devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Laxman Dewangan <ldewangan@nvidia.com>
To: Mark Brown <broonie@kernel.org>
Cc: Bjorn Andersson <bjorn@kryo.se>,
	Bjorn Andersson <bjorn.andersson@linaro.org>,
	Rob Herring <robh+dt@kernel.org>, Pawel Moll <pawel.moll@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Stephen Warren <swarren@wwwdotorg.org>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Gandhar Dighe <gdighe@nvidia.com>,
	Stuart Yates <syates@nvidia.com>
Subject: Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior
Date: Tue, 19 Apr 2016 15:31:11 +0530	[thread overview]
Message-ID: <571601E7.2000901@nvidia.com> (raw)
In-Reply-To: <20160413065310.GK14664@sirena.org.uk>


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.

  reply	other threads:[~2016-04-19 10:01 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29 14:40 [PATCH 1/2] regulator: DT: Add support to scale ramp delay based on platform behavior Laxman Dewangan
     [not found] ` <1456756829-2277-1-git-send-email-ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-02-29 14:40   ` [PATCH 2/2] regulator: " Laxman Dewangan
2016-02-29 17:47   ` [PATCH 1/2] regulator: DT: " Bjorn Andersson
2016-03-01  2:23     ` Mark Brown
     [not found]       ` <20160301022326.GC18327-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-01  3:48         ` Laxman Dewangan
     [not found]           ` <56D5111E.6090606-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-02  3:38             ` Mark Brown
2016-03-02  3:35               ` Laxman Dewangan
     [not found]                 ` <56D65F7E.3090907-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-02  4:35                   ` Mark Brown
2016-03-02  6:12                     ` Laxman Dewangan
2016-03-15 13:41                     ` Laxman Dewangan
     [not found]                       ` <56E81103.8010903-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-15 14:48                         ` Mark Brown
2016-03-16 11:30                           ` Laxman Dewangan
2016-03-19  4:31                       ` Bjorn Andersson
2016-03-19  8:35                         ` Laxman Dewangan
2016-03-30 13:29                           ` Laxman Dewangan
2016-03-30 18:16                             ` Mark Brown
2016-03-31  7:06                               ` Laxman Dewangan
2016-03-31 16:51                                 ` Mark Brown
     [not found]                                   ` <20160331165145.GF2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-31 17:13                                     ` Laxman Dewangan
     [not found]                                       ` <56FD5A9F.5050001-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-31 17:47                                         ` Mark Brown
     [not found]                                           ` <20160331174741.GO2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-31 17:47                                             ` Laxman Dewangan
2016-03-31 18:31                                               ` Mark Brown
     [not found]                                                 ` <20160331183130.GR2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-31 18:31                                                   ` Laxman Dewangan
2016-03-31 18:45                                                     ` Mark Brown
     [not found]                                                       ` <20160331184553.GS2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-31 18:39                                                         ` Laxman Dewangan
2016-03-31 18:59                                                           ` Mark Brown
     [not found]                                                             ` <20160331185945.GT2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-03-31 18:59                                                               ` Laxman Dewangan
2016-03-31 19:22                                                                 ` Mark Brown
2016-03-31 19:48                                                                   ` Laxman Dewangan
     [not found]                                                                     ` <56FD7F07.7010404-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-03-31 20:39                                                                       ` Mark Brown
     [not found]                                                                         ` <20160331203942.GV2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-04-01  7:15                                                                           ` Laxman Dewangan
2016-04-01 16:11                                                                             ` Mark Brown
     [not found]                                                                               ` <20160401161121.GZ2350-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-04-05  8:01                                                                                 ` Laxman Dewangan
     [not found]                                                                                   ` <570370E5.3070901-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-04-12  1:02                                                                                     ` Mark Brown
2016-04-12 13:29                                                                                       ` Laxman Dewangan
     [not found]                                                                                         ` <570CF822.4050002-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2016-04-13  6:53                                                                                           ` Mark Brown
2016-04-19 10:01                                                                                             ` Laxman Dewangan [this message]
2016-04-19 10:55                                                                                               ` Mark Brown
     [not found]                                                                                                 ` <20160419105545.GT3217-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2016-04-19 10:56                                                                                                   ` Laxman Dewangan
2016-04-19 15:47                                                                                                     ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=571601E7.2000901@nvidia.com \
    --to=ldewangan@nvidia.com \
    --cc=bjorn.andersson@linaro.org \
    --cc=bjorn@kryo.se \
    --cc=broonie@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=gdighe@nvidia.com \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=pawel.moll@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=swarren@wwwdotorg.org \
    --cc=syates@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).