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

Groups > linux.kernel > #1371311 > 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 Laxman Dewangan <ldewangan@nvidia.com> - 2016-04-05 10:20 +0200
    Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Mark Brown <broonie@kernel.org> - 2016-04-12 03:10 +0200
      Re: [PATCH 1/2] regulator: DT: Add support to scale ramp delay based  on platform behavior Laxman Dewangan <ldewangan@nvidia.com> - 2016-04-12 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-04-13 09:00 +0200

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

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.

[toc] | [next] | [standalone]

#1376368

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

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?

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

#1376813

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.

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

#1377552

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

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.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web