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.
signature.asc
Description: PGP signature
