* Matthijs van Duin <matthijsvanduin@xxxxxxxxx> [170303 05:21]:
> Like its predecessors, the omap5 has a special bank of I/Os for interfacing
> with sdcards, which (unlike other I/O) may operate at 3V in addition to
> 1.8V, with support for switching at runtime.
>
> Unfortunately the designated LDO for this supply in the PMIC (Palmas),
> ldo9, can only supply 50 mA while cards are known to require more than that
> in practice. The omap5-uevm solved this by using a separate 3.3v supply
> for the sdcard, but disturbingly they continued to use ldo9 for the I/O
> supply on the omap5...
>
> The device tree right now permits ldo9 to be lowered to 1.8V, unaware of
> the fact that the sdcard will continue to drive 3.3V signals into the
> now very unhappy I/Os of the omap5 !
>
> Hence, the most urgent fix would be:
>
> &ldo9_reg {
> regulator-min-microvolt = <3000000>;
> };
Sounds like we should do that ASAP. Care to send a patch for that?
> To make things worse, according to the Recommended Operating Conditions
> in the omap5 datasheet, vdds_sdcard should not be operated at 3.3V at
> all but 3.0V nominal (3.06V MAX DC).
>
> This means you have to choose between:
> - configure ldo9 in bypass. Both sides use 3.3v, but this exceeds the
> max value specified by the omap5 datasheet.
> - configure ldo9 at 3.0V. The sdcard will be driving signals 0.3v
> higher than the omap5's supply (+ overshoot, if any).
>
> Pick your poison.
>
> Afaik bypass is the power-up config, while u-boot changes it to 3.0V.
> I'm not sure what linux does currently since omap5-board-common.dtsi
> incorrectly claims that &vmmcsd_fixed is 3.0V instead of 3.3V.
>
> I'm guessing that ldo9 at 3.0V is indeed the intended modus operandi.
OK
> (side-note: ldo8 can provide 200 mA, which would have been more than
> enough, and is not connected to anything whatsoever... nicely done)
>
>
> A final problem I noticed is power switching. The DT as-is implies that
> the sdcard can be powered off by switching ldo9 but this is plain wrong.
> Powering down the sdcard should be done by switching &vmmcsd_fixed via
> REGEN3. An obstacle is that eMMC (&mmc2) uses it as supply, but
> fortunately DT is simply wrong: eMMC is powered directly from the main
> 3.3v supply.
>
> So, roughly:
>
> vcc_3v3_main: fixedregulator-vcc_3v3_main {
> compatible = "regulator-fixed";
> regulator-name = "vcc_3v3_main";
> vin-supply = <&vmain>;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> };
>
> &vmmcsd_fixed {
> /* called vcc_3v3_sdio on omap5-uevm */
> vin-supply = <&vcc_3v3_main>;
> regulator-min-microvolt = <3300000>;
> regulator-max-microvolt = <3300000>;
> gpio = /* FIXME palmas REGEN3 */;
> };
>
> &mmc1 {
> /* card supply is actually &vmmcsd_fixed */
> vmmc-supply = <&ldo9_reg>;
> };
>
> &mmc2 {
> vmmc-supply = <&vcc_3v3_main>;
> };
>
> The details remaining are how to actually control REGEN3, and how to
> make sure linux leaves ldo9 alone and switches the supply just using
> &vmmcsd_fixed. I'm hoping someone who understands this stuff better
> than me has a suggestion?
I guess for one option is making ldo9 "regulator-always-on" and
"regulator-boot-on" if you want Linux not touch it. If you set it
with status = "disabled" then no struct device is ever created for
it. But isn't the vcc_3v3_main also input for ldo9?
For measuring, you should be able to configure regen3 pin as GPIO
regulator with palmas gpio2, then toggle it via /sys/class/gpio/.
The earlier PMICs would allow controlling REGEN pins(s) manually or
via software loaded to the PMIC based on SoC PM state changes. Not
sure what twl6030 has for that.
For your example above, if REGEN3 is already configured as a
regulator in palmas-regulator.c, maybe all you have to do is:
regen3_reg: regen3 {
regulator-name = "regen3";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
&mmc1 {
/* card supply is actually &vmmcsd_fixed */
vmmc-supply = <&ldo9_reg>;
vmmc_aux-supply = <®en3_reg>;
};
&mmc2 {
vmmc-supply = <&vcc_3v3_main>;
};
If there are other users of REGEN3 or regen3_reg they would need
to be mapped too as with both cards powered off the use count goes
to 0.
Regards,
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
