From: Lee Jones <lee.jones@linaro.org>
To: linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC] pwm-backlight: Allow backlight to remain disabled on boot
Date: Thu, 26 Feb 2015 11:06:59 +0000 [thread overview]
Message-ID: <20150226110659.GO6688@x1> (raw)
In-Reply-To: <1406806970-12561-1-git-send-email-thierry.reding@gmail.com>
On Thu, 31 Jul 2014, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> 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".
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> I've been meaning to send this for a while but was always holding back
> because of the indoctrination that this type of configuration shouldn't
> be part of device tree. However this issue was recently raised again in
> the context of power up sequences for display panels. As described above
> the issue is that panel datasheets recommend that the backlight attached
> to a panel be turned on at the very last step to avoid visual glitches
> during the panel's power up sequence. With the current implementation it
> is typical for the backlight to be probed before the display panel. That
> has, in many cases, the side-effect of enabling the backlight, therefore
> making the screen content visible before it's actually initialized.
>
> Some panels come up with random garbage when uninitialized, others show
> all white. With some luck the panel will be all black and users won't
> really notice.
>
> This patch is an attempt to enable boards to override the default of
> turning on the backlight for the pwm-backlight driver. I'm not sure if
> there was a specific reason to turn on the backlight by default when
> this driver was initially written, but the fact is that since it has
> pretty much always been like this we can't really go and change the
> default, otherwise a lot of people may end up with no backlight and no
> clue as to how to enable it. So the only reasonable thing we can do is
> to keep the old behaviour and give new boards a way to override it if
> they know that some other part of the stack will enable it at the right
> moment.
>
> .../devicetree/bindings/video/backlight/pwm-backlight.txt | 1 +
> drivers/video/backlight/pwm_bl.c | 8 ++++++++
> include/linux/pwm_backlight.h | 2 ++
> 3 files changed, 11 insertions(+)
Some people on the list are talking about this again.
What was the verdict?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: lee.jones@linaro.org (Lee Jones)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC] pwm-backlight: Allow backlight to remain disabled on boot
Date: Thu, 26 Feb 2015 11:06:59 +0000 [thread overview]
Message-ID: <20150226110659.GO6688@x1> (raw)
In-Reply-To: <1406806970-12561-1-git-send-email-thierry.reding@gmail.com>
On Thu, 31 Jul 2014, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> 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".
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> I've been meaning to send this for a while but was always holding back
> because of the indoctrination that this type of configuration shouldn't
> be part of device tree. However this issue was recently raised again in
> the context of power up sequences for display panels. As described above
> the issue is that panel datasheets recommend that the backlight attached
> to a panel be turned on at the very last step to avoid visual glitches
> during the panel's power up sequence. With the current implementation it
> is typical for the backlight to be probed before the display panel. That
> has, in many cases, the side-effect of enabling the backlight, therefore
> making the screen content visible before it's actually initialized.
>
> Some panels come up with random garbage when uninitialized, others show
> all white. With some luck the panel will be all black and users won't
> really notice.
>
> This patch is an attempt to enable boards to override the default of
> turning on the backlight for the pwm-backlight driver. I'm not sure if
> there was a specific reason to turn on the backlight by default when
> this driver was initially written, but the fact is that since it has
> pretty much always been like this we can't really go and change the
> default, otherwise a lot of people may end up with no backlight and no
> clue as to how to enable it. So the only reasonable thing we can do is
> to keep the old behaviour and give new boards a way to override it if
> they know that some other part of the stack will enable it at the right
> moment.
>
> .../devicetree/bindings/video/backlight/pwm-backlight.txt | 1 +
> drivers/video/backlight/pwm_bl.c | 8 ++++++++
> include/linux/pwm_backlight.h | 2 ++
> 3 files changed, 11 insertions(+)
Some people on the list are talking about this again.
What was the verdict?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org ? Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
WARNING: multiple messages have this Message-ID (diff)
From: Lee Jones <lee.jones@linaro.org>
To: Thierry Reding <thierry.reding@gmail.com>
Cc: Jingoo Han <jg1.han@samsung.com>, Bryan Wu <cooloney@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>,
Tomi Valkeinen <tomi.valkeinen@ti.com>,
Russell King <linux@arm.linux.org.uk>,
Eric Miao <eric.y.miao@gmail.com>,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-fbdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] pwm-backlight: Allow backlight to remain disabled on boot
Date: Thu, 26 Feb 2015 11:06:59 +0000 [thread overview]
Message-ID: <20150226110659.GO6688@x1> (raw)
In-Reply-To: <1406806970-12561-1-git-send-email-thierry.reding@gmail.com>
On Thu, 31 Jul 2014, Thierry Reding wrote:
> From: Thierry Reding <treding@nvidia.com>
>
> 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".
>
> Signed-off-by: Thierry Reding <treding@nvidia.com>
> ---
> I've been meaning to send this for a while but was always holding back
> because of the indoctrination that this type of configuration shouldn't
> be part of device tree. However this issue was recently raised again in
> the context of power up sequences for display panels. As described above
> the issue is that panel datasheets recommend that the backlight attached
> to a panel be turned on at the very last step to avoid visual glitches
> during the panel's power up sequence. With the current implementation it
> is typical for the backlight to be probed before the display panel. That
> has, in many cases, the side-effect of enabling the backlight, therefore
> making the screen content visible before it's actually initialized.
>
> Some panels come up with random garbage when uninitialized, others show
> all white. With some luck the panel will be all black and users won't
> really notice.
>
> This patch is an attempt to enable boards to override the default of
> turning on the backlight for the pwm-backlight driver. I'm not sure if
> there was a specific reason to turn on the backlight by default when
> this driver was initially written, but the fact is that since it has
> pretty much always been like this we can't really go and change the
> default, otherwise a lot of people may end up with no backlight and no
> clue as to how to enable it. So the only reasonable thing we can do is
> to keep the old behaviour and give new boards a way to override it if
> they know that some other part of the stack will enable it at the right
> moment.
>
> .../devicetree/bindings/video/backlight/pwm-backlight.txt | 1 +
> drivers/video/backlight/pwm_bl.c | 8 ++++++++
> include/linux/pwm_backlight.h | 2 ++
> 3 files changed, 11 insertions(+)
Some people on the list are talking about this again.
What was the verdict?
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
next prev parent reply other threads:[~2015-02-26 11:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-31 11:42 [RFC] pwm-backlight: Allow backlight to remain disabled on boot Thierry Reding
2014-07-31 11:42 ` Thierry Reding
2014-07-31 11:42 ` Thierry Reding
2014-07-31 11:42 ` Thierry Reding
2014-07-31 11:54 ` Thierry Reding
2014-07-31 11:54 ` Thierry Reding
2014-07-31 11:54 ` Thierry Reding
2014-07-31 11:54 ` Thierry Reding
2014-08-07 9:30 ` Jingoo Han
2014-08-07 9:30 ` Jingoo Han
2014-08-07 9:30 ` Jingoo Han
2014-08-07 9:30 ` Jingoo Han
2014-07-31 11:56 ` Thierry Reding
2014-07-31 11:56 ` Thierry Reding
2014-07-31 11:56 ` Thierry Reding
2014-07-31 11:56 ` Thierry Reding
2014-08-07 9:54 ` Ajay kumar
2014-08-07 9:54 ` Ajay kumar
2014-08-07 9:54 ` Ajay kumar
2014-08-07 9:54 ` Ajay kumar
2015-02-26 11:06 ` Lee Jones [this message]
2015-02-26 11:06 ` Lee Jones
2015-02-26 11:06 ` Lee Jones
2018-01-04 2:18 ` hl
2018-01-04 2:18 ` hl
2018-01-04 2:18 ` hl
2018-01-04 2:18 ` hl
2018-01-04 8:22 ` Peter Ujfalusi
2018-01-04 8:22 ` Peter Ujfalusi
2018-01-04 8:22 ` Peter Ujfalusi
2018-01-04 8:22 ` Peter Ujfalusi
2018-01-04 9:33 ` hl
2018-01-04 9:33 ` hl
2018-01-04 9:33 ` hl
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=20150226110659.GO6688@x1 \
--to=lee.jones@linaro.org \
--cc=linux-arm-kernel@lists.infradead.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.