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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
