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] [day] [month] [year] [list]

Date:   Mon, 6 Feb 2017 08:15:18 -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>,
        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 Mon, Feb 6, 2017 at 4:03 AM, Thierry Reding <thierry.reding@...il.com> wrote:
> On Thu, Feb 02, 2017 at 03:38:53PM -0800, Douglas Anderson 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.
>
> Looks to me like .delay.prepare would be a better fit. That enables the
> regulator and setting it to 300 ms would make sure that the regulator
> will always get enabled for at least 300 ms.

This would also ensure that the 300 ms wasn't violated, right.

> Anyway, your commit message says nothing about why this is important.
> What are the side-effects if the above isn't true? Does the display hang
> in some way?

See my own response where I NAKed my own patch because I realized that
it wasn't fixing the root cause of the problem I was seeing (it just
happened to push timing around).  Basically the problem was that the
backlight was getting turned on while the panel was off and the panel
didn't like that.  This appears to already be addressed with upstream
patches, so picking those into my tree fixed the problem.

It might be nice long term to address some of these "the panel needs
to be on for at least 300 ms" or "the panel needs to be off for at
least 500 ms" in a way that doesn't require a hardcoded delay.

I suppose it could be done today with a custom panel driver, so I
guess it depends on how common those types of requirements are in the
spec and how important they are to actually follow.

-Doug