wlan+omap+mmc: out-of-the-box WLAN support for ZOOM2/3

From: Ohad Ben-Cohen <[email protected]>

Remove SDIO IDs from the driver code since now it is included in linux/mmc/sdio_ids.h.

Signed-off-by Ohad Ben-Cohen <[email protected]>

---

From: Ohad Ben-Cohen <[email protected]>

Add support to set/get mmc_host private embedded data.

This is needed to allow software to dynamically create (and remove) SDIO functions which represents embedded SDIO devices.

Typically, it will be used to set the context of a driver that is creating a new SDIO function (and would then expect to be able to get that context back upon creation of the new sdio func).

Signed-off-by Ohad Ben-Cohen <[email protected]>

---
?drivers/mmc/core/Kconfig | ? ?8 ++++++++ ?include/linux/mmc/host.h | ? 16 ++++++++++++++++ ?2 files changed, 24 insertions(+), 0 deletions(-)

drivers/mmc/core/Kconfig +0 -0

index bb22ffd..ab27eb3 100644
@@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME
 

? ? ? ? ?This option sets a default which can be overridden by the ? ? ? ? ?module parameter "removable=0" or "removable=1".

drivers/mmc/core/Kconfig +8 -0

+
+config MMC_EMBEDDED_SDIO
+ ? ? ? boolean "MMC embedded SDIO device support"
+ ? ? ? help
+ ? ? ? ? If you say Y here, support will be added for embedded SDIO
+ ? ? ? ? devices (e.g. hardwired embedded WLAN SDIO devices).
+ ? ? ? ? Such devices require software support for emulating
+ ? ? ? ? card detect events.

include/linux/mmc/host.h +0 -0

index f65913c..9a48486 100644
@@ -209,6 +209,10 @@ struct mmc_host {

? ? ? ?struct led_trigger ? ? ?*led; ? ? ? ? ? /* activity led */ ?#endif

Hm, do we really need a Kconfig option just for a single pointer? It only saves sizeof(void *) bytes per host, but adds rather confusing config option for users and some ifdef complexity.

-----Original Message-----
From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc- owner at vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux- omap at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm at linux- foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 04/15] mmc: support embedded data field in mmc_host

From: Ohad Ben-Cohen <[email protected]>

Add support to set/get mmc_host private embedded
data.

This is needed to allow software to dynamically create (and remove) SDIO functions which represents embedded SDIO devices.

Typically, it will be used to set the context of a driver that is creating a new SDIO function (and would then expect to be able to get that context back upon creation of the new sdio func).

Signed-off-by Ohad Ben-Cohen <[email protected]>

---
 drivers/mmc/core/Kconfig |    8 ++++++++
 include/linux/mmc/host.h |   16 ++++++++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

drivers/mmc/core/Kconfig +8 -0

index bb22ffd..ab27eb3 100644
@@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME
 
 	  This option sets a default which can be overridden by the
 	  module parameter "removable=0" or "removable=1".
+
+config MMC_EMBEDDED_SDIO
+	boolean "MMC embedded SDIO device support"
+	help
+	  If you say Y here, support will be added for embedded SDIO
+	  devices (e.g. hardwired embedded WLAN SDIO devices).
+	  Such devices require software support for emulating
+	  card detect events.

include/linux/mmc/host.h +7 -0

index f65913c..9a48486 100644
@@ -209,6 +209,10 @@ struct mmc_host {
 	struct led_trigger	*led;		/* activity led */
 #endif
 
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+	void			*embedded_data;
+#endif
+
 	struct dentry		*debugfs_root;
 
 	unsigned long		private[0] ____cacheline_aligned;

@@ -264,5 +268,17 @@ static inline void mmc_set_disable_delay(struct
 mmc_host *host,
 	host->disable_delay = disable_delay;
 }
 
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+static inline void *mmc_get_embedded_data(struct mmc_host *host)
+{

#endif

--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: [email protected] [mailto:linux-mmc- [email protected]] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: [email protected]; [email protected]; linux- [email protected]
Cc: [email protected]; [email protected]; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm@linux- foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 04/15] mmc: support embedded data field in mmc_host

From: Ohad Ben-Cohen <[email protected]>

Add support to set/get mmc_host private embedded
data.

This is needed to allow software to dynamically create (and remove) SDIO functions which represents embedded SDIO devices.

Typically, it will be used to set the context of a driver that is creating a new SDIO function (and would then expect to be able to get that context back upon creation of the new sdio func).

Signed-off-by Ohad Ben-Cohen <[email protected]>

---
 drivers/mmc/core/Kconfig |    8 ++++++++
 include/linux/mmc/host.h |   16 ++++++++++++++++
 2 files changed, 24 insertions(+), 0 deletions(-)

drivers/mmc/core/Kconfig +8 -0

index bb22ffd..ab27eb3 100644
@@ -16,3 +16,11 @@ config MMC_UNSAFE_RESUME
 
 	  This option sets a default which can be overridden by the
 	  module parameter "removable=0" or "removable=1".
+
+config MMC_EMBEDDED_SDIO
+	boolean "MMC embedded SDIO device support"
+	help
+	  If you say Y here, support will be added for embedded SDIO
+	  devices (e.g. hardwired embedded WLAN SDIO devices).
+	  Such devices require software support for emulating
+	  card detect events.

include/linux/mmc/host.h +7 -0

index f65913c..9a48486 100644
@@ -209,6 +209,10 @@ struct mmc_host {
 	struct led_trigger	*led;		/* activity led */
 #endif
 
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+	void			*embedded_data;
+#endif
+
 	struct dentry		*debugfs_root;
 
 	unsigned long		private[0] ____cacheline_aligned;

@@ -264,5 +268,17 @@ static inline void mmc_set_disable_delay(struct
 mmc_host *host,
 	host->disable_delay = disable_delay;
 }
 
+#ifdef CONFIG_MMC_EMBEDDED_SDIO
+static inline void *mmc_get_embedded_data(struct mmc_host *host)
+{

#endif

--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

From: Ohad Ben-Cohen <[email protected]>

Add support for software emulation of card detect events.

This is required for specific controllers that are hard wired with embedded SDIO devices (such as TI's wl1271 WLAN device).

Board-specific configuration is required to enable this software card detect control.

Quoted 8 lines · Ohad Ben-Cohen

From: Ohad Ben-Cohen <[email protected]>

Add support for software emulation of card detect events.

This is required for specific controllers that are hard wired with embedded SDIO devices (such as TI's wl1271 WLAN device).

Why?

Many instances of hardwired SDIO based WLAN devices do exist already, and they don't need extra card detect events to be generated. ?The core MMC code already triggers a probe for cards whenever a new host controller is registered.

Quoted 2 lines

Board-specific configuration is required to enable this software card detect control.

Could you elaborate please?

Nicolas

Hi Nicolas,

Quoted 11 lines · Nicolas Pitre

Quoted 8 lines · Ohad Ben-Cohen

From: Ohad Ben-Cohen<[email protected]>

Add support for software emulation of card detect
events.

This is required for specific controllers
that are hard wired with embedded SDIO devices
(such as TI's wl1271 WLAN device).

Quoted 6 lines

Why?

Many instances of hardwired SDIO based WLAN devices do exist already, and they don't need extra card detect events to be generated. The core MMC code already triggers a probe for cards whenever a new host controller is registered.

We prefer not to power up the chip as early as boot time; instead, we

would like to have it powered off until the wlan interface is brought up, power it on when the interface is brought up,

and power it off again as soon as the interface is brought down again (to minimize power consumption when the wlan is not in use).

Quoted 1 line · ext Ohad Ben-Cohen

We prefer not to power up the chip as early as boot time; instead, we

Why?

The function driver should power it down later if required. no?

If it was powered OFF then how did the wlan interface come into picture?

I agree, we some how need to power down the card when not in use in the right way.

Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better.

Quoted 4 lines · Ohad Ben-Cohen

Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better.

Some correction and additional info:

The wl1271 device has an issue which makes the standard card detect mechanism irrelevant: it is always up, even if the power enable gpio input of the device is down (the power enable input does not supply the power to the chip, it's just logical digital high/low input upon which the device reacts). That's why we must use software control for emulating card detect with that device.

Just to clarify, is the wl1271 device always powered on the board?

And this GPIO power enable (OMAP_ZOOM_WLAN_PMENA_GPIO) is used to gate this supply internally?

and what do these do ?

set_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);

clear_bit(WL1271_FLAG_GPIO_POWER, &wl->flags);

-----Original Message-----
From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
Sent: Tuesday, July 06, 2010 6:48 AM
To: Nicolas Pitre
Cc: linux-wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Luciano Coelho; Andrew Morton; San Mehat; Pandita, Vikram
Subject: Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support

Quoted 4 lines · Ohad Ben-Cohen

Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better.

Some correction and additional info:

The wl1271 device has an issue which makes the standard card detect mechanism irrelevant: it is always up, even if the power enable gpio input of the device is down (the power enable input does not supply the power to the chip, it's just logical digital high/low input upon which the device reacts). That's why we must use software control for emulating card detect with that device.

In addition, as far as I could find out, the card detect mechanism on the ZOOM is implemented by mechanical means, and thus is not relevant for hardwired embedded SDIO devices (I'm not even sure card detect is supported for the 3rd mmc controller).

Quoted 28 lines

-----Original Message-----
From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
Sent: Tuesday, July 06, 2010 6:48 AM
To: Nicolas Pitre
Cc: linux-wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Luciano Coelho; Andrew Morton; San Mehat; Pandita, Vikram
Subject: Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support

Quoted 4 lines · Ohad Ben-Cohen

Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better.

Some correction and additional info:

The wl1271 device has an issue which makes the standard card detect mechanism irrelevant: it is always up, even if the power enable gpio input of the device is down (the power enable input does not supply the power to the chip, it's just logical digital high/low input upon which the device reacts). That's why we must use software control for emulating card detect with that device.

Quoted 4 lines

In addition, as far as I could find out, the card detect mechanism on the ZOOM is implemented by mechanical means, and thus is not relevant for hardwired embedded SDIO devices (I'm not even sure card detect is supported for the 3rd mmc controller).

The card detect is supported through T2 GPIO interrupts only for MMC1 and MMC2. Such a mechanism is not present for MMC3 to which the WLAN chip is hardwired.

From: Ohad Ben-Cohen <[email protected]>

Add board muxing to support the wlan wl1271 chip that is hardwired to mmc2 (third mmc controller) on the ZOOM2.

-----Original Message-----
From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc- owner at vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux- omap at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm at linux- foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 06/15] omap zoom2: wlan board muxing

From: Ohad Ben-Cohen <[email protected]>

Add board muxing to support the wlan wl1271 chip that is hardwired to mmc2 (third mmc controller) on the ZOOM2.

Signed-off-by Ohad Ben-Cohen <[email protected]>

---
 arch/arm/mach-omap2/board-zoom2.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

arch/arm/mach- renamed from arch/arm/mach-omap2/board-zoom2.c +0 -0

omap2/board-zoom2.c
index 803ef14..00871be 100644

arch/arm/mach-omap2/board-zoom2.c +14 -1

+	/* WLAN IRQ - GPIO 162 */
+	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+	/* WLAN POWER ENABLE - GPIO 101 */
+	OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+	/* WLAN SDIO: MMC3 CMD */
+	OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | 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),
+#endif
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else
--

1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

arch/arm/mach-omap2/board-zoom2.c static struct twl4030_platform_data zoom2_twldata = { · line 74

Quoted 5 lines

arch/arm/mach-omap2/board-zoom2.c +1 -0

@@ -71,6 +71,21 @@ static struct twl4030_platform_data zoom2_twldata = {
 
 #ifdef CONFIG_OMAP_MUX
 static struct omap_board_mux board_mux[] __initdata = {
+#ifdef CONFIG_OMAP_ZOOM_WLAN

[Ghorai] This is zoom board specific file, So why need this additional flag?

Quoted 2 lines · Ghorai, Sukumar

Quoted 2 lines

(quoted diff) +0 -0

@@ -71,6 +71,21 @@ static struct twl4030_platform_data zoom2_twldata = {
 

Quoted 5 lines

Quoted 3 lines

?#ifdef CONFIG_OMAP_MUX
?static struct omap_board_mux board_mux[] __initdata = { +#ifdef CONFIG_OMAP_ZOOM_WLAN

[Ghorai] This is zoom board specific file, So why need this additional flag?

Good point, the ifdef is unnecessary in for both zoom2 and zoom3. Will update in my queue to remove the ifdefs.

Tony

-----Original Message-----
From: [email protected] [mailto:linux-mmc- [email protected]] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: [email protected]; [email protected]; linux- [email protected]
Cc: [email protected]; [email protected]; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm@linux- foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 06/15] omap zoom2: wlan board muxing

From: Ohad Ben-Cohen <[email protected]>

Add board muxing to support the wlan wl1271 chip that is hardwired to mmc2 (third mmc controller) on the ZOOM2.

Signed-off-by Ohad Ben-Cohen <[email protected]>

---
 arch/arm/mach-omap2/board-zoom2.c |   15 +++++++++++++++
 1 files changed, 15 insertions(+), 0 deletions(-)

arch/arm/mach- renamed from arch/arm/mach-omap2/board-zoom2.c +0 -0

omap2/board-zoom2.c
index 803ef14..00871be 100644

arch/arm/mach-omap2/board-zoom2.c +14 -1

+	/* WLAN IRQ - GPIO 162 */
+	OMAP3_MUX(MCBSP1_CLKX, OMAP_MUX_MODE4 | OMAP_PIN_INPUT_PULLUP),
+	/* WLAN POWER ENABLE - GPIO 101 */
+	OMAP3_MUX(CAM_D2, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
+	/* WLAN SDIO: MMC3 CMD */
+	OMAP3_MUX(MCSPI1_CS1, OMAP_MUX_MODE3 | 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),
+#endif
 	{ .reg_offset = OMAP_MUX_TERMINATOR },
 };
 #else
--

1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

From: Ohad Ben-Cohen <[email protected]>

Move wl12xx.h outside of the spi-specific location, so it can be shared with both spi and sdio solutions.

Signed-off-by Ohad Ben-Cohen <[email protected]>

---
 drivers/net/wireless/wl12xx/wl1251_sdio.c |    2 +-
 drivers/net/wireless/wl12xx/wl1251_spi.c  |    2 +-
 drivers/net/wireless/wl12xx/wl1271_spi.c  |    2 +-
 include/linux/spi/wl12xx.h                |   34
-----------------------------
 include/linux/wl12xx.h                    |   34
+++++++++++++++++++++++++++++
 5 files changed, 37 insertions(+), 37 deletions(-)
 delete mode 100644 include/linux/spi/wl12xx.h
 create mode 100644 include/linux/wl12xx.h 

From: Ohad Ben-Cohen <[email protected]>

Make it possible for the set power method to indicate a success/failure return value. This is needed to support more complex power on/off operations such as bringing up (and down) sdio functions.

Signed-off-by Ohad Ben-Cohen <[email protected]>

---

From: Ohad Ben-Cohen<[email protected]>

Introduce a platform device support which is decoupled from the life cycle of the sdio function.

The platform device objective is to deliver board-specific values (like irq, ref_clock, and software card-detect emulation control).

The driver can then dynamically create (or destroy) the sdio function whenever the wlan interface is brought up (or down), as part of the power() operation.

Could you please explain why you need to do this?

br,
-roger

Hi Roger,

Quoted 1 line · Roger Quadros

Could you please explain why you need to do this?

To minimize power consumption when the wlan device is not in use, we would like to keep the device powered off as long as the interface is down, and only power it on when the user brings up the interface.

Whenever the chip is powered on, it must be initialized and reconfigured by mmc_attach_sdio, and the wl1271 driver have to wait for that phase to successfully complete (essentially waiting for the sdio_driver's probe function to be called).

To make sure this SDIO init step occurs correctly every time we toggle the device's power back on, and to prevent potential races, we also have to make sure that the sdio function is removed every time we power off the chip (the driver waits for the sdio_driver's remove function to be called).

That's why we let the mmc layer think that the card is removed:
physically it is still there, but for all practical purposes it is really removed, because once you power off the chip, you must reinitialize it again next time you power it on, as if the card was really removed and re-inserted.

My point is that shouldn't this be handled by SDIO core?

If there are no users for the SDIO function and the card, doesn't the SDIO core power down the slot and take care of re-initialization when it is powered up?

Hi Roger,

Quoted 1 line · Roger Quadros

My point is that shouldn't this be handled by SDIO core?

Care to explain what you mean / give a code example ?

Quoted 4 lines

If there are no users for the SDIO function and the card, doesn't the SDIO core power down the slot and take care of re-initialization when it is powered up?

You need card detect events in order to trigger card& sdio function initialization and removals.

Please share any alternative approach you may be thinking on.

Quoted 4 lines · ext Ohad Ben-Cohen

Hi Roger,

On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros<[email protected]> wrote:

Quoted 3 lines

Quoted 1 line

My point is that shouldn't this be handled by SDIO core?

Care to explain what you mean / give a code example ?

If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then the SDIO/MMC core should tackle it, just like it deals with supply for slots with removable cards.

Quoted 2 lines

You need card detect events in order to trigger card& sdio function initialization and removals.

Quoted 1 line

Please share any alternative approach you may be thinking on.

OK, this is how I see it.

- Treat the non-removable card as non-removable. So no need to do card detect emulation.

- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator framework to define this regulator & supply. Even though you mention that it is not actually a supply, it fits well in the fixed supply framework.

- When the host controller is enumerated, the mmc core will power up the slot, find the sdio card, and probe the function driver (i.e. wl1271_sdio).

- if interface is not in use, the function driver must release the sdio host, and this should eventually disable the vmmc supply.

- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the sdio host. this will cause the vmmc supply to be enabled, for as long as the interface is up.

Does this address all issues?

Quoted 10 lines · Roger Quadros

Quoted 6 lines · ext Ohad Ben-Cohen

Hi Roger,

Quoted 1 line · Roger Quadros

My point is that shouldn't this be handled by SDIO core?

Care to explain what you mean / give a code example ?

If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then the SDIO/MMC core should tackle it, just like it deals with supply for slots with removable cards.

Exact.

Quoted 2 lines

Quoted 2 lines

You need card detect events in order to trigger card& sdio function initialization and removals.

Why would you trigger function initialization and removal? Just to turn off power? That's a bit like pulling off the battery from your laptop when you want to suspend it. There is a better way to go about things.

Quoted 13 lines

Quoted 1 line

Please share any alternative approach you may be thinking on.

OK, this is how I see it.

- Treat the non-removable card as non-removable. So no need to do card detect emulation.

- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator framework to define this regulator & supply. Even though you mention that it is not actually a supply, it fits well in the fixed supply framework.

- When the host controller is enumerated, the mmc core will power up the slot, find the sdio card, and probe the function driver (i.e. wl1271_sdio).

Quoted 8 lines

- if interface is not in use, the function driver must release the sdio host, and this should eventually disable the vmmc supply.

- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the sdio host. this will cause the vmmc supply to be enabled, for as long as the interface is up.

Does this address all issues?

This is mostly all good, except that claiming/releasing the SDIO host is about access to the bus. It must be claimed right before doing any IO, and released right after that, even when the card is expected to remain powered. This is not the proper place to hook power control.

Another function pair would be needed instead, which would do almost like the suspend/resume code is already doing. Something like:

/*
* Indicate to the core SDIO layer that we're not requiring that the
* function remain powered. If all functions for the card are in the
* same "no power" state, then the host controller can remove power from
* the card. Note: the function driver must preserve hardware states if
* necessary.
*/
int sdio_release_power(struct sdio_func *func);

/*
* Indicate to the core SDIO layer that we want power back for this
* SDIO function. The power may or may not actually have been removed
* since last call to sdio_release_power(), so the function driver must
* not assume any preserved state at the hardware level and re-perform
* all the necessary hardware config. This function returns 0 when
* power is actually restored, or some error code if this cannot be
* achieved. One error reason might be that the card is no longer
* available on the bus (was removed while powered down and card
* detection didn't trigger yet).
*/
int sdio_claim_power(struct sdio_func *func);

That's it. When the network interface is down and the hardware is not needed, you call sdio_release_power(). When the request to activate the network interface is received, you call sdio_claim_power() and configure the hardware appropriately. If sdio_claim_power() returns an error, then you just return an error to the network request, and eventually the driver's remove method will be called if this is indeed because the card was removed.

In the core SDIO code, this is almost identical to a suspend/resume request, except that the request comes from the function driver instead of the core MMC code.

Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 82 lines · Nicolas Pitre

Quoted 10 lines · Roger Quadros

Quoted 6 lines · ext Ohad Ben-Cohen

Hi Roger,

Quoted 1 line · Roger Quadros

My point is that shouldn't this be handled by SDIO core?

Care to explain what you mean / give a code example ?

If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then the SDIO/MMC core should tackle it, just like it deals with supply for slots with removable cards.

Exact.

Quoted 2 lines

Quoted 2 lines

You need card detect events in order to trigger card& sdio function
initialization and removals.

Why would you trigger function initialization and removal? Just to turn off power? That's a bit like pulling off the battery from your laptop when you want to suspend it. There is a better way to go about things.

Quoted 13 lines

Quoted 1 line

Please share any alternative approach you may be thinking on.

OK, this is how I see it.

- Treat the non-removable card as non-removable. So no need to do card detect emulation.

- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator framework to define this regulator& supply. Even though you mention that it is not actually a supply, it fits well in the fixed supply framework.

- When the host controller is enumerated, the mmc core will power up the slot, find the sdio card, and probe the function driver (i.e. wl1271_sdio).

Quoted 8 lines

- if interface is not in use, the function driver must release the sdio host, and this should eventually disable the vmmc supply.

- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the sdio host. this will cause the vmmc supply to be enabled, for as long as the interface is up.

Does this address all issues?

This is mostly all good, except that claiming/releasing the SDIO host is about access to the bus. It must be claimed right before doing any IO, and released right after that, even when the card is expected to remain powered. This is not the proper place to hook power control.

Another function pair would be needed instead, which would do almost like the suspend/resume code is already doing. Something like:

/*
* Indicate to the core SDIO layer that we're not requiring that the
* function remain powered. If all functions for the card are in the
* same "no power" state, then the host controller can remove power from
* the card. Note: the function driver must preserve hardware states if
* necessary.
*/
int sdio_release_power(struct sdio_func *func);

/*
* Indicate to the core SDIO layer that we want power back for this
* SDIO function. The power may or may not actually have been removed
* since last call to sdio_release_power(), so the function driver must
* not assume any preserved state at the hardware level and re-perform
* all the necessary hardware config. This function returns 0 when
* power is actually restored, or some error code if this cannot be
* achieved. One error reason might be that the card is no longer
* available on the bus (was removed while powered down and card
* detection didn't trigger yet).
*/
int sdio_claim_power(struct sdio_func *func);

That's it. When the network interface is down and the hardware is not needed, you call sdio_release_power(). When the request to activate the network interface is received, you call sdio_claim_power() and configure the hardware appropriately. If sdio_claim_power() returns an error, then you just return an error to the network request, and eventually the driver's remove method will be called if this is indeed because the card was removed.

Quoted 3 lines

In the core SDIO code, this is almost identical to a suspend/resume request, except that the request comes from the function driver instead of the core MMC code.

For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call ->enable() / ->disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host->bus_ops->power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card.

Set omap2_hsmmc_info mmc[x] {.nonremovable=true, .power_saving=true} and implement host->bus_ops->power_restore() for SDIO, then the power will go off 9 seconds after sdio_release_host() is called. Then tweak omap_hsmmc so that it doesn't wait 9 seconds for the SDIO case

Quoted 5 lines · Hunter Adrian (Nokia-MS/Helsinki)

For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call ->enable() / ->disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host->bus_ops->power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card.

Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie with the bus drivers?

-----Original Message-----
From: Nicolas Pitre [mailto:nico at fluxnic.net]
Sent: Wednesday, July 07, 2010 9:03 AM
To: Roger Quadros
Cc: Hunter Adrian (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux- wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Coelho Luciano (Nokia-MS/Helsinki); akpm at linux-foundation.org; San Mehat
Subject: Re: [PATCH 11/15] wireless: wl1271: introduce platform device support

Quoted 6 lines · Roger Quadros

Quoted 5 lines · Hunter Adrian (Nokia-MS/Helsinki)

For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call ->enable() / ->disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host->bus_ops->power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card.

This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using.

I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down.

Quoted 1 line

Shouldn't the power control intelligence (i.e. when to turn power

ON/OFF) lie

Quoted 1 line

with the bus drivers?

Absolutely! And in the SDIO case that should lie with each function drivers. Please let's stop this omap_hsmmc madness.

Nicolas

Quoted 27 lines

-----Original Message-----
From: Nicolas Pitre [mailto:nico at fluxnic.net]
Sent: Wednesday, July 07, 2010 9:03 AM
To: Roger Quadros
Cc: Hunter Adrian (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux- wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux- omap at vger.kernel.org; linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Coelho Luciano (Nokia-MS/Helsinki); akpm at linux-foundation.org; San Mehat
Subject: Re: [PATCH 11/15] wireless: wl1271: introduce platform device support

Quoted 6 lines · Roger Quadros

Quoted 5 lines · Hunter Adrian (Nokia-MS/Helsinki)

For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call ->enable() / ->disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host->bus_ops->power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card.

This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using.

Quoted 7 lines

I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down.

The point is that MMC/SD core files were patched to provide this kind of a support. Any controller driver can use that framework today, right?. As an example omap_hsmmc driver was patched and it works fine.

Quoted 6 lines · Roger Quadros

Quoted 5 lines · Hunter Adrian (Nokia-MS/Helsinki)

For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call ->enable() / ->disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host->bus_ops->power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card.

This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using.

I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down.

Quoted 3 lines

Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie with the bus drivers?

Absolutely! And in the SDIO case that should lie with each function drivers. Please let's stop this omap_hsmmc madness.

Nicolas
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 9 lines · Nicolas Pitre

Quoted 6 lines · Roger Quadros

Quoted 5 lines · Hunter Adrian (Nokia-MS/Helsinki)

For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call ->enable() / ->disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host->bus_ops->power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card.

Quoted 3 lines

This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using.

The power control decision does come from the top via mmc_claim_host / mmc_release_host.

Quoted 5 lines

I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down.

The omap_hsmmc driver does not tell the core to shut down the upper layers.

Instead the core tells the omap_hsmmc driver that it is "disabled" i.e. not currently being used so it can start taking steps to save power.

That is sensible because not even the upper layers know when the next activity will be.

Quoted 6 lines

Quoted 3 lines

Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie
with the bus drivers?

Absolutely! And in the SDIO case that should lie with each function drivers. Please let's stop this omap_hsmmc madness.

You are dealing with a trivial case - turn off the power when not in use.

We have 3 power saving actions: enable DPS, put the card to sleep, and finally power it off. Each increases the latency to start up again and so must be staggered. With DPS-enabled the host controller can be powered off at any time. In that case the controller registers must be restored.

There are numerous entry points to the driver. Checking whether to restore registers at every entry point is error prone and messy.

Instead we require that the core tells the driver when to enable and disable.

Quoted 5 lines · Roger Quadros

Quoted 4 lines · ext Ohad Ben-Cohen

Hi Roger,

On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadros<[email protected]> wrote:

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

My point is that shouldn't this be handled by SDIO core?

Care to explain what you mean / give a code example ?

If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then the SDIO/MMC core should tackle it, just like it deals with supply for slots with removable cards.

Exact.

Quoted 2 lines

Quoted 2 lines

You need card detect events in order to trigger card& sdio function
initialization and removals.

Why would you trigger function initialization and removal? Just to turn off power? That's a bit like pulling off the battery from your laptop when you want to suspend it. There is a better way to go about things.

Quoted 21 lines

Quoted 1 line

Please share any alternative approach you may be thinking on.

OK, this is how I see it.

- Treat the non-removable card as non-removable. So no need to do card detect emulation.

- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator framework to define this regulator& supply. Even though you mention that it is not actually a supply, it fits well in the fixed supply framework.

- When the host controller is enumerated, the mmc core will power up the slot, find the sdio card, and probe the function driver (i.e. wl1271_sdio).

- if interface is not in use, the function driver must release the sdio host, and this should eventually disable the vmmc supply.

- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the sdio host. this will cause the vmmc supply to be enabled, for as long as the interface is up.

Quoted 1 line

Does this address all issues?

This is mostly all good, except that claiming/releasing the SDIO host is about access to the bus. It must be claimed right before doing any IO, and released right after that, even when the card is expected to remain powered. This is not the proper place to hook power control.

Quoted 30 lines · ext Nicolas Pitre

Quoted 27 lines · Roger Quadros

OK, this is how I see it.

- Treat the non-removable card as non-removable. So no need to do card detect
emulation.

- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
framework to define this regulator& supply. Even though you mention that it
is not actually a supply, it fits well in the fixed supply framework.

- When the host controller is enumerated, the mmc core will power up the slot,
find the sdio card, and probe the function driver (i.e. wl1271_sdio).

- if interface is not in use, the function driver must release the sdio host,
and this should eventually disable the vmmc supply.

- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
sdio host. this will cause the vmmc supply to be enabled, for as long as the
interface is up.

Does this address all issues?

Quoted 4 lines

This is mostly all good, except that claiming/releasing the SDIO host is about access to the bus. It must be claimed right before doing any IO, and released right after that, even when the card is expected to remain powered. This is not the proper place to hook power control.

Agreed, but is it so that SDIO power may be removed between a host_release and claim? This appears so from omap_hsmmc host controller.

Quoted 31 lines · Roger Quadros

Quoted 30 lines · ext Nicolas Pitre

Quoted 27 lines · Roger Quadros

OK, this is how I see it.

- Treat the non-removable card as non-removable. So no need to do card detect
emulation.

- Treat the GPIO power enable on wl1271 as VMMC supply. Use fixed regulator
framework to define this regulator& supply. Even though you mention that
it
is not actually a supply, it fits well in the fixed supply framework.

- When the host controller is enumerated, the mmc core will power up the slot,
find the sdio card, and probe the function driver (i.e. wl1271_sdio).

- if interface is not in use, the function driver must release the sdio host,
and this should eventually disable the vmmc supply.

- Whenever the wlan interface must be brought up, wl1271_sdio, can claim the
sdio host. this will cause the vmmc supply to be enabled, for as long as the
interface is up.

Does this address all issues?

Quoted 7 lines

Quoted 4 lines

This is mostly all good, except that claiming/releasing the SDIO host is about access to the bus. It must be claimed right before doing any IO, and released right after that, even when the card is expected to remain powered. This is not the proper place to hook power control.

Agreed, but is it so that SDIO power may be removed between a host_release and claim? This appears so from omap_hsmmc host controller.

No, it is not because a host is not claimed that power should be dropped. The host claim/release is meant to provide exclusive access to the card that's all.

If the OMAP controller is dropping power to the card upon host->disable() then it is wrong. AFAICS only the OMAP controller is playing such games at the moment and I suspect the semantics might not be all right. Shutting down the _controller_ when it is idle might be a good thing, but not power to the _card_. Only the function driver might know when it is fine to lose power.

Quoted 3 lines · Roger Quadros

If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then the SDIO/MMC core should tackle it, just like it deals with supply for slots with removable cards.

Another function pair would be needed instead, which would do almost like the suspend/resume code is already doing. Something like:

Hi Nicolas and Roger,

Quoted 5 lines · Nicolas Pitre

Quoted 3 lines · Roger Quadros

If the Power enable GPIO can be treated as SDIO slot supply (i.e. vmmc), then the SDIO/MMC core should tackle it, just like it deals with supply for slots with removable cards.

...

Quoted 2 lines

Another function pair would be needed instead, which would do almost like the suspend/resume code is already doing. Something like:

Thanks a lot for your review and comments, and for taking the time to present your approach.

I like it !

It'd allow us to lose the software (or fake if you want ;) card detect mechanism, which is something that should have been added to each platform we wanted to support.

We would only need to make it possible to deliver board-specific data to the function driver (e.g., in the case of the wl1271, we need irq and board_ref_clock data). That would require some board-level platform-data configuration, which will be specific to the controller to which the device is hardwired to. This data should propagate through the host controller to the SDIO core so it would eventually be

You are already
creating a new platform device for wl1271_sdio just to pass platform_data

I think this case is specific to wl1271.

Hi Roger,

Quoted 2 lines · Roger Quadros

You are already
creating a new platform device for wl1271_sdio just to pass platform_data

With the new approach, I can remove this platform device altogether, and completely rely on the sdio function device for driver probing (as it was before). I just need to add this little support of delivering small bits of platform data - the mechanism should be simple and generic, and would considerably simplify the driver.

Quoted 1 line

I think this case is specific to wl1271.

Yes, it is.

Another function pair would be needed instead, which would do almost like the suspend/resume code is already doing. ?Something like:

/*
?* Indicate to the core SDIO layer that we're not requiring that the ?* function remain powered. ?If all functions for the card are in the ?* same "no power" state, then the host controller can remove power from ?* the card. ?Note: the function driver must preserve hardware states if ?* necessary.
?*/
int sdio_release_power(struct sdio_func *func);

/*
?* Indicate to the core SDIO layer that we want power back for this ?* SDIO function. ?The power may or may not actually have been removed ?* since last call to sdio_release_power(), so the function driver must ?* not assume any preserved state at the hardware level and re-perform ?* all the necessary hardware config. ?This function returns 0 when ?* power is actually restored, or some error code if this cannot be ?* achieved. ?One error reason might be that the card is no longer ?* available on the bus (was removed while powered down and card ?* detection didn't trigger yet).
?*/
int sdio_claim_power(struct sdio_func *func);

That's it. ?When the network interface is down and the hardware is not needed, you call sdio_release_power(). ?When the request to activate the network interface is received, you call sdio_claim_power() and configure the hardware appropriately. ?If sdio_claim_power() returns an error, then you just return an error to the network request, and eventually the driver's remove method will be called if this is indeed because the card was removed.

From: Ohad Ben-Cohen<[email protected]>

Add WLAN platform device and control
functions (power and virtual card detect)
in order to allow software to control the
embedded SDIO WLAN device which resides on
the ZOOM board (TI's wl1271 device).

Based on Android's WLAN control functions by
San Mehat<[email protected]>.

Signed-off-by Ohad Ben-Cohen<[email protected]>

---
  arch/arm/mach-omap2/board-zoom-wlan.c         |  129 +++++++++++++++++++++++++
  arch/arm/mach-omap2/include/mach/board-zoom.h |    5 +
  2 files changed, 134 insertions(+), 0 deletions(-)

create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c

arch/arm/mach-omap2/board-zoom-wlan.c new file +71 -0

new file mode 100644
index 0000000..7ed5139
@@ -0,0 +1,129 @@
+/* mach-omap2/board-zoom-wlan.c
+ *
+ * Board support for wl1271 embedded SDIO device.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */
+
+#include<linux/kernel.h>
+#include<linux/init.h>
+#include<linux/platform_device.h>
+#include<linux/mmc/host.h>
+#include<linux/mmc/sdio_ids.h>
+#include<linux/err.h>
+#include<linux/gpio.h>
+#include<linux/wl12xx.h>
+
+#include "mux.h"
+
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+
+/* these are zoom-specific board numbers */
+#define OMAP_ZOOM_WLAN_PMENA_GPIO	(101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO		(162)
+
+/* wl1271 virtual 'card detect' status */
+static int omap_zoom_wlan_cd;
+static void (*wlan_set_virtual_cd)(void *dev_id, int card_present);
+static void (*wlan_set_data)(void *dev_id, void *priv);
+static void *wlan_host_devid;
+
+int omap_zoom_wlan_register_embedded_control(void *dev_id,
+			void (*set_virtual_cd)(void *dev_id, int card_present),
+			void (*set_data)(void *dev_id, void *priv))
+{
+	if (wlan_host_devid || wlan_set_virtual_cd || wlan_set_data)
+		return -EBUSY;
+
+	wlan_set_virtual_cd = set_virtual_cd;
+	wlan_set_data = set_data;
+	wlan_host_devid = dev_id;
+
+	return 0;
+}
+
+int omap_zoom_wlan_get_virtual_cd(void)
+{
+	return omap_zoom_wlan_cd;
+}
+
+static void omap_zoom_wlan_set_embedded_data(void *priv)
+{
+	if (wlan_set_data)
+		wlan_set_data(wlan_host_devid, priv);
+	else
+		pr_err("%s: host controller not registered yet\n", __func__);
+}
+
+static void omap_zoom_wlan_set_carddetect(bool card_present)
+{
+	omap_zoom_wlan_cd = card_present ? 1 : 0;
+
+	pr_info("%s: %d\n", __func__, omap_zoom_wlan_cd);
+
+	if (wlan_set_virtual_cd)
+		wlan_set_virtual_cd(wlan_host_devid, omap_zoom_wlan_cd);
+	else
+		pr_err("%s: host controller not registered yet\n", __func__);

arch/arm/mach-omap2/board-zoom-wlan.c line 81

Quoted 8 lines

arch/arm/mach-omap2/board-zoom-wlan.c new file +8 -0

+static void omap_zoom_wlan_power(bool enable)
+{
+ ? ? ? int val = enable ? 1 : 0;
+
+ ? ? ? pr_info("%s: set power %d\n", __func__, val);
+
+ ? ? ? gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
+}

Can we consider that OMAP_ZOOM_WLAN_PMENA_GPIO is equivalent to vmmc supply or equivalent to supply voltage to the SDIO card?

-----Original Message-----
From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc- owner at vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux- omap at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm at linux- foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 14/15] omap: zoom: add WLAN device

From: Ohad Ben-Cohen <[email protected]>

Add WLAN platform device and control
functions (power and virtual card detect)
in order to allow software to control the
embedded SDIO WLAN device which resides on
the ZOOM board (TI's wl1271 device).

Based on Android's WLAN control functions by
San Mehat <[email protected]>.

Signed-off-by Ohad Ben-Cohen <[email protected]>

---
 arch/arm/mach-omap2/board-zoom-wlan.c         |  129
+++++++++++++++++++++++++
 arch/arm/mach-omap2/include/mach/board-zoom.h |    5 +
 2 files changed, 134 insertions(+), 0 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c

arch/arm/mach- renamed from arch/arm/mach-omap2/board-zoom-wlan.c +0 -0

omap2/board-zoom-wlan.c
new file mode 100644
index 0000000..7ed5139

arch/arm/mach-omap2/board-zoom-wlan.c new file +7 -0

@@ -0,0 +1,129 @@
+/* mach-omap2/board-zoom-wlan.c
+ *
+ * Board support for wl1271 embedded SDIO device.
+ *
+ * Copyright (C) 2010 Texas Instruments, Inc.
+ *
+ * This file is licensed under the terms of the GNU General Public

License
+ * version 2. This program is licensed "as is" without any warranty of any
+ * kind, whether express or implied.
+ */

arch/arm/mach-omap2/board-zoom-wlan.c new file +3 -0

+
+#include <linux/kernel.h>
+#include <linux/init.h>

arch/arm/mach-omap2/board-zoom-wlan.c new file +106 -0

+
+/* these are zoom-specific board numbers */
+#define OMAP_ZOOM_WLAN_PMENA_GPIO	(101)
+#define OMAP_ZOOM_WLAN_IRQ_GPIO		(162)
+
+/* wl1271 virtual 'card detect' status */
+static int omap_zoom_wlan_cd;
+static void (*wlan_set_virtual_cd)(void *dev_id, int card_present);
+static void (*wlan_set_data)(void *dev_id, void *priv);
+static void *wlan_host_devid;
+
+int omap_zoom_wlan_register_embedded_control(void *dev_id,
+			void (*set_virtual_cd)(void *dev_id, int card_present),
+			void (*set_data)(void *dev_id, void *priv))
+{
+	if (wlan_host_devid || wlan_set_virtual_cd || wlan_set_data)
+		return -EBUSY;
+
+	wlan_set_virtual_cd = set_virtual_cd;
+	wlan_set_data = set_data;
+	wlan_host_devid = dev_id;
+
+	return 0;
+}
+
+int omap_zoom_wlan_get_virtual_cd(void)
+{
+	return omap_zoom_wlan_cd;
+}
+
+static void omap_zoom_wlan_set_embedded_data(void *priv)
+{
+	if (wlan_set_data)
+		wlan_set_data(wlan_host_devid, priv);
+	else
+		pr_err("%s: host controller not registered yet\n", __func__);
+}
+
+static void omap_zoom_wlan_set_carddetect(bool card_present)
+{
+	omap_zoom_wlan_cd = card_present ? 1 : 0;
+
+	pr_info("%s: %d\n", __func__, omap_zoom_wlan_cd);
+
+	if (wlan_set_virtual_cd)
+		wlan_set_virtual_cd(wlan_host_devid, omap_zoom_wlan_cd);
+	else
+		pr_err("%s: host controller not registered yet\n", __func__);
+}
+
+static void omap_zoom_wlan_power(bool enable)
+{
+	int val = enable ? 1 : 0;
+
+	pr_info("%s: set power %d\n", __func__, val);
+
+	gpio_set_value(OMAP_ZOOM_WLAN_PMENA_GPIO, val);
+}
+
+struct wl12xx_platform_data omap_zoom_wlan_control = {
+	.set_power = omap_zoom_wlan_power,
+	.set_carddetect = omap_zoom_wlan_set_carddetect,
+	.set_embedded_data = omap_zoom_wlan_set_embedded_data,
+	/* ZOOM ref clock is 26 MHz */
+	.board_ref_clock = 1,
+	.irq = OMAP_GPIO_IRQ(OMAP_ZOOM_WLAN_IRQ_GPIO),
+};
+
+static struct platform_device omap_zoom_wlan_device = {
+	.name = "wl1271_sdio",
+	.id = 1,
+	.dev = {
+		.platform_data = &omap_zoom_wlan_control,
+	},
+};
+
+int __init omap_zoom_wlan_init(void)
+{
+	int ret;
+
+	ret = gpio_request(OMAP_ZOOM_WLAN_PMENA_GPIO, "wlan_power");
+	if (ret < 0) {
+		pr_err("%s: power gpio request failed: %d\n", __func__, ret);
+		return ret;
+	}
+
+	gpio_direction_output(OMAP_ZOOM_WLAN_PMENA_GPIO, 0);
+
+	ret = gpio_request(OMAP_ZOOM_WLAN_IRQ_GPIO, "wlan_irq");
+	if (ret < 0) {
+		pr_err("%s: gpio request failed: %d\n", __func__, ret);
+		return ret;
+	}
+	gpio_direction_input(OMAP_ZOOM_WLAN_IRQ_GPIO);
+
+	ret = platform_device_register(&omap_zoom_wlan_device);
+
+	return ret;
+}
+
+#else
+int __init omap_zoom_wlan_init(void)
+{
+	return 0;
+}
+#endif /* CONFIG_OMAP_ZOOM_WLAN */

arch/arm/mach-omap2/include/mach/board-zoom.h +5 -1

index c93b29e..61bbd81 100644
@@ -3,3 +3,8 @@
  */
 extern int __init zoom_debugboard_init(void);
 extern void __init zoom_peripherals_init(void);
+int __init omap_zoom_wlan_init(void);
+int omap_zoom_wlan_register_embedded_control(void *dev_id,
+			void (*set_virtual_cd)(void *dev_id, int card_present),
+			void (*set_data)(void *dev_id, void *priv));
+int omap_zoom_wlan_get_virtual_cd(void);
--

1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc- owner at vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux- omap at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm at linux- foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 15/15] omap: zoom: enable WLAN device

From: Ohad Ben-Cohen <[email protected]>

Make it possible to build and use TI's wl1271
device on the ZOOM boards.

The device is an embedded SDIO WLAN chip
that is hardwired to the 3rd mmc controller
of the ZOOM2/3 boards.

Signed-off-by Ohad Ben-Cohen <[email protected]>

---
 arch/arm/mach-omap2/Kconfig                  |    5 +++++
 arch/arm/mach-omap2/Makefile                 |    1 +
 arch/arm/mach-omap2/board-zoom-peripherals.c |   15 +++++++++++++++
 3 files changed, 21 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/Kconfig +5 -0

index b31b6f1..7fee11b 100644
@@ -131,6 +131,11 @@ config MACH_OMAP_ZOOM3
 	depends on ARCH_OMAP3
 	select OMAP_PACKAGE_CBP
 
+config OMAP_ZOOM_WLAN
+	bool "OMAP Zoom board WLAN support"
+	depends on MACH_OMAP_ZOOM2 || MACH_OMAP_ZOOM3
+	select MMC_EMBEDDED_SDIO
+
 config MACH_CM_T35
 	bool "CompuLab CM-T35 module"
 	depends on ARCH_OMAP3

arch/arm/mach-omap2/Makefile +1 -0

index ea52b03..ac1bad9 100644
@@ -129,6 +129,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM3)		+= board-
 zoom3.o \
 					   board-zoom-peripherals.o \
 					   hsmmc.o \
 					   board-zoom-debugboard.o
+obj-y					+= board-zoom-wlan.o
 obj-$(CONFIG_MACH_OMAP_3630SDP)		+= board-3630sdp.o \
 					   board-zoom-peripherals.o \

arch/arm/mach-omap2/Makefile +0 -0

 					   hsmmc.o

arch/arm/mach- renamed from arch/arm/mach-omap2/board-zoom-peripherals.c +0 -0

omap2/board-zoom-peripherals.c
index 6b39849..3128cd4 100644

arch/arm/mach-omap2/board-zoom-peripherals.c +14 -0

@@ -16,11 +16,13 @@
 #include <linux/gpio.h>
 #include <linux/i2c/twl.h>
 #include <linux/regulator/machine.h>
+#include <linux/mmc/host.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 
+#include <mach/board-zoom.h>
 #include <plat/common.h>
 #include <plat/usb.h>
 

@@ -168,6 +170,18 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 		.nonremovable	= true,
 		.power_saving	= true,
 	},
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+	{
+		.mmc		= 3,
+		.wires		= 4,
+		.gpio_cd	= -EINVAL,
+		.gpio_wp	= -EINVAL,
+		.register_embedded_control =
+				omap_zoom_wlan_register_embedded_control,
+		.virtual_get_cd = omap_zoom_wlan_get_virtual_cd,
+		.ocr_mask	= MMC_VDD_165_195,
+	},
+#endif
 	{}      /* Terminator */
 };
 

--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Ghorai] In general we can avoid OMAP_ZOOM_WLAN and MMC_EMBEDDED_SDIO as kconfig option. 1st one is board specific and 2nd one could be generic sdio code. As I mentioned in other patch too.

Quoted 7 lines

--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at ?http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: [email protected] [mailto:linux-mmc- [email protected]] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: [email protected]; [email protected]; linux- [email protected]
Cc: [email protected]; [email protected]; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm@linux- foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 15/15] omap: zoom: enable WLAN device

From: Ohad Ben-Cohen <[email protected]>

Make it possible to build and use TI's wl1271
device on the ZOOM boards.

The device is an embedded SDIO WLAN chip
that is hardwired to the 3rd mmc controller
of the ZOOM2/3 boards.

Signed-off-by Ohad Ben-Cohen <[email protected]>

---
 arch/arm/mach-omap2/Kconfig                  |    5 +++++
 arch/arm/mach-omap2/Makefile                 |    1 +
 arch/arm/mach-omap2/board-zoom-peripherals.c |   15 +++++++++++++++
 3 files changed, 21 insertions(+), 0 deletions(-)

arch/arm/mach-omap2/Kconfig +5 -0

index b31b6f1..7fee11b 100644
@@ -131,6 +131,11 @@ config MACH_OMAP_ZOOM3
 	depends on ARCH_OMAP3
 	select OMAP_PACKAGE_CBP
 
+config OMAP_ZOOM_WLAN
+	bool "OMAP Zoom board WLAN support"
+	depends on MACH_OMAP_ZOOM2 || MACH_OMAP_ZOOM3
+	select MMC_EMBEDDED_SDIO
+
 config MACH_CM_T35
 	bool "CompuLab CM-T35 module"
 	depends on ARCH_OMAP3

arch/arm/mach-omap2/Makefile +1 -0

index ea52b03..ac1bad9 100644
@@ -129,6 +129,7 @@ obj-$(CONFIG_MACH_OMAP_ZOOM3)		+= board-
 zoom3.o \
 					   board-zoom-peripherals.o \
 					   hsmmc.o \
 					   board-zoom-debugboard.o
+obj-y					+= board-zoom-wlan.o
 obj-$(CONFIG_MACH_OMAP_3630SDP)		+= board-3630sdp.o \
 					   board-zoom-peripherals.o \

arch/arm/mach-omap2/Makefile +0 -0

 					   hsmmc.o

arch/arm/mach- renamed from arch/arm/mach-omap2/board-zoom-peripherals.c +0 -0

omap2/board-zoom-peripherals.c
index 6b39849..3128cd4 100644

arch/arm/mach-omap2/board-zoom-peripherals.c +14 -0

@@ -16,11 +16,13 @@
 #include <linux/gpio.h>
 #include <linux/i2c/twl.h>
 #include <linux/regulator/machine.h>
+#include <linux/mmc/host.h>
 
 #include <asm/mach-types.h>
 #include <asm/mach/arch.h>
 #include <asm/mach/map.h>
 
+#include <mach/board-zoom.h>
 #include <plat/common.h>
 #include <plat/usb.h>
 

@@ -168,6 +170,18 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 		.nonremovable	= true,
 		.power_saving	= true,
 	},
+#ifdef CONFIG_OMAP_ZOOM_WLAN
+	{
+		.mmc		= 3,
+		.wires		= 4,
+		.gpio_cd	= -EINVAL,
+		.gpio_wp	= -EINVAL,
+		.register_embedded_control =
+				omap_zoom_wlan_register_embedded_control,
+		.virtual_get_cd = omap_zoom_wlan_get_virtual_cd,
+		.ocr_mask	= MMC_VDD_165_195,
+	},
+#endif
 	{}      /* Terminator */
 };
 

--
1.7.0.4

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: linux-mmc-owner at vger.kernel.org [mailto:linux-mmc- owner at vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux- omap at vger.kernel.org
Cc: linux-arm-kernel at lists.infradead.org; linux at arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm at linux- foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 00/15] wlan+omap+mmc: out-of-the-box WLAN support for ZOOM2/3

From: Ohad Ben-Cohen <[email protected]>

The ZOOM2/3 boards include TI's wl1271 wlan sdio device, hardwired to the 3rd mmc controller.

These patches add support for WLAN on the ZOOM2/3 boards using only mainline components (most notably mac80211 and wl1271).

Patches were tested on both ZOOM2 and ZOOM3.

In short, these patches add software control for emulating card detect events, add board configurations to support the wl1271 device, and update the wl1271 driver to make use of these new mechanisms.

Software card detect emulation is based on Android's EMBEDDED_SDIO patch by San Mehat <[email protected]> (thanks, San!).

These patches span over several differnt subsystems, but since they are highly dependent on each other, it is preferrable to pull them all together into a single tree (once approved).

Patches are available at:

git://wizery.com/pub/linux-2.6.git wl1271

And will also be sent as a follow-on to this message to the omap, mmc, arm and wireless mailing lists.

Patches are based on mainline 2.6.35-rc4, but can easily be applied on wireless-testing (with two minor conflicts). If desired, I can rebase to wireless-testing and resend.

Note: last missing part for full mainline community support of the wl1271 on ZOOM is the firmware, and for that there is already on-going TI work to provide it in linux-firmware. Hopefully that would be resolved soon.

Thanks,

Ohad Ben-Cohen (15):
sdio: add TI + wl1271 ids
wireless: wl1271: remove SDIO IDs from driver
omap: mmc: prepare for software card detect support
mmc: support embedded data field in mmc_host
omap: hsmmc: add virtual card detect support
omap zoom2: wlan board muxing
omap zoom3: wlan board muxing
wireless: wl1271: make wl12xx.h common to both spi and sdio
wireless: wl12xx: support pdata SDIO handlers
wireless: wl1271: support return value for the set power func
wireless: wl1271: introduce platform device support
wireless: wl1271: take irq info from platform data
wireless: wl1271: make ref_clock configurable by board
omap: zoom: add WLAN device
omap: zoom: enable WLAN device

 arch/arm/mach-omap2/Kconfig                   |    5 +
 arch/arm/mach-omap2/Makefile                  |    1 +
 arch/arm/mach-omap2/board-zoom-peripherals.c  |   15 ++
 arch/arm/mach-omap2/board-zoom-wlan.c         |  129 ++++++++++++++++
 arch/arm/mach-omap2/board-zoom2.c             |   15 ++
 arch/arm/mach-omap2/board-zoom3.c             |   15 ++
 arch/arm/mach-omap2/hsmmc.c                   |    4 +
 arch/arm/mach-omap2/hsmmc.h                   |    5 +
 arch/arm/mach-omap2/include/mach/board-zoom.h |    5 +
 arch/arm/plat-omap/include/plat/mmc.h         |    5 +
 drivers/mmc/core/Kconfig                      |    8 +
 drivers/mmc/host/omap_hsmmc.c                 |   37 +++++-
 drivers/net/wireless/wl12xx/Kconfig           |    1 +
 drivers/net/wireless/wl12xx/wl1251_sdio.c     |    2 +-
 drivers/net/wireless/wl12xx/wl1251_spi.c      |    2 +-
 drivers/net/wireless/wl12xx/wl1271.h          |    8 +-
 drivers/net/wireless/wl12xx/wl1271_boot.c     |   13 +-
 drivers/net/wireless/wl12xx/wl1271_boot.h     |    1 -
 drivers/net/wireless/wl12xx/wl1271_io.h       |    8 +-
 drivers/net/wireless/wl12xx/wl1271_main.c     |    4 +-
 drivers/net/wireless/wl12xx/wl1271_sdio.c     |  204 +++++++++++++++++++-
-----
 drivers/net/wireless/wl12xx/wl1271_spi.c      |    8 +-

 include/linux/mmc/host.h                      |   16 ++
 include/linux/mmc/sdio_ids.h                  |    3 +
 include/linux/spi/wl12xx.h                    |   34 ----
 include/linux/wl12xx.h                        |   37 +++++
 26 files changed, 486 insertions(+), 99 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c
 delete mode 100644 include/linux/spi/wl12xx.h
 create mode 100644 include/linux/wl12xx.h

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo at vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

-----Original Message-----
From: [email protected] [mailto:linux-mmc- [email protected]] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: [email protected]; [email protected]; linux- [email protected]
Cc: [email protected]; [email protected]; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; akpm@linux- foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 00/15] wlan+omap+mmc: out-of-the-box WLAN support for ZOOM2/3

From: Ohad Ben-Cohen <[email protected]>

The ZOOM2/3 boards include TI's wl1271 wlan sdio device, hardwired to the 3rd mmc controller.

These patches add support for WLAN on the ZOOM2/3 boards using only mainline components (most notably mac80211 and wl1271).

Patches were tested on both ZOOM2 and ZOOM3.

In short, these patches add software control for emulating card detect events, add board configurations to support the wl1271 device, and update the wl1271 driver to make use of these new mechanisms.

Software card detect emulation is based on Android's EMBEDDED_SDIO patch by San Mehat <[email protected]> (thanks, San!).

These patches span over several differnt subsystems, but since they are highly dependent on each other, it is preferrable to pull them all together into a single tree (once approved).

Patches are available at:

git://wizery.com/pub/linux-2.6.git wl1271

And will also be sent as a follow-on to this message to the omap, mmc, arm and wireless mailing lists.

Patches are based on mainline 2.6.35-rc4, but can easily be applied on wireless-testing (with two minor conflicts). If desired, I can rebase to wireless-testing and resend.

Note: last missing part for full mainline community support of the wl1271 on ZOOM is the firmware, and for that there is already on-going TI work to provide it in linux-firmware. Hopefully that would be resolved soon.

Thanks,

Ohad Ben-Cohen (15):
sdio: add TI + wl1271 ids
wireless: wl1271: remove SDIO IDs from driver
omap: mmc: prepare for software card detect support
mmc: support embedded data field in mmc_host
omap: hsmmc: add virtual card detect support
omap zoom2: wlan board muxing
omap zoom3: wlan board muxing
wireless: wl1271: make wl12xx.h common to both spi and sdio
wireless: wl12xx: support pdata SDIO handlers
wireless: wl1271: support return value for the set power func
wireless: wl1271: introduce platform device support
wireless: wl1271: take irq info from platform data
wireless: wl1271: make ref_clock configurable by board
omap: zoom: add WLAN device
omap: zoom: enable WLAN device

 arch/arm/mach-omap2/Kconfig                   |    5 +
 arch/arm/mach-omap2/Makefile                  |    1 +
 arch/arm/mach-omap2/board-zoom-peripherals.c  |   15 ++
 arch/arm/mach-omap2/board-zoom-wlan.c         |  129 ++++++++++++++++
 arch/arm/mach-omap2/board-zoom2.c             |   15 ++
 arch/arm/mach-omap2/board-zoom3.c             |   15 ++
 arch/arm/mach-omap2/hsmmc.c                   |    4 +
 arch/arm/mach-omap2/hsmmc.h                   |    5 +
 arch/arm/mach-omap2/include/mach/board-zoom.h |    5 +
 arch/arm/plat-omap/include/plat/mmc.h         |    5 +
 drivers/mmc/core/Kconfig                      |    8 +
 drivers/mmc/host/omap_hsmmc.c                 |   37 +++++-
 drivers/net/wireless/wl12xx/Kconfig           |    1 +
 drivers/net/wireless/wl12xx/wl1251_sdio.c     |    2 +-
 drivers/net/wireless/wl12xx/wl1251_spi.c      |    2 +-
 drivers/net/wireless/wl12xx/wl1271.h          |    8 +-
 drivers/net/wireless/wl12xx/wl1271_boot.c     |   13 +-
 drivers/net/wireless/wl12xx/wl1271_boot.h     |    1 -
 drivers/net/wireless/wl12xx/wl1271_io.h       |    8 +-
 drivers/net/wireless/wl12xx/wl1271_main.c     |    4 +-
 drivers/net/wireless/wl12xx/wl1271_sdio.c     |  204 +++++++++++++++++++-
-----
 drivers/net/wireless/wl12xx/wl1271_spi.c      |    8 +-

 include/linux/mmc/host.h                      |   16 ++
 include/linux/mmc/sdio_ids.h                  |    3 +
 include/linux/spi/wl12xx.h                    |   34 ----
 include/linux/wl12xx.h                        |   37 +++++
 26 files changed, 486 insertions(+), 99 deletions(-)
 create mode 100644 arch/arm/mach-omap2/board-zoom-wlan.c
 delete mode 100644 include/linux/spi/wl12xx.h
 create mode 100644 include/linux/wl12xx.h

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html