<robmur01>
mmind00: I did briefly look into it, and IIRC there was no immediate easy solution. Hence I think Sascha's v2 of the "relax mode valid hook" patch is an OK compromise for that aspect. But then there's the stickier problem of whether the clock accuracy at arbitrary rates is actually good enough, as reported on that same series
<CounterPillow>
Just to make sure I understand the problem domain correctly: there are either one of two PHYs, and the latter validates the mode again with no way to properly reject it because the mode validation only works properly for one of them, and also there are clock accuracy rate issues on certain SoCs?
<CounterPillow>
if this is a matter of making the phy pluggable for dw-hdmi-rockchip then I can look into that since I have all the fun boards needed to validate this around, it's just a matter of finding the time/energy and understanding the problem
kevery has quit [Remote host closed the connection]
kevery has joined #linux-rockchip
<robmur01>
the current validation "works properly" in the sense that it effectively hard-codes a set of clock rates that are known to be good for both the Synopsys and Innosilicon (RK3338/3228) phys
jagan has quit [Quit: Connection closed]
<robmur01>
the problems of going beyond that then differ depending on the phy. The Synopsys one can *nominally* support pretty much any rate, but what actually goes out to the monitor seems to depend on how good the upstream PLL is, and some monitors are less tolerant than others.
<CounterPillow>
oh lovely, so even if I made the synopsys stuff non-hardcoded it would still break working setups because some chips have screwy PLLs, gotcha
<CounterPillow>
if the quality of the upstream PLL is a known quantity for some chips we could have three "tiers", hardcoded small set for innosilicon, hardcoded expanded set with stuff like 4K for synopsys with screwy PLL, and then a fully whatever set for ones where the PLL is ok