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

2009-06-12 Thread Madhusudhan


-Original Message-
From: linux-omap-ow...@vger.kernel.org
[mailto:linux-omap-ow...@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
 Vincenthugo.vinc...@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, Vikramvikram.pand...@ti.com
 wrote:
 Hugo

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org
 [mailto:linux-omap-ow...@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 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0
 timing 0
 mmc2: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0
 timing 0
 mmc2: starting CMD0 arg  flags 00c0
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x
 mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
 mmc2: req done (CMD0): 0:    
 mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0
 timing 0
 mmc2: starting CMD8 arg 01aa flags 02f5
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8

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

2009-06-12 Thread 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 Hunteradrian.hun...@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.

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


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

2009-06-12 Thread Hugo Vincent
On Sat, Jun 13, 2009 at 3:40 AM, Madhusudhanmadhu...@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 majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-06-11 Thread Peter Barada
On Thu, 2009-06-11 at 15:35 +1200, Hugo Vincent wrote:
 On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikramvikram.pand...@ti.com wrote:
  Hugo
 
 -Original Message-
 From: linux-omap-ow...@vger.kernel.org 
 [mailto:linux-omap-ow...@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 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
 mmc2: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
 mmc2: starting CMD0 arg  flags 00c0
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x
 mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
 mmc2: req done (CMD0): 0:    
 mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
 mmc2: starting CMD8 arg 01aa flags 02f5
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x01aa
 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:    
 mmc2: starting CMD5 arg  flags 02e1
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
 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 0x
 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 0x
 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 0x
 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:    
 mmc2: starting CMD55 arg  flags 00f5
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
 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:    
 mmc2: starting CMD55 arg  flags 00f5
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
 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:    
 mmc2: starting CMD55 arg  flags 00f5
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
 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:    
 mmc2: starting CMD55 arg  flags 00f5
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
 mmci-omap-hs mmci-omap-hs.2: IRQ Status is 18000
 mmci-omap-hs mmci-omap-hs.2: MMC IRQ 0x18000 : ERRI 

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

2009-06-11 Thread 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, Vikramvikram.pand...@ti.com 
 wrote:

Hugo


-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@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 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0  
timing 0
mmc2: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0  
timing 0

mmc2: starting CMD0 arg  flags 00c0
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
mmc2: req done (CMD0): 0:    
mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0  
timing 0

mmc2: starting CMD8 arg 01aa flags 02f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x01aa
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:    
mmc2: starting CMD5 arg  flags 02e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
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 0x
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 0x
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 0x
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:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
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:    

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

2009-06-11 Thread Grazvydas Ignotas
On Thu, Jun 11, 2009 at 10:43 AM, Hugo Vincenthugo.vinc...@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, Vikramvikram.pand...@ti.com
 wrote:

 Hugo

 -Original Message-
 From: linux-omap-ow...@vger.kernel.org
 [mailto:linux-omap-ow...@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 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
 mmc2: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
 mmc2: starting CMD0 arg  flags 00c0
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x
 mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
 mmc2: req done (CMD0): 0:    
 mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
 mmc2: starting CMD8 arg 01aa flags 02f5
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x01aa
 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:    
 mmc2: starting CMD5 arg  flags 02e1
 mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
 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 0x
 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 0x
 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 0x
 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:   

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

2009-06-11 Thread 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
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

2009-06-10 Thread Pandita, Vikram
Hugo

-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@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 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
mmc2: starting CMD0 arg  flags 00c0
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
mmc2: req done (CMD0): 0:    
mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: starting CMD8 arg 01aa flags 02f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x01aa
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:    
mmc2: starting CMD5 arg  flags 02e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
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 0x
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 0x
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 0x
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:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
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:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
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:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
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:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
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:    
mmc2: starting CMD1 arg  flags 00e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x
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:    
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 

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

2009-06-10 Thread Hugo Vincent
On Thu, Jun 11, 2009 at 2:39 PM, Pandita, Vikramvikram.pand...@ti.com wrote:
 Hugo

-Original Message-
From: linux-omap-ow...@vger.kernel.org 
[mailto:linux-omap-ow...@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 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 20 width 0 timing 0
mmc2: starting CMD0 arg  flags 00c0
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD0, argument 0x
mmci-omap-hs mmci-omap-hs.2: IRQ Status is 1
mmc2: req done (CMD0): 0:    
mmc2: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 20 width 0 timing 0
mmc2: starting CMD8 arg 01aa flags 02f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD8, argument 0x01aa
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:    
mmc2: starting CMD5 arg  flags 02e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD5, argument 0x
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 0x
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 0x
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 0x
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:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
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:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
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:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
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:    
mmc2: starting CMD55 arg  flags 00f5
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD55, argument 0x
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:    
mmc2: starting CMD1 arg  flags 00e1
mmci-omap-hs mmci-omap-hs.2: mmc2: CMD1, argument 0x
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:    
mmc2: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0

It seems every