On Mon, Nov 19, 2018 at 9:32 AM Uwe Kleine-König
[off-list ref] wrote:

To sumarize: When the pwm driver probes it is not yet clear if the idle
state of the output pin is high or low. Even when the pinctrl device has
an "init" and a "default" pinctrl, it is not yet fixed when its
"default" is configured.

The way Thierry wants to fix that is by disabling the output driver
until the pwm is in use und rely on a pull-up or pull-down in hardware.

The way I want to fix this is to only configure the pwm pin as part of
the consumer. This is late enough that the consumer already requested
and configured the pwm such that the idle level is known.
Thierry's and Lothar's claim was that putting the pin setup of the pwm
pin into the pwm consumer's pinctrl was forbidden. That's why I asked
you as pinctrl maintainer if there is a requirement that I don't know
of.

I think we need to be pragmatic and listen most to whoever has
the hardware and need to get it to work. The system needs
to come up in some reasonable way, preferably so that vendors
doing products with it do not have to apply a fat patch stack
to get that backlight working in an acceptable way. Else the
end result is out-of-tree code to paper over the issue and that
IMO is worse than some minor ugliness in the kernel.

However the whole ordeal points to a problem that is with the
pin control system and Thierry's and Lothar's intuition about this
is right in a way: if the pin control system could read out the
state of the hardware at boot (as we nowadays do with GPIO,
which also has a consumer flag cleverly named GPIOD_ASIS)
the whole thing would be no problem.

The same kind of goes for PWM itself in this case I guess.

The whole issue with splash screens and different hardware
turned over to Linux in running state is a bit imperfect I would
say, I think Viresh was working on boot constraints to get
handover of different systems components into some kind
of shape but maybe that stopped short because of the
complexities involved. Isn't that the real problem here?
https://lkml.org/lkml/2017/8/1/191

Yours,
Linus Walleij