Message-ID: <571601E7.2000901@nvidia.com>
Date: Tue, 19 Apr 2016 15:31:11 +0530
From: Laxman Dewangan <ldewangan@nvidia.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
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
References: <20160331185945.GT2350@sirena.org.uk> <56FD7379.2000307@nvidia.com> <20160331192227.GU2350@sirena.org.uk> <56FD7F07.7010404@nvidia.com> <20160331203942.GV2350@sirena.org.uk> <56FE2009.4020302@nvidia.com> <20160401161121.GZ2350@sirena.org.uk> <570370E5.3070901@nvidia.com> <20160412010226.GO3351@sirena.org.uk> <570CF822.4050002@nvidia.com> <20160413065310.GK14664@sirena.org.uk>
In-Reply-To: <20160413065310.GK14664@sirena.org.uk>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8BIT
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4558
Lines: 95


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.