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

Groups > linux.kernel > #1361047 > 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 Bjorn Andersson <bjorn@kryo.se> - 2016-03-19 05:40 +0100
    Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-19 09:50 +0100
      Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-30 15:50 +0200
        Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-03-30 20:20 +0200
          Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-31 09:20 +0200
            Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-03-31 19:00 +0200
              Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-31 19:30 +0200
                Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-03-31 19:50 +0200
                  Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-31 20:00 +0200
                    Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-03-31 20:40 +0200
                      Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-03-31 20:50 +0200
                        Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-31 21:00 +0200
                          Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-03-31 21:10 +0200
                            Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-31 21:10 +0200
                              Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-03-31 21:30 +0200
                                Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-31 22:00 +0200
                                  Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-03-31 22:50 +0200
                                    Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-04-01 09:30 +0200
                                      Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-04-01 18:20 +0200
                      Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-03-31 20:50 +0200

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

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

[toc] | [next] | [standalone]

#1361059

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.

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

#1367218

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.

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

#1367510

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

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?

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

#1367897

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.

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

#1368452

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

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?

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

#1368470

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.

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

#1368500

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

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?

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

#1368507

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.

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

#1368536

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

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?

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

#1368538

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

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

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

#1368554

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.

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

#1368558

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

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?

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

#1368559

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.

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

#1368569

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

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.

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

#1368583

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.

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

#1368687

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

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?

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

#1369062

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.

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

#1369463

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

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.

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

#1368539

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web