All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Måns Rullgård" <mans@mansr.com>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: Lee Jones <lee@kernel.org>, Jingoo Han <jingoohan1@gmail.com>,
	Helge Deller <deller@gmx.de>,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] backlight: led_bl: fix initial power state
Date: Tue, 04 Jul 2023 16:31:51 +0100	[thread overview]
Message-ID: <yw1xo7krzo9k.fsf@mansr.com> (raw)
In-Reply-To: <20230704150310.GA385243@aspen.lan> (Daniel Thompson's message of "Tue, 4 Jul 2023 16:03:10 +0100")

Daniel Thompson <daniel.thompson@linaro.org> writes:

> On Tue, Jul 04, 2023 at 03:07:50PM +0100, Mans Rullgard wrote:
>> The condition for the initial power state based on the default
>> brightness value is reversed.  Fix it.
>>
>> Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
>> Signed-off-by: Mans Rullgard <mans@mansr.com>
>> ---
>>  drivers/video/backlight/led_bl.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
>> index 3259292fda76..28e83618a296 100644
>> --- a/drivers/video/backlight/led_bl.c
>> +++ b/drivers/video/backlight/led_bl.c
>> @@ -200,8 +200,8 @@ static int led_bl_probe(struct platform_device *pdev)
>>  	props.type = BACKLIGHT_RAW;
>>  	props.max_brightness = priv->max_brightness;
>>  	props.brightness = priv->default_brightness;
>> -	props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
>> -		      FB_BLANK_UNBLANK;
>> +	props.power = (priv->default_brightness > 0) ? FB_BLANK_UNBLANK :
>> +		      FB_BLANK_POWERDOWN;
>
> The logic was wrong before but I think will still be wrong after the
> change too (e.g. the bogus logic is probably avoiding backlight flicker
> in some use cases).
>
> The logic here needs to be similar to what pwm_bl.c implements in
> pwm_backlight_initial_power_state(). Whilst it might be better
> to implement this in led_bl_get_leds() let me show what I mean
> in code that fits in the current line:
>
> 	/*
> 	 * Activate the backlight if the LEDs are already lit *or*
> 	 * there is no phandle link (meaning the backlight power
> 	 * state cannot be synced with the display state).
> 	 */
> 	props.power = (active_at_boot || !dev->node->phandle) ?
> 			FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
>
> Note that active_at_boot is not the same as (priv->default_brightness > 0)
> since the value read by led_bl_get_leds() can be clobbered when we
> parse the properties.

Am I understanding correctly that the code should be using the
default_brightness value as set by led_bl_get_leds() to determine the
initial power state, not whatever default value the devicetree provides?

-- 
Måns Rullgård

WARNING: multiple messages have this Message-ID (diff)
From: "Måns Rullgård" <mans@mansr.com>
To: Daniel Thompson <daniel.thompson@linaro.org>
Cc: linux-fbdev@vger.kernel.org, Jingoo Han <jingoohan1@gmail.com>,
	Helge Deller <deller@gmx.de>, Lee Jones <lee@kernel.org>,
	linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] backlight: led_bl: fix initial power state
Date: Tue, 04 Jul 2023 16:31:51 +0100	[thread overview]
Message-ID: <yw1xo7krzo9k.fsf@mansr.com> (raw)
In-Reply-To: <20230704150310.GA385243@aspen.lan> (Daniel Thompson's message of "Tue, 4 Jul 2023 16:03:10 +0100")

Daniel Thompson <daniel.thompson@linaro.org> writes:

> On Tue, Jul 04, 2023 at 03:07:50PM +0100, Mans Rullgard wrote:
>> The condition for the initial power state based on the default
>> brightness value is reversed.  Fix it.
>>
>> Fixes: ae232e45acf9 ("backlight: add led-backlight driver")
>> Signed-off-by: Mans Rullgard <mans@mansr.com>
>> ---
>>  drivers/video/backlight/led_bl.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/video/backlight/led_bl.c b/drivers/video/backlight/led_bl.c
>> index 3259292fda76..28e83618a296 100644
>> --- a/drivers/video/backlight/led_bl.c
>> +++ b/drivers/video/backlight/led_bl.c
>> @@ -200,8 +200,8 @@ static int led_bl_probe(struct platform_device *pdev)
>>  	props.type = BACKLIGHT_RAW;
>>  	props.max_brightness = priv->max_brightness;
>>  	props.brightness = priv->default_brightness;
>> -	props.power = (priv->default_brightness > 0) ? FB_BLANK_POWERDOWN :
>> -		      FB_BLANK_UNBLANK;
>> +	props.power = (priv->default_brightness > 0) ? FB_BLANK_UNBLANK :
>> +		      FB_BLANK_POWERDOWN;
>
> The logic was wrong before but I think will still be wrong after the
> change too (e.g. the bogus logic is probably avoiding backlight flicker
> in some use cases).
>
> The logic here needs to be similar to what pwm_bl.c implements in
> pwm_backlight_initial_power_state(). Whilst it might be better
> to implement this in led_bl_get_leds() let me show what I mean
> in code that fits in the current line:
>
> 	/*
> 	 * Activate the backlight if the LEDs are already lit *or*
> 	 * there is no phandle link (meaning the backlight power
> 	 * state cannot be synced with the display state).
> 	 */
> 	props.power = (active_at_boot || !dev->node->phandle) ?
> 			FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
>
> Note that active_at_boot is not the same as (priv->default_brightness > 0)
> since the value read by led_bl_get_leds() can be clobbered when we
> parse the properties.

Am I understanding correctly that the code should be using the
default_brightness value as set by led_bl_get_leds() to determine the
initial power state, not whatever default value the devicetree provides?

-- 
Måns Rullgård

  reply	other threads:[~2023-07-04 15:31 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-04 14:07 [PATCH] backlight: led_bl: fix initial power state Mans Rullgard
2023-07-04 14:07 ` Mans Rullgard
2023-07-04 15:03 ` Daniel Thompson
2023-07-04 15:03   ` Daniel Thompson
2023-07-04 15:31   ` Måns Rullgård [this message]
2023-07-04 15:31     ` Måns Rullgård
2023-07-04 15:40     ` Daniel Thompson
2023-07-04 15:40       ` Daniel Thompson
2023-07-04 17:07   ` Sam Ravnborg
2023-07-04 17:07     ` Sam Ravnborg
2023-07-05 14:07     ` Daniel Thompson
2023-07-05 14:07       ` Daniel Thompson
2023-07-05 17:56       ` Sam Ravnborg
2023-07-05 17:56         ` Sam Ravnborg
  -- strict thread matches above, loose matches on Subject: below --
2023-07-05 14:24 Mans Rullgard
2023-07-05 14:24 ` Mans Rullgard
2023-07-05 14:33 ` Daniel Thompson
2023-07-05 14:33   ` Daniel Thompson
2023-07-05 14:36   ` Måns Rullgård
2023-07-05 14:36     ` Måns Rullgård
2023-07-05 14:44     ` Daniel Thompson
2023-07-05 14:44       ` Daniel Thompson
2023-07-05 14:51       ` Måns Rullgård
2023-07-05 14:51         ` Måns Rullgård

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=yw1xo7krzo9k.fsf@mansr.com \
    --to=mans@mansr.com \
    --cc=daniel.thompson@linaro.org \
    --cc=deller@gmx.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jingoohan1@gmail.com \
    --cc=lee@kernel.org \
    --cc=linux-fbdev@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.