Re: [PATCH v2 1/3] devicetree/bindings: add reset-gpios and vcc-supply for panel-dpi

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1705 bytes --]



On 29/12/15 22:54, Rob Herring wrote:
> On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
>> Some displays have a reset input and/or need a regulator to function
>> properly. Allow to specify them for panel-dpi devices.
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
>> ---
>>  Documentation/devicetree/bindings/display/panel/panel-dpi.txt | 2 ++
>>  1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> index 216c894d4f99..b52ac52757df 100644
>> --- a/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> +++ b/Documentation/devicetree/bindings/display/panel/panel-dpi.txt
>> @@ -7,6 +7,8 @@ Required properties:
>>  Optional properties:
>>  - label: a symbolic name for the panel
>>  - enable-gpios: panel enable gpio
>> +- reset-gpios: GPIO to control the RESET pin
> 
> The problem with this in a generic binding is what if the panel has 
> ordering requirements like enable gpio has to be inactive when reset 
> is deasserted?
> 
>> +- vcc-supply: phandle of regulator that will be used to enable power to the display
> 
> What if there are 2 supplies?

Yes, I think it's an impossible task to create a really generic driver
wrt. gpios and supplies. There may be a bunch of them, and a particular
sequence to enable/disable needed, and even particular delays required
in between.

So I think the best we can do is to support (hopefully) most of the
panels by defining one sequence panel-dpi uses. If a particular panel
falls outside that, a separate driver is needed.

 Tomi


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]