native support for wl1271 on ZOOM

Add SDIO IDs for TI and for TI's wl1271 wlan device.

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

---
 include/linux/mmc/sdio_ids.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

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

index 33b2ea0..0d313c6 100644

Quoted 15 lines

Add SDIO IDs for TI and for TI's wl1271 wlan device.

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

---
?include/linux/mmc/sdio_ids.h | ? ?3 +++
?1 files changed, 3 insertions(+), 0 deletions(-)

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

index 33b2ea0..0d313c6 100644
@@ -43,4 +43,7 @@

?#define SDIO_DEVICE_ID_SIANO_NOVA_A0 ? ? ? ? 0x1100 ?#define SDIO_DEVICE_ID_SIANO_STELLAR ? ? ? ? ? ? ? ? 0x5347

include/linux/mmc/sdio_ids.h

Quoted 3 lines

include/linux/mmc/sdio_ids.h +3 -0

+#define SDIO_VENDOR_ID_TI ? ? ? ? ? ? ? ? ? ?0x0097
+#define SDIO_DEVICE_ID_TI_WL1271 ? ? ? ? ? ? 0x4076
+

are we still doing this non-sense for no real reason. What is so wrong with keeping the IDs inside the driver code?

Personally I don't even see a point for these ID defines at all. Just use the bare numbers in SDIO_DEVICE and put a comment above what kind of device this is.

Regards

Marcel

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

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.

(quoted diff) +0 -0

@@ -209,6 +209,8 @@ struct mmc_host {

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

+ ? ? ? void ? ? ? ? ? ? ? ? ? ?*embedded_data;
+

Quoted 7 lines · Ohad Ben-Cohen

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.

<snip>

Quoted 6 lines

(quoted diff) +0 -0

@@ -209,6 +209,8 @@ struct mmc_host {

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

+ ? ? ? void ? ? ? ? ? ? ? ? ? ?*embedded_data;
+

To my understanding, this data doesn't belong to mmc_host. It's not a host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's totally unrelated to host.

I think a cleaner way would be to introduce something similar to what we have for SPI, e. g. struct sdio_board_info. This board info will contain platform-specific stuff and vendor id/chip id for each onboard SDIO device. Then the SDIO core will pick up the appropriate data basing on vendor id/chip id.

~Vitaly

Quoted 9 lines

To my understanding, this data doesn't belong to mmc_host. It's not a host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's totally unrelated to host.

I think a cleaner way would be to introduce something similar to what we have for SPI, e. g. struct sdio_board_info. This board info will contain platform-specific stuff and vendor id/chip id for each onboard SDIO device. Then the SDIO core will pick up the appropriate data basing on vendor id/chip id.

Can you please elaborate some more about your proposal (specifically where does this sdio_board_info get set and how do function drivers access it) ?

If I understand you correctly, you suggest to have a global, board-specific table of sdio_board_info structures, which would be accessible to the SDIO core (through the host driver ?). When a new SDIO device is found the core would search this table for the appropriate sdio_board_info struct and make it accessible to the SDIO function driver ?

Quoted 14 lines · Ohad Ben-Cohen

Quoted 9 lines

To my understanding, this data doesn't belong to mmc_host. It's not a host data at all. E. g. imagine a GPIO IRQ for some SDIO chip -- it's totally unrelated to host.

I think a cleaner way would be to introduce something similar to what we have for SPI, e. g. struct sdio_board_info. This board info will contain platform-specific stuff and vendor id/chip id for each onboard SDIO device. Then the SDIO core will pick up the appropriate data basing on vendor id/chip id.

Can you please elaborate some more about your proposal (specifically where does this sdio_board_info get set and how do function drivers access it) ?

Quoted 6 lines

If I understand you correctly, you suggest to have a global, board-specific table of sdio_board_info structures, which would be accessible to the SDIO core (through the host driver ?). When a new SDIO device is found the core would search this table for the appropriate sdio_board_info struct and make it accessible to the SDIO function driver ?

Well, let's look at how it's implemented for SPI. There is the function spi_register_board_info in the SPI core which copies the board info into the local data structure (a linked list, actually). Whenever needed, the core walks through the list to find the appropriate board_info basing on some search key.

I think this may be the way to go for SDIO as well.

~Vitaly

SPI is using these spi_board_info tables to populate the SPI device trees. These tables are registered early at the board-specific init code, and are later used by SPI core to populate the devices when the SPI master controller is registered.

SDIO doesn't normally needs any kind of hard coded data: most devices are dynamically probed and populated.

On rare cases like the wl1271, we have some platform-specific data we need to deliver the SDIO function driver (i.e. the irq info in this case). Since the device is hardwired to a specific controller, it does make some sense to pass this private data from the controller's info in the board files, through the host driver, and make it accessible through the specific host instance that drives this controller.

Btw, if our problem was be broader (e.g., needs to supply private data for non-hardwired devices), then I agree that a more complex mechanism, such as the one you suggest, would be needed. But currently the problem is very simple and the solution is even simpler: just add 1 private pointer to the host.

Hope you find this reasonable,

Quoted 15 lines · Ohad Ben-Cohen

SPI is using these spi_board_info tables to populate the SPI device trees. These tables are registered early at the board-specific init code, and are later used by SPI core to populate the devices when the SPI master controller is registered.

SDIO doesn't normally needs any kind of hard coded data: most devices are dynamically probed and populated.

On rare cases like the wl1271, we have some platform-specific data we need to deliver the SDIO function driver (i.e. the irq info in this case). Since the device is hardwired to a specific controller, it does make some sense to pass this private data from the controller's info in the board files, through the host driver, and make it accessible through the specific host instance that drives this controller.

Quoted 7 lines

Btw, if our problem was be broader (e.g., needs to supply private data for non-hardwired devices), then I agree that a more complex mechanism, such as the one you suggest, would be needed. But currently the problem is very simple and the solution is even simpler: just add 1 private pointer to the host.

Hope you find this reasonable,

no, actually I don't. I think this is a hack that intrudes into the area it completely doesn't belong to.

In fact, one can have 2 views on this problem: either this is a fairly generic problem we need to address, or this is a very specific corner case.
Your solution will be treated as a hack in both cases.

If we consider it a generic problem, then we need to find a generic solution, which is the board_info solution, for instance. FWIW, I2C also uses this approach now.

If we consider it to be a corner case, let's just add a dummy platform_device like it's done in WL1251 implementation and keep the MMC subsystem clean.

Thanks,
? Vitaly

I'm honestly trying to understand your concerns, but I'm afraid that just saying "it's a hack" is not too informative. Can you please explain what do you think is technically wrong with the proposed solution ? is it not general enough for other use cases ? will it break something ?

Quoted 5 lines · Ohad Ben-Cohen

I'm honestly trying to understand your concerns, but I'm afraid that just saying "it's a hack" is not too informative. Can you please explain what do you think is technically wrong with the proposed solution ? is it not general enough for other use cases ? will it break something ?

So if I'd like to set the *same* structure for the *same* WL1271 driver, provided that I'm working with the other platform, I'll need to do the following:
- add the pointer to the board-specific header;
- add the structure to the board-specific C file and propagate its pointer to the controller driver;
- add setting the pointer in the core structure into the controller driver.

This is far from being intuitive. This means we need to hack, generally speaking, all the MMC controller drivers to get it working on all platforms. This is error prone.

Hi Vitaly,

Quoted 15 lines · Vitaly Wool

Quoted 5 lines · Ohad Ben-Cohen

I'm honestly trying to understand your concerns, but I'm afraid that just saying "it's a hack" is not too informative. Can you please explain what do you think is technically wrong with the proposed solution ? is it not general enough for other use cases ? will it break something ?

So if I'd like to set the *same* structure for the *same* WL1271 driver, provided that I'm working with the other platform, I'll need to do the following:
- add the pointer to the board-specific header;
- add the structure to the board-specific C file and propagate its pointer to the controller driver;
- add setting the pointer in the core structure into the controller driver.

Quoted 3 lines

This is far from being intuitive. This means we need to hack, generally speaking, all the MMC controller drivers to get it working on all platforms. This is error prone.

You make it sound really complex.

Let's see what it means to add it to a totally different platform.

As an example, let's take Google's ADP1 which is based on a different host controller (msm-sdcc), and add the required support (untested of course, just a quick sketch, patch is based on android's msm git):

Quoted 20 lines · Ohad Ben-Cohen

Quoted 15 lines · Vitaly Wool

Quoted 5 lines · Ohad Ben-Cohen

I'm honestly trying to understand your concerns, but I'm afraid that just saying "it's a hack" is not too informative. Can you please explain what do you think is technically wrong with the proposed solution ? is it not general enough for other use cases ? will it break something ?

So if I'd like to set the *same* structure for the *same* WL1271 driver, provided that I'm working with the other platform, I'll need to do the following:
- add the pointer to the board-specific header;
- add the structure to the board-specific C file and propagate its pointer to the controller driver;
- add setting the pointer in the core structure into the controller driver.

Quoted 3 lines

This is far from being intuitive. This means we need to hack, generally speaking, all the MMC controller drivers to get it working on all platforms. This is error prone.

Quoted 7 lines

You make it sound really complex.

Let's see what it means to add it to a totally different platform.

As an example, let's take Google's ADP1 which is based on a different host controller (msm-sdcc), and add the required support (untested of course, just a quick sketch, patch is based on android's msm git):

What if some other driver gets attached and tries to use this platform data? ?This whole idea sounds extremely silly, cumbersome, error prone, and is inviting misuse by normal MMC sockets.

Why not arrange for a small piece of code to be built into the kernel when this driver is selected as a module or built-in, which handles the passing of platform data to the driver?

Something like:

wl12xx_platform_data.c:
#include <linux/module.h>
#include <whatever/required/for/wl12xx.h>

static struct wl12xx_platform_data *platform_data;

int __init wl12xx_set_platform_data(const struct wl12xx_platform_data *data) {
? ? ? ?if (platform_data)
? ? ? ? ? ? ? ?return -EBUSY;
? ? ? ?platform_data = kmemdup(data, sizeof(*data), GFP_KERNEL); ? ? ? ?if (!platform_data)
? ? ? ? ? ? ? ?return -ENOMEM;
? ? ? ?return 0;
}

int wl12xx_get_platform_data(struct wl12xx_platform_data *data) {
? ? ? ?if (platform_data) {
? ? ? ? ? ? ? ?memcpy(data, platform_data, sizeof(*data)); ? ? ? ? ? ? ? ?return 0;
? ? ? ?}
? ? ? ?return -ENODEV;
}
EXPORT_SYMBOL(wl12xx_get_platform_data);

And in the Kconfig, something like:

config WL12XX_PLATFORM_DATA
? ? ? ?bool
? ? ? ?depends on WL12XX != n
? ? ? ?default y

This means there'll be no confusion over who owns the 'embedded data', typechecking is preserved, and no possibility for the wrong driver to pick up the data.

Quoted 29 lines · Russell King - ARM Linux

Quoted 20 lines · Ohad Ben-Cohen

Quoted 15 lines · Vitaly Wool

Quoted 5 lines · Ohad Ben-Cohen

I'm honestly trying to understand your concerns, but I'm afraid that just saying "it's a hack" is not too informative. Can you please explain what do you think is technically wrong with the proposed solution ? is it not general enough for other use cases ? will it break something ?

So if I'd like to set the *same* structure for the *same* WL1271 driver, provided that I'm working with the other platform, I'll need to do the following:
- add the pointer to the board-specific header;
- add the structure to the board-specific C file and propagate its pointer to the controller driver;
- add setting the pointer in the core structure into the controller driver.

Quoted 3 lines

This is far from being intuitive. This means we need to hack, generally speaking, all the MMC controller drivers to get it working on all platforms. This is error prone.

Quoted 7 lines

You make it sound really complex.

Let's see what it means to add it to a totally different platform.

As an example, let's take Google's ADP1 which is based on a different host controller (msm-sdcc), and add the required support (untested of course, just a quick sketch, patch is based on android's msm git):

Quoted 7 lines

What if some other driver gets attached and tries to use this platform data? ?This whole idea sounds extremely silly, cumbersome, error prone, and is inviting misuse by normal MMC sockets.

Why not arrange for a small piece of code to be built into the kernel when this driver is selected as a module or built-in, which handles the passing of platform data to the driver?

It's interesting.

The only drawback I can see is that it has an inherent limitation of having only a single wl1271 device on board, but there are no such boards outside development/testing labs.

Vitaly would that work for you too ?

On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux

Quoted 4 lines

Why not arrange for a small piece of code to be built into the kernel when this driver is selected as a module or built-in, which handles the passing of platform data to the driver?

It's interesting.

The only drawback I can see is that it has an inherent limitation of having only a single wl1271 device on board,

2010/8/4 Ohad Ben-Cohen <[email protected]>:

Quoted 10 lines

On Wed, Aug 4, 2010 at 2:41 PM, Russell King - ARM Linux

Quoted 4 lines

Why not arrange for a small piece of code to be built into the kernel when this driver is selected as a module or built-in, which handles the passing of platform data to the driver?

It's interesting.

The only drawback I can see is that it has an inherent limitation of having only a single wl1271 device on board,

...which is exactly what the *_board_info scheme in the spi and i2c subsystems is designed to solve.

This is an established design pattern in the kernel with two precedents, what makes it so hard to implement this idea? There are plenty of examples all over the place.

We have Russell's suggestion which is nice and simple, but it has the 1 device limitation.

Quoted 2 lines · Ohad Ben-Cohen

We have Russell's suggestion which is nice and simple, but it has the 1 device limitation.

You could make it generic by doing something like this:

#define set_device_data(name, type, index, data) \

 ({									\
    extern void __set_device_data(const char *, int, void *, size_t);	\
    BUILD_BUG_ON(!__same_type(type, *data));				\
    __set_device_data(name ":" #type, index, data, sizeof(type));	\

})

#define get_device_data(name, type, index) ({ \
extern void *__get_device_data(const char *, int); \
type *__ptr = __get_device_data(name ":" #type, index); \
__ptr; })

And now we have something that takes a string and index to use as a lookup key in some kind of list - and it's typesafe (because the lookup key is dependent on the stringified type.)

But... at this point I feel that we're getting too complicated, and will get shouted at to use something like DT which already solves this problem.

arch/arm/mach-omap2/board-zoom-peripherals.c static struct regulator_consumer_supply zoom_vmmc2_supply = { · line 114

Quoted 3 lines · Ohad Ben-Cohen

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

+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+	.supply		= "vmmc",
+};

This looks like a misconfiguration on the consumer - I'd strongly expect the consumer to have a dev_name specified also with the name being in terms of the consumer device.

Quoted 10 lines · ext Mark Brown

arch/arm/mach-omap2/board-zoom-peripherals.c static struct regulator_consumer_supply zoom_vmmc2_supply = { · line 114

Quoted 3 lines · Ohad Ben-Cohen

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

+static struct regulator_consumer_supply zoom_vmmc3_supply = {
+ ? ? ? .supply ? ? ? ? = "vmmc",
+};

This looks like a misconfiguration on the consumer - I'd strongly expect the consumer to have a dev_name specified also with the name being in terms of the consumer device.

you need to add something like

.dev_name ? ? ? = "mmci-omap-hs.2"

regards,
-roger

Quoted 1 line · Roger Quadros

.dev_name ? ? ? = "mmci-omap-hs.2"

I already set the .dev member of the consumer in a similar manner to how all other regulators are configured in this board - please check out patch 13:

https://patchwork.kernel.org/patch/113418/

Does this look reasonable to you ?

Quoted 6 lines · Ohad Ben-Cohen

Quoted 1 line · Roger Quadros

.dev_name ? ? ? = "mmci-omap-hs.2"

I already set the .dev member of the consumer in a similar manner to how all other regulators are configured in this board - please check out patch 13:

Quoted 3 lines

https://patchwork.kernel.org/patch/113418/

Does this look reasonable to you ?

You should really be using dev_name in preference to dev these days unless there's a *very* good reason.

Add support for an SDIO device to stay powered off even without the presence of an SDIO function driver. A host should explicitly ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO function driver should know it needs to call sdio_claim_power before accessing the device.

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

Quoted 7 lines · ext Ohad Ben-Cohen

Add support for an SDIO device to stay powered off even without the presence of an SDIO function driver. A host should explicitly ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO function driver should know it needs to call sdio_claim_power before accessing the device.

Quoted 1 line

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

Shouldn't this be the default behaviour? If there is no function driver for any of the functions of the card, then sdio core shold power off the card.

I don't see a need for a special capability flag for this.

in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability

flag, it seems more like a request from the board to keep the card powered off.

regards,
-roger

Quoted 8 lines · Roger Quadros

Quoted 7 lines · ext Ohad Ben-Cohen

Add support for an SDIO device to stay powered off even without the presence of an SDIO function driver. A host should explicitly ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO function driver should know it needs to call sdio_claim_power before accessing the device.

Quoted 8 lines

Quoted 1 line

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

Shouldn't this be the default behaviour? If there is no function driver for any of the functions of the card, then sdio core shold power off the card.

I don't see a need for a special capability flag for this.

in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability

Totally agree.

I didn't want to change the current behavior of the cards/funcs so I looked for a way to explicitly power down only specific cards.

Alternatively we could power down all cards at the end mmc_attach_sdio, and then power them up selectively in sdio_bus_probe, just before calling probe. If the probe succeeds, the function driver takes over. If the probe fails, we can power them down again.

Is that what you meant ?

This would work both if the sdio function driver is already loaded, or will only be loaded at a later time. But I'm not too fond of the extra power on/off cycles that it will introduce for each card..

Quoted 23 lines · Ohad Ben-Cohen

Quoted 8 lines · Roger Quadros

Quoted 7 lines · ext Ohad Ben-Cohen

Add support for an SDIO device to stay powered off even without the presence of an SDIO function driver. A host should explicitly ask for it by means of MMC_CAP_DONT_POWER_CARD, and the SDIO function driver should know it needs to call sdio_claim_power before accessing the device.

Quoted 8 lines

Quoted 1 line

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

Shouldn't this be the default behaviour? If there is no function driver for any of the functions of the card, then sdio core shold power off the card.

I don't see a need for a special capability flag for this.

in fact MMC_CAP_DONT_POWER_CARD does not seem like an mmc host's capability

Totally agree.

I didn't want to change the current behavior of the cards/funcs so I looked for a way to explicitly power down only specific cards.

Quoted 4 lines

Alternatively we could power down all cards at the end mmc_attach_sdio, and then power them up selectively in sdio_bus_probe, just before calling probe. If the probe succeeds, the function driver takes over. If the probe fails, we can power them down again.

Exactly!

From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
Sent: Wednesday, July 21, 2010 12:34 PM
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; Roger Quadros; Tony Lindgren; Nicolas Pitre; Pandita, Vikram; Kalle Valo; Ohad Ben-Cohen
Subject: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off

Keep the MMC3 wl1271 WLAN device powered off until its SDIO function driver requests otherwise.

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

---

?arch/arm/mach-omap2/board-zoom-peripherals.c | ? ?1 +
?arch/arm/mach-omap2/hsmmc.c ? ? ? ? ? ? ? ? ?| ? ?3 +++
?arch/arm/mach-omap2/hsmmc.h ? ? ? ? ? ? ? ? ?| ? ?1 +
?arch/arm/plat-omap/include/plat/mmc.h ? ? ? ?| ? ?3 +++
?drivers/mmc/host/omap_hsmmc.c ? ? ? ? ? ? ? ?| ? ?3 +++

?5 files changed, 11 insertions(+), 0 deletions(-)

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

index 3230801..3ab9125 100644
@@ -217,6 +217,7 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
 ? ? ? ? ? ? ? ?.gpio_wp ? ? ? ?= -EINVAL,
 ? ? ? ? ? ? ? ?.gpio_cd ? ? ? ?= -EINVAL,
 ? ? ? ? ? ? ? ?.ocr_mask ? ? ? = MMC_VDD_165_195,
+ ? ? ? ? ? ? ? .dont_power_card = true,
 ? ? ? ? ? ? ? ?.priv_data ? ? ?= &omap_zoom_wlan_data,
 ? ? ? ?},

? ? ? ?{} ? ? ?/* Terminator */

--
1.7.0.4

[Benzy Gabay] small comment: Please make sure that all 127x related changes are not bounded only to MMC3. On OMAP4 WLAN is used on MMC5.

-----Original Message-----
From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
Sent: Thursday, July 22, 2010 6:18 PM
To: Gabay, Benzy
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; akpm at linux-foundation.org; San Mehat; Roger Quadros; Tony Lindgren; Nicolas Pitre; Pandita, Vikram; Kalle Valo
Subject: Re: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device powered off

Hi Gever,

Quoted 3 lines · Benzy

From: Ohad Ben-Cohen [mailto:ohad at wizery.com]
Sent: Wednesday, July 21, 2010 12:34 PM
To: linux-wireless at vger.kernel.org; linux-mmc at vger.kernel.org; linux-

omap at vger.kernel.org

Quoted 1 line

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; Roger Quadros; Tony Lindgren; Nicolas Pitre; Pandita, Vikram; Kalle Valo; Ohad Ben-Cohen

Quoted 1 line

Subject: [PATCH v2 19/20] omap: zoom: keep the MMC3 wl1271 device

powered off

Quoted 6 lines

Keep the MMC3 wl1271 WLAN device powered off until its SDIO function driver requests otherwise.

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

---

Review

Quoted 8 lines

?arch/arm/mach-omap2/board-zoom-peripherals.c | ? ?1 +
?arch/arm/mach-omap2/hsmmc.c ? ? ? ? ? ? ? ? ?| ? ?3 +++
?arch/arm/mach-omap2/hsmmc.h ? ? ? ? ? ? ? ? ?| ? ?1 +
?arch/arm/plat-omap/include/plat/mmc.h ? ? ? ?| ? ?3 +++
?drivers/mmc/host/omap_hsmmc.c ? ? ? ? ? ? ? ?| ? ?3 +++

?5 files changed, 11 insertions(+), 0 deletions(-)

(quoted diff) +0 -0

b/arch/arm/mach-omap2/board-zoom-peripherals.c

arch/arm/mach-omap2/board-zoom-peripherals.c static struct omap2_hsmmc_info mmc[] __initdata =

Quoted 4 lines

index 3230801..3ab9125 100644

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

@@ -217,6 +217,7 @@ static struct omap2_hsmmc_info mmc[] __initdata =

{

Quoted 7 lines

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

 ? ? ? ? ? ? ? ?.gpio_wp ? ? ? ?= -EINVAL,
 ? ? ? ? ? ? ? ?.gpio_cd ? ? ? ?= -EINVAL,
 ? ? ? ? ? ? ? ?.ocr_mask ? ? ? = MMC_VDD_165_195,
+ ? ? ? ? ? ? ? .dont_power_card = true,
 ? ? ? ? ? ? ? ?.priv_data ? ? ?= &omap_zoom_wlan_data,
 ? ? ? ?},

? ? ? ?{} ? ? ?/* Terminator */

...

Quoted 4 lines

--
1.7.0.4

[Benzy Gabay] small comment: Please make sure that all 127x related

changes are not bounded only to MMC3.

Quoted 1 line

On OMAP4 WLAN is used on MMC5.

The only place MMC3 is bound is in the board files (see code snippet above), so that should be ok.

I can probably split this patch to make this more obvious just by reading the diffstat if you prefer.

Thanks,
Ohad.

Quoted 1 line

This patch series adds native support for wl1271 on ZOOM.

Changes since v1:

- introduce a fixed regulator device to control the power of wl1271
- allow to propagate private board-specific data to SDIO function drivers
- allow SDIO function driver to control the card's power via new API
- make it possible to keep the card's power down (without depending on an explicit SDIO function driver power-down request)

Thanks to these changes, we no longer need a separate platform device (carrying e.g. the external irq information of the device), and no longer need to emulate virtual card detect events.

The two "board muxing" pathces were already taken by Tony, and are resent here just to make it easier for people to use/test these pathces.

The changes to the MMC core really needs careful review; there still might be some pitfalls that haven't been covered. E.g., one thing we plan to look at next is their bahvior together with SDIO Suspend/Resume.

Special thanks to Roger Quadros and Nicolas Pitre for their extensive review and helpful suggestions.

Quoted 21 lines · Ohad Ben-Cohen

This patch series adds native support for wl1271 on ZOOM.

Changes since v1:

- introduce a fixed regulator device to control the power of wl1271
- allow to propagate private board-specific data to SDIO function drivers
- allow SDIO function driver to control the card's power via new API
- make it possible to keep the card's power down (without depending ? on an explicit SDIO function driver power-down request)

Thanks to these changes, we no longer need a separate platform device (carrying e.g. the external irq information of the device), and no longer need to emulate virtual card detect events.

The two "board muxing" pathces were already taken by Tony, and are resent here just to make it easier for people to use/test these pathces.

The changes to the MMC core really needs careful review; there still might be some pitfalls that haven't been covered. E.g., one thing we plan to look at next is their bahvior together with SDIO Suspend/Resume.

Quoted 2 lines

Special thanks to Roger Quadros and Nicolas Pitre for their extensive review and helpful suggestions.

FYI, I do intend to review those patches, but I'll be flying home in a couple hours, and once there I'll be gone on vacation for 2 weeks. ?So this review won't happen right away.

Nicolas

This patch series adds native support for wl1271 on ZOOM.

Quoted 1 line · Ohad Ben-Cohen

This patch series adds native support for wl1271 on ZOOM.

Just for the record, I'm fine with the wl1271 bits here going through the omap tree with the rest of the series.

John
--
John W. Linville ? ? ? ? ? ? ? ?Someday the world will need a hero, and you linville at tuxdriver.com ? ? ? ? ? ? ? ? ?might be all we have. ?Be ready.

Quoted 1 line · Ohad Ben-Cohen

This patch series adds native support for wl1271 on ZOOM.

Just for the record, I'm fine with the wl1271 bits here going through the omap tree with the rest of the series.

Quoted 5 lines · ext John W. Linville

Quoted 1 line · Ohad Ben-Cohen

This patch series adds native support for wl1271 on ZOOM.

Just for the record, I'm fine with the wl1271 bits here going through the omap tree with the rest of the series.

Yeah, I agree. This is probably the best way to keep things in sync.

Nicolas Pitre made a comment saying he wants to look at these patches more, are there other pending comments?

Regards,

Tony

Nicolas Pitre made a comment saying he wants to look at these patches more, are there other pending comments?

Also, specifically to 12xx, I'd like to see REF_CLOCK moved on and have this set by platform too (I haven't found anything like that in the patches but maybe I've overlooked that).

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

Check out patch no. 9:

Quoted 2 lines · Ohad Ben-Cohen

Check out patch no. 9:

sorry for the confusion. However, I guess if the platform doesn't supply this value, we'll just consider it 0? Without any warning, right?

The problem is, we can't really distinguish between this field not set and value zero, and that means something is wrong with the design. The easiest way is probably changing the clock ids to start with 1.

Thanks,
? Vitaly