[PATCH] Fix IGEPv2 second MMC channel power supply

[PATCH] Fix IGEPv2 second MMC channel power supply

[Marc Zyngier]

Commit 72f381ba056 removed an unused regulator entry, but left
the second MMC channel (used by the Libertas WLAN mudule) without
link to power regulator. This causes the SDIO module to fail being
detected.

This patch adds a second supply to the existing MMC1 regulator,
and let MMC2 hang off it. With that patch, the second channel is
properly detected.

Tested on an IGEPv2 Rev-B.

Signed-off-by: Marc Zyngier <maz@misterjones.org>
Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
---
Note that this doesn't fix WLAN itself on 2.6.37-rc1...

 arch/arm/mach-omap2/board-igep0020.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..b66d114 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -257,8 +257,9 @@ static inline void __init igep2_init_smsc911x(void) { }
 static struct omap_board_config_kernel igep2_config[] __initdata = {
 };
 
-static struct regulator_consumer_supply igep2_vmmc1_supply = {
-	.supply		= "vmmc",
+static struct regulator_consumer_supply igep2_vmmc1_supplies[] = {
+	[0] = { .supply		= "vmmc", },
+	[1] = { .supply		= "vmmc", },
 };
 
 /* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
@@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
 					| REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies  = 1,
-	.consumer_supplies      = &igep2_vmmc1_supply,
+	.num_consumer_supplies  = 2,
+	.consumer_supplies      = igep2_vmmc1_supplies,
 };
 
 static struct omap2_hsmmc_info mmc[] = {
@@ -376,7 +377,8 @@ static int igep2_twl_gpio_setup(struct device *dev,
 	 * link regulators to MMC adapters ... we "know" the
 	 * regulators will be set up only *after* we return.
 	 */
-	igep2_vmmc1_supply.dev = mmc[0].dev;
+	igep2_vmmc1_supplies[0].dev = mmc[0].dev;
+	igep2_vmmc1_supplies[1].dev = mmc[1].dev;
 
 	/*
 	 * REVISIT: need ehci-omap hooks for external VBUS
-- 
1.7.3.2

[PATCH] Fix IGEPv2 second MMC channel power supply

[Marc Zyngier]

Commit 72f381ba056 removed an unused regulator entry, but left
the second MMC channel (used by the Libertas WLAN mudule) without
link to power regulator. This causes the SDIO module to fail being
detected.

This patch adds a second supply to the existing MMC1 regulator,
and let MMC2 hang off it. With that patch, the second channel is
properly detected.

Tested on an IGEPv2 Rev-B.

Signed-off-by: Marc Zyngier <maz@misterjones.org>
Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: Tony Lindgren <tony@atomide.com>
---
Note that this doesn't fix WLAN itself on 2.6.37-rc1...

 arch/arm/mach-omap2/board-igep0020.c |   12 +++++++-----
 1 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/arch/arm/mach-omap2/board-igep0020.c b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..b66d114 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -257,8 +257,9 @@ static inline void __init igep2_init_smsc911x(void) { }
 static struct omap_board_config_kernel igep2_config[] __initdata = {
 };
 
-static struct regulator_consumer_supply igep2_vmmc1_supply = {
-	.supply		= "vmmc",
+static struct regulator_consumer_supply igep2_vmmc1_supplies[] = {
+	[0] = { .supply		= "vmmc", },
+	[1] = { .supply		= "vmmc", },
 };
 
 /* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
@@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
 					| REGULATOR_CHANGE_MODE
 					| REGULATOR_CHANGE_STATUS,
 	},
-	.num_consumer_supplies  = 1,
-	.consumer_supplies      = &igep2_vmmc1_supply,
+	.num_consumer_supplies  = 2,
+	.consumer_supplies      = igep2_vmmc1_supplies,
 };
 
 static struct omap2_hsmmc_info mmc[] = {
@@ -376,7 +377,8 @@ static int igep2_twl_gpio_setup(struct device *dev,
 	 * link regulators to MMC adapters ... we "know" the
 	 * regulators will be set up only *after* we return.
 	 */
-	igep2_vmmc1_supply.dev = mmc[0].dev;
+	igep2_vmmc1_supplies[0].dev = mmc[0].dev;
+	igep2_vmmc1_supplies[1].dev = mmc[1].dev;
 
 	/*
 	 * REVISIT: need ehci-omap hooks for external VBUS
-- 
1.7.3.2

Re: [PATCH] Fix IGEPv2 second MMC channel power supply

[Sergei Shtylyov]

Hello.

On 14-11-2010 14:34, Marc Zyngier wrote:

> Commit 72f381ba056 removed an unused regulator entry, but left

    Linus has aksed to also specify the commit summary in parentheses.

> Signed-off-by: Marc Zyngier<maz@misterjones.org>
> Cc: Enric Balletbo i Serra<eballetbo@gmail.com>
> Cc: Tony Lindgren<tony@atomide.com>

WBR, Sergei

[PATCH] Fix IGEPv2 second MMC channel power supply

[Sergei Shtylyov]

Hello.

On 14-11-2010 14:34, Marc Zyngier wrote:

> Commit 72f381ba056 removed an unused regulator entry, but left

    Linus has aksed to also specify the commit summary in parentheses.

> Signed-off-by: Marc Zyngier<maz@misterjones.org>
> Cc: Enric Balletbo i Serra<eballetbo@gmail.com>
> Cc: Tony Lindgren<tony@atomide.com>

WBR, Sergei

Re: [PATCH] Fix IGEPv2 second MMC channel power supply

[Felipe Balbi]

Hi,

On Sun, 14 Nov 2010 11:34:12 +0000, Marc Zyngier <maz@misterjones.org>
wrote:
> @@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
>  					| REGULATOR_CHANGE_MODE
>  					| REGULATOR_CHANGE_STATUS,
>  	},
> -	.num_consumer_supplies  = 1,
> -	.consumer_supplies      = &igep2_vmmc1_supply,
> +	.num_consumer_supplies  = 2,

use ARRAY_SIZE(igep2_vmmc1_supplies),

-- 
balbi

[PATCH] Fix IGEPv2 second MMC channel power supply

[Felipe Balbi]

Hi,

On Sun, 14 Nov 2010 11:34:12 +0000, Marc Zyngier <maz@misterjones.org>
wrote:
> @@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
>  					| REGULATOR_CHANGE_MODE
>  					| REGULATOR_CHANGE_STATUS,
>  	},
> -	.num_consumer_supplies  = 1,
> -	.consumer_supplies      = &igep2_vmmc1_supply,
> +	.num_consumer_supplies  = 2,

use ARRAY_SIZE(igep2_vmmc1_supplies),

-- 
balbi

Re: [PATCH] Fix IGEPv2 second MMC channel power supply

[Enric Balletbò i Serra]

2010/11/14 Felipe Balbi <me@felipebalbi.com>:
> Hi,
>
> On Sun, 14 Nov 2010 11:34:12 +0000, Marc Zyngier <maz@misterjones.org>
> wrote:
>> @@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
>>                                       | REGULATOR_CHANGE_MODE
>>                                       | REGULATOR_CHANGE_STATUS,
>>       },
>> -     .num_consumer_supplies  = 1,
>> -     .consumer_supplies      = &igep2_vmmc1_supply,
>> +     .num_consumer_supplies  = 2,
>
> use ARRAY_SIZE(igep2_vmmc1_supplies),
>
> --
> balbi
>

Why we need to define an unexistent regulator in board file ? This
should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel
configuration  ?

Cheers,
   Enric
--
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

[PATCH] Fix IGEPv2 second MMC channel power supply

[Enric Balletbò i Serra]

2010/11/14 Felipe Balbi <me@felipebalbi.com>:
> Hi,
>
> On Sun, 14 Nov 2010 11:34:12 +0000, Marc Zyngier <maz@misterjones.org>
> wrote:
>> @@ -272,8 +273,8 @@ static struct regulator_init_data igep2_vmmc1 = {
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | REGULATOR_CHANGE_MODE
>> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | REGULATOR_CHANGE_STATUS,
>> ? ? ? },
>> - ? ? .num_consumer_supplies ?= 1,
>> - ? ? .consumer_supplies ? ? ?= &igep2_vmmc1_supply,
>> + ? ? .num_consumer_supplies ?= 2,
>
> use ARRAY_SIZE(igep2_vmmc1_supplies),
>
> --
> balbi
>

Why we need to define an unexistent regulator in board file ? This
should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel
configuration  ?

Cheers,
   Enric

Re: [PATCH] Fix IGEPv2 second MMC channel power supply

[Marc Zyngier]

On Sun, 14 Nov 2010 19:11:46 +0100
Enric Balletbò i Serra <eballetbo@gmail.com> wrote:

> Why we need to define an unexistent regulator in board file ? This
> should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel
> configuration  ?

I'm not adding another regulator, but instead simply exposing the fact
(or rather my guess) that the same regulator (vmmc1) is powering the
two MMC channels. Not having access to the board schematics, I can't
tell if that reflects the reality or not.

But using CONFIG_DUMMY_REGULATOR seems the wrong idea to me, as it's
just papering over the issue. We should be exposing what's really on
the board (a fixed regulator if that's the case).

	M.
-- 
I'm the slime oozin' out from your TV set...
--
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

[PATCH] Fix IGEPv2 second MMC channel power supply

[Marc Zyngier]

On Sun, 14 Nov 2010 19:11:46 +0100
Enric Balletb? i Serra <eballetbo@gmail.com> wrote:

> Why we need to define an unexistent regulator in board file ? This
> should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel
> configuration  ?

I'm not adding another regulator, but instead simply exposing the fact
(or rather my guess) that the same regulator (vmmc1) is powering the
two MMC channels. Not having access to the board schematics, I can't
tell if that reflects the reality or not.

But using CONFIG_DUMMY_REGULATOR seems the wrong idea to me, as it's
just papering over the issue. We should be exposing what's really on
the board (a fixed regulator if that's the case).

	M.
-- 
I'm the slime oozin' out from your TV set...

Re: [PATCH] Fix IGEPv2 second MMC channel power supply

[Enric Balletbò i Serra]

Hi,

2010/11/14 Marc Zyngier <maz@misterjones.org>:
> On Sun, 14 Nov 2010 19:11:46 +0100
> Enric Balletbò i Serra <eballetbo@gmail.com> wrote:
>
>> Why we need to define an unexistent regulator in board file ? This
>> should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel
>> configuration  ?
>
> I'm not adding another regulator, but instead simply exposing the fact
> (or rather my guess) that the same regulator (vmmc1) is powering the
> two MMC channels. Not having access to the board schematics, I can't
> tell if that reflects the reality or not.
>
> But using CONFIG_DUMMY_REGULATOR seems the wrong idea to me, as it's
> just papering over the issue. We should be exposing what's really on
> the board (a fixed regulator if that's the case).

So the DUMMY_REGULATOR is only a workaround when a regulator is not
defined and shouldn't be used ? Sorry if this is a stupid question but
regulator interface is not too clear for me.

The reality is this :

 -------     --------
| 3V3 |   | 1V8 |
 -------    --------
    |          |
 -----------------
|   WIFI/BT  |
 -----------------
        | ( MMC2  at 1V8 )
 ----------------
|   OMAP   |
 ---------------

3V3 is a fixed regulator
1V8 is a fixed regulator (VIO from TWL4030)

So, which you think is the right solution ?

Cheers,
   Enric
--
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

[PATCH] Fix IGEPv2 second MMC channel power supply

[Enric Balletbò i Serra]

Hi,

2010/11/14 Marc Zyngier <maz@misterjones.org>:
> On Sun, 14 Nov 2010 19:11:46 +0100
> Enric Balletb? i Serra <eballetbo@gmail.com> wrote:
>
>> Why we need to define an unexistent regulator in board file ? This
>> should not be done enabling the CONFIG_DUMMY_REGULATOR in your kernel
>> configuration ??
>
> I'm not adding another regulator, but instead simply exposing the fact
> (or rather my guess) that the same regulator (vmmc1) is powering the
> two MMC channels. Not having access to the board schematics, I can't
> tell if that reflects the reality or not.
>
> But using CONFIG_DUMMY_REGULATOR seems the wrong idea to me, as it's
> just papering over the issue. We should be exposing what's really on
> the board (a fixed regulator if that's the case).

So the DUMMY_REGULATOR is only a workaround when a regulator is not
defined and shouldn't be used ? Sorry if this is a stupid question but
regulator interface is not too clear for me.

The reality is this :

 -------     --------
| 3V3 |   | 1V8 |
 -------    --------
    |          |
 -----------------
|   WIFI/BT  |
 -----------------
        | ( MMC2  at 1V8 )
 ----------------
|   OMAP   |
 ---------------

3V3 is a fixed regulator
1V8 is a fixed regulator (VIO from TWL4030)

So, which you think is the right solution ?

Cheers,
   Enric

Re: [PATCH] Fix IGEPv2 second MMC channel power supply

[Marc Zyngier]

On Mon, 15 Nov 2010 09:32:22 +0100
Enric Balletbò i Serra <eballetbo@gmail.com> wrote:

Hi Enric,
> 
> So the DUMMY_REGULATOR is only a workaround when a regulator is not
> defined and shouldn't be used ? Sorry if this is a stupid question but
> regulator interface is not too clear for me.

My understanding is that DUMMY_REGULATOR kicks in when the regulator
setup is incomplete, and when it's better to fix things behind the
user's back rather than leaving him with a broken device.

> The reality is this :
> 
>  -------     --------
> | 3V3 |   | 1V8 |
>  -------    --------
>     |          |
>  -----------------
> |   WIFI/BT  |
>  -----------------
>         | ( MMC2  at 1V8 )
>  ----------------
> |   OMAP   |
>  ---------------
> 
> 3V3 is a fixed regulator
> 1V8 is a fixed regulator (VIO from TWL4030)
> 
> So, which you think is the right solution ?

I think we should provide a fixed regulator to the device, wired to
the .vio field of twl4030_platform_data. I'll submit a patch later
today, once I get a chance to test it on my board.

Cheers,

	M.
-- 
I'm the slime oozin' out from your TV set...
--
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

[PATCH] Fix IGEPv2 second MMC channel power supply

[Marc Zyngier]

On Mon, 15 Nov 2010 09:32:22 +0100
Enric Balletb? i Serra <eballetbo@gmail.com> wrote:

Hi Enric,
> 
> So the DUMMY_REGULATOR is only a workaround when a regulator is not
> defined and shouldn't be used ? Sorry if this is a stupid question but
> regulator interface is not too clear for me.

My understanding is that DUMMY_REGULATOR kicks in when the regulator
setup is incomplete, and when it's better to fix things behind the
user's back rather than leaving him with a broken device.

> The reality is this :
> 
>  -------     --------
> | 3V3 |   | 1V8 |
>  -------    --------
>     |          |
>  -----------------
> |   WIFI/BT  |
>  -----------------
>         | ( MMC2  at 1V8 )
>  ----------------
> |   OMAP   |
>  ---------------
> 
> 3V3 is a fixed regulator
> 1V8 is a fixed regulator (VIO from TWL4030)
> 
> So, which you think is the right solution ?

I think we should provide a fixed regulator to the device, wired to
the .vio field of twl4030_platform_data. I'll submit a patch later
today, once I get a chance to test it on my board.

Cheers,

	M.
-- 
I'm the slime oozin' out from your TV set...