From: Daniel Thompson <daniel.thompson@linaro.org>
To: Paul Kocialkowski <contact@paulk.fr>,
Philipp Zabel <p.zabel@pengutronix.de>
Cc: linux-pwm@vger.kernel.org, linux-kernel@vger.kernel.org,
Thierry Reding <thierry.reding@gmail.com>,
Lee Jones <lee.jones@linaro.org>,
Jingoo Han <jingoohan1@gmail.com>
Subject: Re: PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support
Date: Thu, 6 Jul 2017 13:57:43 +0100 [thread overview]
Message-ID: <eb6b0abc-28a7-b7e2-0c25-8c7817a3321e@linaro.org> (raw)
In-Reply-To: <1499344862.1379.19.camel@paulk.fr>
On 06/07/17 13:41, Paul Kocialkowski wrote:
>>> Some panels have a documented powerup sequence, which usually ends with
>>> the backlight being enabled to avoid showing garbage before the panel is
>>> initialized completely.
>>> The reason for 3698d7e7d221 was a device with the display disabled out
>>> of the bootloader, where the backlight is controlled by the simple-panel
>>> driver. Enabling the backlight from the backlight driver before the
>>> panel driver requests the backlight to be enabled (before the panel is
>>> powered) would result in a white flash during boot.
>>>
>>> I tried to be careful to only let the backlight driver set the initial
>>> state to disabled if a few conditions are met: the GPIO is already
>>> configured as output and disabled, and the backlight device tree node
>>> has a phandle pointing to it, so we can expect there to be some
>>> controlling instance that will enable it when appropriate.
>>>
>>> I wonder why in your case there is a phandle link to the backlight node
>>> but nothing actually enables the backlight during boot. I would expect
>>> that to be handled by the panel driver.
>>
>> I had completely missed the fact that the panel driver is supposed to request
>> backlight enable! With that in mind, this policy no longer concerns "the whole
>> lifetime of the driver" but only the timeframe between backlight probe and
>> panel
>> probe. Thanks for clarifying this. I suppose I agree with this policy now.
>>
>> So remains the question: why does the panel not enable backlight on my device?
>>
>> I will investigate this later today. Hopefully, the probe defer logic should
>> prevent a case where the panel is probed (to the end) before the backlight
>> driver.
>
> This is actually due to the tegra drm driver not probing. It is happening on my
> setup (with a somewhat custom, out-of-tree config) on both jetson-tk1 and
> nyan_big, but also on kernelci, running both tegra_defconfig and
> multi_v7_defconfig.
>
> Since this is no longer a concern related to the pwm backlight driver, I will
> start a new thread with the relevant addresses in CC.
Thanks for the update. Much appreciated!
BTW, I got the impression from your first mail that you are chasing a
regression between v4.11 and v4.12. If that's the case you should know
that the backlight changes we have been discussing landed in v4.11 (so
if you do have a regression between these two releases then mentioning
backlight in the other thread may just be confusing).
Daniel.
next prev parent reply other threads:[~2017-07-06 12:57 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-04 20:13 PWM backlight initial state assumptions, or how pwm_bl killed my (nyan) cat^W backlight support Paul Kocialkowski
2017-07-05 10:24 ` Daniel Thompson
2017-07-05 10:41 ` Paul Kocialkowski
2017-07-05 11:07 ` Philipp Zabel
2017-07-05 11:47 ` Paul Kocialkowski
2017-07-06 12:41 ` Paul Kocialkowski
2017-07-06 12:57 ` Daniel Thompson [this message]
2017-07-06 13:02 ` Paul Kocialkowski
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=eb6b0abc-28a7-b7e2-0c25-8c7817a3321e@linaro.org \
--to=daniel.thompson@linaro.org \
--cc=contact@paulk.fr \
--cc=jingoohan1@gmail.com \
--cc=lee.jones@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pwm@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=thierry.reding@gmail.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;
as well as URLs for NNTP newsgroup(s).