logo

Could not compile stylesheet for simplistic. Using last compiled stylesheet.
Bug

IGEP Module and MMC3

posted in IGEP COM MODULE
Tuesday, August 14 2012, 03:25 PM
0
Hi

on our base board we want to use MMC3 for SDHC access. So we connected the SDHC slot to the etk-lines at the J4 connector via an "invisible" tranceiver in order to use 3.3V cards.

J4:23 cmd
J4:40 clk
J4:26 d0
J4:36 d1
J4:39 d2
J4:31 d3

BTW: The hardware reference manual from 2011-11-28 has an error in the decription for j4:39: It reads "mmc_data1" instead of "mmc_dat2".

So I expanded the mux definition
static struct omap_board_mux board_mux[] __initdata = {
with

	/* WLAN SDIO: MMC3 CMD */
	OMAP3_MUX(ETK_CTL, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
	/* WLAN SDIO: MMC3 CLK */
	OMAP3_MUX(ETK_CLK, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
	/* WLAN SDIO: MMC3 DAT[0-3] */
	OMAP3_MUX(ETK_D3, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
	OMAP3_MUX(ETK_D4, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
	OMAP3_MUX(ETK_D5, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),
	OMAP3_MUX(ETK_D6, OMAP_MUX_MODE2 | OMAP_PIN_INPUT_PULLUP),


added a regulator

static struct regulator_init_data igep_vmmc3 = {
        .constraints = {
                .valid_ops_mask   = REGULATOR_CHANGE_STATUS,
                .valid_modes_mask = REGULATOR_MODE_NORMAL,
                .min_uV           = 1850000,
                .max_uV           = 1850000,
                .apply_uV         = true,
                .always_on        = true,
        },
	.num_consumer_supplies  = ARRAY_SIZE(igep_vmmc3_supply),
	.consumer_supplies      = igep_vmmc3_supply,
};


expanded

static struct omap2_hsmmc_info mmc[] = {
	{
		.mmc		= 1,
		.caps		= MMC_CAP_4_BIT_DATA,
		.gpio_cd	= -EINVAL,
		.gpio_wp	= -EINVAL,
	},
	{
		.mmc		= 3,
		.caps		= MMC_CAP_4_BIT_DATA,
		.gpio_cd	= -EINVAL,
		.gpio_wp	= -EINVAL,
	},
...


and changed

static struct twl4030_platform_data igep_twldata = {
	/* platform_data for children goes here */
	.gpio		= &igep_twl4030_gpio_pdata,
	.vmmc1          = &igep_vmmc1,
+	.vmmc2          = &igep_vmmc3,
	.vio		= &igep_vio,
};

Which is definetly not enough or plain wrong in order to get it running. For a start gpio_cd is missing. For MMC1 this is configured like that

mmc[0].gpio_cd = gpio + 0;

But how it is done for MMC3?

Information about using MMC3 on the internet is not very widespread, although the current beagleboard also supports the pins.

Anybody know how to get it running?

Thanks in advance
Alexander

Accepted Answer

mcaro
mcaro
Offline
Monday, August 20 2012, 09:18 PM - #permalink
0
Hi Alexander,

As I understand it, the routines for loading the X-Loader from MMC1 are inside the OMAP itself, so the X-Loader always has to be loaded from MMC1 or NAND. Am I right?

Yes, MMC1, MMC2, NAND ... so you can check all devices in the OMAP Hardware Reference Manual page: 3509

The processor cannot use MMC3 for load the x-loader. So if you load the x-loader from flash then you can load the kernel from MMC3 ...

Manel
The reply is currently minimized Show
Responses (5)
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Tuesday, August 14 2012, 08:46 PM - #permalink
    0
    Hi Alexander,

    Thanks for report this bug on hardware manual, we will change it on next manual release.
    So, gpio_cd it's a standar gpio line, you can use your preferred gpio signal ... It is not mmc part ... after select your gpio line used as card detect you should initialize it and add it to the configuration manually as we do for mmc1 ...

    Cheers
    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, August 15 2012, 12:36 PM - #permalink
    0
    Hi Manel

    thanks for your answer. Unfortunetly I do not really understand it...

    > So, gpio_cd it's a standar gpio line, you can use your preferred gpio signal ... It is not mmc part ... after select your gpio line used as card detect you should initialize it and add it to the configuration manually as we do for mmc1 ...

    We used J4:46 for cd (UART1_RTC, GPIO 149) and J4:47 for wp (UART1_CTS, GPIO 150). So I added
    OMAP3_MUX(UART1_RTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
    OMAP3_MUX(UART1_CTS, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
    to board mux data.

    MMC1 is configured in
    static int igep_twl_gpio_setup(struct device *dev,
    unsigned gpio, unsigned ngpio)

    where cd is set with that line of code:
    mmc[0].gpio_cd = gpio + 0;

    And here I have no glue, how to adapt this for MMC3.

    Regards
    Alexander
    The reply is currently minimized Show
  • Accepted Answer

    mcaro
    mcaro
    Offline
    Wednesday, August 15 2012, 01:15 PM - #permalink
    0
    Hi Alexander,

    look the line wp instead.

    We initialize cd line in this way due it is connected to TPS65950, please check the IGEPv2 schematics, you should put there your gpio line ...

    Manel
    The reply is currently minimized Show
  • Accepted Answer

    Wednesday, August 15 2012, 03:30 PM - #permalink
    0
    Hi

    > look the line wp instead.

    The only lines with wp in the source code of 0020 and 0030 I can find are in the omap2_hsmmc_info struct:
    .gpio_wp = -EINVAL,

    > We initialize cd line in this way due it is connected to TPS65950, please check the IGEPv2 schematics, you should put there your gpio line ...

    What part of the schematics should I check? The IGEPv2 does not support MMC3. The IGEP Module reference module explicitly mentions mmc3_cd and mmc3_wp on the J4 connector description.
    Are this lines meant to be used for MMC3? If so, do they need extra mux code? And how to configure them as CD-Signal? I really cannot find any reference code. MMC1 works quite differently, it seems.

    Or do you mean that I should connect the CD line to the TPS65950?

    Regards
    Alexander
    The reply is currently minimized Show
  • Accepted Answer

    Monday, August 20 2012, 06:49 PM - #permalink
    0
    Hi

    as MMC3 is running fine now under Linux, I wonder if it is possibly to change the X-Loader, so the kernel can be loaded from MMC3. As I understand it, the routines for loading the X-Loader from MMC1 are inside the OMAP itself, so the X-Loader always has to be loaded from MMC1 or NAND. Am I right? And how much effort would it be to load the kernel from MMC3, if possible at all?

    Have a nice day
    Alexander
    The reply is currently minimized Show
Your Reply

SUPPORT


This email address is being protected from spambots. You need JavaScript enabled to view it.
This email address is being protected from spambots. You need JavaScript enabled to view it.
IGEP Community Wiki
IGEP Community Forum
IGEP Community Online Chat