On Fri, Dec 06, 2013 at 05:08:38PM +0400, Alexander Shiyan wrote:
quoted
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.
OK. And what is "default" state? State before "unblank"?
---