omap5-uevm sdcard supply woes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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>;
	};


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.

(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?


Matthijs
--
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



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux