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.
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.
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...
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.
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.
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.
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 regulators current limit, the current limit will be enforced.
When the current limit is enforced, the advertised transition rate
(dV/dt) will not occur.
On Tue, Mar 15, 2016 at 6:41 AM, Laxman Dewangan <[email protected]> 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
On Saturday 19 March 2016 10:01 AM, Bjorn Andersson wrote:
> On Tue, Mar 15, 2016 at 6:41 AM, Laxman Dewangan <[email protected]> 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.
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
>> <[email protected]> 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.
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?
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.
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?
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.
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?
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.
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?
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).
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...
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.
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?
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.
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.
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.
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?
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 regulators 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.
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.
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 regulators 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 regulators 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.
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?
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.
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.
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 regulators 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 regulators 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
doesnt hold correct. Thats 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.
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...
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
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.