On Mon, Nov 19, 2018 at 9:32 AM Uwe Kleine-König <u.kleine-koenig@xxxxxxxxxxxxxx> 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
