DM8148 MMC

Hi Zengxing yuan,

1. Change the PINMUX settings to get GPIO1_15 as required functionality

2. Modify the board file (arch/arm/mach-omap2/board-ti8148evm.c) to export GPIO to mmc driver

- .gpio_cd        = -EINVAL, /* Dedicated pins for CD and WP */

+.gpio_cd        = 32 * 1 + 15, /* Dedicated pins for CD and WP */

Note: Make sure that you are not breaking the some other functionality (step 1)

Regards

AnilKumar

Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

I think you'll need to patch drivers/mmc/host/omap_hsmmc.c, because the 814x code paths do not support a gpio CD pin.   If you look near line 211 you'll see that if the version = MMC_CTRL_VERSION_2 it will not check the gpio value.  I replaced that if() statement with

if (gpio_is_valid(mmc->slots[0].switch_pin))

You need to make the same change in omap_hsmmc_get_cover_state(), around line 265

Hi  Chambers,

    I patched the drivers/mmc/host/omap_hsmmc.c,but it did not work.

    I found a error during initialization the mmc:

    <3>_omap_mux_init_gpio: Could not set gpio47

    Did you have the same problem?

Hi AnilKumar,

     We use the MMC0 controller,but the DM8148 EVM Board use the MMC1controller.

    Is there any difference between them?

Regards

zengxingyuan

I used gpio53, but I do get the same message, but the card detect logic works.  I'm not sure what code is trying to set the gpio, but since it's an input it makes sense that a 'set' fails.

When I was figuring this code out, I just coded a "return 0" (active low logic) instead of reading the gpio.  That way the SD card shows as always installed.  Then when the rest of the SD driver was working I went back and figured out the card detect logic.

I believe the mux error is due to a couple of reasons. First is that the GPIO numbers are not properly defined in ti814x_muxmodes table. See

arch/arm/mach-omap2/mux814x.c
...
static struct omap_mux __initdata ti814x_muxmodes[] = {
...
    _TI814X_MUXENTRY(GPMC_A20, 0,
            "gpmc_a_20_mux0", NULL, "spi2_cs1", NULL, NULL, NULL,
            NULL, "gpio1_15_mux0"),
...
    _TI814X_MUXENTRY(MMC2_CLK, 0,
            "mmc2_clk", NULL, NULL, NULL, NULL, NULL, NULL,
            "gpio1_15_mux1"),
...
    { .reg_offset = OMAP_MUX_TERMINATOR },
};

Note the 0's. In the above entries, 0 should be 47. GPIO47 can be muxed to 2 different pins. That leads to the second problem. The omap_mux_init_gpio() function is written to assume that a GPIO can muxed to only one pin. It will check for multiple assignments. The SD card pins are muxed here:

arch/arm/mach-omap2/devices.c
...
static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
            int controller_nr)
{
    if ((mmc_controller->slots[0].switch_pin > 0) && \
        (mmc_controller->slots[0].switch_pin < OMAP_MAX_GPIO_LINES))
        omap_mux_init_gpio(mmc_controller->slots[0].switch_pin,
                    OMAP_PIN_INPUT_PULLUP);
    if ((mmc_controller->slots[0].gpio_wp > 0) && \
        (mmc_controller->slots[0].gpio_wp < OMAP_MAX_GPIO_LINES))
        omap_mux_init_gpio(mmc_controller->slots[0].gpio_wp,
                    OMAP_PIN_INPUT_PULLUP);
...
};

Possible solutions.
- Define only one entry in table ti814x_muxmodes with 47.
- Change the omap_mux_init_gpio() calls to omap_mux_init_signal() calls with the named pin "gpio1_15_mux0" or "gpio1_15_mux1".

Hi  Chambers,

     we use MMC0 controller,but i found the DM8148 EVM board used MMC1 controller.

    In psp4.4.0.1kernel there is no description about MMC0.

    linux-2.6.37/arch/arm/mach-omap2 device.c

    1077:  else if (cpu_is_ti814x()) {

    1078:       base = TI814X_MMC1_BASE;

    1079:       irq = TI814X_IRQ_SD1;
  linux-2.6.37\arch\arm\plat-omap\include\plat mmc.h

 43:  #define TI814X_MMC1_BASE 0x481D8100 /* TI814X MMC/SD config base */

 44:  #define TI814X_MMC1_HL_BASE 0x481D8000 /* TI814X HL configuration*/

There is no TI814X_MMC0_BASE

Hi Zengxing,

Can you follow these steps for using MMC0

http://processors.wiki.ti.com/index.php/TI81xx_PSP_Porting_Guide#MMC.2FSD_Driver

Don't follow this post http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/179512/646984.aspx#646984

This is not required in case of DM8148, stright away MMC0 card detect will work.

Regards

AnilKumar

Please mark this Forum post as answered via the Verify Answer button below if it helps answer your question.  Thanks!

Hi AnilKumar,

I have an question regarding MMC0 configuration. According to the link above (http://processors.wiki.ti.com/index.php/TI81xx_PSP_Porting_Guide#MMC.2FSD_Driver), MMC0 has 8 bits, Does it means that MMC0 should be 8 bits interface ? - not 1bit or 4bit. If 4bit mode is used, how do I configure them ?

The problem I have had is "not detected by DM8148" at all. I have gone through with the link except DMA part but still MMC0 is not detected by DM8148. It is already pointed out and asked but there is no clear answer. The question is "how to set TI814X_MMC1_BASE". From Datasheet (p335, MMC/SD/SDIO Peripheral Register Descriptions http://www.ti.com/lit/ds/symlink/tms320dm8148.pdf), the base address for MMC0 is "0x48060100" not "0x481D8100". Also where does the offset - 0x100 come from ? It is not 0x110 ? 

Please let me know if I have any mistake. Have a good weekend.

Regards,

SK

HI all,

Any further information and success case ? Basically, the main reason why I asked above questions are to verify the information which are not matched between kernel code(func omap2_init_mmc, ~/arch/arm/mach-omap2/devices.c and datasheet(p335, http://www.ti.com/lit/ds/symlink/tms320dm8148.pdf) as following.

According to the linux kernel, the base address can be read as a TI814X_MMC1_BASE -  0x481D8100 in ~/arch/arm/plat-omap/include/plat/mmc.h

} else if (cpu_is_ti814x()) {
base = TI814X_MMC1_BASE;   <-- there is no such TI814X_MMC0_BASE ??
#ifdef CONFIG_TI8148EVM_WL12XX
irq = TI81XX_IRQ_SD;
#else
irq = TI814X_IRQ_SD1; <-- supposed to be TI814X_IRQ_SD(64) ??
#endif

From datasheet

MMC/SD/SDIO0 address : 0x4806 0000

MMC/SD/SDIO1 address : 0x481D 8000

MMC/SD/SDIO2 address : 0x4781 0000

Actually, I have used two different base address and compared the result but no luck because of confused register map. What I got so far is that MMC/SD driver doesn't detect the SDHC card at all. 

Any advice or suggestion ? 

Best Regards,

SK

Looks like TI wrote the code to pretend that MMC0 does not exist and counts MMC1 as the first port. Makes it difficult to support more than one MMC. The constant changing back and forth from 0 base and 1 base indexing is quite confusing. The base addresses are offset by 0x100 because registers offsets in "drivers/mmc/host/omap_hsmmc.c" are shifted by 0x100. You mention you tried difference base addresses. Do you try this sort of change:

arch/arm/plat-omap/include/plat/mmc.h
#define TI814X_MMC0_BASE    0x48060100 /*ADD*/

arch/arm/mach/omap2/devices.c:omap2_init_mmc()
base = TI814X_MMC0_BASE;/*Was TI814X_MMC1_BASE*/
irq = TI81XX_IRQ_SD;    /*Was TI814X_IRQ_SD1  */

There are probably mux and clocks that you have to chase down.

Hi Norman,

Thank you for the reply. I agreed with you. TI MMC code doesn't look consistence and organized. As you pointed out, I have added them and checked mux, power - always on, clock - sysclk8. They looks good and mmc card is detected. Actually it is done by ISR then that's all, nothing more like communication. Even no clock - SD_CLK is provided by DM8148. The "CM_ALWON_MMCHS_0_CLKCTR" register has been set to "0x02" - enable.  According to the wiki page (http://processors.wiki.ti.com/index.php/TI81xx_PSP_Porting_Guide#MMC.2FSD_Driver), the clock source seems like "sysclk6" -  not sysclk8 

"The clocking sequence for mmc0 in DM8148 is as follows 20MHz OSC0 / 20-30Mhz OSC1 (VCXO optional off-chip) -> mainpll_oscclkmx -> DPLL_L3 (GS70 ADPLLLJ) -> dividers -> SYSCLK6 -> MMCHS0" <--- really confused.

I believe that I miss something for initialization of MMC. I'm going to check everything from beginning.

Regards,

SK

Sounds like you have something going. The other thing to look for is the Write Protect and Card Detect lines. These are GPIOs. Usually WP and CD can be optional. If not specified, The MMC driver is supposed to assume always writeable and always inserted. If you are using a custom board, check the pullups. Assuming your processor doesn't have internal pullups.

Hi Norman,

Let me ask a question regarding mmc0. I believe that mmc configuration looks fine and write protect is set to "active high" - actually pull-down on my custom board. I don't think that it bothers me. So far, some CMD and associated IRQ status show up - no error reported on IRQ status but I guess that somehow the communication is not complete middle of "Identification and Selection" procedure - p2069 TRM, http://www.ti.com/lit/ug/sprugz8a/sprugz8a.pdf. I didn't check the message in detail but the most of sequence are in the logs as following.  Basically, my modification is based on mmc.rtf file from Viet Dinh, http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/144963.aspx. The some difference I made comes from MMC0 interface instead of MMC2 on the explanation.

Any advice and idea would help me.

Best Regards,

SK

MMC0 log when a card is inserted

mmc1: starting CMD52 arg 00000c00 flags 00000195
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x00000c00
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO
mmc1: req done (CMD52): -110: 00000000 00000000 00000000 00000000
mmc1: starting CMD52 arg 80000c08 flags 00000195
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD52, argument 0x80000c08
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO
mmc1: req done (CMD52): -110: 00000000 00000000 00000000 00000000
mmc1: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 21 width 0 timing 0
>>>>>>> omap_hsmmc_set_ios
mmc1: starting CMD0 arg 00000000 flags 000000c0
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD0): 0: 00000000 00000000 00000000 00000000
mmc1: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
>>>>>>> omap_hsmmc_set_ios
mmc1: starting CMD8 arg 000001aa flags 000002f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x000001aa
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD8): 0: 000001aa 00000000 00000000 00000000
mmc1: starting CMD5 arg 00000000 flags 000002e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO
mmc1: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO
mmc1: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO
mmc1: req failed (CMD5): -110, retrying...
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000
mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO
mmc1: req done (CMD5): -110: 00000000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00400120 00000000 00000000 00000000
mmc1: starting CMD41 arg 00000000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
>>>>>>> omap_hsmmc_set_ios
mmc1: clock 400000Hz busmode 1 powermode 2 cs 1 Vdd 21 width 0 timing 0
>>>>>>> omap_hsmmc_set_ios
mmc1: starting CMD0 arg 00000000 flags 000000c0
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD0): 0: 00000000 00000000 00000000 00000000
mmc1: clock 400000Hz busmode 1 powermode 2 cs 0 Vdd 21 width 0 timing 0
>>>>>>> omap_hsmmc_set_ios
mmc1: starting CMD8 arg 000001aa flags 000002f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x000001aa
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD8): 0: 000001aa 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: 00ff8000 00000000 00000000 00000000
mmc1: starting CMD55 arg 00000000 flags 000000f5
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000120 00000000 00000000 00000000
mmc1: starting CMD41 arg 40200000 flags 000000e1
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD41, argument 0x40200000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD41): 0: c0ff8000 00000000 00000000 00000000
mmc1: starting CMD2 arg 00000000 flags 00000067
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD2, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD2): 0: 1e414253 44432020 10000004 6400a901
mmc1: starting CMD3 arg 00000000 flags 00000075
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD3, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD3): 0: b3680520 00000000 00000000 00000000
mmc1: clock 400000Hz busmode 2 powermode 2 cs 0 Vdd 21 width 0 timing 0
>>>>>>> omap_hsmmc_set_ios
mmc1: starting CMD9 arg b3680000 flags 00000007
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD9, argument 0xb3680000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD9): 0: 400e0032 5b590000 3bb77f80 0a400085
mmc1: starting CMD7 arg b3680000 flags 00000015
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD7, argument 0xb3680000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD7): 0: 00000700 00000000 00000000 00000000
mmc1: starting CMD55 arg b3680000 flags 00000095
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0xb3680000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1
mmc1: req done (CMD55): 0: 00000920 00000000 00000000 00000000
mmc1: starting CMD51 arg 00000000 flags 000000b5
mmc1:     blksz 8 blocks 1 flags 00000200 tsac 100 ms nsac 0
mmci-omap-hs mmci-omap-hs.1: mmc1: CMD51, argument 0x00000000
mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1

Sorry, I can't help with MMC protocol analysis. Did it once. Forgotten it all. Vaguely remember that depending on how the card responds to commands. the driver will assume a certain size class and bus speed. Usually the driver will print out lots of messages if something is out of step.

When I say pullups, I mean the MMC lines. ie data. etc. Some chips have internal pullups. Another possible HW problem I encountered is a supply voltage that is a little too high. For me it happened my 3.3V supply wandered to 3.4. That can cause logic levels to be confused in the MMC data lines.

Hi all,

I'm going to jump in the "MMC protocol" world to verity the communication procedure. Before doing that, I really like to confirm if or not anyone succeed to get mmc0 working on DM8148. As far as I know, some guy such as Viet Dinh did it for mmc2 but mmc0. I know that this question sounds silly but I'd like to confirm that. If no body does that, I'm going to consider to go with mmc1 instead of mmc0 and mmc2.

Please let me know whether or not the mm0 on DM8148 works.

Best Regards,

SK

By mmc0, you mean the SD0_xxx lines?  Yes, we hacked the kernel drivers to make mmc0 work.  I'm not sure we got hot-plug working for mmc0.  We use pin P22 on our board for Detect, and it definitely works completely if the SD card is installed at boot time, but I think our guys are still working on getting the SD card to automount if it's inserted later.  I don't have all the details of how we hacked the drivers, but I can tell you that the SD0 port does physically work.  We have a 4-bit interface on our board, btw.

Hi Mark,

I appreciated your information. I will keep digging. I guess that I am walking around destination but I couldn't see it. I means that the communication between them looks complete according to TI TRM, p2069, even though it doesn't show every detail command and correspond respond, the very last command is "CMD7 - MMC_CMD_SELECT" and it has been shown up in the kernel log. I believe that the next step would be mmc_blk_probe function called and register it as a mmcblk0.

Anyhow, thank for any advice in advance.

Regards,

SK

Hi all,

I'd like to update the status of mmc0 implementation and share some idea. I have gotten mmc0 working, which means that negotiation is complete  on DM8148 and mmc card type and size are displayed on the console. After that, the kernel complains a lot of I/O error on mmcblk0 as below. The problem was mis-matched DMA configuration - I use SDTXEVT0/SDRXEVT0 as DMA event. 

I have changed the clock  from 50000000 to 48000000, 12000000 or 400000 as well as tweaked time-out. None of way works.  Any suggestion is welcome and appreciated.

Best Regard,

SK

ios->clock=50000000,host->fclk=192000000,dsor=4
SYSCTL=000e0107,con=00000600,host->power_mode =2,SYSCTL=000e0107,HCTL=00000d02
mmc1: new high speed SDHC card at address 1234
mmcblk0: mmc1:1234 SA08G 7.40 GiB
mmcblk0: retrying using single block read
mmcblk0: error -84 transferring data, sector 0, nr 8, card status 0x900
end_request: I/O error, dev mmcblk0, sector 0
mmcblk0: error -84 transferring data, sector 1, nr 7, card status 0x900
end_request: I/O error, dev mmcblk0, sector 1
mmcblk0: error -84 transferring data, sector 2, nr 6, card status 0x900
end_request: I/O error, dev mmcblk0, sector 2
mmcblk0: error -84 transferring data, sector 3, nr 5, card status 0x900
end_request: I/O error, dev mmcblk0, sector 3
mmcblk0: error -84 transferring data, sector 4, nr 4, card status 0x900
end_request: I/O error, dev mmcblk0, sector 4
mmcblk0: error -84 transferring data, sector 5, nr 3, card status 0x900
end_request: I/O error, dev mmcblk0, sector 5
mmcblk0: error -84 transferring data, sector 6, nr 2, card status 0x900
end_request: I/O error, dev mmcblk0, sector 6
mmcblk0: error -84 transferring data, sector 7, nr 1, card status 0x900
end_request: I/O error, dev mmcblk0, sector 7
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: retrying using single block read
mmcblk0: error -84 transferring data, sector 0, nr 8, card status 0x900
end_request: I/O error, dev mmcblk0, sector 0
mmcblk0: error -84 transferring data, sector 1, nr 7, card status 0x900
end_request: I/O error, dev mmcblk0, sector 1
mmcblk0: error -84 transferring data, sector 2, nr 6, card status 0x900
end_request: I/O error, dev mmcblk0, sector 2
mmcblk0: error -84 transferring data, sector 3, nr 5, card status 0x900
end_request: I/O error, dev mmcblk0, sector 3
mmcblk0: error -84 transferring data, sector 4, nr 4, card status 0x900
end_request: I/O error, dev mmcblk0, sector 4
mmcblk0: error -84 transferring data, sector 5, nr 3, card status 0x900
end_request: I/O error, dev mmcblk0, sector 5
mmcblk0: error -84 transferring data, sector 6, nr 2, card status 0x900
end_request: I/O error, dev mmcblk0, sector 6
davinci_mdio davinci_mdio.0: timed out waiting for user access

mmcblk0: error -84 transferring data, sector 7, nr 1, card status 0x900
end_request: I/O error, dev mmcblk0, sector 7
Buffer I/O error on device mmcblk0, logical block 0
mmcblk0: unable to read partition table

Hi all,

I'd like to update and share my process regarding mmc0 implementation. Speaking shortly, it works with 1bit wide. The clock and voltage are not key factor to get it working. I have tested on 1bit wide but I didn't change both side. That's why it didn't work at that time. The SD card on mm0 works magically without any complains such as -84 transfer error. 

I need to ask TI official answer regarding mmc0 bit wide. The question would be if or not my hack is correct and reasonable ? It is important for us because 1bit data is not sufficient and risky. 

Please let me know the answer.

Best Regards,

SK

Hi SEUNGSIK,

I am curious if you have made any progress about accessing SD card on MMC#0 using 4-bit wide bus.

We are in a similar situation;  

• Custom 8148 board with MMC#0 for SD cared,  using 4-bit wide connection.
• EZSDK 5_05_02_00

We are currently trying to access SD card from 2nd stage u-boot.  

The problem is:

• Accessing SD card always fails at first, but sometimes it works afterwards.  Once it worked, then keeps working forever.  Sometimes, just connecting from JTAG makes it work.
• When it doesn't work, SD0_CLK is not generated, and we get IE_CTO errors.

So the symptom seems very similar to what you had when you were trying to use 4bit..

I have tried everything I can think of (changing timing by putting sleeps, resetting MMC interface, etc.) but can't figure out what triggers the successful access.  I have not tried using 1-bit mode yet.  If I cannot find anything else, I will try it.

Thanks,
tamo2 

Since no one has shared a complete solution for MMC0 anywhere on the forum, here's mine:

TI driver is written to only work with MMC1, it assumes MMC0 doesn't exist. Indexing is also very confusing, constantly changing between 0 and 1 indexing in various parts of the driver. We will change the driver so that the omap2_hsmmc_info structure in arch/arm/mach-omap2/board-ti8148evm.c uses 1 indexing for mmc ports instead of 0 indexing. This is easiest since the driver is written to use a .mmc value of 0 as a null terminator in the list of mmc instances. These instructions work for MMC0 and 1, MMC2(not used in my use case) requires additional changes as outlined in the famous MMC.rtf found elsewhere on this forum. I believe more DMA changes are needed as MMC2 is on a muxed DMA channel. In my case the PRCM and clocking registers were already set correctly so the MMC0 module was already powered up. MMC.rtf has more info on setting PRCM/clocking registers as well as DMA settings for MMC2.

Set up pin muxing as required for whatever pins you've put MMC0 on.

in arch/arm/mach-omap2/board-ti8148evm.c, update the omap2_hsmmc_info mmc structure for the new driver. This is an example that uses hardware MMC ports 0 and 1:

static struct omap2_hsmmc_info mmc[] = {
	{
		.mmc		= 1,
		.caps		= MMC_CAP_4_BIT_DATA,
		.gpio_cd	= 14,
		.gpio_wp	= 13,
		.ocr_mask	= MMC_VDD_33_34,
	},
	{
		.mmc		= 2, //This is now the boot MMC port, hardware port 1
		.caps		= MMC_CAP_4_BIT_DATA,
		.gpio_cd	= -EINVAL, /* Dedicated pins for CD and WP */
		.gpio_wp	= -EINVAL,
		.ocr_mask	= MMC_VDD_33_34,
	},
	{}	/* Terminator */
};

Change register base addresses and IRQs for our new indexing

in arch/arm/mach-omap2/devices.c change switch statement cases 0-2 in omap2_init_mmc to:

		switch (i) {
		case 0:
			if (!cpu_is_ti81xx()) {
				base = OMAP2_MMC1_BASE;
				irq = INT_24XX_MMC_IRQ;
			} else if (cpu_is_ti816x()) {
				base = TI816X_MMC1_BASE;
				irq = TI81XX_IRQ_SD;
			} else if (cpu_is_ti814x()) {
				base = TI814X_MMC0_BASE;
				irq = TI81XX_IRQ_SD;
			}
			break;
		case 1:
			if (cpu_is_ti814x()) {
				base = TI814X_MMC1_BASE;
				irq = TI814X_IRQ_SD1;
			}
			else
			{
				base = OMAP2_MMC2_BASE;
				irq = INT_24XX_MMC2_IRQ;
			}
			break;
		case 2:
			if (cpu_is_ti814x()) {
				base = TI814X_MMC2_BASE;
				irq = TI814X_IRQ_SD2;
			}
			else if (!cpu_is_omap44xx() && !cpu_is_omap34xx()) {
				return;
			}
			else
			{	
				base = OMAP3_MMC3_BASE;
				irq = INT_34XX_MMC3_IRQ;
			}
			break;

The stock TI driver has no provisions for CD and WP pins on GPIOs, it only supports CD and WP on MMC module dedicated pins. Configuration is provided in the mmc structure for these, and GPIOs/interrupts are even set up accordingly, but the driver completely ignores them. To work around this, setting the version field to MMC_CTRL_VERSION_1 seems to work. This requires both CD and WP to be on GPIOs
in arch/arm/mach-omap2/omap_hsmmc.c, replace

		if (cpu_is_ti81xx())
			mmc->version = MMC_CTRL_VERSION_2;
with
		//If we're DM81xx and we're using MMC module CD pin (not GPIO),
		//use V2, otherwise use V1 to use GPIOs
		if (cpu_is_ti81xx() && -EINVAL == c->gpio_cd)
			mmc->version = MMC_CTRL_VERSION_2;
		else
			mmc->version = MMC_CTRL_VERSION_1;

Add DMA defines according to datasheet DMA channels, and rename existing ones because we've changed the indexing from 0 indexing to 1 indexing. These are used in arcm/arm/plat-omap/devices.c omap_mmc_add() (Note this is a different devices.c than above!)
in arcm/arm/plat-omap/include/plat/dma.h,
move the #endif at line 217 down to enclose the lines

#define OMAP24XX_DMA_SPI2_TX0		43	/* S_DMA_42 */
#define OMAP24XX_DMA_SPI2_RX0		44	/* S_DMA_43 */

replace lines 188-189 with:
#define OMAP24XX_DMA_MMC1_RX		25
#define OMAP24XX_DMA_MMC1_TX		24
#define OMAP24XX_DMA_MMC2_RX		3
#define OMAP24XX_DMA_MMC2_TX		2

Add new base addresses for other MMC controllers
in arcm/arm/plat-omap/include/plat/mmc.h, replace the 6 lines starting at 39 with

#define TI81XX_NR_MMC		3
#define TI81XX_HSMMC_SIZE	0x10000
#define TI816X_MMC1_BASE	0x48060100 /* TI816X MMC/SD config base */
#define TI816X_MMC1_HL_BASE	0x48060000 /* TI816X HL configuration*/
#define TI814X_MMC0_BASE	0x48060100 /* TI814X MMC/SD 0 config base */
#define TI814X_MMC0_HL_BASE	0x48060000 /* TI814X HL configuration*/
#define TI814X_MMC1_BASE	0x481D8100 /* TI814X MMC/SD 1 config base */
#define TI814X_MMC1_HL_BASE	0x481D8000 /* TI814X HL configuration*/
#define TI814X_MMC2_BASE	0x47810100 /* TI814X MMC/SD 2 config base */
#define TI814X_MMC2_HL_BASE	0x47810000 /* TI814X HL configuration*/