[PATCHv7][ 2/2] video: backlight: gpio-backlight: Add DT support.
thierry.reding at gmail.com
Fri Dec 6 09:12:37 EST 2013
On Fri, Dec 06, 2013 at 05:08:38PM +0400, Alexander Shiyan wrote:
> > On Thu, Dec 05, 2013 at 06:55:09PM +0100, Denis Carikli wrote:
> > [...]
> > > +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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 836 bytes
Desc: not available
More information about the linux-arm-kernel