Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
On 07/06/2010 08:42 PM, ext Nicolas Pitre wrote: On Tue, 6 Jul 2010, Roger Quadros wrote: On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote: Hi Roger, On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadrosroger.quad...@nokia.com wrote: 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. 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. 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? 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. if we have sdio_claim_power() and sdio_release_power() in place then power control should depend on it. regards, -roger -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote:
Nicolas Pitre wrote:
On Tue, 6 Jul 2010, Roger Quadros wrote:
On 07/06/2010 03:53 PM, ext Ohad Ben-Cohen wrote:
Hi Roger,
On Tue, Jul 6, 2010 at 1:35 PM, Roger Quadrosroger.quad...@nokia.com
wrote:
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.
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.
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?
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.
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?
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
is the wl1271 supposed to be used only with omap_hsmmc? We need to have a
solution that works neatly irrespective of which host controller is being used.
regards,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 0/5] Add MMC erase and secure erase V4
Hi Add ability to do MMC erase and secure erase operations from userspace, using the BLKDISCARD ioctl and a newly created BLKSECDISCARD ioctl. This is version 4 of these patches. Changes from V3 - rebased on mmotm - added SD/MMC device attribute documentation to 'mmc: Add erase, secure erase, trim and secure trim operations' patch Changes from V2 - move the addition of BLKSECDISCARD to a separate patch and implement it using I/O requests - move the MMC support of secure discard to a separate patch and support the secure discard I/O request Changes from V1 - use discard I/O requests instead of implementing BLKDISCARD in mmc_block - do not validate erase size for MMC erases, instead round to erase size - rename MMC max_erase to pref_erase and expose it through sysfs as preferred_erase_size Adrian Hunter (5): mmc: Add erase, secure erase, trim and secure trim operations mmc_block: Add discard support omap_hsmmc: Add erase capability block: Add secure discard mmc_block: Add support for secure discard Documentation/00-INDEX |2 + Documentation/mmc/00-INDEX |4 + Documentation/mmc/mmc-dev-attrs.txt | 56 ++ block/blk-core.c|5 +- block/blk-lib.c |6 + block/compat_ioctl.c|1 + block/elevator.c|6 + block/ioctl.c | 15 +- drivers/mmc/card/block.c| 82 - drivers/mmc/card/queue.c| 19 ++- drivers/mmc/core/core.c | 346 +++ drivers/mmc/core/core.h |2 + drivers/mmc/core/mmc.c | 47 +- drivers/mmc/core/sd.c | 82 drivers/mmc/core/sd_ops.c | 48 + drivers/mmc/core/sd_ops.h |1 + drivers/mmc/host/omap_hsmmc.c | 13 +- include/linux/bio.h |2 + include/linux/blkdev.h |7 +- include/linux/fs.h |2 + include/linux/mmc/card.h| 19 ++ include/linux/mmc/core.h| 19 ++ include/linux/mmc/host.h|1 + include/linux/mmc/mmc.h | 26 ++- include/linux/mmc/sd.h |5 + kernel/trace/blktrace.c |8 + 26 files changed, 803 insertions(+), 21 deletions(-) create mode 100644 Documentation/mmc/00-INDEX create mode 100644 Documentation/mmc/mmc-dev-attrs.txt Regards Adrian -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 3/5] omap_hsmmc: Add erase capability
From db31a11109e7f0c89a7a9ca70ad03beff354aa8e Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Tue, 18 May 2010 17:33:13 +0300
Subject: [PATCH 3/5] omap_hsmmc: Add erase capability
Disable the data (busy) timeout for erases and set the
MMC_CAP_ERASE capability.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
drivers/mmc/host/omap_hsmmc.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a0c8515..868498d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -28,6 +28,7 @@
#include linux/clk.h
#include linux/mmc/host.h
#include linux/mmc/core.h
+#include linux/mmc/mmc.h
#include linux/io.h
#include linux/semaphore.h
#include linux/gpio.h
@@ -78,6 +79,7 @@
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define DTO_ENABLE (1 20)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
@@ -523,7 +525,8 @@ static void omap_hsmmc_stop_clock(struct omap_hsmmc_host
*host)
dev_dbg(mmc_dev(host-mmc), MMC Clock is not stoped\n);
}
-static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host)
+static void omap_hsmmc_enable_irq(struct omap_hsmmc_host *host,
+ struct mmc_command *cmd)
{
unsigned int irq_mask;
@@ -532,6 +535,10 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host)
else
irq_mask = INT_EN_MASK;
+ /* Disable timeout for erases */
+ if (cmd-opcode == MMC_ERASE)
+ irq_mask = ~DTO_ENABLE;
+
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
@@ -782,7 +789,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host *host,
struct mmc_command *cmd,
mmc_hostname(host-mmc), cmd-opcode, cmd-arg);
host-cmd = cmd;
- omap_hsmmc_enable_irq(host);
+ omap_hsmmc_enable_irq(host, cmd);
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
@@ -2094,7 +2101,7 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
mmc-max_seg_size = mmc-max_req_size;
mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
-MMC_CAP_WAIT_WHILE_BUSY;
+MMC_CAP_WAIT_WHILE_BUSY | MMC_CAP_ERASE;
switch (mmc_slot(host).wires) {
case 8:
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V4 1/5] mmc: Add erase, secure erase, trim and secure trim operations
From 7f01ad3c4be6ec09318176db12db66f353b526e0 Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Tue, 1 Jun 2010 13:20:22 +0300 Subject: [PATCH 1/5] mmc: Add erase, secure erase, trim and secure trim operations SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4 cards can support secure erase, trim and secure trim operations that are all variants of the basic erase command. SD/MMC device attributes erase_size and preferred_erase_size have been added. erase_size is the minimum size, in bytes, of an erase operation. For MMC, erase_size is the erase group size reported by the card. Note that erase_size does not apply to trim or secure trim operations where the minimum size is always one 512 byte sector. For SD, erase_size is 512 if the card is block-addressed, 0 otherwise. SD/MMC cards can erase an arbitrarily large area up to and including the whole card. When erasing a large area it may be desirable to do it in smaller chunks for three reasons: 1. A single erase command will make all other I/O on the card wait. This is not a problem if the whole card is being erased, but erasing one partition will make I/O for another partition on the same card wait for the duration of the erase - which could be a several minutes. 2. To be able to inform the user of erase progress. 3. The erase timeout becomes too large to be very useful. Because the erase timeout contains a margin which is multiplied by the size of the erase area, the value can end up being several minutes for large areas. erase_size is not the most efficient unit to erase (especially for SD where it is just one sector), hence preferred_erase_size provides a good chunk size for erasing large areas. For MMC, preferred_erase_size is the high-capacity erase size if a card specifies one, otherwise it is based on the capacity of the card. For SD, preferred_erase_size is the allocation unit size specified by the card. preferred_erase_size is in bytes. Signed-off-by: Adrian Hunter adrian.hun...@nokia.com --- Documentation/00-INDEX |2 + Documentation/mmc/00-INDEX |4 + Documentation/mmc/mmc-dev-attrs.txt | 56 ++ drivers/mmc/core/core.c | 346 +++ drivers/mmc/core/core.h |2 + drivers/mmc/core/mmc.c | 47 +- drivers/mmc/core/sd.c | 82 drivers/mmc/core/sd_ops.c | 48 + drivers/mmc/core/sd_ops.h |1 + include/linux/mmc/card.h| 19 ++ include/linux/mmc/core.h| 19 ++ include/linux/mmc/host.h|1 + include/linux/mmc/mmc.h | 26 ++- include/linux/mmc/sd.h |5 + 14 files changed, 650 insertions(+), 8 deletions(-) create mode 100644 Documentation/mmc/00-INDEX create mode 100644 Documentation/mmc/mmc-dev-attrs.txt diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX index dd10b51..7cfc696 100644 --- a/Documentation/00-INDEX +++ b/Documentation/00-INDEX @@ -232,6 +232,8 @@ memory.txt - info on typical Linux memory problems. mips/ - directory with info about Linux on MIPS architecture. +mmc/ + - directory with info about the MMC subsystem mono.txt - how to execute Mono-based .NET binaries with the help of BINFMT_MISC. mutex-design.txt diff --git a/Documentation/mmc/00-INDEX b/Documentation/mmc/00-INDEX new file mode 100644 index 000..fca586f --- /dev/null +++ b/Documentation/mmc/00-INDEX @@ -0,0 +1,4 @@ +00-INDEX +- this file +mmc-dev-attrs.txt +- info on SD and MMC device attributes diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt new file mode 100644 index 000..ff2bd68 --- /dev/null +++ b/Documentation/mmc/mmc-dev-attrs.txt @@ -0,0 +1,56 @@ +SD and MMC Device Attributes + + +All attributes are read-only. + + cid Card Identifaction Register + csd Card Specific Data Register + scr SD Card Configuration Register (SD only) + dateManufacturing Date (from CID Register) + fwrev Firmware/Product Revision (from CID Register) (SD and MMCv1 only) + hwrev Hardware/Product Revision (from CID Register) (SD and MMCv1 only) + manfid Manufacturer ID (from CID Register) + nameProduct Name (from CID Register) + oemid OEM/Application ID (from CID Register) + serial Product Serial Number (from CID Register) + erase_size Erase group size + preferred_erase_sizePreferred erase size + +Note on Erase Size and Preferred Erase Size: + + erase_size is the minimum size, in bytes, of an erase + operation. For MMC, erase_size is
[PATCH V4 4/5] block: Add secure discard
From 1cdd5b576bfafcd53857ed4d37830446e96e8206 Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Wed, 23 Jun 2010 15:41:38 +0300
Subject: [PATCH 4/5] block: Add secure discard
Secure discard is the same as discard except that all copies
of the discarded sectors (perhaps created by garbage collection)
must also be erased.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
block/blk-core.c|5 -
block/blk-lib.c |6 ++
block/compat_ioctl.c|1 +
block/elevator.c|6 ++
block/ioctl.c | 15 ++-
include/linux/bio.h |2 ++
include/linux/blkdev.h |7 ++-
include/linux/fs.h |2 ++
kernel/trace/blktrace.c |8
9 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index 3c37894..7931081 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -1513,7 +1513,10 @@ static inline void __generic_make_request(struct bio
*bio)
if (bio_check_eod(bio, nr_sectors))
goto end_io;
- if ((bio-bi_rw REQ_DISCARD) !blk_queue_discard(q)) {
+ if ((bio-bi_rw REQ_DISCARD)
+ (!blk_queue_discard(q) ||
+((bio-bi_rw REQ_SECURE)
+ !blk_queue_secdiscard(q {
err = -EOPNOTSUPP;
goto end_io;
}
diff --git a/block/blk-lib.c b/block/blk-lib.c
index e16185b..ba8c0f9 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -50,6 +50,12 @@ int blkdev_issue_discard(struct block_device *bdev, sector_t
sector,
if (!blk_queue_discard(q))
return -EOPNOTSUPP;
+ if (flags BLKDEV_IFL_SECURE) {
+ if (!blk_queue_secdiscard(q))
+ return -EOPNOTSUPP;
+ type |= DISCARD_SECURE;
+ }
+
while (nr_sects !ret) {
unsigned int max_discard_sectors =
min(q-limits.max_discard_sectors, UINT_MAX 9);
diff --git a/block/compat_ioctl.c b/block/compat_ioctl.c
index f26051f..24a146d 100644
--- a/block/compat_ioctl.c
+++ b/block/compat_ioctl.c
@@ -753,6 +753,7 @@ long compat_blkdev_ioctl(struct file *file, unsigned cmd,
unsigned long arg)
case BLKFLSBUF:
case BLKROSET:
case BLKDISCARD:
+ case BLKSECDISCARD:
/*
* the ones below are implemented in blkdev_locked_ioctl,
* but we call blkdev_ioctl, which gets the lock for us
diff --git a/block/elevator.c b/block/elevator.c
index 816a7c8..ec585c9 100644
--- a/block/elevator.c
+++ b/block/elevator.c
@@ -83,6 +83,12 @@ int elv_rq_merge_ok(struct request *rq, struct bio *bio)
return 0;
/*
+* Don't merge discard requests and secure discard requests
+*/
+ if ((bio-bi_rw REQ_SECURE) != (rq-bio-bi_rw REQ_SECURE))
+ return 0;
+
+ /*
* different data direction or already started, don't merge
*/
if (bio_data_dir(bio) != rq_data_dir(rq))
diff --git a/block/ioctl.c b/block/ioctl.c
index 6f3db6f..afcfe48 100644
--- a/block/ioctl.c
+++ b/block/ioctl.c
@@ -114,8 +114,10 @@ static int blkdev_reread_part(struct block_device *bdev)
}
static int blk_ioctl_discard(struct block_device *bdev, uint64_t start,
-uint64_t len)
+uint64_t len, int secure)
{
+ unsigned long flags = BLKDEV_IFL_WAIT;
+
if (start 511)
return -EINVAL;
if (len 511)
@@ -125,8 +127,9 @@ static int blk_ioctl_discard(struct block_device *bdev,
uint64_t start,
if (start + len (bdev-bd_inode-i_size 9))
return -EINVAL;
- return blkdev_issue_discard(bdev, start, len, GFP_KERNEL,
- BLKDEV_IFL_WAIT);
+ if (secure)
+ flags |= BLKDEV_IFL_SECURE;
+ return blkdev_issue_discard(bdev, start, len, GFP_KERNEL, flags);
}
static int put_ushort(unsigned long arg, unsigned short val)
@@ -226,7 +229,8 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode,
unsigned cmd,
unlock_kernel();
return 0;
- case BLKDISCARD: {
+ case BLKDISCARD:
+ case BLKSECDISCARD: {
uint64_t range[2];
if (!(mode FMODE_WRITE))
@@ -235,7 +239,8 @@ int blkdev_ioctl(struct block_device *bdev, fmode_t mode,
unsigned cmd,
if (copy_from_user(range, (void __user *)arg, sizeof(range)))
return -EFAULT;
- return blk_ioctl_discard(bdev, range[0], range[1]);
+ return blk_ioctl_discard(bdev, range[0], range[1],
+cmd == BLKSECDISCARD);
}
case HDIO_GETGEO: {
diff --git a/include/linux/bio.h b/include/linux/bio.h
index 4d379c8..147e631 100644
---
[PATCH 2/4] Smedia Glamo 3362 MMC/SD Card Interface driver
Signed-off-by: Thibaut Girka t...@sitedethib.com
---
drivers/mmc/host/Kconfig | 11 +
drivers/mmc/host/Makefile|1 +
drivers/mmc/host/glamo-mci.c | 985 ++
3 files changed, 997 insertions(+), 0 deletions(-)
create mode 100644 drivers/mmc/host/glamo-mci.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index f06d06e..b28bf7c 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -365,6 +365,17 @@ config MMC_S3C_PIODMA
endchoice
+config MMC_GLAMO
+ tristate Glamo S3C SD/MMC Card Interface support
+ depends on MFD_GLAMO MMC REGULATOR
+ select CRC7
+ help
+ This selects a driver for the MCI interface found in
+ the S-Media GLAMO chip, as used in Openmoko
+ neo1973 GTA-02.
+
+ If unsure, say N.
+
config MMC_SDRICOH_CS
tristate MMC/SD driver for Ricoh Bay1Controllers (EXPERIMENTAL)
depends on EXPERIMENTAL PCI PCMCIA
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index e30c2ee..9d03382 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -30,6 +30,7 @@ ifeq ($(CONFIG_OF),y)
obj-$(CONFIG_MMC_SPI) += of_mmc_spi.o
endif
obj-$(CONFIG_MMC_S3C) += s3cmci.o
+obj-$(CONFIG_MMC_GLAMO)+= glamo-mci.o
obj-$(CONFIG_MMC_SDRICOH_CS) += sdricoh_cs.o
obj-$(CONFIG_MMC_TMIO) += tmio_mmc.o
obj-$(CONFIG_MMC_CB710)+= cb710-mmc.o
diff --git a/drivers/mmc/host/glamo-mci.c b/drivers/mmc/host/glamo-mci.c
new file mode 100644
index 000..f07ad09
--- /dev/null
+++ b/drivers/mmc/host/glamo-mci.c
@@ -0,0 +1,985 @@
+/*
+ * linux/drivers/mmc/host/glamo-mmc.c - Glamo MMC driver
+ *
+ * Copyright (C) 2007 Openmoko, Inc, Andy Green a...@openmoko.com
+ * Copyright (C) 2009, Lars-Peter Clausen l...@metafoo.de
+ * Based on S3C MMC driver that was:
+ * Copyright (C) 2004-2006 maintech GmbH, Thomas Kleffel t...@maintech.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/module.h
+#include linux/mmc/mmc.h
+#include linux/mmc/sd.h
+#include linux/mmc/host.h
+#include linux/platform_device.h
+#include linux/irq.h
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/workqueue.h
+#include linux/crc7.h
+#include linux/scatterlist.h
+#include linux/io.h
+#include linux/regulator/consumer.h
+#include linux/err.h
+#include linux/mfd/glamo.h
+#include linux/mfd/glamo-core.h
+#include linux/mfd/glamo-regs.h
+
+struct glamo_mci_host {
+ struct glamo_mmc_platform_data *pdata;
+ struct platform_device *pdev;
+ struct glamo_core *core;
+ struct mmc_host *mmc;
+ struct resource *mmio_mem;
+ struct resource *data_mem;
+ void __iomem*mmio_base;
+ uint16_t __iomem*data_base;
+
+ unsigned int irq;
+
+ struct regulator *regulator;
+ struct mmc_request *mrq;
+
+ unsigned int clk_rate;
+
+ unsigned short vdd;
+ char power_mode;
+
+ unsigned char request_counter;
+
+ struct workqueue_struct *workqueue;
+ struct work_struct read_work;
+};
+
+static void glamo_mci_send_request(struct mmc_host *mmc,
+ struct mmc_request *mrq);
+static void glamo_mci_send_command(struct glamo_mci_host *host,
+ struct mmc_command *cmd);
+
+/*
+ * Max SD clock rate
+ *
+ * held at /(3 + 1) due to concerns of 100R recommended series resistor
+ * allows 16MHz @ 4-bit -- 8MBytes/sec raw
+ *
+ * you can override this on kernel commandline using
+ *
+ * glamo_mci.sd_max_clk=1000
+ *
+ * for example
+ */
+
+static int sd_max_clk = 2100;
+module_param(sd_max_clk, int, 0644);
+
+/*
+ * Slow SD clock rate
+ *
+ * you can override this on kernel commandline using
+ *
+ * glamo_mci.sd_slow_ratio=8
+ *
+ * for example
+ *
+ * platform callback is used to decide effective clock rate, if not
+ * defined then max is used, if defined and returns nonzero, rate is
+ * divided by this factor
+ */
+
+static int sd_slow_ratio = 8;
+module_param(sd_slow_ratio, int, 0644);
+
+/*
+ * Post-power SD clock rate
+ *
+ * you can override this on kernel commandline using
+ *
+ * glamo_mci.sd_post_power_clock=100
+ *
+ * for example
+ *
+ * After changing power to card, clock is held at this rate until first bulk
+ * transfer completes
+ */
+
+static int sd_post_power_clock = 100;
+module_param(sd_post_power_clock, int, 0644);
+
+
+static inline void glamomci_reg_write(struct glamo_mci_host *glamo,
+ uint16_t reg, uint16_t val)
+{
+ writew(val, glamo-mmio_base + reg);
+}
+
+static inline uint16_t glamomci_reg_read(struct glamo_mci_host *glamo,
+ uint16_t reg)
+{
+
Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 08:42 PM, ext Nicolas Pitre wrote: On Tue, 6 Jul 2010, Roger Quadros wrote: 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? 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. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] OMAP: Fix for bus width which improves SD card's peformance.
Tony,
Could this patch be taken ?
Thanks,
kishore
On Tue, Jun 15, 2010 at 1:37 PM, kishore kadiyala
kishorek.kadiy...@gmail.com wrote:
From: Kishore Kadiyala kishore.kadiy...@ti.com
This patch improves low speeds for SD cards.
OMAP-MMC controller's can support maximum bus width of '8'.
when bus width is mentioned as 8 in controller data,the SD
stack will check whether bus width is 4 and if not it will
set bus width to 1 and there by degrading performance.
This patch fixes the issue and improves the performance of
SD cards.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Tested-by: Jarkko Nikula jhnik...@gmail.com
---
In V5 : Rebasing on 2.6.35-rc3
In V4 : Updated with Nishanth's comments and appened his Signed-off
http://marc.info/?t=12716914936r=1w=2
In V3 : Updated with Madhu's comments and appended Tested by Nikula
In V2 : Appended Signed-off by Venkat and Ack by Madhu
Here are my experiment numbers, on a Class 6 SDHC card:
Read peformance is increased by 220%
Write Performance is increased by 52%
drivers/mmc/host/omap_hsmmc.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b032828..a0c8515 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2096,10 +2096,23 @@ static int __init omap_hsmmc_probe(struct
mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_WAIT_WHILE_BUSY;
- if (mmc_slot(host).wires = 8)
+ switch (mmc_slot(host).wires) {
+ case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
- else if (mmc_slot(host).wires = 4)
+ /* Fall through */
+ case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
+ break;
+ case 1:
+ /* Nothing to crib here */
+ case 0:
+ /* Assuming nothing was given by board, Core use's 1-Bit */
+ break;
+ default:
+ /* Completely unexpected.. Core goes with 1-Bit Width */
+ dev_crit(mmc_dev(host-mmc), Invalid width %d\n used!
+ using 1 instead\n, mmc_slot(host).wires);
+ }
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] mmc: Add erase, secure erase, trim and secure trim operations
On Wed, Jul 7, 2010 at 7:17 AM, Adrian Hunter adrian.hun...@nokia.com wrote:
From 7f01ad3c4be6ec09318176db12db66f353b526e0 Mon Sep 17 00:00:00 2001
SD/MMC cards tend to support an erase operation. In addition,
eMMC v4.4 cards can support secure erase, trim and secure trim
operations that are all variants of the basic erase command.
This is great. I am interested primarily in SD media.
Please forgive my naive perspective: it seems that with the features
enabled by this patchset and a filesystem that is capable of issuing
erase block commands, the wear-leveling on SD media will be improved
-- much like with CF TRIM commands. Do you also think that is the
case? I would be very interested in hearing your expert opinion on
this.
I have a couple comments regarding mostly the SD support introduced in
this patch. Patches 2..5 of 5 seem fine to me but I'm not sure I'm
qualified to add acks or reviewed-by's.
+int mmc_erase(struct mmc_card *card, unsigned int from, unsigned int nr,
+ unsigned int arg)
+{
+ unsigned int rem, to = from + nr;
+
+ if (!(card-host-caps MMC_CAP_ERASE) ||
+ !(card-csd.cmdclass CCC_ERASE))
+ return -EOPNOTSUPP;
+
+ if (!card-erase_size)
+ return -EOPNOTSUPP;
+
+ if (mmc_card_sd(card) arg != MMC_ERASE_ARG)
+ return -EOPNOTSUPP;
+
+ if ((arg MMC_SECURE_ARGS)
+ !(card-ext_csd.sec_feature_support EXT_CSD_SEC_ER_EN))
+ return -EOPNOTSUPP;
+
+ if ((arg MMC_TRIM_ARGS)
+ !(card-ext_csd.sec_feature_support EXT_CSD_SEC_GB_CL_EN))
+ return -EOPNOTSUPP;
+
+int mmc_can_trim(struct mmc_card *card)
+{
+ if (card-ext_csd.sec_feature_support EXT_CSD_SEC_GB_CL_EN)
+ return 1;
+ return 0;
+}
+EXPORT_SYMBOL(mmc_can_trim);
It looks like mmc_can_trim(card) would return true when
mmc_card_sd(card) is true; but the mmc_erase function will return
-EOPNOTSUPP in such a case. I think that this results in the
mmc_blk_issue_discard_rq function (from 2/5) also returning
-EOPNOTSUPP whenever mmc_card_sd(card) is true:
From 2/5:
+ if (mmc_can_trim(card))
+ arg = MMC_TRIM_ARG;
+ else
+ arg = MMC_ERASE_ARG;
+
+ err = mmc_erase(card, from, nr, arg);
Also, there is some duplication between the sec_feature_support
checking in mmc_erase and in the mmc_can* functions; If mmc_erase
could call the mmc_can_* functions then the the bit-checking logic
could be centralized.
/*
+ * Fetch and process SD Status register.
+ */
+static int mmc_read_ssr(struct mmc_card *card)
+{
It looks like the conventional function prefix for SD-specific
functions in the rest of this file is mmc_sd_ ; 'mmc_read_ssr' -
'mmc_sd_read_ssr' or - 'mmc_read_sd_sr' perhaps?
+ ssr = kmalloc(64, GFP_KERNEL);
Why '64' instead of 'sizeof(*ssr)' ?
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 11/15] wireless: wl1271: introduce platform device support
On Wed, 7 Jul 2010, Madhusudhan wrote: -Original Message- From: Nicolas Pitre [mailto:n...@fluxnic.net] Sent: Wednesday, July 07, 2010 9:03 AM To: Roger Quadros Cc: Hunter Adrian (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux- wirel...@vger.kernel.org; linux-mmc@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Coelho Luciano (Nokia-MS/Helsinki); a...@linux-foundation.org; San Mehat Subject: Re: [PATCH 11/15] wireless: wl1271: introduce platform device support On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote: 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. 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. It is not because you are twisting the layers and customizing the core stack around your own controller that it is good software design. And the presence of the mmc_power_restore_host() code doesn't mean it is sane. My point is that no one should ever use that, not even omap_hsmmc. Proof: it works so fine that now you must come up with yet another contorted hack piled on top called fake^H^H^H^Hsoftware insert/remove events to support power handling with SDIO cards. This MMC_CAP_DISABLE is ridiculous. Why would this have to be a host capability? This should be a core feature that should be _transparent_ to all hosts with no changes to any of the host drivers. When the core code knows that the card can be shut down after some idle period, it should do so with the *existing* API calls, namely the set_ios method. In the SDIO case it would be a simple matter of mapping the sdio_release_power() onto that. Instead, some contorted power management support was sneaked in, which is misdesigned to the point of breaking proper SDIO support for which more misdesigned features are now needed to work around the former ones. Now the OMAP driver is becoming a stack of its own, making decisions that clearly should be made at a higher level of abstraction. To me this denotes some laziness from the involved developers who didn't take the time to design something sensible and generic in the core code, but rather hacked a quick solution specific to omap_hmmc.c. Of course the former would require a greater understanding of common code and some additional effort to make the solution truly generic. Instead, the easy solution was taken which is to stuff magic behaviors in a host driver while other people are not paying as much attention to it than core code. Needless to say that I'm not impressed at all. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] mmc: Add erase, secure erase, trim and secure trim operations
Ben Gardiner wrote:
On Wed, Jul 7, 2010 at 7:17 AM, Adrian Hunter adrian.hun...@nokia.com wrote:
From 7f01ad3c4be6ec09318176db12db66f353b526e0 Mon Sep 17 00:00:00 2001
SD/MMC cards tend to support an erase operation. In addition,
eMMC v4.4 cards can support secure erase, trim and secure trim
operations that are all variants of the basic erase command.
This is great. I am interested primarily in SD media.
Please forgive my naive perspective: it seems that with the features
enabled by this patchset and a filesystem that is capable of issuing
erase block commands, the wear-leveling on SD media will be improved
-- much like with CF TRIM commands. Do you also think that is the
case? I would be very interested in hearing your expert opinion on
this.
I am sorry but I don't know. Wear-levelling in cards tends to be kept
secret by the manufacturers. However, it is not clear to me that cards
bother to record whether or not anything has been erased. For example,
erase a card twice - it takes the same amount of time the second time
as the first time, whereas if the card knew it was already erased, why
wasn't the second time much quicker?
I have a couple comments regarding mostly the SD support introduced in
this patch. Patches 2..5 of 5 seem fine to me but I'm not sure I'm
qualified to add acks or reviewed-by's.
+int mmc_erase(struct mmc_card *card, unsigned int from, unsigned int nr,
+ unsigned int arg)
+{
+ unsigned int rem, to = from + nr;
+
+ if (!(card-host-caps MMC_CAP_ERASE) ||
+ !(card-csd.cmdclass CCC_ERASE))
+ return -EOPNOTSUPP;
+
+ if (!card-erase_size)
+ return -EOPNOTSUPP;
+
+ if (mmc_card_sd(card) arg != MMC_ERASE_ARG)
+ return -EOPNOTSUPP;
+
+ if ((arg MMC_SECURE_ARGS)
+ !(card-ext_csd.sec_feature_support EXT_CSD_SEC_ER_EN))
+ return -EOPNOTSUPP;
+
+ if ((arg MMC_TRIM_ARGS)
+ !(card-ext_csd.sec_feature_support EXT_CSD_SEC_GB_CL_EN))
+ return -EOPNOTSUPP;
+
+int mmc_can_trim(struct mmc_card *card)
+{
+ if (card-ext_csd.sec_feature_support EXT_CSD_SEC_GB_CL_EN)
+ return 1;
+ return 0;
+}
+EXPORT_SYMBOL(mmc_can_trim);
It looks like mmc_can_trim(card) would return true when
mmc_card_sd(card) is true;
It will return false for SD. card-ext_csd.sec_feature_support
is only used by MMC.
but the mmc_erase function will return
-EOPNOTSUPP in such a case. I think that this results in the
mmc_blk_issue_discard_rq function (from 2/5) also returning
-EOPNOTSUPP whenever mmc_card_sd(card) is true:
From 2/5:
+ if (mmc_can_trim(card))
+ arg = MMC_TRIM_ARG;
+ else
+ arg = MMC_ERASE_ARG;
+
+ err = mmc_erase(card, from, nr, arg);
Also, there is some duplication between the sec_feature_support
checking in mmc_erase and in the mmc_can* functions; If mmc_erase
could call the mmc_can_* functions then the the bit-checking logic
could be centralized.
I can do that if there is a V5 but I do not think it is worth
rolling another set of patches just for that.
/*
+ * Fetch and process SD Status register.
+ */
+static int mmc_read_ssr(struct mmc_card *card)
+{
It looks like the conventional function prefix for SD-specific
functions in the rest of this file is mmc_sd_ ; 'mmc_read_ssr' -
'mmc_sd_read_ssr' or - 'mmc_read_sd_sr' perhaps?
Well there is also mmc_decode_*, and mmc_read_switch so the other
functions that do smilar things also do not follow that convention.
+ ssr = kmalloc(64, GFP_KERNEL);
Why '64' instead of 'sizeof(*ssr)' ?
sizeof(*ssr) is 4
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
Nicolas Pitre wrote: On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote: 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. The power control decision does come from the top via mmc_claim_host / mmc_release_host. 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. 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. Nicolas -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 01/12] mmci: use sg_miter API to fix multi-page sg handling
I've tested this MMCI patch set on RealView PB1176 and U300, mounted cards, copied files back and forth, unmount diff files. No problems. This should cover all MMCI variants, since the PB1176 is a vanilla ARM variant. Just fix the comments on patch #7 and it should be ripe for the patch tracker methinks. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 1/5] mmc: Add erase, secure erase, trim and secure trim operations
On Wed, Jul 7, 2010 at 3:05 PM, Adrian Hunter adrian.hun...@nokia.com wrote:
Ben Gardiner wrote:
On Wed, Jul 7, 2010 at 7:17 AM, Adrian Hunter adrian.hun...@nokia.com
wrote:
From 7f01ad3c4be6ec09318176db12db66f353b526e0 Mon Sep 17 00:00:00 2001
SD/MMC cards tend to support an erase operation. In addition,
eMMC v4.4 cards can support secure erase, trim and secure trim
operations that are all variants of the basic erase command.
This is great. I am interested primarily in SD media.
Please forgive my naive perspective: it seems that with the features
enabled by this patchset and a filesystem that is capable of issuing
erase block commands, the wear-leveling on SD media will be improved
-- much like with CF TRIM commands. Do you also think that is the
case? I would be very interested in hearing your expert opinion on
this.
I am sorry but I don't know. Wear-levelling in cards tends to be kept
secret by the manufacturers. However, it is not clear to me that cards
bother to record whether or not anything has been erased. For example,
erase a card twice - it takes the same amount of time the second time
as the first time, whereas if the card knew it was already erased, why
wasn't the second time much quicker?
No worries. I'm happy to hear your opinion anyways.
Interesting observation re: erase time of cards, I assume that is
erase as in the SD erase operations as proposed in this patch as
opposed to erase as in 'mkfs'.
I have a couple comments regarding mostly the SD support introduced in
this patch. Patches 2..5 of 5 seem fine to me but I'm not sure I'm
qualified to add acks or reviewed-by's.
+int mmc_erase(struct mmc_card *card, unsigned int from, unsigned int nr,
+ unsigned int arg)
+{
+ unsigned int rem, to = from + nr;
+
+ if (!(card-host-caps MMC_CAP_ERASE) ||
+ !(card-csd.cmdclass CCC_ERASE))
+ return -EOPNOTSUPP;
+
+ if (!card-erase_size)
+ return -EOPNOTSUPP;
+
+ if (mmc_card_sd(card) arg != MMC_ERASE_ARG)
+ return -EOPNOTSUPP;
+
+ if ((arg MMC_SECURE_ARGS)
+ !(card-ext_csd.sec_feature_support EXT_CSD_SEC_ER_EN))
+ return -EOPNOTSUPP;
+
+ if ((arg MMC_TRIM_ARGS)
+ !(card-ext_csd.sec_feature_support EXT_CSD_SEC_GB_CL_EN))
+ return -EOPNOTSUPP;
+
+int mmc_can_trim(struct mmc_card *card)
+{
+ if (card-ext_csd.sec_feature_support EXT_CSD_SEC_GB_CL_EN)
+ return 1;
+ return 0;
+}
+EXPORT_SYMBOL(mmc_can_trim);
It looks like mmc_can_trim(card) would return true when
mmc_card_sd(card) is true;
It will return false for SD. card-ext_csd.sec_feature_support
is only used by MMC.
Makes sense now, thanks.
/*
+ * Fetch and process SD Status register.
+ */
+static int mmc_read_ssr(struct mmc_card *card)
+{
It looks like the conventional function prefix for SD-specific
functions in the rest of this file is mmc_sd_ ; 'mmc_read_ssr' -
'mmc_sd_read_ssr' or - 'mmc_read_sd_sr' perhaps?
Well there is also mmc_decode_*, and mmc_read_switch so the other
functions that do smilar things also do not follow that convention.
Good point.
+ ssr = kmalloc(64, GFP_KERNEL);
Why '64' instead of 'sizeof(*ssr)' ?
sizeof(*ssr) is 4
Right -- my mistake :)
I guess I was _thinking_ 16*sizeof(*ssr) or SSR_SIZE*sizeof(*ssr)
instead of a magic number '64'. I see now that this wouldn't be the
only kmalloc of a magic number in sd.c -- so I'll stop being so picky.
Reviewed-by: Ben Gardiner bengardi...@nanometrics.ca
---
Ben Gardiner
Nanometrics Inc.
http://www.nanometrics.ca
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+ mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-fix.patch added to -mm tree
The patch titled
mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-fix
has been added to the -mm tree. Its filename is
mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-fix.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
--
Subject:
mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-fix
From: Andrew Morton a...@linux-foundation.org
fix CONFIG_PM-n linkage, small cleanups
Cc: linux-mmc@vger.kernel.org
Cc: Alan Stern st...@rowland.harvard.edu
Cc: David Brownell davi...@pacbell.net
Cc: Maxim Levitsky maximlevit...@gmail.com
Reported-by: Randy Dunlap randy.dun...@oracle.com
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/mmc/core/core.c |7 +++
include/linux/mmc/host.h |4
2 files changed, 7 insertions(+), 4 deletions(-)
diff -puN
drivers/mmc/core/core.c~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-fix
drivers/mmc/core/core.c
---
a/drivers/mmc/core/core.c~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-fix
+++ a/drivers/mmc/core/core.c
@@ -1316,11 +1316,12 @@ int mmc_resume_host(struct mmc_host *hos
return err;
}
+EXPORT_SYMBOL(mmc_resume_host);
/* Do the card removal on suspend if card is assumed removeable
* Do that in pm notifier while userspace isn't yet frozen, so we will be able
- to sync the card.
-*/
+ * to sync the card.
+ */
int mmc_pm_notify(struct notifier_block *notify_block,
unsigned long mode, void *unused)
{
@@ -1348,8 +1349,6 @@ int mmc_pm_notify(struct notifier_block
return 0;
}
-EXPORT_SYMBOL(mmc_resume_host);
-
#endif
static int __init mmc_init(void)
diff -puN
include/linux/mmc/host.h~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-fix
include/linux/mmc/host.h
---
a/include/linux/mmc/host.h~mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume-fix
+++ a/include/linux/mmc/host.h
@@ -258,8 +258,12 @@ int mmc_card_can_sleep(struct mmc_host *
int mmc_host_enable(struct mmc_host *host);
int mmc_host_disable(struct mmc_host *host);
int mmc_host_lazy_disable(struct mmc_host *host);
+#ifdef CONFIG_PM
int mmc_pm_notify(struct notifier_block *notify_block, unsigned long mode,
void *unused);
+#else
+#define mmc_pm_notify NULL
+#endif
static inline void mmc_set_disable_delay(struct mmc_host *host,
unsigned int disable_delay)
_
Patches currently in -mm which might be from a...@linux-foundation.org are
origin.patch
ipc-semc-bugfix-for-semop-not-reporting-successful-operation.patch
mm-vmap-area-cache-fix.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
revert-ed5aa19b93da2c094b6647762774a8022e4e1d6c.patch
revert-9652e31db6d841e291531547b3f4f12b5aeb42a9.patch
revert-fdc8302019d9bc10729cd3e8d348571e833388aa.patch
revert-324d76561842e551051e2a897b958b0539f6867b.patch
revert-e92e80797e7eaaf2a9bbd586c63f7c6bd3177276.patch
revert-d04ab5241f301bdcad2f6beb0ecd326bd82100a7.patch
revert-3ab7269a6058c136795ce9417f7051a0edde60db.patch
revert-4624469822455b4accc886557f6c997ccdd59066.patch
include-linux-fsh-complete-hexification-of-fmode_-constants.patch
acpi-fix-bogus-preemption-logic-fix.patch
intel_menlow-fix-memory-leaks-in-error-path-fix.patch
x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent-fix.patch
compal-laptop-added-jhl90-battery-hwmon-interface.patch
gcc-46-btrfs-clean-up-unused-variables-bugs-fix.patch
dib3000mc-reduce-large-stack-usage-fix.patch
hpet-factor-timer-allocate-from-open.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
arch-um-drivers-remove-duplicate-structure-field-initialization.patch
3x59x-fix-pci-resource-management.patch
altera_uart-simplify-altera_uart_console_putc-checkpatch-fixes.patch
serial-mcf-dont-take-spinlocks-in-already-protected-functions-fix.patch
sched-make-sched_param-argument-static-variables-in-some-sched_setscheduler-caller.patch
scsi-remove-private-bit-macros.patch
vfs-use-kmalloc-to-allocate-fdmem-if-possible.patch
mm.patch
mm-track-the-root-oldest-anon_vma-fix.patch
oom-improve-commentary-in-dump_tasks.patch
oom-sacrifice-child-with-highest-badness-score-for-parent-protect-dereferencing-of-tasks-comm.patch
oom-select-task-from-tasklist-for-mempolicy-ooms-add-has_intersects_mems_allowed-uma-variant.patch
RE: [PATCH 06/15] omap zoom2: wlan board muxing
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-mmc@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 06/15] omap zoom2: wlan board muxing
From: Ohad Ben-Cohen oh...@ti.com
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 oh...@ti.com
---
arch/arm/mach-omap2/board-zoom2.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom2.c b/arch/arm/mach-
omap2/board-zoom2.c
index 803ef14..00871be 100644
--- a/arch/arm/mach-omap2/board-zoom2.c
+++ b/arch/arm/mach-omap2/board-zoom2.c
@@ -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?
+ /* 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 04/15] mmc: support embedded data field in mmc_host
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-mmc@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 04/15] mmc: support embedded data field in mmc_host
From: Ohad Ben-Cohen oh...@ti.com
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 oh...@ti.com
---
drivers/mmc/core/Kconfig |8
include/linux/mmc/host.h | 16
2 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/Kconfig b/drivers/mmc/core/Kconfig
index bb22ffd..ab27eb3 100644
--- a/drivers/mmc/core/Kconfig
+++ b/drivers/mmc/core/Kconfig
@@ -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.
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index f65913c..9a48486 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -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)
+{
+ return host-embedded_data;
+}
+
+static inline void mmc_set_embedded_data(struct mmc_host *host, void
*data)
+{
+ host-embedded_data = data;
+}
+#endif
+
[Ghorai] we can avoid CONFIG_MMC_EMBEDDED_SDIO flag itself. Why we are passing
fixed data? We can enquire form card for the functions, features,.. and at
runtime itself. And we are adding many compile-time/kconfig options in this
patch series.
#endif
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 00/15] wlan+omap+mmc: out-of-the-box WLAN support for ZOOM2/3
-Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen Sent: Tuesday, July 06, 2010 6:08 AM To: linux-wirel...@vger.kernel.org; linux-mmc@vger.kernel.org; linux- o...@vger.kernel.org Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@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 oh...@ti.com 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 s...@google.com (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 [Ghorai] This patch series having the CONFIG_MMC_EMBEDDED_SDIO as kconfig option and I feel we should void this. This could be a generic and can be get from sdio card at runtime. Quite long codes are adding in this patch series under this flag. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to
RE: [PATCH 15/15] omap: zoom: enable WLAN device
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-mmc@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 15/15] omap: zoom: enable WLAN device
From: Ohad Ben-Cohen oh...@ti.com
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 oh...@ti.com
---
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(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index b31b6f1..7fee11b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -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
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index ea52b03..ac1bad9 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -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 \
hsmmc.o
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c b/arch/arm/mach-
omap2/board-zoom-peripherals.c
index 6b39849..3128cd4 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -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 */
};
@@ -282,4 +296,5 @@ void __init zoom_peripherals_init(void)
omap_i2c_init();
usb_musb_init(musb_board_data);
enable_board_wakeup_source();
+ omap_zoom_wlan_init();
}
[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.
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 14/15] omap: zoom: add WLAN device
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Ohad Ben-Cohen
Sent: Tuesday, July 06, 2010 6:08 AM
To: linux-wirel...@vger.kernel.org; linux-mmc@vger.kernel.org; linux-
o...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk;
Chikkature Rajashekar, Madhusudhan; Luciano Coelho; a...@linux-
foundation.org; San Mehat; Ben-cohen, Ohad
Subject: [PATCH 14/15] omap: zoom: add WLAN device
From: Ohad Ben-Cohen oh...@ti.com
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 s...@android.com.
Signed-off-by: Ohad Ben-Cohen oh...@ti.com
---
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
diff --git a/arch/arm/mach-omap2/board-zoom-wlan.c b/arch/arm/mach-
omap2/board-zoom-wlan.c
new file mode 100644
index 000..7ed5139
--- /dev/null
+++ b/arch/arm/mach-omap2/board-zoom-wlan.c
@@ -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
[Ghorai] Again the file itself is zoom specific, why we need the additional
flag?
+
+/* 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
Re: [PATCH 11/15] wireless: wl1271: introduce platform device support
On Wed, 7 Jul 2010, Adrian Hunter wrote: Nicolas Pitre wrote: On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote: 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. The power control decision does come from the top via mmc_claim_host / mmc_release_host. NO!!! THIS IS NOT ABOUT POWER! To the risk of repeating myself, mmc_claim_host and mmc_release_host are about getting exclusive access to the host controller. This should not have any relationship with power. If anything, you might infer some idleness of the host through that, but only to save power at the host controller level, but not at the card level. 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. What is this call to mmc_power_save_host() and mmc_power_restore_host() then? 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's not how I see things implemented right now. That is sensible because not even the upper layers know when the next activity will be. I don't agree with you. The upper layer, even if it cannot predict exactly when the next activity will occur, still has a hell of a better visibility on what is going on. In the context of an MMC/SD card, the upper layer knows about the block subsystem and it can look for dirty blocks that might be flushed in a near future. In the context of a SDIO card, it is the SDIO function driver that knows when it is important to preserve power to the card and when it is not. All the host controller driver must do is to simply and dumbly process requests from the core MMC code, including power control requests. 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. And apparently this cannot be implemented sanely on OMAP without faking a card removal. 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. You could implement the first one based on some idle period. The core code probably doesn't need to know as this should be transparent to the upper layer. But the other two definitely should be handled by the core code. There are numerous entry points to the driver. Checking whether to restore registers at every entry point is error prone and messy. Please give me something else than this lame excuse. There is effectively only _one_ main entry point, namely the request method of the mmc_host_ops structure. You might need to poke at the hardware when the set_ios or the enable_sdio_irq methods are called, and if the controller is latent then you'd only have to update the register cache. This is certainly not what I would call numerous. Instead we require that the core tells the driver when to enable and disable. No you don't. You are abusing the mmc_claim_host interface with power management issues. Those power issues are then guessed in the host controller driver, and then it eventually calls back into the core to tell the upper layer to shut off. What I'm telling you is that: 1) If you want to save power after some idle period you don't need host-ops-enable and host-ops-disable at all. Simply keep a timer alive in your host driver and reset it when a new request comes in. The code for mmc_host_enable() looks rather redundant, and fishy to me with its flag to prevent recursion, so this all could be removed. 2) Putting the card to sleep and/or removing power to it must be completely managed by the core code and certainly not from the host controller driver. The fact that mmc_power_save_host() is currently called from a host
