On Wed, Aug 24, 2022 at 05:07:50PM +0100, Robin Murphy wrote: > On 2022-08-22 16:20, Sascha Hauer wrote: > > The driver checks if the pixel clock of the given mode matches an entry > > in the mpll config table. The frequencies in the mpll table are meant as > > a frequency range up to which the entry works, not as a frequency that > > must match the pixel clock. Return MODE_OK when the pixelclock is > > smaller than one of the mpll frequencies to allow for more display > > resolutions. > > Has the issue been fixed that this table is also used to validate modes on > RK3328, which doesn't even *have* the Synopsys phy? Last time I looked, that > tended to lead to complete display breakage when the proper phy driver later > decides it doesn't like a pixel clock that mode_valid already said was OK. > > The more general concern is that these known-good clock rates are good, but > others may not be even when nominally supported, which I suspect is the > dirty secret of why it was implemented this way to begin with. I would > really really love this patch so my RK3399 board can drive my 1920x1200 > monitor at native resolution, but on the other hand my RK3288 box generates > such a crap 154MHz clock for that mode that - unless that's been improved in > the meantime too - patch #2 might be almost be considered a regression if it > means such a setup would start defaulting to an unusably glitchy display > instead of falling back to 1920x1080 which does at least work perfectly > (even if the slightly squished aspect ratio is ugly). I could limit the change to rk3568 only. Would that be an option? Not sure if I should rk3399 as well then as this would work, at least in your setup. Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
