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.