Thread (1 message) 1 message, 1 author, 2013-12-06

[PATCHv7][ 2/2] video: backlight: gpio-backlight: Add DT support.

From: Thierry Reding <hidden>
Date: 2013-12-06 14:12:37
Also in: linux-devicetree

On Fri, Dec 06, 2013 at 05:08:38PM +0400, Alexander Shiyan wrote:
quoted
On Thu, Dec 05, 2013 at 06:55:09PM +0100, Denis Carikli wrote:
[...]
quoted
+Optional properties:
+  - default-state: The initial state of the backlight.
+    Valid values are "on", "off", and "keep".
+    The "keep" setting will keep the backlight at whatever its current
+    state is, without producing a glitch. The default is keep if this
+    property is not present.
I'm not sure if "on", "off" and "keep" are a good choice for this
binding. Having strings for these tristate values seems suboptimal.
Other bindings have chosen a representation that, transposed to this
use-case, would read something like this:

	- default-state: The initial state of the backlight. Valid
	  values:
	  - 0: off
	  - 1: on

	If the "default-state" property is not present, the default
	will be to keep the current backlight state.

Which is in fact the exact behaviour that your binding describes, but
it's much more intuitive in my opinion.
Why we cannot use GPIO bindings for active level here?
What a reason for "keep" state? Can this be an additional property?
Default state and active level are two different things.

Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20131206/6b4b0460/attachment.sig>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help