On 29/12/15 22:54, Rob Herring wrote:
On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
quoted
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 <redacted>
---
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?
quoted
+- 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