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]

Date:   Wed, 31 Jan 2018 10:16:37 -0500
From:   Sean Paul <seanpaul@...omium.org>
To:     Lucas Stach <l.stach@...gutronix.de>
Cc:     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>,
        David Airlie <airlied@...ux.ie>,
        Tomasz Figa <tfiga@...omium.org>,
        Enric Balletbo i Serra <enric.balletbo@...labora.com>,
        Zain Wang <wzz@...k-chips.com>, Lin Huang <hl@...k-chips.com>,
        Douglas Anderson <dianders@...omium.org>,
        dri-devel <dri-devel@...ts.freedesktop.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "open list:ARM/Rockchip SoC..." <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

On Wed, Jan 31, 2018 at 7:54 AM, Lucas Stach <l.stach@...gutronix.de> wrote:
> 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.
>

Agreed, I think we had this discussion the first time around. We
should drop this patch.

Thanks for catching this!

Sean

> 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 = {