linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] pwm-backlight: allow for non-increasing brightness levels
@ 2013-09-12 18:35 Mike Dunn
       [not found] ` <1379010952-8928-1-git-send-email-mikedunn-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
  0 siblings, 1 reply; 5+ messages in thread
From: Mike Dunn @ 2013-09-12 18:35 UTC (permalink / raw)
  To: thierry.reding
  Cc: Mike Dunn, Richard Purdie, Jingoo Han,
	Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Grant Likely,
	Rob Herring, linux-pwm, linux-fbdev, linux-kernel, devicetree,
	Robert Jarzmik, Marek Vasut

Currently the driver assumes that the values specified in the brightness-levels
device tree property increase as they are parsed from left to right.  But boards
that invert the signal between the PWM output and the backlight will need to
specify decreasing brightness-levels.  This patch removes the assumption that
the last element of the array is the max value, and instead searches the array
for the max value and uses that as the normalizing value when determining the
duty cycle.

Signed-off-by: Mike Dunn <mikedunn@newsguy.com>
---
 drivers/video/backlight/pwm_bl.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 1fea627..d66aaa0 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -27,6 +27,7 @@ struct pwm_bl_data {
 	unsigned int		period;
 	unsigned int		lth_brightness;
 	unsigned int		*levels;
+	unsigned int		max_level;
 	int			(*notify)(struct device *,
 					  int brightness);
 	void			(*notify_after)(struct device *,
@@ -57,7 +58,7 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
 
 		if (pb->levels) {
 			duty_cycle = pb->levels[brightness];
-			max = pb->levels[max];
+			max = pb->levels[pb->max_level];
 		} else {
 			duty_cycle = brightness;
 		}
@@ -195,7 +196,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 	}
 
 	if (data->levels) {
-		max = data->levels[data->max_brightness];
+		int i, max_value = 0, max_idx = 0;
+		for (i = 0; i <= data->max_brightness; i++) {
+			if (data->levels[i] > max_value) {
+				max_value = data->levels[i];
+				max_idx = i;
+			}
+		}
+		pb->max_level = max_idx;
+		max = data->levels[max_idx];
 		pb->levels = data->levels;
 	} else
 		max = data->max_brightness;
-- 
1.8.1.5


^ permalink raw reply related	[flat|nested] 5+ messages in thread

* Re: [PATCH] pwm-backlight: allow for non-increasing brightness levels
       [not found] ` <1379010952-8928-1-git-send-email-mikedunn-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
@ 2013-09-17  9:36   ` Sascha Hauer
       [not found]     ` <20130917093622.GB30088-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
  2013-09-19 11:56   ` Thierry Reding
  1 sibling, 1 reply; 5+ messages in thread
From: Sascha Hauer @ 2013-09-17  9:36 UTC (permalink / raw)
  To: Mike Dunn
  Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, Richard Purdie, Jingoo Han,
	Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Grant Likely,
	Rob Herring, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut

Hi Mike,

On Thu, Sep 12, 2013 at 11:35:52AM -0700, Mike Dunn wrote:
> Currently the driver assumes that the values specified in the brightness-levels
> device tree property increase as they are parsed from left to right.  But boards
> that invert the signal between the PWM output and the backlight will need to
> specify decreasing brightness-levels.  This patch removes the assumption that
> the last element of the array is the max value, and instead searches the array
> for the max value and uses that as the normalizing value when determining the
> duty cycle.

Note there's also support for inverted PWMs in the PWM framework
provided your hardware supports this.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] pwm-backlight: allow for non-increasing brightness levels
       [not found]     ` <20130917093622.GB30088-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
@ 2013-09-17 14:23       ` Mike Dunn
  0 siblings, 0 replies; 5+ messages in thread
From: Mike Dunn @ 2013-09-17 14:23 UTC (permalink / raw)
  To: Sascha Hauer
  Cc: thierry.reding-Re5JQEeQqe8AvxtiuMwx3w, Richard Purdie, Jingoo Han,
	Jean-Christophe Plagniol-Villard, Tomi Valkeinen, Grant Likely,
	Rob Herring, linux-pwm-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut

On 09/17/2013 02:36 AM, Sascha Hauer wrote:
> Hi Mike,
> 
> On Thu, Sep 12, 2013 at 11:35:52AM -0700, Mike Dunn wrote:
>> Currently the driver assumes that the values specified in the brightness-levels
>> device tree property increase as they are parsed from left to right.  But boards
>> that invert the signal between the PWM output and the backlight will need to
>> specify decreasing brightness-levels.  This patch removes the assumption that
>> the last element of the array is the max value, and instead searches the array
>> for the max value and uses that as the normalizing value when determining the
>> duty cycle.
> 
> Note there's also support for inverted PWMs in the PWM framework
> provided your hardware supports this.


Yes, and in fact my first solution was to implement simulated polarity inversion
in the pwm driver, but that was shot down because polarity inversion is not
actually supported by the pwm hardware.  My inverter is external in the path
between the pwm output and the backlight.  Not sure of the reason for its presence.

Thanks,
Mike


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] pwm-backlight: allow for non-increasing brightness levels
       [not found] ` <1379010952-8928-1-git-send-email-mikedunn-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
  2013-09-17  9:36   ` Sascha Hauer
@ 2013-09-19 11:56   ` Thierry Reding
  2013-09-19 16:13     ` Mike Dunn
  1 sibling, 1 reply; 5+ messages in thread
From: Thierry Reding @ 2013-09-19 11:56 UTC (permalink / raw)
  To: Mike Dunn
  Cc: Richard Purdie, Jingoo Han, Jean-Christophe Plagniol-Villard,
	Tomi Valkeinen, Grant Likely, Rob Herring,
	linux-pwm-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut

[-- Attachment #1: Type: text/plain, Size: 2176 bytes --]

On Thu, Sep 12, 2013 at 11:35:52AM -0700, Mike Dunn wrote:
> Currently the driver assumes that the values specified in the brightness-levels
> device tree property increase as they are parsed from left to right.  But boards
> that invert the signal between the PWM output and the backlight will need to
> specify decreasing brightness-levels.  This patch removes the assumption that
> the last element of the array is the max value, and instead searches the array
> for the max value and uses that as the normalizing value when determining the
> duty cycle.

"maximum value", "... and uses that as the scale to normalize the duty
cycle"?

Also please wrap commit messages at 72 characters.

> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 1fea627..d66aaa0 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -27,6 +27,7 @@ struct pwm_bl_data {
>  	unsigned int		period;
>  	unsigned int		lth_brightness;
>  	unsigned int		*levels;
> +	unsigned int		max_level;

Perhaps call this "scale"? Otherwise there some potential to mix it up
with max_brightness.

> @@ -195,7 +196,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>  	}
>  
>  	if (data->levels) {
> -		max = data->levels[data->max_brightness];
> +		int i, max_value = 0, max_idx = 0;

i should be unsigned int to match the type of data->max_brightness.

> +		for (i = 0; i <= data->max_brightness; i++) {

There should be a blank line above this one to increase readability.

> +			if (data->levels[i] > max_value) {
> +				max_value = data->levels[i];
> +				max_idx = i;
> +			}
> +		}
> +		pb->max_level = max_idx;

Some here.

Also I suggest to just drop the max_ prefix from the local variables.
Perhaps also simplify all of it to something like:

	for (i = 0; i <= data->max_brightness; i++)
		if (data->levels[i] > pb->scale)
			pb->scale = data->levels[i];

And get rid of the index altogether. That way you can use pb->scale
directly during the computation of the duty cycle and don't have to
index the levels array over and over again.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] pwm-backlight: allow for non-increasing brightness levels
  2013-09-19 11:56   ` Thierry Reding
@ 2013-09-19 16:13     ` Mike Dunn
  0 siblings, 0 replies; 5+ messages in thread
From: Mike Dunn @ 2013-09-19 16:13 UTC (permalink / raw)
  To: Thierry Reding
  Cc: Richard Purdie, Jingoo Han, Jean-Christophe Plagniol-Villard,
	Tomi Valkeinen, Grant Likely, Rob Herring,
	linux-pwm-u79uwXL29TY76Z2rM5mHXA,
	linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	devicetree-u79uwXL29TY76Z2rM5mHXA, Robert Jarzmik, Marek Vasut

On 09/19/2013 04:56 AM, Thierry Reding wrote:
> On Thu, Sep 12, 2013 at 11:35:52AM -0700, Mike Dunn wrote:
>> Currently the driver assumes that the values specified in the brightness-levels
>> device tree property increase as they are parsed from left to right.  But boards
>> that invert the signal between the PWM output and the backlight will need to
>> specify decreasing brightness-levels.  This patch removes the assumption that
>> the last element of the array is the max value, and instead searches the array
>> for the max value and uses that as the normalizing value when determining the
>> duty cycle.
> 
> "maximum value", "... and uses that as the scale to normalize the duty
> cycle"?


It's been a while since my last math class... is "normalizing value" not the
correct term?  Maybe just "uses that in the duty cycle calculation"?


> 
> Also please wrap commit messages at 72 characters.


OK.  Sorry, didn't know.


> 
>> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
>> index 1fea627..d66aaa0 100644
>> --- a/drivers/video/backlight/pwm_bl.c
>> +++ b/drivers/video/backlight/pwm_bl.c
>> @@ -27,6 +27,7 @@ struct pwm_bl_data {
>>  	unsigned int		period;
>>  	unsigned int		lth_brightness;
>>  	unsigned int		*levels;
>> +	unsigned int		max_level;
> 
> Perhaps call this "scale"? Otherwise there some potential to mix it up
> with max_brightness.


Yes, this name is thorny.  The code was somewhat confusing to me until I
realized that for the DT case, brightness and max_brightness are indices into
the levels[] array, whereas they are actual values for the platform_data case.
I'll go with "scale" if you prefer.


> 
>> @@ -195,7 +196,15 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>>  	}
>>  
>>  	if (data->levels) {
>> -		max = data->levels[data->max_brightness];
>> +		int i, max_value = 0, max_idx = 0;
> 
> i should be unsigned int to match the type of data->max_brightness.


Yes, thanks.  I'm surprised there's no warning from the compiler.  I'm also
assigning an unsigned to a signed.


> 
>> +		for (i = 0; i <= data->max_brightness; i++) {
> 
> There should be a blank line above this one to increase readability.
> 
>> +			if (data->levels[i] > max_value) {
>> +				max_value = data->levels[i];
>> +				max_idx = i;
>> +			}
>> +		}
>> +		pb->max_level = max_idx;
> 
> Some here.
> 
> Also I suggest to just drop the max_ prefix from the local variables.
> Perhaps also simplify all of it to something like:
> 
> 	for (i = 0; i <= data->max_brightness; i++)
> 		if (data->levels[i] > pb->scale)
> 			pb->scale = data->levels[i];
> 
> And get rid of the index altogether. That way you can use pb->scale
> directly during the computation of the duty cycle and don't have to
> index the levels array over and over again.


Ok, if you prefer.  The reason I made max_level an index is for consistency.
For the DT case, brightness and max_brightness are indices, and I had already
been confused by the value-versus-index issue.

Thanks much for the review!  I'll ready a v2 patch.

Mike


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2013-09-19 16:13 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-09-12 18:35 [PATCH] pwm-backlight: allow for non-increasing brightness levels Mike Dunn
     [not found] ` <1379010952-8928-1-git-send-email-mikedunn-kFrNdAxtuftBDgjK7y7TUQ@public.gmane.org>
2013-09-17  9:36   ` Sascha Hauer
     [not found]     ` <20130917093622.GB30088-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
2013-09-17 14:23       ` Mike Dunn
2013-09-19 11:56   ` Thierry Reding
2013-09-19 16:13     ` Mike Dunn

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).