[RFC] regulator: Shared regulators (configured by bootloader)

[Viresh Kumar <viresh.kumar@linaro.org>]

Hi Mark/Liam,

I am looking to solve a problem faced by some of the Qualcomm
platforms and want your suggestions on how should we fix it. One of my
ex-colleague tried to solve [1] this problem but that thread never
concluded (and I don't really agree with the solution it offered).


Problem statement

A regulator is shared by multiple devices and their drivers can get
probed in any order. The regulator is configured (with constraints
suitable for one or more devices) by the bootloader (i.e. regulator
was ON at kernel boot). While the drivers get probed, they may choose
to disable or reconfigure the regulator. And that is of course the
right thing to do for those drivers. But this might not be ideal for
other devices which share the regulator and are currently using it
(but haven't been probed yet).

A typical use case in cell phones is to put up a simple splash screen
in the bootloader and replace that screen when userspace is running
(typically with the home screen). If a shared regulator is enabled in
the bootloader to power the screen and left on during kernel
initialization, it's possible that a non-screen driver may disable or
reconfigure the regulator from its probe() and that would generate a
glitch at the screen, which wouldn't be nice.


Solution(s)

There is no way for us to know when the kernel has done booting,
specially with the drivers compiled as modules, as they can be
inserted anytime. For example, if the LCD driver is never inserted to
the kernel, then we should never allow to regulator to get disabled
(Even if that results in loss of energy).

I was wondering if we should add some DT properties to consumer
devices to list down such constraints and create "proxy" regulators
for them as soon as possible during the kernel boot (maybe from
regulator_register()). Of course that would require us to traverse all
DT nodes containing such properties, as the device drivers shouldn't
be up by then.

And finally once the drivers are probed and try to get regulator for
the device, we remove these proxy regulators (only after creating the
real ones). If driver for some proxy regulator doesn't get probed,
then that regulator stays ON for ever.

Suggestions ? Take your time to reply, I know that the merge window
has just started.

-- 
viresh

[1] https://lkml.org/lkml/2016/5/9/64