Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1

Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1

[Koen Kooi]

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

Hi,

I'm trying to bring up a wl1271 sdio expansion board on beagle with 2.6.37 and I'm running into a weird problem when enabling MMC_CAP_POWER_OFF_CARD.

My patch basically does:

--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -270,7 +270,7 @@ static struct omap2_hsmmc_info mmc[] = {
       {
               .name           = "wl1271",
               .mmc            = 2,
-               .caps           = MMC_CAP_4_BIT_DATA,
+               .caps           = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,

And does NOT touch mmc1. But after adding MMC_CAP_POWER_OFF_CARD I get tons of:

[   22.259490] mmcblk0: error -110 sending status comand
[   22.264617] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
[   22.273345] mmcblk0: error -110 transferring data, sector 2338228, nr 3, card status 0x0
[   22.281799] end_request: I/O error, dev mmcblk0, sector 2338228
[   22.288055] mmcblk0: error -110 sending status comand
[   22.293151] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
[   22.301879] mmcblk0: error -110 transferring data, sector 2338229, nr 2, card status 0x0
[   22.310363] end_request: I/O error, dev mmcblk0, sector 2338229

When using mmcblk0p2 as rootfs. Attached is the complete patch. It looks a bit weird because it's using the expansionboard infrastucture I hacked together.

I suspect that mmc2 is turning off the shared regulator, but I have various people claiming this code (minus the expansionboard detection) works with the same regulator setup, so I'm extremely puzzled.

The CC: list was partially generated with the get_maintainer.pl script, apologies if I screwed it up.

regards,

Koen


[-- Attachment #2: 0001-omap3-beagleboard-add-WIP-support-for-beagleboardtoy.patch --]
[-- Type: application/octet-stream, Size: 3434 bytes --]

From b3e1e2b9793b9afa286a1a195b739587fbf85c8c Mon Sep 17 00:00:00 2001
From: Koen Kooi <koen@beagleboard.org>
Date: Mon, 20 Dec 2010 11:57:56 +0100
Subject: [PATCH] omap3: beagleboard: add WIP support for beagleboardtoys WL12xx board

Based on a patch by Luciano Coelho <luciano.coelho@nokia.com>

Signed-off-by: Koen Kooi <koen@beagleboard.org>
---
 arch/arm/mach-omap2/board-omap3beagle.c |   76 +++++++++++++++++++++++++++++++
 1 files changed, 76 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 64a181e..9285ae7 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -146,6 +146,67 @@ fail0:
 
 char expansionboard_name[16];
 
+#if defined(CONFIG_WL1271) || defined(CONFIG_WL1271_MODULE)
+#include <linux/regulator/fixed.h>
+#include <linux/wl12xx.h>
+
+#define OMAP_BEAGLE_WLAN_EN_GPIO    (139)
+#define OMAP_BEAGLE_WLAN_IRQ_GPIO   (137)
+
+struct wl12xx_platform_data omap_beagle_wlan_data __initdata = {
+	.irq = OMAP_GPIO_IRQ(OMAP_BEAGLE_WLAN_IRQ_GPIO),
+	.board_ref_clock = 2, /* 38.4 MHz */
+};
+
+ static struct omap2_hsmmc_info mmcbbt[] = {
+ 	{
+ 		.mmc		= 1,
+ 		.caps		= MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
+ 		.gpio_wp	= 29,
+ 	},
+	{
+		.name		= "wl1271",
+		.mmc		= 2,
+		.caps		= MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
+		.gpio_wp	= -EINVAL,
+		.gpio_cd	= -EINVAL,
+		.nonremovable	= true,
+	},
+ 	{}	/* Terminator */
+ };
+
+static struct regulator_consumer_supply beagle_vmmc2_supply = {
+	.supply         = "vmmc",
+	.dev_name       = "mmci-omap-hs.1",
+};
+
+static struct regulator_init_data beagle_vmmc2 = {
+	.constraints = {
+		.valid_ops_mask = REGULATOR_CHANGE_STATUS,
+	},
+	.num_consumer_supplies = 1,
+	.consumer_supplies = &beagle_vmmc2_supply,
+};
+
+static struct fixed_voltage_config beagle_vwlan = {
+	.supply_name = "vwl1271",
+	.microvolts = 1800000,  /* 1.8V */
+	.gpio = OMAP_BEAGLE_WLAN_EN_GPIO,
+	.startup_delay = 70000, /* 70ms */
+	.enable_high = 1,
+	.enabled_at_boot = 0,
+	.init_data = &beagle_vmmc2,
+};
+
+static struct platform_device omap_vwlan_device = {
+	.name           = "reg-fixed-voltage",
+	.id             = 1,
+	.dev = {
+		.platform_data = &beagle_vwlan,
+	},
+};
+#endif
+
 #if defined(CONFIG_ENC28J60) || defined(CONFIG_ENC28J60_MODULE)
 
 #include <plat/mcspi.h>
@@ -384,7 +445,14 @@ static int beagle_twl_gpio_setup(struct device *dev,
 	}
 	/* gpio + 0 is "mmc0_cd" (input/IRQ) */
 	mmc[0].gpio_cd = gpio + 0;
+#if defined(CONFIG_WL1271) || defined(CONFIG_WL1271_MODULE)
+	if(!strcmp(expansionboard_name, "fixme-beagletoy")) 
+		omap2_hsmmc_init(mmcbbt);
+	else
+		omap2_hsmmc_init(mmc);
+#else
 	omap2_hsmmc_init(mmc);
+#endif
 
 	/* link regulators to MMC adapters */
 	beagle_vmmc1_supply.dev = mmc[0].dev;
@@ -788,6 +856,14 @@ static void __init omap3_beagle_init(void)
 		gpio_export(162, 1);
 	}
 
+	if(!strcmp(expansionboard_name, "fixme-beagletoy"))
+	{
+		if (wl12xx_set_platform_data(&omap_beagle_wlan_data))
+			pr_err("error setting wl12xx data\n");
+		printk(KERN_INFO "Beagle expansionboard: registering wl12xx platform device\n");
+		platform_device_register(&omap_vwlan_device);
+	}
+
 	usb_musb_init(&musb_board_data);
 	usb_ehci_init(&ehci_pdata);
 	omap3beagle_flash_init();
-- 
1.6.6.1

Re: Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1

[Luciano Coelho]

On Fri, 2011-01-21 at 15:18 +0100, Koen Kooi wrote:
> Hi,
> 
> I'm trying to bring up a wl1271 sdio expansion board on beagle with 2.6.37 and I'm running into a weird problem when enabling MMC_CAP_POWER_OFF_CARD.
> 
> My patch basically does:
> 
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -270,7 +270,7 @@ static struct omap2_hsmmc_info mmc[] = {
>        {
>                .name           = "wl1271",
>                .mmc            = 2,
> -               .caps           = MMC_CAP_4_BIT_DATA,
> +               .caps           = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
> 
> And does NOT touch mmc1. But after adding MMC_CAP_POWER_OFF_CARD I get tons of:
> 
> [   22.259490] mmcblk0: error -110 sending status comand
> [   22.264617] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
> [   22.273345] mmcblk0: error -110 transferring data, sector 2338228, nr 3, card status 0x0
> [   22.281799] end_request: I/O error, dev mmcblk0, sector 2338228
> [   22.288055] mmcblk0: error -110 sending status comand
> [   22.293151] mmcblk0: error -110 sending read/write command, response 0x0, card status 0x0
> [   22.301879] mmcblk0: error -110 transferring data, sector 2338229, nr 2, card status 0x0
> [   22.310363] end_request: I/O error, dev mmcblk0, sector 2338229
> 
> When using mmcblk0p2 as rootfs. Attached is the complete patch. It looks a bit weird because it's using the expansionboard infrastucture I hacked together.
> 
> I suspect that mmc2 is turning off the shared regulator, but I have various people claiming this code (minus the expansionboard detection) works with the same regulator setup, so I'm extremely puzzled.
> 
> The CC: list was partially generated with the get_maintainer.pl script, apologies if I screwed it up.

I think Ohad is the right person to answer this question.

-- 
Cheers,
Luca.

Re: Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1

[Ohad Ben-Cohen]

Hi Koen,

On Fri, Jan 21, 2011 at 4:49 PM, Luciano Coelho <coelho@ti.com> wrote:
>> My patch basically does:
>>
>> --- a/arch/arm/mach-omap2/board-omap3beagle.c
>> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
>> @@ -270,7 +270,7 @@ static struct omap2_hsmmc_info mmc[] = {
>>        {
>>                .name           = "wl1271",
>>                .mmc            = 2,
>> -               .caps           = MMC_CAP_4_BIT_DATA,
>> +               .caps           = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
>>
>> And does NOT touch mmc1. But after adding MMC_CAP_POWER_OFF_CARD I get tons of:


Hmm. The snippet above looks different in your patch.

It seems that you're adding a new mmcbbt array, along with the
existing mmc one, but still using unchanged board-omap3beagle code,
and I suspect you have some unhealthy  mmc/mmcbbt references.

Particularly, look at this:

@@ -384,7 +445,14 @@ static int beagle_twl_gpio_setup(struct device *dev,
 	}
 	/* gpio + 0 is "mmc0_cd" (input/IRQ) */
 	mmc[0].gpio_cd = gpio + 0;
+#if defined(CONFIG_WL1271) || defined(CONFIG_WL1271_MODULE)
+	if(!strcmp(expansionboard_name, "fixme-beagletoy"))
+		omap2_hsmmc_init(mmcbbt);
+	else
+		omap2_hsmmc_init(mmc);
+#else
 	omap2_hsmmc_init(mmc);
+#endif

 	/* link regulators to MMC adapters */
 	beagle_vmmc1_supply.dev = mmc[0].dev;

When WL1271 is configured, and you have your "fixme-beagletoy"
expansionboard around, you're only initializing mmcbbt, but still
using mmc for regulators references.

Care to check if fixing that makes your issues go away ?

Thanks,
Ohad.

Re: Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1

[Koen Kooi]

Op 22 jan 2011, om 11:36 heeft Ohad Ben-Cohen het volgende geschreven:

> Hi Koen,
> 
> On Fri, Jan 21, 2011 at 4:49 PM, Luciano Coelho <coelho@ti.com> wrote:
>>> My patch basically does:
>>> 
>>> --- a/arch/arm/mach-omap2/board-omap3beagle.c
>>> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
>>> @@ -270,7 +270,7 @@ static struct omap2_hsmmc_info mmc[] = {
>>>        {
>>>                .name           = "wl1271",
>>>                .mmc            = 2,
>>> -               .caps           = MMC_CAP_4_BIT_DATA,
>>> +               .caps           = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
>>> 
>>> And does NOT touch mmc1. But after adding MMC_CAP_POWER_OFF_CARD I get tons of:
> 
> 
> Hmm. The snippet above looks different in your patch.
> 
> It seems that you're adding a new mmcbbt array, along with the
> existing mmc one, but still using unchanged board-omap3beagle code,
> and I suspect you have some unhealthy  mmc/mmcbbt references.
> 
> Particularly, look at this:
> 
> @@ -384,7 +445,14 @@ static int beagle_twl_gpio_setup(struct device *dev,
> 	}
> 	/* gpio + 0 is "mmc0_cd" (input/IRQ) */
> 	mmc[0].gpio_cd = gpio + 0;
> +#if defined(CONFIG_WL1271) || defined(CONFIG_WL1271_MODULE)
> +	if(!strcmp(expansionboard_name, "fixme-beagletoy"))
> +		omap2_hsmmc_init(mmcbbt);
> +	else
> +		omap2_hsmmc_init(mmc);
> +#else
> 	omap2_hsmmc_init(mmc);
> +#endif
> 
> 	/* link regulators to MMC adapters */
> 	beagle_vmmc1_supply.dev = mmc[0].dev;
> 
> When WL1271 is configured, and you have your "fixme-beagletoy"
> expansionboard around, you're only initializing mmcbbt, but still
> using mmc for regulators references.
> 
> Care to check if fixing that makes your issues go away ?

That was indeed the problem, not I get:

[   35.417053] wl1271: firmware booted (Rev 6.1.0.0.343)

and

root@beagleboard-xm-next:~# ifconfig wlan0 hw eth 00:11:22:33:44:55
root@beagleboard-xm-next:~# iwlist wlan0 scanning | grep ESSID | wc -l
13

That get's me a lot further!

regards,

Koen

Re: Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1

[Ohad Ben-Cohen]

On Sat, Jan 22, 2011 at 5:30 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> That was indeed the problem, not I get:
>
> [   35.417053] wl1271: firmware booted (Rev 6.1.0.0.343)
>
> and
>
> root@beagleboard-xm-next:~# ifconfig wlan0 hw eth 00:11:22:33:44:55
> root@beagleboard-xm-next:~# iwlist wlan0 scanning | grep ESSID | wc -l
> 13
>
> That get's me a lot further!

Cool !

Re: Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1

[Tony Lindgren]

* Ohad Ben-Cohen <ohad@wizery.com> [110122 07:47]:
> On Sat, Jan 22, 2011 at 5:30 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> > That was indeed the problem, not I get:
> >
> > [   35.417053] wl1271: firmware booted (Rev 6.1.0.0.343)
> >
> > and
> >
> > root@beagleboard-xm-next:~# ifconfig wlan0 hw eth 00:11:22:33:44:55
> > root@beagleboard-xm-next:~# iwlist wlan0 scanning | grep ESSID | wc -l
> > 13
> >
> > That get's me a lot further!
> 
> Cool !

Hmm, do we need to still patch something for the -rc cycle for this?
If so, please let me know.

Tony
--
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: Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1

[Ohad Ben-Cohen]

On Wed, Feb 2, 2011 at 2:11 AM, Tony Lindgren <tony@atomide.com> wrote:
> * Ohad Ben-Cohen <ohad@wizery.com> [110122 07:47]:
>> On Sat, Jan 22, 2011 at 5:30 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
>> > That was indeed the problem, not I get:
>> >
>> > [   35.417053] wl1271: firmware booted (Rev 6.1.0.0.343)
>> >
>> > and
>> >
>> > root@beagleboard-xm-next:~# ifconfig wlan0 hw eth 00:11:22:33:44:55
>> > root@beagleboard-xm-next:~# iwlist wlan0 scanning | grep ESSID | wc -l
>> > 13
>> >
>> > That get's me a lot further!
>>
>> Cool !
>
> Hmm, do we need to still patch something for the -rc cycle for this?

I don't think so; the problem wasn't in the existing mainline code,
but in the new functionality developed (adding support for the
beagletoy expansion board), so this is not -rc material.

Thanks
--
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: Setting MMC_CAP_POWER_OFF_CARD on mmc2 leads to filesystem problems on mmc1

[Tony Lindgren]

* Ohad Ben-Cohen <ohad@wizery.com> [110202 00:00]:
> On Wed, Feb 2, 2011 at 2:11 AM, Tony Lindgren <tony@atomide.com> wrote:
> > * Ohad Ben-Cohen <ohad@wizery.com> [110122 07:47]:
> >> On Sat, Jan 22, 2011 at 5:30 PM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> >> > That was indeed the problem, not I get:
> >> >
> >> > [   35.417053] wl1271: firmware booted (Rev 6.1.0.0.343)
> >> >
> >> > and
> >> >
> >> > root@beagleboard-xm-next:~# ifconfig wlan0 hw eth 00:11:22:33:44:55
> >> > root@beagleboard-xm-next:~# iwlist wlan0 scanning | grep ESSID | wc -l
> >> > 13
> >> >
> >> > That get's me a lot further!
> >>
> >> Cool !
> >
> > Hmm, do we need to still patch something for the -rc cycle for this?
> 
> I don't think so; the problem wasn't in the existing mainline code,
> but in the new functionality developed (adding support for the
> beagletoy expansion board), so this is not -rc material.

OK thanks.

Tony