linux-kernel - Re: [PATCH v3 33/43] drm/panel: simple: Change mode for Sharp lq123p1jx31

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1517403243.14302.1.camel@pengutronix.de>
Date:   Wed, 31 Jan 2018 13:54:03 +0100
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Thierry Escande <thierry.escande@...labora.com>,
        Archit Taneja <architt@...eaurora.org>,
        Inki Dae <inki.dae@...sung.com>,
        Thierry Reding <thierry.reding@...il.com>,
        Sandy Huang <hjc@...k-chips.com>,
        Sean Paul <seanpaul@...omium.org>,
        David Airlie <airlied@...ux.ie>,
        Tomasz Figa <tfiga@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>
Cc:     Zain Wang <wzz@...k-chips.com>, Lin Huang <hl@...k-chips.com>,
        Douglas Anderson <dianders@...omium.org>,
        dri-devel@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
        linux-rockchip@...ts.infradead.org,
        Yakir Yang <ykk@...k-chips.com>,
        Ørjan Eide <orjan.eide@....com>,
        Mark Yao <mark.yao@...k-chips.com>,
        Haixia Shi <hshi@...omium.org>
Subject: Re: [PATCH v3 33/43] drm/panel: simple: Change mode for Sharp
 lq123p1jx31

Am Dienstag, den 30.01.2018, 21:29 +0100 schrieb Thierry Escande:
> From: Sean Paul <seanpaul@...omium.org>
> 
> Change the mode for Sharp lq123p1jx31 panel to something more
> rockchip-friendly such that we can use the fixed PLLs to
> generate the pixel clock

This should really switch to a display timing instead of exposing a
single mode. The display timing has min, typical, max tuples for all
the timings values, which would allow the attached driver to vary the
timings inside the allowed bounds if it makes sense.

Trying to hit a specific pixel clock to free up a PLL is exactly one of
the use cases envisioned for the display timings stuff.

Regards,
Lucas
 
> Cc: Chris Zhong <zyw@...k-chips.com>
> Cc: Stéphane Marchesin <marcheu@...omium.org>
> Signed-off-by: Sean Paul <seanpaul@...omium.org>
> Signed-off-by: Thierry Escande <thierry.escande@...labora.com>
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/panel/panel-simple.c
> b/drivers/gpu/drm/panel/panel-simple.c
> index 5591984a392b..a4a6ea3ca0e6 100644
> --- a/drivers/gpu/drm/panel/panel-simple.c
> +++ b/drivers/gpu/drm/panel/panel-simple.c
> @@ -1742,17 +1742,18 @@ static const struct panel_desc
> sharp_lq101k1ly04 = {
>  };
>  
>  static const struct drm_display_mode sharp_lq123p1jx31_mode = {
> -	.clock = 252750,
> +	.clock = 266667,
>  	.hdisplay = 2400,
>  	.hsync_start = 2400 + 48,
>  	.hsync_end = 2400 + 48 + 32,
> -	.htotal = 2400 + 48 + 32 + 80,
> +	.htotal = 2400 + 48 + 32 + 139,
>  	.vdisplay = 1600,
>  	.vsync_start = 1600 + 3,
>  	.vsync_end = 1600 + 3 + 10,
> -	.vtotal = 1600 + 3 + 10 + 33,
> +	.vtotal = 1600 + 3 + 10 + 84,
>  	.vrefresh = 60,
>  	.flags = DRM_MODE_FLAG_NVSYNC | DRM_MODE_FLAG_NHSYNC,
> +	.type = DRM_MODE_TYPE_PREFERRED | DRM_MODE_TYPE_DRIVER,
>  };
>  
>  static const struct panel_desc sharp_lq123p1jx31 = {