On Sun, Dec 20, 2015 at 12:13:20PM +0100, Uwe Kleine-König wrote:
quoted hunk
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?
+- vcc-supply: phandle of regulator that will be used to enable power to the display
What if there are 2 supplies?
While there are limits to what can be described here, I'm okay with
allowing these, so:
Acked-by: Rob Herring <robh@kernel.org>
Rob
On Tue, Dec 29, 2015 at 9:54 PM, Rob Herring [off-list ref] 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?
So it should be "vcc-supplies". Most properties containing phandles use plural
naming, even if Linux supports a single phandle only (e.g. "power-domains").
You also may want to add an optional "vcc-supply-names" property to
differentiate.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
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