On Tue, Feb 19, 2019 at 07:44:56AM -0800, Vasily Khoruzhick wrote:
On Tue, Feb 19, 2019 at 12:56 AM Maxime Ripard maxime.ripard@bootlin.com wrote:
On Mon, Feb 18, 2019 at 11:33:05AM -0800, Vasily Khoruzhick wrote:
On Mon, Feb 18, 2019 at 10:26 AM Rob Herring robh@kernel.org wrote:
On Thu, Feb 14, 2019 at 09:09:52PM -0800, Vasily Khoruzhick wrote:
Clock rate check that was added in commit bb43d40d7c83 ("drm/sun4i: rgb: Validate the clock rate") prevents some panel and bridges from working with sun4i driver.
Sounds lile a regression that should be reverted. The fix is not a backwards compatible change either.
anx6345 driver isn't mainlined yet and I'm not sure if this change breaks any mainlined boards. So likely there's not enough justification to revert it.
Unfortunately, dotclock frequency for some modes are not achievable on sunxi hardware, and there's a slight deviation in rate returned by clk_round_rate(), so they fail this check.
Experiments show that panels and bridges work fine with this slight deviation, e.g. Pinebook that uses ANX6345 bridge with 768p eDP panel requests 73 MHz, gets 72.296MHz instead (0.96% difference) and works just fine.
This patch adds DT property to disable strict clock rate check
Signed-off-by: Vasily Khoruzhick anarsoul@gmail.com
.../devicetree/bindings/display/sunxi/sun4i-drm.txt | 2 ++ drivers/gpu/drm/sun4i/sun4i_rgb.c | 5 +++++ drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 +++ drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + 4 files changed, 11 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index f426bdb42f18..18c8b053a28d 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -63,6 +63,8 @@ Required properties: Documentation/devicetree/bindings/media/video-interfaces.txt. The first port should be the input endpoint. The second should be the output, usually to an HDMI connector.
- no-strict-clock-check: don't reject timings if exact dot clock can't be
- reached.
This should be the default IMO. Most panels are a single timing, so if we reject it the fallback no display?
As far as I remember the change was introduced to reject some modes for which dotclock can't be reached when driver is used with VGA bridge. So if we make it default it'll break boards with VGA bridge and old DT.
I thought we had some mechanism already to allow some range of frequencies. I think the chromeos guys needed something IIRC.
You can specify frequency range for panels, but there's nothing for bridges. In my case EDID doesn't specify clock tolerance.
I gave it some more though, and came up with the following patch. The basic idea is to leave the boundary check for the bridges that will have EDID and we need to filter out the modes that have no chance of being supported. The tolerancy used is the one defined in VESA specs, but I added a module parameter if you wanted to tune that.
And finally, since most of our panels are single timings without any tolerancy, we just try our best in this case and that's it, while leaving the door open to support display_timings and being able to do more once we have an idea of what the tolerancies are.
If that works for you, I'll submit it.
Maxime, thanks for your patch but it doesn't work for me. Pinebook needs 1% tolerance. Having it as a module parameter means that no distro will be able to boot on Pinebook out of the box.
I don't really know what to tell you, the VESA spec defines everywhere that tolerance, and if we're not able to provide that, then we're not compliant and I don't want us to not be compliant just because one panel needed to be a bit more flexible, and especially since what could work on one panel might fail on another one.
If you want alternate solutions, then please answer to: http://lists.infradead.org/pipermail/linux-arm-kernel/2019-February/630441.h...
or provide the EDID blob.
Maxime