* [PATCH 0/2 v2] Add mandatory regulator for all users of pwm-backlight.
@ 2013-03-12 22:22 Andrew Chew
2013-03-12 22:22 ` [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight Andrew Chew
2013-03-12 22:22 ` [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator Andrew Chew
0 siblings, 2 replies; 12+ messages in thread
From: Andrew Chew @ 2013-03-12 22:22 UTC (permalink / raw)
To: peter.ujfalusi; +Cc: thierry.reding, acourbot, achew, linux-omap
Many backlights are enabled via GPIO. We can generalize the GPIO to a
fixed regulator.
The enable regulator needs to be mandatory because there was no good way
to determine the difference between opting out of the regulator, and probe
deferral.
This series of patches is intended to add a dummy regulator (or a GPIO
regulator) for all users of the pwm-backlight.
The last patch in the series will always be the pwm-backlight change to add
this mandatory regulator. Patches following up to that patch add the
mandatory regulator on a per mach family basis. Once all users of
pwm-backlight have been patched, this series can be applied in order to
maintain bisectability.
Andrew Chew (2):
ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight
pwm_bl: Add mandatory backlight enable regulator
.../bindings/video/backlight/pwm-backlight.txt | 14 +++++
arch/arm/mach-omap2/board-4430sdp.c | 5 ++
drivers/video/backlight/pwm_bl.c | 55 ++++++++++++++++----
3 files changed, 64 insertions(+), 10 deletions(-)
--
1.7.9.5
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight
2013-03-12 22:22 [PATCH 0/2 v2] Add mandatory regulator for all users of pwm-backlight Andrew Chew
@ 2013-03-12 22:22 ` Andrew Chew
2013-03-13 8:51 ` Peter Ujfalusi
2013-03-12 22:22 ` [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator Andrew Chew
1 sibling, 1 reply; 12+ messages in thread
From: Andrew Chew @ 2013-03-12 22:22 UTC (permalink / raw)
To: peter.ujfalusi; +Cc: thierry.reding, acourbot, achew, linux-omap
The pwm-backlight driver now takes a mandatory regulator that is gotten
during driver probe. Initialize a dummy regulator to satisfy this
requirement.
Signed-off-by: Andrew Chew <achew@nvidia.com>
---
arch/arm/mach-omap2/board-4430sdp.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
index 35f3ad0..62022c0 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -291,6 +291,10 @@ static struct platform_device sdp4430_leds_pwm = {
},
};
+/* Dummy regulator for pwm-backlight driver */
+static struct regulator_consumer_supply backlight_supply =
+ REGULATOR_SUPPLY("enable", NULL);
+
static struct platform_pwm_backlight_data sdp4430_backlight_data = {
.max_brightness = 127,
.dft_brightness = 127,
@@ -718,6 +722,7 @@ static void __init omap_4430sdp_init(void)
omap4_i2c_init();
omap_sfh7741prox_init();
+ regulator_register_always_on(-1, "bl-enable", &backlight_supply, 1, 0);
platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
omap_serial_init();
omap_sdrc_init(NULL, NULL);
--
1.7.9.5
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator
2013-03-12 22:22 [PATCH 0/2 v2] Add mandatory regulator for all users of pwm-backlight Andrew Chew
2013-03-12 22:22 ` [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight Andrew Chew
@ 2013-03-12 22:22 ` Andrew Chew
2013-03-13 8:56 ` Peter Ujfalusi
1 sibling, 1 reply; 12+ messages in thread
From: Andrew Chew @ 2013-03-12 22:22 UTC (permalink / raw)
To: peter.ujfalusi; +Cc: thierry.reding, acourbot, achew, linux-omap
Many backlights need to be explicitly enabled. Typically, this is done
with a GPIO. For flexibility, we generalize the enable mechanism to a
regulator.
If an enable regulator is not needed, then a dummy regulator can be given
to the backlight driver. If a GPIO is used to enable the backlight,
then a fixed regulator can be instantiated to control the GPIO.
The backlight enable regulator can be specified in the device tree node
for the backlight, or can be done with legacy board setup code in the
usual way.
Signed-off-by: Andrew Chew <achew@nvidia.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
---
.../bindings/video/backlight/pwm-backlight.txt | 14 +++++
drivers/video/backlight/pwm_bl.c | 55 ++++++++++++++++----
2 files changed, 59 insertions(+), 10 deletions(-)
diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
index 1e4fc72..7e2e089 100644
--- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
@@ -10,6 +10,11 @@ Required properties:
last value in the array represents a 100% duty cycle (brightest).
- default-brightness-level: the default brightness level (index into the
array defined by the "brightness-levels" property)
+ - enable-supply: A phandle to the regulator device tree node. This
+ regulator will be turned on and off as the pwm is enabled and disabled.
+ Many backlights are enabled via a GPIO. In this case, we instantiate
+ a fixed regulator and give that to enable-supply. If a regulator
+ is not needed, then provide a dummy fixed regulator.
Optional properties:
- pwm-names: a list of names for the PWM devices specified in the
@@ -19,10 +24,19 @@ Optional properties:
Example:
+ bl_en: fixed-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "bl-en-supply";
+ regulator-boot-on;
+ gpio = <&some_gpio>;
+ enable-active-high;
+ };
+
backlight {
compatible = "pwm-backlight";
pwms = <&pwm 0 5000000>;
brightness-levels = <0 4 8 16 32 64 128 255>;
default-brightness-level = <6>;
+ enable-supply = <&bl_en>;
};
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1fea627..c557c51 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -20,10 +20,13 @@
#include <linux/pwm.h>
#include <linux/pwm_backlight.h>
#include <linux/slab.h>
+#include <linux/regulator/consumer.h>
struct pwm_bl_data {
struct pwm_device *pwm;
struct device *dev;
+ bool enabled;
+ struct regulator *enable_supply;
unsigned int period;
unsigned int lth_brightness;
unsigned int *levels;
@@ -35,6 +38,38 @@ struct pwm_bl_data {
void (*exit)(struct device *);
};
+static void pwm_backlight_enable(struct backlight_device *bl)
+{
+ struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
+
+ /* Bail if we are already enabled. */
+ if (pb->enabled)
+ return;
+
+ pwm_enable(pb->pwm);
+
+ if (regulator_enable(pb->enable_supply) != 0)
+ dev_warn(&bl->dev, "Failed to enable regulator");
+
+ pb->enabled = true;
+}
+
+static void pwm_backlight_disable(struct backlight_device *bl)
+{
+ struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
+
+ /* Bail if we are already disabled. */
+ if (!pb->enabled)
+ return;
+
+ if (regulator_disable(pb->enable_supply) != 0)
+ dev_warn(&bl->dev, "Failed to disable regulator");
+
+ pwm_disable(pb->pwm);
+
+ pb->enabled = false;
+}
+
static int pwm_backlight_update_status(struct backlight_device *bl)
{
struct pwm_bl_data *pb = bl_get_data(bl);
@@ -51,7 +86,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
if (brightness == 0) {
pwm_config(pb->pwm, 0, pb->period);
- pwm_disable(pb->pwm);
+ pwm_backlight_disable(bl);
} else {
int duty_cycle;
@@ -65,7 +100,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
duty_cycle = pb->lth_brightness +
(duty_cycle * (pb->period - pb->lth_brightness) / max);
pwm_config(pb->pwm, duty_cycle, pb->period);
- pwm_enable(pb->pwm);
+ pwm_backlight_enable(bl);
}
if (pb->notify_after)
@@ -138,12 +173,6 @@ static int pwm_backlight_parse_dt(struct device *dev,
data->max_brightness--;
}
- /*
- * TODO: Most users of this driver use a number of GPIOs to control
- * backlight power. Support for specifying these needs to be
- * added.
- */
-
return 0;
}
@@ -206,6 +235,12 @@ static int pwm_backlight_probe(struct platform_device *pdev)
pb->exit = data->exit;
pb->dev = &pdev->dev;
+ pb->enable_supply = devm_regulator_get(&pdev->dev, "enable");
+ if (IS_ERR(pb->enable_supply)) {
+ ret = PTR_ERR(pb->enable_supply);
+ goto err_alloc;
+ }
+
pb->pwm = devm_pwm_get(&pdev->dev, NULL);
if (IS_ERR(pb->pwm)) {
dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
@@ -268,7 +303,7 @@ static int pwm_backlight_remove(struct platform_device *pdev)
backlight_device_unregister(bl);
pwm_config(pb->pwm, 0, pb->period);
- pwm_disable(pb->pwm);
+ pwm_backlight_disable(bl);
if (pb->exit)
pb->exit(&pdev->dev);
return 0;
@@ -283,7 +318,7 @@ static int pwm_backlight_suspend(struct device *dev)
if (pb->notify)
pb->notify(pb->dev, 0);
pwm_config(pb->pwm, 0, pb->period);
- pwm_disable(pb->pwm);
+ pwm_backlight_disable(bl);
if (pb->notify_after)
pb->notify_after(pb->dev, 0);
return 0;
--
1.7.9.5
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight
2013-03-12 22:22 ` [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight Andrew Chew
@ 2013-03-13 8:51 ` Peter Ujfalusi
2013-03-13 20:38 ` Andrew Chew
0 siblings, 1 reply; 12+ messages in thread
From: Peter Ujfalusi @ 2013-03-13 8:51 UTC (permalink / raw)
To: Andrew Chew; +Cc: thierry.reding, acourbot, linux-omap
On 03/12/2013 11:22 PM, Andrew Chew wrote:
> The pwm-backlight driver now takes a mandatory regulator that is gotten
> during driver probe. Initialize a dummy regulator to satisfy this
> requirement.
I can test this tomorrow, but I have one comment:
>
> Signed-off-by: Andrew Chew <achew@nvidia.com>
> ---
> arch/arm/mach-omap2/board-4430sdp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
> index 35f3ad0..62022c0 100644
> --- a/arch/arm/mach-omap2/board-4430sdp.c
> +++ b/arch/arm/mach-omap2/board-4430sdp.c
> @@ -291,6 +291,10 @@ static struct platform_device sdp4430_leds_pwm = {
> },
> };
>
> +/* Dummy regulator for pwm-backlight driver */
> +static struct regulator_consumer_supply backlight_supply =
> + REGULATOR_SUPPLY("enable", NULL);
'enable' is just too generic, the device name should be also provided:
REGULATOR_SUPPLY("enable", "pwm-backlight");
> +
> static struct platform_pwm_backlight_data sdp4430_backlight_data = {
> .max_brightness = 127,
> .dft_brightness = 127,
> @@ -718,6 +722,7 @@ static void __init omap_4430sdp_init(void)
>
> omap4_i2c_init();
> omap_sfh7741prox_init();
> + regulator_register_always_on(-1, "bl-enable", &backlight_supply, 1, 0);
> platform_add_devices(sdp4430_devices, ARRAY_SIZE(sdp4430_devices));
> omap_serial_init();
> omap_sdrc_init(NULL, NULL);
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator
2013-03-12 22:22 ` [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator Andrew Chew
@ 2013-03-13 8:56 ` Peter Ujfalusi
2013-03-13 10:13 ` Thierry Reding
2013-03-13 21:10 ` Andrew Chew
0 siblings, 2 replies; 12+ messages in thread
From: Peter Ujfalusi @ 2013-03-13 8:56 UTC (permalink / raw)
To: Andrew Chew; +Cc: thierry.reding, acourbot, linux-omap
On 03/12/2013 11:22 PM, Andrew Chew wrote:
> Many backlights need to be explicitly enabled. Typically, this is done
> with a GPIO. For flexibility, we generalize the enable mechanism to a
> regulator.
>
> If an enable regulator is not needed, then a dummy regulator can be given
> to the backlight driver. If a GPIO is used to enable the backlight,
> then a fixed regulator can be instantiated to control the GPIO.
>
> The backlight enable regulator can be specified in the device tree node
> for the backlight, or can be done with legacy board setup code in the
> usual way.
>
> Signed-off-by: Andrew Chew <achew@nvidia.com>
> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
> ---
> .../bindings/video/backlight/pwm-backlight.txt | 14 +++++
> drivers/video/backlight/pwm_bl.c | 55 ++++++++++++++++----
> 2 files changed, 59 insertions(+), 10 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> index 1e4fc72..7e2e089 100644
> --- a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> +++ b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt
> @@ -10,6 +10,11 @@ Required properties:
> last value in the array represents a 100% duty cycle (brightest).
> - default-brightness-level: the default brightness level (index into the
> array defined by the "brightness-levels" property)
> + - enable-supply: A phandle to the regulator device tree node. This
> + regulator will be turned on and off as the pwm is enabled and disabled.
> + Many backlights are enabled via a GPIO. In this case, we instantiate
> + a fixed regulator and give that to enable-supply. If a regulator
> + is not needed, then provide a dummy fixed regulator.
>
> Optional properties:
> - pwm-names: a list of names for the PWM devices specified in the
> @@ -19,10 +24,19 @@ Optional properties:
>
> Example:
>
> + bl_en: fixed-regulator {
> + compatible = "regulator-fixed";
> + regulator-name = "bl-en-supply";
> + regulator-boot-on;
> + gpio = <&some_gpio>;
> + enable-active-high;
> + };
> +
> backlight {
> compatible = "pwm-backlight";
> pwms = <&pwm 0 5000000>;
>
> brightness-levels = <0 4 8 16 32 64 128 255>;
> default-brightness-level = <6>;
> + enable-supply = <&bl_en>;
> };
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 1fea627..c557c51 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -20,10 +20,13 @@
> #include <linux/pwm.h>
> #include <linux/pwm_backlight.h>
> #include <linux/slab.h>
> +#include <linux/regulator/consumer.h>
>
> struct pwm_bl_data {
> struct pwm_device *pwm;
> struct device *dev;
> + bool enabled;
> + struct regulator *enable_supply;
> unsigned int period;
> unsigned int lth_brightness;
> unsigned int *levels;
> @@ -35,6 +38,38 @@ struct pwm_bl_data {
> void (*exit)(struct device *);
> };
>
> +static void pwm_backlight_enable(struct backlight_device *bl)
> +{
> + struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
> +
> + /* Bail if we are already enabled. */
> + if (pb->enabled)
> + return;
> +
> + pwm_enable(pb->pwm);
> +
> + if (regulator_enable(pb->enable_supply) != 0)
I would loose the '!= 0'
> + dev_warn(&bl->dev, "Failed to enable regulator");
> +
> + pb->enabled = true;
> +}
> +
> +static void pwm_backlight_disable(struct backlight_device *bl)
> +{
> + struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
> +
> + /* Bail if we are already disabled. */
> + if (!pb->enabled)
> + return;
> +
> + if (regulator_disable(pb->enable_supply) != 0)
> + dev_warn(&bl->dev, "Failed to disable regulator");
> +
> + pwm_disable(pb->pwm);
> +
> + pb->enabled = false;
> +}
Would it not be better to have some locking here since the code started to use
flag for state tracking?
> +
> static int pwm_backlight_update_status(struct backlight_device *bl)
> {
> struct pwm_bl_data *pb = bl_get_data(bl);
> @@ -51,7 +86,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
>
> if (brightness == 0) {
> pwm_config(pb->pwm, 0, pb->period);
> - pwm_disable(pb->pwm);
> + pwm_backlight_disable(bl);
> } else {
> int duty_cycle;
>
> @@ -65,7 +100,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
> duty_cycle = pb->lth_brightness +
> (duty_cycle * (pb->period - pb->lth_brightness) / max);
> pwm_config(pb->pwm, duty_cycle, pb->period);
> - pwm_enable(pb->pwm);
> + pwm_backlight_enable(bl);
> }
>
> if (pb->notify_after)
> @@ -138,12 +173,6 @@ static int pwm_backlight_parse_dt(struct device *dev,
> data->max_brightness--;
> }
>
> - /*
> - * TODO: Most users of this driver use a number of GPIOs to control
> - * backlight power. Support for specifying these needs to be
> - * added.
> - */
> -
> return 0;
> }
>
> @@ -206,6 +235,12 @@ static int pwm_backlight_probe(struct platform_device *pdev)
> pb->exit = data->exit;
> pb->dev = &pdev->dev;
>
> + pb->enable_supply = devm_regulator_get(&pdev->dev, "enable");
> + if (IS_ERR(pb->enable_supply)) {
> + ret = PTR_ERR(pb->enable_supply);
> + goto err_alloc;
> + }
> +
> pb->pwm = devm_pwm_get(&pdev->dev, NULL);
> if (IS_ERR(pb->pwm)) {
> dev_err(&pdev->dev, "unable to request PWM, trying legacy API\n");
> @@ -268,7 +303,7 @@ static int pwm_backlight_remove(struct platform_device *pdev)
>
> backlight_device_unregister(bl);
> pwm_config(pb->pwm, 0, pb->period);
> - pwm_disable(pb->pwm);
> + pwm_backlight_disable(bl);
> if (pb->exit)
> pb->exit(&pdev->dev);
> return 0;
> @@ -283,7 +318,7 @@ static int pwm_backlight_suspend(struct device *dev)
> if (pb->notify)
> pb->notify(pb->dev, 0);
> pwm_config(pb->pwm, 0, pb->period);
> - pwm_disable(pb->pwm);
> + pwm_backlight_disable(bl);
> if (pb->notify_after)
> pb->notify_after(pb->dev, 0);
> return 0;
>
--
Péter
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator
2013-03-13 8:56 ` Peter Ujfalusi
@ 2013-03-13 10:13 ` Thierry Reding
2013-03-13 21:10 ` Andrew Chew
1 sibling, 0 replies; 12+ messages in thread
From: Thierry Reding @ 2013-03-13 10:13 UTC (permalink / raw)
To: Peter Ujfalusi; +Cc: Andrew Chew, acourbot, linux-omap
[-- Attachment #1: Type: text/plain, Size: 962 bytes --]
On Wed, Mar 13, 2013 at 09:56:57AM +0100, Peter Ujfalusi wrote:
> On 03/12/2013 11:22 PM, Andrew Chew wrote:
[...]
> > +static void pwm_backlight_disable(struct backlight_device *bl)
> > +{
> > + struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
> > +
> > + /* Bail if we are already disabled. */
> > + if (!pb->enabled)
> > + return;
> > +
> > + if (regulator_disable(pb->enable_supply) != 0)
> > + dev_warn(&bl->dev, "Failed to disable regulator");
> > +
> > + pwm_disable(pb->pwm);
> > +
> > + pb->enabled = false;
> > +}
>
> Would it not be better to have some locking here since the code started to use
> flag for state tracking?
I don't think that's necessary. The backlight core already uses the
ops_lock mutex to serial accesses. I just noticed that the documentation
mentions that update_lock is used for this purpose, but the code doesn't
use it after it is initialized. Still, the ops_lock should be enough.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight
2013-03-13 8:51 ` Peter Ujfalusi
@ 2013-03-13 20:38 ` Andrew Chew
2013-03-13 20:59 ` Thierry Reding
0 siblings, 1 reply; 12+ messages in thread
From: Andrew Chew @ 2013-03-13 20:38 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: thierry.reding@avionic-design.de, Alex Courbot,
linux-omap@vger.kernel.org
> > +/* Dummy regulator for pwm-backlight driver */ static struct
> > +regulator_consumer_supply backlight_supply =
> > + REGULATOR_SUPPLY("enable", NULL);
>
> 'enable' is just too generic, the device name should be also provided:
> REGULATOR_SUPPLY("enable", "pwm-backlight");
You're right. I don't like how generic it is as well. But I don't think
"pwm-backlight" works...at least, not for me when I test it. What
does work is "backlight.x" where x is some number (for me, it's 1).
Problem is, I don't know what it would be for you. If only there
was a way to wildcard that...
Would it be better if we called the regulator something other than
"enable"? Maybe "backlight-enable", or "bl-enable" for brevity?
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight
2013-03-13 20:38 ` Andrew Chew
@ 2013-03-13 20:59 ` Thierry Reding
2013-03-13 21:12 ` Andrew Chew
0 siblings, 1 reply; 12+ messages in thread
From: Thierry Reding @ 2013-03-13 20:59 UTC (permalink / raw)
To: Andrew Chew; +Cc: Peter Ujfalusi, Alex Courbot, linux-omap@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 1301 bytes --]
On Wed, Mar 13, 2013 at 01:38:31PM -0700, Andrew Chew wrote:
> > > +/* Dummy regulator for pwm-backlight driver */ static struct
> > > +regulator_consumer_supply backlight_supply =
> > > + REGULATOR_SUPPLY("enable", NULL);
> >
> > 'enable' is just too generic, the device name should be also provided:
> > REGULATOR_SUPPLY("enable", "pwm-backlight");
>
> You're right. I don't like how generic it is as well. But I don't think
> "pwm-backlight" works...at least, not for me when I test it. What
> does work is "backlight.x" where x is some number (for me, it's 1).
> Problem is, I don't know what it would be for you. If only there
> was a way to wildcard that...
>
> Would it be better if we called the regulator something other than
> "enable"? Maybe "backlight-enable", or "bl-enable" for brevity?
The second parameter needs to match the device name. For the 4430sdp
board this should be "pwm-backlight" since the name will be generated
from the .name and .id fields of the struct platform_device. .id = -1
will result in no .<id> suffix being attached, so the device should be
named "pwm-backlight". The first parameter needs to match the name of
the supply that the driver requests, so "enable" is correct since the
call to regulator_get() uses that.
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator
2013-03-13 8:56 ` Peter Ujfalusi
2013-03-13 10:13 ` Thierry Reding
@ 2013-03-13 21:10 ` Andrew Chew
2013-03-13 21:36 ` Thierry Reding
1 sibling, 1 reply; 12+ messages in thread
From: Andrew Chew @ 2013-03-13 21:10 UTC (permalink / raw)
To: Peter Ujfalusi
Cc: thierry.reding@avionic-design.de, Alex Courbot,
linux-omap@vger.kernel.org
> > +static void pwm_backlight_enable(struct backlight_device *bl) {
> > + struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
> > +
> > + /* Bail if we are already enabled. */
> > + if (pb->enabled)
> > + return;
> > +
> > + pwm_enable(pb->pwm);
> > +
> > + if (regulator_enable(pb->enable_supply) != 0)
>
> I would loose the '!= 0'
I think I prefer the '!= 0'. Without it, it looks at first glance
like regulator_enable() is following boolean semantics,
so it reads kind of weird. But I'll defer to Thierry on this
one. Thierry, what's your preference?
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight
2013-03-13 20:59 ` Thierry Reding
@ 2013-03-13 21:12 ` Andrew Chew
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Chew @ 2013-03-13 21:12 UTC (permalink / raw)
To: Thierry Reding; +Cc: Peter Ujfalusi, Alex Courbot, linux-omap@vger.kernel.org
> From: Thierry Reding [mailto:thierry.reding@avionic-design.de]
> Sent: Wednesday, March 13, 2013 1:59 PM
> To: Andrew Chew
> Cc: Peter Ujfalusi; Alex Courbot; linux-omap@vger.kernel.org
> Subject: Re: [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator
> to pwm-backlight
>
> * PGP Signed by an unknown key
>
> On Wed, Mar 13, 2013 at 01:38:31PM -0700, Andrew Chew wrote:
> > > > +/* Dummy regulator for pwm-backlight driver */ static struct
> > > > +regulator_consumer_supply backlight_supply =
> > > > + REGULATOR_SUPPLY("enable", NULL);
> > >
> > > 'enable' is just too generic, the device name should be also provided:
> > > REGULATOR_SUPPLY("enable", "pwm-backlight");
> >
> > You're right. I don't like how generic it is as well. But I don't
> > think "pwm-backlight" works...at least, not for me when I test it.
> > What does work is "backlight.x" where x is some number (for me, it's 1).
> > Problem is, I don't know what it would be for you. If only there was
> > a way to wildcard that...
> >
> > Would it be better if we called the regulator something other than
> > "enable"? Maybe "backlight-enable", or "bl-enable" for brevity?
>
> The second parameter needs to match the device name. For the 4430sdp
> board this should be "pwm-backlight" since the name will be generated from
> the .name and .id fields of the struct platform_device. .id = -1 will result in no
> .<id> suffix being attached, so the device should be named "pwm-backlight".
> The first parameter needs to match the name of the supply that the driver
> requests, so "enable" is correct since the call to regulator_get() uses that.
Ah, I see. That makes sense. Thanks, Thierry! "pwm-backlight" it is, then,
and I'll make sure to check for this for the other boards.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator
2013-03-13 21:10 ` Andrew Chew
@ 2013-03-13 21:36 ` Thierry Reding
2013-03-13 21:39 ` Andrew Chew
0 siblings, 1 reply; 12+ messages in thread
From: Thierry Reding @ 2013-03-13 21:36 UTC (permalink / raw)
To: Andrew Chew; +Cc: Peter Ujfalusi, Alex Courbot, linux-omap@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 894 bytes --]
On Wed, Mar 13, 2013 at 02:10:16PM -0700, Andrew Chew wrote:
> > > +static void pwm_backlight_enable(struct backlight_device *bl) {
> > > + struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
> > > +
> > > + /* Bail if we are already enabled. */
> > > + if (pb->enabled)
> > > + return;
> > > +
> > > + pwm_enable(pb->pwm);
> > > +
> > > + if (regulator_enable(pb->enable_supply) != 0)
> >
> > I would loose the '!= 0'
>
> I think I prefer the '!= 0'. Without it, it looks at first glance
> like regulator_enable() is following boolean semantics,
> so it reads kind of weird. But I'll defer to Thierry on this
> one. Thierry, what's your preference?
Why not assign the return value of regulator_enable() to a variable, for
instance "err", and make that part of the warning message so that people
will have a better chance to diagnose what's going wrong?
Thierry
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator
2013-03-13 21:36 ` Thierry Reding
@ 2013-03-13 21:39 ` Andrew Chew
0 siblings, 0 replies; 12+ messages in thread
From: Andrew Chew @ 2013-03-13 21:39 UTC (permalink / raw)
To: Thierry Reding; +Cc: Peter Ujfalusi, Alex Courbot, linux-omap@vger.kernel.org
> On Wed, Mar 13, 2013 at 02:10:16PM -0700, Andrew Chew wrote:
> > > > +static void pwm_backlight_enable(struct backlight_device *bl) {
> > > > + struct pwm_bl_data *pb = dev_get_drvdata(&bl->dev);
> > > > +
> > > > + /* Bail if we are already enabled. */
> > > > + if (pb->enabled)
> > > > + return;
> > > > +
> > > > + pwm_enable(pb->pwm);
> > > > +
> > > > + if (regulator_enable(pb->enable_supply) != 0)
> > >
> > > I would loose the '!= 0'
> >
> > I think I prefer the '!= 0'. Without it, it looks at first glance
> > like regulator_enable() is following boolean semantics, so it reads
> > kind of weird. But I'll defer to Thierry on this one. Thierry,
> > what's your preference?
>
> Why not assign the return value of regulator_enable() to a variable, for
> instance "err", and make that part of the warning message so that people will
> have a better chance to diagnose what's going wrong?
That's a good idea. I'll have that modification in the next patch series that I
post.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2013-03-13 21:39 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-12 22:22 [PATCH 0/2 v2] Add mandatory regulator for all users of pwm-backlight Andrew Chew
2013-03-12 22:22 ` [PATCH 1/2 v2] ARM: OMAP: board-4430sdp: Provide regulator to pwm-backlight Andrew Chew
2013-03-13 8:51 ` Peter Ujfalusi
2013-03-13 20:38 ` Andrew Chew
2013-03-13 20:59 ` Thierry Reding
2013-03-13 21:12 ` Andrew Chew
2013-03-12 22:22 ` [PATCH 2/2 v2] pwm_bl: Add mandatory backlight enable regulator Andrew Chew
2013-03-13 8:56 ` Peter Ujfalusi
2013-03-13 10:13 ` Thierry Reding
2013-03-13 21:10 ` Andrew Chew
2013-03-13 21:36 ` Thierry Reding
2013-03-13 21:39 ` Andrew Chew
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).