[PATCH] backlight: pwm_bl: Avoid backlight flicker if backlight control GPIO is input

Daniel Thompson daniel.thompson at linaro.org
Mon Jul 19 11:22:02 UTC 2021


On Sun, Jul 18, 2021 at 11:14:15PM +0200, Marek Vasut wrote:
> If the backlight enable GPIO is configured as input, the driver currently
> unconditionally forces the GPIO to output-enable. This can cause backlight
> flicker on boot e.g. in case the GPIO should not be enabled before the PWM
> is configured and is correctly pulled low by external resistor.
> 
> Fix this by extending the current check to differentiate between backlight
> GPIO enable set as input and set as direction unknown. In case of input,
> read the GPIO value to determine the pull resistor placement, set the GPIO
> as output, and drive that exact value it was pulled to. In case of unknown
> direction, retain previous behavior, that is set the GPIO as output-enable.
> 
> Fixes: 3698d7e7d221 ("backlight: pwm_bl: Avoid backlight flicker when probed from DT")
> Signed-off-by: Marek Vasut <marex at denx.de>
> Cc: Christian Gmeiner <christian.gmeiner at gmail.com>
> Cc: Daniel Thompson <daniel.thompson at linaro.org>
> Cc: Heiko Stuebner <heiko at sntech.de>
> Cc: Philipp Zabel <p.zabel at pengutronix.de>
> Cc: Thierry Reding <treding at nvidia.com>
> Cc: linux-pwm at vger.kernel.org
> Cc: linux-fbdev at vger.kernel.org
> To: dri-devel at lists.freedesktop.org
> ---
> NOTE: I think this whole auto-detection scheme should just be replaced by a
>       DT prop, because it is very fragile.

I have some sympathy for this view... although I think the boat has
already set sail.

However, on the basis of making things less fragile, I think the
underlying problem here is the assumption that it is safe to modify
enable_gpio before the driver has imposed state upon the PWM (this
assumption has always been made and, in addition to systems where the BL
has a phandle will also risks flicker problems on systems where
power_pwm_on_delay is not zero).

This patch does not change the assumption that we can configure the
GPIO before we modify the PWM state. This means it won't fix the problem
for cases there the pin is HiZ by default but whose GPIOD_ASIS state is
neither input nor output.

I wonder if it might be better to move the code to configure the
direction of enable_gpio out of the probe function and into
pwm_backlight_power_on():

	if (pb->enable_gpio) {
		if (gpiod_get_direction(pb->enable_gpio) != 0))
			gpiod_direction_output(pb->enable_gpio, 1);
		else
			gpiod_set_value_can_sleep(pb->enable_gpio, 1);
	}

By the time we reach this function the driver explicitly applies state
to the GPIO then we know what the value must be.


Daniel.

> ---
>  drivers/video/backlight/pwm_bl.c | 35 +++++++++++++++++++++++---------
>  1 file changed, 25 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
> index e48fded3e414..7ec992b722eb 100644
> --- a/drivers/video/backlight/pwm_bl.c
> +++ b/drivers/video/backlight/pwm_bl.c
> @@ -445,7 +445,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>  	struct device_node *node = pdev->dev.of_node;
>  	struct pwm_bl_data *pb;
>  	struct pwm_state state;
> -	unsigned int i;
> +	unsigned int i, dir, val;
>  	int ret;
>  
>  	if (!data) {
> @@ -487,16 +487,31 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>  	}
>  
>  	/*
> -	 * If the GPIO is not known to be already configured as output, that
> -	 * is, if gpiod_get_direction returns either 1 or -EINVAL, change the
> -	 * direction to output and set the GPIO as active.
> -	 * Do not force the GPIO to active when it was already output as it
> -	 * could cause backlight flickering or we would enable the backlight too
> -	 * early. Leave the decision of the initial backlight state for later.
> +	 * If the GPIO is not known to be already configured as output, then:
> +	 * - if the GPIO direction is input, read its current value to find out
> +	 *   whether the pin is pulled high or low (it is backlight control, so
> +	 *   it cannot be floating), change the direction to output and set the
> +	 *   GPIO such that it drives this strapped value.
> +	 *   Do not force the GPIO to state which is different than that to
> +	 *   which the GPIO was pulled to, this could cause backlight flicker
> +	 *   on boot e.g. in case the PWM is not ready yet.
> +	 * - if the GPIO direction is unknown, tahat is, if gpiod_get_direction
> +	 *   returns -EINVAL, change the direction to output and set the GPIO
> +	 *   as active.
> +	 *   Do not force the GPIO to active when it was already output as it
> +	 *   could cause backlight flickering or we would enable the backlight
> +	 *   too early. Leave the decision of the initial backlight state for
> +	 *   later.
>  	 */
> -	if (pb->enable_gpio &&
> -	    gpiod_get_direction(pb->enable_gpio) != 0)
> -		gpiod_direction_output(pb->enable_gpio, 1);
> +	if (pb->enable_gpio) {
> +		dir = gpiod_get_direction(pb->enable_gpio);
> +		if (dir != 0) {
> +			val = 1;
> +			if (dir == 1)
> +				val = gpiod_get_value_cansleep(pb->enable_gpio);
> +			gpiod_direction_output(pb->enable_gpio, val);
> +		}
> +	}
>  
>  	pb->power_supply = devm_regulator_get(&pdev->dev, "power");
>  	if (IS_ERR(pb->power_supply)) {
> -- 
> 2.30.2
> 


More information about the dri-devel mailing list