Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1376421 > unrolled thread

[RFC] shared regulator initialization and protection

Started byPingbo Wen <pingbo.wen@linaro.org>
First post2016-04-12 05:00 +0200
Last post2016-04-12 05:00 +0200
Articles 1 — 1 participant

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [RFC] shared regulator initialization and protection Pingbo Wen <pingbo.wen@linaro.org> - 2016-04-12 05:00 +0200

#1376421 — [RFC] shared regulator initialization and protection

FromPingbo Wen <pingbo.wen@linaro.org>
Date2016-04-12 05:00 +0200
Subject[RFC] shared regulator initialization and protection
Message-ID<rmWIy-8cp-13@gated-at.bofh.it>
(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

[toc] | [standalone]


Back to top | Article view | linux.kernel


csiph-web