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@xxxxxxxxxxxxxx> >> --- >> 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:
signature.asc
Description: OpenPGP digital signature
