lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <571601E7.2000901@nvidia.com>
Date:	Tue, 19 Apr 2016 15:31:11 +0530
From:	Laxman Dewangan <ldewangan@...dia.com>
To:	Mark Brown <broonie@...nel.org>
CC:	Bjorn Andersson <bjorn@...o.se>,
	Bjorn Andersson <bjorn.andersson@...aro.org>,
	Rob Herring <robh+dt@...nel.org>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Liam Girdwood <lgirdwood@...il.com>,
	"Stephen Warren" <swarren@...dotorg.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Gandhar Dighe <gdighe@...dia.com>,
	"Stuart Yates" <syates@...dia.com>
Subject: 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.





Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ