Devicetree node to turn off LCD when backlight is 'disabled'

Devicetree node to turn off LCD when backlight is 'disabled'

[Tony Prisk]

I was just wondering if the following would be an acceptable way to turn
off an lcd backlight when the pwm-backlight driver is set to level 0.
The LCD backlight is 'powered' by the gpio.

leds {
	compatible = "gpio-leds";
	backlight {
		label = "lcd-power";
		gpios = <&gpio 0 0 0>;  /* bank pin active_low */
		linux,default-trigger = "backlight";
		default-state = "on";
	};
};

The method has been tested by an end-user and confirmed as working - I
just wanted to check whether it is the 'accepted' way of doing it.

Regards
Tony Prisk

Devicetree node to turn off LCD when backlight is 'disabled'

[Thierry Reding]

On Mon, Feb 11, 2013 at 07:25:05PM +1300, Tony Prisk wrote:
> I was just wondering if the following would be an acceptable way to turn
> off an lcd backlight when the pwm-backlight driver is set to level 0.
> The LCD backlight is 'powered' by the gpio.
> 
> leds {
> 	compatible = "gpio-leds";
> 	backlight {
> 		label = "lcd-power";
> 		gpios = <&gpio 0 0 0>;  /* bank pin active_low */
> 		linux,default-trigger = "backlight";
> 		default-state = "on";
> 	};
> };
> 
> The method has been tested by an end-user and confirmed as working - I
> just wanted to check whether it is the 'accepted' way of doing it.

I don't quite see how this is related to pwm-backlight. Maybe you can
post a more complete example? Representing the backlight power as a GPIO
controlled LED seems somewhat kludgy.

That said, there is currently no "accepted" way to use a GPIO to control
the power to the backlight in pwm-backlight. There was some work by Alex
(Cc'ed) to integrate this using generic power-sequences, but there was
some pushback on that. Your best bet currently would seem to integrate
this with the CDF (Common Display Framework). Unfortunately that'd mean
you'd need to write a whole new driver to abstract the panel. Even in
CDF there are ongoing discussions about how to hook it up with the
backlight framework. I know this doesn't give you a solution right away
but I think it's the best way to represent the actual hardware and it
takes into account a number of other aspect about displays as well.

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/20130212/4bd63fdd/attachment-0001.sig>

Devicetree node to turn off LCD when backlight is 'disabled'

[Tony Prisk]

On Tue, 2013-02-12 at 08:04 +0100, Thierry Reding wrote:
> On Mon, Feb 11, 2013 at 07:25:05PM +1300, Tony Prisk wrote:
> > I was just wondering if the following would be an acceptable way to turn
> > off an lcd backlight when the pwm-backlight driver is set to level 0.
> > The LCD backlight is 'powered' by the gpio.
> > 
> > leds {
> > 	compatible = "gpio-leds";
> > 	backlight {
> > 		label = "lcd-power";
> > 		gpios = <&gpio 0 0 0>;  /* bank pin active_low */
> > 		linux,default-trigger = "backlight";
> > 		default-state = "on";
> > 	};
> > };
> > 
> > The method has been tested by an end-user and confirmed as working - I
> > just wanted to check whether it is the 'accepted' way of doing it.
> 
> I don't quite see how this is related to pwm-backlight. Maybe you can
> post a more complete example? Representing the backlight power as a GPIO
> controlled LED seems somewhat kludgy.
> 
> That said, there is currently no "accepted" way to use a GPIO to control
> the power to the backlight in pwm-backlight. There was some work by Alex
> (Cc'ed) to integrate this using generic power-sequences, but there was
> some pushback on that. Your best bet currently would seem to integrate
> this with the CDF (Common Display Framework). Unfortunately that'd mean
> you'd need to write a whole new driver to abstract the panel. Even in
> CDF there are ongoing discussions about how to hook it up with the
> backlight framework. I know this doesn't give you a solution right away
> but I think it's the best way to represent the actual hardware and it
> takes into account a number of other aspect about displays as well.
> 
> Thierry


Just to clarify - I'm not looking for a way to do it immediately.

The small snippet was sent as a patch to me by an end-user and although
it worked, it just didn't 'feel' right so I thought I'd get a bit of
feedback on it.

Thanks for your thoughts.

Regards
Tony P

Devicetree node to turn off LCD when backlight is 'disabled'

[Alex Courbot]

On 02/11/2013 03:25 PM, Tony Prisk wrote:
> I was just wondering if the following would be an acceptable way to turn
> off an lcd backlight when the pwm-backlight driver is set to level 0.
> The LCD backlight is 'powered' by the gpio.
>
> leds {
> 	compatible = "gpio-leds";
> 	backlight {
> 		label = "lcd-power";
> 		gpios = <&gpio 0 0 0>;  /* bank pin active_low */
> 		linux,default-trigger = "backlight";
> 		default-state = "on";
> 	};
> };

This would work... for the most common case of a FB blank event (as 
gpio-leds will be notified of it and switch your GPIO on/off according 
to the kind of event). There are a few drawbacks however:

1) You will have no control over the order of your power sequence. 
pwm-backlight also uses FB notifications to switch the PWM on/off. Which 
one will happen first will depend on the registration order.

2) This will only work on FB blank events. For instance, if someone 
writes "0" into the "brightness" property of your backlight's sysfs 
node, no FB blank event will be emitted and your GPIO will remain on.

Also this solution works for the simple case where you control the 
backlight using only a GPIO. It would be good to support more complex 
cases as well (I have to handle a GPIO and a regulator, for instance).

The "correct" way of doing this would be to let the pwm-backlight driver 
(or even the backlight framework) control the power status of the 
backlight itself. You can do this using the platform callbacks of 
pwm-backlight, but this will require a custom panel. Another possibility 
would be to use the power sequence framework within the backlight 
drivers, but I need to rewrite it first.

So as an ad-hoc solution, what you propose would certainly work - 
however I think this is a good opportunity to try and solve this problem 
more globally. Maybe we can start discussing about Power Sequences 2.0. :)

Alex.

Devicetree node to turn off LCD when backlight is 'disabled'

[Grant Likely]

On Tue, 12 Feb 2013 16:35:56 +0900, Alex Courbot <acourbot@nvidia.com> wrote:
> On 02/11/2013 03:25 PM, Tony Prisk wrote:
> > I was just wondering if the following would be an acceptable way to turn
> > off an lcd backlight when the pwm-backlight driver is set to level 0.
> > The LCD backlight is 'powered' by the gpio.
> >
> > leds {
> > 	compatible = "gpio-leds";
> > 	backlight {
> > 		label = "lcd-power";
> > 		gpios = <&gpio 0 0 0>;  /* bank pin active_low */
> > 		linux,default-trigger = "backlight";
> > 		default-state = "on";
> > 	};
> > };
> 
> This would work... for the most common case of a FB blank event (as 
> gpio-leds will be notified of it and switch your GPIO on/off according 
> to the kind of event). There are a few drawbacks however:
> 
> 1) You will have no control over the order of your power sequence. 
> pwm-backlight also uses FB notifications to switch the PWM on/off. Which 
> one will happen first will depend on the registration order.
> 
> 2) This will only work on FB blank events. For instance, if someone 
> writes "0" into the "brightness" property of your backlight's sysfs 
> node, no FB blank event will be emitted and your GPIO will remain on.
> 
> Also this solution works for the simple case where you control the 
> backlight using only a GPIO. It would be good to support more complex 
> cases as well (I have to handle a GPIO and a regulator, for instance).
> 
> The "correct" way of doing this would be to let the pwm-backlight driver 
> (or even the backlight framework) control the power status of the 
> backlight itself. You can do this using the platform callbacks of 
> pwm-backlight, but this will require a custom panel. Another possibility 
> would be to use the power sequence framework within the backlight 
> drivers, but I need to rewrite it first.

That really does sound like the right approach, and wiring it up to a
GPIO sounds reasonable. I don't think there is a need to use platform
callbacks for this.

g.