OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Hugo Vincent]

Hi everyone,

I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix Overo
based board working.

Compiling 2.6.29-omap1 with
    CONFIG_MMC=y
    CONFIG_MMC_DEBUG=y
    CONFIG_MMC_BLOCK=y
    CONFIG_MMC_BLOCK_BOUNCE=y
and MMC polling enabled (mmc->caps |= MMC_CAP_NEEDS_POLL; in omap_hsmmc.c)

then doing: $ echo 8 > /proc/sys/kernel/printk
gives the following:

clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
mmc2: starting CMD0 arg 00000000 flags 000000c0
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
mmc2: req done (CMD0): 0: 00000000 00000000 00000000 00000000
mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: starting CMD8 arg 000001aa flags 000002f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x000001aa
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD8): -110: 00000000 00000000 00000000 00000000
mmc2: starting CMD5 arg 00000000 flags 000002e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD5): -110: 00000000 00000000 00000000 00000000
mmc2: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
mmc2: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
mmc2: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
mmc2: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
mmc2: starting CMD1 arg 00000000 flags 000000e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x00000000
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
mmc2: req done (CMD1): -110: 00000000 00000000 00000000 00000000
mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0

It seems every request returns -110 which is -ETIMEDOUT.

I've checked the hardware, and it appears to be correct (level
translators etc seem to be doing their job).

During polling, the CMD and CLK signals show activity, but the data
lines never change; this is presumably why every request is timing
out.

I've also tried it with 2.6.30-omap1 in git, which changes some
MMC3-specific stuff (notably DMA), but has the exact same behaviour.

I've also checked pin multiplexing settings and confirmed that the
correct values are set for the MMC3 data pins. The card I'm using is a
microSD card that works when attached to MMC1 (the Gumstix Overo
built-in microSD slot). The slot is powered by 3.3V that is always on,
there is no provision for power switching with this particular board.

Any ideas?

Many thanks,
Hugo Vincent

RE: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Pandita, Vikram]

Hugo

>-----Original Message-----
>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Hugo
>Vincent
>Sent: Wednesday, June 10, 2009 9:14 PM
>To: linux-omap; General mailing list for gumstix users.
>Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?
>
>Hi everyone,
>
>I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix Overo
>based board working.

Please check if your MMC3 Mux setting are as follows:
Note the input configuration for CLK and CMD. This is needed.

/* MMC3 */
MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x1d0,
               OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x5d8,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)


Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.


>
>Compiling 2.6.29-omap1 with
>    CONFIG_MMC=y
>    CONFIG_MMC_DEBUG=y
>    CONFIG_MMC_BLOCK=y
>    CONFIG_MMC_BLOCK_BOUNCE=y
>and MMC polling enabled (mmc->caps |= MMC_CAP_NEEDS_POLL; in omap_hsmmc.c)
>
>then doing: $ echo 8 > /proc/sys/kernel/printk
>gives the following:
>
>clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
>mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
>mmc2: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
>mmc2: starting CMD0 arg 00000000 flags 000000c0
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
>mmc2: req done (CMD0): 0: 00000000 00000000 00000000 00000000
>mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
>mmc2: starting CMD8 arg 000001aa flags 000002f5
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x000001aa
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req done (CMD8): -110: 00000000 00000000 00000000 00000000
>mmc2: starting CMD5 arg 00000000 flags 000002e1
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req failed (CMD5): -110, retrying...
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req failed (CMD5): -110, retrying...
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req failed (CMD5): -110, retrying...
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req done (CMD5): -110: 00000000 00000000 00000000 00000000
>mmc2: starting CMD55 arg 00000000 flags 000000f5
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>mmc2: starting CMD55 arg 00000000 flags 000000f5
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>mmc2: starting CMD55 arg 00000000 flags 000000f5
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>mmc2: starting CMD55 arg 00000000 flags 000000f5
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>mmc2: starting CMD1 arg 00000000 flags 000000e1
>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x00000000
>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>mmc2: req done (CMD1): -110: 00000000 00000000 00000000 00000000
>mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
>
>It seems every request returns -110 which is -ETIMEDOUT.
>
>I've checked the hardware, and it appears to be correct (level
>translators etc seem to be doing their job).
>
>During polling, the CMD and CLK signals show activity, but the data
>lines never change; this is presumably why every request is timing
>out.
>
>I've also tried it with 2.6.30-omap1 in git, which changes some
>MMC3-specific stuff (notably DMA), but has the exact same behaviour.
>
>I've also checked pin multiplexing settings and confirmed that the
>correct values are set for the MMC3 data pins. The card I'm using is a
>microSD card that works when attached to MMC1 (the Gumstix Overo
>built-in microSD slot). The slot is powered by 3.3V that is always on,
>there is no provision for power switching with this particular board.
>
>Any ideas?
>
>Many thanks,
>Hugo Vincent
>--
>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Hugo Vincent]

On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikram<vikram.pandita@ti.com> wrote:
> Hugo
>
>>-----Original Message-----
>>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Hugo
>>Vincent
>>Sent: Wednesday, June 10, 2009 9:14 PM
>>To: linux-omap; General mailing list for gumstix users.
>>Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?
>>
>>Hi everyone,
>>
>>I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix Overo
>>based board working.
>
> Please check if your MMC3 Mux setting are as follows:
> Note the input configuration for CLK and CMD. This is needed.
>
> /* MMC3 */
> MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x1d0,
>               OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x5d8,
>               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>
>
> Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.

Thanks for that Vikram. Unfortunately, these are the exact mux &
pullup settings I was already using. (In my case, they were set by
u-boot, but to be sure, I've copied and pasted the above exactly into
mach-omap2/mux.c - same result). Any other ideas?

>>
>>Compiling 2.6.29-omap1 with
>>    CONFIG_MMC=y
>>    CONFIG_MMC_DEBUG=y
>>    CONFIG_MMC_BLOCK=y
>>    CONFIG_MMC_BLOCK_BOUNCE=y
>>and MMC polling enabled (mmc->caps |= MMC_CAP_NEEDS_POLL; in omap_hsmmc.c)
>>
>>then doing: $ echo 8 > /proc/sys/kernel/printk
>>gives the following:
>>
>>clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
>>mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
>>mmc2: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
>>mmc2: starting CMD0 arg 00000000 flags 000000c0
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
>>mmc2: req done (CMD0): 0: 00000000 00000000 00000000 00000000
>>mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
>>mmc2: starting CMD8 arg 000001aa flags 000002f5
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x000001aa
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req done (CMD8): -110: 00000000 00000000 00000000 00000000
>>mmc2: starting CMD5 arg 00000000 flags 000002e1
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req failed (CMD5): -110, retrying...
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req failed (CMD5): -110, retrying...
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req failed (CMD5): -110, retrying...
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req done (CMD5): -110: 00000000 00000000 00000000 00000000
>>mmc2: starting CMD55 arg 00000000 flags 000000f5
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>mmc2: starting CMD55 arg 00000000 flags 000000f5
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>mmc2: starting CMD55 arg 00000000 flags 000000f5
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>mmc2: starting CMD55 arg 00000000 flags 000000f5
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>mmc2: starting CMD1 arg 00000000 flags 000000e1
>>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x00000000
>>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>mmc2: req done (CMD1): -110: 00000000 00000000 00000000 00000000
>>mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
>>
>>It seems every request returns -110 which is -ETIMEDOUT.
>>
>>I've checked the hardware, and it appears to be correct (level
>>translators etc seem to be doing their job).
>>
>>During polling, the CMD and CLK signals show activity, but the data
>>lines never change; this is presumably why every request is timing
>>out.
>>
>>I've also tried it with 2.6.30-omap1 in git, which changes some
>>MMC3-specific stuff (notably DMA), but has the exact same behaviour.
>>
>>I've also checked pin multiplexing settings and confirmed that the
>>correct values are set for the MMC3 data pins. The card I'm using is a
>>microSD card that works when attached to MMC1 (the Gumstix Overo
>>built-in microSD slot). The slot is powered by 3.3V that is always on,
>>there is no provision for power switching with this particular board.
>>
>>Any ideas?
>>
>>Many thanks,
>>Hugo Vincent
>>--
>>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>the body of a message to majordomo@vger.kernel.org
>>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Peter Barada]

On Thu, 2009-06-11 at 15:35 +1200, Hugo Vincent wrote:
> On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikram<vikram.pandita@ti.com> wrote:
> > Hugo
> >
> >>-----Original Message-----
> >>From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Hugo
> >>Vincent
> >>Sent: Wednesday, June 10, 2009 9:14 PM
> >>To: linux-omap; General mailing list for gumstix users.
> >>Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?
> >>
> >>Hi everyone,
> >>
> >>I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix Overo
> >>based board working.
> >
> > Please check if your MMC3 Mux setting are as follows:
> > Note the input configuration for CLK and CMD. This is needed.
> >
> > /* MMC3 */
> > MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x1d0,
> >               OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
> > MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x5d8,
> >               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> > MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
> >               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> > MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
> >               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> > MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
> >               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> > MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
> >               OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> >
> >
> > Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.
> 
> Thanks for that Vikram. Unfortunately, these are the exact mux &
> pullup settings I was already using. (In my case, they were set by
> u-boot, but to be sure, I've copied and pasted the above exactly into
> mach-omap2/mux.c - same result). Any other ideas?

Are you using a 1.8V capable SD/MMC card?  MMC3 only works at 1.8V on
the 3430 - MMC1 can work at 3V due to PBIAS register settings.  If
you're not, then the MMC can talk to the card, but the card can't
understand what its seeing due to the volatages of CLK/CMD being too
low...


> >>
> >>Compiling 2.6.29-omap1 with
> >>    CONFIG_MMC=y
> >>    CONFIG_MMC_DEBUG=y
> >>    CONFIG_MMC_BLOCK=y
> >>    CONFIG_MMC_BLOCK_BOUNCE=y
> >>and MMC polling enabled (mmc->caps |= MMC_CAP_NEEDS_POLL; in omap_hsmmc.c)
> >>
> >>then doing: $ echo 8 > /proc/sys/kernel/printk
> >>gives the following:
> >>
> >>clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
> >>mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
> >>mmc2: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
> >>mmc2: starting CMD0 arg 00000000 flags 000000c0
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
> >>mmc2: req done (CMD0): 0: 00000000 00000000 00000000 00000000
> >>mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
> >>mmc2: starting CMD8 arg 000001aa flags 000002f5
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x000001aa
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req done (CMD8): -110: 00000000 00000000 00000000 00000000
> >>mmc2: starting CMD5 arg 00000000 flags 000002e1
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req failed (CMD5): -110, retrying...
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req failed (CMD5): -110, retrying...
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req failed (CMD5): -110, retrying...
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req done (CMD5): -110: 00000000 00000000 00000000 00000000
> >>mmc2: starting CMD55 arg 00000000 flags 000000f5
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
> >>mmc2: starting CMD55 arg 00000000 flags 000000f5
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
> >>mmc2: starting CMD55 arg 00000000 flags 000000f5
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
> >>mmc2: starting CMD55 arg 00000000 flags 000000f5
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
> >>mmc2: starting CMD1 arg 00000000 flags 000000e1
> >>mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x00000000
> >>mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
> >>mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
> >>mmc2: req done (CMD1): -110: 00000000 00000000 00000000 00000000
> >>mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
> >>
> >>It seems every request returns -110 which is -ETIMEDOUT.
> >>
> >>I've checked the hardware, and it appears to be correct (level
> >>translators etc seem to be doing their job).
> >>
> >>During polling, the CMD and CLK signals show activity, but the data
> >>lines never change; this is presumably why every request is timing
> >>out.
> >>
> >>I've also tried it with 2.6.30-omap1 in git, which changes some
> >>MMC3-specific stuff (notably DMA), but has the exact same behaviour.
> >>
> >>I've also checked pin multiplexing settings and confirmed that the
> >>correct values are set for the MMC3 data pins. The card I'm using is a
> >>microSD card that works when attached to MMC1 (the Gumstix Overo
> >>built-in microSD slot). The slot is powered by 3.3V that is always on,
> >>there is no provision for power switching with this particular board.
> >>
> >>Any ideas?
> >>
> >>Many thanks,
> >>Hugo Vincent
> >>--
> >>To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> >>the body of a message to majordomo@vger.kernel.org
> >>More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Hugo Vincent]

On 11/06/2009, at 6:08 PM, Peter Barada wrote:

> On Thu, 2009-06-11 at 15:35 +1200, Hugo Vincent wrote:
>> On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikram<vikram.pandita@ti.com 
>> > wrote:
>>> Hugo
>>>
>>>> -----Original Message-----
>>>> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-owner@vger.kernel.org 
>>>> ] On Behalf Of Hugo
>>>> Vincent
>>>> Sent: Wednesday, June 10, 2009 9:14 PM
>>>> To: linux-omap; General mailing list for gumstix users.
>>>> Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?
>>>>
>>>> Hi everyone,
>>>>
>>>> I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix  
>>>> Overo
>>>> based board working.
>>>
>>> Please check if your MMC3 Mux setting are as follows:
>>> Note the input configuration for CLK and CMD. This is needed.
>>>
>>> /* MMC3 */
>>> MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x1d0,
>>>             OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>>> MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x5d8,
>>>             OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>>>             OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>>>             OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>>>             OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>>>             OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>
>>>
>>> Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.
>>
>> Thanks for that Vikram. Unfortunately, these are the exact mux &
>> pullup settings I was already using. (In my case, they were set by
>> u-boot, but to be sure, I've copied and pasted the above exactly into
>> mach-omap2/mux.c - same result). Any other ideas?
>
> Are you using a 1.8V capable SD/MMC card?  MMC3 only works at 1.8V on
> the 3430 - MMC1 can work at 3V due to PBIAS register settings.  If
> you're not, then the MMC can talk to the card, but the card can't
> understand what its seeing due to the volatages of CLK/CMD being too
> low...

I am using a 3V SD card. But I'm also using TI TXS02612 for level  
translation (and to multiplex between two slots - but for now I only  
need to get one slot working and thus the select pin is wired high).  
I'm pretty confident that the level translation is working correctly  
as (a) the clk and cmd signals come out to the correct pins on the  
socket at the correct levels and (b) remultiplexing the datX signals  
as GPIOs and driving them is correctly reflected (and at the correct  
3V levels) on the correct pins on the card socket. Similarly in the  
card->OMAP direction of signaling (they are of course bidirectional  
level translators).

Do I need to somehow tell the mmc host or core driver that I have  
external level translation and therefore not to worry that the host  
only supports 1.8V cards?

Thanks for your help!

Hugo

>>>> Compiling 2.6.29-omap1 with
>>>>  CONFIG_MMC=y
>>>>  CONFIG_MMC_DEBUG=y
>>>>  CONFIG_MMC_BLOCK=y
>>>>  CONFIG_MMC_BLOCK_BOUNCE=y
>>>> and MMC polling enabled (mmc->caps |= MMC_CAP_NEEDS_POLL; in  
>>>> omap_hsmmc.c)
>>>>
>>>> then doing: $ echo 8 > /proc/sys/kernel/printk
>>>> gives the following:
>>>>
>>>> clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0  
>>>> timing 0
>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0  
>>>> timing 0
>>>> mmc2: starting CMD0 arg 00000000 flags 000000c0
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
>>>> mmc2: req done (CMD0): 0: 00000000 00000000 00000000 00000000
>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0  
>>>> timing 0
>>>> mmc2: starting CMD8 arg 000001aa flags 000002f5
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x000001aa
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req done (CMD8): -110: 00000000 00000000 00000000 00000000
>>>> mmc2: starting CMD5 arg 00000000 flags 000002e1
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req failed (CMD5): -110, retrying...
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req failed (CMD5): -110, retrying...
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req failed (CMD5): -110, retrying...
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req done (CMD5): -110: 00000000 00000000 00000000 00000000
>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>> mmc2: starting CMD1 arg 00000000 flags 000000e1
>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x00000000
>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>> mmc2: req done (CMD1): -110: 00000000 00000000 00000000 00000000
>>>> mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
>>>>
>>>> It seems every request returns -110 which is -ETIMEDOUT.
>>>>
>>>> I've checked the hardware, and it appears to be correct (level
>>>> translators etc seem to be doing their job).
>>>>
>>>> During polling, the CMD and CLK signals show activity, but the data
>>>> lines never change; this is presumably why every request is timing
>>>> out.
>>>>
>>>> I've also tried it with 2.6.30-omap1 in git, which changes some
>>>> MMC3-specific stuff (notably DMA), but has the exact same  
>>>> behaviour.
>>>>
>>>> I've also checked pin multiplexing settings and confirmed that the
>>>> correct values are set for the MMC3 data pins. The card I'm using  
>>>> is a
>>>> microSD card that works when attached to MMC1 (the Gumstix Overo
>>>> built-in microSD slot). The slot is powered by 3.3V that is  
>>>> always on,
>>>> there is no provision for power switching with this particular  
>>>> board.
>>>>
>>>> Any ideas?
>>>>
>>>> Many thanks,
>>>> Hugo Vincent
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux- 
>>>> omap" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux- 
>> omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html


------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing 
server and web deployment.
http://p.sf.net/sfu/businessobjects

Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Grazvydas Ignotas]

On Thu, Jun 11, 2009 at 10:43 AM, Hugo Vincent<hugo.vincent@gmail.com> wrote:
>
> On 11/06/2009, at 6:08 PM, Peter Barada wrote:
>
>> On Thu, 2009-06-11 at 15:35 +1200, Hugo Vincent wrote:
>>>
>>> On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikram<vikram.pandita@ti.com>
>>> wrote:
>>>>
>>>> Hugo
>>>>
>>>>> -----Original Message-----
>>>>> From: linux-omap-owner@vger.kernel.org
>>>>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Hugo
>>>>> Vincent
>>>>> Sent: Wednesday, June 10, 2009 9:14 PM
>>>>> To: linux-omap; General mailing list for gumstix users.
>>>>> Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix Overo
>>>>> based board working.
>>>>
>>>> Please check if your MMC3 Mux setting are as follows:
>>>> Note the input configuration for CLK and CMD. This is needed.
>>>>
>>>> /* MMC3 */
>>>> MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x1d0,
>>>>            OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x5d8,
>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>
>>>>
>>>> Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.
>>>
>>> Thanks for that Vikram. Unfortunately, these are the exact mux &
>>> pullup settings I was already using. (In my case, they were set by
>>> u-boot, but to be sure, I've copied and pasted the above exactly into
>>> mach-omap2/mux.c - same result). Any other ideas?
>>
>> Are you using a 1.8V capable SD/MMC card?  MMC3 only works at 1.8V on
>> the 3430 - MMC1 can work at 3V due to PBIAS register settings.  If
>> you're not, then the MMC can talk to the card, but the card can't
>> understand what its seeing due to the volatages of CLK/CMD being too
>> low...
>
> I am using a 3V SD card. But I'm also using TI TXS02612 for level
> translation (and to multiplex between two slots - but for now I only need to
> get one slot working and thus the select pin is wired high). I'm pretty
> confident that the level translation is working correctly as (a) the clk and
> cmd signals come out to the correct pins on the socket at the correct levels
> and (b) remultiplexing the datX signals as GPIOs and driving them is
> correctly reflected (and at the correct 3V levels) on the correct pins on
> the card socket. Similarly in the card->OMAP direction of signaling (they
> are of course bidirectional level translators).
>
> Do I need to somehow tell the mmc host or core driver that I have external
> level translation and therefore not to worry that the host only supports
> 1.8V cards?

The TRM says MMC3 "is used without external transceiver" [only?].
Doesn't the transceiver need additional control signals (dir_cmd and
dir_dat[2:0]), that are only provided by MMC2?

>
> Thanks for your help!
>
> Hugo
>
>>>>> Compiling 2.6.29-omap1 with
>>>>>  CONFIG_MMC=y
>>>>>  CONFIG_MMC_DEBUG=y
>>>>>  CONFIG_MMC_BLOCK=y
>>>>>  CONFIG_MMC_BLOCK_BOUNCE=y
>>>>> and MMC polling enabled (mmc->caps |= MMC_CAP_NEEDS_POLL; in
>>>>> omap_hsmmc.c)
>>>>>
>>>>> then doing: $ echo 8 > /proc/sys/kernel/printk
>>>>> gives the following:
>>>>>
>>>>> clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
>>>>> mmc2: starting CMD0 arg 00000000 flags 000000c0
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
>>>>> mmc2: req done (CMD0): 0: 00000000 00000000 00000000 00000000
>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
>>>>> mmc2: starting CMD8 arg 000001aa flags 000002f5
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x000001aa
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req done (CMD8): -110: 00000000 00000000 00000000 00000000
>>>>> mmc2: starting CMD5 arg 00000000 flags 000002e1
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req done (CMD5): -110: 00000000 00000000 00000000 00000000
>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>> mmc2: starting CMD1 arg 00000000 flags 000000e1
>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x00000000
>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>> mmc2: req done (CMD1): -110: 00000000 00000000 00000000 00000000
>>>>> mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
>>>>>
>>>>> It seems every request returns -110 which is -ETIMEDOUT.
>>>>>
>>>>> I've checked the hardware, and it appears to be correct (level
>>>>> translators etc seem to be doing their job).
>>>>>
>>>>> During polling, the CMD and CLK signals show activity, but the data
>>>>> lines never change; this is presumably why every request is timing
>>>>> out.
>>>>>
>>>>> I've also tried it with 2.6.30-omap1 in git, which changes some
>>>>> MMC3-specific stuff (notably DMA), but has the exact same behaviour.
>>>>>
>>>>> I've also checked pin multiplexing settings and confirmed that the
>>>>> correct values are set for the MMC3 data pins. The card I'm using is a
>>>>> microSD card that works when attached to MMC1 (the Gumstix Overo
>>>>> built-in microSD slot). The slot is powered by 3.3V that is always on,
>>>>> there is no provision for power switching with this particular board.
>>>>>
>>>>> Any ideas?
>>>>>
>>>>> Many thanks,
>>>>> Hugo Vincent
>>>>> --
>>>>> To unsubscribe from this list: send the line "unsubscribe linux-omap"
>>>>> in
>>>>> the body of a message to majordomo@vger.kernel.org
>>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Hugo Vincent]

On 11/06/2009, at 9:29 PM, Grazvydas Ignotas wrote:

> On Thu, Jun 11, 2009 at 10:43 AM, Hugo  
> Vincent<hugo.vincent@gmail.com> wrote:
>>
>> On 11/06/2009, at 6:08 PM, Peter Barada wrote:
>>
>>> On Thu, 2009-06-11 at 15:35 +1200, Hugo Vincent wrote:
>>>>
>>>> On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikram<vikram.pandita@ti.com 
>>>> >
>>>> wrote:
>>>>>
>>>>> Hugo
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: linux-omap-owner@vger.kernel.org
>>>>>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Hugo
>>>>>> Vincent
>>>>>> Sent: Wednesday, June 10, 2009 9:14 PM
>>>>>> To: linux-omap; General mailing list for gumstix users.
>>>>>> Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?
>>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix  
>>>>>> Overo
>>>>>> based board working.
>>>>>
>>>>> Please check if your MMC3 Mux setting are as follows:
>>>>> Note the input configuration for CLK and CMD. This is needed.
>>>>>
>>>>> /* MMC3 */
>>>>> MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x1d0,
>>>>>            OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>> MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x5d8,
>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>> MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>> MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>
>>>>>
>>>>> Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.
>>>>
>>>> Thanks for that Vikram. Unfortunately, these are the exact mux &
>>>> pullup settings I was already using. (In my case, they were set by
>>>> u-boot, but to be sure, I've copied and pasted the above exactly  
>>>> into
>>>> mach-omap2/mux.c - same result). Any other ideas?
>>>
>>> Are you using a 1.8V capable SD/MMC card?  MMC3 only works at 1.8V  
>>> on
>>> the 3430 - MMC1 can work at 3V due to PBIAS register settings.  If
>>> you're not, then the MMC can talk to the card, but the card can't
>>> understand what its seeing due to the volatages of CLK/CMD being too
>>> low...
>>
>> I am using a 3V SD card. But I'm also using TI TXS02612 for level
>> translation (and to multiplex between two slots - but for now I  
>> only need to
>> get one slot working and thus the select pin is wired high). I'm  
>> pretty
>> confident that the level translation is working correctly as (a)  
>> the clk and
>> cmd signals come out to the correct pins on the socket at the  
>> correct levels
>> and (b) remultiplexing the datX signals as GPIOs and driving them is
>> correctly reflected (and at the correct 3V levels) on the correct  
>> pins on
>> the card socket. Similarly in the card->OMAP direction of signaling  
>> (they
>> are of course bidirectional level translators).
>>
>> Do I need to somehow tell the mmc host or core driver that I have  
>> external
>> level translation and therefore not to worry that the host only  
>> supports
>> 1.8V cards?
>
> The TRM says MMC3 "is used without external transceiver" [only?].
> Doesn't the transceiver need additional control signals (dir_cmd and
> dir_dat[2:0]), that are only provided by MMC2?

You are quite possibly correct, but the level translator I'm using is  
"invisible" - it doesn't require the transceiver control signals  
offered only on MMC2. So as far as I know, there is no hardware reason  
the OMAP MMC3 controller couldn't talk correctly at the electrical  
level with the card. This is evidenced by the CMD signal being  
correctly level translated (and this is via the same type of level  
translator as the data signals are according to the TXS02612  
datasheet), and toggling correctly(-looking) at the card socket (i.e.  
between 0 and 3.3V and it's edges synced to the clock signal). The  
DAT0-DAT3 signals never do anything though.

Hugo

>>
>> Thanks for your help!
>>
>> Hugo
>>
>>>>>> Compiling 2.6.29-omap1 with
>>>>>>  CONFIG_MMC=y
>>>>>>  CONFIG_MMC_DEBUG=y
>>>>>>  CONFIG_MMC_BLOCK=y
>>>>>>  CONFIG_MMC_BLOCK_BOUNCE=y
>>>>>> and MMC polling enabled (mmc->caps |= MMC_CAP_NEEDS_POLL; in
>>>>>> omap_hsmmc.c)
>>>>>>
>>>>>> then doing: $ echo 8 > /proc/sys/kernel/printk
>>>>>> gives the following:
>>>>>>
>>>>>> clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
>>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0  
>>>>>> timing 0
>>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0  
>>>>>> timing 0
>>>>>> mmc2: starting CMD0 arg 00000000 flags 000000c0
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
>>>>>> mmc2: req done (CMD0): 0: 00000000 00000000 00000000 00000000
>>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0  
>>>>>> timing 0
>>>>>> mmc2: starting CMD8 arg 000001aa flags 000002f5
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x000001aa
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req done (CMD8): -110: 00000000 00000000 00000000 00000000
>>>>>> mmc2: starting CMD5 arg 00000000 flags 000002e1
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req done (CMD5): -110: 00000000 00000000 00000000 00000000
>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>> mmc2: starting CMD1 arg 00000000 flags 000000e1
>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x00000000
>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>> mmc2: req done (CMD1): -110: 00000000 00000000 00000000 00000000
>>>>>> mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
>>>>>>
>>>>>> It seems every request returns -110 which is -ETIMEDOUT.
>>>>>>
>>>>>> I've checked the hardware, and it appears to be correct (level
>>>>>> translators etc seem to be doing their job).
>>>>>>
>>>>>> During polling, the CMD and CLK signals show activity, but the  
>>>>>> data
>>>>>> lines never change; this is presumably why every request is  
>>>>>> timing
>>>>>> out.
>>>>>>
>>>>>> I've also tried it with 2.6.30-omap1 in git, which changes some
>>>>>> MMC3-specific stuff (notably DMA), but has the exact same  
>>>>>> behaviour.
>>>>>>
>>>>>> I've also checked pin multiplexing settings and confirmed that  
>>>>>> the
>>>>>> correct values are set for the MMC3 data pins. The card I'm  
>>>>>> using is a
>>>>>> microSD card that works when attached to MMC1 (the Gumstix Overo
>>>>>> built-in microSD slot). The slot is powered by 3.3V that is  
>>>>>> always on,
>>>>>> there is no provision for power switching with this particular  
>>>>>> board.
>>>>>>
>>>>>> Any ideas?
>>>>>>
>>>>>> Many thanks,
>>>>>> Hugo Vincent
>>>>>> --
>>>>>> To unsubscribe from this list: send the line "unsubscribe linux- 
>>>>>> omap"
>>>>>> in
>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>> More majordomo info at  http://vger.kernel.org/majordomo- 
>>>>>> info.html
>>>>>
>>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux- 
>>>> omap" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux- 
>> omap" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>

RE: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Gadiyar, Anand]

<snip>
> 
> You are quite possibly correct, but the level translator I'm using is  
> "invisible" - it doesn't require the transceiver control signals  
> offered only on MMC2. So as far as I know, there is no hardware reason  
> the OMAP MMC3 controller couldn't talk correctly at the electrical  
> level with the card. This is evidenced by the CMD signal being  
> correctly level translated (and this is via the same type of level  
> translator as the data signals are according to the TXS02612  
> datasheet), and toggling correctly(-looking) at the card socket (i.e.  
> between 0 and 3.3V and it's edges synced to the clock signal). The  
> DAT0-DAT3 signals never do anything though.

The MMC3 DAT0-DAT3 lines are muxed with MMC2 DAT4-DAT7. Any chance the
padconfs are being overwritten even though you programmed them
correctly in the bootloader?

- Anand

Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Adrian Hunter]

[-- Attachment #1: Type: text/plain, Size: 9463 bytes --]

Hugo Vincent wrote:
> On 11/06/2009, at 9:29 PM, Grazvydas Ignotas wrote:
> 
>> On Thu, Jun 11, 2009 at 10:43 AM, Hugo
>> Vincent<hugo.vincent@gmail.com> wrote:
>>> On 11/06/2009, at 6:08 PM, Peter Barada wrote:
>>>
>>>> On Thu, 2009-06-11 at 15:35 +1200, Hugo Vincent wrote:
>>>>> On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikram<vikram.pandita@ti.com
>>>>> wrote:
>>>>>> Hugo
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: linux-omap-owner@vger.kernel.org
>>>>>>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Hugo
>>>>>>> Vincent
>>>>>>> Sent: Wednesday, June 10, 2009 9:14 PM
>>>>>>> To: linux-omap; General mailing list for gumstix users.
>>>>>>> Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix
>>>>>>> Overo
>>>>>>> based board working.
>>>>>> Please check if your MMC3 Mux setting are as follows:
>>>>>> Note the input configuration for CLK and CMD. This is needed.
>>>>>>
>>>>>> /* MMC3 */
>>>>>> MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x1d0,
>>>>>>            OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x5d8,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>>
>>>>>>
>>>>>> Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.
>>>>> Thanks for that Vikram. Unfortunately, these are the exact mux &
>>>>> pullup settings I was already using. (In my case, they were set by
>>>>> u-boot, but to be sure, I've copied and pasted the above exactly
>>>>> into
>>>>> mach-omap2/mux.c - same result). Any other ideas?
>>>> Are you using a 1.8V capable SD/MMC card?  MMC3 only works at 1.8V
>>>> on
>>>> the 3430 - MMC1 can work at 3V due to PBIAS register settings.  If
>>>> you're not, then the MMC can talk to the card, but the card can't
>>>> understand what its seeing due to the volatages of CLK/CMD being too
>>>> low...
>>> I am using a 3V SD card. But I'm also using TI TXS02612 for level
>>> translation (and to multiplex between two slots - but for now I
>>> only need to
>>> get one slot working and thus the select pin is wired high). I'm
>>> pretty
>>> confident that the level translation is working correctly as (a)
>>> the clk and
>>> cmd signals come out to the correct pins on the socket at the
>>> correct levels
>>> and (b) remultiplexing the datX signals as GPIOs and driving them is
>>> correctly reflected (and at the correct 3V levels) on the correct
>>> pins on
>>> the card socket. Similarly in the card->OMAP direction of signaling
>>> (they
>>> are of course bidirectional level translators).
>>>
>>> Do I need to somehow tell the mmc host or core driver that I have
>>> external
>>> level translation and therefore not to worry that the host only
>>> supports
>>> 1.8V cards?
>> The TRM says MMC3 "is used without external transceiver" [only?].
>> Doesn't the transceiver need additional control signals (dir_cmd and
>> dir_dat[2:0]), that are only provided by MMC2?
> 
> You are quite possibly correct, but the level translator I'm using is
> "invisible" - it doesn't require the transceiver control signals
> offered only on MMC2. So as far as I know, there is no hardware reason
> the OMAP MMC3 controller couldn't talk correctly at the electrical
> level with the card. This is evidenced by the CMD signal being
> correctly level translated (and this is via the same type of level
> translator as the data signals are according to the TXS02612
> datasheet), and toggling correctly(-looking) at the card socket (i.e.
> between 0 and 3.3V and it's edges synced to the clock signal). The
> DAT0-DAT3 signals never do anything though.
> 
> Hugo
> 
>>> Thanks for your help!
>>>
>>> Hugo
>>>
>>>>>>> Compiling 2.6.29-omap1 with
>>>>>>>  CONFIG_MMC=y
>>>>>>>  CONFIG_MMC_DEBUG=y
>>>>>>>  CONFIG_MMC_BLOCK=y
>>>>>>>  CONFIG_MMC_BLOCK_BOUNCE=y
>>>>>>> and MMC polling enabled (mmc->caps |= MMC_CAP_NEEDS_POLL; in
>>>>>>> omap_hsmmc.c)
>>>>>>>
>>>>>>> then doing: $ echo 8 > /proc/sys/kernel/printk
>>>>>>> gives the following:
>>>>>>>
>>>>>>> clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
>>>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0
>>>>>>> timing 0
>>>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0
>>>>>>> timing 0
>>>>>>> mmc2: starting CMD0 arg 00000000 flags 000000c0
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
>>>>>>> mmc2: req done (CMD0): 0: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0
>>>>>>> timing 0
>>>>>>> mmc2: starting CMD8 arg 000001aa flags 000002f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x000001aa
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD8): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD5 arg 00000000 flags 000002e1
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD5): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD1 arg 00000000 flags 000000e1
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD1): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
>>>>>>>
>>>>>>> It seems every request returns -110 which is -ETIMEDOUT.
>>>>>>>
>>>>>>> I've checked the hardware, and it appears to be correct (level
>>>>>>> translators etc seem to be doing their job).
>>>>>>>
>>>>>>> During polling, the CMD and CLK signals show activity, but the
>>>>>>> data
>>>>>>> lines never change; this is presumably why every request is
>>>>>>> timing
>>>>>>> out.
>>>>>>>
>>>>>>> I've also tried it with 2.6.30-omap1 in git, which changes some
>>>>>>> MMC3-specific stuff (notably DMA), but has the exact same
>>>>>>> behaviour.
>>>>>>>
>>>>>>> I've also checked pin multiplexing settings and confirmed that
>>>>>>> the
>>>>>>> correct values are set for the MMC3 data pins. The card I'm
>>>>>>> using is a
>>>>>>> microSD card that works when attached to MMC1 (the Gumstix Overo
>>>>>>> built-in microSD slot). The slot is powered by 3.3V that is
>>>>>>> always on,
>>>>>>> there is no provision for power switching with this particular
>>>>>>> board.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>>
>>>>>>> Many thanks,
>>>>>>> Hugo Vincent

We have fixed a few bugs in omap_hsmmc.c that we have not had time
to send to mainline, but will hopefully in the coming weeks.

I have attached some patches which probably do not apply cleanly,
and may not help with your problem anyway.



[-- Attachment #2: 0001-omap_hsmmc-set-open-drain-bit-correctly.patch --]
[-- Type: text/x-diff, Size: 1157 bytes --]

>From d92f5c940461992c7a25f134a58a94bd3161fd54 Mon Sep 17 00:00:00 2001
From: Denis Karpov <ext-denis.2.karpov@nokia.com>
Date: Thu, 23 Apr 2009 16:44:58 +0300
Subject: [PATCH] omap_hsmmc: set open drain bit correctly

The code could set the bit to 1 but not reset it to 0.

Signed-off-by: Denis Karpov <ext-denis.2.karpov@nokia.com>
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
---
 drivers/mmc/host/omap_hsmmc.c |    6 ++++--
 1 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 19bbfa5..87d4e7a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1033,9 +1033,11 @@ static void omap_mmc_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
 	if (ios->power_mode == MMC_POWER_ON)
 		send_init_stream(host);
 
+	con = OMAP_HSMMC_READ(host->base, CON);
 	if (ios->bus_mode == MMC_BUSMODE_OPENDRAIN)
-		OMAP_HSMMC_WRITE(host->base, CON,
-				OMAP_HSMMC_READ(host->base, CON) | OD);
+		OMAP_HSMMC_WRITE(host->base, CON, con | OD);
+	else
+		OMAP_HSMMC_WRITE(host->base, CON, con & ~OD);
 
 	mmc_host_lazy_disable(host->mmc);
 }
-- 
1.5.6.3


[-- Attachment #3: 0002-omap_hsmmc-clear-interrupt-status-after-init-sequen.patch --]
[-- Type: text/x-diff, Size: 958 bytes --]

>From 908a0774d4e60408542fc848d00f8fdafd540762 Mon Sep 17 00:00:00 2001
From: Adrian Hunter <adrian.hunter@nokia.com>
Date: Sat, 16 May 2009 09:35:17 +0300
Subject: [PATCH] omap_hsmmc: clear interrupt status after init sequence

Clear the interrupt status after sending the initialization sequence,
as specified in the TRM.

Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
---
 drivers/mmc/host/omap_hsmmc.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 066ed2e..af10012 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -354,6 +354,10 @@ static void send_init_stream(struct mmc_omap_host *host)
 
 	OMAP_HSMMC_WRITE(host->base, CON,
 		OMAP_HSMMC_READ(host->base, CON) & ~INIT_STREAM);
+
+	OMAP_HSMMC_WRITE(host->base, STAT, STAT_CLEAR);
+	OMAP_HSMMC_READ(host->base, STAT);
+
 	enable_irq(host->irq);
 }
 
-- 
1.5.6.3


[-- Attachment #4: 0003-omap_hsmmc-cater-for-weird-CMD6-behaviour.patch --]
[-- Type: text/x-diff, Size: 1225 bytes --]

>From d060f6d385adc1bd2e7b34b036915836df93624d Mon Sep 17 00:00:00 2001
From: Adrian Hunter <adrian.hunter@nokia.com>
Date: Sat, 16 May 2009 10:05:40 +0300
Subject: [PATCH] omap_hsmmc: cater for weird CMD6 behaviour

Sometimes the controller unexpectedly produces a TC (transfer
complete) interrupt before the CC (command complete) interrupt for
command 6 (SWITCH).  This is a problem because the CC interrupt
can get mixed up with the next request.  Add a hack for CMD6.

Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
---
 drivers/mmc/host/omap_hsmmc.c |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index af10012..ee25ce4 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -470,6 +470,13 @@ mmc_omap_xfer_done(struct mmc_omap_host *host, struct mmc_data *data)
 	if (!data) {
 		struct mmc_request *mrq = host->mrq;
 
+		/* TC before CC from CMD6 - don't know why, but it happens */
+		if (host->cmd && host->cmd->opcode == 6 &&
+		    host->response_busy) {
+			host->response_busy = 0;
+			return;
+		}
+
 		host->mrq = NULL;
 		mmc_request_done(host->mmc, mrq);
 		return;
-- 
1.5.6.3


[-- Attachment #5: 0004-omap_hsmmc-prevent-races-with-irq-handler.patch --]
[-- Type: text/x-diff, Size: 2061 bytes --]

>From ee637dbef6306a9b774b388d02ac81200906830c Mon Sep 17 00:00:00 2001
From: Adrian Hunter <adrian.hunter@nokia.com>
Date: Sat, 16 May 2009 10:32:34 +0300
Subject: [PATCH] omap_hsmmc: prevent races with irq handler

If an unexpected interrupt occurs while preparing the
next request, an oops can occur.

For example, a new request is setting up DMA for data
transfer so host->data is not NULL.  An unexpected
transfer complete (TC) interrupt comes along and
the interrupt handler sets host->data to NULL.  Oops!

Prevent that by disabling interrupts while setting up
a new request.

Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
---
 drivers/mmc/host/omap_hsmmc.c |   16 ++++++++++++++++
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index ee25ce4..751f63f 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -448,6 +448,13 @@ mmc_omap_start_command(struct mmc_omap_host *host, struct mmc_command *cmd,
 	if (host->use_dma)
 		cmdreg |= DMA_EN;
 
+	/*
+	 * In an interrupt context (i.e. STOP command), the interrupt is already
+	 * enabled, otherwise it is not (i.e. new request).
+	 */
+	if (!in_interrupt())
+		enable_irq(host->irq);
+
 	OMAP_HSMMC_WRITE(host->base, ARG, cmd->arg);
 	OMAP_HSMMC_WRITE(host->base, CMD, cmdreg);
 }
@@ -981,6 +988,13 @@ static void omap_mmc_request(struct mmc_host *mmc, struct mmc_request *req)
 	struct mmc_omap_host *host = mmc_priv(mmc);
 	int err;
 
+	/*
+	 * Prevent races with the interrupt handler because of unexpected
+	 * interrupts, but not if we are already in interrupt context i.e.
+	 * retries.
+	 */
+	if (!in_interrupt())
+		disable_irq(host->irq);
 	WARN_ON(host->mrq != NULL);
 	host->mrq = req;
 	err = mmc_omap_prepare_data(host, req);
@@ -991,6 +1005,8 @@ static void omap_mmc_request(struct mmc_host *mmc, struct mmc_request *req)
 			req->cmd->error = err;
 
 		mmc_omap_xfer_done(host, host->data);
+		if (!in_interrupt())
+			enable_irq(host->irq);
 		return;
 	}
 
-- 
1.5.6.3

RE: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Madhusudhan]

-----Original Message-----
From: linux-omap-owner@vger.kernel.org
[mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Adrian Hunter
Sent: Friday, June 12, 2009 2:26 AM
To: Hugo Vincent
Cc: Grazvydas Ignotas; Pandita, Vikram; linux-omap; General mailing list for
gumstix users.
Subject: Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

Hugo Vincent wrote:
> On 11/06/2009, at 9:29 PM, Grazvydas Ignotas wrote:
> 
>> On Thu, Jun 11, 2009 at 10:43 AM, Hugo
>> Vincent<hugo.vincent@gmail.com> wrote:
>>> On 11/06/2009, at 6:08 PM, Peter Barada wrote:
>>>
>>>> On Thu, 2009-06-11 at 15:35 +1200, Hugo Vincent wrote:
>>>>> On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikram<vikram.pandita@ti.com
>>>>> wrote:
>>>>>> Hugo
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: linux-omap-owner@vger.kernel.org
>>>>>>> [mailto:linux-omap-owner@vger.kernel.org] On Behalf Of Hugo
>>>>>>> Vincent
>>>>>>> Sent: Wednesday, June 10, 2009 9:14 PM
>>>>>>> To: linux-omap; General mailing list for gumstix users.
>>>>>>> Subject: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> I'm trying to get the MMC3 slot working on my OMAP3503 Gumstix
>>>>>>> Overo
>>>>>>> based board working.
>>>>>> Please check if your MMC3 Mux setting are as follows:
>>>>>> Note the input configuration for CLK and CMD. This is needed.
>>>>>>
>>>>>> /* MMC3 */
>>>>>> MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x1d0,
>>>>>>            OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x5d8,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>> MUX_CFG_34XX("AF13_3430_MMC3_DAT3", 0x5e2,
>>>>>>            OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
>>>>>>
>>>>>>
>>>>>> Also we will be soon (tomorrow) posting MUX patch for MMC1,2,3.
>>>>> Thanks for that Vikram. Unfortunately, these are the exact mux &
>>>>> pullup settings I was already using. (In my case, they were set by
>>>>> u-boot, but to be sure, I've copied and pasted the above exactly
>>>>> into
>>>>> mach-omap2/mux.c - same result). Any other ideas?
>>>> Are you using a 1.8V capable SD/MMC card?  MMC3 only works at 1.8V
>>>> on
>>>> the 3430 - MMC1 can work at 3V due to PBIAS register settings.  If
>>>> you're not, then the MMC can talk to the card, but the card can't
>>>> understand what its seeing due to the volatages of CLK/CMD being too
>>>> low...
>>> I am using a 3V SD card. But I'm also using TI TXS02612 for level
>>> translation (and to multiplex between two slots - but for now I
>>> only need to
>>> get one slot working and thus the select pin is wired high). I'm
>>> pretty
>>> confident that the level translation is working correctly as (a)
>>> the clk and
>>> cmd signals come out to the correct pins on the socket at the
>>> correct levels
>>> and (b) remultiplexing the datX signals as GPIOs and driving them is
>>> correctly reflected (and at the correct 3V levels) on the correct
>>> pins on
>>> the card socket. Similarly in the card->OMAP direction of signaling
>>> (they
>>> are of course bidirectional level translators).
>>>
>>> Do I need to somehow tell the mmc host or core driver that I have
>>> external
>>> level translation and therefore not to worry that the host only
>>> supports
>>> 1.8V cards?
>> The TRM says MMC3 "is used without external transceiver" [only?].
>> Doesn't the transceiver need additional control signals (dir_cmd and
>> dir_dat[2:0]), that are only provided by MMC2?
> 
> You are quite possibly correct, but the level translator I'm using is
> "invisible" - it doesn't require the transceiver control signals
> offered only on MMC2. So as far as I know, there is no hardware reason
> the OMAP MMC3 controller couldn't talk correctly at the electrical
> level with the card. This is evidenced by the CMD signal being
> correctly level translated (and this is via the same type of level
> translator as the data signals are according to the TXS02612
> datasheet), and toggling correctly(-looking) at the card socket (i.e.
> between 0 and 3.3V and it's edges synced to the clock signal). The
> DAT0-DAT3 signals never do anything though.
> 
> Hugo
> 
>>> Thanks for your help!
>>>
>>> Hugo
>>>
>>>>>>> Compiling 2.6.29-omap1 with
>>>>>>>  CONFIG_MMC=y
>>>>>>>  CONFIG_MMC_DEBUG=y
>>>>>>>  CONFIG_MMC_BLOCK=y
>>>>>>>  CONFIG_MMC_BLOCK_BOUNCE=y
>>>>>>> and MMC polling enabled (mmc->caps |= MMC_CAP_NEEDS_POLL; in
>>>>>>> omap_hsmmc.c)
>>>>>>>
>>>>>>> then doing: $ echo 8 > /proc/sys/kernel/printk
>>>>>>> gives the following:
>>>>>>>
>>>>>>> clock 0Hz busmode 1 powermode 1 cs 0 Vdd 20 width 0 timing 0
>>>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0
>>>>>>> timing 0
>>>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0
>>>>>>> timing 0
>>>>>>> mmc2: starting CMD0 arg 00000000 flags 000000c0
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
>>>>>>> mmc2: req done (CMD0): 0: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0
>>>>>>> timing 0
>>>>>>> mmc2: starting CMD8 arg 000001aa flags 000002f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x000001aa
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD8): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD5 arg 00000000 flags 000002e1
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req failed (CMD5): -110, retrying...
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD5): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD55 arg 00000000 flags 000000f5
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD55): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: starting CMD1 arg 00000000 flags 000000e1
>>>>>>> mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x00000000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
>>>>>>> mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI CTO
>>>>>>> mmc2: req done (CMD1): -110: 00000000 00000000 00000000 00000000
>>>>>>> mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0
>>>>>>>
>>>>>>> It seems every request returns -110 which is -ETIMEDOUT.
>>>>>>>
>>>>>>> I've checked the hardware, and it appears to be correct (level
>>>>>>> translators etc seem to be doing their job).
>>>>>>>
>>>>>>> During polling, the CMD and CLK signals show activity, but the
>>>>>>> data
>>>>>>> lines never change; this is presumably why every request is
>>>>>>> timing
>>>>>>> out.
>>>>>>>
>>>>>>> I've also tried it with 2.6.30-omap1 in git, which changes some
>>>>>>> MMC3-specific stuff (notably DMA), but has the exact same
>>>>>>> behaviour.
>>>>>>>
>>>>>>> I've also checked pin multiplexing settings and confirmed that
>>>>>>> the
>>>>>>> correct values are set for the MMC3 data pins. The card I'm
>>>>>>> using is a
>>>>>>> microSD card that works when attached to MMC1 (the Gumstix Overo
>>>>>>> built-in microSD slot). The slot is powered by 3.3V that is
>>>>>>> always on,
>>>>>>> there is no provision for power switching with this particular
>>>>>>> board.
>>>>>>>
>>>>>>> Any ideas?
>>>>>>>
>>>>>>> Many thanks,
>>>>>>> Hugo Vincent

We have fixed a few bugs in omap_hsmmc.c that we have not had time
to send to mainline, but will hopefully in the coming weeks.

I have attached some patches which probably do not apply cleanly,
and may not help with your problem anyway.

Hugo,

Your CLK and CMD line mux does not look correct to me.

Try the below settings.

MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x5d8,
                OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x1d0,
                OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)

CMD1 can never go through if your MUX is wrong.

Let me know if this helps.

Regards,
Madhu

Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Hugo Vincent]

On Sat, Jun 13, 2009 at 3:40 AM, Madhusudhan<madhu.cr@ti.com> wrote:
<snip>
> Hugo,
>
> Your CLK and CMD line mux does not look correct to me.
>
> Try the below settings.
>
> MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x5d8,
>                OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
> MUX_CFG_34XX("AC3_3430_MMC3_CMD", 0x1d0,
>                OMAP34XX_MUX_MODE3 | OMAP34XX_PIN_INPUT_PULLUP)
>
> CMD1 can never go through if your MUX is wrong.
>
> Let me know if this helps.
>
> Regards,
> Madhu

Thanks Madhu. Your updated settings seem wrong to me (at least for the
way my particular board is wired). Perhaps there is a difference
between the 3430 and 3503 in this respect (I don't have the 3430
datasheet so can't check). Note I'm using MMC3_CLK and CMD that are
muxed on balls AF10 and AE10. It's a shame Gumstix chose not to
publish the Overo modules' schematics - having them would have made
this problem much easier to debug!

After some experimentation, the following mux settings are working
with my hardware:

+/* MMC3 */
+MUX_CFG_34XX("AF10_3430_MMC3_CLK", 0x5d8,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AE10_3430_MMC3_CMD", 0x5da,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AE11_3430_MMC3_DAT0", 0x5e4,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AH9_3430_MMC3_DAT1", 0x5e6,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AF13_3430_MMC3_DAT2", 0x5e8,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)
+MUX_CFG_34XX("AE13_3430_MMC3_DAT3", 0x5e2,
+		OMAP34XX_MUX_MODE2 | OMAP34XX_PIN_INPUT_PULLUP)

For the archive, it looks like the ehci driver (which has some hackish
out-of-tree patches specific to the Overo) was messing up my padconf
settings even though they were correct in u-boot. The other
possibility, is that u-boot wasn't defining the CLK signal with input
enable; this gives the following mux debug message:
MUX: setup AF10_3430_MMC3_CLK (0xd80025d8): 0x001a -> 0x011a

Thanks everyone for your help!

Hugo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: OMAP3xxx hsmmc : MMC3 doesn't work, always times out?

[Hugo Vincent]

Thanks for that. These don't help specifically with my problem, but
are none-the-less valuable, and seem to make MMC more reliable when
the system is heavily loaded.

On Fri, Jun 12, 2009 at 7:25 PM, Adrian Hunter<adrian.hunter@nokia.com> wrote:
<snip>
> We have fixed a few bugs in omap_hsmmc.c that we have not had time
> to send to mainline, but will hopefully in the coming weeks.
>
> I have attached some patches which probably do not apply cleanly,
> and may not help with your problem anyway.
>