Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1382363 > unrolled thread

Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-04-19 12:20 +0200
    Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-04-19 13:00 +0200
      Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-04-19 13:10 +0200
        Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-04-19 17:50 +0200

#1382363 — Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior

On Wednesday 13 April 2016 12:23 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Tue, Apr 12, 2016 at 06:59:06PM +0530, Laxman Dewangan wrote:
>
>> I have put my understanding based on datasheet and observation but it seems
>> I am missing some important information which is making difficult to
>> understand further here.
>> We are not crossing the maximum limit of the load on the rail per datasheet.
>> We just changed the output capacitor in the platforms and saw deviation.
> Well, we might be hitting an inrush limit as we attempt to ramp the
> voltage up.

Yes, and Maxim said that once this is there, there is no way to 
calculate the actual ramp time. It just say that ramp will not meet the 
advertised value but there is no equation or anything to get the actual 
ramp time. :-(



>
>> I think I need to go again to Vendor to find out that why changing of
>> capacitor making the deviation in ramp delay and what is the relation.
>> Probably, that may help here.
> Possibly.  It did also occur to me last night that having a Maxim
> specific property which lets you specify a raw register value to
> configure in cases where the board goes out of spec (as opposed to a
> time which could be left specified as the real value) might solve the
> problem without being too terrible from an interface point of view,
> though something that's directly obvious from the schematic would be
> much better.

We had discussion with maxim and he pointed us the datasheet for 
descriptions and helped on some query:

/*
Note 20. During a soft-start event or a DVS transition, the regulators 
output current will increase by COUT*dV/dt. In the event that the load 
current plus the additional current imposed by the soft-start or DVS 
transition, reach the regulator’s current limit, the current limit will 
be enforced. When the current limit is enforced, the advertised 
transition rate (dV/dt) will not occur.
---
13.4 Soft-Start and Dynamic Voltage Scaling
The linear regulators have a programmable soft-start rate. When a linear 
regulator is enabled, the output voltage ramps to its final voltage at a 
slew rate of either 5mV/µs or 100mV/µs, depending on the state of the 
SS_Lx bit.
The 5mV/µs ramp rate limits the input inrush current to around 10mA on a 
300mA regulator with a 2.2µF output capacitor and no load. The 100mV/µs 
ramp rate results in a 200mA inrush current on a 300mA regulator with a 
2.2µF output capacitor and no load, but achieves regulation within 50µs. 
The soft-start ramp rate is also the rate of change at the output when 
changing dynamically between two output voltages while enabled (dynamic 
voltage scaling: DVS).
The LDO soft-start circuitry supports starting into a pre-biased output. 
For example, if the output capacitor has an initial voltage of 0.4V when 
the regulator is enabled, the regulator gracefully increases the 
capacitor voltage to the required target voltage such as 1.2V. This is 
unlike other regulators without the start into pre-bias feature where 
they may force the output capacitor voltage to 0V before the soft-start 
ramp begins.
During a soft-start event or a DVS transition, the regulators output 
current will increase by COUT*dV/dt. In the event that the load current 
plus the additional current imposed by the soft-start or DVS transition, 
reach the regulator’s current limit, the current limit will be enforced. 
When the current limit is enforced, the advertised transition rate 
(dV/dt) will not occur.
*/

We have more capacitance on the board and this increases the current at 
power up. If we are within the specs for the LDO current then you will 
notice that Maxim specs are guaranteed. However, Maxim does not 
guarantee the timings in case current exceeds the LDO specs. In this 
case because of the larger capacitances the currents seen by the LDO is 
much more and hence Maxim device enforces current limit. When the 
current limit is enforced then the dv/dt will be different than what is set.

Some more query to help SW interface:
Q: Is there any mechanism where we can derive ramp rate based on maximum 
load or capacitor or inrush current?
Ans: No. Since the LDO imposes the current limit the standard formula 
doesn’t hold correct. That’s the reason Maxim in their datasheet has 
mentioned that the advertised rate will not occur.


So based on this, when platform does not have the advertised ramp, we 
need to have:
Maxim specific property for register configurations and do not allow run 
time changes as this does not hold correctly.

[toc] | [next] | [standalone]

#1382391

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 19, 2016 at 03:31:11PM +0530, Laxman Dewangan wrote:
> On Wednesday 13 April 2016 12:23 PM, Mark Brown wrote:

> >Possibly.  It did also occur to me last night that having a Maxim
> >specific property which lets you specify a raw register value to
> >configure in cases where the board goes out of spec (as opposed to a
> >time which could be left specified as the real value) might solve the
> >problem without being too terrible from an interface point of view,
> >though something that's directly obvious from the schematic would be
> >much better.

You appear to have ignord my suggestion above...

[toc] | [prev] | [next] | [standalone]

#1382398

On Tuesday 19 April 2016 04:25 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Tue, Apr 19, 2016 at 03:31:11PM +0530, Laxman Dewangan wrote:
>> On Wednesday 13 April 2016 12:23 PM, Mark Brown wrote:
>>> Possibly.  It did also occur to me last night that having a Maxim
>>> specific property which lets you specify a raw register value to
>>> configure in cases where the board goes out of spec (as opposed to a
>>> time which could be left specified as the real value) might solve the
>>> problem without being too terrible from an interface point of view,
>>> though something that's directly obvious from the schematic would be
>>> much better.
> You appear to have ignord my suggestion above...
>
>
I was too focused on the getting the info from Maxim on this to get 
something in equation form.
There is no way to get the deviation equation and your suggestion is 
only seems solution for this issue.
Thanks for evaluating/trying at your end and for valuable suggestion.

Now, for property, I will add
  maxim,ramp-delay

This is device specific ramp delay which need to be configure on device 
register. The platform observed delay must be provided via 
regulator-ramp-delay.

I will send the patch on this.

Thanks,
Laxman

[toc] | [prev] | [next] | [standalone]

#1382627

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 19, 2016 at 04:26:27PM +0530, Laxman Dewangan wrote:

> Now, for property, I will add
>  maxim,ramp-delay

Please call it something that makes it obvious that it's a register
value rather than a time like ramp-setting or something.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web