diff mbox series

[2/3] backlight: pwm_bl: Artificially add 0% during interpolation

Message ID 20200720212502.2.Iab4d2192e4cf50226e0a58d58df7d90ef92713ce@changeid
State Not Applicable
Headers show
Series PWM backlight interpolation adjustments | expand

Commit Message

Alexandru Stan July 21, 2020, 4:25 a.m. UTC
Some displays need the low end of the curve cropped in order to make
them happy. In that case we still want to have the 0% point, even though
anything between 0% and 5%(example) would be skipped.

Signed-off-by: Alexandru Stan <amstan@chromium.org>
---

 drivers/video/backlight/pwm_bl.c | 8 ++++++++
 1 file changed, 8 insertions(+)

Comments

Daniel Vetter Aug. 7, 2020, 8:21 a.m. UTC | #1
On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> Some displays need the low end of the curve cropped in order to make
> them happy. In that case we still want to have the 0% point, even though
> anything between 0% and 5%(example) would be skipped.
> 
> Signed-off-by: Alexandru Stan <amstan@chromium.org>
> ---
> 
>  drivers/video/backlight/pwm_bl.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 5193a72305a2..b24711ddf504 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev,
>  			/* Fill in the last point, since no line starts here. */
>  			table[x2] = y2;
>  
> +			/*
> +			 * If we don't start at 0 yet we're increasing, assume
> +			 * the dts wanted to crop the low end of the range, so
> +			 * insert a 0 to provide a display off mode.
> +			 */
> +			if (table[0] > 0 && table[0] < table[num_levels - 1])
> +				table[0] = 0;

Isn't that what the enable/disable switch in backlights are for? There's
lots of backligh drivers (mostly the firmware variety) where setting the
backlight to 0 does not shut it off, it's just the lowest setting.

But I've not been involved in the details of these discussions.
-Daniel

> +
>  			/*
>  			 * As we use interpolation lets remove current
>  			 * brightness levels table and replace for the
> -- 
> 2.27.0
> 
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Daniel Thompson Aug. 13, 2020, 1:45 p.m. UTC | #2
On Fri, Aug 07, 2020 at 10:21:13AM +0200, daniel@ffwll.ch wrote:
> On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> > Some displays need the low end of the curve cropped in order to make
> > them happy. In that case we still want to have the 0% point, even though
> > anything between 0% and 5%(example) would be skipped.
> > 
> > Signed-off-by: Alexandru Stan <amstan@chromium.org>
> > ---
> > 
> >  drivers/video/backlight/pwm_bl.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > index 5193a72305a2..b24711ddf504 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev,
> >  			/* Fill in the last point, since no line starts here. */
> >  			table[x2] = y2;
> >  
> > +			/*
> > +			 * If we don't start at 0 yet we're increasing, assume
> > +			 * the dts wanted to crop the low end of the range, so
> > +			 * insert a 0 to provide a display off mode.
> > +			 */
> > +			if (table[0] > 0 && table[0] < table[num_levels - 1])
> > +				table[0] = 0;
> 
> Isn't that what the enable/disable switch in backlights are for? There's
> lots of backligh drivers (mostly the firmware variety) where setting the
> backlight to 0 does not shut it off, it's just the lowest setting.
> 
> But I've not been involved in the details of these discussions.

It's been a long standing complaint that the backlight drivers are not
consistent w.r.t. whether 0 means off or lowest. The most commonly used
backlights (ACPI in particular) do not adopt 0 means off but lots of
specific drivers do.

IMHO what is "right" depends on the display technology. For displays
that are essentially black when the backlight is off and become
difficult or impossible to read I'm a little dubious about standardizing
on zero means off. There are situations when zero means off
does make sense however. For example front-lit or transflexive displays
are readable when the "backlight" is off and on these displays it would
make sense.


Daniel.
Daniel Thompson Sept. 4, 2020, 11:38 a.m. UTC | #3
On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> Some displays need the low end of the curve cropped in order to make
> them happy. In that case we still want to have the 0% point, even though
> anything between 0% and 5%(example) would be skipped.

For backlights it is not defined that 0 means off and, to be honest, 0
means off is actually rather weird for anything except transflexive
or front lit reflective displays[1]. There is a problem on several
systems that when the backlight slider is reduced to zero you can't
see the screen properly to turn it back up. This patch looks like it
would make that problem worse by hurting systems with will written
device trees.

There is some nasty legacy here: some backlight displays that are off
at zero and that sucks because userspace doesn't know whether zero is
off or lowest possible setting.

Nevertheless perhaps a better way to handle this case is for 0 to map to
5% power and for the userspace to turn the backlight on/off as final
step in an animated backlight fade out (and one again for a fade in).


Daniel.

> 
> Signed-off-by: Alexandru Stan <amstan@chromium.org>
> ---
> 
>  drivers/video/backlight/pwm_bl.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index 5193a72305a2..b24711ddf504 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev,
>  			/* Fill in the last point, since no line starts here. */
>  			table[x2] = y2;
>  
> +			/*
> +			 * If we don't start at 0 yet we're increasing, assume
> +			 * the dts wanted to crop the low end of the range, so
> +			 * insert a 0 to provide a display off mode.
> +			 */
> +			if (table[0] > 0 && table[0] < table[num_levels - 1])
> +				table[0] = 0;
> +
>  			/*
>  			 * As we use interpolation lets remove current
>  			 * brightness levels table and replace for the
> -- 
> 2.27.0
Daniel Vetter Sept. 7, 2020, 7:50 a.m. UTC | #4
On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote:
> On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> > Some displays need the low end of the curve cropped in order to make
> > them happy. In that case we still want to have the 0% point, even though
> > anything between 0% and 5%(example) would be skipped.
> 
> For backlights it is not defined that 0 means off and, to be honest, 0
> means off is actually rather weird for anything except transflexive
> or front lit reflective displays[1]. There is a problem on several
> systems that when the backlight slider is reduced to zero you can't
> see the screen properly to turn it back up. This patch looks like it
> would make that problem worse by hurting systems with will written
> device trees.
> 
> There is some nasty legacy here: some backlight displays that are off
> at zero and that sucks because userspace doesn't know whether zero is
> off or lowest possible setting.
> 
> Nevertheless perhaps a better way to handle this case is for 0 to map to
> 5% power and for the userspace to turn the backlight on/off as final
> step in an animated backlight fade out (and one again for a fade in).

Afaik chromeos encodes "0 means off" somewhere in there stack. We've
gotten similar patches for the i915 backlight driver when we started
obeying the panel's lower limit in our pwm backlight driver thing that's
sometimes used instead of acpi.

There's also the problem that with fancy panels with protocol (dsi, edp,
...) shutting of the backlight completely out of the proper power sequence
hangs the panel (for some panels at least), so providing a backlight off
that doesn't go through the drm modeset sequence isn't always possible.

It's a bit a mess indeed :-/
-Daniel

> 
> 
> Daniel.
> 
> > 
> > Signed-off-by: Alexandru Stan <amstan@chromium.org>
> > ---
> > 
> >  drivers/video/backlight/pwm_bl.c | 8 ++++++++
> >  1 file changed, 8 insertions(+)
> > 
> > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > index 5193a72305a2..b24711ddf504 100644
> > --- a/drivers/video/backlight/pwm_bl.c
> > +++ b/drivers/video/backlight/pwm_bl.c
> > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev,
> >  			/* Fill in the last point, since no line starts here. */
> >  			table[x2] = y2;
> >  
> > +			/*
> > +			 * If we don't start at 0 yet we're increasing, assume
> > +			 * the dts wanted to crop the low end of the range, so
> > +			 * insert a 0 to provide a display off mode.
> > +			 */
> > +			if (table[0] > 0 && table[0] < table[num_levels - 1])
> > +				table[0] = 0;
> > +
> >  			/*
> >  			 * As we use interpolation lets remove current
> >  			 * brightness levels table and replace for the
> > -- 
> > 2.27.0
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Daniel Thompson Sept. 9, 2020, 2:45 p.m. UTC | #5
On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote:
> On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote:
> > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> > > Some displays need the low end of the curve cropped in order to make
> > > them happy. In that case we still want to have the 0% point, even though
> > > anything between 0% and 5%(example) would be skipped.
> > 
> > For backlights it is not defined that 0 means off and, to be honest, 0
> > means off is actually rather weird for anything except transflexive
> > or front lit reflective displays[1]. There is a problem on several
> > systems that when the backlight slider is reduced to zero you can't
> > see the screen properly to turn it back up. This patch looks like it
> > would make that problem worse by hurting systems with will written
> > device trees.
> > 
> > There is some nasty legacy here: some backlight displays that are off
> > at zero and that sucks because userspace doesn't know whether zero is
> > off or lowest possible setting.
> > 
> > Nevertheless perhaps a better way to handle this case is for 0 to map to
> > 5% power and for the userspace to turn the backlight on/off as final
> > step in an animated backlight fade out (and one again for a fade in).
> 
> Afaik chromeos encodes "0 means off" somewhere in there stack. We've
> gotten similar patches for the i915 backlight driver when we started
> obeying the panel's lower limit in our pwm backlight driver thing that's
> sometimes used instead of acpi.

Out of interest... were they accepted?

I did took a quick look at intel_panel.c and didn't see anything
that appeared to be special casing zero but I thought I might double
check.


Daniel.


> There's also the problem that with fancy panels with protocol (dsi, edp,
> ...) shutting of the backlight completely out of the proper power sequence
> hangs the panel (for some panels at least), so providing a backlight off
> that doesn't go through the drm modeset sequence isn't always possible.
> 
> It's a bit a mess indeed :-/
> -Daniel
> 
> > 
> > 
> > Daniel.
> > 
> > > 
> > > Signed-off-by: Alexandru Stan <amstan@chromium.org>
> > > ---
> > > 
> > >  drivers/video/backlight/pwm_bl.c | 8 ++++++++
> > >  1 file changed, 8 insertions(+)
> > > 
> > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > index 5193a72305a2..b24711ddf504 100644
> > > --- a/drivers/video/backlight/pwm_bl.c
> > > +++ b/drivers/video/backlight/pwm_bl.c
> > > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev,
> > >  			/* Fill in the last point, since no line starts here. */
> > >  			table[x2] = y2;
> > >  
> > > +			/*
> > > +			 * If we don't start at 0 yet we're increasing, assume
> > > +			 * the dts wanted to crop the low end of the range, so
> > > +			 * insert a 0 to provide a display off mode.
> > > +			 */
> > > +			if (table[0] > 0 && table[0] < table[num_levels - 1])
> > > +				table[0] = 0;
> > > +
> > >  			/*
> > >  			 * As we use interpolation lets remove current
> > >  			 * brightness levels table and replace for the
> > > -- 
> > > 2.27.0
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
Daniel Vetter Sept. 9, 2020, 3:03 p.m. UTC | #6
On Wed, Sep 9, 2020 at 4:45 PM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote:
> > On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote:
> > > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> > > > Some displays need the low end of the curve cropped in order to make
> > > > them happy. In that case we still want to have the 0% point, even though
> > > > anything between 0% and 5%(example) would be skipped.
> > >
> > > For backlights it is not defined that 0 means off and, to be honest, 0
> > > means off is actually rather weird for anything except transflexive
> > > or front lit reflective displays[1]. There is a problem on several
> > > systems that when the backlight slider is reduced to zero you can't
> > > see the screen properly to turn it back up. This patch looks like it
> > > would make that problem worse by hurting systems with will written
> > > device trees.
> > >
> > > There is some nasty legacy here: some backlight displays that are off
> > > at zero and that sucks because userspace doesn't know whether zero is
> > > off or lowest possible setting.
> > >
> > > Nevertheless perhaps a better way to handle this case is for 0 to map to
> > > 5% power and for the userspace to turn the backlight on/off as final
> > > step in an animated backlight fade out (and one again for a fade in).
> >
> > Afaik chromeos encodes "0 means off" somewhere in there stack. We've
> > gotten similar patches for the i915 backlight driver when we started
> > obeying the panel's lower limit in our pwm backlight driver thing that's
> > sometimes used instead of acpi.
>
> Out of interest... were they accepted?
>
> I did took a quick look at intel_panel.c and didn't see anything
> that appeared to be special casing zero but I thought I might double
> check.

I don't think so. Just figured I bring this up since it might explain
why this is coming back again from an @chromium.com address.
-Daniel

>
>
> Daniel.
>
>
> > There's also the problem that with fancy panels with protocol (dsi, edp,
> > ...) shutting of the backlight completely out of the proper power sequence
> > hangs the panel (for some panels at least), so providing a backlight off
> > that doesn't go through the drm modeset sequence isn't always possible.
> >
> > It's a bit a mess indeed :-/
> > -Daniel
> >
> > >
> > >
> > > Daniel.
> > >
> > > >
> > > > Signed-off-by: Alexandru Stan <amstan@chromium.org>
> > > > ---
> > > >
> > > >  drivers/video/backlight/pwm_bl.c | 8 ++++++++
> > > >  1 file changed, 8 insertions(+)
> > > >
> > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > > index 5193a72305a2..b24711ddf504 100644
> > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev,
> > > >                   /* Fill in the last point, since no line starts here. */
> > > >                   table[x2] = y2;
> > > >
> > > > +                 /*
> > > > +                  * If we don't start at 0 yet we're increasing, assume
> > > > +                  * the dts wanted to crop the low end of the range, so
> > > > +                  * insert a 0 to provide a display off mode.
> > > > +                  */
> > > > +                 if (table[0] > 0 && table[0] < table[num_levels - 1])
> > > > +                         table[0] = 0;
> > > > +
> > > >                   /*
> > > >                    * As we use interpolation lets remove current
> > > >                    * brightness levels table and replace for the
> > > > --
> > > > 2.27.0
> > > _______________________________________________
> > > dri-devel mailing list
> > > dri-devel@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> >
> > --
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Alexandru Stan Sept. 9, 2020, 6:42 p.m. UTC | #7
On Fri, Sep 4, 2020 at 4:38 AM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> > Some displays need the low end of the curve cropped in order to make
> > them happy. In that case we still want to have the 0% point, even though
> > anything between 0% and 5%(example) would be skipped.
>
> For backlights it is not defined that 0 means off and, to be honest, 0
> means off is actually rather weird for anything except transflexive
> or front lit reflective displays[1]. There is a problem on several
> systems that when the backlight slider is reduced to zero you can't
> see the screen properly to turn it back up. This patch looks like it
> would make that problem worse by hurting systems with will written
> device trees.
>
> There is some nasty legacy here: some backlight displays that are off
> at zero and that sucks because userspace doesn't know whether zero is
> off or lowest possible setting.
>
> Nevertheless perhaps a better way to handle this case is for 0 to map to
> 5% power and for the userspace to turn the backlight on/off as final
> step in an animated backlight fade out (and one again for a fade in).

Hello

Apologies for my delay. Thanks for the responses!

Yeah, I felt pretty sketchy about this 0% patch as well. But I figured
it's better to send my suggestion and get corrected than lose the
fixed interpolation patch.

Turns out there's no reason to need 2/3. I was mistaken:
echo "4" > /sys/devices/platform/backlight/backlight/backlight/bl_power
seems to work just fine to turn the backlight off, nothing special
about my device (pwm comes from cros_ec).
Chrome OS user space already makes full use of that knob
(https://source.chromium.org/chromiumos/chromiumos/codesearch/+/master:src/platform2/power_manager/powerd/system/internal_backlight.cc;l=169)
I wanted to try X11 on the same device but I haven't gotten to it yet,
perhaps I'll post my results in the next cover letter.
So it seems I didn't have to worry about "not breaking userspace" on
the existing devices.

I'll respin this patch set: keep 1/3 and 3/3, remove 2/3, and
potentially add another one to update trogdor's dtsi (since that's
where I want this fixed linear interpolation to happen).

Thank you,
Alexandru Stan
Daniel Vetter Sept. 10, 2020, 7:47 a.m. UTC | #8
On Wed, Sep 09, 2020 at 05:03:37PM +0200, Daniel Vetter wrote:
> On Wed, Sep 9, 2020 at 4:45 PM Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> >
> > On Mon, Sep 07, 2020 at 09:50:18AM +0200, Daniel Vetter wrote:
> > > On Fri, Sep 04, 2020 at 12:38:22PM +0100, Daniel Thompson wrote:
> > > > On Mon, Jul 20, 2020 at 09:25:21PM -0700, Alexandru Stan wrote:
> > > > > Some displays need the low end of the curve cropped in order to make
> > > > > them happy. In that case we still want to have the 0% point, even though
> > > > > anything between 0% and 5%(example) would be skipped.
> > > >
> > > > For backlights it is not defined that 0 means off and, to be honest, 0
> > > > means off is actually rather weird for anything except transflexive
> > > > or front lit reflective displays[1]. There is a problem on several
> > > > systems that when the backlight slider is reduced to zero you can't
> > > > see the screen properly to turn it back up. This patch looks like it
> > > > would make that problem worse by hurting systems with will written
> > > > device trees.
> > > >
> > > > There is some nasty legacy here: some backlight displays that are off
> > > > at zero and that sucks because userspace doesn't know whether zero is
> > > > off or lowest possible setting.
> > > >
> > > > Nevertheless perhaps a better way to handle this case is for 0 to map to
> > > > 5% power and for the userspace to turn the backlight on/off as final
> > > > step in an animated backlight fade out (and one again for a fade in).
> > >
> > > Afaik chromeos encodes "0 means off" somewhere in there stack. We've
> > > gotten similar patches for the i915 backlight driver when we started
> > > obeying the panel's lower limit in our pwm backlight driver thing that's
> > > sometimes used instead of acpi.
> >
> > Out of interest... were they accepted?
> >
> > I did took a quick look at intel_panel.c and didn't see anything
> > that appeared to be special casing zero but I thought I might double
> > check.
> 
> I don't think so. Just figured I bring this up since it might explain
> why this is coming back again from an @chromium.com address.

Thanks to Alexandru pointing at the right code it's clear this got fix,
over 5 years ago:

https://source.chromium.org/chromiumos/_/chromium/chromiumos/platform2/+/6e83a6a8bb772ed8a2f939da1c7a152147c12789

	power: Write to bl_power when backlight reaches or leaves 0.
	
	Make InternalBacklight write FB_BLANK_UNBLANK to bl_power
	just before setting the internal backlight brightness to a
	nonzero value, and FB_BLANK_POWERDOWN to bl_power just
	before setting the brightness to 0.
	
	This is needed for hardware that interprets a brightness
	level of 0 as meaning "dim" rather than "off".
	
	BUG=chromium:396218
	TEST=added unit tests
	
	Change-Id: I914e333ab41db623564d5a67beac89f1a62bce9d
	Reviewed-on: https://chromium-review.googlesource.com/311010
	Commit-Ready: Dan Erat <derat@chromium.org>
	Tested-by: Dan Erat <derat@chromium.org>
	Reviewed-by: Dan Erat <derat@chromium.org>

Cheers, Daniel

> > > There's also the problem that with fancy panels with protocol (dsi, edp,
> > > ...) shutting of the backlight completely out of the proper power sequence
> > > hangs the panel (for some panels at least), so providing a backlight off
> > > that doesn't go through the drm modeset sequence isn't always possible.
> > >
> > > It's a bit a mess indeed :-/
> > > -Daniel
> > >
> > > >
> > > >
> > > > Daniel.
> > > >
> > > > >
> > > > > Signed-off-by: Alexandru Stan <amstan@chromium.org>
> > > > > ---
> > > > >
> > > > >  drivers/video/backlight/pwm_bl.c | 8 ++++++++
> > > > >  1 file changed, 8 insertions(+)
> > > > >
> > > > > diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> > > > > index 5193a72305a2..b24711ddf504 100644
> > > > > --- a/drivers/video/backlight/pwm_bl.c
> > > > > +++ b/drivers/video/backlight/pwm_bl.c
> > > > > @@ -349,6 +349,14 @@ static int pwm_backlight_parse_dt(struct device *dev,
> > > > >                   /* Fill in the last point, since no line starts here. */
> > > > >                   table[x2] = y2;
> > > > >
> > > > > +                 /*
> > > > > +                  * If we don't start at 0 yet we're increasing, assume
> > > > > +                  * the dts wanted to crop the low end of the range, so
> > > > > +                  * insert a 0 to provide a display off mode.
> > > > > +                  */
> > > > > +                 if (table[0] > 0 && table[0] < table[num_levels - 1])
> > > > > +                         table[0] = 0;
> > > > > +
> > > > >                   /*
> > > > >                    * As we use interpolation lets remove current
> > > > >                    * brightness levels table and replace for the
> > > > > --
> > > > > 2.27.0
> > > > _______________________________________________
> > > > dri-devel mailing list
> > > > dri-devel@lists.freedesktop.org
> > > > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> > >
> > > --
> > > Daniel Vetter
> > > Software Engineer, Intel Corporation
> > > http://blog.ffwll.ch
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 
> 
> 
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
diff mbox series

Patch

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 5193a72305a2..b24711ddf504 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -349,6 +349,14 @@  static int pwm_backlight_parse_dt(struct device *dev,
 			/* Fill in the last point, since no line starts here. */
 			table[x2] = y2;
 
+			/*
+			 * If we don't start at 0 yet we're increasing, assume
+			 * the dts wanted to crop the low end of the range, so
+			 * insert a 0 to provide a display off mode.
+			 */
+			if (table[0] > 0 && table[0] < table[num_levels - 1])
+				table[0] = 0;
+
 			/*
 			 * As we use interpolation lets remove current
 			 * brightness levels table and replace for the