All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lee Jones <lee.jones@linaro.org>
To: "Lothar Waßmann" <LW@KARO-electronics.de>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pwm@vger.kernel.org,
	Marcel Ziswiler <marcel.ziswiler@toradex.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Pawel Moll <pawel.moll@arm.com>, Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCHv2] backlight: pwm_bl: disable PWM when 'duty_cycle' is zero
Date: Fri, 10 Jun 2016 15:54:49 +0100	[thread overview]
Message-ID: <20160610145449.GA7351@dell> (raw)
In-Reply-To: <20160610123453.3a8ee14e@ipc1.ka-ro>

On Fri, 10 Jun 2016, Lothar Waßmann wrote:
> On Fri, 10 Jun 2016 08:44:49 +0100 Lee Jones wrote:
> > On Fri, 10 Jun 2016, Lothar Waßmann wrote:
> > 
> > > Hi,
> > > 
> > > On Thu, 9 Jun 2016 14:51:25 +0100 Lee Jones wrote:
> > > > On Tue, 07 Jun 2016, Lothar Waßmann wrote:
> > > > 
> > > > > 'brightness' is usually an index into a table of duty_cycle values,
> > > > > where the value at index 0 may well be non-zero
> > > > > (tegra30-apalis-eval.dts and tegra30-colibri-eval-v3.dts are real-life
> > > > > examples).
> > > > > Thus brightness == 0 does not necessarily mean that the PWM output
> > > > > will be inactive.
> > > > > Check for 'duty_cycle == 0' rather than 'brightness == 0' to decide
> > > > > whether to disable the PWM.
> > > > > 
> > > > > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> > > > > ---
> > > > > Changes wrt. v1:
> > > > >   - update binding docs to reflect the change
> > > > > 
> > > > >  .../devicetree/bindings/leds/backlight/pwm-backlight.txt         | 9 ++++++---
> > > > >  drivers/video/backlight/pwm_bl.c                                 | 4 ++--
> > > > >  2 files changed, 8 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > > > > index 764db86..95fa8a9 100644
> > > > > --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > > > > +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > > > > @@ -4,10 +4,13 @@ Required properties:
> > > > >    - compatible: "pwm-backlight"
> > > > >    - pwms: OF device-tree PWM specification (see PWM binding[0])
> > > > >    - brightness-levels: Array of distinct brightness levels. Typically these
> > > > > -      are in the range from 0 to 255, but any range starting at 0 will do.
> > > > > +      are in the range from 0 to 255, but any range will do.
> > > > >        The actual brightness level (PWM duty cycle) will be interpolated
> > > > > -      from these values. 0 means a 0% duty cycle (darkest/off), while the
> > > > > -      last value in the array represents a 100% duty cycle (brightest).
> > > > > +      from these values. 0 means a 0% duty cycle, while the highest value in
> > > > > +      the array represents a 100% duty cycle.
> > > > > +      The range may be in reverse order (starting with the maximum duty cycle
> > > > > +      value) to create a PWM signal with the 100% duty cycle representing
> > > > > +      minimum and 0% duty cycle maximum brigthness.
> > > > >    - default-brightness-level: the default brightness level (index into the
> > > > >        array defined by the "brightness-levels" property)
> > > > >    - power-supply: regulator for supply voltage
> > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > > > index b2b366b..80b2b52 100644
> > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > @@ -103,8 +103,8 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
> > > > >  	if (pb->notify)
> > > > >  		brightness = pb->notify(pb->dev, brightness);
> > > > >  
> > > > > -	if (brightness > 0) {
> > > > > -		duty_cycle = compute_duty_cycle(pb, brightness);
> > > > > +	duty_cycle = compute_duty_cycle(pb, brightness);
> > > > > +	if (duty_cycle > 0) {
> > > > 
> > > > How does this work in the aforementioned:
> > > > 
> > > >   "The range may be in reverse order"
> > > > 
> > > > ... case?  Surely when duty_cycle is when the screen should be at it's
> > > > brightest?  Wouldn't it confuse the user if they turn their brightness
> > > > *up* and the screen goes *off*?
> > > > 
> > > Assuming that the PWM output is inactive (LOW) when the duty_cycle is
> > > set to zero, there will be no difference between operating the PWM at
> > > duty_cycle 0 or disabling it.
> > > 
> > > Currently, the screen will go bright when it should be off in this
> > > case.
> > 
> > It sounds like we need something that lets the framework know if
> > duty_cycle = MAX is the brightest or if duty_cycle = 0 is.  Either way
> > someone is going to get screwed by this logic.
> > 
> The backlight framework does not (and does not need to) know anything
> about PWM duty cycles. Its 'brightness' values are consistently 0 ==
> dark, max == brightest in either case.

What I'm getting at is; by the look of the documentation, the
brightest setting can either be a duty cycle of 0 or 255.  So what
happens with your new semantics when the duty cycle of 0 represents
the brightest setting and you reach 0?  Didn't you just turn the
backlight off?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: "Lothar Waßmann" <LW@KARO-electronics.de>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
	Jingoo Han <jingoohan1@gmail.com>,
	Thierry Reding <thierry.reding@gmail.com>,
	Tomi Valkeinen <tomi.valkeinen@ti.com>,
	linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-pwm@vger.kernel.org,
	Marcel Ziswiler <marcel.ziswiler@toradex.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Kumar Gala <galak@codeaurora.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Pawel Moll <pawel.moll@arm.com>, Rob Herring <robh+dt@kernel.org>,
	devicetree@vger.kernel.org
Subject: Re: [PATCHv2] backlight: pwm_bl: disable PWM when 'duty_cycle' is zero
Date: Fri, 10 Jun 2016 14:54:49 +0000	[thread overview]
Message-ID: <20160610145449.GA7351@dell> (raw)
In-Reply-To: <20160610123453.3a8ee14e@ipc1.ka-ro>

On Fri, 10 Jun 2016, Lothar Waßmann wrote:
> On Fri, 10 Jun 2016 08:44:49 +0100 Lee Jones wrote:
> > On Fri, 10 Jun 2016, Lothar Waßmann wrote:
> > 
> > > Hi,
> > > 
> > > On Thu, 9 Jun 2016 14:51:25 +0100 Lee Jones wrote:
> > > > On Tue, 07 Jun 2016, Lothar Waßmann wrote:
> > > > 
> > > > > 'brightness' is usually an index into a table of duty_cycle values,
> > > > > where the value at index 0 may well be non-zero
> > > > > (tegra30-apalis-eval.dts and tegra30-colibri-eval-v3.dts are real-life
> > > > > examples).
> > > > > Thus brightness = 0 does not necessarily mean that the PWM output
> > > > > will be inactive.
> > > > > Check for 'duty_cycle = 0' rather than 'brightness = 0' to decide
> > > > > whether to disable the PWM.
> > > > > 
> > > > > Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
> > > > > ---
> > > > > Changes wrt. v1:
> > > > >   - update binding docs to reflect the change
> > > > > 
> > > > >  .../devicetree/bindings/leds/backlight/pwm-backlight.txt         | 9 ++++++---
> > > > >  drivers/video/backlight/pwm_bl.c                                 | 4 ++--
> > > > >  2 files changed, 8 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > > > > index 764db86..95fa8a9 100644
> > > > > --- a/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > > > > +++ b/Documentation/devicetree/bindings/leds/backlight/pwm-backlight.txt
> > > > > @@ -4,10 +4,13 @@ Required properties:
> > > > >    - compatible: "pwm-backlight"
> > > > >    - pwms: OF device-tree PWM specification (see PWM binding[0])
> > > > >    - brightness-levels: Array of distinct brightness levels. Typically these
> > > > > -      are in the range from 0 to 255, but any range starting at 0 will do.
> > > > > +      are in the range from 0 to 255, but any range will do.
> > > > >        The actual brightness level (PWM duty cycle) will be interpolated
> > > > > -      from these values. 0 means a 0% duty cycle (darkest/off), while the
> > > > > -      last value in the array represents a 100% duty cycle (brightest).
> > > > > +      from these values. 0 means a 0% duty cycle, while the highest value in
> > > > > +      the array represents a 100% duty cycle.
> > > > > +      The range may be in reverse order (starting with the maximum duty cycle
> > > > > +      value) to create a PWM signal with the 100% duty cycle representing
> > > > > +      minimum and 0% duty cycle maximum brigthness.
> > > > >    - default-brightness-level: the default brightness level (index into the
> > > > >        array defined by the "brightness-levels" property)
> > > > >    - power-supply: regulator for supply voltage
> > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > > > index b2b366b..80b2b52 100644
> > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > @@ -103,8 +103,8 @@ static int pwm_backlight_update_status(struct backlight_device *bl)
> > > > >  	if (pb->notify)
> > > > >  		brightness = pb->notify(pb->dev, brightness);
> > > > >  
> > > > > -	if (brightness > 0) {
> > > > > -		duty_cycle = compute_duty_cycle(pb, brightness);
> > > > > +	duty_cycle = compute_duty_cycle(pb, brightness);
> > > > > +	if (duty_cycle > 0) {
> > > > 
> > > > How does this work in the aforementioned:
> > > > 
> > > >   "The range may be in reverse order"
> > > > 
> > > > ... case?  Surely when duty_cycle is when the screen should be at it's
> > > > brightest?  Wouldn't it confuse the user if they turn their brightness
> > > > *up* and the screen goes *off*?
> > > > 
> > > Assuming that the PWM output is inactive (LOW) when the duty_cycle is
> > > set to zero, there will be no difference between operating the PWM at
> > > duty_cycle 0 or disabling it.
> > > 
> > > Currently, the screen will go bright when it should be off in this
> > > case.
> > 
> > It sounds like we need something that lets the framework know if
> > duty_cycle = MAX is the brightest or if duty_cycle = 0 is.  Either way
> > someone is going to get screwed by this logic.
> > 
> The backlight framework does not (and does not need to) know anything
> about PWM duty cycles. Its 'brightness' values are consistently 0 =
> dark, max = brightest in either case.

What I'm getting at is; by the look of the documentation, the
brightest setting can either be a duty cycle of 0 or 255.  So what
happens with your new semantics when the duty cycle of 0 represents
the brightest setting and you reach 0?  Didn't you just turn the
backlight off?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

  reply	other threads:[~2016-06-10 14:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-07 10:13 [PATCHv2] backlight: pwm_bl: disable PWM when 'duty_cycle' is zero Lothar Waßmann
2016-06-07 10:13 ` Lothar Waßmann
2016-06-08 20:06 ` Rob Herring
2016-06-08 20:06   ` Rob Herring
2016-06-09 13:51 ` Lee Jones
2016-06-09 13:51   ` Lee Jones
2016-06-10  5:23   ` Lothar Waßmann
2016-06-10  5:23     ` Lothar Waßmann
2016-06-10  7:44     ` Lee Jones
2016-06-10  7:44       ` Lee Jones
2016-06-10 10:34       ` Lothar Waßmann
2016-06-10 10:34         ` Lothar Waßmann
2016-06-10 14:54         ` Lee Jones [this message]
2016-06-10 14:54           ` Lee Jones
2016-06-11  7:08           ` Lothar Waßmann
2016-06-11  7:08             ` Lothar Waßmann
2016-06-17 14:17             ` Lee Jones
2016-06-17 14:17               ` Lee Jones
2016-06-20  6:21               ` Lothar Waßmann
2016-06-20  6:21                 ` Lothar Waßmann
2016-06-20  6:29                 ` Phil Reid
2016-06-20  6:29                   ` Phil Reid
2016-06-20  8:18                   ` Lee Jones
2016-06-20  8:18                     ` Lee Jones

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160610145449.GA7351@dell \
    --to=lee.jones@linaro.org \
    --cc=LW@KARO-electronics.de \
    --cc=devicetree@vger.kernel.org \
    --cc=galak@codeaurora.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=jingoohan1@gmail.com \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=marcel.ziswiler@toradex.com \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=plagnioj@jcrosoft.com \
    --cc=robh+dt@kernel.org \
    --cc=thierry.reding@gmail.com \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.