| Message ID | 1397526163-20126-5-git-send-email-abrestic@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 04/14/2014 07:42 PM, Andrew Bresticker wrote: > VDDIO_SDMMC3 is the VQMMC supply, not the VMMC supply, for the SD > slot. Add 1.8V_VDDIO as the VQMMC supply for the eMMC. Is there documentation re: what vmmc-supply and vqmmc-supply actually refer to? I looked a long while ago and couldn't find any, and didn't get an answer when I asked. Neither Documentation/devicetree/bindings/mmc/{mmc.txt,nvidia,tegra20-sdhci.txt} seem to say:-(
Hi Stephen, On Tue, Apr 15 2014, Stephen Warren wrote: > Is there documentation re: what vmmc-supply and vqmmc-supply actually > refer to? I looked a long while ago and couldn't find any, and didn't > get an answer when I asked. > > Neither > Documentation/devicetree/bindings/mmc/{mmc.txt,nvidia,tegra20-sdhci.txt} > seem to say:-( MMC cards use the same voltage for the VDD pin on the card and to pull up the signal lines. UHS SDHCI switches to using 1.8V vqmmc (signaling voltage) and 3.3V vmmc (card supply voltage). So the idea is to supply a vqmmc-supply if your board supports ultra-high-speed modes on an SD 3.0 host, and a vmmc-supply if your card power is controlled by a regulator. I agree that this ought to be in the bindings somewhere. Thanks, - Chris.
> sdhci@0,700b0600 { > status = "okay"; > bus-width = <8>; > + vqmmc-supply = <&vddio_1v8>; It turns out this bit isn't needed as the initialization failures are instead due to +3V3_RUN toggling, which Stephen has fixed: http://patchwork.ozlabs.org/patch/339386/
On 04/15/2014 06:29 PM, Andrew Bresticker wrote: >> sdhci@0,700b0600 { >> status = "okay"; >> bus-width = <8>; >> + vqmmc-supply = <&vddio_1v8>; > > It turns out this bit isn't needed as the initialization failures are > instead due to +3V3_RUN toggling, which Stephen has fixed: > http://patchwork.ozlabs.org/patch/339386/ Indeed, if I apply patches 1, 2, and 4 from this series, revert the hunk above, apply my Venice2 regulator patch, and finally apply your AS3722 regulator GPIO patch, then everything works fine for me:-)
On Wed, Apr 16, 2014 at 9:19 AM, Stephen Warren <swarren@wwwdotorg.org> wrote: > On 04/15/2014 06:29 PM, Andrew Bresticker wrote: >>> sdhci@0,700b0600 { >>> status = "okay"; >>> bus-width = <8>; >>> + vqmmc-supply = <&vddio_1v8>; >> >> It turns out this bit isn't needed as the initialization failures are >> instead due to +3V3_RUN toggling, which Stephen has fixed: >> http://patchwork.ozlabs.org/patch/339386/ > > Indeed, if I apply patches 1, 2, and 4 from this series, revert the hunk > above, apply my Venice2 regulator patch, and finally apply your AS3722 > regulator GPIO patch, then everything works fine for me:-) Great, I'll fix up and resend without patch 3 as it looks like that will need some more work.
diff --git a/arch/arm/boot/dts/tegra124-venice2.dts b/arch/arm/boot/dts/tegra124-venice2.dts index c17283c..53061ef 100644 --- a/arch/arm/boot/dts/tegra124-venice2.dts +++ b/arch/arm/boot/dts/tegra124-venice2.dts @@ -933,12 +933,13 @@ power-gpios = <&gpio TEGRA_GPIO(R, 0) GPIO_ACTIVE_HIGH>; status = "okay"; bus-width = <4>; - vmmc-supply = <&vddio_sdmmc3>; + vqmmc-supply = <&vddio_sdmmc3>; }; sdhci@0,700b0600 { status = "okay"; bus-width = <8>; + vqmmc-supply = <&vddio_1v8>; }; ahub@0,70300000 {
VDDIO_SDMMC3 is the VQMMC supply, not the VMMC supply, for the SD slot. Add 1.8V_VDDIO as the VQMMC supply for the eMMC. Signed-off-by: Andrew Bresticker <abrestic@chromium.org> --- arch/arm/boot/dts/tegra124-venice2.dts | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)