[PATCH] backlight: pwm_bl: Avoid backlight flicker if backlight control GPIO is input

[Marek Vasut]

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