On Wed, Dec 30, 2015 at 07:37:19PM +0100, Paul Kocialkowski wrote: > Le mercredi 30 décembre 2015 à 16:33 +0000, Mark Brown a écrit : > > On Wed, Dec 30, 2015 at 09:35:21AM +0100, Paul Kocialkowski wrote: > > > In my opinion, it would be more elegant to adapt the core regulator > > > framework to first enable the GPIO and then call the regulator enable > > > ops callback instead of handling the GPIO in the driver. > > Why would we want to actively manage both things at runtime? It's more > > work, what do we gain from it? > Well, I figured that it would be best to disable the EN pin when we're > not using any of the regulators, since that allows the chip to enter > standby mode (and thus consume less power). This doesn't sound like it's anything to do with the regulators, that's a chip wide power management function which should be implemented via runtime PM if there's any value in implementing it at all (if the device is a primary PMIC normally this would be handled by the CPU core when it enters low power state without any software). It's not something we should be considering on a per regulator basis since it's at the chip level and on a per regulator basis it's not doing anything useful for the reasons above. > It also doesn't hurt regulators that only use a GPIO for enable. It causes problems for any device with an optional GPIO, it means that we end up mantaining both GPIO and register which as I've said a couple of times now defeats the point of having the GPIO.
Attachment:
signature.asc
Description: PGP signature
