Re: [PATCH] mmc: boot partition ro lock support
Hi Ulf, Johan, - Original Message - From: Ulf Hansson ulf.hans...@stericsson.com To: linux-mmc@vger.kernel.org, Chris Ball c...@laptop.org Cc: Per Forlin per.for...@stericsson.com, Ulf Hansson ulf.hans...@stericsson.com, Lee Jones lee.jo...@linaro.org, Johan Rudholm johan.rudh...@stericsson.com, John Beckett john.beck...@stericsson.com Sent: Friday, October 21, 2011 9:17:23 AM Subject: [PATCH] mmc: boot partition ro lock support From: Johan Rudholm johan.rudh...@stericsson.com Enable boot partitions to be power and permanently read-only locked via a sysfs entry. There will be one sysfs entry for the main mmc device: /sys/block/mmcblkX/boot_partition_ro_lock and one for each boot partition: /sys/block/mmcblkXbootY/ro_lock The boot partitions are power or permanently locked by writing pwr_ro or perm_ro to one of the files. Signed-off-by: Ulf Hansson ulf.hans...@stericsson.com Signed-off-by: John Beckett john.beck...@stericsson.com Signed-off-by: Johan Rudholm johan.rudh...@stericsson.com --- What does power locking do that force_ro currently doesn't achieve? The permalocking brick-potential (more like paper-weight-potential) is IMO unacceptably high that something like this is just accessible via a sysfs attribute. This is exactly why the boot partitions were put under force_ro, so that some poor sap wouldn't end up nuking the boot partitions (with obvious consequences), and permalocking seems even nastier. At a bigger picture, I'm uncertain what the point of this is. It adds code complexity for, a generally rare and possibly self-destructive operation. This is like the GP partitioning support - it's a once-a-time (and unrecoverable) operation usually done at manufacturing (or initial provisioning time) that shouldn't be even exposed to the general purpose user. This would be a good use of that arbitrary-CMD ioctl interface John Calixto put in. Thanks, A -- 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: A question on IOCTL interface for MMC
Hi, - Original Message - From: Shashidhar Hiremath shashidh...@vayavyalabs.com To: Chris Ball c...@laptop.org, J Freyensee james_p_freyen...@linux.intel.com, John Calixto john.cali...@modsystems.com, linux-mmc@vger.kernel.org Sent: Thursday, October 20, 2011 1:09:00 AM Subject: A question on IOCTL interface for MMC Hi , I am planning to use the existing IOCTL interface for SD/MMC present in the kernel. Since, the IOCTL interface expects a read/write flag and the MMC IOCTL is actually an interface to block layer I feel without modifying the block layer for the support of non-read write commands ,I may not be able to test the non-read/write commands through the IOCTL interface . Unsure what you mean. Certainly it's up to you how to handle the data you pass to the ioctl(). The in and out just says whether you are passing data to the kernel or expecting something back, no more - no less. What are you actually trying to do? What are you trying to expose or control through an ioctl? A -- 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: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
Hi Randy, - Original Message - From: Randy Dunlap rdun...@xenotime.net To: Stephen Rothwell s...@canb.auug.org.au Cc: linux-n...@vger.kernel.org, LKML linux-ker...@vger.kernel.org, linux-mmc@vger.kernel.org, Chris Ball c...@laptop.org Sent: Tuesday, October 11, 2011 2:49:39 PM Subject: Re: linux-next: Tree for Oct 11 (mmc) On 10/11/11 02:11, Stephen Rothwell wrote: Hi all, The linux-next tree is now available from git://github.com/sfrothwell/linux-next.git as a temporary measure while the kernel.org servers are unavailable. It may also turn up on git.kernel.org (depending on the mirroring). The patch set is still absent, however. Changes since 20111007: When CONFIG_BLOCK is not enabled: In file included from next-2011-1011/drivers/mmc/card/sdio_uart.c:43:0: next-2011-1011/include/linux/mmc/card.h:175:12: error: 'DISK_NAME_LEN' undeclared here (not in a function) Deleting the #include linux/mmc/card.h fixes the sdio_uart.c build. However, the same problem occurs in mmc/core/core.c: Because linux/genhd is now included, oops. I'm pretty positive this is due to the mmc : general purpose partition support patch pulled recently. I am adding NamJae, who was the author. In file included from next-2011-1011/drivers/mmc/core/core.c:30:0: next-2011-1011/include/linux/mmc/card.h:175:12: error: 'DISK_NAME_LEN' undeclared here (not in a function) Should mmc/core/ depend on BLOCK? or should it just be made to build even when BLOCK is not enabled? I don't think there should be a direct dependency on BLOCK. I have two suggestions - 1) Have our own define similar to (and in fact smaller): linux/genhd.h:#define DISK_NAME_LEN 32 2) Put the MMC physical partition code under an #ifdef CONFIG_BLOCK, which is a reasonable proposition, given that there wouldn't be any need to parse physical partition info if it would never be consumed by the MMC block driver. Thoughts? A -- 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: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
- Original Message - From: NamJae Jeon linkinj...@gmail.com To: Randy Dunlap rdun...@xenotime.net, Andrei Warkentin awarken...@vmware.com Cc: linux-n...@vger.kernel.org, LKML linux-ker...@vger.kernel.org, linux-mmc@vger.kernel.org, Chris Ball c...@laptop.org, Stephen Rothwell s...@canb.auug.org.au Sent: Tuesday, October 11, 2011 7:20:48 PM Subject: Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc)) Hi Randy, Andrei. I suggest third option for this. As you know, MMC like ATA Driver and SCSI Driver etc.. can not enable without CONFIG_BLOCK So I think that mmc should be depended from CONFIG_BLOCK like other block device driver. see the their Kconfig. How do you think ? MMC core doesn't not imply MMC_BLOCK. You could well use SDIO devices via MMC without any flash storage whatsoever. What I want to say is that MMC_BLOCK already depends on BLOCK. MMC, however, has no such functional dependence, as it just (effectively) provides bus and device enumeration. So I think the better solution is wrapping all MMC partition code within mmc/core/mmc.c and card.h with CONFIG_BLOCK. A -- 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: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc))
Hi, - Original Message - From: NamJae Jeon linkinj...@gmail.com To: Andrei Warkentin awarken...@vmware.com Cc: linux-n...@vger.kernel.org, LKML linux-ker...@vger.kernel.org, linux-mmc@vger.kernel.org, Chris Ball c...@laptop.org, Stephen Rothwell s...@canb.auug.org.au, Randy Dunlap rdun...@xenotime.net Sent: Tuesday, October 11, 2011 8:16:51 PM Subject: Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc)) 2011/10/12 Andrei Warkentin awarken...@vmware.com: - Original Message - From: NamJae Jeon linkinj...@gmail.com To: Randy Dunlap rdun...@xenotime.net, Andrei Warkentin awarken...@vmware.com Cc: linux-n...@vger.kernel.org, LKML linux-ker...@vger.kernel.org, linux-mmc@vger.kernel.org, Chris Ball c...@laptop.org, Stephen Rothwell s...@canb.auug.org.au Sent: Tuesday, October 11, 2011 7:20:48 PM Subject: Re: mmc core broken dependency on CONFIG_BLOCK (Was: linux-next: Tree for Oct 11 (mmc)) Hi Randy, Andrei. I suggest third option for this. As you know, MMC like ATA Driver and SCSI Driver etc.. can not enable without CONFIG_BLOCK So I think that mmc should be depended from CONFIG_BLOCK like other block device driver. see the their Kconfig. How do you think ? MMC core doesn't not imply MMC_BLOCK. You could well use SDIO devices via MMC without any flash storage whatsoever. What I want to say is that MMC_BLOCK already depends on BLOCK. MMC, however, has no such functional dependence, as it just (effectively) provides bus and device enumeration. So I think the better solution is wrapping all MMC partition code within mmc/core/mmc.c and card.h with CONFIG_BLOCK. yes, you're right, I found it after sending mail. If so, should I wrap CONFIG_MMC_BLOCK instead of CONFIG_MMC ? After I add CONFIG_MMC_BLOCK in core/mmc.c, card.h, I can see compile is okay. Thanks. I am not sure if it should be CONFIG_MMC_BLOCK or CONFIG_BLOCK. After all, the code you're wrapping doesn't really depend on CONFIG_MMC_BLOCK, it gets consumed by it, and it depends (in using that one define) only on CONFIG_BLOCK. Maybe I'm overthinking it and the code should just define it's own MAX_MMC_PART_NAME to be like 10 or something. A -- 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 2/5] drivercore: Add driver probe deferral mechanism
Hi, - Original Message - From: Greg KH g...@kroah.com To: Josh Triplett j...@joshtriplett.org Cc: G, Manjunath Kondaiah manj...@ti.com, linux-arm-ker...@lists.infradead.org, Grant Likely grant.lik...@secretlab.ca, linux-o...@vger.kernel.org, linux-mmc@vger.kernel.org, linux-ker...@vger.kernel.org, Dilan Lee di...@nvidia.com, Mark Brown broo...@opensource.wolfsonmicro.com, manjun...@jasper.es Sent: Saturday, October 8, 2011 11:55:02 AM Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism I'm a bit of a fly on the wall here, but I'm curious how this impacts suspend/resume. device_initialize-device_pm_init are called from device_register, so certainly this patch doesn't also ensure that the PM ordering matches probe ordering, which is bound to break suspend, right? Was this ever tested with the OMAP target? Shouldn't the PM change be also part of this patch set? I don't see why you would want to have this in without the PM changes. Maybe I have it all wrong though :-). A -- 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 v12] mmc : general purpose partition support.
- Original Message - From: Namjae Jeon linkinj...@gmail.com To: c...@laptop.org, linux-mmc@vger.kernel.org Cc: linux-ker...@vger.kernel.org, awarken...@vmware.com, adrian hunter adrian.hun...@intel.com, linus walleij linus.wall...@linaro.org, james p freyensee james_p_freyen...@linux.intel.com, seb...@gmail.com, Ulf Hansson ulf.hans...@stericsson.com, stefan xk nilsson stefan.xk.nils...@stericsson.com, per forlin per.for...@stericsson.com, johan rudholm johan.rudh...@stericsson.com, Namjae Jeon linkinj...@gmail.com Sent: Thursday, October 6, 2011 10:41:38 AM Subject: [PATCH v12] mmc : general purpose partition support. It allows gerneral purpose partitions in MMC Device. And I try to simpliy make mmc_blk_alloc_parts using mmc_part structure suggested by Andrei Warkentin. After patching, we can see general purpose partitions like this. cat /proc/partitions 179 0 847872 mmcblk0 179 192 4096 mmcblk0gp3 179 160 4096 mmcblk0gp2 179 128 4096 mmcblk0gp1 179 96 1052672 mmcblk0gp0 179 64 1024 mmcblk0boot1 179 32 1024 mmcblk0boot0 Signed-off-by: Namjae Jeon linkinj...@gmail.com --- Acked-by: Andrei Warkentin andrey.warken...@gmail.com A -- 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 v11] mmc : general purpose partition support.
Hi,
- Original Message -
From: Namjae Jeon linkinj...@gmail.com
To: c...@laptop.org, linux-mmc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org, awarken...@vmware.com, adrian hunter
adrian.hun...@intel.com, linus walleij
linus.wall...@linaro.org, james p freyensee
james_p_freyen...@linux.intel.com, seb...@gmail.com, Ulf Hansson
ulf.hans...@stericsson.com, stefan xk nilsson
stefan.xk.nils...@stericsson.com, per forlin
per.for...@stericsson.com, johan rudholm johan.rudh...@stericsson.com,
Namjae Jeon linkinj...@gmail.com
Sent: Wednesday, October 5, 2011 10:45:45 AM
Subject: [PATCH v11] mmc : general purpose partition support.
It allows gerneral purpose partitions in MMC Device.
And I try to simpliy make mmc_blk_alloc_parts using mmc_part
structure suggested by Andrei Warkentin.
After patching, we can see general purpose partitions like this.
cat /proc/partitions
179 0 847872 mmcblk0
179 192 4096 mmcblk0gp3
179 160 4096 mmcblk0gp2
179 128 4096 mmcblk0gp1
179 96 1052672 mmcblk0gp0
179 64 1024 mmcblk0boot1
179 32 1024 mmcblk0boot0
Signed-off-by: Namjae Jeon linkinj...@gmail.com
---
drivers/mmc/card/block.c | 41 +++
drivers/mmc/core/mmc.c | 52
++---
include/linux/mmc/card.h | 34 +-
include/linux/mmc/mmc.h |5 +++-
4 files changed, 112 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
+ for (idx = 0; idx card-nr_parts; idx++) {
+ if (mmc_is_boot_partition(card-part[idx])
+ !mmc_boot_partition_access(card-host))
+ continue;
+ if (card-part[idx].size) {
+ ret = mmc_blk_alloc_part(card, md,
+ card-part[idx].part_cfg,
+ card-part[idx].size 9,
+ card-part[idx].force_ro,
+ card-part[idx].name);
+ if (ret)
+ return ret;
+ }
}
Is there any reason for putting the mmc_boot_partition_access() logic here? If
boot partitions are not allowed by host, then just don't add the mmc_parts to
the parts array, no? Such minutae should belong in core mmc code, not block
driver, IMHO.
A
--
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 v10] mmc : general purpose partition support.
Hi, - Original Message - From: Namjae Jeon linkinj...@gmail.com To: c...@laptop.org, linux-mmc@vger.kernel.org Cc: linux-ker...@vger.kernel.org, awarken...@vmware.com, adrian hunter adrian.hun...@intel.com, linus walleij linus.wall...@linaro.org, james p freyensee james_p_freyen...@linux.intel.com, seb...@gmail.com, Ulf Hansson ulf.hans...@stericsson.com, stefan xk nilsson stefan.xk.nils...@stericsson.com, per forlin per.for...@stericsson.com, johan rudholm johan.rudh...@stericsson.com, Namjae Jeon linkinj...@gmail.com Sent: Tuesday, October 4, 2011 1:45:17 PM Subject: [PATCH v10] mmc : general purpose partition support. It allows gerneral purpose partitions in MMC Device. And I try to simpliy make mmc_blk_alloc_parts using mmc_part structure suggested by Andrei Warkentin. After patching, we can see general purpose partitions like this. cat /proc/partitions 179 0 847872 mmcblk0 179 192 4096 mmcblk0gp3 179 160 4096 mmcblk0gp2 179 128 4096 mmcblk0gp1 179 96 1052672 mmcblk0gp0 179 64 1024 mmcblk0boot1 179 32 1024 mmcblk0boot0 Signed-off-by: Namjae Jeon linkinj...@gmail.com --- Acked-by: Andrei Warkentin andrey.warken...@gmail.com A -- 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: slow eMMC write speed
Hi James, - Original Message - From: J Freyensee james_p_freyen...@linux.intel.com Yeah, I know I'd be doing myself a huge favor by working off of mmc-next (or close to it), but product-wise, my department doesn't care for sustaining current platforms...yet (still trying to convince). I'd suggest working on linux-mmc. You can always back-port. So I was looking into sticking a write cache into block.c driver as a parameter, so it can be turned on and off upon driver load. Any write operation goes to the cache and only on a cache collision will the write operation get sent to the host controller for a write. What I have working so far is just with an MMC card in an MMC slot of a laptop, and just bare-bones. No general flush routine, error-handling, etc. From a couple performance measurements I did on the MMC slot using blktrace/blkparse and 400MB write transactions, I was seeing huge performance boost with no data corruption. So it is not looking like a total hair-brained idea. But I am still pretty far from understanding everything here. And the real payoff we want to see is performance a user can see on a handheld (i.e., Android) systems. Interesting. Thanks for sharing. I don't want to seem silly, but how is what you're doing different from the page cache? The page cache certainly defers write back (and I believe this is tunable...I'm not too familiar yet or comfortable around the rest of blk I/O and VM). What are your test workloads? I would guess this wouldn't have too great of an impact on a non O_DIRECT access, and O_DIRECT access anyway have to bypass any caching logic. A -- 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 v3] mmc : general purpose partition support.
Namjae,
- Original Message -
From: Namjae Jeon linkinj...@gmail.com
To: c...@laptop.org, linux-mmc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org, awarken...@vmware.com, adrian hunter
adrian.hun...@intel.com, linus walleij
linus.wall...@linaro.org, james p freyensee
james_p_freyen...@linux.intel.com, seb...@gmail.com, Ulf Hansson
ulf.hans...@stericsson.com, stefan xk nilsson
stefan.xk.nils...@stericsson.com, per forlin
per.for...@stericsson.com, johan rudholm johan.rudh...@stericsson.com,
Namjae Jeon linkinj...@gmail.com
Sent: Thursday, September 29, 2011 11:17:11 AM
Subject: [PATCH v3] mmc : general purpose partition support.
It allows gerneral purpose partitions in MMC Device.
And I try to simpliy make mmc_blk_alloc_parts using mmc_part
structure suggested by Andrei Warkentin.
After patching, we can see general purpose partitions like this.
cat /proc/partitions
179 0 847872 mmcblk0
179 192 4096 mmcblk0gp3
179 160 4096 mmcblk0gp2
179 128 4096 mmcblk0gp1
179 96 1052672 mmcblk0gp0
179 64 1024 mmcblk0boot1
179 32 1024 mmcblk0boot0
Signed-off-by: Namjae Jeon linkinj...@gmail.com
+ for (idx = 0; idx MMC_NUM_BOOT_PARTITION; idx++) {
+ if (card-boot_part[idx].size) {
+ ret = mmc_blk_alloc_part(card, md,
+ card-boot_part[idx].cookie,
+ card-boot_part[idx].size 9,
+ card-boot_part[idx].force_ro,
+ card-boot_part[idx].name);
+ if (ret)
+ return ret;
+ }
+ }
+
+ for (idx = 0; idx MMC_NUM_GP_PARTITION; idx++) {
+ if (card-gp_part[idx].size) {
+ ret = mmc_blk_alloc_part(card, md,
+ card-gp_part[idx].cookie,
+ card-gp_part[idx].size 9,
+ card-gp_part[idx].force_ro,
+ card-gp_part[idx].name);
+ if (ret)
+ return ret;
You were on a better track before. Why does the block drivre need to know about
the partition types?
You should parse one array.
- card-ext_csd.boot_size = ext_csd[EXT_CSD_BOOT_MULT] 17;
+ if (ext_csd[EXT_CSD_BOOT_MULT]) {
+ part_cfg = EXT_CSD_PART_CONFIG_ACC_BOOT0;
+ for (idx = 0; idx MMC_NUM_BOOT_PARTITION; idx++) {
+ card-boot_part[idx].size =
+ ext_csd[EXT_CSD_BOOT_MULT] 17;
+ card-boot_part[idx].cookie = part_cfg++;
+ sprintf(card-boot_part[idx].name, boot%d,
+ idx);
+ card-boot_part[idx].force_ro = true;
+ }
+ }
}
My earlier comment still stands - make your code look something like -
if (ext_csd[EXT_CSD_BOOT_MULT]) {
part_cfg = EXT_CSD_PART_CONFIG_ACC_BOOT0;
for (idx = 0; idx MMC_NUM_BOOT_PARTITION; idx++) {
mmc_part_add(card, size, part_cfg++, boot%d, part_cfg++,
boot%d, idx, true)
}
+ struct mmc_part boot_part[MMC_NUM_BOOT_PARTITION]; /* mmc boot
partitions */
+ struct mmc_part gp_part[MMC_NUM_GP_PARTITION]; /* mmc general
purpose partitions */
struct mmc_part parts[MMC_NUM_BOOT_PARTITION + MMC_NUM_GP_PARTITION];
unsigned nr_parts;
A
--
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 v2] mmc : general purpose partition support.
Hi Namjae,
In general I think your approach is fine and solves the problem. See further
inline
comments.
- Original Message -
From: Namjae Jeon linkinj...@gmail.com
To: c...@laptop.org, linux-mmc@vger.kernel.org
Cc: linux-ker...@vger.kernel.org, awarken...@vmware.com, adrian hunter
adrian.hun...@intel.com, james p
freyensee james_p_freyen...@linux.intel.com, Namjae Jeon
linkinj...@gmail.com
Sent: Saturday, September 24, 2011 1:07:00 AM
Subject: [PATCH v2] mmc : general purpose partition support.
It allows gerneral purpose partitions in MMC Device.
And I try to simpliy make mmc_blk_alloc_parts using mmc_part
structure suggested by Andrei Warkentin.
After patching, we can see general purpose partitions like this.
cat /proc/partitions
179 0 847872 mmcblk0
179 192 4096 mmcblk0gp4
179 160 4096 mmcblk0gp3
179 128 4096 mmcblk0gp2
179 96 1052672 mmcblk0gp1
179 64 1024 mmcblk0boot1
179 32 1024 mmcblk0boot0
Signed-off-by: Namjae Jeon linkinj...@gmail.com
+ if (ext_csd[EXT_CSD_BOOT_MULT]) {
+ for (i = 0, boot_part_config = 0x1;
+ i MMC_NUM_BOOT_PARTITION;
+ i++, boot_part_config++) {
+ card-part[i].size = ...
+ card-part[i].cookie = ...
+ sprintf(card-part[i].name, boot%d, i);
+ card-part[i].force_ro = ...
+ }
+ }
}
+ if (ext_csd[EXT_CSD_PARTITION_SUPPORT] 0x1) {
+
+ int i, gp_num, gp_part_config, gp_size_mult;
+ for (i = 2, gp_num = 1, gp_part_config = 0x4,
+ card-part[i].size = ...
+ card-part[i].cookie = ...
+ sprintf(card-part[i].name,
+ gp%d, gp_num);
+ card-part[i].force_ro = ..
+ }
+ }
I feel that you should factor out a function that operates on the static part[]
array and
adds a new entry base name, index (i.e. the %d for gp%d), cookie, size, force.
Otherwise you end up with these hidden mines like fixed indeces for
particular parts (i = 2, etc...) which becomes indecipherable for others.
Plus you're mostly doing the same thing.
Thanks,
A
--
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] mmc: dw_mmc: Support predefined multiple block transfers.
Hi Seungwon, - Original Message - From: Seungwon Jeon tgih@samsung.com To: linux-mmc@vger.kernel.org Cc: Chris Ball c...@laptop.org, linux-samsung-...@vger.kernel.org, kgene kim kgene@samsung.com, dh han dh@samsung.com, Seungwon Jeon tgih@samsung.com Sent: Monday, September 26, 2011 7:46:59 AM Subject: [PATCH] mmc: dw_mmc: Support predefined multiple block transfers. This patch adds the support for predefined multiple block read/write. Signed-off-by: Seungwon Jeon tgih@samsung.com Without knowing much about dw_mmc host, your logic otherwise looks ok, given what I've previously done for SDHCI as far as CMD23/Auto-CMD23 enhancement. Just curious, what eMMC cards did you test this on, and what improvement did you see? Acked-by: Andrei Warkentin andrey.warken...@gmail.com Thanks, A -- 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] mmc : general purpose partition support.
Hi Namjae,
I scanned over your changes to enable GP partitions, and while I
did not yet test your changes, they do appear to be ok.
Please CC me on the next version of your patch so I can give
it a spin and Ack on it.
I do suggest at least thinking about ways to improve on this. Back
when I added boot partition support, I already didn't like the fact
that the block driver had to be aware of the eMMC partitions, with all
the code duplication and such. By adding four more partitions,
you've compounded the problem and now you have six pieces of
code that really look the same.
The core/mmc.c right now scans the size values and stores them
in mmc_card, and the block driver is smart enough to know what
to do with them. Why not make the block code generic at the expense
of keeping an array of structures in mmc_card? The block driver
would then just iterate over these and create the additional devices. The
partition
switch routine would then operate on these structures, and could then be pulled
out
of the block driver, making it simpler.
Each physical partition could be described by something like -
struct mmc_part {
unsigned int size;
unsigned int cookie;/* for mmc, idx used in mmc_switch, part_type
from current mmc_blk_data */
char name[DISK_NAME_LEN];
bool force_ro; /* to make boot parts RO by default */
};
Just an idea. Clearly, if MMC grows by another 4-5 possible partitions, it's not
realistic to be copy-pasting the same block of code, nor would it make sense
if/when these types of devices support an arbitrary amount of physical
partitions.
Thanks,
A
--
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] MMC: ext_csd.raw_* used in comparison but never set
f39b2dd9d065151a04f5996656d1f27a7eb32d45 added code to
only compare read-only ext_csd fields in bus width
testing code, yet it's comparing some fields that are
never set.
The affected fields are ext_csd.raw_erased_mem_count and
ext_csd.raw_partition_support.
Signed-off-by: Andrei Warkentin andrey.warken...@gmail.com
---
drivers/mmc/core/mmc.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 5700b1c..bb33832 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -359,6 +359,7 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
*ext_csd)
* card has the Enhanced area enabled. If so, export enhanced
* area offset and size to user by adding sysfs interface.
*/
+ card-ext_csd.raw_partition_support =
ext_csd[EXT_CSD_PARTITION_SUPPORT];
if ((ext_csd[EXT_CSD_PARTITION_SUPPORT] 0x2)
(ext_csd[EXT_CSD_PARTITION_ATTRIBUTE] 0x1)) {
u8 hc_erase_grp_sz =
@@ -405,6 +406,7 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
*ext_csd)
if (card-ext_csd.rev = 5)
card-ext_csd.rel_param = ext_csd[EXT_CSD_WR_REL_PARAM];
+ card-ext_csd.raw_erased_mem_count = ext_csd[EXT_CSD_ERASED_MEM_CONT];
if (ext_csd[EXT_CSD_ERASED_MEM_CONT])
card-erased_byte = 0xFF;
else
--
1.7.6.1
--
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] mmc : export hw reset function info to user
Hi Namjae, others, - Original Message - From: Namjae Jeon linkinj...@gmail.com To: c...@laptop.org, linux-mmc@vger.kernel.org Cc: linux-ker...@vger.kernel.org, Namjae Jeon linkinj...@gmail.com Sent: Sunday, September 18, 2011 11:20:25 AM Subject: [PATCH] mmc : export hw reset function info to user user app should know whether hw reset function is enable to use it. so I try to add sysfs file of hw reset function like enhanced area. If we're going to be adding a bunch of attributes from ext_csd, why not just allow dumping the entire ext_csd in a semi-readable form? Via something like hex_dump_to_buffer. This will allow easy human an machine parsing, and be more lightweight then adding a sysfs attr for each EXT_CSD byte (of which there are a lot). I'm basing this on the thought that the only clients of these attrbutes would either be developers or engineers involved with MMC media, or very specialized software. Thoughts? A -- 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: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Heiko, On Sun, Jun 19, 2011 at 9:23 AM, Heiko Stübner he...@sntech.de wrote: Am Samstag 18 Juni 2011, 22:56:11 schrieb Daniel Mack: The log you sent out seems a bit short (it's covers 1s of boot time - usb0: no IPv6 routers present is the last line ). Can you send - 1) A full log with errors without any of my patches. 2) A full log with just the first patch. 3) A full log with just the second patch. I'm interested in knowing what the pattern of access to boot0 and boot1 is that causes these failures - does it only report I/O errors for for certain blocks (say, above some number) or for all of them. A -- 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: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi, On Thu, Jun 16, 2011 at 3:14 PM, Heiko Stübner he...@sntech.de wrote: Am Dienstag 14 Juni 2011, 22:32:41 schrieb Andrei Warkentin: Hi Heiko, On Tue, Jun 14, 2011 at 9:10 AM, Heiko Stübner he...@sntech.de wrote: nope, no updates yet. The flood also only starts when udev wants to create its device nodes, meaning the initial detection seems not to produce this problem But when I disable the whole boot partition stuff, it works as before without irq storms. As there don't seem to exist reports from other emmc users about this I guess the problem lays somewhere between the boot-partitions-patch and the sdhci-s3c driver (for s3c2416 at least). Alright. Curious. Can you let me know what eMMC device you are connecting to the controller? What is the eMMC revision? hmm ... how do I find these? The simplest is probably knowing what part is in your platform. The slightly more involved is adding a relevant printk for card-ext_csd.rev inside drivers/mmc/core/mmc.c. The real device providing the storage is a 2GB NAND Flash from Hynix. And sadly both of your patches didn't change anything. Can you provide me dmesg for both patches? Thanks again, A -- 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: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi Heiko,
On Tue, Jun 14, 2011 at 9:10 AM, Heiko Stübner he...@sntech.de wrote:
Hi Andrei,
Am Dienstag 14 Juni 2011 schrieb Andrei Warkentin:
I recently came back from vacation (which is why I didn't pitch in
before). Has there been any further update on this? I want to exclude
my EMMC partitioning changes as the possible culprit here.
nope, no updates yet. The flood also only starts when udev wants to
create its device nodes, meaning the initial detection seems not to
produce this problem
But when I disable the whole boot partition stuff, it works as before
without irq storms.
As there don't seem to exist reports from other emmc users about this
I guess the problem lays somewhere between the boot-partitions-patch
and the sdhci-s3c driver (for s3c2416 at least).
As my knowledge about the whole mmc-subsystem is quite spare I also
don't really know where to start looking for the culprit yet.
Alright. Curious. Can you let me know what eMMC device you are
connecting to the controller? What is the eMMC revision?
Can you also apply the following and let me know the results? This
adds an error message if the partition switch fails, and forces the
device to ALWAYS switch back to main user area after every completed
RQ.
start
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 71da564..74e1029 100755
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -450,9 +450,12 @@ static inline int mmc_blk_part_switch(struct
mmc_card *card,
ret = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
EXT_CSD_PART_CONFIG, card-ext_csd.part_config,
card-ext_csd.part_time);
- if (ret)
+ if (ret) {
+ printk(KERN_ERR error switching to part_type %d\n,
+ md-part_type);
return ret;
-}
+ }
+ }
main_md-part_curr = md-part_type;
return 0;
@@ -964,6 +967,13 @@ static int mmc_blk_issue_rq(struct mmc_queue *mq,
struct request *req)
}
out:
+
+ /* Switch to main_md (type = 0) */
+ ret = mmc_blk_part_switch(card, (struct mmc_blk_data *)
mmc_get_drvdata(card));
+ if (ret) {
+ ret = 0;
+ }
+
mmc_release_host(card-host);
return ret;
}
end
I am curious about the results. Here is another thing to try out. This
forces a switch to user area (main partition) every time blk resume is
invoked -
start
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 71da564..f7be8f7 100755
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1318,6 +1318,7 @@ static int mmc_blk_suspend(struct mmc_card
*card, pm_message_t state)
static int mmc_blk_resume(struct mmc_card *card)
{
+ int ret;
struct mmc_blk_data *part_md;
struct mmc_blk_data *md = mmc_get_drvdata(card);
@@ -1325,10 +1326,13 @@ static int mmc_blk_resume(struct mmc_card *card)
mmc_blk_set_blksize(md, card);
/*
-* Resume involves the card going into idle state,
-* so current partition is always the main one.
+* Force main user area on resume. Technically
+* card should have switched itself during reset.
*/
- md-part_curr = md-part_type;
+ ret = mmc_blk_part_switch(card, md);
+ if (ret)
+ return ret;
+
mmc_queue_resume(md-queue);
list_for_each_entry(part_md, md-part, part) {
mmc_queue_resume(part_md-queue);
end
Thanks for helping tracking this down,
A
--
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: irq flood with mmc boot partitions on s3c2416 with 3.0rc1
Hi Everybody, On Fri, Jun 3, 2011 at 2:56 AM, Heiko Stübner he...@sntech.de wrote: Hi, Am Freitag 03 Juni 2011, 01:48:05 schrieb Kyungmin Park: As I don't have the s3c2416 user manaul, I'm not sure it's support AUTO CMD12 or not. but at least it's support at s3c6410 and later. According to the manual, the 2416 supports AUTO CMD12. As I wrote disabling auto cmd12 only works sometimes and other times the irq storm happens like with auto cmd12 enabled - always after the first reboot. So it seems auto cmd12 is not the real reason for the error. Do you also encounter the second error later on (for me in udev stage): mmcblk1boot0: retrying using single block read mmc1: ADMA error mmcblk1boot0: error -5 transferring data, sector 448, nr 32, card status 0x900 end_request: I/O error, dev mmcblk1boot0, sector 448 Buffer I/O error on device mmcblk1boot0, logical block 56 mmcblk1boot1: retrying using single block read mmc1: ADMA error mmcblk1boot1: error -5 transferring data, sector 448, nr 32, card status 0x900 end_request: I/O error, dev mmcblk1boot1, sector 448 I recently came back from vacation (which is why I didn't pitch in before). Has there been any further update on this? I want to exclude my EMMC partitioning changes as the possible culprit here. A -- 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] MMC: SDHCI Auto-CMD23 fixes.
Fixes bugs in Auto-CMD23 feature enable decision. Auto-CMD23
shoud be enabled if host is = v3, and SDMA is not in use.
USE_ADMA | USE_SDMA | Auto-CMD23
-+--+---
0|0 | 1
-+--+---
0|1 | 0
-+--+---
1|0 | 1
-+--+---
1|1 | 1
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index fbb1842..a4e64b0 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2498,9 +2498,9 @@ int sdhci_add_host(struct sdhci_host *host)
host-flags |= SDHCI_AUTO_CMD12;
/* Auto-CMD23 stuff only works in ADMA or PIO. */
- if ((host-version == SDHCI_SPEC_300)
+ if ((host-version = SDHCI_SPEC_300)
((host-flags SDHCI_USE_ADMA) ||
-!(host-flags SDHCI_REQ_USE_DMA))) {
+!(host-flags SDHCI_USE_SDMA))) {
host-flags |= SDHCI_AUTO_CMD23;
printk(KERN_INFO %s: Auto-CMD23 available\n,
mmc_hostname(mmc));
} 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
Re: [PATCH] MMC: SDHCI Auto-CMD23 fixes.
Chris,
On Wed, May 25, 2011 at 2:13 AM, Andrei Warkentin andr...@motorola.com wrote:
Fixes bugs in Auto-CMD23 feature enable decision. Auto-CMD23
shoud be enabled if host is = v3, and SDMA is not in use.
USE_ADMA | USE_SDMA | Auto-CMD23
-+--+---
0 | 0 | 1
-+--+---
0 | 1 | 0
-+--+---
1 | 0 | 1
-+--+---
1 | 1 | 1
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index fbb1842..a4e64b0 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -2498,9 +2498,9 @@ int sdhci_add_host(struct sdhci_host *host)
host-flags |= SDHCI_AUTO_CMD12;
/* Auto-CMD23 stuff only works in ADMA or PIO. */
- if ((host-version == SDHCI_SPEC_300)
+ if ((host-version = SDHCI_SPEC_300)
((host-flags SDHCI_USE_ADMA) ||
- !(host-flags SDHCI_REQ_USE_DMA))) {
+ !(host-flags SDHCI_USE_SDMA))) {
host-flags |= SDHCI_AUTO_CMD23;
printk(KERN_INFO %s: Auto-CMD23 available\n,
mmc_hostname(mmc));
} else
--
1.7.0.4
The reason the older logic didn't work correctly is because
SDHCI_REQ_USE_DMA is not set in sdhci_add_host, but set in
sdhci_prepare_data. That means if you didn't have USE_ADMA, but had
USE_SDMA, it would still enable AUTO_CMD23, since the
SDHCI_REQ_USE_DMA bit would always be 0. I would be very grateful if
you can try it out on your XO. I unfortunately can't test this out
right now.
A
--
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] MMC: SDHCI Auto-CMD23 fixes.
On Wed, May 25, 2011 at 3:13 PM, Chris Ball c...@laptop.org wrote: Hi, On Wed, May 25 2011, Andrei Warkentin wrote: Fixes bugs in Auto-CMD23 feature enable decision. Auto-CMD23 shoud be enabled if host is = v3, and SDMA is not in use. USE_ADMA | USE_SDMA | Auto-CMD23 -+--+--- 0 | 0 | 1 -+--+--- 0 | 1 | 0 -+--+--- 1 | 0 | 1 -+--+--- 1 | 1 | 1 Signed-off-by: Andrei Warkentin andr...@motorola.com Great, this does the right thing on my XO now. I'll send it to Linus along with the rest of the merge shortly. Thanks! Great :-)! Thanks! A -- 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: [[v4] 2/5] MMC: Use CMD23 for multiblock transfers when we can.
On Mon, May 23, 2011 at 7:40 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi A.. I tested your patch..(using CMD23) my environment is the below. eMMC card : Sandisk SEM8G (eMMC 4.3+) buswidth : 4bit (SDR) AP : C110 benchmark : IOzone I want to know how do you think about this result? (i can't see your results) I think that you should use my tool to measure I/O performance. Because I want to see the mins, maxes, average and std dev. Iozone adds way too much noise to the data. You can run it 5 times in a row and get completely different numbers. Please use https://github.com/andreiw/superalign. For a more realistic test you can try performing 2 sqlite inserts or something of the sort and timing that. A -- 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
CMD23 plumbing patchset.
This is the 6th version of the patchset. Made sure that Auto-CMD(12|23) is called *_AUTO_CMD* instead of *_ACMD*. Also removed an unnecessary check for v3 spec, since one is already in place after Arindam's patches. ToC: [v6 1/5] MMC: Add/remove quirks conditional support. [v6 2/5] MMC: Use CMD23 for multiblock transfers when we can. [v6 3/5] MMC: Implement MMC_CAP_CMD23 for SDHCI. [v6 4/5] MMC: Block CMD23 support for UHS104/SDXC cards. [v6 5/5] MMC: SDHCI AutoCMD23 support. A -- 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
[v6 1/5] MMC: Add/remove quirks conditional support.
Conditional add/remove quirks for MMC and SD.
Cc: c...@laptop.org
Cc: malc...@google.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
include/linux/mmc/card.h | 40
1 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 4910dec..7190aa2 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -273,16 +273,14 @@ struct mmc_fixup {
card-cid.month)
/*
- * This hook just adds a quirk unconditionally.
+ * Unconditionally quirk add/remove.
*/
+
static inline void __maybe_unused add_quirk(struct mmc_card *card, int data)
{
card-quirks |= data;
}
-/*
- * This hook just removes a quirk unconditionally.
- */
static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)
{
card-quirks = ~data;
@@ -308,6 +306,40 @@ static inline void __maybe_unused remove_quirk(struct
mmc_card *card, int data)
#define mmc_sd_card_set_uhs(c) ((c)-state |= MMC_STATE_ULTRAHIGHSPEED)
#define mmc_card_set_ext_capacity(c) ((c)-state |= MMC_CARD_SDXC)
+/*
+ * Quirk add/remove for MMC products.
+ */
+
+static inline void __maybe_unused add_quirk_mmc(struct mmc_card *card, int
data)
+{
+ if (mmc_card_mmc(card))
+ card-quirks |= data;
+}
+
+static inline void __maybe_unused remove_quirk_mmc(struct mmc_card *card,
+ int data)
+{
+ if (mmc_card_mmc(card))
+ card-quirks = ~data;
+}
+
+/*
+ * Quirk add/remove for SD products.
+ */
+
+static inline void __maybe_unused add_quirk_sd(struct mmc_card *card, int data)
+{
+ if (mmc_card_sd(card))
+ card-quirks |= data;
+}
+
+static inline void __maybe_unused remove_quirk_sd(struct mmc_card *card,
+ int data)
+{
+ if (mmc_card_sd(card))
+ card-quirks = ~data;
+}
+
static inline int mmc_card_lenient_fn0(const struct mmc_card *c)
{
return c-quirks MMC_QUIRK_LENIENT_FN0;
--
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
Re: [[v4] 2/5] MMC: Use CMD23 for multiblock transfers when we can.
On Mon, May 23, 2011 at 2:25 PM, Andrei Warkentin andr...@motorola.com wrote: On Mon, May 23, 2011 at 7:40 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi A.. I tested your patch..(using CMD23) my environment is the below. eMMC card : Sandisk SEM8G (eMMC 4.3+) buswidth : 4bit (SDR) AP : C110 benchmark : IOzone I want to know how do you think about this result? (i can't see your results) I think that you should use my tool to measure I/O performance. Because I want to see the mins, maxes, average and std dev. Iozone adds way too much noise to the data. You can run it 5 times in a row and get completely different numbers. Please use https://github.com/andreiw/superalign. For a more realistic test you can try performing 2 sqlite inserts or something of the sort and timing that. A Additionally, be careful how you do your testing. I don't want to sound obvious, but, to ensure you can actually compare the collected data against each other - 1) Disable all power/frequency scaling/management/gating, suspend/resume, etc. 2) Make sure nothing else uses the eMMC. No root mounted fs, nothing. 3) Make sure you are avoiding block cache and file system. You want direct block I/O. 4) For extra extra extra reliable results - Make sure you are not rebooting across testing. You will need to add a flag so you can disable CMD23 on the fly via debugfs. For sqlite testing some other helpful hints - 1) Unmount partition containing files on which the SQLite test operates. 2) Perform BLKDISCARD over the partition. 3) Format with desired file system. 4) Mount. 6) Sync echo 3 /proc/sys/vm/drop_caches 7) Perform test. 8) Umount. 9) Repeat from (1) A -- 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
[v6 2/5] MMC: Use CMD23 for multiblock transfers when we can.
CMD23-prefixed instead of open-ended multiblock transfers
have a performance advantage on some MMC cards.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Cc: malc...@google.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 108 +
include/linux/mmc/card.h |1 +
include/linux/mmc/core.h |1 +
include/linux/mmc/host.h |6 +++
include/linux/mmc/mmc.h |6 +++
5 files changed, 93 insertions(+), 29 deletions(-)
mode change 100644 = 100755 drivers/mmc/card/block.c
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
old mode 100644
new mode 100755
index 126c7f4..a380acc
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -59,10 +59,6 @@ MODULE_ALIAS(mmc:block);
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
-#define REL_WRITES_SUPPORTED(card) (mmc_card_mmc((card)) \
-(((card)-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN) || \
- ((card)-ext_csd.rel_sectors)))
-
static DEFINE_MUTEX(block_mutex);
/*
@@ -90,6 +86,10 @@ struct mmc_blk_data {
struct mmc_queue queue;
struct list_head part;
+ unsigned intflags;
+#define MMC_BLK_CMD23 (1 0)/* Can do SET_BLOCK_COUNT for
multiblock */
+#define MMC_BLK_REL_WR (1 1)/* MMC Reliable write support */
+
unsigned intusage;
unsigned intread_only;
unsigned intpart_type;
@@ -429,6 +429,7 @@ static const struct block_device_operations mmc_bdops = {
struct mmc_blk_request {
struct mmc_request mrq;
+ struct mmc_command sbc;
struct mmc_command cmd;
struct mmc_command stop;
struct mmc_data data;
@@ -652,13 +653,10 @@ static int mmc_blk_issue_flush(struct mmc_queue *mq,
struct request *req)
* reliable write can handle, thus finish the request in
* partial completions.
*/
-static inline int mmc_apply_rel_rw(struct mmc_blk_request *brq,
- struct mmc_card *card,
- struct request *req)
+static inline void mmc_apply_rel_rw(struct mmc_blk_request *brq,
+ struct mmc_card *card,
+ struct request *req)
{
- int err;
- struct mmc_command set_count = {0};
-
if (!(card-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN)) {
/* Legacy mode imposes restrictions on transfers. */
if (!IS_ALIGNED(brq-cmd.arg, card-ext_csd.rel_sectors))
@@ -669,15 +667,6 @@ static inline int mmc_apply_rel_rw(struct mmc_blk_request
*brq,
else if (brq-data.blocks card-ext_csd.rel_sectors)
brq-data.blocks = 1;
}
-
- set_count.opcode = MMC_SET_BLOCK_COUNT;
- set_count.arg = brq-data.blocks | (1 31);
- set_count.flags = MMC_RSP_R1 | MMC_CMD_AC;
- err = mmc_wait_for_cmd(card-host, set_count, 0);
- if (err)
- printk(KERN_ERR %s: error %d SET_BLOCK_COUNT\n,
- req-rq_disk-disk_name, err);
- return err;
}
static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *req)
@@ -694,7 +683,7 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct
request *req)
bool do_rel_wr = ((req-cmd_flags REQ_FUA) ||
(req-cmd_flags REQ_META))
(rq_data_dir(req) == WRITE)
- REL_WRITES_SUPPORTED(card);
+ (md-flags MMC_BLK_REL_WR);
do {
struct mmc_command cmd = {0};
@@ -732,11 +721,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
if (brq.data.blocks 1 || do_rel_wr) {
/* SPI multiblock writes terminate using a special
-* token, not a STOP_TRANSMISSION request. Reliable
-* writes use SET_BLOCK_COUNT and do not use a
-* STOP_TRANSMISSION request either.
+* token, not a STOP_TRANSMISSION request.
*/
- if ((!mmc_host_is_spi(card-host) !do_rel_wr) ||
+ if (!mmc_host_is_spi(card-host) ||
rq_data_dir(req) == READ)
brq.mrq.stop = brq.stop;
readcmd = MMC_READ_MULTIPLE_BLOCK;
@@ -754,8 +741,37 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
brq.data.flags |= MMC_DATA_WRITE;
}
- if (do_rel_wr mmc_apply_rel_rw(brq, card, req))
- goto cmd_err;
+ if (do_rel_wr)
+ mmc_apply_rel_rw(brq, card, req);
+
+ /*
+* Pre-defined multi-block transfers are preferable to
+* open ended-ones (and necessary
[v6 3/5] MMC: Implement MMC_CAP_CMD23 for SDHCI.
Implements support for multiblock transfers bounded
by SET_BLOCK_COUNT (CMD23).
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Cc: malc...@google.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 66 ++---
drivers/mmc/host/sdhci.h |2 +-
include/linux/mmc/sdhci.h |1 +
3 files changed, 52 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index cc63f5e..3a53512 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -838,9 +838,10 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
}
static void sdhci_set_transfer_mode(struct sdhci_host *host,
- struct mmc_data *data)
+ struct mmc_command *cmd)
{
u16 mode;
+ struct mmc_data *data = cmd-data;
if (data == NULL)
return;
@@ -848,11 +849,17 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
WARN_ON(!host-data);
mode = SDHCI_TRNS_BLK_CNT_EN;
- if (data-blocks 1) {
- if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
- mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
- else
- mode |= SDHCI_TRNS_MULTI;
+ if (mmc_op_multi(cmd-opcode) ||
+ data-blocks 1) {
+ mode |= SDHCI_TRNS_MULTI;
+
+ /*
+* If we are sending CMD23, CMD12 never gets sent
+* on successful completion (so no Auto-CMD12).
+*/
+ if (!host-mrq-sbc
+ host-flags SDHCI_AUTO_CMD12)
+ mode |= SDHCI_TRNS_AUTO_CMD12;
}
if (data-flags MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
@@ -893,7 +900,15 @@ static void sdhci_finish_data(struct sdhci_host *host)
else
data-bytes_xfered = data-blksz * data-blocks;
- if (data-stop) {
+ /*
+* Need to send CMD12 if -
+* a) open-ended multiblock transfer (no CMD23)
+* b) error in multiblock transfer
+*/
+ if (data-stop
+ (data-error ||
+!host-mrq-sbc)) {
+
/*
* The controller needs a reset of internal state machines
* upon error conditions.
@@ -949,7 +964,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
sdhci_writel(host, cmd-arg, SDHCI_ARGUMENT);
- sdhci_set_transfer_mode(host, cmd-data);
+ sdhci_set_transfer_mode(host, cmd);
if ((cmd-flags MMC_RSP_136) (cmd-flags MMC_RSP_BUSY)) {
printk(KERN_ERR %s: Unsupported response type!\n,
@@ -1004,13 +1019,21 @@ static void sdhci_finish_command(struct sdhci_host
*host)
host-cmd-error = 0;
- if (host-data host-data_early)
- sdhci_finish_data(host);
+ /* Finished CMD23, now send actual command. */
+ if (host-cmd == host-mrq-sbc) {
+ host-cmd = NULL;
+ sdhci_send_command(host, host-mrq-cmd);
+ } else {
- if (!host-cmd-data)
- tasklet_schedule(host-finish_tasklet);
+ /* Processed actual command. */
+ if (host-data host-data_early)
+ sdhci_finish_data(host);
- host-cmd = NULL;
+ if (!host-cmd-data)
+ tasklet_schedule(host-finish_tasklet);
+
+ host-cmd = NULL;
+ }
}
static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
@@ -1189,7 +1212,12 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
#ifndef SDHCI_USE_LEDS_CLASS
sdhci_activate_led(host);
#endif
- if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12) {
+
+ /*
+* Ensure we don't send the STOP for non-SET_BLOCK_COUNTED
+* requests if Auto-CMD12 is enabled.
+*/
+ if (!mrq-sbc (host-flags SDHCI_AUTO_CMD12)) {
if (mrq-stop) {
mrq-data-stop = NULL;
mrq-stop = NULL;
@@ -1227,7 +1255,10 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
host-mrq = mrq;
}
- sdhci_send_command(host, mrq-cmd);
+ if (mrq-sbc)
+ sdhci_send_command(host, mrq-sbc);
+ else
+ sdhci_send_command(host, mrq-cmd);
}
mmiowb();
@@ -2455,7 +2486,10 @@ int sdhci_add_host(struct sdhci_host *host)
} else
mmc-f_min = host-max_clk / SDHCI_MAX_DIV_SPEC_200;
- mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;
+ mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE | MMC_CAP_CMD23;
+
+ if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
+ host-flags |= SDHCI_AUTO_CMD12
[v6 4/5] MMC: Block CMD23 support for UHS104/SDXC cards.
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Cc: malc...@google.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c |9 ++---
drivers/mmc/core/sd.c|2 ++
include/linux/mmc/card.h |3 +++
include/linux/mmc/sd.h |2 +-
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index a380acc..71da564 100755
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1057,9 +1057,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
blk_queue_logical_block_size(md-queue.queue, 512);
set_capacity(md-disk, size);
- if (mmc_host_cmd23(card-host)
- mmc_card_mmc(card))
- md-flags |= MMC_BLK_CMD23;
+ if (mmc_host_cmd23(card-host)) {
+ if (mmc_card_mmc(card) ||
+ (mmc_card_sd(card)
+card-scr.cmds SD_SCR_CMD23_SUPPORT))
+ md-flags |= MMC_BLK_CMD23;
+ }
if (mmc_card_mmc(card)
md-flags MMC_BLK_CMD23
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 596d0b9..ff27741 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -203,6 +203,8 @@ static int mmc_decode_scr(struct mmc_card *card)
else
card-erased_byte = 0x0;
+ if (scr-sda_spec3)
+ scr-cmds = UNSTUFF_BITS(resp, 32, 2);
return 0;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 4a0e27b..c6927a4 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -72,6 +72,9 @@ struct sd_scr {
unsigned char bus_widths;
#define SD_SCR_BUS_WIDTH_1 (10)
#define SD_SCR_BUS_WIDTH_4 (12)
+ unsigned char cmds;
+#define SD_SCR_CMD20_SUPPORT (10)
+#define SD_SCR_CMD23_SUPPORT (11)
};
struct sd_ssr {
diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
index c648878..7d35d52 100644
--- a/include/linux/mmc/sd.h
+++ b/include/linux/mmc/sd.h
@@ -66,7 +66,7 @@
#define SCR_SPEC_VER_0 0 /* Implements system specification 1.0
- 1.01 */
#define SCR_SPEC_VER_1 1 /* Implements system specification 1.10
*/
-#define SCR_SPEC_VER_2 2 /* Implements system specification 2.00
*/
+#define SCR_SPEC_VER_2 2 /* Implements system specification
2.00-3.0X */
/*
* SD bus widths
--
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
[v6 5/5] MMC: SDHCI AutoCMD23 support.
Enables Auto-CMD23 support where available (SDHCI 3.0 controllers)
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Cc: subha...@codeaurora.org
Cc: malc...@google.com
Tested-by: Arindam Nath arindam.n...@amd.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 17 -
drivers/mmc/host/sdhci.h |2 ++
include/linux/mmc/sdhci.h |1 +
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 3a53512..fbb1842 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -860,7 +860,13 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
if (!host-mrq-sbc
host-flags SDHCI_AUTO_CMD12)
mode |= SDHCI_TRNS_AUTO_CMD12;
+ else if (host-mrq-sbc
+host-flags SDHCI_AUTO_CMD23) {
+ mode |= SDHCI_TRNS_AUTO_CMD23;
+ sdhci_writel(host, host-mrq-sbc-arg,
SDHCI_ARGUMENT2);
+ }
}
+
if (data-flags MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
if (host-flags SDHCI_REQ_USE_DMA)
@@ -1255,7 +1261,7 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
host-mrq = mrq;
}
- if (mrq-sbc)
+ if (mrq-sbc !(host-flags SDHCI_AUTO_CMD23))
sdhci_send_command(host, mrq-sbc);
else
sdhci_send_command(host, mrq-cmd);
@@ -2491,6 +2497,15 @@ int sdhci_add_host(struct sdhci_host *host)
if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
host-flags |= SDHCI_AUTO_CMD12;
+ /* Auto-CMD23 stuff only works in ADMA or PIO. */
+ if ((host-version == SDHCI_SPEC_300)
+ ((host-flags SDHCI_USE_ADMA) ||
+!(host-flags SDHCI_REQ_USE_DMA))) {
+ host-flags |= SDHCI_AUTO_CMD23;
+ printk(KERN_INFO %s: Auto-CMD23 available\n,
mmc_hostname(mmc));
+ } else
+ printk(KERN_INFO %s: Auto-CMD23 unavailable\n,
mmc_hostname(mmc));
+
/*
* A controller may support 8-bit width, but the board itself
* might not have the pins brought out. Boards that support
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 2c3fbc5..745c42f 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -25,6 +25,7 @@
*/
#define SDHCI_DMA_ADDRESS 0x00
+#define SDHCI_ARGUMENT2SDHCI_DMA_ADDRESS
#define SDHCI_BLOCK_SIZE 0x04
#define SDHCI_MAKE_BLKSZ(dma, blksz) (((dma 0x7) 12) | (blksz 0xFFF))
@@ -37,6 +38,7 @@
#define SDHCI_TRNS_DMA0x01
#define SDHCI_TRNS_BLK_CNT_EN 0x02
#define SDHCI_TRNS_AUTO_CMD12 0x04
+#define SDHCI_TRNS_AUTO_CMD23 0x08
#define SDHCI_TRNS_READ 0x10
#define SDHCI_TRNS_MULTI 0x20
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 73e27ba..6a68c4e 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -114,6 +114,7 @@ struct sdhci_host {
#define SDHCI_SDR50_NEEDS_TUNING (14)/* SDR50 needs tuning */
#define SDHCI_NEEDS_RETUNING (15) /* Host needs retuning */
#define SDHCI_AUTO_CMD12 (16) /* Auto CMD12 support */
+#define SDHCI_AUTO_CMD23 (17) /* Auto CMD23 support */
unsigned int version; /* SDHCI spec. version */
--
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
Re: [[v4] 2/5] MMC: Use CMD23 for multiblock transfers when we can.
On Mon, May 23, 2011 at 7:40 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi A.. I tested your patch..(using CMD23) my environment is the below. eMMC card : Sandisk SEM8G (eMMC 4.3+) buswidth : 4bit (SDR) AP : C110 benchmark : IOzone Knowing what controller you are on is helpful too. Unless you are on SDHCI, you will see no effect. A -- 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: [[v4] 2/5] MMC: Use CMD23 for multiblock transfers when we can.
On Mon, May 23, 2011 at 2:34 PM, Andrei Warkentin andr...@motorola.com wrote: On Mon, May 23, 2011 at 7:40 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi A.. I tested your patch..(using CMD23) my environment is the below. eMMC card : Sandisk SEM8G (eMMC 4.3+) buswidth : 4bit (SDR) AP : C110 benchmark : IOzone Knowing what controller you are on is helpful too. Unless you are on SDHCI, you will see no effect. A If after all you still see no improvement, you should talk to your Sandisk representative if your particular batch actually is new enough to support CMD23 improvements. Sandisk ships different versions of hardware at the same time, so it's pretty impossible to tell it apart other than some vendor specific EXT_CSD fields... A -- 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: [[v4] 2/5] MMC: Use CMD23 for multiblock transfers when we can.
On Fri, May 20, 2011 at 1:49 AM, Andrei Warkentin andr...@motorola.com wrote: On Thu, May 19, 2011 at 11:38 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi Andrei, Andrei Warkentin wrote: On Wed, May 18, 2011 at 9:37 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi Andrei Andrei Warkentin wrote: CMD23-prefixed instead of open-ended multiblock transfers have a performance advantage on some MMC cards. you mentioned about some MMC cards. Conversely, that means the some card didn't have a performance advantage? Did you find the performance advantage? if you found the advantage and you can tell me, i want to know what do you have the some MMC cards.. I've tested this on a Sandisk eMMC where I saw as good as a 50% improvement on writes (30% real-life use cases). This was a SEM32G 4.3+ part. Can you tell me your environment? buswidth, AP information, benchmark etc.. And if you have the performance result's data, can you share them? This was on an SDHCI controller (hence the patch...) on a Tegra 2-based system. I was measuring throughput on reads and writes (obviously without block cache, filesystem, etc) to an eMMC card, 8 bits. Tested both with my tool (https://github.com/andreiw/superalign) and an sqllite-based test. I'm attaching the data I have. A Additionally, CMD23 use is a requirement for SDXC cards (Arindam can comment on that), as well as for MMC reliable writes and eMMC 4.5-spec features (Yunpeng Gao can comment on that). These patches allow CMD23 use. They do involve a some changes to host controller because of interaction with CMD12, as well as Auto-CMD12 and Auto-CMD23 features. I can definitely consult you if you need help implementing CMD23 support for whatever controller you develop for. A -- 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: [v5 5/5] MMC: SDHCI AutoCMD23 support.
Hi Arindam, On Fri, May 20, 2011 at 5:46 AM, Nath, Arindam arindam.n...@amd.com wrote: Hi Andrei, [...] diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h index 7e28eec..713caf0 100644 --- a/drivers/mmc/host/sdhci.h +++ b/drivers/mmc/host/sdhci.h @@ -25,6 +25,7 @@ */ #define SDHCI_DMA_ADDRESS 0x00 +#define SDHCI_ARGUMENT2 0x00 Since SDHCI_DMA_ADDRESS and SDHCI_ARGUMENT2 in actually the same register, probably ... #define SDHCI_ARGUMENT2 SDHCI_DMA_ADDRESS Sure. #define SDHCI_TRNS_ACMD12 0x04 +#define SDHCI_TRNS_ACMD23 0x08 How about changing these names explicitly to _AUTO_CMD12 and _AUTO_CMD23? That way we are less likely to get confused with App commands with same names. Sounds good. #define SDHCI_ACMD12 (16) /* Auto CMD12 support */ +#define SDHCI_ACMD23 (17) /* Auto CMD23 support */ Ok, will clean it up. A -- 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: [v5 4/5] MMC: Block CMD23 support for UHS104/SDXC cards.
On Fri, May 20, 2011 at 5:38 AM, Nath, Arindam arindam.n...@amd.com wrote:
Hi Andrei,
[...]
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 596d0b9..efff41d 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -203,6 +203,13 @@ static int mmc_decode_scr(struct mmc_card *card)
else
card-erased_byte = 0x0;
+ if (scr-sda_vsn == SCR_SPEC_VER_2) {
+
+ /* Check if Physical Layer Spec v3.0X is supported. */
+ scr-sda_spec3 = UNSTUFF_BITS(resp, 47, 1);
+ if (scr-sda_spec3)
+ scr-cmds = UNSTUFF_BITS(resp, 32, 2);
+ }
There is already this condition checking (== SCR_SPEC_VER_2) in
mmc_decode_scr(). So can you please make your changes appropriately?
Ok, will clean it up.
A
--
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: [v5 2/5] MMC: Use CMD23 for multiblock transfers when we can.
On Fri, May 20, 2011 at 5:29 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Andrei.
I have some question..
In mmc_blk_issue_rw_rq() of block.c, there is the below code.
static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *req)
{
struct mmc_blk_data *md = mq-data;
struct mmc_card *card = md-queue.card;
struct mmc_blk_request brq;
int ret = 1, disable_multi = 0;
/*
* Reliable writes are used to implement Forced Unit Access and
* REQ_META accesses, and are supported only on MMCs.
*/
bool do_rel_wr = ((req-cmd_flags REQ_FUA) ||
(req-cmd_flags REQ_META))
(rq_data_dir(req) == WRITE)
REL_WRITES_SUPPORTED(card);
do {
struct mmc_command cmd = {0};
u32 readcmd, writecmd, status = 0;
memset(brq, 0, sizeof(struct mmc_blk_request));
brq.mrq.cmd = brq.cmd;
brq.mrq.data = brq.data;
brq.cmd.arg = blk_rq_pos(req);
if (!mmc_card_blockaddr(card))
brq.cmd.arg = 9;
brq.cmd.flags = MMC_RSP_SPI_R1 | MMC_RSP_R1 | MMC_CMD_ADTC;
brq.data.blksz = 512;
brq.stop.opcode = MMC_STOP_TRANSMISSION;
brq.stop.arg = 0;
brq.stop.flags = MMC_RSP_SPI_R1B | MMC_RSP_R1B | MMC_CMD_AC;
brq.data.blocks = blk_rq_sectors(req);
There is brq.stop.opcode = MMC_STOP_TRANSMISSION.
If we use CMD23, this line didn't need? Actually i don't know, so i ask to
you.
Nope. Needed. CMD23 support might not be implemented by host driver
(like it isn't right now for anything non-SDHCI). And even it if were,
you still need to send stop command on any error conditions. I suggest
you read the relevant sections in the publically available eMMC spec.
A
--
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: [[v4] 2/5] MMC: Use CMD23 for multiblock transfers when we can.
On Wed, May 18, 2011 at 9:37 PM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi Andrei Andrei Warkentin wrote: CMD23-prefixed instead of open-ended multiblock transfers have a performance advantage on some MMC cards. you mentioned about some MMC cards. Conversely, that means the some card didn't have a performance advantage? Did you find the performance advantage? if you found the advantage and you can tell me, i want to know what do you have the some MMC cards.. I've tested this on a Sandisk eMMC where I saw as good as a 50% improvement on writes (30% real-life use cases). This was a SEM32G 4.3+ part. A -- 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
[v5 1/5] MMC: Add/remove quirks conditional support.
Conditional add/remove quirks for MMC and SD.
Cc: c...@laptop.org
Cc: malc...@google.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
include/linux/mmc/card.h | 40
1 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 4910dec..7190aa2 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -273,16 +273,14 @@ struct mmc_fixup {
card-cid.month)
/*
- * This hook just adds a quirk unconditionally.
+ * Unconditionally quirk add/remove.
*/
+
static inline void __maybe_unused add_quirk(struct mmc_card *card, int data)
{
card-quirks |= data;
}
-/*
- * This hook just removes a quirk unconditionally.
- */
static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)
{
card-quirks = ~data;
@@ -308,6 +306,40 @@ static inline void __maybe_unused remove_quirk(struct
mmc_card *card, int data)
#define mmc_sd_card_set_uhs(c) ((c)-state |= MMC_STATE_ULTRAHIGHSPEED)
#define mmc_card_set_ext_capacity(c) ((c)-state |= MMC_CARD_SDXC)
+/*
+ * Quirk add/remove for MMC products.
+ */
+
+static inline void __maybe_unused add_quirk_mmc(struct mmc_card *card, int
data)
+{
+ if (mmc_card_mmc(card))
+ card-quirks |= data;
+}
+
+static inline void __maybe_unused remove_quirk_mmc(struct mmc_card *card,
+ int data)
+{
+ if (mmc_card_mmc(card))
+ card-quirks = ~data;
+}
+
+/*
+ * Quirk add/remove for SD products.
+ */
+
+static inline void __maybe_unused add_quirk_sd(struct mmc_card *card, int data)
+{
+ if (mmc_card_sd(card))
+ card-quirks |= data;
+}
+
+static inline void __maybe_unused remove_quirk_sd(struct mmc_card *card,
+ int data)
+{
+ if (mmc_card_sd(card))
+ card-quirks = ~data;
+}
+
static inline int mmc_card_lenient_fn0(const struct mmc_card *c)
{
return c-quirks MMC_QUIRK_LENIENT_FN0;
--
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
CMD23 plumbing patchset
This is the fifth version of the CMD23 plumbing and host driver support. Changes: - rebased on top of latest mmc-next - have a tested-by by Arindam ToC: [v5 1/5] MMC: Add/remove quirks conditional support. [v5 2/5] MMC: Use CMD23 for multiblock transfers when we can. [v5 3/5] MMC: Implement MMC_CAP_CMD23 for SDHCI. [v5 4/5] MMC: Block CMD23 support for UHS104/SDXC cards. [v5 5/5] MMC: SDHCI AutoCMD23 support. Thanks, A -- 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
[v5 3/5] MMC: Implement MMC_CAP_CMD23 for SDHCI.
Implements support for multiblock transfers bounded
by SET_BLOCK_COUNT (CMD23).
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Cc: malc...@google.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 66 ++---
include/linux/mmc/sdhci.h |1 +
2 files changed, 51 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index cc63f5e..1138b55 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -838,9 +838,10 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
}
static void sdhci_set_transfer_mode(struct sdhci_host *host,
- struct mmc_data *data)
+ struct mmc_command *cmd)
{
u16 mode;
+ struct mmc_data *data = cmd-data;
if (data == NULL)
return;
@@ -848,11 +849,17 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
WARN_ON(!host-data);
mode = SDHCI_TRNS_BLK_CNT_EN;
- if (data-blocks 1) {
- if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
- mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
- else
- mode |= SDHCI_TRNS_MULTI;
+ if (mmc_op_multi(cmd-opcode) ||
+ data-blocks 1) {
+ mode |= SDHCI_TRNS_MULTI;
+
+ /*
+* If we are sending CMD23, CMD12 never gets sent
+* on successful completion (so no Auto-CMD12).
+*/
+ if (!host-mrq-sbc
+ host-flags SDHCI_ACMD12)
+ mode |= SDHCI_TRNS_ACMD12;
}
if (data-flags MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
@@ -893,7 +900,15 @@ static void sdhci_finish_data(struct sdhci_host *host)
else
data-bytes_xfered = data-blksz * data-blocks;
- if (data-stop) {
+ /*
+* Need to send CMD12 if -
+* a) open-ended multiblock transfer (no CMD23)
+* b) error in multiblock transfer
+*/
+ if (data-stop
+ (data-error ||
+!host-mrq-sbc)) {
+
/*
* The controller needs a reset of internal state machines
* upon error conditions.
@@ -949,7 +964,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
sdhci_writel(host, cmd-arg, SDHCI_ARGUMENT);
- sdhci_set_transfer_mode(host, cmd-data);
+ sdhci_set_transfer_mode(host, cmd);
if ((cmd-flags MMC_RSP_136) (cmd-flags MMC_RSP_BUSY)) {
printk(KERN_ERR %s: Unsupported response type!\n,
@@ -1004,13 +1019,21 @@ static void sdhci_finish_command(struct sdhci_host
*host)
host-cmd-error = 0;
- if (host-data host-data_early)
- sdhci_finish_data(host);
+ /* Finished CMD23, now send actual command. */
+ if (host-cmd == host-mrq-sbc) {
+ host-cmd = NULL;
+ sdhci_send_command(host, host-mrq-cmd);
+ } else {
- if (!host-cmd-data)
- tasklet_schedule(host-finish_tasklet);
+ /* Processed actual command. */
+ if (host-data host-data_early)
+ sdhci_finish_data(host);
- host-cmd = NULL;
+ if (!host-cmd-data)
+ tasklet_schedule(host-finish_tasklet);
+
+ host-cmd = NULL;
+ }
}
static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
@@ -1189,7 +1212,12 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
#ifndef SDHCI_USE_LEDS_CLASS
sdhci_activate_led(host);
#endif
- if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12) {
+
+ /*
+* Ensure we don't send the STOP for non-SET_BLOCK_COUNTED
+* requests if Auto-CMD12 is enabled.
+*/
+ if (!mrq-sbc (host-flags SDHCI_ACMD12)) {
if (mrq-stop) {
mrq-data-stop = NULL;
mrq-stop = NULL;
@@ -1227,7 +1255,10 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
host-mrq = mrq;
}
- sdhci_send_command(host, mrq-cmd);
+ if (mrq-sbc)
+ sdhci_send_command(host, mrq-sbc);
+ else
+ sdhci_send_command(host, mrq-cmd);
}
mmiowb();
@@ -2455,7 +2486,10 @@ int sdhci_add_host(struct sdhci_host *host)
} else
mmc-f_min = host-max_clk / SDHCI_MAX_DIV_SPEC_200;
- mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;
+ mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE | MMC_CAP_CMD23;
+
+ if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
+ host-flags |= SDHCI_ACMD12;
/*
* A controller may support 8-bit
[v5 4/5] MMC: Block CMD23 support for UHS104/SDXC cards.
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Cc: malc...@google.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c |9 ++---
drivers/mmc/core/sd.c|7 +++
include/linux/mmc/card.h |3 +++
include/linux/mmc/sd.h |2 +-
4 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index a380acc..71da564 100755
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -1057,9 +1057,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
blk_queue_logical_block_size(md-queue.queue, 512);
set_capacity(md-disk, size);
- if (mmc_host_cmd23(card-host)
- mmc_card_mmc(card))
- md-flags |= MMC_BLK_CMD23;
+ if (mmc_host_cmd23(card-host)) {
+ if (mmc_card_mmc(card) ||
+ (mmc_card_sd(card)
+card-scr.cmds SD_SCR_CMD23_SUPPORT))
+ md-flags |= MMC_BLK_CMD23;
+ }
if (mmc_card_mmc(card)
md-flags MMC_BLK_CMD23
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 596d0b9..efff41d 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -203,6 +203,13 @@ static int mmc_decode_scr(struct mmc_card *card)
else
card-erased_byte = 0x0;
+ if (scr-sda_vsn == SCR_SPEC_VER_2) {
+
+ /* Check if Physical Layer Spec v3.0X is supported. */
+ scr-sda_spec3 = UNSTUFF_BITS(resp, 47, 1);
+ if (scr-sda_spec3)
+ scr-cmds = UNSTUFF_BITS(resp, 32, 2);
+ }
return 0;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 4a0e27b..c6927a4 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -72,6 +72,9 @@ struct sd_scr {
unsigned char bus_widths;
#define SD_SCR_BUS_WIDTH_1 (10)
#define SD_SCR_BUS_WIDTH_4 (12)
+ unsigned char cmds;
+#define SD_SCR_CMD20_SUPPORT (10)
+#define SD_SCR_CMD23_SUPPORT (11)
};
struct sd_ssr {
diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
index c648878..7d35d52 100644
--- a/include/linux/mmc/sd.h
+++ b/include/linux/mmc/sd.h
@@ -66,7 +66,7 @@
#define SCR_SPEC_VER_0 0 /* Implements system specification 1.0
- 1.01 */
#define SCR_SPEC_VER_1 1 /* Implements system specification 1.10
*/
-#define SCR_SPEC_VER_2 2 /* Implements system specification 2.00
*/
+#define SCR_SPEC_VER_2 2 /* Implements system specification
2.00-3.0X */
/*
* SD bus widths
--
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
[v5 5/5] MMC: SDHCI AutoCMD23 support.
Enables Auto-CMD23 support where available (SDHCI 3.0 controllers)
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Cc: subha...@codeaurora.org
Cc: malc...@google.com
Tested-by: Arindam Nath arindam.n...@amd.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 17 -
drivers/mmc/host/sdhci.h |2 ++
include/linux/mmc/sdhci.h |1 +
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1138b55..d79b2d0 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -860,7 +860,13 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
if (!host-mrq-sbc
host-flags SDHCI_ACMD12)
mode |= SDHCI_TRNS_ACMD12;
+ else if (host-mrq-sbc
+host-flags SDHCI_ACMD23) {
+ mode |= SDHCI_TRNS_ACMD23;
+ sdhci_writel(host, host-mrq-sbc-arg,
SDHCI_ARGUMENT2);
+ }
}
+
if (data-flags MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
if (host-flags SDHCI_REQ_USE_DMA)
@@ -1255,7 +1261,7 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
host-mrq = mrq;
}
- if (mrq-sbc)
+ if (mrq-sbc !(host-flags SDHCI_ACMD23))
sdhci_send_command(host, mrq-sbc);
else
sdhci_send_command(host, mrq-cmd);
@@ -2491,6 +2497,15 @@ int sdhci_add_host(struct sdhci_host *host)
if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
host-flags |= SDHCI_ACMD12;
+ /* Auto-CMD23 stuff only works in ADMA or PIO. */
+ if ((host-version == SDHCI_SPEC_300)
+ ((host-flags SDHCI_USE_ADMA) ||
+!(host-flags SDHCI_REQ_USE_DMA))) {
+ host-flags |= SDHCI_ACMD23;
+ printk(KERN_INFO %s: Auto-CMD23 available\n,
mmc_hostname(mmc));
+ } else
+ printk(KERN_INFO %s: Auto-CMD23 unavailable\n,
mmc_hostname(mmc));
+
/*
* A controller may support 8-bit width, but the board itself
* might not have the pins brought out. Boards that support
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 7e28eec..713caf0 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -25,6 +25,7 @@
*/
#define SDHCI_DMA_ADDRESS 0x00
+#define SDHCI_ARGUMENT20x00
#define SDHCI_BLOCK_SIZE 0x04
#define SDHCI_MAKE_BLKSZ(dma, blksz) (((dma 0x7) 12) | (blksz 0xFFF))
@@ -37,6 +38,7 @@
#define SDHCI_TRNS_DMA0x01
#define SDHCI_TRNS_BLK_CNT_EN 0x02
#define SDHCI_TRNS_ACMD12 0x04
+#define SDHCI_TRNS_ACMD23 0x08
#define SDHCI_TRNS_READ 0x10
#define SDHCI_TRNS_MULTI 0x20
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index d70de9d..d0db8ae 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -114,6 +114,7 @@ struct sdhci_host {
#define SDHCI_SDR50_NEEDS_TUNING (14)/* SDR50 needs tuning */
#define SDHCI_NEEDS_RETUNING (15) /* Host needs retuning */
#define SDHCI_ACMD12 (16) /* Auto CMD12 support */
+#define SDHCI_ACMD23 (17) /* Auto CMD23 support */
unsigned int version; /* SDHCI spec. version */
--
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
Re: [RFC]mmc: fix dead lock issue when system entering S3
Hey, On Tue, May 17, 2011 at 5:03 AM, Dong, Chuanxiao chuanxiao.d...@intel.com wrote: Just found Andrei Warkentin also submitted a RFC patch, which included more fix for mounted root file system media. Please ignore this thread. I submitted an RFC patch as an idea up for discussion, but certainly the issue never went away :-).. Your patch will not quite work. If you have a filesystem it will not unmount, so mmc0 (for example) will never release, so when a new (or same) card re-enumerates, it will be mmc1... I believe my patch basically created md orphans which would be reconnected on resume, which is bit of a really nasty hack... I'm not sure if there is a better way. I could have sworn I saw a patch a week ago that attempted to resolve the suspend/resume with mounted fs issue by deferring removal until resume, but I don't see it now, and I'm not sure if it dealt well with the whole attempting to unmount fs in mmc block cleanup path... I guess I can resubmit... A -- 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: [RFC] MMC: Request for comments attempt at dealing with removeable suspend/resume.
On Tue, May 17, 2011 at 5:15 AM, Dong, Chuanxiao chuanxiao.d...@intel.com wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Andrei Warkentin Sent: Tuesday, April 05, 2011 4:31 AM To: linux-mmc@vger.kernel.org Cc: Andrei Warkentin Subject: [RFC] MMC: Request for comments attempt at dealing with removeable suspend/resume. Is there any value to doing something like this in order to be able to suspend/resume with a (manually, or rootfs) mounted filesystem on mmcblk? Thoughts? Hi Andrei, I also encountered the same issue with you when system is suspending. And the modification in core.c actually can fix my issue. For the mounted root file system, I think it makes sense for such medias to use MMC_UNSAFE_RESUME. Is there some use case need to remove root file system media? Except that if the filesystem (non-root) fails to unmount or it's a root filesystem on a device on a host which isn't MMC_UNSAFE_RESUME, then you will re-enumerate incorrectly on resume. On resume, fs will be on a now dead device (say mmc0), while kernel will re-enumerate card as mmc1 now since mmc0 never tore down. Basically even if you're smart enough to avoid switching cards on suspend/resume, this can still get to you and you will wind up with either just a hang (if root fs on card), or weird re-enumeration and countless I/O errors to dead device. What above patch does is that it uses a two step process to clean up MDs. MDs are put on an orphan list when the backing device goes away. If they can be safely cleaned up - great, and they go away completely when the refcount drops. Otherwise, they'll be reconnected to if the *same* backing device reappears again. A -- 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: cjb traveling May 1 - May 10
Hi Chris, On Fri, Apr 29, 2011 at 3:35 PM, Chris Ball c...@laptop.org wrote: Hi, I'll be in Uruguay for OLPC from May 1st to May 10th. I'll be online there but won't have as much time to reply to list mail as usual -- I'll catch up on mail properly after I get back. I'm going to push the changes below to Linus early next week (after some more time in -next), and I'll push the next revision of Arindam's SD 3.0 patchset to mmc-next once it has a few Reviewed/Tested-by tags attached. Thanks, Once Arindam's changes are in, I'll rebase the CMD23 support on top of that and resubmit. A -- 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] mmc: subtract boot sectors from disk size for eMMC 4.3+ devices
On Thu, Apr 28, 2011 at 1:00 PM, Colin Cross ccr...@google.com wrote: On Thu, Apr 28, 2011 at 3:33 AM, Linus Walleij linus.wall...@linaro.org wrote: 2011/3/5 Linus Walleij linus.wall...@stericsson.com: This patch is a squash of patches from Gary King and Ulf Hansson done in Android trees, hopefully fixing the issue properly. The csd sector count reported by eMMC 4.3+ cards includes the boot partition size; subtract this from the size reported to the disk since the boot partition is inaccessible. I'm trying to get somewhere with this. AFAICT reading the spec it does not say anything about the boot sectors being subtracted from the pool of available sectors, i.e. either you set these sectors aside permanently or you do not support the feature. So the behaviour fixed in this patch should be a per-card quirk, not generic. Then this: + /* size is in 256K chunks, i.e. 512 sectors each */ + boot_sectors = ext_csd[EXT_CSD_BOOT_SIZE_MULTI] * 512; This is not what the spec says. It states that the size is in 128KB chunks, so the correct code shoul be: boot_sectors = ext_csd[EXT_CSD_BOOT_SIZE_MULTI] * 256; Any comments on this? I guess it's been working, the patch prent in the Android kernels simply remove twice as many sectors as required from the card sector pool :-/ This patch was dropped from the Android tree, it is clearly not correct for all eMMC devices. We have worked around the problem on the affected by letting the bootloader tell us where it put the GPT near the end of the device, in which case the actual size of the device becomes irrelevant. I'm not convinced that any eMMC chip has this problem, it may have just been confusion on the part of nVidia caused by their bootloader's logical block addressing system, where the boot sectors are addressed as 0, and the regular area starts at sizeof(boot sector). The off-by-two error may have been caused by the affected eMMC having two boot sectors. I would suggest forgetting about this patch unless someone can prove that there is a device that fails to write at the end. Plus as far as linux-mmc tree, the boot size calculation is now correct for enabling the boot hardware partitions as separate logical devices... All the cards I've tested (granted, wasn't too many) handled boot partitions correctly, and the user partition area size never included the boot partitions. So I think we can forget about Gary's patch. For broken hardware we now have the quirk hooks in block.c to work around this if said broken hardware actually exists... A -- 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] RFC: mmc: subtract boot sectors from disk size on quirky cards
On Thu, Apr 28, 2011 at 5:58 AM, Linus Walleij
linus.wall...@stericsson.com wrote:
From: Linus Walleij linus.wall...@linaro.org
The csd sector count reported by some problematic eMMC 4.3+ cards
includes the boot partition size; subtract this from the size
reported to the disk since the boot partition is inaccessible.
Cc: Gary King gk...@nvidia.com
Cc: Ulf Hansson ulf.hans...@stericsson.com
Cc: Colin Cross ccr...@android.com
Cc: Andrei Warkentin andr...@motorola.com
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
GARY: can you provide the VID+PID numbers for the problematic
card, so we can handle this properly?
---
drivers/mmc/core/mmc.c | 13 +
drivers/mmc/core/quirks.c | 3 +++
include/linux/mmc/card.h | 1 +
include/linux/mmc/mmc.h | 1 +
4 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 772d0d0..0833d15 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -255,6 +255,19 @@ static int mmc_read_ext_csd(struct mmc_card *card)
/* Cards with density 2GiB are sector addressed */
if (card-ext_csd.sectors (2u * 1024 * 1024 * 1024) / 512)
mmc_card_set_blockaddr(card);
+
+ /*
+ * Some cards require that you remove the boot sectors from
the
+ * total amount of sectors on the card. This is not defined
+ * by the spec so needs to be a per-card quirk.
+ */
+ if (card-ext_csd.sectors
+ (card-quirks MMC_QUIRK_SUBTRACT_BOOTSECS)) {
+ unsigned boot_sectors;
+ /* size is in 128K chunks, i.e. 256 sectors each */
+ boot_sectors = ext_csd[EXT_CSD_BOOT_SIZE_MULTI] * 256;
+ card-ext_csd.sectors -= boot_sectors;
+ }
}
switch (ext_csd[EXT_CSD_CARD_TYPE] EXT_CSD_CARD_TYPE_MASK) {
diff --git a/drivers/mmc/core/quirks.c b/drivers/mmc/core/quirks.c
index 8b74..fb1f528 100644
--- a/drivers/mmc/core/quirks.c
+++ b/drivers/mmc/core/quirks.c
@@ -64,6 +64,9 @@ static const struct mmc_fixup mmc_fixup_methods[] = {
add_quirk_for_sdio_devices, MMC_QUIRK_BROKEN_CLK_GATING },
{ SDIO_VENDOR_ID_TI, SDIO_DEVICE_ID_TI_WL1271,
remove_quirk, MMC_QUIRK_BROKEN_CLK_GATING },
+ /* TODO: fill in problematic card VID/PID here */
+ { 0x, 0x,
+ add_quirk, MMC_QUIRK_SUBTRACT_BOOTSECS },
{ 0 }
};
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index adb4888..f860eea 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -125,6 +125,7 @@ struct mmc_card {
#define MMC_QUIRK_NONSTD_SDIO (12) /* non-standard SDIO card
attached */
/* (missing CIA registers) */
#define MMC_QUIRK_BROKEN_CLK_GATING (13) /* clock gating the sdio bus
will make card fail */
+#define MMC_QUIRK_SUBTRACT_BOOTSECS (14) /* remove any boot sectors
from the sector allocation pool */
unsigned int erase_size; /* erase size in sectors */
unsigned int erase_shift; /* if erase unit is power 2 */
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index 264ba54..4516fc1 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -267,6 +267,7 @@ struct _mmc_csd {
#define EXT_CSD_HC_WP_GRP_SIZE 221 /* RO */
#define EXT_CSD_ERASE_TIMEOUT_MULT 223 /* RO */
#define EXT_CSD_HC_ERASE_GRP_SIZE 224 /* RO */
+#define EXT_CSD_BOOT_SIZE_MULTI 226 /* RO */
#define EXT_CSD_SEC_TRIM_MULT 229 /* RO */
#define EXT_CSD_SEC_ERASE_MULT 230 /* RO */
#define EXT_CSD_SEC_FEATURE_SUPPORT 231 /* RO */
Linus,
The right place for this would now be the block.c quirks table.
Assuming issue actually exists. Additionally, your changes to
mmc.c are not required (size is already correctly fetched there).
A
--
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: [[v4] 5/5] MMC: SDHCI AutoCMD23 support.
On Thu, Apr 28, 2011 at 3:34 AM, Nath, Arindam arindam.n...@amd.com wrote: Hi Andrei, The controller is able to send Auto CMD23 with your patch. Thanks, Arindam Whoo hoo :-). This just about made my day... Thanks a lot Arindam, I really appreciate you taking your time to test this out! So is that an Ack? A -- 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: [[v4] 5/5] MMC: SDHCI AutoCMD23 support.
Hi Arindam, On Wed, Apr 27, 2011 at 12:49 AM, Nath, Arindam arindam.n...@amd.com wrote: Hi Andrei, Is there any more change to your V4 than the ones we discussed yesterday? I did the mod we discussed, but seems like the driver only sends CMD23 now, not Auto CMD23. Two things V4 does, both of which we discussed yesterday - 1) Make sure the code that set SDHCI_ACMD23 is always run (got rid of the Kconfig conditional) 2) Make sure value written into ARGUMENT2 comes from sbc struct. Only (1) should have affected you. (2) would have broken rel. writes. I put in an info print telling you if you have auto-cmd23 available or not. If you see CMD23 getting sent, then AutoCMD23 was not detected as a feature. Weird. SDHCI_ACMD23 is set if a) Host controller is version 3 b) You're using ADMA or no DMA. A -- 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: [[v4] 5/5] MMC: SDHCI AutoCMD23 support.
On Wed, Apr 27, 2011 at 1:02 AM, Nath, Arindam arindam.n...@amd.com wrote:
Guess I will have to hand modify my code based on your V4 patches again, I
don't think your patches are based on top of mine.
Thanks,
Arindam
Just verify these blobs look similar -
+ else if (host-mrq-sbc
+host-flags SDHCI_ACMD23) {
+ mode |= SDHCI_TRNS_ACMD23;
+ sdhci_writel(host, host-mrq-sbc-arg,
SDHCI_ARGUMENT2);
+ }
and
host-flags |= SDHCI_ACMD12;
+ /* Auto-CMD23 stuff only works in ADMA or PIO. */
+ if ((host-version == SDHCI_SPEC_300)
+ ((host-flags SDHCI_USE_ADMA) ||
+!(host-flags SDHCI_REQ_USE_DMA))) {
+ host-flags |= SDHCI_ACMD23;
+ printk(KERN_INFO %s: Auto-CMD23 available\n,
mmc_hostname(mmc));
+ } else
+ printk(KERN_INFO %s: Auto-CMD23 unavailable\n,
mmc_hostname(mmc));
+
/*
* A controller may support 8-bit width, but the board itself
* might not have the pins brought out. Boards that support
I apologize for the fuss.
A
--
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 1/6] mmc: block: Resume multi-block reads after transient read errors.
On Wed, Apr 27, 2011 at 3:16 AM, Adrian Hunter adrian.hun...@nokia.com wrote: On 26/04/11 16:19, Arnd Bergmann wrote: On Saturday 23 April 2011, John Stultz wrote: From: David Dingdavid.j.d...@motorola.com CC: Chris Ballc...@laptop.org CC: Arnd Bergmanna...@arndb.de CC: Dima Zavind...@android.com Signed-off-by: Bentao Zoubz...@motorola.com Signed-off-by: David Dingdavid.j.d...@motorola.com Signed-off-by: San Mehats...@google.com Signed-off-by: John Stultzjohn.stu...@linaro.org The disable_multi logic was introduced in 6a79e391 mmc_block: ensure all sectors that do not have errors are read by Adrian Hunter. Maybe he can comment on this. My impression is that the code makes more sense without this add-on patch, because the flag is set for exactly one request and makes mmc_blk_issue_rw_rq issue all blocks in that request one by one up to the first error, while after the patch, we would read one sector, then read the remaining request at once, fail, and read the next sector, and so on. You could definitely interpret the retry path as being: - do a probe sector-sized read/write - if it succeeds, pretend everything is fine and retry with disable_multi=0 - else the probed sector must the point of failure ...it would mean more retrying in the case of an actual card failure mode (at which point you're not doing much anyway), and drastic improvement in the case of some one-time (or not so one-time) host glitches... The other thought I have is that it's not ideal to overcomplicate the logic inside issue_rw_rq (i.e. bisection stuff). Until Per's refactoring as part of async issue it was already too big :-). What do you think? Anyway I hope the patch owner weighs in. A -- 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 0/2] Race fixes in sdhci
On Wed, Apr 27, 2011 at 8:23 AM, Mark Brown broo...@opensource.wolfsonmicro.com wrote: I've had this pair of patches sitting in my tree for a while now (I believe they were previously posted) providing stability improvements in sdhci on my systems. Having looked through the code I believe but have not confirmed that the issue is that the timeout is racing with an actual completion of a pending task - both paths will trigger the tasklet, and if you trigger a tasklet while it is running this causes it to be rescheduled. The result will be that the tasklet gets run a second time with no work pending for it. I'm not convinced that these are the best fixes (it feels like we should instead be closing the races down) but I don't really have time to come up with something better myself right now so I'm pushing them out as-is for comment. Ben Dooks (1): MMC: SDHCI: Check mrq-cmd in sdhci_tasklet_finish Dimitris Papastamos (1): MMC: SDHCI: Check mrq != NULL in sdhci_tasklet_finish drivers/mmc/host/sdhci.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) So the timeout interrupt occurs after even though the command succeeds? Am I interpreting that correctly? A -- 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: CMD23 plumbing and support patchset.
On Fri, Apr 22, 2011 at 9:51 PM, Chris Ball c...@laptop.org wrote: Hi, On Thu, Apr 21 2011, Andrei Warkentin wrote: Can you give me the manufacturing date? This is pretty interesting. You can see an improvement even if you do something like time block writes (O_DIRECT | O_SYNC, of course). But after all synthetic tests I measured the time it took to do 4 SQLite insertions and saw something like 30% improvement. And you're trying this on SDHCI I presume, right? Is this on the same board as the other log you sent? Controller is SDHCI-PXA? If you give me /sys/block/mmcblk0/device/date, I'll investigate why this improvement isn't helping you out. Yeah, sdhci-pxa: [root@localhost olpc]# cat /sys/block/mmcblk0/device/date 10/2010 Want to give me a benchmark script so that we can compare speeds directly? One more thing to check - is this an eMMC 4.3+ card? (you're going to have to plumb something in mmc.c to print it). Sandisk says improvement going to be seen only on 4.3+ cards. Sandisk releases different generation cards concurrently, and there is no way to tell from manfid/oemid/date/hwref/fwrev. Ugh. I'll send another email (in a bit) with test script and a patch to enable/disable cmd23 use at runtime so you can get better tests than across reboot. A -- 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] mmc: sdhci: add support for pre_req and post_req
Hi,
On Fri, Apr 22, 2011 at 6:01 AM, Jaehoon Chung jh80.ch...@samsung.com wrote:
Hi Andrei..
Did you test this patch with ADMA?
I wonder that be increased performance or others..
FWIW...
ADMA
With changes
adb shell echo 0 /sys/module/sdhci/parameters/no_prepost
time adb shell iozone -a -f /cache/file -g 4m /mnt/obb/with
real0m37.245s
user0m0.010s
sys 0m0.000s
Without changes
adb shell echo 1 /sys/module/sdhci/parameters/no_prepost
time adb shell iozone -a -f /cache/file -g 4m /mnt/obb/without
real0m38.400s
user0m0.000s
sys 0m0.010s
SDMA plus BOUNCE_BUFFER
With changes
adb shell echo 0 /sys/module/sdhci/parameters/no_prepost
time adb shell iozone -a -f /cache/file -g 4m /mnt/obb/with
real0m37.999s
user0m0.000s
sys 0m0.010s
Without changes
adb shell echo 1 /sys/module/sdhci/parameters/no_prepost
time adb shell iozone -a -f /cache/file -g 4m /mnt/obb/without
real0m39.717s
user0m0.000s
sys 0m0.010s
Collected data using this patch on top of Shawn's...
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 3320c75..f698586 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -39,6 +39,7 @@
#endif
static unsigned int debug_quirks = 0;
+static unsigned int no_prepost = 0;
static void sdhci_prepare_data(struct sdhci_host *, struct mmc_data *);
static void sdhci_finish_data(struct sdhci_host *);
@@ -1140,6 +1141,8 @@ static void sdhci_pre_req(struct mmc_host *mmc,
struct mmc_request *mrq,
bool is_first_req)
{
struct sdhci_host *host = mmc_priv(mmc);
+ if (no_prepost)
+ return;
if (mrq-data-host_cookie) {
mrq-data-host_cookie = 0;
@@ -1157,6 +1160,9 @@ static void sdhci_post_req(struct mmc_host *mmc,
struct mmc_request *mrq,
struct sdhci_host *host = mmc_priv(mmc);
struct mmc_data *data = mrq-data;
+ if (no_prepost)
+ return;
+
if (host-flags SDHCI_REQ_USE_DMA) {
dma_unmap_sg(mmc_dev(host-mmc), data-sg, data-sg_len,
(data-flags MMC_DATA_WRITE) ?
@@ -2163,6 +2169,7 @@ module_init(sdhci_drv_init);
module_exit(sdhci_drv_exit);
module_param(debug_quirks, uint, 0444);
+module_param(no_prepost, uint, 0644);
MODULE_AUTHOR(Pierre Ossman pie...@ossman.eu);
MODULE_DESCRIPTION(Secure Digital Host Controller Interface core driver);
A
--
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
CMD23 plumbing patchset.
This is the fourth version of the CMD23 plumbing and host driver support. Changes: 1) Changes MMC white list to a black list. 2) Fixes two stupid bugs in tentative AutoCMD23 patch (sorry Arindam) ToC: [[v4] 1/5] MMC: Add/remove quirks conditional support. [[v4] 2/5] MMC: Use CMD23 for multiblock transfers when we can. [[v4] 3/5] MMC: Implement MMC_CAP_CMD23 for SDHCI. [[v4] 4/5] MMC: Block CMD23 support for UHS104/SDXC cards. [[v4] 5/5] MMC: SDHCI AutoCMD23 support. A -- 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
[[v4] 1/5] MMC: Add/remove quirks conditional support.
Conditional add/remove quirks for MMC and SD.
Cc: c...@laptop.org
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
include/linux/mmc/card.h | 40
1 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 72a9868..6a4ed2a 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -233,16 +233,14 @@ struct mmc_fixup {
card-cid.month)
/*
- * This hook just adds a quirk unconditionally.
+ * Unconditionally quirk add/remove.
*/
+
static inline void __maybe_unused add_quirk(struct mmc_card *card, int data)
{
card-quirks |= data;
}
-/*
- * This hook just removes a quirk unconditionally.
- */
static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)
{
card-quirks = ~data;
@@ -264,6 +262,40 @@ static inline void __maybe_unused remove_quirk(struct
mmc_card *card, int data)
#define mmc_card_set_blockaddr(c) ((c)-state |= MMC_STATE_BLOCKADDR)
#define mmc_card_set_ddr_mode(c) ((c)-state |= MMC_STATE_HIGHSPEED_DDR)
+/*
+ * Quirk add/remove for MMC products.
+ */
+
+static inline void __maybe_unused add_quirk_mmc(struct mmc_card *card, int
data)
+{
+ if (mmc_card_mmc(card))
+ card-quirks |= data;
+}
+
+static inline void __maybe_unused remove_quirk_mmc(struct mmc_card *card,
+ int data)
+{
+ if (mmc_card_mmc(card))
+ card-quirks = ~data;
+}
+
+/*
+ * Quirk add/remove for SD products.
+ */
+
+static inline void __maybe_unused add_quirk_sd(struct mmc_card *card, int data)
+{
+ if (mmc_card_sd(card))
+ card-quirks |= data;
+}
+
+static inline void __maybe_unused remove_quirk_sd(struct mmc_card *card,
+ int data)
+{
+ if (mmc_card_sd(card))
+ card-quirks = ~data;
+}
+
static inline int mmc_card_lenient_fn0(const struct mmc_card *c)
{
return c-quirks MMC_QUIRK_LENIENT_FN0;
--
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
[[v4] 2/5] MMC: Use CMD23 for multiblock transfers when we can.
CMD23-prefixed instead of open-ended multiblock transfers
have a performance advantage on some MMC cards.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 109 +-
include/linux/mmc/card.h |1 +
include/linux/mmc/core.h |1 +
include/linux/mmc/host.h |6 +++
include/linux/mmc/mmc.h |6 +++
5 files changed, 93 insertions(+), 30 deletions(-)
mode change 100644 = 100755 drivers/mmc/card/block.c
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
old mode 100644
new mode 100755
index 92e4a00..b91bec2
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -55,10 +55,6 @@ MODULE_ALIAS(mmc:block);
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
-#define REL_WRITES_SUPPORTED(card) (mmc_card_mmc((card)) \
-(((card)-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN) || \
- ((card)-ext_csd.rel_sectors)))
-
static DEFINE_MUTEX(block_mutex);
/*
@@ -86,6 +82,10 @@ struct mmc_blk_data {
struct mmc_queue queue;
struct list_head part;
+ unsigned intflags;
+#define MMC_BLK_CMD23 (1 0)/* Can do SET_BLOCK_COUNT for
multiblock */
+#define MMC_BLK_REL_WR (1 1)/* MMC Reliable write support */
+
unsigned intusage;
unsigned intread_only;
unsigned intpart_type;
@@ -227,6 +227,7 @@ static const struct block_device_operations mmc_bdops = {
struct mmc_blk_request {
struct mmc_request mrq;
+ struct mmc_command sbc;
struct mmc_command cmd;
struct mmc_command stop;
struct mmc_data data;
@@ -457,13 +458,10 @@ static int mmc_blk_issue_flush(struct mmc_queue *mq,
struct request *req)
* reliable write can handle, thus finish the request in
* partial completions.
*/
-static inline int mmc_apply_rel_rw(struct mmc_blk_request *brq,
- struct mmc_card *card,
- struct request *req)
+static inline void mmc_apply_rel_rw(struct mmc_blk_request *brq,
+ struct mmc_card *card,
+ struct request *req)
{
- int err;
- struct mmc_command set_count;
-
if (!(card-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN)) {
/* Legacy mode imposes restrictions on transfers. */
if (!IS_ALIGNED(brq-cmd.arg, card-ext_csd.rel_sectors))
@@ -474,16 +472,6 @@ static inline int mmc_apply_rel_rw(struct mmc_blk_request
*brq,
else if (brq-data.blocks card-ext_csd.rel_sectors)
brq-data.blocks = 1;
}
-
- memset(set_count, 0, sizeof(struct mmc_command));
- set_count.opcode = MMC_SET_BLOCK_COUNT;
- set_count.arg = brq-data.blocks | (1 31);
- set_count.flags = MMC_RSP_R1 | MMC_CMD_AC;
- err = mmc_wait_for_cmd(card-host, set_count, 0);
- if (err)
- printk(KERN_ERR %s: error %d SET_BLOCK_COUNT\n,
- req-rq_disk-disk_name, err);
- return err;
}
static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *req)
@@ -500,7 +488,7 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct
request *req)
bool do_rel_wr = ((req-cmd_flags REQ_FUA) ||
(req-cmd_flags REQ_META))
(rq_data_dir(req) == WRITE)
- REL_WRITES_SUPPORTED(card);
+ (md-flags MMC_BLK_REL_WR);
do {
struct mmc_command cmd;
@@ -539,11 +527,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
if (brq.data.blocks 1 || do_rel_wr) {
/* SPI multiblock writes terminate using a special
-* token, not a STOP_TRANSMISSION request. Reliable
-* writes use SET_BLOCK_COUNT and do not use a
-* STOP_TRANSMISSION request either.
+* token, not a STOP_TRANSMISSION request.
*/
- if ((!mmc_host_is_spi(card-host) !do_rel_wr) ||
+ if (!mmc_host_is_spi(card-host) ||
rq_data_dir(req) == READ)
brq.mrq.stop = brq.stop;
readcmd = MMC_READ_MULTIPLE_BLOCK;
@@ -561,8 +547,37 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
brq.data.flags |= MMC_DATA_WRITE;
}
- if (do_rel_wr mmc_apply_rel_rw(brq, card, req))
- goto cmd_err;
+ if (do_rel_wr)
+ mmc_apply_rel_rw(brq, card, req);
+
+ /*
+* Pre-defined multi-block transfers are preferable to
+* open ended-ones
[[v4] 3/5] MMC: Implement MMC_CAP_CMD23 for SDHCI.
Implements support for multiblock transfers bounded
by SET_BLOCK_COUNT (CMD23).
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 70 ++---
include/linux/mmc/sdhci.h |1 +
2 files changed, 54 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 94793f2..41c987d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -822,9 +822,10 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
}
static void sdhci_set_transfer_mode(struct sdhci_host *host,
- struct mmc_data *data)
+ struct mmc_command *cmd)
{
u16 mode;
+ struct mmc_data *data = cmd-data;
if (data == NULL)
return;
@@ -832,11 +833,17 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
WARN_ON(!host-data);
mode = SDHCI_TRNS_BLK_CNT_EN;
- if (data-blocks 1) {
- if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
- mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
- else
- mode |= SDHCI_TRNS_MULTI;
+ if (mmc_op_multi(cmd-opcode) ||
+ data-blocks 1) {
+ mode |= SDHCI_TRNS_MULTI;
+
+ /*
+* If we are sending CMD23, CMD12 never gets sent
+* on successful completion (so no Auto-CMD12).
+*/
+ if (!host-mrq-sbc
+ host-flags SDHCI_ACMD12)
+ mode |= SDHCI_TRNS_ACMD12;
}
if (data-flags MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
@@ -877,7 +884,15 @@ static void sdhci_finish_data(struct sdhci_host *host)
else
data-bytes_xfered = data-blksz * data-blocks;
- if (data-stop) {
+ /*
+* Need to send CMD12 if -
+* a) open-ended multiblock transfer (no CMD23)
+* b) error in multiblock transfer
+*/
+ if (data-stop
+ (data-error ||
+!host-mrq-sbc)) {
+
/*
* The controller needs a reset of internal state machines
* upon error conditions.
@@ -933,7 +948,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
sdhci_writel(host, cmd-arg, SDHCI_ARGUMENT);
- sdhci_set_transfer_mode(host, cmd-data);
+ sdhci_set_transfer_mode(host, cmd);
if ((cmd-flags MMC_RSP_136) (cmd-flags MMC_RSP_BUSY)) {
printk(KERN_ERR %s: Unsupported response type!\n,
@@ -986,13 +1001,21 @@ static void sdhci_finish_command(struct sdhci_host *host)
host-cmd-error = 0;
- if (host-data host-data_early)
- sdhci_finish_data(host);
+ /* Finished CMD23, now send actual command. */
+ if (host-cmd == host-mrq-sbc) {
+ host-cmd = NULL;
+ sdhci_send_command(host, host-mrq-cmd);
+ } else {
- if (!host-cmd-data)
- tasklet_schedule(host-finish_tasklet);
+ /* Processed actual command. */
+ if (host-data host-data_early)
+ sdhci_finish_data(host);
- host-cmd = NULL;
+ if (!host-cmd-data)
+ tasklet_schedule(host-finish_tasklet);
+
+ host-cmd = NULL;
+ }
}
static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
@@ -1140,7 +1163,12 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
#ifndef SDHCI_USE_LEDS_CLASS
sdhci_activate_led(host);
#endif
- if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12) {
+
+ /*
+* Ensure we don't send the STOP for non-SET_BLOCK_COUNTED
+* requests if Auto-CMD12 is enabled.
+*/
+ if (!mrq-sbc (host-flags SDHCI_ACMD12)) {
if (mrq-stop) {
mrq-data-stop = NULL;
mrq-stop = NULL;
@@ -1159,8 +1187,13 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
if (!present || host-flags SDHCI_DEVICE_DEAD) {
host-mrq-cmd-error = -ENOMEDIUM;
tasklet_schedule(host-finish_tasklet);
- } else
- sdhci_send_command(host, mrq-cmd);
+ } else {
+
+ if (mrq-sbc)
+ sdhci_send_command(host, mrq-sbc);
+ else
+ sdhci_send_command(host, mrq-cmd);
+ }
mmiowb();
spin_unlock_irqrestore(host-lock, flags);
@@ -1909,7 +1942,10 @@ int sdhci_add_host(struct sdhci_host *host)
mmc-f_min = host-max_clk / SDHCI_MAX_DIV_SPEC_200;
mmc-f_max = host-max_clk;
- mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;
+ mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE
[[v4] 4/5] MMC: Block CMD23 support for UHS104/SDXC cards.
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c |9 ++---
drivers/mmc/core/sd.c|7 +++
include/linux/mmc/card.h |4
include/linux/mmc/sd.h |2 +-
4 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index b91bec2..96250cf 100755
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -863,9 +863,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
blk_queue_logical_block_size(md-queue.queue, 512);
set_capacity(md-disk, size);
- if (mmc_host_cmd23(card-host)
- mmc_card_mmc(card))
- md-flags |= MMC_BLK_CMD23;
+ if (mmc_host_cmd23(card-host)) {
+ if (mmc_card_mmc(card) ||
+ (mmc_card_sd(card)
+card-scr.cmds SD_SCR_CMD23_SUPPORT))
+ md-flags |= MMC_BLK_CMD23;
+ }
if (mmc_card_mmc(card)
md-flags MMC_BLK_CMD23
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 6dac89f..a3d771a 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -195,6 +195,13 @@ static int mmc_decode_scr(struct mmc_card *card)
else
card-erased_byte = 0x0;
+ if (scr-sda_vsn == SCR_SPEC_VER_2) {
+
+ /* Check if Physical Layer Spec v3.0X is supported. */
+ scr-sda_spec3 = UNSTUFF_BITS(resp, 47, 1);
+ if (scr-sda_spec3)
+ scr-cmds = UNSTUFF_BITS(resp, 32, 2);
+ }
return 0;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index c758181..e6b2e6f 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -67,9 +67,13 @@ struct mmc_ext_csd {
struct sd_scr {
unsigned char sda_vsn;
+ unsigned char sda_spec3;
unsigned char bus_widths;
#define SD_SCR_BUS_WIDTH_1 (10)
#define SD_SCR_BUS_WIDTH_4 (12)
+ unsigned char cmds;
+#define SD_SCR_CMD20_SUPPORT (10)
+#define SD_SCR_CMD23_SUPPORT (11)
};
struct sd_ssr {
diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
index 3fd85e0..9fe0689 100644
--- a/include/linux/mmc/sd.h
+++ b/include/linux/mmc/sd.h
@@ -59,7 +59,7 @@
#define SCR_SPEC_VER_0 0 /* Implements system specification 1.0
- 1.01 */
#define SCR_SPEC_VER_1 1 /* Implements system specification 1.10
*/
-#define SCR_SPEC_VER_2 2 /* Implements system specification 2.00
*/
+#define SCR_SPEC_VER_2 2 /* Implements system specification
2.00-3.0X */
/*
* SD bus widths
--
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
[[v4] 5/5] MMC: SDHCI AutoCMD23 support.
Enables Auto-CMD23 support where available (SDHCI 3.0 controllers)
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Cc: subha...@codeaurora.org
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 17 -
drivers/mmc/host/sdhci.h |2 ++
include/linux/mmc/sdhci.h |1 +
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 41c987d..bf9aedb 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -844,7 +844,13 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
if (!host-mrq-sbc
host-flags SDHCI_ACMD12)
mode |= SDHCI_TRNS_ACMD12;
+ else if (host-mrq-sbc
+host-flags SDHCI_ACMD23) {
+ mode |= SDHCI_TRNS_ACMD23;
+ sdhci_writel(host, host-mrq-sbc-arg,
SDHCI_ARGUMENT2);
+ }
}
+
if (data-flags MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
if (host-flags SDHCI_REQ_USE_DMA)
@@ -1189,7 +1195,7 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
tasklet_schedule(host-finish_tasklet);
} else {
- if (mrq-sbc)
+ if (mrq-sbc !(host-flags SDHCI_ACMD23))
sdhci_send_command(host, mrq-sbc);
else
sdhci_send_command(host, mrq-cmd);
@@ -1947,6 +1953,15 @@ int sdhci_add_host(struct sdhci_host *host)
if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
host-flags |= SDHCI_ACMD12;
+ /* Auto-CMD23 stuff only works in ADMA or PIO. */
+ if ((host-version == SDHCI_SPEC_300)
+ ((host-flags SDHCI_USE_ADMA) ||
+!(host-flags SDHCI_REQ_USE_DMA))) {
+ host-flags |= SDHCI_ACMD23;
+ printk(KERN_INFO %s: Auto-CMD23 available\n,
mmc_hostname(mmc));
+ } else
+ printk(KERN_INFO %s: Auto-CMD23 unavailable\n,
mmc_hostname(mmc));
+
/*
* A controller may support 8-bit width, but the board itself
* might not have the pins brought out. Boards that support
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 85750a9..2b3fb76 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -25,6 +25,7 @@
*/
#define SDHCI_DMA_ADDRESS 0x00
+#define SDHCI_ARGUMENT20x00
#define SDHCI_BLOCK_SIZE 0x04
#define SDHCI_MAKE_BLKSZ(dma, blksz) (((dma 0x7) 12) | (blksz 0xFFF))
@@ -37,6 +38,7 @@
#define SDHCI_TRNS_DMA0x01
#define SDHCI_TRNS_BLK_CNT_EN 0x02
#define SDHCI_TRNS_ACMD12 0x04
+#define SDHCI_TRNS_ACMD23 0x08
#define SDHCI_TRNS_READ 0x10
#define SDHCI_TRNS_MULTI 0x20
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index c54ac14..d91585a 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -110,6 +110,7 @@ struct sdhci_host {
#define SDHCI_REQ_USE_DMA (12) /* Use DMA for this req. */
#define SDHCI_DEVICE_DEAD (13) /* Device unresponsive */
#define SDHCI_ACMD12 (14) /* Auto CMD12 support */
+#define SDHCI_ACMD23 (15) /* Auto CMD23 support */
unsigned int version; /* SDHCI spec. version */
--
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
Re: [PATCH] mmc: block: init force_ro sysfs attribute
On Sat, Apr 23, 2011 at 10:22 AM, Rabin Vincent ra...@rab.in wrote: To avoid lockdep warnings: BUG: key dc90a520 not in .data! [ cut here ] WARNING: at /home/rabin/kernel/arm/kernel/lockdep.c:2701 sysfs_add_file_mode+0x4c/0xb0() Modules linked in: [c004b5d8] (unwind_backtrace+0x0/0xe4) from [c0074f20] (warn_slowpath_common+0x4c/0x64) [c0074f20] (warn_slowpath_common+0x4c/0x64) from [c0074f50] (warn_slowpath_null+0x18/0x1c) [c0074f50] (warn_slowpath_null+0x18/0x1c) from [c0157fec] (sysfs_add_file_mode+0x4c/0xb0) [c0157fec] (sysfs_add_file_mode+0x4c/0xb0) from [c02d61e4] (mmc_add_disk+0x40/0x64) [c02d61e4] (mmc_add_disk+0x40/0x64) from [c02d64cc] (mmc_blk_probe+0x188/0x1fc) [c02d64cc] (mmc_blk_probe+0x188/0x1fc) from [c02ce820] (mmc_bus_probe+0x14/0x18) ... Signed-off-by: Rabin Vincent ra...@rab.in --- drivers/mmc/card/block.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c index 9e30cf6..179a607 100644 --- a/drivers/mmc/card/block.c +++ b/drivers/mmc/card/block.c @@ -967,6 +967,7 @@ static int mmc_add_disk(struct mmc_blk_data *md) add_disk(md-disk); md-force_ro.show = force_ro_show; md-force_ro.store = force_ro_store; + sysfs_attr_init(md-force_ro.attr); md-force_ro.attr.name = force_ro; md-force_ro.attr.mode = S_IRUGO | S_IWUSR; ret = device_create_file(disk_to_dev(md-disk), md-force_ro); -- 1.7.4.1 Thanks for catching this. I should really fix the lockdep issues with our platform (some deadlock/hang with a watchdog reboot). A -- 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: CMD23 plumbing and support patchset.
Hi Chris, On Wed, Apr 20, 2011 at 8:44 PM, Chris Ball c...@laptop.org wrote: Hi, On Sat, Apr 16 2011, Andrei Warkentin wrote: This is the third version of the CMD23 plumbing and host driver support patch set. Changes: 1) CMD23 support (used for features such as reliable writes) is decoupled from general multiblock trans through use of a quirk for affected cards. 2) Newer Sandisk MMC products are whitelisted along with some known good ones. All other MMC products do not use CMD23 for general transfers (seems like safest choice for now). SD products unaffected. Just gave this a try on SEM04G, which is in the whitelist, but didn't see a performance increase (or decrease). What are you using for a testcase? I'm a little wary of running mmc_test on it. :) Can you give me the manufacturing date? This is pretty interesting. You can see an improvement even if you do something like time block writes (O_DIRECT | O_SYNC, of course). But after all synthetic tests I measured the time it took to do 4 SQLite insertions and saw something like 30% improvement. A -- 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: CMD23 plumbing and support patchset.
On Thu, Apr 21, 2011 at 1:29 AM, Andrei Warkentin andr...@motorola.com wrote: Hi Chris, On Wed, Apr 20, 2011 at 8:44 PM, Chris Ball c...@laptop.org wrote: Hi, On Sat, Apr 16 2011, Andrei Warkentin wrote: This is the third version of the CMD23 plumbing and host driver support patch set. Changes: 1) CMD23 support (used for features such as reliable writes) is decoupled from general multiblock trans through use of a quirk for affected cards. 2) Newer Sandisk MMC products are whitelisted along with some known good ones. All other MMC products do not use CMD23 for general transfers (seems like safest choice for now). SD products unaffected. Just gave this a try on SEM04G, which is in the whitelist, but didn't see a performance increase (or decrease). What are you using for a testcase? I'm a little wary of running mmc_test on it. :) Can you give me the manufacturing date? This is pretty interesting. You can see an improvement even if you do something like time block writes (O_DIRECT | O_SYNC, of course). But after all synthetic tests I measured the time it took to do 4 SQLite insertions and saw something like 30% improvement. And you're trying this on SDHCI I presume, right? A -- 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
[RFC] MMC: Block: Ensure hardware partitions don't mess with mmcblk device naming.
With the hardware partitions support (which represent additional logical devices
present on MMC), devidx does not correspond with index used to form
/dev/mmcblkX names. So use an additional allocated index for device names.
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 24 +---
1 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 9e30cf6..5572012 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -75,6 +75,7 @@ static int max_devices;
/* 256 minors, so at most 256 separate devices */
static DECLARE_BITMAP(dev_use, 256);
+static DECLARE_BITMAP(name_use, 256);
/*
* There is one mmc_blk_data per slot.
@@ -88,6 +89,7 @@ struct mmc_blk_data {
unsigned intusage;
unsigned intread_only;
unsigned intpart_type;
+ unsigned intname_idx;
/*
* Only set in main mmc_blk_data associated
@@ -776,6 +778,18 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
}
/*
+* !subname implies we are creating main mmc_blk_data that will be
+* associated with mmc_card with mmc_set_drvdata. Due to device
partitions,
+* devidx will not coincide with a per-physical card index anymore
+* so we keep track of a name index.
+*/
+ if (!subname)
+ md-name_idx = find_first_zero_bit(name_use, max_devices);
+ else
+ md-name_idx = ((struct mmc_blk_data *)
+ dev_to_disk(parent)-private_data)-name_idx;
+
+ /*
* Set the read-only status based on the supported commands
* and the write protect switch.
*/
@@ -820,13 +834,8 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
* messages to tell when the card is present.
*/
- if (subname)
- snprintf(md-disk-disk_name, sizeof(md-disk-disk_name),
-mmcblk%d%s,
-mmc_get_devidx(dev_to_disk(parent)), subname);
- else
- snprintf(md-disk-disk_name, sizeof(md-disk-disk_name),
-mmcblk%d, devidx);
+ snprintf(md-disk-disk_name, sizeof(md-disk-disk_name),
+mmcblk%d%s, md-name_idx, subname ? subname : );
blk_queue_logical_block_size(md-queue.queue, 512);
set_capacity(md-disk, size);
@@ -953,6 +962,7 @@ static void mmc_blk_remove_parts(struct mmc_card *card,
struct list_head *pos, *q;
struct mmc_blk_data *part_md;
+ __clear_bit(md-name_idx, name_use);
list_for_each_safe(pos, q, md-part) {
part_md = list_entry(pos, struct mmc_blk_data, part);
list_del(pos);
--
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
Re: [RFC] MMC: Block: Ensure hardware partitions don't mess with mmcblk device naming.
On Thu, Apr 21, 2011 at 1:07 AM, Andrei Warkentin andr...@motorola.com wrote: With the hardware partitions support (which represent additional logical devices present on MMC), devidx does not correspond with index used to form /dev/mmcblkX names. So use an additional allocated index for device names. Signed-off-by: Andrei Warkentin andr...@motorola.com --- drivers/mmc/card/block.c | 24 +--- 1 files changed, 17 insertions(+), 7 deletions(-) The alternative is to borrow from a previous suggestion by Stephen Warren, but instead of using card-host-index in place of devidx, use card-host-index in place of an additional name_index used to form /dev/mmcblkX device names. Using card-host-index for devidx doesn't work when you have multiple logical devices per host (because MMC card contains HW partitions). Chris, unfortunately I am working OOF for next couple of days(I am happy I took my eMMC board with me), so I was not able to test second card (laptop only has 1 slot). Tested on your mmc tree with SDHCI and my MMC08G card. Would you mind testing above RFC change? Sorry again for the regression, g. A -- 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] sdhci: add quirk to support shared bus controller
Hi,
On Thu, Apr 21, 2011 at 3:51 AM, Barry Song 21cn...@gmail.com wrote:
From: Bin Shi bin@csr.com
some controllers share data bus or other pins between
multi-controllers and need to switch the functions of shared pins
runtime
this patch requested those shared pins before actual hardware access
and release them after access
Signed-off-by: Bin Shi bin@csr.com
Cc: Binghua Duan binghua.d...@csr.com
Signed-off-by: Barry Song 21cn...@gmail.com
---
drivers/mmc/host/sdhci.c | 13 +
drivers/mmc/host/sdhci.h | 2 ++
include/linux/mmc/sdhci.h | 2 ++
3 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index f31077d..7b07152 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1379,6 +1379,13 @@ static void sdhci_tasklet_finish(unsigned long param)
sdhci_reset(host, SDHCI_RESET_DATA);
}
+ /*
+ * some controllers share data bus or other pins between
multi-controller
+ * and need to switch the function of pins runtime
+ */
+ if (host-quirks SDHCI_QUIRK_SHARED_PINS)
+ host-ops-get_shared_pins(host);
+
Why in tasklet_finish? Why not in sdhci_request?
No need to waste a quirk flag. Just invoke if method is not NULL.
Also, I would assume host-ops-get_shared_pins would need to
synchronize with other SDHCI instances
it shares the pins with. Since you do it after the host-lock (as you
should), what happens if get_shared_pins needs to wait?
Can you show the rest (sdhci driver implementing these hooks)?
host-mrq = NULL;
host-cmd = NULL;
host-data = NULL;
@@ -1391,6 +1398,12 @@ static void sdhci_tasklet_finish(unsigned long param)
spin_unlock_irqrestore(host-lock, flags);
mmc_request_done(host-mmc, mrq);
+
+ /*
+ * release shared pins so that other controllers can use them
+ */
+ if (host-quirks SDHCI_QUIRK_SHARED_PINS)
+ host-ops-get_shared_pins(host);
}
static void sdhci_timeout_timer(unsigned long data)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 85750a9..9d918a5 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -229,6 +229,8 @@ struct sdhci_ops {
void (*platform_send_init_74_clocks)(struct sdhci_host *host,
u8 power_mode);
unsigned int (*get_ro)(struct sdhci_host *host);
+ unsigned int (*get_shared_pins)(struct sdhci_host *host);
+ unsigned int (*put_shared_pins)(struct sdhci_host *host);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 83bd9f7..32ab422 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -85,6 +85,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_NO_HISPD_BIT (129)
/* Controller treats ADMA descriptors with length h incorrectly */
#define SDHCI_QUIRK_BROKEN_ADMA_ZEROLEN_DESC (130)
+/* Controller shared data bus or other pins with other controllers */
+#define SDHCI_QUIRK_SHARED_PINS (131)
int irq; /* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.7.1
--
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: CMD23 plumbing and support patchset.
On Thu, Apr 21, 2011 at 1:30 AM, Andrei Warkentin andr...@motorola.com wrote: On Thu, Apr 21, 2011 at 1:29 AM, Andrei Warkentin andr...@motorola.com wrote: Hi Chris, On Wed, Apr 20, 2011 at 8:44 PM, Chris Ball c...@laptop.org wrote: Hi, On Sat, Apr 16 2011, Andrei Warkentin wrote: This is the third version of the CMD23 plumbing and host driver support patch set. Changes: 1) CMD23 support (used for features such as reliable writes) is decoupled from general multiblock trans through use of a quirk for affected cards. 2) Newer Sandisk MMC products are whitelisted along with some known good ones. All other MMC products do not use CMD23 for general transfers (seems like safest choice for now). SD products unaffected. Just gave this a try on SEM04G, which is in the whitelist, but didn't see a performance increase (or decrease). What are you using for a testcase? I'm a little wary of running mmc_test on it. :) Can you give me the manufacturing date? This is pretty interesting. You can see an improvement even if you do something like time block writes (O_DIRECT | O_SYNC, of course). But after all synthetic tests I measured the time it took to do 4 SQLite insertions and saw something like 30% improvement. And you're trying this on SDHCI I presume, right? Is this on the same board as the other log you sent? Controller is SDHCI-PXA? If you give me /sys/block/mmcblk0/device/date, I'll investigate why this improvement isn't helping you out. A -- 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: [patchv3 4/4] MMC: MMC boot partitions support.
On Thu, Apr 21, 2011 at 12:22 AM, Chris Ball c...@laptop.org wrote: Hi, On Thu, Apr 21 2011, Philip Rakity wrote: Aren't these the hidden partitions ? Only available at boot time? Yes, it's the previously-hidden boot partitions -- Andrei's patch exposes them to Linux. I need to apply my patch to reset the boot partition -- or is that now in mmc-next Your patch is in mmc-next. to see if the problem still happens. Well, there isn't a problem per se, the system still boots fine -- the boot partitions are being exposed as the patch intends them to. I'm just curious whether it's normal for two 1MiB partitions to be created as a factory default. Chris, the partitions are always present and are a feature of the card. I ptofusely apologize for the dev_idx issue, I should have caught that immediately. A dev_idx is till assigned even though the name doesn't reflect the actual assigned dev_idx for hardware partitions. That effectively means you need to track a name_idx per main mmc_blk_data that is only used to form the naming for the device. I will send a patch in about 30 mins... A -- 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: [patchv3 2/5] MMC: Use CMD23 for multiblock transfers when we can.
On Tue, Apr 19, 2011 at 2:39 AM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 19 April 2011, Andrei Warkentin wrote: So maybe this should be a blacklist for known bad cards. And the entire support should be a default-N compile option for MMCs (not SDs). That way someone who just does an make oldconfig will see CONFIG_MMC_BLK_CMD23 - I/O performance improvement for newer eMMC cards, may cause degradation on older cards. What do you think? I'm not sure if I understand the distinction between MMC and SD here. Do you suggest we always enable it for SD but make it compile-time selected for MMC? I did, because CMD23 support on SDs is a new feature mandatory on UHS104 cards. However, I guess no matter what you do, it's going to break something. Right now I'm only aware of Toshiba perf regressions. I generally argue against compile time options. A distribution integrator needs to choose a reasonable default, and giving them an option makes it possible to get it wrong. I believe the best way would be trying to warn people against regressions while going forward with this enabled unconditionally, unless we hear back from people that actually got regressions. Alright. Then I'll just blacklist the known-affected Toshiba cards for now, and we'll keep it enabled by default. We could perhaps key enabling the feature by the production date on the card, so it only gets turned on for new cards. Unfortunately, date by itself is meaningless too (current Toshiba eMMCs) A -- 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: [patchv3 2/5] MMC: Use CMD23 for multiblock transfers when we can.
On Sun, Apr 17, 2011 at 12:23 PM, Arnd Bergmann a...@arndb.de wrote: On Saturday 16 April 2011, Andrei Warkentin wrote: @@ -982,6 +1016,26 @@ static const struct mmc_fixup blk_fixups[] = MMC_FIXUP(SEM08G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38), MMC_FIXUP(SEM16G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38), MMC_FIXUP(SEM32G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38), + + /* + * Some MMC cards experience performance degradation with CMD23 + * instead of CMD12-bounded multiblock transfers. For now we'll + * white list what's good: + * 1) Certain SanDisk eMMCs with the old MMCA manfid. + * 2) All new SanDisk products. + * + * N.B. This doesn't affect SD cards. + */ + MMC_FIXUP(CID_NAME_ANY, CID_MANFID_ANY, CID_OEMID_ANY, add_quirk_mmc, + MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM04G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM08G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM16G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM32G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM02G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(CID_NAME_ANY, 0x45, CID_OEMID_ANY, + remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + END_FIXUP }; Shouldn't this better be a blacklist for known bad cards? As far as I can tell, we should always use CMD23 where possible. I thought about this some more. In this space (eMMCs), it's still going to be up to the system integrator to evaluate the system and enable/disable certain properties (such as CMD23 use) as they make sense. What you would want to avoid, ideally, is someone compiling a kernel for their pre-2.6.40 embedded system, not knowing anything amount eMMCs and CMD23, and winding up with an I/O performance regression. So maybe this should be a blacklist for known bad cards. And the entire support should be a default-N compile option for MMCs (not SDs). That way someone who just does an make oldconfig will see CONFIG_MMC_BLK_CMD23 - I/O performance improvement for newer eMMC cards, may cause degradation on older cards. What do you think? A -- 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: [patchv3 2/5] MMC: Use CMD23 for multiblock transfers when we can.
Hi Arnd, On Sun, Apr 17, 2011 at 12:23 PM, Arnd Bergmann a...@arndb.de wrote: On Saturday 16 April 2011, Andrei Warkentin wrote: @@ -982,6 +1016,26 @@ static const struct mmc_fixup blk_fixups[] = MMC_FIXUP(SEM08G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38), MMC_FIXUP(SEM16G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38), MMC_FIXUP(SEM32G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38), + + /* + * Some MMC cards experience performance degradation with CMD23 + * instead of CMD12-bounded multiblock transfers. For now we'll + * white list what's good: + * 1) Certain SanDisk eMMCs with the old MMCA manfid. + * 2) All new SanDisk products. + * + * N.B. This doesn't affect SD cards. + */ + MMC_FIXUP(CID_NAME_ANY, CID_MANFID_ANY, CID_OEMID_ANY, add_quirk_mmc, + MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM04G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM08G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM16G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM32G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(SEM02G, 0x2, 0x100, remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + MMC_FIXUP(CID_NAME_ANY, 0x45, CID_OEMID_ANY, + remove_quirk_mmc, MMC_QUIRK_BLK_NO_CMD23), + END_FIXUP }; Shouldn't this better be a blacklist for known bad cards? As far as I can tell, we should always use CMD23 where possible. Arnd Unfortunately it's unknown yet for how many MMC cards this could be a regression. So far it's a regression for Toshiba MMC32G/MMC16G/MMC08G cards because they don't do anything with the advanced knowledge of transfer size, and not using CMD12 seems somehow to interfere with some internal optimization, resulting in a real-life degradation of about 8-10%. According to Sandisk, all their newer products (MMC spec 4.3+) should be good (with new manfid), and I am stilll waiting for specifics for older cards. I (well, and another person at MMI) are collecting some more data for more newer eMMC devices to get a clearer picture, and I am trying to get word on whether newer Toshiba devices should work better with CMD23. A -- 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: [patchv3 5/5] MMC: SDHCI AutoCMD23 support.
Hi Arnd, On Sun, Apr 17, 2011 at 12:25 PM, Arnd Bergmann a...@arndb.de wrote: On Saturday 16 April 2011, Andrei Warkentin wrote: @@ -68,6 +68,15 @@ config MMC_SDHCI_PCI If unsure, say N. +config MMC_SDHCI_AUTO_CMD23 + tristate SDHCI 3.0 Auto-CMD23 support (EXPERIMENTAL) + depends on MMC_SDHCI EXPERIMENTAL + help + This enables the Auto-CMD23 optimization for multiblock + transfers where a CMD23 would be sent + + If unsure, say N. + config MMC_RICOH_MMC bool Ricoh MMC Controller Disabler (EXPERIMENTAL) depends on MMC_SDHCI_PCI Does this need to be a Konfig option? We are already asking too many questions here IMHO. Sorry, I should have clarified - I made this an experimental option because I couldn't vouch for the correct functionality (no SDHCI 3.0 hardware around me) and I posted it only because Arindam wanted to try it out and see if it worked alright. As soon as we're clear it works fine I'll take the Kconfig out. A -- 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 v3 01/12] mmc: sdhci: add support for auto CMD23
On Sat, Apr 16, 2011 at 1:25 AM, Nath, Arindam arindam.n...@amd.com wrote: Hi Subhash, Please keep in mind that my patch _only_ adds support for Auto CMD23, and not CMD23. CMD23 support can be made part of block layer, but Auto CMD23 is a feature as per the Host Controller Spec v3.00. So my patch takes care of the second case. All Auto CMD23 means is that the host sends the command automatically, instead of having some code do it manually. Auto CMD23 makes no sense if the block layer doesn't want or need CMD23. Let me explain: 1) Not all cards support CMD23 2) Not all cards that do support CMD23 want to use it for regular multiblock transfers for performance reasons 3) If you disregard my current patch set, then your changes, if ever enabled for MMCs, will actually break reliable writes because current block code sent CMD23 manually (but the CMD23 support patch set fixed that) That means you can't just enable it in the host just because you feel like it. Your current host changes make the host aware of the card capabilities, and then force policy. This violates layering and makes everything an unmaintainable mess. Given the existing work for plumbing normal CMD23 support, you should take advantage of that. Your current patch does not integrate well with it, and I've tried to make it specifically very easy to enable enhancements like Auto-CMD23. Let me help you out: 1) If you have mmc_request-sbc - then you should set your Auto-CMD23 flag and not send mmc_request-sbc. 2) You can forget your save stop command. The current code should function correctly as long as you can detect the error condition as set data-error appropriately. But of course, feel free to change it if you see fit. Right now the stop command is only sent if - a) No mmc_request-sbc so this must have been an open-ended multiblock transfer b) An error condition detected in data transfer, so the stop must be sent anyway Anyway I'm at your disposal to answer your questions and make sure you can implement AutoCMD23 support on top of existing MMC subsystem changes. A -- 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 v3 01/12] mmc: sdhci: add support for auto CMD23
On Sat, Apr 16, 2011 at 1:43 AM, Nath, Arindam arindam.n...@amd.com wrote: and then sending the CMD23 for multi block read/write. MMC cards also supports CMD23 so in that case again you have to check MMC EXT_CSD register for CMD23 Yes, you are right. I followed the Physical Layer Spec v3.01 as is, so in case the support is needed for MMC cards, we will need to take care of that too. It's already done. In the block layer. All you need to do is honor mmc_request-sbc and set Auto-CMD23 and the CMD23 argument. support. All this logic is better be in core/block layer and let core/block layer inform host controller when to send CMD23 and when not to. Well in that case, Auto CMD23 will never make sense. I am unsure why you think that. All Auto CMD23 means is that instead of manually sending CMD23 (and incurring the extra interrupt penalty), I have the host automatically do it. But this feature should only be enabled when upper layers care to enabled it. This is what the CMD23 support plumbed in. A -- 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 v3 01/12] mmc: sdhci: add support for auto CMD23
On Sat, Apr 16, 2011 at 12:25 AM, Nath, Arindam arindam.n...@amd.com wrote: Hi Andrei, I saw in one of the community threads that you also have a patch ready for supporting Auto CMD23 for SDHCI. Can you share the same with us? I would like to take a look at your patch first before deciding whether it would make sense for controllers which comply with Host Controller Spec v3.00. Will send updated patch set in a few. You and Subhash are on the Cc. Once again, the Auto-CMD23 is completely untested. I would be extremely grateful if you can verify it. Is there any kind of error injection mechanism you guys use to verify the error paths for Auto 12/23? By the way - + /* If the host can perform ADMA operation, we reset SDMA flag */ + if (host-flags SDHCI_USE_ADMA) + host-flags = ~SDHCI_USE_SDMA; This seems completely unnecessary, as the code already prefers ADMA to SDMA. What do you think? A -- 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
CMD23 plumbing and support patchset.
Dear Group, This is the third version of the CMD23 plumbing and host driver support patch set. Changes: 1) CMD23 support (used for features such as reliable writes) is decoupled from general multiblock trans through use of a quirk for affected cards. 2) Newer Sandisk MMC products are whitelisted along with some known good ones. All other MMC products do not use CMD23 for general transfers (seems like safest choice for now). SD products unaffected. 3) Small fix for interaction with Auto-CMD12 (and resulting cleanup of Auto-CMD12 SDHCI capability) 4) Completely experimental (and untested) Auto-CMD23 support, for Arindam to look over (Hi!). Table of Contents: [patchv3 1/5] MMC: Add/remove quirks conditional support. [patchv3 2/5] MMC: Use CMD23 for multiblock transfers when we can. [patchv3 3/5] MMC: Implement MMC_CAP_CMD23 for SDHCI. [patchv3 4/5] MMC: Block CMD23 support for UHS104/SDXC cards. [patchv3 5/5] MMC: SDHCI AutoCMD23 support. Thanks, A -- 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
[patchv3 1/5] MMC: Add/remove quirks conditional support.
Conditional add/remove quirks for MMC and SD.
Cc: c...@laptop.org
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
include/linux/mmc/card.h | 40
1 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 72a9868..6a4ed2a 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -233,16 +233,14 @@ struct mmc_fixup {
card-cid.month)
/*
- * This hook just adds a quirk unconditionally.
+ * Unconditionally quirk add/remove.
*/
+
static inline void __maybe_unused add_quirk(struct mmc_card *card, int data)
{
card-quirks |= data;
}
-/*
- * This hook just removes a quirk unconditionally.
- */
static inline void __maybe_unused remove_quirk(struct mmc_card *card, int data)
{
card-quirks = ~data;
@@ -264,6 +262,40 @@ static inline void __maybe_unused remove_quirk(struct
mmc_card *card, int data)
#define mmc_card_set_blockaddr(c) ((c)-state |= MMC_STATE_BLOCKADDR)
#define mmc_card_set_ddr_mode(c) ((c)-state |= MMC_STATE_HIGHSPEED_DDR)
+/*
+ * Quirk add/remove for MMC products.
+ */
+
+static inline void __maybe_unused add_quirk_mmc(struct mmc_card *card, int
data)
+{
+ if (mmc_card_mmc(card))
+ card-quirks |= data;
+}
+
+static inline void __maybe_unused remove_quirk_mmc(struct mmc_card *card,
+ int data)
+{
+ if (mmc_card_mmc(card))
+ card-quirks = ~data;
+}
+
+/*
+ * Quirk add/remove for SD products.
+ */
+
+static inline void __maybe_unused add_quirk_sd(struct mmc_card *card, int data)
+{
+ if (mmc_card_sd(card))
+ card-quirks |= data;
+}
+
+static inline void __maybe_unused remove_quirk_sd(struct mmc_card *card,
+ int data)
+{
+ if (mmc_card_sd(card))
+ card-quirks = ~data;
+}
+
static inline int mmc_card_lenient_fn0(const struct mmc_card *c)
{
return c-quirks MMC_QUIRK_LENIENT_FN0;
--
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
[patchv3 2/5] MMC: Use CMD23 for multiblock transfers when we can.
CMD23-prefixed instead of open-ended multiblock transfers
have a performance advantage on some MMC cards.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 114 ++
include/linux/mmc/card.h |1 +
include/linux/mmc/core.h |1 +
include/linux/mmc/host.h |6 ++
include/linux/mmc/mmc.h |6 ++
5 files changed, 98 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c209953..4b1a58e 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -55,10 +55,6 @@ MODULE_ALIAS(mmc:block);
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
-#define REL_WRITES_SUPPORTED(card) (mmc_card_mmc((card)) \
-(((card)-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN) || \
- ((card)-ext_csd.rel_sectors)))
-
static DEFINE_MUTEX(block_mutex);
/*
@@ -85,6 +81,10 @@ struct mmc_blk_data {
struct mmc_queue queue;
struct list_head part;
+ unsigned intflags;
+#define MMC_BLK_CMD23 (1 0)/* Can do SET_BLOCK_COUNT for
multiblock */
+#define MMC_BLK_REL_WR (1 1)/* MMC Reliable write support */
+
unsigned intusage;
unsigned intread_only;
unsigned intpart_type;
@@ -225,6 +225,7 @@ static const struct block_device_operations mmc_bdops = {
struct mmc_blk_request {
struct mmc_request mrq;
+ struct mmc_command sbc;
struct mmc_command cmd;
struct mmc_command stop;
struct mmc_data data;
@@ -455,13 +456,10 @@ static int mmc_blk_issue_flush(struct mmc_queue *mq,
struct request *req)
* reliable write can handle, thus finish the request in
* partial completions.
*/
-static inline int mmc_apply_rel_rw(struct mmc_blk_request *brq,
- struct mmc_card *card,
- struct request *req)
+static inline void mmc_apply_rel_rw(struct mmc_blk_request *brq,
+ struct mmc_card *card,
+ struct request *req)
{
- int err;
- struct mmc_command set_count;
-
if (!(card-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN)) {
/* Legacy mode imposes restrictions on transfers. */
if (!IS_ALIGNED(brq-cmd.arg, card-ext_csd.rel_sectors))
@@ -472,16 +470,6 @@ static inline int mmc_apply_rel_rw(struct mmc_blk_request
*brq,
else if (brq-data.blocks card-ext_csd.rel_sectors)
brq-data.blocks = 1;
}
-
- memset(set_count, 0, sizeof(struct mmc_command));
- set_count.opcode = MMC_SET_BLOCK_COUNT;
- set_count.arg = brq-data.blocks | (1 31);
- set_count.flags = MMC_RSP_R1 | MMC_CMD_AC;
- err = mmc_wait_for_cmd(card-host, set_count, 0);
- if (err)
- printk(KERN_ERR %s: error %d SET_BLOCK_COUNT\n,
- req-rq_disk-disk_name, err);
- return err;
}
static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *req)
@@ -498,7 +486,7 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct
request *req)
bool do_rel_wr = ((req-cmd_flags REQ_FUA) ||
(req-cmd_flags REQ_META))
(rq_data_dir(req) == WRITE)
- REL_WRITES_SUPPORTED(card);
+ (md-flags MMC_BLK_REL_WR);
do {
struct mmc_command cmd;
@@ -536,11 +524,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
if (brq.data.blocks 1 || do_rel_wr) {
/* SPI multiblock writes terminate using a special
-* token, not a STOP_TRANSMISSION request. Reliable
-* writes use SET_BLOCK_COUNT and do not use a
-* STOP_TRANSMISSION request either.
+* token, not a STOP_TRANSMISSION request.
*/
- if ((!mmc_host_is_spi(card-host) !do_rel_wr) ||
+ if (!mmc_host_is_spi(card-host) ||
rq_data_dir(req) == READ)
brq.mrq.stop = brq.stop;
readcmd = MMC_READ_MULTIPLE_BLOCK;
@@ -558,8 +544,37 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
brq.data.flags |= MMC_DATA_WRITE;
}
- if (do_rel_wr mmc_apply_rel_rw(brq, card, req))
- goto cmd_err;
+ if (do_rel_wr)
+ mmc_apply_rel_rw(brq, card, req);
+
+ /*
+* Pre-defined multi-block transfers are preferable to
+* open ended-ones (and necessary for reliable writes).
+* However
[patchv3 4/5] MMC: Block CMD23 support for UHS104/SDXC cards.
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c |9 ++---
drivers/mmc/core/sd.c|1 +
include/linux/mmc/card.h |1 +
include/linux/mmc/sd.h |1 +
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 4b1a58e..23da6e6 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -851,9 +851,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
blk_queue_logical_block_size(md-queue.queue, 512);
set_capacity(md-disk, size);
- if (mmc_host_cmd23(card-host)
- mmc_card_mmc(card))
- md-flags |= MMC_BLK_CMD23;
+ if (mmc_host_cmd23(card-host)) {
+ if (mmc_card_mmc(card) ||
+ (mmc_card_sd(card)
+card-scr.cmds SCR_CMDS_CMD23))
+ md-flags |= MMC_BLK_CMD23;
+ }
if (mmc_card_mmc(card)
md-flags MMC_BLK_CMD23
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 6dac89f..16a1f10 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -195,6 +195,7 @@ static int mmc_decode_scr(struct mmc_card *card)
else
card-erased_byte = 0x0;
+ scr-cmds = UNSTUFF_BITS(resp, 32, 2);
return 0;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index c758181..b33186a 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -70,6 +70,7 @@ struct sd_scr {
unsigned char bus_widths;
#define SD_SCR_BUS_WIDTH_1 (10)
#define SD_SCR_BUS_WIDTH_4 (12)
+ unsigned char cmds;
};
struct sd_ssr {
diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
index 3fd85e0..81ba37b 100644
--- a/include/linux/mmc/sd.h
+++ b/include/linux/mmc/sd.h
@@ -60,6 +60,7 @@
#define SCR_SPEC_VER_0 0 /* Implements system specification 1.0
- 1.01 */
#define SCR_SPEC_VER_1 1 /* Implements system specification 1.10
*/
#define SCR_SPEC_VER_2 2 /* Implements system specification 2.00
*/
+#define SCR_CMDS_CMD23 (1 1) /* Supports CMD23 */
/*
* SD bus widths
--
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
[patchv3 5/5] MMC: SDHCI AutoCMD23 support.
Enables Auto-CMD23 support where available (SDHCI 3.0 controllers)
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Cc: subha...@codeaurora.org
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/Kconfig |9 +
drivers/mmc/host/sdhci.c | 16 +++-
drivers/mmc/host/sdhci.h |2 ++
include/linux/mmc/sdhci.h |1 +
4 files changed, 27 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index b981715..d4e5658 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -68,6 +68,15 @@ config MMC_SDHCI_PCI
If unsure, say N.
+config MMC_SDHCI_AUTO_CMD23
+ tristate SDHCI 3.0 Auto-CMD23 support (EXPERIMENTAL)
+ depends on MMC_SDHCI EXPERIMENTAL
+ help
+ This enables the Auto-CMD23 optimization for multiblock
+ transfers where a CMD23 would be sent
+
+ If unsure, say N.
+
config MMC_RICOH_MMC
bool Ricoh MMC Controller Disabler (EXPERIMENTAL)
depends on MMC_SDHCI_PCI
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 41c987d..e7a38b6 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -844,7 +844,13 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
if (!host-mrq-sbc
host-flags SDHCI_ACMD12)
mode |= SDHCI_TRNS_ACMD12;
+ else if (host-mrq-sbc
+host-flags SDHCI_ACMD23) {
+ mode |= SDHCI_TRNS_ACMD23;
+ sdhci_writel(host, data-blocks, SDHCI_ARGUMENT2);
+ }
}
+
if (data-flags MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
if (host-flags SDHCI_REQ_USE_DMA)
@@ -1189,7 +1195,7 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
tasklet_schedule(host-finish_tasklet);
} else {
- if (mrq-sbc)
+ if (mrq-sbc !(host-flags SDHCI_ACMD23))
sdhci_send_command(host, mrq-sbc);
else
sdhci_send_command(host, mrq-cmd);
@@ -1947,6 +1953,14 @@ int sdhci_add_host(struct sdhci_host *host)
if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
host-flags |= SDHCI_ACMD12;
+#ifdef CONFIG_MMC_SDHCI_CMD23
+ /* Auto-CMD23 stuff only works in ADMA or PIO. */
+ if ((host-version == SDHCI_SPEC_300)
+ ((host-flags SDHCI_USE_ADMA) ||
+!(host-flags SDHCI_REQ_USE_DMA)))
+ host-flags |= SDHCI_ACMD23;
+#endif
+
/*
* A controller may support 8-bit width, but the board itself
* might not have the pins brought out. Boards that support
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 85750a9..2b3fb76 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -25,6 +25,7 @@
*/
#define SDHCI_DMA_ADDRESS 0x00
+#define SDHCI_ARGUMENT20x00
#define SDHCI_BLOCK_SIZE 0x04
#define SDHCI_MAKE_BLKSZ(dma, blksz) (((dma 0x7) 12) | (blksz 0xFFF))
@@ -37,6 +38,7 @@
#define SDHCI_TRNS_DMA0x01
#define SDHCI_TRNS_BLK_CNT_EN 0x02
#define SDHCI_TRNS_ACMD12 0x04
+#define SDHCI_TRNS_ACMD23 0x08
#define SDHCI_TRNS_READ 0x10
#define SDHCI_TRNS_MULTI 0x20
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index c54ac14..d91585a 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -110,6 +110,7 @@ struct sdhci_host {
#define SDHCI_REQ_USE_DMA (12) /* Use DMA for this req. */
#define SDHCI_DEVICE_DEAD (13) /* Device unresponsive */
#define SDHCI_ACMD12 (14) /* Auto CMD12 support */
+#define SDHCI_ACMD23 (15) /* Auto CMD23 support */
unsigned int version; /* SDHCI spec. version */
--
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
Re: [PATCH v3 01/12] mmc: sdhci: add support for auto CMD23
On Sat, Apr 16, 2011 at 4:40 AM, Nath, Arindam arindam.n...@amd.com wrote: Hi Andrei, -Original Message- From: Andrei Warkentin [mailto:andr...@motorola.com] Sent: Saturday, April 16, 2011 2:38 PM To: Nath, Arindam Cc: linux-mmc@vger.kernel.org Subject: Re: [PATCH v3 01/12] mmc: sdhci: add support for auto CMD23 On Sat, Apr 16, 2011 at 12:25 AM, Nath, Arindam arindam.n...@amd.com wrote: Hi Andrei, I saw in one of the community threads that you also have a patch ready for supporting Auto CMD23 for SDHCI. Can you share the same with us? I would like to take a look at your patch first before deciding whether it would make sense for controllers which comply with Host Controller Spec v3.00. Will send updated patch set in a few. You and Subhash are on the Cc. Once again, the Auto-CMD23 is completely untested. I would be extremely grateful if you can verify it. Yes, I can do that. On that note, I have a suggestion. Since the Auto CMD23 feature is separate and none of my other patches depend on this, I would rather re-submit V3 patches except for the Auto CMD23 feature. Then once your patches have been accepted and tested, we can enable Auto CMD23 feature in the kernel. Let me know what you think. Sure, great! I've just mailed the v3 of my patch set, so I'm looking forward to any comments you have and any problems you uncover with Auto-CMD23. Is there any kind of error injection mechanism you guys use to verify the error paths for Auto 12/23? None in particular. I am starting to wish I had a fake MMC or SD card I could program to fail in various spectacular ways... A -- 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] MMC: Block CMD23 support for UHS104/SDXC cards.
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c |9 ++---
drivers/mmc/core/sd.c|7 +++
include/linux/mmc/card.h |4
include/linux/mmc/sd.h |2 +-
4 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 4b1a58e..520529a 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -851,9 +851,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
blk_queue_logical_block_size(md-queue.queue, 512);
set_capacity(md-disk, size);
- if (mmc_host_cmd23(card-host)
- mmc_card_mmc(card))
- md-flags |= MMC_BLK_CMD23;
+ if (mmc_host_cmd23(card-host)) {
+ if (mmc_card_mmc(card) ||
+ (mmc_card_sd(card)
+card-scr.cmds SD_SCR_CMD23_SUPPORT))
+ md-flags |= MMC_BLK_CMD23;
+ }
if (mmc_card_mmc(card)
md-flags MMC_BLK_CMD23
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 6dac89f..a3d771a 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -195,6 +195,13 @@ static int mmc_decode_scr(struct mmc_card *card)
else
card-erased_byte = 0x0;
+ if (scr-sda_vsn == SCR_SPEC_VER_2) {
+
+ /* Check if Physical Layer Spec v3.0X is supported. */
+ scr-sda_spec3 = UNSTUFF_BITS(resp, 47, 1);
+ if (scr-sda_spec3)
+ scr-cmds = UNSTUFF_BITS(resp, 32, 2);
+ }
return 0;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index c758181..e6b2e6f 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -67,9 +67,13 @@ struct mmc_ext_csd {
struct sd_scr {
unsigned char sda_vsn;
+ unsigned char sda_spec3;
unsigned char bus_widths;
#define SD_SCR_BUS_WIDTH_1 (10)
#define SD_SCR_BUS_WIDTH_4 (12)
+ unsigned char cmds;
+#define SD_SCR_CMD20_SUPPORT (10)
+#define SD_SCR_CMD23_SUPPORT (11)
};
struct sd_ssr {
diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
index 3fd85e0..9fe0689 100644
--- a/include/linux/mmc/sd.h
+++ b/include/linux/mmc/sd.h
@@ -59,7 +59,7 @@
#define SCR_SPEC_VER_0 0 /* Implements system specification 1.0
- 1.01 */
#define SCR_SPEC_VER_1 1 /* Implements system specification 1.10
*/
-#define SCR_SPEC_VER_2 2 /* Implements system specification 2.00
*/
+#define SCR_SPEC_VER_2 2 /* Implements system specification
2.00-3.0X */
/*
* SD bus widths
--
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
Re: SET_BLOCK_COUNT-bounded multiblock transfers
On Thu, Apr 14, 2011 at 6:18 PM, Chris Ball c...@laptop.org wrote: If we've seen a card that freaks out and loses significant bandwidth, that would be a good reason to start with a whitelist. If all the data we have suggests that it's performance-wise either a win or a no-op, that's a fine reason to push it to mmc-next with a blacklist approach and change our minds later if our knowledge gets updated. Does that help? Yes, it does, thanks! Basically so far - (a) amazing boost for Sandisk eMMCs (b) synthetic tests showed no-op for Toshiba (a derivative of Arnd's flashbench, I'll put it up on GitHub as soon as my hands get to it), but more realistic test (via SQLite transactions on top of fs) showed slight deterioration. I'm bringing it up with the vendor to get a clear picture why and if they are doing anything to address it. (c) I am going to try to dig up some discrete MMCs (hard beasts to come by these days) and try with that. (d) I am going to dig up a few SDXCs and try them out. My current theory is that the CMD23 for multiblock should have no effect on the really braindead cards, and could have deterioration on cards that somehow optimize the CMD12 path (for example, the T eMMC optimize consecutive multiblock writes). At any rate, I'll decouple CMD23 support from multiblock CMD23 use... Yunpeng, I'm curious, what vendors did you have in mind when you suggested in your original email to use the CMD23 multiblock stuff? Thanks again, A -- 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: SET_BLOCK_COUNT-bounded multiblock transfers
+Arindam (This is the patch set I mentioned) On Fri, Apr 15, 2011 at 2:10 AM, Andrei Warkentin andr...@motorola.com wrote: On Thu, Apr 14, 2011 at 6:18 PM, Chris Ball c...@laptop.org wrote: If we've seen a card that freaks out and loses significant bandwidth, that would be a good reason to start with a whitelist. If all the data we have suggests that it's performance-wise either a win or a no-op, that's a fine reason to push it to mmc-next with a blacklist approach and change our minds later if our knowledge gets updated. Does that help? Yes, it does, thanks! Basically so far - (a) amazing boost for Sandisk eMMCs (b) synthetic tests showed no-op for Toshiba (a derivative of Arnd's flashbench, I'll put it up on GitHub as soon as my hands get to it), but more realistic test (via SQLite transactions on top of fs) showed slight deterioration. I'm bringing it up with the vendor to get a clear picture why and if they are doing anything to address it. (c) I am going to try to dig up some discrete MMCs (hard beasts to come by these days) and try with that. (d) I am going to dig up a few SDXCs and try them out. My current theory is that the CMD23 for multiblock should have no effect on the really braindead cards, and could have deterioration on cards that somehow optimize the CMD12 path (for example, the T eMMC optimize consecutive multiblock writes). At any rate, I'll decouple CMD23 support from multiblock CMD23 use... Yunpeng, I'm curious, what vendors did you have in mind when you suggested in your original email to use the CMD23 multiblock stuff? Thanks again, A -- 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] MMC: fix a race between card-detect rescan and clock-gate work instances
On Fri, Apr 15, 2011 at 1:08 PM, Guennadi Liakhovetski
g.liakhovet...@gmx.de wrote:
Currently there is a race in the MMC core between a card-detect
rescan work and the clock-gating work, scheduled from a command
completion. Fix it by removing the dedicated clock-gating mutex and
using the MMC standard locking mechanism instead.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Simon Horman ho...@verge.net.au
Cc: Magnus Damm d...@opensource.se
Cc: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/core/host.c | 9 -
include/linux/mmc/host.h | 1 -
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 461e6a1..2b200c1 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -94,7 +94,7 @@ static void mmc_host_clk_gate_delayed(struct mmc_host *host)
spin_unlock_irqrestore(host-clk_lock, flags);
return;
}
- mutex_lock(host-clk_gate_mutex);
+ mmc_claim_host(host);
spin_lock_irqsave(host-clk_lock, flags);
if (!host-clk_requests) {
spin_unlock_irqrestore(host-clk_lock, flags);
@@ -104,7 +104,7 @@ static void mmc_host_clk_gate_delayed(struct mmc_host
*host)
pr_debug(%s: gated MCI clock\n, mmc_hostname(host));
}
spin_unlock_irqrestore(host-clk_lock, flags);
- mutex_unlock(host-clk_gate_mutex);
+ mmc_release_host(host);
}
/*
@@ -130,7 +130,7 @@ void mmc_host_clk_ungate(struct mmc_host *host)
{
unsigned long flags;
- mutex_lock(host-clk_gate_mutex);
+ mmc_claim_host(host);
spin_lock_irqsave(host-clk_lock, flags);
if (host-clk_gated) {
spin_unlock_irqrestore(host-clk_lock, flags);
@@ -140,7 +140,7 @@ void mmc_host_clk_ungate(struct mmc_host *host)
}
host-clk_requests++;
spin_unlock_irqrestore(host-clk_lock, flags);
- mutex_unlock(host-clk_gate_mutex);
+ mmc_release_host(host);
}
/**
@@ -215,7 +215,6 @@ static inline void mmc_host_clk_init(struct mmc_host
*host)
host-clk_gated = false;
INIT_WORK(host-clk_gate_work, mmc_host_clk_gate_work);
spin_lock_init(host-clk_lock);
- mutex_init(host-clk_gate_mutex);
}
/**
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index bcb793e..eb792cb 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -183,7 +183,6 @@ struct mmc_host {
struct work_struct clk_gate_work; /* delayed clock gate */
unsigned int clk_old; /* old clock value cache */
spinlock_t clk_lock; /* lock for clk fields */
- struct mutex clk_gate_mutex; /* mutex for clock gating */
#endif
/* host specific block data */
--
1.7.2.5
I've looked at this when Guennadi sent the original email and it looks
good to me FWIW.
A
--
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 v3 01/12] mmc: sdhci: add support for auto CMD23
+linux-mmc On Fri, Apr 15, 2011 at 3:03 PM, Andrei Warkentin andr...@motorola.com wrote: On Fri, Apr 15, 2011 at 1:57 PM, Andrei Warkentin andr...@motorola.com wrote: Hi Arindam, On Fri, Apr 15, 2011 at 12:34 PM, Nath, Arindam arindam.n...@amd.com wrote: Hi Andrei, I've recently posted changes relating to CMD23 support in block layer. Effectively, in order to support hosts with and without Auto-CMD23 (and with proper error handling) there is a new MMC_CAP_CMD23 for the host, and a new field mmc_command sbc inside the mmc_request. I also have a patch enabling CMD23 use with an SDHCI host ( 3.00). Could you be so kind as to rebase this patch on top of that? You're doing a lot of things here that you really shouldn't be (like enforcing policy on what gets sent to cards, knowing what's connected to the host, conflicting with reliable writes code if Auto-CMD23 was enabled for MMCs, not supporting MMCs which always have SET_BLOCK_COUNT). Our Host Controller is complaint to the Host Controller Spec v3.00, and since Auto CMD23 is a feature added to the HC, I thought it would be better to make this feature part of sdhci and not the core/block layer. But in case you want Auto CMD23 to be implemented in a different way, it would rather be great if you help me implement in your own way, and then probably based on community suggestions, we can keep either of the patch. Let me clarify: 1) Sending CMD23 on multiblock transfers is not a an SDHCI specific feature. It's a feature of MMC cards and SD cards operating at UHS104 or greater. 2) CMD23-bounded multi block writes are a generic problem already - eMMC reliable writes, for example. 3) CMD23 is not bound to any specific controller - so having generic code to allow execution of CMD23 will speed up transfers (and enable certain features) on any host. 4) Auto-CMD is a specific SDHCI enhancement, meant to reduce overhead of sending CMD23. 5) Host controller has to be aware of CMD23 sending, because on an error STOP has to be sent, and without error, no STOP has to be sent. You are in a unique position where you have functional SDHCI 3.0 hardware and are able to test Auto-CMD23. Please look at the patch set I sent - it should be trivial to extend current SDHCI patch to use Auto-CMD23 when possible instead of sending mmc_request-sbc. Basically, I have a generic improvement that affects all host controllers. Auto-CMD23 is an optimization of that for SDHCI 3.0. Your current patch to enable Auto-CMD23 is not useful as far as non-SD cards are concerned and you push way to much policy and non-host-related complexity into it. Thanks, A More clarification: The block layer patch may change slightly (whitelisting/blacklisting certain MMC devices for using CMD23 for multiblock transfers), but the changes to mmc_request and SDHCI are not. So feel free to rebase it without waiting for anything. If you need help, I will gladly help you, but keep in mind I don't have SDHCI 3.0 hardware around. Thanks, A -- 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
[patchv2 1/3] MMC: Use CMD23 for multiblock transfers when we can.
CMD23-prefixed instead of open-ended multiblock transfers
have a performance advantage on some MMC cards.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 112 +
include/linux/mmc/card.h |1 +
include/linux/mmc/core.h |1 +
include/linux/mmc/host.h |6 +++
include/linux/mmc/mmc.h |6 +++
5 files changed, 96 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c209953..bba0888 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -55,10 +55,6 @@ MODULE_ALIAS(mmc:block);
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
-#define REL_WRITES_SUPPORTED(card) (mmc_card_mmc((card)) \
-(((card)-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN) || \
- ((card)-ext_csd.rel_sectors)))
-
static DEFINE_MUTEX(block_mutex);
/*
@@ -85,6 +81,10 @@ struct mmc_blk_data {
struct mmc_queue queue;
struct list_head part;
+ unsigned intflags;
+#define MMC_BLK_CMD23 (1 0)/* Can do SET_BLOCK_COUNT for
multiblock */
+#define MMC_BLK_REL_WR (1 1)/* MMC Reliable write support */
+
unsigned intusage;
unsigned intread_only;
unsigned intpart_type;
@@ -225,6 +225,7 @@ static const struct block_device_operations mmc_bdops = {
struct mmc_blk_request {
struct mmc_request mrq;
+ struct mmc_command sbc;
struct mmc_command cmd;
struct mmc_command stop;
struct mmc_data data;
@@ -455,13 +456,10 @@ static int mmc_blk_issue_flush(struct mmc_queue *mq,
struct request *req)
* reliable write can handle, thus finish the request in
* partial completions.
*/
-static inline int mmc_apply_rel_rw(struct mmc_blk_request *brq,
- struct mmc_card *card,
- struct request *req)
+static inline void mmc_apply_rel_rw(struct mmc_blk_request *brq,
+ struct mmc_card *card,
+ struct request *req)
{
- int err;
- struct mmc_command set_count;
-
if (!(card-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN)) {
/* Legacy mode imposes restrictions on transfers. */
if (!IS_ALIGNED(brq-cmd.arg, card-ext_csd.rel_sectors))
@@ -472,16 +470,6 @@ static inline int mmc_apply_rel_rw(struct mmc_blk_request
*brq,
else if (brq-data.blocks card-ext_csd.rel_sectors)
brq-data.blocks = 1;
}
-
- memset(set_count, 0, sizeof(struct mmc_command));
- set_count.opcode = MMC_SET_BLOCK_COUNT;
- set_count.arg = brq-data.blocks | (1 31);
- set_count.flags = MMC_RSP_R1 | MMC_CMD_AC;
- err = mmc_wait_for_cmd(card-host, set_count, 0);
- if (err)
- printk(KERN_ERR %s: error %d SET_BLOCK_COUNT\n,
- req-rq_disk-disk_name, err);
- return err;
}
static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *req)
@@ -498,7 +486,7 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct
request *req)
bool do_rel_wr = ((req-cmd_flags REQ_FUA) ||
(req-cmd_flags REQ_META))
(rq_data_dir(req) == WRITE)
- REL_WRITES_SUPPORTED(card);
+ (md-flags MMC_BLK_REL_WR);
do {
struct mmc_command cmd;
@@ -536,11 +524,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
if (brq.data.blocks 1 || do_rel_wr) {
/* SPI multiblock writes terminate using a special
-* token, not a STOP_TRANSMISSION request. Reliable
-* writes use SET_BLOCK_COUNT and do not use a
-* STOP_TRANSMISSION request either.
+* token, not a STOP_TRANSMISSION request.
*/
- if ((!mmc_host_is_spi(card-host) !do_rel_wr) ||
+ if (!mmc_host_is_spi(card-host) ||
rq_data_dir(req) == READ)
brq.mrq.stop = brq.stop;
readcmd = MMC_READ_MULTIPLE_BLOCK;
@@ -558,8 +544,37 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
brq.data.flags |= MMC_DATA_WRITE;
}
- if (do_rel_wr mmc_apply_rel_rw(brq, card, req))
- goto cmd_err;
+ if (do_rel_wr)
+ mmc_apply_rel_rw(brq, card, req);
+
+ /*
+* Pre-defined multi-block transfers are preferable to
+* open ended-ones (and necessary for reliable writes).
+* However
[patchv2 2/3] MMC: Implement MMC_CAP_CMD23 for SDHCI.
Implements support for multiblock transfers bounded
by SET_BLOCK_COUNT (CMD23).
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 60 +
1 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 94793f2..0b71ce8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -822,9 +822,10 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
}
static void sdhci_set_transfer_mode(struct sdhci_host *host,
- struct mmc_data *data)
+ struct mmc_command *cmd)
{
u16 mode;
+ struct mmc_data *data = cmd-data;
if (data == NULL)
return;
@@ -832,11 +833,17 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
WARN_ON(!host-data);
mode = SDHCI_TRNS_BLK_CNT_EN;
- if (data-blocks 1) {
- if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
- mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
- else
- mode |= SDHCI_TRNS_MULTI;
+ if (mmc_op_multi(cmd-opcode) ||
+ data-blocks 1) {
+ mode |= SDHCI_TRNS_MULTI;
+
+ /*
+* If we are sending CMD23, CMD12 never gets sent
+* on successful completion.
+*/
+ if (!host-mrq-sbc
+ host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
+ mode |= SDHCI_TRNS_ACMD12;
}
if (data-flags MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
@@ -877,7 +884,15 @@ static void sdhci_finish_data(struct sdhci_host *host)
else
data-bytes_xfered = data-blksz * data-blocks;
- if (data-stop) {
+ /*
+* Need to send CMD12 if -
+* a) open-ended multiblock transfer (no CMD23)
+* b) error in multiblock transfer
+*/
+ if (data-stop
+ (data-error ||
+!host-mrq-sbc)) {
+
/*
* The controller needs a reset of internal state machines
* upon error conditions.
@@ -933,7 +948,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
sdhci_writel(host, cmd-arg, SDHCI_ARGUMENT);
- sdhci_set_transfer_mode(host, cmd-data);
+ sdhci_set_transfer_mode(host, cmd);
if ((cmd-flags MMC_RSP_136) (cmd-flags MMC_RSP_BUSY)) {
printk(KERN_ERR %s: Unsupported response type!\n,
@@ -986,13 +1001,21 @@ static void sdhci_finish_command(struct sdhci_host *host)
host-cmd-error = 0;
- if (host-data host-data_early)
- sdhci_finish_data(host);
+ /* Finished CMD23, now send actual command. */
+ if (host-cmd == host-mrq-sbc) {
+ host-cmd = NULL;
+ sdhci_send_command(host, host-mrq-cmd);
+ } else {
- if (!host-cmd-data)
- tasklet_schedule(host-finish_tasklet);
+ /* Processed actual command. */
+ if (host-data host-data_early)
+ sdhci_finish_data(host);
- host-cmd = NULL;
+ if (!host-cmd-data)
+ tasklet_schedule(host-finish_tasklet);
+
+ host-cmd = NULL;
+ }
}
static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
@@ -1159,8 +1182,13 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
if (!present || host-flags SDHCI_DEVICE_DEAD) {
host-mrq-cmd-error = -ENOMEDIUM;
tasklet_schedule(host-finish_tasklet);
- } else
- sdhci_send_command(host, mrq-cmd);
+ } else {
+
+ if (mrq-sbc)
+ sdhci_send_command(host, mrq-sbc);
+ else
+ sdhci_send_command(host, mrq-cmd);
+ }
mmiowb();
spin_unlock_irqrestore(host-lock, flags);
@@ -1909,7 +1937,7 @@ int sdhci_add_host(struct sdhci_host *host)
mmc-f_min = host-max_clk / SDHCI_MAX_DIV_SPEC_200;
mmc-f_max = host-max_clk;
- mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;
+ mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE | MMC_CAP_CMD23;
/*
* A controller may support 8-bit width, but the board itself
--
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
[patchv2 3/3] MMC: Block CMD23 support for UHS104/SDXC cards.
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.
Cc: arindam.n...@amd.com
Cc: c...@laptop.org
Cc: a...@arndb.de
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c |9 ++---
drivers/mmc/core/sd.c|1 +
include/linux/mmc/card.h |1 +
include/linux/mmc/sd.h |1 +
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index bba0888..69b70ce 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -851,9 +851,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
blk_queue_logical_block_size(md-queue.queue, 512);
set_capacity(md-disk, size);
- if (mmc_host_cmd23(card-host)
- mmc_card_mmc(card))
- md-flags |= MMC_BLK_CMD23;
+ if (mmc_host_cmd23(card-host)) {
+ if (mmc_card_mmc(card) ||
+ (mmc_card_sd(card)
+card-scr.cmds SCR_CMDS_CMD23))
+ md-flags |= MMC_BLK_CMD23;
+ }
if (mmc_card_mmc(card)
md-flags MMC_BLK_CMD23
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 6dac89f..16a1f10 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -195,6 +195,7 @@ static int mmc_decode_scr(struct mmc_card *card)
else
card-erased_byte = 0x0;
+ scr-cmds = UNSTUFF_BITS(resp, 32, 2);
return 0;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 1e6bd6c..c036a78 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -70,6 +70,7 @@ struct sd_scr {
unsigned char bus_widths;
#define SD_SCR_BUS_WIDTH_1 (10)
#define SD_SCR_BUS_WIDTH_4 (12)
+ unsigned char cmds;
};
struct sd_ssr {
diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
index 3fd85e0..81ba37b 100644
--- a/include/linux/mmc/sd.h
+++ b/include/linux/mmc/sd.h
@@ -60,6 +60,7 @@
#define SCR_SPEC_VER_0 0 /* Implements system specification 1.0
- 1.01 */
#define SCR_SPEC_VER_1 1 /* Implements system specification 1.10
*/
#define SCR_SPEC_VER_2 2 /* Implements system specification 2.00
*/
+#define SCR_CMDS_CMD23 (1 1) /* Supports CMD23 */
/*
* SD bus widths
--
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
[PATCH] MMC: Fix use of uninitialized data in mmc_cmd_app.
mmc_cmd_app did not zero out mmc_command on stack.
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/core/sd_ops.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/sd_ops.c b/drivers/mmc/core/sd_ops.c
index 76af349..71fdb07 100644
--- a/drivers/mmc/core/sd_ops.c
+++ b/drivers/mmc/core/sd_ops.c
@@ -29,6 +29,8 @@ static int mmc_app_cmd(struct mmc_host *host, struct mmc_card
*card)
BUG_ON(!host);
BUG_ON(card (card-host != host));
+ memset(cmd, 0, sizeof(struct mmc_command));
+
cmd.opcode = MMC_APP_CMD;
if (card) {
--
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
SET_BLOCK_COUNT-bounded multiblock transfers
This is a request for comments for a patch set that enables predefined multiblock transfers if these are supported. Before this patch set, all multiblock transfers look like (for example) CMD25 - [block] [block] [block] [block] - CMD12 (stop) ...or for controllers with Auto-CMD12 CMD25 - [block] [block] [block] [block] (host sends CMD12 itself). We want to enable - CMD23(4 blocks) CMD25 [data] [data] [data] [data] ...and for controllers with Auto-CMD23 - (Host sends CMD23(4 blocks)) CMD25 [data] [data] [data] [data] The interrupt overhead is the same, but for cards that optimize for predefined transfers we can see better transfer rates. I've tested this on a Sandisk eMMC where I saw as good as a 50% improvement on writes, and on a Toshiba eMMC where I saw no improvement at all. Also, reliable writes use CMD23, so this cleans up that code path as well. Note, that if a transfer fails, CMD12 must still be sent, so it is not sufficient to just not fill the mrq-stop field while doing a CMD23-enabled transfer. Due to this error handling and off-loads of Auto-CMD23 (and interaction with Auto-CMD12) handling of SET_BLOCK_COUNT, just like STOP, is left to the host driver. Host driver now exposes MMC_CAP_CMD23 if it has been changed to handle the new sbc field in struct mmc_request. If a host doesn't expose this capability, open-ended transfers are used, and all functionality relying on CMD23 (such as reliable writes) is disabled. The third patch has been only tested on SD cards that don't expose CMD23. Still need to get an SDXC card and test it out, but I wanted to get eyes on this patch set anyway :-). I had a fourth patch enabling Auto-CMD23 for SDHCI, but I'll hold off until I can verify it. Thoughts? Table of Contents: [RFC 1/3] MMC: use CMD23 for multiblock transfers when we can. [RFC 2/3] MMC: Implement MMC_CAP_CMD23 for SDHCI. [RFC 3/3] MMC: Block CMD23 support for UHS104/SDXC cards. A -- 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
[RFC 1/3] MMC: use CMD23 for multiblock transfers when we can.
CMD23-prefixed instead of open-ended multiblock transfers
have a performance advantage on some MMC cards.
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 89 ++---
include/linux/mmc/core.h |1 +
include/linux/mmc/host.h |6 +++
include/linux/mmc/mmc.h |6 +++
4 files changed, 72 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c209953..282e6ef 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -55,10 +55,6 @@ MODULE_ALIAS(mmc:block);
#define INAND_CMD38_ARG_SECTRIM1 0x81
#define INAND_CMD38_ARG_SECTRIM2 0x88
-#define REL_WRITES_SUPPORTED(card) (mmc_card_mmc((card)) \
-(((card)-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN) || \
- ((card)-ext_csd.rel_sectors)))
-
static DEFINE_MUTEX(block_mutex);
/*
@@ -85,6 +81,10 @@ struct mmc_blk_data {
struct mmc_queue queue;
struct list_head part;
+ unsigned intflags;
+#define MMC_BLK_CMD23 (1 0)/* Can do SET_BLOCK_COUNT for
multiblock */
+#define MMC_BLK_REL_WR (1 1)/* MMC Reliable write support */
+
unsigned intusage;
unsigned intread_only;
unsigned intpart_type;
@@ -225,6 +225,7 @@ static const struct block_device_operations mmc_bdops = {
struct mmc_blk_request {
struct mmc_request mrq;
+ struct mmc_command sbc;
struct mmc_command cmd;
struct mmc_command stop;
struct mmc_data data;
@@ -455,13 +456,10 @@ static int mmc_blk_issue_flush(struct mmc_queue *mq,
struct request *req)
* reliable write can handle, thus finish the request in
* partial completions.
*/
-static inline int mmc_apply_rel_rw(struct mmc_blk_request *brq,
- struct mmc_card *card,
- struct request *req)
+static inline void mmc_apply_rel_rw(struct mmc_blk_request *brq,
+ struct mmc_card *card,
+ struct request *req)
{
- int err;
- struct mmc_command set_count;
-
if (!(card-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN)) {
/* Legacy mode imposes restrictions on transfers. */
if (!IS_ALIGNED(brq-cmd.arg, card-ext_csd.rel_sectors))
@@ -472,16 +470,6 @@ static inline int mmc_apply_rel_rw(struct mmc_blk_request
*brq,
else if (brq-data.blocks card-ext_csd.rel_sectors)
brq-data.blocks = 1;
}
-
- memset(set_count, 0, sizeof(struct mmc_command));
- set_count.opcode = MMC_SET_BLOCK_COUNT;
- set_count.arg = brq-data.blocks | (1 31);
- set_count.flags = MMC_RSP_R1 | MMC_CMD_AC;
- err = mmc_wait_for_cmd(card-host, set_count, 0);
- if (err)
- printk(KERN_ERR %s: error %d SET_BLOCK_COUNT\n,
- req-rq_disk-disk_name, err);
- return err;
}
static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct request *req)
@@ -498,7 +486,7 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq, struct
request *req)
bool do_rel_wr = ((req-cmd_flags REQ_FUA) ||
(req-cmd_flags REQ_META))
(rq_data_dir(req) == WRITE)
- REL_WRITES_SUPPORTED(card);
+ (md-flags MMC_BLK_REL_WR);
do {
struct mmc_command cmd;
@@ -536,11 +524,9 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
if (brq.data.blocks 1 || do_rel_wr) {
/* SPI multiblock writes terminate using a special
-* token, not a STOP_TRANSMISSION request. Reliable
-* writes use SET_BLOCK_COUNT and do not use a
-* STOP_TRANSMISSION request either.
+* token, not a STOP_TRANSMISSION request.
*/
- if ((!mmc_host_is_spi(card-host) !do_rel_wr) ||
+ if (!mmc_host_is_spi(card-host) ||
rq_data_dir(req) == READ)
brq.mrq.stop = brq.stop;
readcmd = MMC_READ_MULTIPLE_BLOCK;
@@ -558,8 +544,32 @@ static int mmc_blk_issue_rw_rq(struct mmc_queue *mq,
struct request *req)
brq.data.flags |= MMC_DATA_WRITE;
}
- if (do_rel_wr mmc_apply_rel_rw(brq, card, req))
- goto cmd_err;
+ if (do_rel_wr)
+ mmc_apply_rel_rw(brq, card, req);
+
+ /*
+* Pre-defined multi-block transfers are preferable to
+* open ended-ones (and necessary for reliable writes).
+* However, it is not sufficient to just send CMD23,
+* and avoid the final CMD12, as on an error condition
[RFC 2/3] MMC: Implement MMC_CAP_CMD23 for SDHCI.
Implements support for multiblock transfers bounded
by SET_BLOCK_COUNT (CMD23).
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 60 +
1 files changed, 44 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 94793f2..0b71ce8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -822,9 +822,10 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_command *cmd)
}
static void sdhci_set_transfer_mode(struct sdhci_host *host,
- struct mmc_data *data)
+ struct mmc_command *cmd)
{
u16 mode;
+ struct mmc_data *data = cmd-data;
if (data == NULL)
return;
@@ -832,11 +833,17 @@ static void sdhci_set_transfer_mode(struct sdhci_host
*host,
WARN_ON(!host-data);
mode = SDHCI_TRNS_BLK_CNT_EN;
- if (data-blocks 1) {
- if (host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
- mode |= SDHCI_TRNS_MULTI | SDHCI_TRNS_ACMD12;
- else
- mode |= SDHCI_TRNS_MULTI;
+ if (mmc_op_multi(cmd-opcode) ||
+ data-blocks 1) {
+ mode |= SDHCI_TRNS_MULTI;
+
+ /*
+* If we are sending CMD23, CMD12 never gets sent
+* on successful completion.
+*/
+ if (!host-mrq-sbc
+ host-quirks SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12)
+ mode |= SDHCI_TRNS_ACMD12;
}
if (data-flags MMC_DATA_READ)
mode |= SDHCI_TRNS_READ;
@@ -877,7 +884,15 @@ static void sdhci_finish_data(struct sdhci_host *host)
else
data-bytes_xfered = data-blksz * data-blocks;
- if (data-stop) {
+ /*
+* Need to send CMD12 if -
+* a) open-ended multiblock transfer (no CMD23)
+* b) error in multiblock transfer
+*/
+ if (data-stop
+ (data-error ||
+!host-mrq-sbc)) {
+
/*
* The controller needs a reset of internal state machines
* upon error conditions.
@@ -933,7 +948,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
sdhci_writel(host, cmd-arg, SDHCI_ARGUMENT);
- sdhci_set_transfer_mode(host, cmd-data);
+ sdhci_set_transfer_mode(host, cmd);
if ((cmd-flags MMC_RSP_136) (cmd-flags MMC_RSP_BUSY)) {
printk(KERN_ERR %s: Unsupported response type!\n,
@@ -986,13 +1001,21 @@ static void sdhci_finish_command(struct sdhci_host *host)
host-cmd-error = 0;
- if (host-data host-data_early)
- sdhci_finish_data(host);
+ /* Finished CMD23, now send actual command. */
+ if (host-cmd == host-mrq-sbc) {
+ host-cmd = NULL;
+ sdhci_send_command(host, host-mrq-cmd);
+ } else {
- if (!host-cmd-data)
- tasklet_schedule(host-finish_tasklet);
+ /* Processed actual command. */
+ if (host-data host-data_early)
+ sdhci_finish_data(host);
- host-cmd = NULL;
+ if (!host-cmd-data)
+ tasklet_schedule(host-finish_tasklet);
+
+ host-cmd = NULL;
+ }
}
static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
@@ -1159,8 +1182,13 @@ static void sdhci_request(struct mmc_host *mmc, struct
mmc_request *mrq)
if (!present || host-flags SDHCI_DEVICE_DEAD) {
host-mrq-cmd-error = -ENOMEDIUM;
tasklet_schedule(host-finish_tasklet);
- } else
- sdhci_send_command(host, mrq-cmd);
+ } else {
+
+ if (mrq-sbc)
+ sdhci_send_command(host, mrq-sbc);
+ else
+ sdhci_send_command(host, mrq-cmd);
+ }
mmiowb();
spin_unlock_irqrestore(host-lock, flags);
@@ -1909,7 +1937,7 @@ int sdhci_add_host(struct sdhci_host *host)
mmc-f_min = host-max_clk / SDHCI_MAX_DIV_SPEC_200;
mmc-f_max = host-max_clk;
- mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE;
+ mmc-caps |= MMC_CAP_SDIO_IRQ | MMC_CAP_ERASE | MMC_CAP_CMD23;
/*
* A controller may support 8-bit width, but the board itself
--
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
[RFC 3/3] MMC: Block CMD23 support for UHS104/SDXC cards.
SD cards operating at UHS104 or better support SET_BLOCK_COUNT.
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c |9 ++---
drivers/mmc/core/sd.c|1 +
include/linux/mmc/card.h |1 +
include/linux/mmc/sd.h |1 +
4 files changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 282e6ef..6573e36 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -846,9 +846,12 @@ static struct mmc_blk_data *mmc_blk_alloc_req(struct
mmc_card *card,
blk_queue_logical_block_size(md-queue.queue, 512);
set_capacity(md-disk, size);
- if (mmc_host_cmd23(card-host)
- mmc_card_mmc(card))
- md-flags |= MMC_BLK_CMD23;
+ if (mmc_host_cmd23(card-host)) {
+ if (mmc_card_mmc(card) ||
+ (mmc_card_sd(card)
+card-scr.cmds SCR_CMDS_CMD23))
+ md-flags |= MMC_BLK_CMD23;
+ }
if (mmc_card_mmc(card)
md-flags MMC_BLK_CMD23
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 6dac89f..16a1f10 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -195,6 +195,7 @@ static int mmc_decode_scr(struct mmc_card *card)
else
card-erased_byte = 0x0;
+ scr-cmds = UNSTUFF_BITS(resp, 32, 2);
return 0;
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 72a9868..337a851 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -70,6 +70,7 @@ struct sd_scr {
unsigned char bus_widths;
#define SD_SCR_BUS_WIDTH_1 (10)
#define SD_SCR_BUS_WIDTH_4 (12)
+ unsigned char cmds;
};
struct sd_ssr {
diff --git a/include/linux/mmc/sd.h b/include/linux/mmc/sd.h
index 3fd85e0..81ba37b 100644
--- a/include/linux/mmc/sd.h
+++ b/include/linux/mmc/sd.h
@@ -60,6 +60,7 @@
#define SCR_SPEC_VER_0 0 /* Implements system specification 1.0
- 1.01 */
#define SCR_SPEC_VER_1 1 /* Implements system specification 1.10
*/
#define SCR_SPEC_VER_2 2 /* Implements system specification 2.00
*/
+#define SCR_CMDS_CMD23 (1 1) /* Supports CMD23 */
/*
* SD bus widths
--
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
Re: SET_BLOCK_COUNT-bounded multiblock transfers
On Wed, Apr 13, 2011 at 7:38 PM, Andrei Warkentin andr...@motorola.com wrote: This is a request for comments for a patch set that enables predefined multiblock transfers if these are supported. Before this patch set, all multiblock transfers look like (for example) CMD25 - [block] [block] [block] [block] - CMD12 (stop) ...or for controllers with Auto-CMD12 CMD25 - [block] [block] [block] [block] (host sends CMD12 itself). We want to enable - CMD23(4 blocks) CMD25 [data] [data] [data] [data] ...and for controllers with Auto-CMD23 - (Host sends CMD23(4 blocks)) CMD25 [data] [data] [data] [data] The interrupt overhead is the same, but for cards that optimize for predefined transfers we can see better transfer rates. I've tested this on a Sandisk eMMC where I saw as good as a 50% improvement on writes, and on a Toshiba eMMC where I saw no improvement at all. Also, reliable writes use CMD23, so this cleans up that code path as well. Note, that if a transfer fails, CMD12 must still be sent, so it is not sufficient to just not fill the mrq-stop field while doing a CMD23-enabled transfer. Due to this error handling and off-loads of Auto-CMD23 (and interaction with Auto-CMD12) handling of SET_BLOCK_COUNT, just like STOP, is left to the host driver. Host driver now exposes MMC_CAP_CMD23 if it has been changed to handle the new sbc field in struct mmc_request. If a host doesn't expose this capability, open-ended transfers are used, and all functionality relying on CMD23 (such as reliable writes) is disabled. The third patch has been only tested on SD cards that don't expose CMD23. Still need to get an SDXC card and test it out, but I wanted to get eyes on this patch set anyway :-). I had a fourth patch enabling Auto-CMD23 for SDHCI, but I'll hold off until I can verify it. Thoughts? Table of Contents: [RFC 1/3] MMC: use CMD23 for multiblock transfers when we can. [RFC 2/3] MMC: Implement MMC_CAP_CMD23 for SDHCI. [RFC 3/3] MMC: Block CMD23 support for UHS104/SDXC cards. A + Yunpeng -- 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: [patchv3 2/4] MMC: SDHCI R1B command handling + MMC_CAP_ERASE.
On Tue, Apr 12, 2011 at 4:06 AM, Dong, Chuanxiao
chuanxiao.d...@intel.com wrote:
-Original Message-
From: linux-mmc-ow...@vger.kernel.org
[mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Andrei Warkentin
Sent: Tuesday, April 12, 2011 5:14 AM
To: linux-mmc@vger.kernel.org
Cc: a...@arndb.de; c...@laptop.org; Andrei Warkentin
Subject: [patchv3 2/4] MMC: SDHCI R1B command handling + MMC_CAP_ERASE.
ERASE command needs R1B response, so fix R1B-type command
handling for SDHCI controller. For non-DAT commands using a busy
reponse, the cmd-cmd_timeout_ms (in ms) field is used for timeout
calculations.
Based on patch by Chuanxiao Dong chuanxiao.d...@intel.com
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/host/sdhci.c | 43 +++
1 files changed, 27 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9e15f41..173e980 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -40,7 +40,6 @@
static unsigned int debug_quirks = 0;
-static void sdhci_prepare_data(struct sdhci_host *, struct mmc_data *);
static void sdhci_finish_data(struct sdhci_host *);
static void sdhci_send_command(struct sdhci_host *, struct mmc_command *);
@@ -591,9 +590,10 @@ static void sdhci_adma_table_post(struct sdhci_host
*host,
data-sg_len, direction);
}
-static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_data *data)
+static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_command
*cmd)
{
u8 count;
+ struct mmc_data *data = cmd-data;
unsigned target_timeout, current_timeout;
/*
@@ -605,12 +605,16 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host,
struct mmc_data *data)
if (host-quirks SDHCI_QUIRK_BROKEN_TIMEOUT_VAL)
return 0xE;
- /* timeout in us */
- target_timeout = data-timeout_ns / 1000 +
- data-timeout_clks / host-clock;
+ /* Unspecified timeout, assume max */
+ if (!data !cmd-cmd_timeout_ms)
+ return 0xE;
Just a inline question here. I noticed cmd_timeout_ms only be set for the
ERASE command and SWITCH command, for other types of commands, this value is
left not initialized. Cmd_timeout_ms may not be zero and also not be
initialized. And next, driver will use this value to calculate the timeout.
So I think using an uninitialized value here doesn't make sense. If we want
to use it, we have to make sure at this point, this value is already
initialized.
First, cmd_timeout only has meaning for non-DAT-transfer commands
using DAT as a busy indicator. This is exactly why the cmd_timeout_ms
affects the data timeout on the host. Hence - cmd_timeout_ms only
makes sense for R1b commands. (R5b too, but that's SDIO land and I
don't want to push support for something I can't verify) Second - if
it's not initialized, it is zero (look in block.c, the entire brq is
cleared to 0, look in mmc_ops, sd_ops, sdio_ops).
Remember, if !data and !cmd_timeout, then this must be a busy-wait
command with no timeout specified, we pick the safe maximum of 0xE.
Also again, this timeout has any meaning (and is only calculated) only
if the command actually leverages the DAT line.
What commands are you interested in? There are not a lot of R1b
commands. This patch addressed missing DAT timeout for R1b commands
like erase, switch, etc.
- if (host-quirks SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK)
- host-timeout_clk = host-clock / 1000;
+ /* timeout in us */
+ if (!data)
+ target_timeout = cmd-cmd_timeout_ms * 1000;
That is where I concerned about the uninitialized cmd_timeout_ms.
You claim it's uninitialized, but it is zero because all consumers of
mmc_command memset the structure to 0.
+ else
+ target_timeout = data-timeout_ns / 1000 +
+ data-timeout_clks / host-clock;
/*
* Figure out needed cycles.
@@ -632,8 +636,9 @@ static u8 sdhci_calc_timeout(struct sdhci_host *host,
struct mmc_data *data)
}
if (count = 0xF) {
- printk(KERN_WARNING %s: Too large timeout requested!\n,
- mmc_hostname(host-mmc));
+ printk(KERN_WARNING %s: Too large timeout requested for
CMD%d!\n,
+ mmc_hostname(host-mmc),
+ cmd-opcode);
count = 0xE;
}
@@ -651,15 +656,21 @@ static void sdhci_set_transfer_irqs(struct sdhci_host
*host)
sdhci_clear_set_irqs(host, dma_irqs, pio_irqs);
}
-static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data
*data)
+static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command
*cmd)
{
u8 count;
u8 ctrl;
+ struct mmc_data *data = cmd-data;
int ret;
WARN_ON(host-data);
- if (data == NULL)
+ if (data || (cmd-flags
Re: SanDisk 4.3+ iNAND eMMC devices TRIM bug workaround.
On Tue, Apr 12, 2011 at 11:57 AM, Chris Ball c...@laptop.org wrote: Hi Andrei, On Mon, Apr 11 2011, Andrei Warkentin wrote: This fixes the out-of-spec erase/trim support. CMD38 argument is passed through an EXT_CSD byte instead of as the command argument. This has the effect that trims act as group erases, erasing more data than necessary. Secure trims/erases were also affected. N.B. This depends on the mmc_switch patch from the earlier boot partition patchset (MMC: Allow setting CMD timeout for CMD6 (SWITCH)). This also depends on the update core/quirks.c code. ToC: [PATCH 1/2] MMC: Support for block quirks. [PATCH 2/2] MMC: Fix erase/trim for certain SanDisk cards. Looks like these are missing your new timeout arg to mmc_switch(): drivers/mmc/card/block.c: In function ‘mmc_blk_issue_discard_rq’: drivers/mmc/card/block.c:371:6: error: too few arguments to function ‘mmc_switch’ include/linux/mmc/core.h:138:12: note: declared here drivers/mmc/card/block.c: In function ‘mmc_blk_issue_secdiscard_rq’: drivers/mmc/card/block.c:410:6: error: too few arguments to function ‘mmc_switch’ include/linux/mmc/core.h:138:12: note: declared here drivers/mmc/card/block.c:419:7: error: too few arguments to function ‘mmc_switch’ Thanks, - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child I'm sorry about that. I was sure I had rebased it appropriately, but I had not. I will repush it. A -- 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] MMC: Fix erase/trim for certain SanDisk cards.
CMD38 argument is passed through EXT_CSD[113].
Signed-off-by: Andrei Warkentin andr...@motorola.com
---
drivers/mmc/card/block.c | 40 +++-
include/linux/mmc/card.h |1 +
2 files changed, 40 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 1bf1c5d..8895bb9 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -48,6 +48,13 @@ MODULE_ALIAS(mmc:block);
#endif
#define MODULE_PARAM_PREFIX mmcblk.
+#define INAND_CMD38_ARG_EXT_CSD 113
+#define INAND_CMD38_ARG_ERASE0x00
+#define INAND_CMD38_ARG_TRIM 0x01
+#define INAND_CMD38_ARG_SECERASE 0x80
+#define INAND_CMD38_ARG_SECTRIM1 0x81
+#define INAND_CMD38_ARG_SECTRIM2 0x88
+
#define REL_WRITES_SUPPORTED(card) (mmc_card_mmc((card)) \
(((card)-ext_csd.rel_param EXT_CSD_WR_REL_PARAM_EN) || \
((card)-ext_csd.rel_sectors)))
@@ -356,6 +363,15 @@ static int mmc_blk_issue_discard_rq(struct mmc_queue *mq,
struct request *req)
else
arg = MMC_ERASE_ARG;
+ if (card-quirks MMC_QUIRK_INAND_CMD38) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+INAND_CMD38_ARG_EXT_CSD,
+arg == MMC_TRIM_ARG ?
+INAND_CMD38_ARG_TRIM :
+INAND_CMD38_ARG_ERASE);
+ if (err)
+ goto out;
+ }
err = mmc_erase(card, from, nr, arg);
out:
spin_lock_irq(md-lock);
@@ -386,9 +402,26 @@ static int mmc_blk_issue_secdiscard_rq(struct mmc_queue
*mq,
else
arg = MMC_SECURE_ERASE_ARG;
+ if (card-quirks MMC_QUIRK_INAND_CMD38) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+INAND_CMD38_ARG_EXT_CSD,
+arg == MMC_SECURE_TRIM1_ARG ?
+INAND_CMD38_ARG_SECTRIM1 :
+INAND_CMD38_ARG_SECERASE);
+ if (err)
+ goto out;
+ }
err = mmc_erase(card, from, nr, arg);
- if (!err arg == MMC_SECURE_TRIM1_ARG)
+ if (!err arg == MMC_SECURE_TRIM1_ARG) {
+ if (card-quirks MMC_QUIRK_INAND_CMD38) {
+ err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
+INAND_CMD38_ARG_EXT_CSD,
+INAND_CMD38_ARG_SECTRIM2);
+ if (err)
+ goto out;
+ }
err = mmc_erase(card, from, nr, MMC_SECURE_TRIM2_ARG);
+ }
out:
spin_lock_irq(md-lock);
__blk_end_request(req, err, blk_rq_bytes(req));
@@ -941,6 +974,11 @@ static int mmc_add_disk(struct mmc_blk_data *md)
static const struct mmc_fixup blk_fixups[] =
{
+ MMC_FIXUP(SEM02G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
+ MMC_FIXUP(SEM04G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
+ MMC_FIXUP(SEM08G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
+ MMC_FIXUP(SEM16G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
+ MMC_FIXUP(SEM32G, 0x2, 0x100, add_quirk, MMC_QUIRK_INAND_CMD38),
END_FIXUP
};
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 8ac96f7..0a2be01 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -133,6 +133,7 @@ struct mmc_card {
#define MMC_QUIRK_BROKEN_CLK_GATING (13) /* clock gating the sdio bus
will make card fail */
#define MMC_QUIRK_NONSTD_FUNC_IF (14)/* SDIO card has nonstd
function interfaces */
#define MMC_QUIRK_DISABLE_CD (15) /* disconnect CD/DAT[3]
resistor */
+#define MMC_QUIRK_INAND_CMD38 (16) /* iNAND devices have broken
CMD38 */
unsigned interase_size; /* erase size in sectors */
unsigned interase_shift;/* if erase unit is power 2 */
--
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
Re: [PATCH] MMC: Fix erase/trim for certain SanDisk cards.
On Tue, Apr 12, 2011 at 3:03 PM, Andrei Warkentin andr...@motorola.com wrote: CMD38 argument is passed through EXT_CSD[113]. Signed-off-by: Andrei Warkentin andr...@motorola.com --- Wrong version again, sorry! :( A -- 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
