linux-kernel - Re: [PATCH v2] drm/panel: simple: Support reset GPIOs

Open Source and information security mailing list archives

Message-ID: <519b5628-3e40-b034-8efd-56288cc2159e@phytec.de>
Date:   Wed, 29 Apr 2020 15:45:04 +0200
From:   Wadim Egorov <w.egorov@...tec.de>
To:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Sam Ravnborg <sam@...nborg.org>
Cc:     Thomas Petazzoni <thomas.petazzoni@...tlin.com>,
        David Airlie <airlied@...ux.ie>, linux-kernel@...r.kernel.org,
        dri-devel@...ts.freedesktop.org,
        Maxime Chevallier <maxime.chevallier@...tlin.com>,
        Paul Kocialkowski <paul.kocialkowski@...tlin.com>,
        Thierry Reding <thierry.reding@...il.com>
Subject: Re: [PATCH v2] drm/panel: simple: Support reset GPIOs

Hi Sam,

you've asked in another thread [1] if there is any known simple panel
that requires a reset. We have a Densitron DMT070WSNLCMI-1E Panel
(compatible to avic,tm070ddh03) with some reset timing requirements, [2]
Page 20. So it would be nice to see this patch accepted.

[1] https://patchwork.kernel.org/patch/11292207/
[2]
https://www.densitron.com/sites/default/files/2019-09/DMT070WSNLCMI-1E%20Rev%20A.pdf

Regards,
Wadim

On 06.01.20 10:10, Miquel Raynal wrote:
> Hi Sam,
>
> Sam Ravnborg <sam@...nborg.org> wrote on Thu, 2 Jan 2020 18:27:00 +0100:
>
>> Hi Miquel
>>
>> On Tue, Dec 24, 2019 at 03:21:34PM +0100, Miquel Raynal wrote:
>>> The panel common bindings provide a gpios-reset property. Let's
>>> support it in the simple driver.
>>>
>>> Two fields are added to the panel description structure: the time to
>>> assert the reset and the time to wait right after before starting to
>>> interact with it in any manner. In case these default values are not
>>> filled but the GPIO is present in the DT, default values are applied.  
>> Wehn we discussed this the last time you wrote:
>>
>> """
>> my hardware is:
>>
>> LVDS IP <----------> LVDS to RGB bridge <------------> Panel
>>
>> While there is a simple "RGB to LVDS" bridge driver, there is none
>> doing the work the other way around. In my case, the bridge has a reset
>> pin.
>>
>> As until now there is no way to represent the "LVDS to RGB" bridge and
>> because the bindings already document such reset pin, I decided to add
>> support for it in the simple panel driver.
>> """
>>
>> Based on the information provided it seems that the correct way is to
>> add a "LVDS to RGB bridge" and then let the bridge handle the reset
>> functionality.
> This I agree, but we are talking about my current situation. 
>
>> It is obviously much more code to do it this way but then
>> other panels using the same type of brigde have the
>> same functionality without adding bridge functionality to the panel.
> This, I do not fully agree as bindings for the panel reset already
> exist and we could have a reset on both: the bridge and the panel.
> I choose to use a wrong (private) DT representation because I am not
> willing to add an LVDS->RGB bridge: as you say, it is much more work to
> do. But, IMHO, this is not related to the patch. If you consider this
> patch wrong because a panel cannot have a reset, then it should be
> stated clearly and maybe removed from the bindings?
>
> Anyway if you think this change can't be useful, let's put it aside.
>
> Thanks for your time,
> Miquèl
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@...ts.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

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