Regulator enable/disable delay based on board design: How to handle?

Regulator enable/disable delay based on board design: How to handle?

[Laxman Dewangan]

Hi Mark,
We observed that some of the rail enable/disable settling time depends 
on the board design specially based on external capacitor connected on
rails.  This is observed mainly on VBUS regulator rail where difference 
on the capacitance value which is connected on rail makes the on/off
time to vary.
Currently none of regulator driver support such board related delay.
My question is:

- Should we add board delay as part of platform data for regulator and 
handle in regulator driver? Or,
- Push this delay parameter to respective client driver and let them to 
handle. Not a good idea as it is mainly related to rail on/off. Or,
- Should we add one more parameter in regulator_init_data as rail_delay 
and push this change to core driver of regulator i.e. if it is non-zero 
then take this value from this field otherwise take from <xxx>-regulator 
driver?


I can also work towards If there is any other good options and 
acceptable to linux community.

Thanks,
Laxman

Re: Regulator enable/disable delay based on board design: How to handle?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Mon, Feb 13, 2012 at 02:48:18PM +0530, Laxman Dewangan wrote:

> We observed that some of the rail enable/disable settling time
> depends on the board design specially based on external capacitor
> connected on
> rails.  This is observed mainly on VBUS regulator rail where
> difference on the capacitance value which is connected on rail makes
> the on/off
> time to vary.

Usually this would be handled via regulator driver platform data as the
regulator will typically be designed with particular external components
in mind and (especially in the case of DCDC convertors) may need to be
configured differently depending on the choice of passive components.
Many regulators also have some software control for the ramp rate,
mainly intended to limit inrush currents on system startup, which can be
varied at runtime if desired.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Regulator enable/disable delay based on board design: How to handle?

[Laxman Dewangan]

On Monday 13 February 2012 10:07 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Mon, Feb 13, 2012 at 02:48:18PM +0530, Laxman Dewangan wrote:
>
>> We observed that some of the rail enable/disable settling time
>> depends on the board design specially based on external capacitor
>> connected on
>> rails.  This is observed mainly on VBUS regulator rail where
>> difference on the capacitance value which is connected on rail makes
>> the on/off
>> time to vary.
> Usually this would be handled via regulator driver platform data as the
> regulator will typically be designed with particular external components
> in mind and (especially in the case of DCDC convertors) may need to be
> configured differently depending on the choice of passive components.
> Many regulators also have some software control for the ramp rate,
> mainly intended to limit inrush currents on system startup, which can be
> varied at runtime if desired.
>

Interesting, Many regulator driver is written like it just take the 
regulator_init_data as the platform data and does not leave any option 
to add any new platform parameters.
Not sure how can we add platform data without too much tempering on the 
existing user, but if we can add parameter of delay(settling time) in 
struct regulator_init_data then almost all driver can support such 
platform specific delay.

Re: Regulator enable/disable delay based on board design: How to handle?

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Mon, Feb 13, 2012 at 11:28:00PM +0530, Laxman Dewangan wrote:

> Interesting, Many regulator driver is written like it just take the
> regulator_init_data as the platform data and does not leave any
> option to add any new platform parameters.
> Not sure how can we add platform data without too much tempering on
> the existing user, but if we can add parameter of delay(settling
> time) in struct regulator_init_data then almost all driver can
> support such platform specific delay.

This is part of the reason why the driver_data field is present in the
constraints - the driver can take that and use it as a pdata within
pdata structure.  It's not terribly nice to do that but it's possible.
A standard parameter might cause too much complexity as drivers try to
implement it even if they don't really need to (for example, due to
having soft control of this stuff already).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Regulator enable/disable delay based on board design: How to handle?

[Laxman Dewangan]

On Tuesday 14 February 2012 06:39 AM, Mark Brown wrote:
> This is part of the reason why the driver_data field is present in the
> constraints - the driver can take that and use it as a pdata within
> pdata structure.  It's not terribly nice to do that but it's possible.
Ok, I was thinking that driver data is specific to machine file and 
driver will pass this information to the function regulator_init() at 
the time of call.
But I think it is fine to use this for driver specific data for my case.
Thanks lot for suggestion,
> A standard parameter might cause too much complexity as drivers try to
> implement it even if they don't really need to (for example, due to
> having soft control of this stuff already).

I was thinking that this will be taken care by core if board files 
override the value (non-zero). So if it is zero then just ignore this 
parameters otherwise take this value and ignore what driver is returning.
Hence option will be as per data sheet (what driver is returning) or as 
per board designs (if some more delay is require than specified in 
datasheet).

Thanks,
Laxman