IMX6 USDHC card detection

IMX6 USDHC card detection

[Russell King - ARM Linux]

Having spent many hours chasing around wondering why controller based
card detection doesn't work on IMX6, I've finally found it.

The hardware is setup such that we have a card detect signal routed to
GPIO 4.  If we try and use the host controller's built-in card detection,
things go awry - the host controller believes that a card is always
inserted.

This appears to be because the kernel sets the D3CD bit in the PROT_CTRL
register.  This enables card detection via the DAT3 signal, which
indicates a logic '1' level when a card is inserted.  SD cards have a 50k
pullup internally which provides the card detection mechanism, and hosts
are expected to have a weak pull-down on this signal.

However, the default setup of the SD data lines in IOMUX is this (eg):

             MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
             MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
             MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
             MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059

Bits 14 and 15 indicate "pull this pin up via a 22K resistor".

What you end up with is the SD controller believes that a card is always
inserted no matter what you do.  You can see this through the PRES_STATE
register - you see bit 18 assert/deassert appropriately on card insertion
and removals indicating that the socket CD signal is changing state, but
you don't see the card inserted bit (bit 16) ever change.  Neither does
the kernel react in any way.

So, are the defaults for DATA3 signals really appropriate, or should they
be adjusted (in other words, 0x13059 for DATA3).  The alternative is to
ignore the built-in host card detection, and configure the CD pin as a
GPIO instead.

IMX6 USDHC card detection

[Fabio Estevam]

On Thu, Oct 3, 2013 at 4:36 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> Having spent many hours chasing around wondering why controller based
> card detection doesn't work on IMX6, I've finally found it.
>
> The hardware is setup such that we have a card detect signal routed to
> GPIO 4.  If we try and use the host controller's built-in card detection,
> things go awry - the host controller believes that a card is always
> inserted.
>
> This appears to be because the kernel sets the D3CD bit in the PROT_CTRL
> register.  This enables card detection via the DAT3 signal, which
> indicates a logic '1' level when a card is inserted.  SD cards have a 50k
> pullup internally which provides the card detection mechanism, and hosts
> are expected to have a weak pull-down on this signal.
>
> However, the default setup of the SD data lines in IOMUX is this (eg):
>
>              MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
>              MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
>              MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
>              MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
>
> Bits 14 and 15 indicate "pull this pin up via a 22K resistor".
>
> What you end up with is the SD controller believes that a card is always
> inserted no matter what you do.  You can see this through the PRES_STATE
> register - you see bit 18 assert/deassert appropriately on card insertion
> and removals indicating that the socket CD signal is changing state, but
> you don't see the card inserted bit (bit 16) ever change.  Neither does
> the kernel react in any way.
>
> So, are the defaults for DATA3 signals really appropriate, or should they
> be adjusted (in other words, 0x13059 for DATA3).  The alternative is to
> ignore the built-in host card detection, and configure the CD pin as a
> GPIO instead.

Ran a quick test on a mx6qsabresd.

The original imx6qdl-sabresd.dtsi uses cd-gpio for sdhc3 port and I removed it:

--- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
+++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
@@ -164,8 +164,6 @@
                        fsl,pins = <
                                MX6QDL_PAD_GPIO_4__GPIO1_IO04   0x80000000
                                MX6QDL_PAD_GPIO_5__GPIO1_IO05   0x80000000
-                               MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x80000000
-                               MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x80000000
                                MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x80000000
                                MX6QDL_PAD_NANDF_D3__GPIO2_IO03 0x80000000
                                MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0
@@ -239,7 +237,5 @@
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_usdhc3_1>;
        bus-width = <8>;
-       cd-gpios = <&gpio2 0 0>;
-       wp-gpios = <&gpio2 1 0>;
        status = "okay";
 };

After this change,  the SD controller internal card detection also worked fine.

I see your point of SD3 needing a pull-down, so also tested:

--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1197,7 +1197,7 @@

MX6QDL_PAD_SD3_DAT0__SD3_DATA0 0x17059

MX6QDL_PAD_SD3_DAT1__SD3_DATA1 0x17059

MX6QDL_PAD_SD3_DAT2__SD3_DATA2 0x17059
-
MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x17059
+
MX6QDL_PAD_SD3_DAT3__SD3_DATA3 0x13059

MX6QDL_PAD_SD3_DAT4__SD3_DATA4 0x17059

MX6QDL_PAD_SD3_DAT5__SD3_DATA5 0x17059

MX6QDL_PAD_SD3_DAT6__SD3_DATA6 0x17059

and the internal card detection also worked fine here.

IMX6 USDHC card detection

[Shawn Guo]

On Thu, Oct 03, 2013 at 08:36:23PM +0100, Russell King - ARM Linux wrote:
> Having spent many hours chasing around wondering why controller based
> card detection doesn't work on IMX6, I've finally found it.
> 
> The hardware is setup such that we have a card detect signal routed to
> GPIO 4.  If we try and use the host controller's built-in card detection,
> things go awry - the host controller believes that a card is always
> inserted.
> 
> This appears to be because the kernel sets the D3CD bit in the PROT_CTRL
> register.  This enables card detection via the DAT3 signal, which
> indicates a logic '1' level when a card is inserted.  SD cards have a 50k
> pullup internally which provides the card detection mechanism, and hosts
> are expected to have a weak pull-down on this signal.
> 
> However, the default setup of the SD data lines in IOMUX is this (eg):
> 
>              MX6QDL_PAD_SD2_DAT0__SD2_DATA0 0x17059
>              MX6QDL_PAD_SD2_DAT1__SD2_DATA1 0x17059
>              MX6QDL_PAD_SD2_DAT2__SD2_DATA2 0x17059
>              MX6QDL_PAD_SD2_DAT3__SD2_DATA3 0x17059
> 
> Bits 14 and 15 indicate "pull this pin up via a 22K resistor".
> 
> What you end up with is the SD controller believes that a card is always
> inserted no matter what you do.  You can see this through the PRES_STATE
> register - you see bit 18 assert/deassert appropriately on card insertion
> and removals indicating that the socket CD signal is changing state, but
> you don't see the card inserted bit (bit 16) ever change.  Neither does
> the kernel react in any way.
> 
> So, are the defaults for DATA3 signals really appropriate, or should they
> be adjusted (in other words, 0x13059 for DATA3).  The alternative is to
> ignore the built-in host card detection, and configure the CD pin as a
> GPIO instead.

Unless we're sure that 0x13059 will not cause any ill effect, I would
suggest you configure the CD pin as GPIO and keep 0x17059 as pad
configuration, since it's been validated by various boards.

Shawn

IMX6 USDHC card detection

[Shawn Guo]

On Fri, Oct 04, 2013 at 01:07:03PM -0300, Fabio Estevam wrote:
> Ran a quick test on a mx6qsabresd.
> 
> The original imx6qdl-sabresd.dtsi uses cd-gpio for sdhc3 port and I removed it:
> 
> --- a/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> +++ b/arch/arm/boot/dts/imx6qdl-sabresd.dtsi
> @@ -164,8 +164,6 @@
>                         fsl,pins = <
>                                 MX6QDL_PAD_GPIO_4__GPIO1_IO04   0x80000000
>                                 MX6QDL_PAD_GPIO_5__GPIO1_IO05   0x80000000
> -                               MX6QDL_PAD_NANDF_D0__GPIO2_IO00 0x80000000
> -                               MX6QDL_PAD_NANDF_D1__GPIO2_IO01 0x80000000
>                                 MX6QDL_PAD_NANDF_D2__GPIO2_IO02 0x80000000
>                                 MX6QDL_PAD_NANDF_D3__GPIO2_IO03 0x80000000
>                                 MX6QDL_PAD_GPIO_0__CCM_CLKO1    0x130b0
> @@ -239,7 +237,5 @@
>         pinctrl-names = "default";
>         pinctrl-0 = <&pinctrl_usdhc3_1>;
>         bus-width = <8>;
> -       cd-gpios = <&gpio2 0 0>;
> -       wp-gpios = <&gpio2 1 0>;
>         status = "okay";
>  };
> 
> After this change,  the SD controller internal card detection also worked fine.

I guess you are not using the controller internal card detection at all
in this case, because pad NANDF_D0 has no function of any SD_CD_B.  The
card detection may just happen to work via DAT3 (D3CD).  But same as
what Russell has seen, the description of D3CD bit suggests that DAT3
should be pulled down in this case.

DATA3 as Card Detection Pin:
If this bit is set, DATA3 should be pulled down to act as a card
detection pin. Be cautious when using this feature, because DATA3 is
also a chip-select for the SPI mode. A pull-down on this pin and CMD0
may set the card into the SPI mode, which the uSDHC does not support.

Shawn

IMX6 USDHC card detection

[Russell King - ARM Linux]

On Sat, Oct 05, 2013 at 05:20:01PM +0800, Shawn Guo wrote:
> DATA3 as Card Detection Pin:
> If this bit is set, DATA3 should be pulled down to act as a card
> detection pin. Be cautious when using this feature, because DATA3 is
> also a chip-select for the SPI mode. A pull-down on this pin and CMD0
> may set the card into the SPI mode, which the uSDHC does not support.

The issue there is if the pull-down is too strong.

DATA3 is pulled up by the SD card via a 50k internal resistor.  If the
IMX6 is programmed to pull down via 100k, that will result in 2/3s of
the card supply on DATA3.  That should be fine given the card thresholds:

				Min		Max
Input High Voltage	VIH	0.625*VDD	VDD+0.3		V
Input Low Voltage	VIL	VSS-0.3		0.25*VDD	V

Of course, if a board has an additional external pull-down resistor on
DAT3, that will lower the DATA3 voltage level, so that's where a problem
could be.

Would you be happy if I added new pinctrl entries to imx6qdl.dtsi which
pulled down the DATA3 line - that way, existing DT setups will not be
affected, and they can switch over if they wish to using controller
based card detection.

Thanks.

IMX6 USDHC card detection

[Shawn Guo]

On Sat, Oct 05, 2013 at 10:35:27AM +0100, Russell King - ARM Linux wrote:
> On Sat, Oct 05, 2013 at 05:20:01PM +0800, Shawn Guo wrote:
> > DATA3 as Card Detection Pin:
> > If this bit is set, DATA3 should be pulled down to act as a card
> > detection pin. Be cautious when using this feature, because DATA3 is
> > also a chip-select for the SPI mode. A pull-down on this pin and CMD0
> > may set the card into the SPI mode, which the uSDHC does not support.
> 
> The issue there is if the pull-down is too strong.
> 
> DATA3 is pulled up by the SD card via a 50k internal resistor.  If the
> IMX6 is programmed to pull down via 100k, that will result in 2/3s of
> the card supply on DATA3.  That should be fine given the card thresholds:
> 
> 				Min		Max
> Input High Voltage	VIH	0.625*VDD	VDD+0.3		V
> Input Low Voltage	VIL	VSS-0.3		0.25*VDD	V
> 
> Of course, if a board has an additional external pull-down resistor on
> DAT3, that will lower the DATA3 voltage level, so that's where a problem
> could be.
> 
> Would you be happy if I added new pinctrl entries to imx6qdl.dtsi which
> pulled down the DATA3 line - that way, existing DT setups will not be
> affected, and they can switch over if they wish to using controller
> based card detection.

I'm fine with it.

Shawn

IMX6 USDHC card detection

[Fabio Estevam]

On Sat, Oct 5, 2013 at 6:20 AM, Shawn Guo <shawn.guo@linaro.org> wrote:

> I guess you are not using the controller internal card detection at all
> in this case, because pad NANDF_D0 has no function of any SD_CD_B.  The
> card detection may just happen to work via DAT3 (D3CD).  But same as

Yes, this is what I meant: card detection via DAT3.