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.
