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 08:52:59 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Sean Paul <seanpaul@...omium.org>
Cc:     Lucas Stach <l.stach@...gutronix.de>,
        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>,
        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

Hi,

On Wed, Jan 31, 2018 at 7:16 AM, Sean Paul <seanpaul@...omium.org> wrote:
> 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!

Are you sure we should drop this?  In order for things to work
properly (not generate noise on the digitizer or other EMI), this
needs to run at a very specific pixel clock with very specific
blanking times.  I know that earlier we had slightly different
blanking times and Samsung came back and said that there was noise on
the digitizer.  I could be wrong, but I don't think there's any way
currently to be able to specify exactly what timings should be used on
a particular board.

Don't get be wrong--I think a patch such as this one that claims a
single board's timings as the "right" ones for a generic panel is a
bit of a hack.  ...but at the same time there are no other users of
this panel (that I know of) in mainline and the timings presented here
are certainly sane timings for this panel.

In any case, previous discussion at: https://patchwork.kernel.org/patch/9614603/

...oh, and looking at the previous discussion reminds me that the
timings presented in this here patch are actually not the right ones
(they have the right PLL, but the wrong blankings to avoid the noise
issues).  See <//chromium-review.googlesource.com/381015>

-Doug