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

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

[Laxman Dewangan]

It is observed that voltage change in given rail affected by the load
and the capacitor in the rail. This may cause the slow ramp in voltage
against what PMIC has programmed.

The property regulator-ramp-delay provides the ramp delay configuration
for PMIC but actual voltage settling time may change based on platform.

Add new property "regulator-ramp-delay-scale" for platform specific scaling
in final ramp delay calculation. On this case, final wait delay time
for voltage change is calculated as the
   DIV_ROUND_UP(ramp_delay * ramp_delay_scale, 100)

The value is provided in the term of percentage i.e. 300% means it will
do the 3x delay of calculated value.

Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 Documentation/devicetree/bindings/regulator/regulator.txt | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
index 1d112fc..f2e8360 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -16,6 +16,13 @@ Optional properties:
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
   For hardware which supports disabling ramp rate, it should be explicitly
   initialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
+- regulator-ramp-delay-scale: Platform specific scaling in ramp delay to
+  provide extra guard time to settle down voltage after its change. This will
+  help to wait for extra time for voltage settling based on platform behavior.
+  This is provided in terms of percentage scaling like 300% means final delay
+  will become 3x of calculated ramp delay for voltage change.
+  The final delay is calculated as:
+	delay = DIV_ROUND_UP(ramp-delay * ramp-delay-scale, 100)
 - regulator-enable-ramp-delay: The time taken, in microseconds, for the supply
   rail to reach the target voltage, plus/minus whatever tolerance the board
   design requires. This property describes the total system ramp time
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Laxman Dewangan]

It is observed that voltage change in given rail affected by the load
and the capacitor in the rail. This may cause the slow ramp in voltage
against what PMIC has programmed.

The machine constraints ramp_delay provides the ramp delay configuration
for PMIC but actual voltage settling time may change based on platform.

Add ramp_delay_scale in the machine constraints for platform specific
scaling for final ramp delay calculation. On this case, final wait
delay time for voltage change is calculated as the
	DIV_ROUND_UP(ramp_delay * ramp_delay_scale, 100)

The value is provided in the term of percentage i.e. 300% means it will
do the 3x delay of calculated value.

Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
---
 drivers/regulator/core.c          | 6 ++++++
 drivers/regulator/of_regulator.c  | 7 +++++++
 include/linux/regulator/machine.h | 7 +++++++
 3 files changed, 20 insertions(+)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 055f8c1..476fe6c 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -2786,6 +2786,12 @@ static int _regulator_do_set_voltage(struct regulator_dev *rdev,
 			delay = 0;
 		}
 
+		if (delay && rdev->constraints &&
+		    rdev->constraints->ramp_delay_scale) {
+			delay *= rdev->constraints->ramp_delay_scale;
+			delay = DIV_ROUND_UP(delay, 100);
+		}
+
 		/* Insert any necessary delays */
 		if (delay >= 1000) {
 			mdelay(delay / 1000);
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 499e437..cd204b1 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -87,6 +87,13 @@ static void of_get_regulation_constraints(struct device_node *np,
 			constraints->ramp_disable = true;
 	}
 
+	if (constraints->ramp_delay) {
+		ret = of_property_read_u32(np, "regulator-ramp-delay-scale",
+					   &pval);
+		if (!ret)
+			constraints->ramp_delay_scale = pval;
+	}
+
 	ret = of_property_read_u32(np, "regulator-enable-ramp-delay", &pval);
 	if (!ret)
 		constraints->enable_time = pval;
diff --git a/include/linux/regulator/machine.h b/include/linux/regulator/machine.h
index a1067d0..5153e5a 100644
--- a/include/linux/regulator/machine.h
+++ b/include/linux/regulator/machine.h
@@ -100,6 +100,12 @@ struct regulator_state {
  * @initial_state: Suspend state to set by default.
  * @initial_mode: Mode to set at startup.
  * @ramp_delay: Time to settle down after voltage change (unit: uV/us)
+ * @ramp_delay_scale: Scaling in ramp delay to provide extra guard time
+ *		      to settle down after voltage change. This is
+ *		      provided in terms of percentage like 200% means
+ *		      2x of calculated ramp delay for given voltage change.
+ *		      The final delay is calucated as:
+			DIV_ROUND_UP(ramp_delay * ramp_delay_scale, 100);
  * @enable_time: Turn-on time of the rails (unit: microseconds)
  */
 struct regulation_constraints {
@@ -139,6 +145,7 @@ struct regulation_constraints {
 
 	unsigned int ramp_delay;
 	unsigned int enable_time;
+	unsigned int ramp_delay_scale;
 
 	/* constraint flags */
 	unsigned always_on:1;	/* regulator never off when system is on */
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Bjorn Andersson]

On Mon 29 Feb 06:40 PST 2016, Laxman Dewangan wrote:

> It is observed that voltage change in given rail affected by the load
> and the capacitor in the rail. This may cause the slow ramp in voltage
> against what PMIC has programmed.
> 
> The property regulator-ramp-delay provides the ramp delay configuration
> for PMIC but actual voltage settling time may change based on platform.
> 
> Add new property "regulator-ramp-delay-scale" for platform specific scaling
> in final ramp delay calculation. On this case, final wait delay time
> for voltage change is calculated as the
>    DIV_ROUND_UP(ramp_delay * ramp_delay_scale, 100)
> 
> The value is provided in the term of percentage i.e. 300% means it will
> do the 3x delay of calculated value.
> 
> Signed-off-by: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> ---

The regulator-ramp-delay is a variable you can tweak on a board basis,
so I'm not sure what benefit it gives to be able to add a scaling
factor to this.

In my experience your HW engineer will say "you have to wait X ms", not
"you have to wait 125% of X ms".


Can you please elaborate on why the original knob isn't sufficient?

Regards,
Bjorn

>  Documentation/devicetree/bindings/regulator/regulator.txt | 7 +++++++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt b/Documentation/devicetree/bindings/regulator/regulator.txt
> index 1d112fc..f2e8360 100644
> --- a/Documentation/devicetree/bindings/regulator/regulator.txt
> +++ b/Documentation/devicetree/bindings/regulator/regulator.txt
> @@ -16,6 +16,13 @@ Optional properties:
>  - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
>    For hardware which supports disabling ramp rate, it should be explicitly
>    initialised to zero (regulator-ramp-delay = <0>) for disabling ramp delay.
> +- regulator-ramp-delay-scale: Platform specific scaling in ramp delay to
> +  provide extra guard time to settle down voltage after its change. This will
> +  help to wait for extra time for voltage settling based on platform behavior.
> +  This is provided in terms of percentage scaling like 300% means final delay
> +  will become 3x of calculated ramp delay for voltage change.
> +  The final delay is calculated as:
> +	delay = DIV_ROUND_UP(ramp-delay * ramp-delay-scale, 100)
>  - regulator-enable-ramp-delay: The time taken, in microseconds, for the supply
>    rail to reach the target voltage, plus/minus whatever tolerance the board
>    design requires. This property describes the total system ramp time
> -- 
> 2.1.4
> 
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

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

On Mon, Feb 29, 2016 at 09:47:51AM -0800, Bjorn Andersson wrote:
> On Mon 29 Feb 06:40 PST 2016, Laxman Dewangan wrote:

> > It is observed that voltage change in given rail affected by the load
> > and the capacitor in the rail. This may cause the slow ramp in voltage
> > against what PMIC has programmed.

> The regulator-ramp-delay is a variable you can tweak on a board basis,
> so I'm not sure what benefit it gives to be able to add a scaling
> factor to this.

> In my experience your HW engineer will say "you have to wait X ms", not
> "you have to wait 125% of X ms".

> Can you please elaborate on why the original knob isn't sufficient?

Right, this definitely feels like the wrong thing is being specified
here (and also like the PMIC might be going out of spec, possibly as a
result of being overloaded) and that the existing board specific
controls should be used.  It just doesn't correspond to the way people
usually talk about specs for PMICs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Tuesday 01 March 2016 07:53 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Mon, Feb 29, 2016 at 09:47:51AM -0800, Bjorn Andersson wrote:
>> On Mon 29 Feb 06:40 PST 2016, Laxman Dewangan wrote:
>>> It is observed that voltage change in given rail affected by the load
>>> and the capacitor in the rail. This may cause the slow ramp in voltage
>>> against what PMIC has programmed.
>> The regulator-ramp-delay is a variable you can tweak on a board basis,
>> so I'm not sure what benefit it gives to be able to add a scaling
>> factor to this.
>> In my experience your HW engineer will say "you have to wait X ms", not
>> "you have to wait 125% of X ms".
>> Can you please elaborate on why the original knob isn't sufficient?
> Right, this definitely feels like the wrong thing is being specified
> here (and also like the PMIC might be going out of spec, possibly as a
> result of being overloaded) and that the existing board specific
> controls should be used.  It just doesn't correspond to the way people
> usually talk about specs for PMICs.
>

Most of PMICs offer to configure the slew rate (ramp time). For 
discussion, I am considering MAX77620 LDOs provides option to 27mV/us 
and 100mV/us.

HW team characterize the board and its rail and come up with the 
following data:
- Configure PMIC to 27mV/us for ramp time.
- With this measured value of ramp on board is 10mV/us and it is safe 
to  assume 5mv/us to consider the board variations.

So we have now two input from HW team:
1. What should be configure in PMIC.
2. And for calculation, how much ramp need to be consider.

For (1), it is 25mV/us and for (2) which 540% (27 *100/5).

Currently, we can provide the 27mv/us as ramp-delay but do not have 
option for scaling it.

My patch add for knob for (2).
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Laxman Dewangan]

On Wednesday 02 March 2016 09:08 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Tue, Mar 01, 2016 at 09:18:46AM +0530, Laxman Dewangan wrote:
>
>> HW team characterize the board and its rail and come up with the following
>> data:
>> - Configure PMIC to 27mV/us for ramp time.
>> - With this measured value of ramp on board is 10mV/us and it is safe to
>> assume 5mv/us to consider the board variations.
>> So we have now two input from HW team:
>> 1. What should be configure in PMIC.
>> 2. And for calculation, how much ramp need to be consider.
>> For (1), it is 25mV/us and for (2) which 540% (27 *100/5).
>> Currently, we can provide the 27mv/us as ramp-delay but do not have option
>> for scaling it.
> You're not trying to scale the value here, you're trying to replace the
> value because the PMIC is incapable of delivering the advertised ramp
> rate.  Trying to express this as a multiple of the advertised ramp rate
> is just adding complexity.
>
So should we provide absolute ramp value here for platform specific?
Or any other suggestion to handle this situation as this is very common 
and almost all our boards have this slowness on ramp.

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

[Mark Brown]

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

On Tue, Mar 01, 2016 at 09:18:46AM +0530, Laxman Dewangan wrote:

> HW team characterize the board and its rail and come up with the following
> data:
> - Configure PMIC to 27mV/us for ramp time.
> - With this measured value of ramp on board is 10mV/us and it is safe to
> assume 5mv/us to consider the board variations.

> So we have now two input from HW team:
> 1. What should be configure in PMIC.
> 2. And for calculation, how much ramp need to be consider.

> For (1), it is 25mV/us and for (2) which 540% (27 *100/5).

> Currently, we can provide the 27mv/us as ramp-delay but do not have option
> for scaling it.

You're not trying to scale the value here, you're trying to replace the
value because the PMIC is incapable of delivering the advertised ramp
rate.  Trying to express this as a multiple of the advertised ramp rate
is just adding complexity.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Mark Brown]

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

On Wed, Mar 02, 2016 at 09:05:26AM +0530, Laxman Dewangan wrote:
> On Wednesday 02 March 2016 09:08 AM, Mark Brown wrote:

> >You're not trying to scale the value here, you're trying to replace the
> >value because the PMIC is incapable of delivering the advertised ramp
> >rate.  Trying to express this as a multiple of the advertised ramp rate
> >is just adding complexity.

> So should we provide absolute ramp value here for platform specific?

Yes, otherwise if the PMIC vendor respecifies their ramp rates to
reflect reality and the driver is updated then your DT will be broken.

> Or any other suggestion to handle this situation as this is very common and
> almost all our boards have this slowness on ramp.

Perhaps time to have a chat with your PMIC vendors...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Wednesday 02 March 2016 10:05 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Wed, Mar 02, 2016 at 09:05:26AM +0530, Laxman Dewangan wrote:
>> On Wednesday 02 March 2016 09:08 AM, Mark Brown wrote:
>>> You're not trying to scale the value here, you're trying to replace the
>>> value because the PMIC is incapable of delivering the advertised ramp
>>> rate.  Trying to express this as a multiple of the advertised ramp rate
>>> is just adding complexity.
>> So should we provide absolute ramp value here for platform specific?
> Yes, otherwise if the PMIC vendor respecifies their ramp rates to
> reflect reality and the driver is updated then your DT will be broken.

Then can we have other member for pmic ramp time register configuration 
via DT.
So measured value on platform will be existing ramp-delay and the value 
which will be configured in PMIC will be via pmic-ramp-delay if provided 
otherwise use ramp-delay.

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

[Laxman Dewangan]

On Wednesday 02 March 2016 10:05 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Wed, Mar 02, 2016 at 09:05:26AM +0530, Laxman Dewangan wrote:
>> On Wednesday 02 March 2016 09:08 AM, Mark Brown wrote:
>>> You're not trying to scale the value here, you're trying to replace the
>>> value because the PMIC is incapable of delivering the advertised ramp
>>> rate.  Trying to express this as a multiple of the advertised ramp rate
>>> is just adding complexity.
>> So should we provide absolute ramp value here for platform specific?
> Yes, otherwise if the PMIC vendor respecifies their ramp rates to
> reflect reality and the driver is updated then your DT will be broken.
>
>> Or any other suggestion to handle this situation as this is very common and
>> almost all our boards have this slowness on ramp.
> Perhaps time to have a chat with your PMIC vendors...
>

I had discussion with our HW team to get more information about this 
variation.
They said that Maxim advertise the ramp time with given condition in 
interface i.e. capacitance etc which is very generic.
We did the experiment with Maxim recommendation about the rail and its 
capacitance (2.2uF) and found that measured value is same as what they 
advertise in datasheet.

When chip team use this PMIC with Tegra hardware specs and did the 
circuit simulation to ensures how our boards should be designed for 
signal integrity they suggested that the rail capacitance should be more 
than what Maxim recommending in general to work with our silicon. So 
here condition get changed and hence the effective ramp time.

So here we will need two parameters:
advertised-ramp-delay for PMIC configurations and
ramp-delay which is measured one.

Most of time, advertised-ramp-delay is same as ramp-delay and hence one 
value from DT will be sufficient.
If there is difference then both value can be provided and 
advertised-ramp-delay  will be used for PMIC configuration and rest of 
calculation about delay will be from ramp-delay.

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

[Mark Brown]

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

On Tue, Mar 15, 2016 at 07:11:23PM +0530, Laxman Dewangan wrote:

> So here we will need two parameters:
> advertised-ramp-delay for PMIC configurations and
> ramp-delay which is measured one.

> Most of time, advertised-ramp-delay is same as ramp-delay and hence one
> value from DT will be sufficient.
> If there is difference then both value can be provided and
> advertised-ramp-delay  will be used for PMIC configuration and rest of
> calculation about delay will be from ramp-delay.

This sounds more like the difference between typical and maximum spec
values than anything else, we are looking for maxima in Linux.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Tuesday 15 March 2016 08:18 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Tue, Mar 15, 2016 at 07:11:23PM +0530, Laxman Dewangan wrote:
>
>> So here we will need two parameters:
>> advertised-ramp-delay for PMIC configurations and
>> ramp-delay which is measured one.
>> Most of time, advertised-ramp-delay is same as ramp-delay and hence one
>> value from DT will be sufficient.
>> If there is difference then both value can be provided and
>> advertised-ramp-delay  will be used for PMIC configuration and rest of
>> calculation about delay will be from ramp-delay.
> This sounds more like the difference between typical and maximum spec
> values than anything else, we are looking for maxima in Linux.
>

Maxim datasheet does not say about the typical/maximum. It has only one 
value and that is typical.
However, it has note on the advertised values as:

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.

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

[Bjorn Andersson]

On Tue, Mar 15, 2016 at 6:41 AM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
>
> On Wednesday 02 March 2016 10:05 AM, Mark Brown wrote:
>>
>> * PGP Signed by an unknown key
>>
>> On Wed, Mar 02, 2016 at 09:05:26AM +0530, Laxman Dewangan wrote:
>>>
>>> On Wednesday 02 March 2016 09:08 AM, Mark Brown wrote:
>>>>
>>>> You're not trying to scale the value here, you're trying to replace the
>>>> value because the PMIC is incapable of delivering the advertised ramp
>>>> rate.  Trying to express this as a multiple of the advertised ramp rate
>>>> is just adding complexity.
>>>
>>> So should we provide absolute ramp value here for platform specific?
>>
>> Yes, otherwise if the PMIC vendor respecifies their ramp rates to
>> reflect reality and the driver is updated then your DT will be broken.
>>
>>> Or any other suggestion to handle this situation as this is very common
>>> and
>>> almost all our boards have this slowness on ramp.
>>
>> Perhaps time to have a chat with your PMIC vendors...
>>
>
> I had discussion with our HW team to get more information about this
> variation.
> They said that Maxim advertise the ramp time with given condition in
> interface i.e. capacitance etc which is very generic.
> We did the experiment with Maxim recommendation about the rail and its
> capacitance (2.2uF) and found that measured value is same as what they
> advertise in datasheet.
>
> When chip team use this PMIC with Tegra hardware specs and did the circuit
> simulation to ensures how our boards should be designed for signal integrity
> they suggested that the rail capacitance should be more than what Maxim
> recommending in general to work with our silicon. So here condition get
> changed and hence the effective ramp time.
>
> So here we will need two parameters:
> advertised-ramp-delay for PMIC configurations and
> ramp-delay which is measured one.
>
> Most of time, advertised-ramp-delay is same as ramp-delay and hence one
> value from DT will be sufficient.
> If there is difference then both value can be provided and
> advertised-ramp-delay  will be used for PMIC configuration and rest of
> calculation about delay will be from ramp-delay.
>

Generally the device driver should describe the PMIC and the device
tree should describe the board. So the Maxim's numbers should (if
specified at all) go into the driver and the measures/calculated
characteristics for your board should be specified in the dt.

The ramp properties in the generic regulator binding is used to inform
the OS about the board's ramp properties.


If I understand you correctly the Maxim PMIC can be configured to
drive the change at different speed, this should be configured through
a Maxim specific property. It should not reuse the generic properties
for ramp delays.

Regards,
Bjorn

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

[Laxman Dewangan]

On Saturday 19 March 2016 10:01 AM, Bjorn Andersson wrote:
> On Tue, Mar 15, 2016 at 6:41 AM, Laxman Dewangan <ldewangan@nvidia.com> wrote:
>> On Wednesday 02 March 2016 10:05 AM, Mark Brown wrote:
>>> * PGP Signed by an unknown key
>>>
>>> On Wed, Mar 02, 2016 at 09:05:26AM +0530, Laxman Dewangan wrote:
>>>> On Wednesday 02 March 2016 09:08 AM, Mark Brown wrote:
>>>>> You're not trying to scale the value here, you're trying to replace the
>>>>> value because the PMIC is incapable of delivering the advertised ramp
>>>>> rate.  Trying to express this as a multiple of the advertised ramp rate
>>>>> is just adding complexity.
>>>> So should we provide absolute ramp value here for platform specific?
>>> Yes, otherwise if the PMIC vendor respecifies their ramp rates to
>>> reflect reality and the driver is updated then your DT will be broken.
>>>
>>>> Or any other suggestion to handle this situation as this is very common
>>>> and
>>>> almost all our boards have this slowness on ramp.
>>> Perhaps time to have a chat with your PMIC vendors...
>>>
>> I had discussion with our HW team to get more information about this
>> variation.
>> They said that Maxim advertise the ramp time with given condition in
>> interface i.e. capacitance etc which is very generic.
>> We did the experiment with Maxim recommendation about the rail and its
>> capacitance (2.2uF) and found that measured value is same as what they
>> advertise in datasheet.
>>
>> When chip team use this PMIC with Tegra hardware specs and did the circuit
>> simulation to ensures how our boards should be designed for signal integrity
>> they suggested that the rail capacitance should be more than what Maxim
>> recommending in general to work with our silicon. So here condition get
>> changed and hence the effective ramp time.
>>
>> So here we will need two parameters:
>> advertised-ramp-delay for PMIC configurations and
>> ramp-delay which is measured one.
>>
>> Most of time, advertised-ramp-delay is same as ramp-delay and hence one
>> value from DT will be sufficient.
>> If there is difference then both value can be provided and
>> advertised-ramp-delay  will be used for PMIC configuration and rest of
>> calculation about delay will be from ramp-delay.
>>
> Generally the device driver should describe the PMIC and the device
> tree should describe the board. So the Maxim's numbers should (if
> specified at all) go into the driver and the measures/calculated
> characteristics for your board should be specified in the dt.
>
> The ramp properties in the generic regulator binding is used to inform
> the OS about the board's ramp properties.
>
>
> If I understand you correctly the Maxim PMIC can be configured to
> drive the change at different speed, this should be configured through
> a Maxim specific property. It should not reuse the generic properties
> for ramp delays.
>

Ramp delay configurations are seen on other vendor's PMIC devices also.
Therefore, I like o me generic property rather than specific to Maxim. 
Parsing can be done in the core framework and applied during setting 
machine constraints.

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

[Laxman Dewangan]

On Saturday 19 March 2016 02:05 PM, Laxman Dewangan wrote:
>
> On Saturday 19 March 2016 10:01 AM, Bjorn Andersson wrote:
>> On Tue, Mar 15, 2016 at 6:41 AM, Laxman Dewangan 
>> <ldewangan@nvidia.com> wrote:
>>>
>>>
>> Generally the device driver should describe the PMIC and the device
>> tree should describe the board. So the Maxim's numbers should (if
>> specified at all) go into the driver and the measures/calculated
>> characteristics for your board should be specified in the dt.
>>
>> The ramp properties in the generic regulator binding is used to inform
>> the OS about the board's ramp properties.
>>
>>
>> If I understand you correctly the Maxim PMIC can be configured to
>> drive the change at different speed, this should be configured through
>> a Maxim specific property. It should not reuse the generic properties
>> for ramp delays.
>>
>
> Ramp delay configurations are seen on other vendor's PMIC devices also.
> Therefore, I like o me generic property rather than specific to Maxim. 
> Parsing can be done in the core framework and applied during setting 
> machine constraints.

Any comment on this approach?

Like to add property as "regulator-device-ramp-delay" which will be used 
for PMIC configuration and regulator-ramp-delay will be used for delay 
calculation. This is case when advertised ramp delay does not match with 
the platform measured ramp delay.

If regulator-device-ramp-delay is not provided from platform then 
regulator-ramp-delay will be used for PMIC configuration as well as for 
the delay calculation. This is case when advertised ramp delay match 
with the platform measured ramp delay.

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

[Mark Brown]

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

On Wed, Mar 30, 2016 at 06:59:07PM +0530, Laxman Dewangan wrote:

> Like to add property as "regulator-device-ramp-delay" which will be used for
> PMIC configuration and regulator-ramp-delay will be used for delay
> calculation. This is case when advertised ramp delay does not match with the
> platform measured ramp delay.

Why -device?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Wednesday 30 March 2016 11:46 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Wed, Mar 30, 2016 at 06:59:07PM +0530, Laxman Dewangan wrote:
>
>> Like to add property as "regulator-device-ramp-delay" which will be used for
>> PMIC configuration and regulator-ramp-delay will be used for delay
>> calculation. This is case when advertised ramp delay does not match with the
>> platform measured ramp delay.
> Why -device?
>
This is device specific and just to differentiate with 
regulator-ramp-delay which is the platform specific.
May be there is some other good name. I can think of other name as 
regulator-typical-ramp-delay, regulator-advertised-ramp-delay etc.

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

[Mark Brown]

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

On Thu, Mar 31, 2016 at 12:36:08PM +0530, Laxman Dewangan wrote:
> On Wednesday 30 March 2016 11:46 PM, Mark Brown wrote:

> >>Like to add property as "regulator-device-ramp-delay" which will be used for
> >>PMIC configuration and regulator-ramp-delay will be used for delay
> >>calculation. This is case when advertised ramp delay does not match with the
> >>platform measured ramp delay.

> >Why -device?

> This is device specific and just to differentiate with regulator-ramp-delay
> which is the platform specific.
> May be there is some other good name. I can think of other name as
> regulator-typical-ramp-delay, regulator-advertised-ramp-delay etc.

So there's already a property you want to set, why are you not trying to
set that property?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Thursday 31 March 2016 10:21 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Thu, Mar 31, 2016 at 12:36:08PM +0530, Laxman Dewangan wrote:
>> On Wednesday 30 March 2016 11:46 PM, Mark Brown wrote:
>>>> Like to add property as "regulator-device-ramp-delay" which will be used for
>>>> PMIC configuration and regulator-ramp-delay will be used for delay
>>>> calculation. This is case when advertised ramp delay does not match with the
>>>> platform measured ramp delay.
>>> Why -device?
>> This is device specific and just to differentiate with regulator-ramp-delay
>> which is the platform specific.
>> May be there is some other good name. I can think of other name as
>> regulator-typical-ramp-delay, regulator-advertised-ramp-delay etc.
> So there's already a property you want to set, why are you not trying to
> set that property?

We need two properties, one what we measured in platform and second one 
for what we want to program PMIC. This is for the case where vendor 
advertised ramp delay is not same as measured due to platform design.
Based on discussion, regulator-ramp-delay is for measured ramp delay in 
platform. So we will need another property for configuring PMIC.


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Laxman Dewangan]

On Thursday 31 March 2016 11:17 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Thu, Mar 31, 2016 at 10:43:03PM +0530, Laxman Dewangan wrote:
>
>> We need two properties, one what we measured in platform and second one for
>> what we want to program PMIC. This is for the case where vendor advertised
>> ramp delay is not same as measured due to platform design.
> What makes you say that we need two properties?
>
>> Based on discussion, regulator-ramp-delay is for measured ramp delay in
>> platform. So we will need another property for configuring PMIC.
> So as well as delaying in the kernel to cover the ramp time you want to
> configure something in the PMIC?  What are you trying to configure in
> the PMIC?  How will the PMIC driver meaningfully interpret a generic
> property given that the whole point here is that the PMIC is unable to
> deliver in spec behaviour?
>

Here is the case,
PMIC supports 2 ramp time configurations 5mv/us and 100mV/us. This is 
supported with some specific capacitance in rail output per 
recommendation from PMIC Vendor. This recommendation is generic in nature.
We got PMIC with some non-desired default configuration i.e. 5mV/us. Our 
HW team recommend to configure the PMIC for 100mV/us.

HW and chip team did simulation with tegra and PMIC and found that the 
board needs more capacitance then what Vendor recommended for proper 
signal conditioning on interface. So they put the difference 
capactitance value and this causes deviation in ramp delay from 
advertised value. In out design, we measured the ramp time as 50mv/us 
when PMIC is configured for 100mV/us.

So for all settling time, we need to use the ramp as 50mV/us.

 From DT, I will provide regulator-ramp-delay as 50mv/us.

But I do not have property for saying 100mv/us for PMIC configurations 
and this is what makes need of 2nd property.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

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

On Thu, Mar 31, 2016 at 10:43:03PM +0530, Laxman Dewangan wrote:

> We need two properties, one what we measured in platform and second one for
> what we want to program PMIC. This is for the case where vendor advertised
> ramp delay is not same as measured due to platform design.

What makes you say that we need two properties?  

> Based on discussion, regulator-ramp-delay is for measured ramp delay in
> platform. So we will need another property for configuring PMIC.

So as well as delaying in the kernel to cover the ramp time you want to
configure something in the PMIC?  What are you trying to configure in
the PMIC?  How will the PMIC driver meaningfully interpret a generic
property given that the whole point here is that the PMIC is unable to
deliver in spec behaviour?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Friday 01 April 2016 12:01 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Thu, Mar 31, 2016 at 11:17:38PM +0530, Laxman Dewangan wrote:
>
>> HW and chip team did simulation with tegra and PMIC and found that the board
>> needs more capacitance then what Vendor recommended for proper signal
>> conditioning on interface. So they put the difference capactitance value and
>> this causes deviation in ramp delay from advertised value. In out design, we
>> measured the ramp time as 50mv/us when PMIC is configured for 100mV/us.
>> So for all settling time, we need to use the ramp as 50mV/us.
>>  From DT, I will provide regulator-ramp-delay as 50mv/us.
>> But I do not have property for saying 100mv/us for PMIC configurations and
>> this is what makes need of 2nd property.
> So the PMIC actually has a setting for the rate you're seeing but for
> some resaon you can't use it?

PMIC has the different rate setting what I am seeing on platform (measured).
HW team measured the ramp dealy with specific configuration of rate 
setting on PMIC which is not default (OTP-One time programmed from Vendor).

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

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

On Thu, Mar 31, 2016 at 11:17:38PM +0530, Laxman Dewangan wrote:

> HW and chip team did simulation with tegra and PMIC and found that the board
> needs more capacitance then what Vendor recommended for proper signal
> conditioning on interface. So they put the difference capactitance value and
> this causes deviation in ramp delay from advertised value. In out design, we
> measured the ramp time as 50mv/us when PMIC is configured for 100mV/us.

> So for all settling time, we need to use the ramp as 50mV/us.

> From DT, I will provide regulator-ramp-delay as 50mv/us.

> But I do not have property for saying 100mv/us for PMIC configurations and
> this is what makes need of 2nd property.

So the PMIC actually has a setting for the rate you're seeing but for
some resaon you can't use it?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Friday 01 April 2016 12:15 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Fri, Apr 01, 2016 at 12:01:19AM +0530, Laxman Dewangan wrote:
>> On Friday 01 April 2016 12:01 AM, Mark Brown wrote:
>>> So the PMIC actually has a setting for the rate you're seeing but for
>>> some resaon you can't use it?
>> PMIC has the different rate setting what I am seeing on platform (measured).
>> HW team measured the ramp dealy with specific configuration of rate setting
>> on PMIC which is not default (OTP-One time programmed from Vendor).
> That doesn't tell me what happens if you just configure the device to
> deliver the rate you're observing...

The setting for observed value is not there for device configuration.

Device support 5mV/us and 100mV/us.

We observed 50mV/us when setting device to 100mV/us.


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

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

On Fri, Apr 01, 2016 at 12:01:19AM +0530, Laxman Dewangan wrote:
> On Friday 01 April 2016 12:01 AM, Mark Brown wrote:

> >So the PMIC actually has a setting for the rate you're seeing but for
> >some resaon you can't use it?

> PMIC has the different rate setting what I am seeing on platform (measured).
> HW team measured the ramp dealy with specific configuration of rate setting
> on PMIC which is not default (OTP-One time programmed from Vendor).

That doesn't tell me what happens if you just configure the device to
deliver the rate you're observing...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Friday 01 April 2016 12:29 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Fri, Apr 01, 2016 at 12:09:18AM +0530, Laxman Dewangan wrote:
>
>> The setting for observed value is not there for device configuration.
>> Device support 5mV/us and 100mV/us.
>> We observed 50mV/us when setting device to 100mV/us.
> But you said the device had a configuration for 50mV/us?
I looked for last 4 communication and tried to find out if any typo on 
mail so that I can correct but did not found.

/**
Here is the case,
PMIC supports 2 ramp time configurations 5mv/us and 100mV/us. This is 
supported with some specific capacitance in rail output per 
recommendation from PMIC
**/

So may be more older may have..

But here is the stuff without typo ;-)
Device supports 5mV/us and 100mV/us which is not in observed value.

And this is the only reason for requesting of second property.


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

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

On Fri, Apr 01, 2016 at 12:09:18AM +0530, Laxman Dewangan wrote:

> The setting for observed value is not there for device configuration.

> Device support 5mV/us and 100mV/us.

> We observed 50mV/us when setting device to 100mV/us.

But you said the device had a configuration for 50mV/us?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Mark Brown]

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

On Fri, Apr 01, 2016 at 12:29:05AM +0530, Laxman Dewangan wrote:
> On Friday 01 April 2016 12:29 AM, Mark Brown wrote:

> /**
> Here is the case,
> PMIC supports 2 ramp time configurations 5mv/us and 100mV/us. This is

This looks like a typo given a lot of the other content and the fact
that this is a concern.

> But here is the stuff without typo ;-)
> Device supports 5mV/us and 100mV/us which is not in observed value.

So why doesn't the device end up configuring 100mV/us when asked for
50mv/us?  That's reasonably expected - the configured ramp rate is a
maximum rate given that this is used to limit inrush current.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Friday 01 April 2016 12:52 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Fri, Apr 01, 2016 at 12:29:05AM +0530, Laxman Dewangan wrote:
>> On Friday 01 April 2016 12:29 AM, Mark Brown wrote:
>> But here is the stuff without typo ;-)
>> Device supports 5mV/us and 100mV/us which is not in observed value.
> So why doesn't the device end up configuring 100mV/us when asked for
> 50mv/us?  That's reasonably expected - the configured ramp rate is a
> maximum rate given that this is used to limit inrush current.
>
>

We did this to adjust device configuration to nearest higher side but 
this is not working well on some of cases.

On same device, DCDC (SD) rails support 4 ramp configurations, 
13.75mV/us, 27.5mV/us, 55mV/us and 100mV/us.

HW team measured the  ramp time at 7.5mV/us when device configured at 
27.5mV/uS.

So as per above, it will be adjusted to 13.75mV/us (nearest higher side) 
for device configuration but this device need to configure for 27.5mV/us.

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

[Mark Brown]

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

On Fri, Apr 01, 2016 at 01:18:23AM +0530, Laxman Dewangan wrote:
> On Friday 01 April 2016 12:52 AM, Mark Brown wrote:

> >So why doesn't the device end up configuring 100mV/us when asked for
> >50mv/us?  That's reasonably expected - the configured ramp rate is a
> >maximum rate given that this is used to limit inrush current.

> We did this to adjust device configuration to nearest higher side but this
> is not working well on some of cases.

> On same device, DCDC (SD) rails support 4 ramp configurations, 13.75mV/us,
> 27.5mV/us, 55mV/us and 100mV/us.

> HW team measured the  ramp time at 7.5mV/us when device configured at
> 27.5mV/uS.

> So as per above, it will be adjusted to 13.75mV/us (nearest higher side) for
> device configuration but this device need to configure for 27.5mV/us.

You're saying that the device is so bad at regulating the ramp rate that
it's not only failing to keep up with the desired ramp rate and capping
at whatever rate but it's also doing even worse if configured for a
slower rate?  That's not great, it sounds like it's doing the ramp
control via some sort of dead reckoning thing rather than by actually
ramping the voltage it's trying to regulate like it was asked to.

Is the error in the observed values a function of the capacitance that
we can calcuate here?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Friday 01 April 2016 02:09 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Fri, Apr 01, 2016 at 01:18:23AM +0530, Laxman Dewangan wrote:
>> On Friday 01 April 2016 12:52 AM, Mark Brown wrote:
>> So as per above, it will be adjusted to 13.75mV/us (nearest higher side) for
>> device configuration but this device need to configure for 27.5mV/us.
> You're saying that the device is so bad at regulating the ramp rate that
> it's not only failing to keep up with the desired ramp rate and capping
> at whatever rate but it's also doing even worse if configured for a
> slower rate?  That's not great, it sounds like it's doing the ramp
> control via some sort of dead reckoning thing rather than by actually
> ramping the voltage it's trying to regulate like it was asked to.
>
> Is the error in the observed values a function of the capacitance that
> we can calcuate here?
>
As per datasheet, There is no direct equation for ramp time deviation 
when regulator output current cross the regulator current limit.

 From data sheet:
/**

During 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 DVS transition, reach the regulator’s current 
limit, the current limit will be enforced. When the current limit is 
enforced, the advertised DVS transition rate (dV/dt) will not occur.


And there is calculation of Iinrush based on Cout and configured dv/dt.
Iinrush=min(Ilim & Cout*dV/dt).

IINRUSH calculation for Cout = 100uF

IINRUSH=min(ILIMP & COUT*dV/dt).
SD0 is a two phase regulator with a typical PMOS current limit (ILIMPP0) 
of 3.75A per phase. For ILIMP in the above equation we will use 
2x3.75A=7.5A.
SD0 has a typical soft-start rate (dV/dt_SS_SD0) of 25mV/us. For dv/dt 
in the above equation we will use 25mV/us.
IINRUSH=min(7.5A & 100uF*25mV/us).
IINRUSH=min(7.5A & 2.5A).
IINRUSH=2.5A

**/


So providing configured and observed value direct will help much here.

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

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

On Fri, Apr 01, 2016 at 12:45:21PM +0530, Laxman Dewangan wrote:
> On Friday 01 April 2016 02:09 AM, Mark Brown wrote:

> >Is the error in the observed values a function of the capacitance that
> >we can calcuate here?

> As per datasheet, There is no direct equation for ramp time deviation when
> regulator output current cross the regulator current limit.

OK, so it's really a current limit that's kicking in rather than a ramp
rate control (though if it's a current limit I'm still not clear why the
target rate limits where we cap)?  Can we do something based on the
maximum load configured and the current limit?  That sounds more generic
anyway, a current limiting feature is quite common.  If we implement the
current limit interface for the regulator and then specify what the
maximum load is we should be able to do the calculations you quoted from
the datasheet I'd have thought (unless I'm missing something).

> So providing configured and observed value direct will help much here.

Only if we never do anything like reconfigure the ramp rate at runtime
which some other user might want to do, and it does rely on every system
integrator to notice that the ramp rate is inaccurate and work out how
to work around it for their system.  What would be better would be if we
could figure out a way of describing this based on something more
directly observable.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Friday 01 April 2016 09:41 PM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Fri, Apr 01, 2016 at 12:45:21PM +0530, Laxman Dewangan wrote:
>> On Friday 01 April 2016 02:09 AM, Mark Brown wrote:
>>> Is the error in the observed values a function of the capacitance that
>>> we can calcuate here?
>> As per datasheet, There is no direct equation for ramp time deviation when
>> regulator output current cross the regulator current limit.
> OK, so it's really a current limit that's kicking in rather than a ramp
> rate control (though if it's a current limit I'm still not clear why the
> target rate limits where we cap)?  Can we do something based on the
> maximum load configured and the current limit?  That sounds more generic
> anyway, a current limiting feature is quite common.  If we implement the
> current limit interface for the regulator and then specify what the
> maximum load is we should be able to do the calculations you quoted from
> the datasheet I'd have thought (unless I'm missing something).

We are not having any control/configuration for this in this particular 
observations. All are set at maximum and still seeing this deviation.

During 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 DVS transition, reach the regulator’s current 
limit, the current limit will be enforced. When the current limit is 
enforced, the advertised DVS transition rate (dV/dt) will not occur.

Now there is not really equation that how it control dV/dt with required 
current vs regulator’s current limit current limit.

Working with HW team on LDO3 rail, we observed that Vendor recommend the 
Cout to 2.2uF. With having this capacitor in rail, we meet the 
advertised dv/dt i.e. 100mV/us.
In Our platform, we have used 2x4.7uF for signal conditioning and we 
observed dv/dt went by half.
When we changed the output capacitor to 2.2uF, we get exactly what 
vendor advertised.

So can we derive the configured value from the ramp time (platform) and 
some multiplication factor? If this is not common way then probably 
maxim specific as suggested by Bjorn.


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

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

On Tue, Apr 05, 2016 at 01:31:41PM +0530, Laxman Dewangan wrote:
> On Friday 01 April 2016 09:41 PM, Mark Brown wrote:

> >>As per datasheet, There is no direct equation for ramp time deviation when
> >>regulator output current cross the regulator current limit.

> >OK, so it's really a current limit that's kicking in rather than a ramp
> >rate control (though if it's a current limit I'm still not clear why the
> >target rate limits where we cap)?  Can we do something based on the

> We are not having any control/configuration for this in this particular
> observations. All are set at maximum and still seeing this deviation.

I'm not sure how that follows from what I'm saying?  I'm saying we know
the limit, not that we can control the limit.

> During 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 DVS transition, reach the regulator’s current limit, the
> current limit will be enforced. When the current limit is enforced, the
> advertised DVS transition rate (dV/dt) will not occur.

> Now there is not really equation that how it control dV/dt with required
> current vs regulator’s current limit current limit.

I'm having a hard time tying this in with what you're saying.  You're
saying we have a predictable limit based on some hard maximum inrush
current but we can't tell what that limit is?  What I'd expect is that
we'd get the spec limit up to some maximum and then cap out at that.

> Working with HW team on LDO3 rail, we observed that Vendor recommend the
> Cout to 2.2uF. With having this capacitor in rail, we meet the advertised
> dv/dt i.e. 100mV/us.
> In Our platform, we have used 2x4.7uF for signal conditioning and we
> observed dv/dt went by half.
> When we changed the output capacitor to 2.2uF, we get exactly what vendor
> advertised.

The charge rate of the capactior should be a spec thing for the
capacitor shouldn't it?  

> So can we derive the configured value from the ramp time (platform) and some
> multiplication factor? If this is not common way then probably maxim
> specific as suggested by Bjorn.

How can we use a multiple of the advertised limit if we can't tell what
the limit is going to be?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

On Tuesday 12 April 2016 06:32 AM, Mark Brown wrote:
> * PGP Signed by an unknown key
>
> On Tue, Apr 05, 2016 at 01:31:41PM +0530, Laxman Dewangan wrote:
>> On Friday 01 April 2016 09:41 PM, Mark Brown wrote:
>> Now there is not really equation that how it control dV/dt with required
>> current vs regulator's current limit current limit.
> I'm having a hard time tying this in with what you're saying.  You're
> saying we have a predictable limit based on some hard maximum inrush
> current but we can't tell what that limit is?  What I'd expect is that
> we'd get the spec limit up to some maximum and then cap out at that.
>
>
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.

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.

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

[Mark Brown]

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

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.

> 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

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.

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

[Mark Brown]

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

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...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

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

[Laxman Dewangan]

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


--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[Mark Brown]

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

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]