[RFC] shared regulator initialization and protection

[RFC] shared regulator initialization and protection

[Pingbo Wen]

(Resend, previous one rejected due to html link code)

Hi,

Those day, I get some fuzz idea in a proxy-consumer regulator driver [1] from Qcom kernel tree.
The driver is simple, that let some critical regulator, which specified in DT tree, initializing 
in a pre-defined state, and hold a regulator consumer during system boot, to provide some 
protection between multi-consumers.

And I think this driver is a hint that our upstream code lack of some regulator initialization protection.
We already have some regulator flags liked always_on, boot_on in the upstream code. The boot_on 
flag can do the enable work in boot time, the regulator_get_exclusive can provide some protection
from other consumers, and the regulator consumers itself will filter out some illegal and duplicated
operation.

If a regulator only used by one consumer, current code will work fine. But for the regulator which
shared between multi-consumers, we can not make sure that the regulator will work in a defined-state,
during system boot, since the device driver can probe in any order, and set some conflict attributes.

Currently, I didn’t have much solution for this problem, but I’m work on that. The simplest solution is
to create an agent regulator driver to do the first ‘regulator_get’, just like Qcom proxy consumer driver.
Or we define a master device of a regulator, only the master device can set the regulator attributes,
other device can only do the enable operation.

Any idea?

(Hope I have cc-ed the people right)

Pingbo

- [1]  https://codeaurora.org/cgit/quic/la/kernel/msm-3.18/tree/drivers/regulator/proxy-consumer.c?h=rel/msm-3.18

Re: [RFC] shared regulator initialization and protection

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2460 bytes --]

On Tue, Apr 12, 2016 at 10:44:11AM +0800, Pingbo Wen wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> Those day, I get some fuzz idea in a proxy-consumer regulator driver
> [1] from Qcom kernel tree. The driver is simple, that let some
> critical regulator, which specified in DT tree, initializing in a
> pre-defined state, and hold a regulator consumer during system boot,
> to provide some protection between multi-consumers.

> And I think this driver is a hint that our upstream code lack of some
> regulator intialization and protection. We already have some regulator

Given how poorly most of the Qualcom code uses the regulator API I'd
take anything they've got out of tree with a pinch of salt.  At best
this looks like a hack for some system specific issues but since it's
just some undocumented code it's hard to tell.

> If a regulator only used by one consumer, current code will work fine.
> But for the regulator which shared between multi-consumers, we can not
> make sure that the regulator will work in a defined-state, during
> system boot, since the device driver can probe in any order, and set
> some conflict attributes.

What is the actual problem here?  Every driver is responsible for
ensuring that regulators are in a good state before it starts using the
hardware, if some other device did something before why do we care?

> Currently, I didn’t have much solution for this problem, but I’m work
> on that. The simplest solution is to create an agent regulator driver
> to do the first ‘regulator_get’, just like Qcom proxy consumer driver.
> Or we define a master device of a regulator, only the master device
> can set the regulator attributes, other device can only do the enable
> operation.

If there are constraints they need to be set in the constraints.  If
drivers need to cooperate then they need to arrange to cooperate
including handling the case where some of them aren't loaded.

Anything based on doing things at initcall levels is fundamentally
broken, as soon as things are built modular like most things in a distro
kernel then it'll stop working.  If the system integrator needs some
devices to start early to provide continuity (the main case here is
display) they need to deal with that at the system integration level.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [RFC] shared regulator initialization and protection

[Pingbo Wen]

Hi, Mark

On Tuesday, April 12, 2016 11:48 AM, Mark Brown wrote:
> On Tue, Apr 12, 2016 at 10:44:11AM +0800, Pingbo Wen wrote:
> 
> Please fix your mail client to word wrap within paragraphs at something
> substantially less than 80 columns.  Doing this makes your messages much
> easier to read and reply to.

Ok, I have re-send another pre-formated email, but you replied to the bad
one. Anyway, sorry for this.

> 
>> Those day, I get some fuzz idea in a proxy-consumer regulator driver
>> [1] from Qcom kernel tree. The driver is simple, that let some
>> critical regulator, which specified in DT tree, initializing in a
>> pre-defined state, and hold a regulator consumer during system boot,
>> to provide some protection between multi-consumers.
> 
>> And I think this driver is a hint that our upstream code lack of some
>> regulator intialization and protection. We already have some regulator
> 
> Given how poorly most of the Qualcom code uses the regulator API I'd
> take anything they've got out of tree with a pinch of salt.  At best
> this looks like a hack for some system specific issues but since it's
> just some undocumented code it's hard to tell.
> 

It's hard to tell how many Qualcom code uses the regulator API, I didn't
do such investigation. Maybe the 'proxy' consumer driver is just a
work-around code, but I don't think it's a reason to prevent us to get
some hints from it.

>> If a regulator only used by one consumer, current code will work fine.
>> But for the regulator which shared between multi-consumers, we can not
>> make sure that the regulator will work in a defined-state, during
>> system boot, since the device driver can probe in any order, and set
>> some conflict attributes.
> 
> What is the actual problem here?  Every driver is responsible for
> ensuring that regulators are in a good state before it starts using the
> hardware, if some other device did something before why do we care?
> 

Yes, I agree the driver should set the regulator before do the real work,
when the device life time is started from driver probing. But if the device
life time is started before Linux kernel loading, the regulator core should
do the regulator initialization and protection to power the device properly,
during kernel booting, until the consumer driver probed.

> 
> Anything based on doing things at initcall levels is fundamentally
> broken, as soon as things are built modular like most things in a distro
> kernel then it'll stop working.  If the system integrator needs some
> devices to start early to provide continuity (the main case here is
> display) they need to deal with that at the system integration level.
> 

Adding a initcall to do the consumer removing is not a decent method.
We can do some hack in regulator_get(), removing agent consumer until
specified device call regulator_get(), or the first regulator_get().

Pingbo

Re: [RFC] shared regulator initialization and protection

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 2041 bytes --]

On Mon, Apr 18, 2016 at 03:26:03PM +0800, Pingbo Wen wrote:
> On Tuesday, April 12, 2016 11:48 AM, Mark Brown wrote:
> > On Tue, Apr 12, 2016 at 10:44:11AM +0800, Pingbo Wen wrote:

> > What is the actual problem here?  Every driver is responsible for
> > ensuring that regulators are in a good state before it starts using the
> > hardware, if some other device did something before why do we care?

> Yes, I agree the driver should set the regulator before do the real work,
> when the device life time is started from driver probing. But if the device
> life time is started before Linux kernel loading, the regulator core should
> do the regulator initialization and protection to power the device properly,
> during kernel booting, until the consumer driver probed.

We can't guarantee that a consumer for a device will ever load in any
reasonable time.  There may be no driver, the driver may have hit some
other problem, the driver may not have been built or may have been built
but placed on inaccessible media.  It's fundamentally an unresolvable
problem outside of specific system integration, we have no way of
telling at what point to give up on something appearing.  The closest
we've got is initcalls but they are before modules get loaded so mean
things break as soon as they're built modular.

> > Anything based on doing things at initcall levels is fundamentally
> > broken, as soon as things are built modular like most things in a distro
> > kernel then it'll stop working.  If the system integrator needs some
> > devices to start early to provide continuity (the main case here is
> > display) they need to deal with that at the system integration level.

> Adding a initcall to do the consumer removing is not a decent method.
> We can do some hack in regulator_get(), removing agent consumer until
> specified device call regulator_get(), or the first regulator_get().

Then what happens if that driver never loads?  The other consumers are
stuck being unable to control the regulator indefinitely which isn't
great.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]