Hi, On Fri, Mar 25, 2016 at 03:54:19PM +0000, Mark Brown wrote: > On Fri, Mar 25, 2016 at 04:02:59PM +0100, Sebastian Reichel wrote: > > On Fri, Mar 25, 2016 at 11:17:57AM +0000, Mark Brown wrote: > > > On Wed, Mar 23, 2016 at 09:22:36PM +0200, Ivaylo Dimitrov wrote: > > > > > Assigning a device group to a regulator does not change its state. To > > > > change the state of a regulator a message over the powerbus is required. > > > > Also, the check for the current state of a regulator should not count on > > > > a device group being assigned, but on the current resource state. > > > > How did this driver ever work then? It sounds like there must be > > > something else going on here. > > > From my understanding of the twl4030 TRM assigning a device group > > means "<device group> wants this regulator enabled". It does not > > change the regulator mode (sleep vs normal or in regulator-framework > > terms: REGULATOR_STATUS_NORMAL vs REGULATOR_STATUS_STANDBY). > > > It usually works, since the default state is normal. If the system > > is rebooted from a non-mainline kernel, which left the regulator in > > sleep/standby, nothing in the kernel switches it to normal. > > I really can't tell how anyone could get from the changelog to what > you're saying about modes. The explanation needs to be *much* clearer. > > Part of the confusion is that if you're trying to do something to do > with the mode support that really needs to use the mode APIs, enabling > or disabling the regulator should not silently change the mode.
I just tried to describe what's going on, so that you can see the whole picture. I don't agree with the patch and think that the mode should be switched to normal at probe time. I assumed, that you would suggest the correct solution if I describe the problem. -- Sebastian
signature.asc
Description: PGP signature
