On Wed, Sep 11, 2013 at 11:59:48AM -0600, Stephen Warren wrote: > On 09/11/2013 12:09 PM, Laxman Dewangan wrote: > >> I suppose that either is fine from a DT perspective. But, the regulator > >> drivers already know their internal delay, so presumably driver code > >> will have to take the value from DT, and subtract out whatever delay the > >> driver already embodies, in order to calculate the extra delay required? > >> Or, if this property is set, does the driver-specified delay just get > >> ignored? > > Yes, if property is available then driver-specified delay get ignored. > > Delay will be used from dt provided value. > I'm not sure whether I prefer one option or the other. Perhaps Mark can > decide? The drivers don't implement their own delays, this is already factored out of them into the framework. It seems simpler from both a user and implementation point of view for the delay specified in the DT to just completely override what the drivers know. > That said, what if the internal ramp rate of the regulator itself is > configurable, and can change at run-time. Won't that affect the total > time? If so, having this property represent the additional time might > better allow the total time to be recalculated based on internal > regulator ramp delay changes. Perhaps the additional time varies if the > internal ramp rate varies though, so perhaps it's not worth thinking > about this situation. There's very little use case for varying the ramp rate from cold at run time - it's mostly just used to limit inrush current on initial power on. I think it's OK to just say that if someone specifies a fixed dleay and varies the ramp rate then they probably aren't being sensible and get to keep all the pieces. > - regulator-enable-ramp-delay: The time taken, in uSec, for the supply microseconds.
Attachment:
signature.asc
Description: Digital signature
