cyrozap has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
cyrozap has joined #linux-amlogic
R0nd has joined #linux-amlogic
Rond has quit [Ping timeout: 255 seconds]
R0nd is now known as Rond
Guest79 has quit [Quit: Client closed]
<jbrunet>
xdarklight: Thanks for taking the time to look at it.
<jbrunet>
On side note #1: I actually experimented with a dedicated PHY driver at one. It is doable, using something like .set_speed() to setup the TMDS bandwidth. The 420 quirk could be dealt with the meson_dw_hdmi.c driver, dividing the requested speed if necessary. This could be transparent IMO. The major hurdle is DT. There is nothing really complicated about where we are trying to go code wise, the ABI stability is going to be a
<jbrunet>
PITA. It is the same for side note #2 actually.
<jbrunet>
Maybe there is way for the display drivers to support both legacy direct HHI access and modern CCF/Reset/PD frameworks in a maintenable fashion but, TBH, I'm not seeing it.
<jbrunet>
And I'm not a fan of this because, when all platform have migrated to the newer version, we end up with big pile of code that is sitting there and is not tested anymore.
<jbrunet>
This is also going to be a problem for s4 and t7 anyway
<jbrunet>
xdarklight: looking at your VCLK CCF dev, it looks promising. Have tried to cut rate propagation at some selected point in the clock tree, instead of using rate_exclusive ? There should be only HDMI fiddling with HDMI pll (I suppose this what you are trying to protect). The rate_exclusive is more intended when several devices compete for the same clock. We tend to set CLK_SET_RATE_PARENT everywhere, it is generally a good
<jbrunet>
thing but not always. For complex cases like that, it can be a problem. I think it is sometimes better if the device owns the PLL (ie: claim it and sets the rate directly) then manages the child clocks. IMO, AML display should work in such a way.