On Thu, 2019-10-10 at 16:36 +0100, Mark Brown wrote: > > On Thu, Oct 10, 2019 at 03:05:24PM +0000, Sa, Nuno wrote: > > On Thu, 2019-10-10 at 15:05 +0100, Mark Brown wrote: > > > You could use regulator_bulk_enable() here (and similarly on > > > disable) but it doesn't fundamentally matter - they do guarantee > > > that they'll do things in sequence, though they don't wait for > > > the ramp to complete before kicking off the next enable in the > > > sequence which can be an issue for some hardware. > > Yes, regulator_bulk_enable() could fit. The only thing that worries > > me > > is that we only check for errors returned from regulator_enable() > > after > > all async work is done (which is probably what you mean by "they > > don't > > wait for the ramp to complete before kicking off the next > > enable...") > > which could leave us with DVDD applied without IOVDD for a short > > amount > > of time. I'm not sure this would be a really issue and that would > > damage the HW, but from what I can tell from the datasheet, It's > > not > > advised to apply DVDD without IOVDD. > > Yeah, exactly. OTOH things like that (especially for brief time > periods) are much more likely to result in the chip being in some > weird state on init which won't matter if we immediately power > off than anything else. Like I say it's not a requirement to use > bulk operations. Yeah, that's probably right. I can also do some internal querying to understand if this could really damage the part. If not and since I have to prepare a v4 either way (for dt bindings), I will use regulator_bulk_enable(). Nuno Sá
