While reviewing the imx6q-cpufreq driver in detail, we come up with the concern that this driver is probably violating the LDO voltage constraints while transitioning from one operating frequency to other operating frequency. Although after the transition it will meet the constraints if the operating points are correctly defined in device tree. But during the transition as the LDO regulators are set sequentially so during the transition period for some instructions cycles these constraints are violated.
Following are the voltage constraints that are being violated.
1). VDD_SOC_CAP and VDD_PU_CAP must be equal
2). VDD_ARM_CAP must not exceed VDD_SOC_CAP or VDD_PU_CAP by more than 50 mV (i.MX6 DQ) or 100 mV (i.MX6 SDL)
3). VDD_SOC_CAP must not exceed VDD_ARM_CAP by more than 200 mV (i.MX6 DQ only)
Just for reference the associativity of these LDO regulators with the voltages mentioned above.
For example during the scaling down,
VDD_SOC_CAP is set to new value first and then VDD_PU_CAP. So after setting VDD_SOC_CAP and before setting VDD_PU_CAP, they are at the different voltage levels and that is violating the 1st constraint mentioned above.
/* scaling down? scale voltage after frequency */ | |
if (new_freq < old_freq) { | |
ret = regulator_set_voltage_tol(arm_reg, volt, 0); | |
if (ret) { | |
dev_warn(cpu_dev, | |
"failed to scale vddarm down: %d\n", ret); | |
ret = 0; | |
} | |
ret = regulator_set_voltage_tol(soc_reg, imx6_soc_volt[index], 0); | |
if (ret) { | |
dev_warn(cpu_dev, "failed to scale vddsoc down: %d\n", ret); | |
ret = 0; | |
} | |
if (!IS_ERR(pu_reg) && regulator_is_enabled(pu_reg)) { | |
ret = regulator_set_voltage_tol(pu_reg, | |
imx6_soc_volt[index], 0); | |
if (ret) { | |
dev_warn(cpu_dev, | |
"failed to scale vddpu down: %d\n", | |
ret); | |
ret = 0; | |
} | |
} | |
} |
But we have also observed that this code is functional on several variants of i.mx6 and does not harm the CPU/SoC.
So we are quite interested to know that if this code is not violating these voltage constraints, then how ?
One thing that comes in mind is that as the regulators move to new value in steps instead of abrupt change so that might be covering up these conditions.
Hi Adeel
you are right, change is performed not instantly, during some time defined
in CCM_ANALOG_MISC2n register as REGn_STEP_TIME.
Best regards
igor
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hello Igor,
Thank you for providing the feedback.
But even though if the change is performed in the steps of 25mV, there will be a very short time frame in which VDD_SOC_CAP will not be equal to VDD_PU_CAP, although the difference may be less than 25mV but still we cannot say that these remain equal all the time.
So I am still a bit confused that if this voltage constraint is violated then why it is not damaging the CPU/SoC ? Do we have some allowable voltage range or time frame during which if these constraints are violated would not harm the CPU/SoC ?
---
Regards,
Adeel Arshad
Hi Adeel
there will be no any very short time, as CCM_ANALOG_MISC2n register as REGn_STEP_TIME
defines 64 (and more)_CLOCKS step time, also there are capacitors at LDO which prevent.fast
voltage change.
Best regards
igor
Hello Igor,
Yes I agree that it would take 64 or more clocks to complete the step, but like in case of scaling down the frequency the change in VDD_SOC_CAP is triggered some instructions earlier than the change in VDD_PU_CAP. In that case what my understanding is that those 64 cycles will be started earlier for VDD_SOC_CAP than for VDD_PU_CAP...isnt it correct ?
Is that gap is negligible as the clock that is used for step is 24 MHz whereas the clock our CPU operating would be around 300+ MHz.
---
Regards,
Adeel Arshad
Hi Adeel
"some instructions earlier" with arm frequency 1GHz is tiny
difference.
~igor
Hello Igor,
So one last concern is the interruption/preemption in between setting VDD_SOC_CAP and VDD_PU_CAP,
in that case that gap can become significant ?