public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@wwwdotorg.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Rob Herring <rob.herring@calxeda.com>,
	Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Tony Lindgren <tony@atomide.com>,
	Eric Miao <eric.y.miao@gmail.com>,
	Haojian Zhuang <haojian.zhuang@gmail.com>,
	Ben Dooks <ben-linux@fluff.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Simon Horman <horms@verge.net.au>,
	Magnus Damm <magnus.damm@gmail.com>,
	Guan Xuetao <gxt@mprc.pku.edu.cn>,
	devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
	linux-omap@vger.kernel.org, openezx-devel@lists.openezx.org,
	linux-samsung-soc@vger.kernel.org, linux-sh@vger.kernel.org,
	linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 10/10] pwm-backlight: Allow backlight to remain disabled on boot
Date: Tue, 01 Oct 2013 12:50:51 -0600	[thread overview]
Message-ID: <524B198B.3010609@wwwdotorg.org> (raw)
In-Reply-To: <1379972467-11243-11-git-send-email-treding@nvidia.com>

On 09/23/2013 03:41 PM, Thierry Reding wrote:
> The default for backlight devices is to be enabled immediately when
> registering with the backlight core. This can be useful for setups that
> use a simple framebuffer device and where the backlight cannot otherwise
> be hooked up to the panel.
> 
> However, when dealing with more complex setups, such as those of recent
> ARM SoCs, this can be problematic. Since the backlight is usually setup
> separately from the display controller, the probe order is not usually
> deterministic. That can lead to situations where the backlight will be
> powered up and the panel will show an uninitialized framebuffer.
> 
> Furthermore, subsystems such as DRM have advanced functionality to set
> the power mode of a panel. In order to allow such setups to power up the
> panel at exactly the right moment, a way is needed to prevent the
> backlight core from powering the backlight up automatically when it is
> registered.
> 
> This commit introduces a new boot_off field in the platform data (and
> also implements getting the same information from device tree). When set
> the initial backlight power mode will be set to "off".

> diff --git a/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt b/Documentation/devicetree/bindings/video/backlight/pwm-backlight.txt

> +  - backlight-boot-off: keep the backlight disabled on boot

A few thoughts:

1) Does this property indicate that:

a) The current state of the backlight at boot. In which case, this will
need bootloader involvement to modify the value in the DT at boot time
based on whether the bootloader turned on the backlight:-(

b) That the driver should not turn on the backlight immediately? That
seems to describe driver behaviour more than HW. Is it appropriate to
put that into DT?

Your suggestion to make the backlight not turn on by default might be a
better fix?

2) Should the driver instead attempt to read the current state of the
GPIO output to determine whether the backlight is on? This may not be
possible on all HW.

3) Doesn't the following code in probe() (added in a previous patch)
need to be updated?

> +	if (gpio_is_valid(pb->enable_gpio)) {
> +		if (pb->enable_gpio_flags & PWM_BACKLIGHT_GPIO_ACTIVE_LOW)
> +			gpio_set_value(pb->enable_gpio, 0);
> +		else
> +			gpio_set_value(pb->enable_gpio, 1);
> +	}

... That assumes that the backlight is on at boot, and hence presumably
after this patch still always turns on the backlight, only to turn it
off very quickly once the following code in this patch executes:

(and perhaps we also need to avoid turning the backlight off then on if
it was already on at boot)

> diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c

> @@ -318,6 +320,12 @@ static int pwm_backlight_probe(struct platform_device *pdev)
>  	}
>  
>  	bl->props.brightness = data->dft_brightness;
> +
> +	if (data->boot_off)
> +		bl->props.power = FB_BLANK_POWERDOWN;
> +	else
> +		bl->props.power = FB_BLANK_UNBLANK;


  reply	other threads:[~2013-10-01 18:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-23 21:40 [PATCH 00/10] pwm-backlight: Add GPIO and power supply support Thierry Reding
2013-09-23 21:40 ` [PATCH 01/10] pwm-backlight: Refactor backlight power on/off Thierry Reding
2013-10-01 18:26   ` Stephen Warren
2013-10-01 20:34     ` Thierry Reding
2013-09-23 21:40 ` [PATCH 02/10] pwm-backlight: Add optional enable GPIO Thierry Reding
2013-09-23 21:41 ` [PATCH 03/10] ARM: OMAP: Initialize PWM backlight enable_gpio field Thierry Reding
2013-09-23 21:41 ` [PATCH 04/10] ARM: pxa: " Thierry Reding
2013-09-23 21:41 ` [PATCH 05/10] ARM: SAMSUNG: " Thierry Reding
2013-10-01 18:31   ` Stephen Warren
2013-10-01 20:43     ` Thierry Reding
2013-10-01 20:58       ` Stephen Warren
2013-10-01 21:23         ` Thierry Reding
2013-09-23 21:41 ` [PATCH 06/10] ARM: shmobile: " Thierry Reding
2013-09-25  5:40   ` Simon Horman
2013-09-23 21:41 ` [PATCH 07/10] unicore32: " Thierry Reding
2013-09-23 21:41 ` [PATCH 08/10] pwm-backlight: Use new " Thierry Reding
2013-10-01 18:39   ` Stephen Warren
2013-10-01 20:49     ` Thierry Reding
2013-09-23 21:41 ` [PATCH 09/10] pwm-backlight: Use an optional power supply Thierry Reding
2013-10-01 18:43   ` Stephen Warren
2013-10-01 20:53     ` Thierry Reding
2013-10-01 20:59       ` Stephen Warren
2013-10-01 21:31         ` Thierry Reding
2013-10-02 10:35           ` Mark Brown
2013-09-23 21:41 ` [PATCH 10/10] pwm-backlight: Allow backlight to remain disabled on boot Thierry Reding
2013-10-01 18:50   ` Stephen Warren [this message]
2013-10-01 21:14     ` Thierry Reding
2013-10-02 17:45     ` Thierry Reding
2013-09-24  8:14 ` [PATCH 00/10] pwm-backlight: Add GPIO and power supply support Simon Horman
2013-09-24  9:00   ` Thierry Reding
2013-09-25  5:39     ` Simon Horman

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=524B198B.3010609@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=ben-linux@fluff.org \
    --cc=devicetree@vger.kernel.org \
    --cc=eric.y.miao@gmail.com \
    --cc=gxt@mprc.pku.edu.cn \
    --cc=haojian.zhuang@gmail.com \
    --cc=horms@verge.net.au \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=kgene.kim@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux-pwm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux-sh@vger.kernel.org \
    --cc=magnus.damm@gmail.com \
    --cc=mark.rutland@arm.com \
    --cc=openezx-devel@lists.openezx.org \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.com \
    --cc=thierry.reding@gmail.com \
    --cc=tony@atomide.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox