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