* Re: [PATCH] backlight: gpio_backlight: Drop output gpio direction check for initial power state
2023-07-20 11:27 ` Daniel Thompson
@ 2023-07-20 12:56 ` Bartosz Golaszewski
2023-07-20 13:10 ` Daniel Thompson
2023-07-20 16:28 ` Andy Shevchenko
2023-07-21 5:16 ` Ying Liu
2 siblings, 1 reply; 8+ messages in thread
From: Bartosz Golaszewski @ 2023-07-20 12:56 UTC (permalink / raw)
To: Daniel Thompson
Cc: Ying Liu, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lee@kernel.org, jingoohan1@gmail.com, deller@gmx.de,
Linus Walleij, Andy Shevchenko
On Thu, Jul 20, 2023 at 1:27 PM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Thu, Jul 20, 2023 at 06:06:27AM +0000, Ying Liu wrote:
> > Bootloader may leave gpio direction as input and gpio value as logical low.
> > It hints that initial backlight power state should be FB_BLANK_POWERDOWN
> > since the gpio value is literally logical low.
>
> To be honest this probably "hints" that the bootloader simply didn't
> consider the backlight at all :-) . I'd rather the patch description
> focus on what circumstances lead to the current code making a bad
> decision. More like:
>
> If the GPIO pin is in the input state but the backlight is currently
> off due to default pull downs then ...
>
> > So, let's drop output gpio
> > direction check and only check gpio value to set the initial power state.
>
> This check was specifically added by Bartosz so I'd be interested in his
> opinion of this change (especially since he is now a GPIO maintainer)!
>
> What motivates (or motivated) the need to check the direction rather
> than just read that current logic level on the pin?
>
>
> Daniel.
> [I'm done but since Bartosz and Linus were not on copy of the original
> thread I've left the rest of the patch below as a convenience ;-) ]
>
This was done in commit: 706dc68102bc ("backlight: gpio: Explicitly
set the direction of the GPIO").
Let me quote myself from it:
--
The GPIO backlight driver currently requests the line 'as is', without
actively setting its direction. This can lead to problems: if the line
is in input mode by default, we won't be able to drive it later when
updating the status and also reading its initial value doesn't make
sense for backlight setting.
--
I agree with Thomas that it's highly unlikely the bootloader "hints"
at any specific backlight settings. That being said, the change itself
looks correct to me. The other branch of that if will always unblank
the backlight if the GPIO is in input mode which may not be desirable.
I don't see any obvious problem with this change, just make sure the
commit message makes more sense.
Bartosz
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] backlight: gpio_backlight: Drop output gpio direction check for initial power state
2023-07-20 12:56 ` Bartosz Golaszewski
@ 2023-07-20 13:10 ` Daniel Thompson
2023-07-20 13:18 ` Bartosz Golaszewski
0 siblings, 1 reply; 8+ messages in thread
From: Daniel Thompson @ 2023-07-20 13:10 UTC (permalink / raw)
To: Bartosz Golaszewski
Cc: Ying Liu, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lee@kernel.org, jingoohan1@gmail.com, deller@gmx.de,
Linus Walleij, Andy Shevchenko
On Thu, Jul 20, 2023 at 02:56:32PM +0200, Bartosz Golaszewski wrote:
> On Thu, Jul 20, 2023 at 1:27 PM Daniel Thompson
> <daniel.thompson@linaro.org> wrote:
> >
> > On Thu, Jul 20, 2023 at 06:06:27AM +0000, Ying Liu wrote:
> > > Bootloader may leave gpio direction as input and gpio value as logical low.
> > > It hints that initial backlight power state should be FB_BLANK_POWERDOWN
> > > since the gpio value is literally logical low.
> >
> > To be honest this probably "hints" that the bootloader simply didn't
> > consider the backlight at all :-) . I'd rather the patch description
> > focus on what circumstances lead to the current code making a bad
> > decision. More like:
> >
> > If the GPIO pin is in the input state but the backlight is currently
> > off due to default pull downs then ...
> >
> > > So, let's drop output gpio
> > > direction check and only check gpio value to set the initial power state.
> >
> > This check was specifically added by Bartosz so I'd be interested in his
> > opinion of this change (especially since he is now a GPIO maintainer)!
> >
> > What motivates (or motivated) the need to check the direction rather
> > than just read that current logic level on the pin?
> >
> >
> > Daniel.
> > [I'm done but since Bartosz and Linus were not on copy of the original
> > thread I've left the rest of the patch below as a convenience ;-) ]
> >
>
> This was done in commit: 706dc68102bc ("backlight: gpio: Explicitly
> set the direction of the GPIO").
>
> Let me quote myself from it:
> --
> The GPIO backlight driver currently requests the line 'as is', without
> actively setting its direction. This can lead to problems: if the line
> is in input mode by default, we won't be able to drive it later when
> updating the status and also reading its initial value doesn't make
> sense for backlight setting.
> --
You are perhaps quoting the wrong bit here ;-). The currently proposed
patch leaves the code to put the pin into output mode unmodified. However
there was an extra line at the bottom of your commit message:
--
Also: check the current direction and only read the value if it's output.
--
This was the bit I wanted to check on, since the proposed patch
literally reverses this!
However...
> I agree with Thomas that it's highly unlikely the bootloader "hints"
> at any specific backlight settings. That being said, the change itself
> looks correct to me. The other branch of that if will always unblank
> the backlight if the GPIO is in input mode which may not be desirable.
... if you're happy the proposed change is OK then I'm happy too!
I came to the same conclusion after reviewing the GPIO code this morning,
however I copied you in because I was worried I might have overlooked
something.
> I don't see any obvious problem with this change, just make sure the
> commit message makes more sense.
Agreed.
Daniel.
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] backlight: gpio_backlight: Drop output gpio direction check for initial power state
2023-07-20 13:10 ` Daniel Thompson
@ 2023-07-20 13:18 ` Bartosz Golaszewski
0 siblings, 0 replies; 8+ messages in thread
From: Bartosz Golaszewski @ 2023-07-20 13:18 UTC (permalink / raw)
To: Daniel Thompson
Cc: Ying Liu, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lee@kernel.org, jingoohan1@gmail.com, deller@gmx.de,
Linus Walleij, Andy Shevchenko
On Thu, Jul 20, 2023 at 3:10 PM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Thu, Jul 20, 2023 at 02:56:32PM +0200, Bartosz Golaszewski wrote:
> > On Thu, Jul 20, 2023 at 1:27 PM Daniel Thompson
> > <daniel.thompson@linaro.org> wrote:
> > >
> > > On Thu, Jul 20, 2023 at 06:06:27AM +0000, Ying Liu wrote:
> > > > Bootloader may leave gpio direction as input and gpio value as logical low.
> > > > It hints that initial backlight power state should be FB_BLANK_POWERDOWN
> > > > since the gpio value is literally logical low.
> > >
> > > To be honest this probably "hints" that the bootloader simply didn't
> > > consider the backlight at all :-) . I'd rather the patch description
> > > focus on what circumstances lead to the current code making a bad
> > > decision. More like:
> > >
> > > If the GPIO pin is in the input state but the backlight is currently
> > > off due to default pull downs then ...
> > >
> > > > So, let's drop output gpio
> > > > direction check and only check gpio value to set the initial power state.
> > >
> > > This check was specifically added by Bartosz so I'd be interested in his
> > > opinion of this change (especially since he is now a GPIO maintainer)!
> > >
> > > What motivates (or motivated) the need to check the direction rather
> > > than just read that current logic level on the pin?
> > >
> > >
> > > Daniel.
> > > [I'm done but since Bartosz and Linus were not on copy of the original
> > > thread I've left the rest of the patch below as a convenience ;-) ]
> > >
> >
> > This was done in commit: 706dc68102bc ("backlight: gpio: Explicitly
> > set the direction of the GPIO").
> >
> > Let me quote myself from it:
> > --
> > The GPIO backlight driver currently requests the line 'as is', without
> > actively setting its direction. This can lead to problems: if the line
> > is in input mode by default, we won't be able to drive it later when
> > updating the status and also reading its initial value doesn't make
> > sense for backlight setting.
> > --
>
> You are perhaps quoting the wrong bit here ;-). The currently proposed
> patch leaves the code to put the pin into output mode unmodified. However
> there was an extra line at the bottom of your commit message:
> --
> Also: check the current direction and only read the value if it's output.
> --
Yeah I'm no longer sure why I did this. The commit doesn't look harmful though.
Bart
>
> This was the bit I wanted to check on, since the proposed patch
> literally reverses this!
>
> However...
>
>
> > I agree with Thomas that it's highly unlikely the bootloader "hints"
> > at any specific backlight settings. That being said, the change itself
> > looks correct to me. The other branch of that if will always unblank
> > the backlight if the GPIO is in input mode which may not be desirable.
>
> ... if you're happy the proposed change is OK then I'm happy too!
> I came to the same conclusion after reviewing the GPIO code this morning,
> however I copied you in because I was worried I might have overlooked
> something.
>
>
> > I don't see any obvious problem with this change, just make sure the
> > commit message makes more sense.
>
> Agreed.
>
>
> Daniel.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH] backlight: gpio_backlight: Drop output gpio direction check for initial power state
2023-07-20 11:27 ` Daniel Thompson
2023-07-20 12:56 ` Bartosz Golaszewski
@ 2023-07-20 16:28 ` Andy Shevchenko
2023-07-21 5:16 ` Ying Liu
2 siblings, 0 replies; 8+ messages in thread
From: Andy Shevchenko @ 2023-07-20 16:28 UTC (permalink / raw)
To: Daniel Thompson
Cc: Ying Liu, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lee@kernel.org, jingoohan1@gmail.com, deller@gmx.de,
Linus Walleij, Bartosz Golaszewski, Andy Shevchenko
On Thu, Jul 20, 2023 at 2:27 PM Daniel Thompson
<daniel.thompson@linaro.org> wrote:
>
> On Thu, Jul 20, 2023 at 06:06:27AM +0000, Ying Liu wrote:
> > Bootloader may leave gpio direction as input and gpio value as logical low.
> > It hints that initial backlight power state should be FB_BLANK_POWERDOWN
> > since the gpio value is literally logical low.
>
> To be honest this probably "hints" that the bootloader simply didn't
> consider the backlight at all :-) . I'd rather the patch description
> focus on what circumstances lead to the current code making a bad
> decision. More like:
>
> If the GPIO pin is in the input state but the backlight is currently
> off due to default pull downs then ...
>
> > So, let's drop output gpio
> > direction check and only check gpio value to set the initial power state.
>
> This check was specifically added by Bartosz so I'd be interested in his
> opinion of this change (especially since he is now a GPIO maintainer)!
>
> What motivates (or motivated) the need to check the direction rather
> than just read that current logic level on the pin?
...
> > - else if (gpiod_get_direction(gbl->gpiod) == 0 &&
> > - gpiod_get_value_cansleep(gbl->gpiod) == 0)
> > + else if (gpiod_get_value_cansleep(gbl->gpiod) == 0)
> > bl->props.power = FB_BLANK_POWERDOWN;
The code before this patch needs a bit of elaboration. There is no
prohibition on reading value for the pin that is in any direction.
I.o.w. if the direction here is a problem it should have been
configured beforehand.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 8+ messages in thread
* RE: [PATCH] backlight: gpio_backlight: Drop output gpio direction check for initial power state
2023-07-20 11:27 ` Daniel Thompson
2023-07-20 12:56 ` Bartosz Golaszewski
2023-07-20 16:28 ` Andy Shevchenko
@ 2023-07-21 5:16 ` Ying Liu
2023-07-21 6:32 ` Andy Shevchenko
2 siblings, 1 reply; 8+ messages in thread
From: Ying Liu @ 2023-07-21 5:16 UTC (permalink / raw)
To: Daniel Thompson
Cc: dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
linux-kernel@vger.kernel.org, lee@kernel.org,
jingoohan1@gmail.com, deller@gmx.de, Linus Walleij,
Bartosz Golaszewski, Andy Shevchenko
Hi Daniel,
On Thursday, July 20, 2023 7:28 PM Daniel Thompson <daniel.thompson@linaro.org> wrote:
>
> On Thu, Jul 20, 2023 at 06:06:27AM +0000, Ying Liu wrote:
> > Bootloader may leave gpio direction as input and gpio value as logical low.
> > It hints that initial backlight power state should be
> FB_BLANK_POWERDOWN
> > since the gpio value is literally logical low.
>
> To be honest this probably "hints" that the bootloader simply didn't
> consider the backlight at all :-) . I'd rather the patch description
> focus on what circumstances lead to the current code making a bad
> decision. More like:
>
> If the GPIO pin is in the input state but the backlight is currently
> off due to default pull downs then ...
How about this patch description?
---------------------------------8<-------------------------------------------
Without this patch, if gpio pin is in input state but backlight is currently
off due to default pull downs, then initial power state is set to
FB_BLANK_UNBLANK in DT boot mode with phandle link and the backlight is
effectively turned on in gpio_backlight_probe(), which is undesirable
according to patch description of commit ec665b756e6f ("backlight:
gpio-backlight: Correct initial power state handling").
Quote:
---
If in DT boot we have phandle link then leave the GPIO in a state which the
bootloader left it and let the user of the backlight to configure it further.
---
So, let's drop output gpio direction check and only check gpio value to set
the initial power state.
---------------------------------8<-------------------------------------------
Regards,
Liu Ying
^ permalink raw reply [flat|nested] 8+ messages in thread* Re: [PATCH] backlight: gpio_backlight: Drop output gpio direction check for initial power state
2023-07-21 5:16 ` Ying Liu
@ 2023-07-21 6:32 ` Andy Shevchenko
0 siblings, 0 replies; 8+ messages in thread
From: Andy Shevchenko @ 2023-07-21 6:32 UTC (permalink / raw)
To: Ying Liu
Cc: Daniel Thompson, dri-devel@lists.freedesktop.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org,
lee@kernel.org, jingoohan1@gmail.com, deller@gmx.de,
Linus Walleij, Bartosz Golaszewski, Andy Shevchenko
On Fri, Jul 21, 2023 at 8:17 AM Ying Liu <victor.liu@nxp.com> wrote:
> On Thursday, July 20, 2023 7:28 PM Daniel Thompson <daniel.thompson@linaro.org> wrote:
> > On Thu, Jul 20, 2023 at 06:06:27AM +0000, Ying Liu wrote:
> > > Bootloader may leave gpio direction as input and gpio value as logical low.
> > > It hints that initial backlight power state should be
> > FB_BLANK_POWERDOWN
> > > since the gpio value is literally logical low.
> >
> > To be honest this probably "hints" that the bootloader simply didn't
> > consider the backlight at all :-) . I'd rather the patch description
> > focus on what circumstances lead to the current code making a bad
> > decision. More like:
> >
> > If the GPIO pin is in the input state but the backlight is currently
> > off due to default pull downs then ...
>
> How about this patch description?
>
> ---------------------------------8<-------------------------------------------
> Without this patch, if gpio pin is in input state but backlight is currently
s/Without this patch, if/If/
> off due to default pull downs, then initial power state is set to
> FB_BLANK_UNBLANK in DT boot mode with phandle link and the backlight is
> effectively turned on in gpio_backlight_probe(), which is undesirable
> according to patch description of commit ec665b756e6f ("backlight:
> gpio-backlight: Correct initial power state handling").
>
> Quote:
> ---
> If in DT boot we have phandle link then leave the GPIO in a state which the
> bootloader left it and let the user of the backlight to configure it further.
> ---
>
> So, let's drop output gpio direction check and only check gpio value to set
> the initial power state.
> ---------------------------------8<-------------------------------------------
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply [flat|nested] 8+ messages in thread