Re: Request for SPI testing
On Tue, Jun 29, 2010 at 09:30:34PM -0600, Grant Likely wrote: I've pushed out Ernst's spi bus locking API patches to the following branch. Before I push them into linux-next, I'd like to get some testing. Can I have some volunteers please to pull this branch and give it a spin? Bonus points for people who have mmc cards multiplexed with other devices on their SPI bus. I put these patches through some light testing by reading data from a flash device and writing it to an mmc card, both over SPI. They seem to hold up fine, but I can certainly try some other things if you have anything specific in mind. -- 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: Request for SPI testing
Hi Grant, I've pushed out Ernst's spi bus locking API patches to the following branch. Before I push them into linux-next, I'd like to get some testing. Can I have some volunteers please to pull this branch and give it a spin? Bonus points for people who have mmc cards multiplexed with other devices on their SPI bus. Thanks for bringing up this topic. We are working with these two patches (except the spin_lock_irqsave modification and the 'bool' datatype for bus_lock_flag) for several months on our system (powerpc, MPC8314, kernel 2.6.32.7 and 2.6.32.14) that makes heavy use of several SPI devices: 9 x EEPROM, 3 x dataflash, MMC and 2 x MDIO-pseudo-SPI (with a special SPI-to-MDIO bus driver). The MMC is used rarely, but the rest is essential for system operation. Until now, we observed no problems, even when copying EEPROM data to MMC. So you may add my 'tested-by'. Best regards Ernst -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5] OMAP: Fix for bus width which improves SD card's peformance.
Hi Andrew,
If no further comments on this patch, can this be taken?
Regards,
Kishore
On Tue, Jun 15, 2010 at 1:37 PM, kishore kadiyala
kishorek.kadiy...@gmail.com wrote:
From: Kishore Kadiyala kishore.kadiy...@ti.com
This patch improves low speeds for SD cards.
OMAP-MMC controller's can support maximum bus width of '8'.
when bus width is mentioned as 8 in controller data,the SD
stack will check whether bus width is 4 and if not it will
set bus width to 1 and there by degrading performance.
This patch fixes the issue and improves the performance of
SD cards.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Tested-by: Jarkko Nikula jhnik...@gmail.com
---
In V5 : Rebasing on 2.6.35-rc3
In V4 : Updated with Nishanth's comments and appened his Signed-off
http://marc.info/?t=12716914936r=1w=2
In V3 : Updated with Madhu's comments and appended Tested by Nikula
In V2 : Appended Signed-off by Venkat and Ack by Madhu
Here are my experiment numbers, on a Class 6 SDHC card:
Read peformance is increased by 220%
Write Performance is increased by 52%
drivers/mmc/host/omap_hsmmc.c | 17 +++--
1 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b032828..a0c8515 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2096,10 +2096,23 @@ static int __init omap_hsmmc_probe(struct
mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_WAIT_WHILE_BUSY;
- if (mmc_slot(host).wires = 8)
+ switch (mmc_slot(host).wires) {
+ case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
- else if (mmc_slot(host).wires = 4)
+ /* Fall through */
+ case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
+ break;
+ case 1:
+ /* Nothing to crib here */
+ case 0:
+ /* Assuming nothing was given by board, Core use's 1-Bit */
+ break;
+ default:
+ /* Completely unexpected.. Core goes with 1-Bit Width */
+ dev_crit(mmc_dev(host-mmc), Invalid width %d\n used!
+ using 1 instead\n, mmc_slot(host).wires);
+ }
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] MMC: Add JZ4740 mmc driver
On Mon, 28 Jun 2010 03:20:41 +0200
Lars-Peter Clausen l...@metafoo.de wrote:
This patch adds support for the mmc controller on JZ4740 SoCs.
Signed-off-by: Lars-Peter Clausen l...@metafoo.de
Cc: Andrew Morton a...@linux-foundation.org
Cc: Matt Fleming m...@console-pimps.org
Cc: linux-mmc@vger.kernel.org
...
+#define JZ4740_MMC_MAX_TIMEOUT 1000
That was a really big timeout. How long do 1e7 readw's take? Oh well.
...
+static void jz4740_mmc_clock_disable(struct jz4740_mmc_host *host)
+{
+ uint32_t status;
+
+ writew(JZ_MMC_STRPCL_CLOCK_STOP, host-base + JZ_REG_MMC_STRPCL);
+ do {
+ status = readl(host-base + JZ_REG_MMC_STATUS);
+ } while (status JZ_MMC_STATUS_CLK_EN);
+}
+
+static void jz4740_mmc_reset(struct jz4740_mmc_host *host)
+{
+ uint32_t status;
+
+ writew(JZ_MMC_STRPCL_RESET, host-base + JZ_REG_MMC_STRPCL);
+ udelay(10);
+ do {
+ status = readl(host-base + JZ_REG_MMC_STATUS);
+ } while (status JZ_MMC_STATUS_IS_RESETTING);
+}
Maybe these should have a timeout too?
...
+static inline unsigned int jz4740_mmc_wait_irq(struct jz4740_mmc_host *host,
+ unsigned int irq)
+{
+ unsigned int timeout = JZ4740_MMC_MAX_TIMEOUT;
+ uint16_t status;
+
+ do {
+ status = readw(host-base + JZ_REG_MMC_IREG);
+ } while (!(status irq) --timeout);
+
+ return timeout;
+}
This guy's too big to inline. Recent gcc's know that and they tend to
uninline such things behind your back anwyay.
...
+struct jz4740_mmc_platform_data {
+ int gpio_power;
+ int gpio_card_detect;
+ int gpio_read_only;
+ unsigned card_detect_active_low:1;
+ unsigned read_only_active_low:1;
+ unsigned power_active_low:1;
+
+ unsigned data_1bit:1;
+};
The bitfields will all share the same word, so modification of one
field can race against modification of another field. Hence some form
of locking which covers *all* the bitfields is needed.
Is that a problem in this driver?
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
+ mmc-add-jz4740-mmc-driver.patch added to -mm tree
The patch titled mmc: add JZ4740 mmc driver has been added to the -mm tree. Its filename is mmc-add-jz4740-mmc-driver.patch Before you just go and hit reply, please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/SubmitChecklist when testing your code *** See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find out what to do about this The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/ -- Subject: mmc: add JZ4740 mmc driver From: Lars-Peter Clausen l...@metafoo.de Add support for the mmc controller on JZ4740 SoCs. Signed-off-by: Lars-Peter Clausen l...@metafoo.de Acked-by: Matt Fleming m...@console-pimps.org Cc: linux-mmc@vger.kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/mmc/host/Kconfig |8 drivers/mmc/host/Makefile |1 drivers/mmc/host/jz4740_mmc.c | 969 +++ include/linux/mmc/jz4740_mmc.h | 15 4 files changed, 993 insertions(+) diff -puN drivers/mmc/host/Kconfig~mmc-add-jz4740-mmc-driver drivers/mmc/host/Kconfig --- a/drivers/mmc/host/Kconfig~mmc-add-jz4740-mmc-driver +++ a/drivers/mmc/host/Kconfig @@ -81,6 +81,14 @@ config MMC_RICOH_MMC If unsure, say Y. +config MMC_JZ4740 + tristate JZ4740 SD/Multimedia Card Interface support + depends on MACH_JZ4740 + help + This selects the Ingenic Z4740 SD/Multimedia card Interface. + If you have an ngenic platform with a Multimedia Card slot, + say Y or M here. + config MMC_SDHCI_OF tristate SDHCI support on OpenFirmware platforms depends on MMC_SDHCI PPC_OF diff -puN drivers/mmc/host/Makefile~mmc-add-jz4740-mmc-driver drivers/mmc/host/Makefile --- a/drivers/mmc/host/Makefile~mmc-add-jz4740-mmc-driver +++ a/drivers/mmc/host/Makefile @@ -36,6 +36,7 @@ obj-$(CONFIG_MMC_CB710) += cb710-mmc.o obj-$(CONFIG_MMC_VIA_SDMMC)+= via-sdmmc.o obj-$(CONFIG_SDH_BFIN) += bfin_sdh.o obj-$(CONFIG_MMC_SH_MMCIF) += sh_mmcif.o +obj-$(CONFIG_MMC_JZ4740) += jz4740_mmc.o obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o sdhci-of-y := sdhci-of-core.o diff -puN /dev/null drivers/mmc/host/jz4740_mmc.c --- /dev/null +++ a/drivers/mmc/host/jz4740_mmc.c @@ -0,0 +1,969 @@ +/* + * Copyright (C) 2009-2010, Lars-Peter Clausen l...@metafoo.de + * JZ4740 SD/MMC controller driver + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 675 Mass Ave, Cambridge, MA 02139, USA. + * + */ + +#include linux/mmc/host.h +#include linux/io.h +#include linux/irq.h +#include linux/interrupt.h +#include linux/module.h +#include linux/platform_device.h +#include linux/delay.h +#include linux/scatterlist.h +#include linux/clk.h +#include linux/mmc/jz4740_mmc.h + +#include linux/bitops.h +#include linux/gpio.h +#include asm/mach-jz4740/gpio.h +#include asm/cacheflush.h +#include linux/dma-mapping.h + + +#define JZ_REG_MMC_STRPCL 0x00 +#define JZ_REG_MMC_STATUS 0x04 +#define JZ_REG_MMC_CLKRT 0x08 +#define JZ_REG_MMC_CMDAT 0x0C +#define JZ_REG_MMC_RESTO 0x10 +#define JZ_REG_MMC_RDTO0x14 +#define JZ_REG_MMC_BLKLEN 0x18 +#define JZ_REG_MMC_NOB 0x1C +#define JZ_REG_MMC_SNOB0x20 +#define JZ_REG_MMC_IMASK 0x24 +#define JZ_REG_MMC_IREG0x28 +#define JZ_REG_MMC_CMD 0x2C +#define JZ_REG_MMC_ARG 0x30 +#define JZ_REG_MMC_RESP_FIFO 0x34 +#define JZ_REG_MMC_RXFIFO 0x38 +#define JZ_REG_MMC_TXFIFO 0x3C + +#define JZ_MMC_STRPCL_EXIT_MULTIPLE BIT(7) +#define JZ_MMC_STRPCL_EXIT_TRANSFER BIT(6) +#define JZ_MMC_STRPCL_START_READWAIT BIT(5) +#define JZ_MMC_STRPCL_STOP_READWAIT BIT(4) +#define JZ_MMC_STRPCL_RESET BIT(3) +#define JZ_MMC_STRPCL_START_OP BIT(2) +#define JZ_MMC_STRPCL_CLOCK_CONTROL (BIT(1) | BIT(0)) +#define JZ_MMC_STRPCL_CLOCK_STOP BIT(0) +#define JZ_MMC_STRPCL_CLOCK_START BIT(1) + + +#define JZ_MMC_STATUS_IS_RESETTING BIT(15) +#define JZ_MMC_STATUS_SDIO_INT_ACTIVE BIT(14) +#define JZ_MMC_STATUS_PRG_DONE BIT(13) +#define JZ_MMC_STATUS_DATA_TRAN_DONE BIT(12) +#define JZ_MMC_STATUS_END_CMD_RES BIT(11) +#define JZ_MMC_STATUS_DATA_FIFO_AFULL BIT(10) +#define JZ_MMC_STATUS_IS_READWAIT BIT(9) +#define JZ_MMC_STATUS_CLK_EN BIT(8) +#define JZ_MMC_STATUS_DATA_FIFO_FULL BIT(7) +#define
+ mmc-add-jz4740-mmc-driver-fix.patch added to -mm tree
The patch titled
mmc-add-jz4740-mmc-driver-fix
has been added to the -mm tree. Its filename is
mmc-add-jz4740-mmc-driver-fix.patch
Before you just go and hit reply, please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/SubmitChecklist when testing your code ***
See http://userweb.kernel.org/~akpm/stuff/added-to-mm.txt to find
out what to do about this
The current -mm tree may be found at http://userweb.kernel.org/~akpm/mmotm/
--
Subject: mmc-add-jz4740-mmc-driver-fix
From: Andrew Morton a...@linux-foundation.org
uninline jz4740_mmc_wait_irq()
For it is large and has four callsites.
Cc: linux-mmc@vger.kernel.org
Cc: Lars-Peter Clausen l...@metafoo.de
Cc: Matt Fleming m...@console-pimps.org
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
drivers/mmc/host/jz4740_mmc.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/mmc/host/jz4740_mmc.c~mmc-add-jz4740-mmc-driver-fix
drivers/mmc/host/jz4740_mmc.c
--- a/drivers/mmc/host/jz4740_mmc.c~mmc-add-jz4740-mmc-driver-fix
+++ a/drivers/mmc/host/jz4740_mmc.c
@@ -188,7 +188,7 @@ static void jz4740_mmc_request_done(stru
mmc_request_done(host-mmc, req);
}
-static inline unsigned int jz4740_mmc_wait_irq(struct jz4740_mmc_host *host,
+static unsigned int jz4740_mmc_wait_irq(struct jz4740_mmc_host *host,
unsigned int irq)
{
unsigned int timeout = JZ4740_MMC_MAX_TIMEOUT;
_
Patches currently in -mm which might be from a...@linux-foundation.org are
origin.patch
drivers-gpio-is-platform-neutral.patch
fs-fcntlc-kill_fasync_rcu-fa_lock-must-be-irq-safe.patch
ipc-semc-bugfix-for-semop-not-reporting-successful-operation.patch
linux-next.patch
next-remove-localversion.patch
i-need-old-gcc.patch
revert-ed5aa19b93da2c094b6647762774a8022e4e1d6c.patch
revert-9652e31db6d841e291531547b3f4f12b5aeb42a9.patch
revert-fdc8302019d9bc10729cd3e8d348571e833388aa.patch
revert-324d76561842e551051e2a897b958b0539f6867b.patch
revert-e92e80797e7eaaf2a9bbd586c63f7c6bd3177276.patch
revert-d04ab5241f301bdcad2f6beb0ecd326bd82100a7.patch
revert-3ab7269a6058c136795ce9417f7051a0edde60db.patch
revert-4624469822455b4accc886557f6c997ccdd59066.patch
include-linux-fsh-complete-hexification-of-fmode_-constants.patch
cpuidle-avoid-using-smp_processor_id-in-preemptible-code-nr_iowait_cpu.patch
acpi-fix-bogus-preemption-logic-fix.patch
intel_menlow-fix-memory-leaks-in-error-path-fix.patch
x86-cpufreq-make-trace_power_frequency-cpufreq-driver-independent-fix.patch
compal-laptop-added-jhl90-battery-hwmon-interface.patch
gcc-46-btrfs-clean-up-unused-variables-bugs-fix.patch
dib3000mc-reduce-large-stack-usage-fix.patch
hpet-factor-timer-allocate-from-open.patch
leds-route-kbd-leds-through-the-generic-leds-layer.patch
arch-um-drivers-remove-duplicate-structure-field-initialization.patch
3x59x-fix-pci-resource-management.patch
altera_uart-simplify-altera_uart_console_putc-checkpatch-fixes.patch
serial-mcf-dont-take-spinlocks-in-already-protected-functions-fix.patch
scsi-remove-private-bit-macros.patch
vfs-use-kmalloc-to-allocate-fdmem-if-possible.patch
mm.patch
mm-vmap-area-cache-fix.patch
mm-track-the-root-oldest-anon_vma-fix.patch
oom-improve-commentary-in-dump_tasks.patch
oom-sacrifice-child-with-highest-badness-score-for-parent-protect-dereferencing-of-tasks-comm.patch
oom-select-task-from-tasklist-for-mempolicy-ooms-add-has_intersects_mems_allowed-uma-variant.patch
mempolicy-reduce-stack-size-of-migrate_pages-fix.patch
radix-tree-implement-function-radix_tree_range_tag_if_tagged-checkpatch-fixes.patch
frv-duplicate-output_buffer-of-e03-checkpatch-fixes.patch
include-linux-compiler-gcch-use-__same_type-in-__must_be_array.patch
drivers-misc-support-for-the-pressure-sensor-bmp085-from-bosch-sensortec-fix.patch
drivers-misc-support-for-the-pressure-sensor-bmp085-from-bosch-sensortec-update-checkpatch-fixes.patch
mmc-recognize-csd-structure-fix.patch
mmc-fix-all-hangs-related-to-mmc-sd-card-insert-removal-during-suspend-resume.patch
mmc-add-jz4740-mmc-driver-checkpatch-fixes.patch
mmc-add-jz4740-mmc-driver-fix.patch
fix-vc-vc_origin-on-take_over_console-checkpatch-fixes.patch
rtc-fixes-and-new-functionality-for-fm3130-fix.patch
drivers-video-via-via-gpioc-fix-warning.patch
delay-accounting-re-implement-c-for-getdelaysc-to-report-information-on-a-target-command-checkpatch-fixes.patch
kfifo-add-example-files-to-the-kernel-sample-directory-checkpatch-fixes.patch
vfs-add-super-operation-writeback_inodes-fix.patch
reiser4-export-remove_from_page_cache-fix.patch
reiser4-export-find_get_pages.patch
reiser4.patch
reiser4-writeback_inodes-implementation-fix.patch
reiser4-fixups.patch
reiser4-broke.patch
journal_add_journal_head-debug.patch
slab-leaks3-default-y.patch
put_bh-debug.patch
Re: [PATCH V3 4/5] block: Add secure discard
On Thu, 24 Jun 2010 11:44:23 +0300 Adrian Hunter adrian.hun...@nokia.com wrote: From b25b9a499f255ee5999c219525d82ef40382318c Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Wed, 23 Jun 2010 15:41:38 +0300 Subject: [PATCH 4/5] block: Add secure discard Secure discard is the same as discard except that all copies of the discarded sectors (perhaps created by garbage collection) must also be erased. That's not an awfully informative changelog. From a quick peek at the code it seems that you took your earlier design sketch: On Mon, Jun 14, 2010 at 02:10:06PM +0300, Adrian Hunter wrote: Needs a bio flag, a request flag, setup the request flag based on the bio flag, prevent merging secure and non-secure discards, prevent drivers doing non-secure discards for secure discards. Seems like a lot of little changes for something that no one wants. Shouldn't it wait for someone to need it first? and changed your mind and implemented it. Is that a correct interpretation? -- 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 1/5] mmc: Add erase, secure erase, trim and secure trim operations
On Thu, 24 Jun 2010 11:44:00 +0300 Adrian Hunter adrian.hun...@nokia.com wrote: SD/MMC cards tend to support an erase operation. In addition, eMMC v4.4 cards can support secure erase, trim and secure trim operations that are all variants of the basic erase command. The patch proposes a new userspace interface via sysfs, yes? Please fully describe that interface and its operation in the changelog. It'd also be nice to add permanent documentation for it. From reading the code, it appears that erase_size and preferred_erase_size have units in bytes. But users shouldn't need to read the code to find that out. What are the alignemnt and size requirements on these? What is their position in /sys? What do they actually *do* and what is the difference between them? etetera. People want to review this code and other people actually want to use it. I'm not sure that I want to try to review this code when nobody's told me what interface it implements and how it's supposed to work. Seems that whoever implemented BLKDISCARD didn't want anyone to use it either. Sigh. All of mmc core appears to use 32-bit quantities to represent sectors, yes? Why didn't it use sector_t? What are the implications of this? -- 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
