On 7/23/21 1:17 PM, Daniel Thompson wrote:
On Fri, Jul 23, 2021 at 11:15:10AM +0100, Daniel Thompson wrote:
On Thu, Jul 22, 2021 at 09:02:04PM +0200, Marek Vasut wrote:
On 7/22/21 1:28 PM, Daniel Thompson wrote:
On Wed, Jul 21, 2021 at 08:46:42PM +0200, Marek Vasut wrote:
On 7/21/21 6:12 PM, Daniel Thompson wrote:
On Wed, Jul 21, 2021 at 05:09:57PM +0200, Marek Vasut wrote:
On 7/21/21 12:49 PM, Daniel Thompson wrote:
[...]
This sails very close to the
edge of what is in-scope for DT (at least it does it we can read
the inherited state directly from the hardware).
The problem with reading it out of hardware is that the hardware might be in
undefined state and expects Linux to define that state, so that does not
always work. Hence my initial suggestion to add a DT property to define the
state up front, instead of using these fragile heuristics.
To achieve a flicker-free boot we must know the initial state of the
backlight (not just the enable pin).
The backlight hardware might be in uninitialized state and then Linux should
set the state, likely based on something in DT, because there is no previous
state to read.
There is always a previous state. The kernel doesn't care whether that
previous state was imposed by a power-on reset, the bootloader or a
kexec.
For the driver to come up flicker-free in all the different cases we
need to know whether the backlight is currently emitting light or not
and, if it is emitting light, then we need to know what the duty cycle
is (currently we inherit require the PWM driver to correctly inherit the
duty cycle from the hardware).
Oops... this is wrong (I think it is cross-talk from an old patch). We
do not currently inherit the duty cycle.
There is that, and if you did, you would be telling PWM drivers not to
reset/reinit the hardware in probe. I'm not sure whether that is a good
idea.
So far, the previous state has been observable by the lower level
drivers (GPIO, PWM, regulator). I remain reluctant to provide
workarounds for cases where it is not observable without motivating
hardware. I certainly wouldn't want to make such bindings mandatory
since observable hardware registers are a far more reliable source of
truth than what the DT tells us about what it thinks the bootloader
(or power-on reset) actually did ;-).
Which makes conclusion badly reasoned.
However, until we can clearly articulate whether the problem we want to
solve is describing the initial backlight state or specifying the default
(post-probe) power state for the legacy cases I'm still content not to
change things ;-).
For me, it was always about specifying well defined default state of the
backlight.
[...]
Wow! That is *way* longer than I intended when I started writing it.
Anyhow I suspect any disconnect comes about due to the difference in
backlight state *after* probe being, in part, to software structure
rather than purely a hardware property.
Maybe this should be added to documentation.
I'll see what I can do.
Done, see v3. I think it is better explained than the e-mail version.
Thanks
