Thread (16 messages) 16 messages, 4 authors, 2012-09-07

Re: [PATCH v5 2/4] pwm_backlight: use power sequences

flat view

From: Alex Courbot <acourbot@nvidia.com>
Date: 2012-09-07 08:26:27
Also in: linux-devicetree, linux-tegra, lkml

On Thursday 06 September 2012 01:25:27 Stephen Warren wrote:
On 08/31/2012 05:34 AM, Alexandre Courbot wrote:
quoted
Make use of the power sequences specified in the device tree or platform
data to control how the backlight is powered on and off.
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt

 Optional properties:
-  - pwm-names: a list of names for the PWM devices specified in the
-               "pwms" property (see PWM binding[0])
+  - pwm-names: name for the PWM device specified in the "pwms" property
(see PWM +      binding[0]). Necessary if power sequences are used
So this implies that power sequence are completely optional in the pwm
binding...
quoted
diff --git a/drivers/video/backlight/Kconfig
b/drivers/video/backlight/Kconfig> 
 config BACKLIGHT_PWM
 
 	tristate "Generic PWM based Backlight Driver"
 	depends on PWM

+	select POWER_SEQ
... but that implies they're basically mandatory.

Briefly looking at the code, power sequences don't appear to be
optional, at least for the DT case, so perhaps you just need to update
the documentation to make "pwm-names" non-optional?
This has to do with how power sequences are enabled during the build. Instead 
of providing yet-another-kernel-option, I thought it would be better to make 
it invisible and let drivers that take advantage of power seqs enable the 
option by themselves when they are selected. That's why power sequences are 
unconditionally compiled when pwm-backlight is selected.

But on the other hand, pwm-backlight already has a DT interface that does not 
use power sequences, and its current users are still relying on the legacy 
platform data interface (with one PWM and some callback functions). Making the 
power sequences mandatory in the DT bindings would make it impossible to use 
that legacy interface.

We could make power sequences an option of its own and add #ifdefs to drivers 
that use it to lift this ambiguity, but I like the transparency of the current 
way. It also seems hard (illegal?) to get rid of the legacy DT interface.

Alex.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help