On Mon, Nov 14, 2016 at 02:18:49PM +0200, Laurent Pinchart wrote: > On Wednesday 26 Oct 2016 12:51:49 Mark Brown wrote: > > Why would this be guaranteed by the API given that it's not documented > > and why would many drivers break? It's fairly rare for devices other > > than SoCs to have strict power on sequencing requirements as it is hard > > to achieve in practical systems. > Is there a reason why the API shouldn't guarantee that regulators are powered > on in the order listed, and powered off in the reverse order ? Looking at the If it ever even did that through implementation it's not been true for a very long time - it does the regulator enables in parallel in order to reduce the overall time to power things up. I keep wanting to come up with code to figure out if we're using multiple enable bits in a single register and hit them all at once though it's likely to be more trouble than it's worth. > implementation that's already the case for regulator_bulk_disable(), but > regulator_bulk_enable() uses async scheduling so doesn't guarantee ordering. I > wonder whether a synchronous version of regulator_bulk_enable() would be > useful. *Possibly* but I'd be surprised to learn that there's a substantial amount of hardware out there that cares given that a power on reset circuit isn't exactly complex to implement. You do sometimes see a global rail that should come up first (especially if there is an integrated regulator) but I've not seen many cases where the hardware cared outside of SoCs.
Attachment:
signature.asc
Description: PGP signature
