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.
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 ;-).
[...] 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.
Daniel.