[PATCH v3 06/11] drm/sun4i: rgb: Add DT property to disable strict clock rate check

Rob Herring robh at kernel.org
Mon Feb 18 18:26:29 UTC 2019


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.

> 
> 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 at 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? 

I thought we had some mechanism already to allow some range of 
frequencies. I think the chromeos guys needed something IIRC.

Rob


More information about the dri-devel mailing list