Re: [REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
2010/12/13 Tony Lindgren : > * Enric Balletbò i Serra [101213 08:47]: >> >> Tony, please can this patch be included before 2.6.37 ? Without this >> patch the wifi module on IGEP v2 board not works. > > Sorry it's too much for the -rc series. For the -rc series > the fixes should be major bugs. This is in the category > "it never worked before". > > I will add it to omap-boards branch for the next merge window > over the next few days while going through all the pending > patches in patchwork. Ok, I'll wait :-) thanks Cheers, Enric -- 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: [REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
* Enric Balletbò i Serra [101213 08:47]: > > Tony, please can this patch be included before 2.6.37 ? Without this > patch the wifi module on IGEP v2 board not works. Sorry it's too much for the -rc series. For the -rc series the fixes should be major bugs. This is in the category "it never worked before". I will add it to omap-boards branch for the next merge window over the next few days while going through all the pending patches in patchwork. Cheers, Tony -- 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: [REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
Hi all,
2010/12/4 Marc Zyngier :
> Commit 72f381ba056 (omap3: Remove VMMC2 regulator on IGEP v2)
> removed an unused regulator entry, but left the second MMC channel
> (used by the Libertas WLAN module) without link to power regulator.
> This causes the SDIO module to fail being detected.
>
> This patch adds the two regulators that actually feed the WLAN module
> (1v8 from the TWL4030 VIO LDO, and a fixed 3v3). With that patch, the
> second channel is properly detected. Details of the power supply
> implementation were kindly provided by Enric Balletbo i Serra.
>
> Also change vmmc1 to use symbolic names instead of direct device
> reference.
>
> Tested on an IGEPv2 Rev-B.
>
> Signed-off-by: Marc Zyngier
> Acked-by: Enric Balletbo i Serra
> Cc: Tony Lindgren
> ---
> arch/arm/mach-omap2/board-igep0020.c | 61 -
> 1 files changed, 51 insertions(+), 10 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-igep0020.c
> b/arch/arm/mach-omap2/board-igep0020.c
> index 5e035a5..9a85e60 100644
> --- a/arch/arm/mach-omap2/board-igep0020.c
> +++ b/arch/arm/mach-omap2/board-igep0020.c
> @@ -19,6 +19,7 @@
> #include
>
> #include
> +#include
> #include
> #include
>
> @@ -257,9 +258,8 @@ 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_supply =
> + REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.0");
>
> /* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
> static struct regulator_init_data igep2_vmmc1 = {
> @@ -276,6 +276,52 @@ static struct regulator_init_data igep2_vmmc1 = {
> .consumer_supplies = &igep2_vmmc1_supply,
> };
>
> +static struct regulator_consumer_supply igep2_vio_supply =
> + REGULATOR_SUPPLY("vmmc_aux", "mmci-omap-hs.1");
> +
> +static struct regulator_init_data igep2_vio = {
> + .constraints = {
> + .min_uV = 180,
> + .max_uV = 180,
> + .apply_uV = 1,
> + .valid_modes_mask = REGULATOR_MODE_NORMAL
> + | REGULATOR_MODE_STANDBY,
> + .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
> + | REGULATOR_CHANGE_MODE
> + | REGULATOR_CHANGE_STATUS,
> + },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &igep2_vio_supply,
> +};
> +
> +static struct regulator_consumer_supply igep2_vmmc2_supply =
> + REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.1");
> +
> +static struct regulator_init_data igep2_vmmc2 = {
> + .constraints = {
> + .valid_modes_mask = REGULATOR_MODE_NORMAL,
> + .always_on = 1,
> + },
> + .num_consumer_supplies = 1,
> + .consumer_supplies = &igep2_vmmc2_supply,
> +};
> +
> +static struct fixed_voltage_config igep2_vwlan = {
> + .supply_name = "vwlan",
> + .microvolts = 330,
> + .gpio = -EINVAL,
> + .enabled_at_boot = 1,
> + .init_data = &igep2_vmmc2,
> +};
> +
> +static struct platform_device igep2_vwlan_device = {
> + .name = "reg-fixed-voltage",
> + .id = 0,
> + .dev = {
> + .platform_data = &igep2_vwlan,
> + },
> +};
> +
> static struct omap2_hsmmc_info mmc[] = {
> {
> .mmc = 1,
> @@ -373,12 +419,6 @@ static int igep2_twl_gpio_setup(struct device *dev,
> omap2_hsmmc_init(mmc);
>
> /*
> - * link regulators to MMC adapters ... we "know" the
> - * regulators will be set up only *after* we return.
> - */
> - igep2_vmmc1_supply.dev = mmc[0].dev;
> -
> - /*
> * REVISIT: need ehci-omap hooks for external VBUS
> * power switch and overcurrent detect
> */
> @@ -489,6 +529,7 @@ static void __init igep2_display_init(void)
>
> static struct platform_device *igep2_devices[] __initdata = {
> &igep2_dss_device,
> + &igep2_vwlan_device,
> };
>
> static void __init igep2_init_irq(void)
> @@ -519,7 +560,7 @@ static struct twl4030_platform_data igep2_twldata = {
> .gpio = &igep2_twl4030_gpio_pdata,
> .vmmc1 = &igep2_vmmc1,
> .vpll2 = &igep2_vpll2,
> -
> + .vio = &igep2_vio,
> };
>
> static struct i2c_board_info __initdata igep2_i2c1_boardinfo[] = {
> --
> 1.7.3.2
>
>
Tony, please can this patch be included before 2.6.37 ? Without this
patch the wifi module on IGEP v2 board not works.
Thanks,
Enric Balletbo i Serra.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of
[REPOST][PATCH] Fix IGEPv2 second MMC channel power supply
Commit 72f381ba056 (omap3: Remove VMMC2 regulator on IGEP v2)
removed an unused regulator entry, but left the second MMC channel
(used by the Libertas WLAN module) without link to power regulator.
This causes the SDIO module to fail being detected.
This patch adds the two regulators that actually feed the WLAN module
(1v8 from the TWL4030 VIO LDO, and a fixed 3v3). With that patch, the
second channel is properly detected. Details of the power supply
implementation were kindly provided by Enric Balletbo i Serra.
Also change vmmc1 to use symbolic names instead of direct device
reference.
Tested on an IGEPv2 Rev-B.
Signed-off-by: Marc Zyngier
Acked-by: Enric Balletbo i Serra
Cc: Tony Lindgren
---
arch/arm/mach-omap2/board-igep0020.c | 61 -
1 files changed, 51 insertions(+), 10 deletions(-)
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 5e035a5..9a85e60 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -19,6 +19,7 @@
#include
#include
+#include
#include
#include
@@ -257,9 +258,8 @@ 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_supply =
+ REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.0");
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data igep2_vmmc1 = {
@@ -276,6 +276,52 @@ static struct regulator_init_data igep2_vmmc1 = {
.consumer_supplies = &igep2_vmmc1_supply,
};
+static struct regulator_consumer_supply igep2_vio_supply =
+ REGULATOR_SUPPLY("vmmc_aux", "mmci-omap-hs.1");
+
+static struct regulator_init_data igep2_vio = {
+ .constraints = {
+ .min_uV = 180,
+ .max_uV = 180,
+ .apply_uV = 1,
+ .valid_modes_mask = REGULATOR_MODE_NORMAL
+ | REGULATOR_MODE_STANDBY,
+ .valid_ops_mask = REGULATOR_CHANGE_VOLTAGE
+ | REGULATOR_CHANGE_MODE
+ | REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &igep2_vio_supply,
+};
+
+static struct regulator_consumer_supply igep2_vmmc2_supply =
+ REGULATOR_SUPPLY("vmmc", "mmci-omap-hs.1");
+
+static struct regulator_init_data igep2_vmmc2 = {
+ .constraints= {
+ .valid_modes_mask = REGULATOR_MODE_NORMAL,
+ .always_on = 1,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &igep2_vmmc2_supply,
+};
+
+static struct fixed_voltage_config igep2_vwlan = {
+ .supply_name= "vwlan",
+ .microvolts = 330,
+ .gpio = -EINVAL,
+ .enabled_at_boot= 1,
+ .init_data = &igep2_vmmc2,
+};
+
+static struct platform_device igep2_vwlan_device = {
+ .name = "reg-fixed-voltage",
+ .id = 0,
+ .dev = {
+ .platform_data = &igep2_vwlan,
+ },
+};
+
static struct omap2_hsmmc_info mmc[] = {
{
.mmc= 1,
@@ -373,12 +419,6 @@ static int igep2_twl_gpio_setup(struct device *dev,
omap2_hsmmc_init(mmc);
/*
-* link regulators to MMC adapters ... we "know" the
-* regulators will be set up only *after* we return.
-*/
- igep2_vmmc1_supply.dev = mmc[0].dev;
-
- /*
* REVISIT: need ehci-omap hooks for external VBUS
* power switch and overcurrent detect
*/
@@ -489,6 +529,7 @@ static void __init igep2_display_init(void)
static struct platform_device *igep2_devices[] __initdata = {
&igep2_dss_device,
+ &igep2_vwlan_device,
};
static void __init igep2_init_irq(void)
@@ -519,7 +560,7 @@ static struct twl4030_platform_data igep2_twldata = {
.gpio = &igep2_twl4030_gpio_pdata,
.vmmc1 = &igep2_vmmc1,
.vpll2 = &igep2_vpll2,
-
+ .vio= &igep2_vio,
};
static struct i2c_board_info __initdata igep2_i2c1_boardinfo[] = {
--
1.7.3.2
--
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: [PATCH] Fix IGEPv2 second MMC channel power supply
On Mon, 15 Nov 2010 09:32:22 +0100 Enric Balletbò i Serra 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix IGEPv2 second MMC channel power supply
Hi, 2010/11/14 Marc Zyngier : > On Sun, 14 Nov 2010 19:11:46 +0100 > Enric Balletbò i Serra 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix IGEPv2 second MMC channel power supply
On Sun, 14 Nov 2010 19:11:46 +0100 Enric Balletbò i Serra 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix IGEPv2 second MMC channel power supply
2010/11/14 Felipe Balbi :
> Hi,
>
> On Sun, 14 Nov 2010 11:34:12 +, Marc Zyngier
> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Fix IGEPv2 second MMC channel power supply
Hi,
On Sun, 14 Nov 2010 11:34:12 +, Marc Zyngier
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
--
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: [PATCH] Fix IGEPv2 second MMC channel power supply
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 Cc: Enric Balletbo i Serra Cc: Tony Lindgren WBR, Sergei -- 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
[PATCH] Fix IGEPv2 second MMC channel power supply
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
Cc: Enric Balletbo i Serra
Cc: Tony Lindgren
---
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
--
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
