linux-kernel - Re: [PATCH] drm/panel: simple: ensure Sharp lq123p1jx31 isn't turned off too soon

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:   Fri, 3 Feb 2017 18:36:37 -0800
From:   Doug Anderson <dianders@...omium.org>
To:     Thierry Reding <thierry.reding@...il.com>
Cc:     Sean Paul <seanpaul@...omium.org>,
        Stéphane Marchesin <marcheu@...omium.org>,
        Brian Norris <briannorris@...omium.org>,
        Kristian Kristensen <hoegsberg@...gle.com>,
        Douglas Anderson <dianders@...omium.org>,
        David Airlie <airlied@...ux.ie>,
        "dri-devel@...ts.freedesktop.org" <dri-devel@...ts.freedesktop.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] drm/panel: simple: ensure Sharp lq123p1jx31 isn't turned
 off too soon

Hi

On Thu, Feb 2, 2017 at 3:38 PM, Douglas Anderson <dianders@...omium.org> wrote:
> The Sharp lq123p1jx31 has a requirement that the VDD is on for at
> least 300 ms before being turned off.  At the moment nothing anywhere
> in the kernel is ensuring this.
>
> The simplest way to ensure this is to add a "disable" timing of 150
> ms.  With this the we know that there will be at least 300 ms between
> the regulator/gpio being turned on and being turned off.
> Specifically, here's what happens after this change:
>
> * prepare: enable regulator, delay 110 ms (10 for regulator, then 100)
> * enable: delay 50 ms
> * disable: delay 150 ms, then disable regulator
> * unprepare: delay 550 ms (50 for regulator, 500 to off=>on too quick)
>
> As you can see, even giving the regulator 10 ms (the max the panel
> spec allows) for ramping up we are sure that the regulator was on for
> 300 ms now.
>
> Signed-off-by: Douglas Anderson <dianders@...omium.org>
> ---
>  drivers/gpu/drm/panel/panel-simple.c | 1 +
>  1 file changed, 1 insertion(+)

NAKing my own patch.

While this patch _does_ indeed enforce a requirement from the
datasheet and also empirically fixes the problem I was seeing, I'm
nearly certain that the reason it works has more to do with luck than
anything else.

After a little more digging, I'm becoming more certain that we need to
manage the backlight state for this panel and sequence it properly
with the enable signals.  Assuming this is correct, I will likely post
another patch adding a custom panel driver.

-Doug