Re: [PATCH] mmc_test: Don't warn about not waiting for busy if controller can't do this
On Mon, 17 Jan 2011 17:00:31 + Pawel Moll pawel.m...@arm.com wrote: If the MMC host controller does not support waiting for card signaling busy state (MMC_CAP_WAIT_WHILE_BUSY cap), there is no point in prining the relevant warning message. Signed-off-by: Pawel Moll pawel.m...@arm.com --- drivers/mmc/card/mmc_test.c |7 --- 1 files changed, 4 insertions(+), 3 deletions(-) Seems straight forward. Reviewed-by: Matt Fleming m...@console-pimps.org -- 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/2] dw_mmc: Run card detect tasklet during slot initialisation.
On Fri, 4 Feb 2011 11:17:54 + Will Newton will.new...@gmail.com wrote: We need to run the card detect tasklet at the end of slot initialisation as it is possible that a card has been inserted prior to boot, so we miss the insertion interrupt and now the card is sitting there inserted but with no power to it. So when powering up the board with a card already inserted, an interrupt isn't generated? If that's the case then we haven't missed an interrupt as one was never generated, right? If the answer to the above questions is yes, then you can add my Reviewed-by (though it might be worth changing the bit about missing an interrupt in the commit message). Otherwise, I would have expected the usual interrupt machinery to take care of detecting the inserted card? -- 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] dw_mmc: Add Synopsys DesignWare mmc host driver.
On Wed, Dec 08, 2010 at 02:21:05PM +, Will Newton wrote: This adds the mmc host driver for the Synopsys DesignWare mmc host controller, found in a number of embedded SoC designs. Signed-off-by: Will Newton will.new...@imgtec.com --- drivers/mmc/host/Kconfig | 15 + drivers/mmc/host/Makefile |1 + drivers/mmc/host/dw_mmc.c | 1806 drivers/mmc/host/dw_mmc.h | 153 include/linux/mmc/dw_mmc.h | 149 5 files changed, 2124 insertions(+), 0 deletions(-) create mode 100644 drivers/mmc/host/dw_mmc.c create mode 100644 drivers/mmc/host/dw_mmc.h create mode 100644 include/linux/mmc/dw_mmc.h - patch v2: make changes based on review by Matt Fleming. Reviewed-by: Matt Fleming m...@console-pimps.org -- 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 1/1]MMC: add support of sdhci-pxa driver
On Tue, Sep 28, 2010 at 11:23:35PM -0400, zhangfei gao wrote:
+
+ pxa-clk = clk_get(dev, PXA-SDHCLK);
+ if (IS_ERR(pxa-clk)) {
+ dev_err(dev, failed to get io clock\n);
+ ret = PTR_ERR(pxa-clk);
+ goto out;
+ }
+
+ pxa-res = request_mem_region(iomem-start, resource_size(iomem),
+ mmc_hostname(host-mmc));
+ if (!pxa-res) {
+ dev_err(pdev-dev, cannot request region\n);
+ ret = -EBUSY;
+ goto out;
+ }
+
+ host-ioaddr = ioremap(iomem-start, resource_size(iomem));
+ if (!host-ioaddr) {
+ dev_err(pdev-dev, failed to remap registers\n);
+ ret = -ENOMEM;
+ goto out;
+ }
+
+ host-hw_name = MMC;
+ host-ops = sdhci_pxa_ops;
+ host-irq = irq;
+ host-quirks = SDHCI_QUIRK_BROKEN_ADMA | SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
+
+ if (pdata-pxa_quirk PXA_QUIRK_BROKEN_CARD_DETECTION)
+ host-quirks |= SDHCI_QUIRK_BROKEN_CARD_DETECTION;
I don't think there's a good reason to define
PXA_QUIRK_BROKEN_CARD_DETECTION because its only use is to turn on
SDHCI_QUIRK_BROKEN_CARD_DETECTION. As Eric pointed out, you should
just use SDHCI_QUIRK_BROKEN_CARD_DETECTION directly. While adding new
sdhci quirks should be avoided, using the existing ones is fine :-)
+
+ ret = sdhci_add_host(host);
+ if (ret) {
+ dev_err(pdev-dev, failed to add host\n);
+ goto out;
+ }
+
+ if (pxa-pdata-max_speed)
+ host-mmc-f_max = pxa-pdata-max_speed;
+
+ platform_set_drvdata(pdev, host);
+
+ return 0;
+out:
+ if (host) {
+ if (host-ioaddr)
+ iounmap(host-ioaddr);
+ if (pxa-res)
+ release_mem_region(pxa-res-start,
+ resource_size(pxa-res));
+ sdhci_free_host(host);
+ }
Aren't you missing a clk_put() here?
--
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 V2 0/2] MMC removable helper function
Chris, I've rebased this mmc_assume_removable patch series against mmc-next and fixed up the compilation breakage with allmodconfig. Note, I've left your Signed-off-by on Jaehoon's patch because you modified the patch slightly (and because it's going through your tree anyway). I hope that's OK. Jaehoon Chung (1): mmc: sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case Matt Fleming (1): mmc: Add helper function to check if a card is removable drivers/mmc/core/core.c |1 + drivers/mmc/core/core.h |1 - drivers/mmc/core/mmc.c |2 +- drivers/mmc/core/sd.c|2 +- drivers/mmc/host/sdhci.c |3 ++- include/linux/mmc/host.h |8 6 files changed, 13 insertions(+), 4 deletions(-) -- 1.7.2.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
[PATCH V2 2/2] mmc: sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case
From: Jaehoon Chung jh80.ch...@samsung.com When a controller requires SDHCI_QUIRK_BROKEN_CARD_DETECTION, we poll for card insertion/removal, and that creates interrupts. There's no need to be doing this if we have a non-removable card. This patch requires cards to be removable before we're willing to set MMC_CAP_NEEDS_POLL. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Acked-by: Kyungmin Park kyungmin.p...@samsung.com Acked-by: Matt Fleming m...@console-pimps.org [cjb: modified changelog and code indentation] Signed-off-by: Chris Ball c...@laptop.org --- drivers/mmc/host/sdhci.c |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 5928b0a..d851315 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1847,7 +1847,8 @@ int sdhci_add_host(struct sdhci_host *host) if (caps SDHCI_CAN_DO_HISPD) mmc-caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; - if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + if ((host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + mmc_card_is_removable(mmc)) mmc-caps |= MMC_CAP_NEEDS_POLL; mmc-ocr_avail = 0; -- 1.7.2.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
[PATCH V2 1/2] mmc: Add helper function to check if a card is removable
There are two checks that need to be made when determining whether a
card is removable. A host controller may set MMC_CAP_NONREMOVABLE if the
controller does not support removing cards (e.g. eMMC), in which case
the card is physically non-removable. Also the 'mmc_assume_removable'
module parameter can be configured at module load time, in which case
the card may be logically non-removable.
A helper function keeps the logic in one place so that code always
checks both conditions.
Because this new function is likely to be called from modules we now
need to export the mmc_assume_removable symbol.
Signed-off-by: Matt Fleming m...@console-pimps.org
Acked-by: Kyungmin Park kyungmin.p...@samsung.com
Tested-by: Jaehoon Chung jh80.ch...@samsung.com
---
drivers/mmc/core/core.c |1 +
drivers/mmc/core/core.h |1 -
drivers/mmc/core/mmc.c |2 +-
drivers/mmc/core/sd.c|2 +-
include/linux/mmc/host.h |8
5 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 5db49b1..7c12612 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -58,6 +58,7 @@ int mmc_assume_removable;
#else
int mmc_assume_removable = 1;
#endif
+EXPORT_SYMBOL(mmc_assume_removable);
module_param_named(removable, mmc_assume_removable, bool, 0644);
MODULE_PARM_DESC(
removable,
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 9d9eef5..a2ca770 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -58,7 +58,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr);
/* Module parameters */
extern int use_spi_crc;
-extern int mmc_assume_removable;
/* Debugfs information for hosts and cards */
void mmc_add_host_debugfs(struct mmc_host *host);
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 6909a54..6570c03 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -685,7 +685,7 @@ static void mmc_attach_bus_ops(struct mmc_host *host)
{
const struct mmc_bus_ops *bus_ops;
- if (host-caps MMC_CAP_NONREMOVABLE || !mmc_assume_removable)
+ if (!mmc_card_is_removable(host))
bus_ops = mmc_ops_unsafe;
else
bus_ops = mmc_ops;
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 0f52410..bc745e1 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -750,7 +750,7 @@ static void mmc_sd_attach_bus_ops(struct mmc_host *host)
{
const struct mmc_bus_ops *bus_ops;
- if (host-caps MMC_CAP_NONREMOVABLE || !mmc_assume_removable)
+ if (!mmc_card_is_removable(host))
bus_ops = mmc_sd_ops_unsafe;
else
bus_ops = mmc_sd_ops;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index ded4017..23a4864 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -267,5 +267,13 @@ static inline void mmc_set_disable_delay(struct mmc_host
*host,
host-disable_delay = disable_delay;
}
+/* Module parameter */
+extern int mmc_assume_removable;
+
+static inline int mmc_card_is_removable(struct mmc_host *host)
+{
+ return (!(host-caps MMC_CAP_NONREMOVABLE) mmc_assume_removable);
+}
+
#endif
--
1.7.2.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 2/2] sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case
On Sun, Sep 26, 2010 at 03:31:22PM +0800, zhangfei gao wrote: On Thu, Sep 16, 2010 at 5:02 PM, Matt Fleming m...@console-pimps.org wrote: On Thu, Sep 16, 2010 at 03:20:08AM +0100, Chris Ball wrote: Hi Matt, On Wed, Sep 15, 2010 at 09:38:55PM +0100, Chris Ball wrote: On Wed, Sep 15, 2010 at 04:11:42PM +0100, Matt Fleming wrote: Chris, are you OK to pick this up (including Jaehoon's change)? Or would you prefer me to resubmit? Thanks, that's fine, I've applied both patches to mmc-next: This (patch 2/2) doesn't resolve symbols properly, so I've dropped it: Building modules, stage 2. MODPOST 448 modules ERROR: mmc_assume_removable [drivers/mmc/host/sdhci.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 There's no EXPORT_SYMBOL(mmc_assume_removable) in core/core.c, yet it's being referenced in host/sdhci.c. Bah! That'll teach me for not compiling an allmodconfig kernel. I'll fix this up and resubmit. -- 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 Any new patch of this, then we could re-use SDHCI_QUIRK_BROKEN_CARD_DETECTION :) Thanks a lot for the reminder! I've just re-sent these two patches. -- 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] tmio_mmc: Allow 2 byte requests in 4-bit mode
On Thu, Sep 23, 2010 at 08:11:26PM +0100, Ian Molton wrote: If its not already gone through... Acked-by: Ian Molton i...@mnementh.co.uk Cheers Ian. I think Sam applied this patch but was waiting for your Acked-by. -- 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 RESEND] sdhci-s3c: support clock enable/disable (clock-gating)
On Thu, Sep 16, 2010 at 03:46:50PM +0900, Jaehoon Chung wrote:
Hi all,
This is a RFC patch that support clock-gating for saving power consumption.
I found mmc_host_enable/mmc_host_disable function in core.c
(using MMC_CAP_DSIABLE. i think that use when host enable/disable)
So, i used that functions and implemented some functions in sdhci-s3c.c
sdhci.c
i want any feedback. how do you think about this patch?
Plz let me know...
Thank you all
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/host/sdhci-s3c.c | 36
drivers/mmc/host/sdhci.c | 30 ++
drivers/mmc/host/sdhci.h |4
3 files changed, 70 insertions(+), 0 deletions(-)
[...]
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 401527d..fa2e55d 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1245,7 +1245,37 @@ out:
spin_unlock_irqrestore(host-lock, flags);
}
+static int sdhci_enable_clk(struct mmc_host *mmc)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+ int ret = 0;
+
+ if (host-old_clock != 0 host-clock == 0) {
+ if (host-ops-enable)
+ ret = host-ops-enable(host);
+ sdhci_set_clock(host, host-old_clock);
+ }
+
+ return ret;
+}
+
+static int sdhci_disable_clk(struct mmc_host *mmc, int lazy)
+{
+ struct sdhci_host *host = mmc_priv(mmc);
+ int ret = 0;
+
+ if (host-clock != 0) {
+ host-old_clock = host-clock;
+ sdhci_set_clock(host, 0);
+ if (host-ops-disable)
+ ret = host-ops-disable(host, lazy);
+ }
+ return ret;
+}
+
static const struct mmc_host_ops sdhci_ops = {
+ .enable = sdhci_enable_clk,
+ .disable= sdhci_disable_clk,
.request= sdhci_request,
.set_ios= sdhci_set_ios,
.get_ro = sdhci_get_ro,
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index d316bc7..0c6f143 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -278,6 +278,8 @@ struct sdhci_host {
unsigned inttimeout_clk;/* Timeout freq (KHz) */
unsigned intclock; /* Current clock (MHz) */
+ unsigned intold_clock; /* Old clock (MHz) */
+ unsigned intclk_cnt;/* Clock user count */
u8 pwr;/* Current voltage */
struct mmc_request *mrq; /* Current request */
@@ -323,6 +325,8 @@ struct sdhci_ops {
unsigned int(*get_max_clock)(struct sdhci_host *host);
unsigned int(*get_min_clock)(struct sdhci_host *host);
unsigned int(*get_timeout_clock)(struct sdhci_host *host);
+ int (*enable)(struct sdhci_host *host);
+ int (*disable)(struct sdhci_host *host, int lazy);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
I could have misunderstood something, but do you really need this new
'old_clock' member? Is the previous clock value not stored in
host-ios.clock?
--
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: [Bugme-new] [Bug 18602] New: mmc_block / tifm_sd not completely registering when a new sd card is inserted
(CC'ing maintainer) On Wed, Sep 15, 2010 at 12:38:54PM -0700, Andrew Morton wrote: (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Wed, 15 Sep 2010 13:48:30 GMT bugzilla-dae...@bugzilla.kernel.org wrote: https://bugzilla.kernel.org/show_bug.cgi?id=18602 Summary: mmc_block / tifm_sd not completely registering when a new sd card is inserted Product: Drivers Version: 2.5 Kernel Version: 2.6.35.4 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: MMC/SD AssignedTo: drivers_mmc...@kernel-bugs.osdl.org ReportedBy: pi...@pioto.org Regression: No After I insert an SD card once after booting, mount it, unmount it, then pop out the card, if I try to insert the card again, the /dev/mmcblk* devices do not show again. I have to unload the mmc_block and tifm_sd (and mmc_core) modules, then reload them, in order for the device node to apear again. I don't think this was always the case, but I can't remember the specific version that this problem first occurred. On the first insertion cycle, dmsg looks like this: [204702.558153] tifm_core: MMC/SD card detected in socket 0:1 [204702.834915] mmc0: new SD card at address 4f9a [204702.878743] mmcblk0: mmc0:4f9a SD02G 1.83 GiB [204702.878802] mmcblk0: p1 # ... do stuff with the card [204908.381864] tifm0 : demand removing card from socket 0:1 [204908.381936] mmc0: card 4f9a removed # now, insert the card again [204913.581176] tifm_core: MMC/SD card detected in socket 0:1 # and remove it again [204926.188570] tifm0 : demand removing card from socket 0:1 lspci identifies my SD card reader as: 0f:06.3 SD Host controller: Texas Instruments PCIxx12 SDA Standard Compliant SD Host Controller Any advice would be appreciated. Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case
On Thu, Sep 16, 2010 at 03:20:08AM +0100, Chris Ball wrote: Hi Matt, On Wed, Sep 15, 2010 at 09:38:55PM +0100, Chris Ball wrote: On Wed, Sep 15, 2010 at 04:11:42PM +0100, Matt Fleming wrote: Chris, are you OK to pick this up (including Jaehoon's change)? Or would you prefer me to resubmit? Thanks, that's fine, I've applied both patches to mmc-next: This (patch 2/2) doesn't resolve symbols properly, so I've dropped it: Building modules, stage 2. MODPOST 448 modules ERROR: mmc_assume_removable [drivers/mmc/host/sdhci.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 There's no EXPORT_SYMBOL(mmc_assume_removable) in core/core.c, yet it's being referenced in host/sdhci.c. Bah! That'll teach me for not compiling an allmodconfig kernel. I'll fix this up and resubmit. -- 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/2] sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case
On Wed, Sep 08, 2010 at 10:27:14AM +0900, Jaehoon Chung wrote: Matt Fleming wrote: On Thu, Sep 02, 2010 at 05:51:45PM +0900, Jaehoon Chung wrote: Matt Fleming wrote: From: Jaehoon Chung jh80.ch...@samsung.com If controller use SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk, controller need always polling detect In this case, always generated interrupt.Because controller checked card status. I think that is not efficiently. But if card is nonremovable, we need not always polling. So i added the check-point which is nonremovable or not Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- drivers/mmc/host/sdhci.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index f6be963..3111859 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1827,8 +1827,9 @@ int sdhci_add_host(struct sdhci_host *host) if (caps SDHCI_CAN_DO_HISPD) mmc-caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; - if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) - mmc-caps |= MMC_CAP_NEEDS_POLL; + if ((host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + !mmc_card_is_removable(mmc)) + mmc-caps |= MMC_CAP_NEEDS_POLL; mmc-ocr_avail = 0; if (caps SDHCI_CAN_VDD_330) !mmc_card_is_removable(mmc) is right? i think that is mmc_card_is_removable.. because when card is removable, host controller needs polling. + if ((host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + *mmc_card_is_removable(mmc))* + mmc-caps |= MMC_CAP_NEEDS_POLL; Sorry, I messed up the logic here. You're completely correct. With this change and patch 2/2 does your controller function correctly? yes. i changed and applied this patch, then i tested in my controller. it's working well. Chris, are you OK to pick this up (including Jaehoon's change)? Or would you prefer me to resubmit? -- 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/2] sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case
On Wed, Sep 15, 2010 at 04:11:42PM +0100, Matt Fleming wrote: On Wed, Sep 08, 2010 at 10:27:14AM +0900, Jaehoon Chung wrote: Matt Fleming wrote: On Thu, Sep 02, 2010 at 05:51:45PM +0900, Jaehoon Chung wrote: Matt Fleming wrote: From: Jaehoon Chung jh80.ch...@samsung.com If controller use SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk, controller need always polling detect In this case, always generated interrupt.Because controller checked card status. I think that is not efficiently. But if card is nonremovable, we need not always polling. So i added the check-point which is nonremovable or not Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- drivers/mmc/host/sdhci.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index f6be963..3111859 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1827,8 +1827,9 @@ int sdhci_add_host(struct sdhci_host *host) if (caps SDHCI_CAN_DO_HISPD) mmc-caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; - if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) - mmc-caps |= MMC_CAP_NEEDS_POLL; + if ((host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + !mmc_card_is_removable(mmc)) + mmc-caps |= MMC_CAP_NEEDS_POLL; mmc-ocr_avail = 0; if (caps SDHCI_CAN_VDD_330) !mmc_card_is_removable(mmc) is right? i think that is mmc_card_is_removable.. because when card is removable, host controller needs polling. +if ((host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) +*mmc_card_is_removable(mmc))* +mmc-caps |= MMC_CAP_NEEDS_POLL; Sorry, I messed up the logic here. You're completely correct. With this change and patch 2/2 does your controller function correctly? yes. i changed and applied this patch, then i tested in my controller. it's working well. Chris, are you OK to pick this up (including Jaehoon's change)? Or would you prefer me to resubmit? Argh, sorry! I hit send before changing the To: field. -- 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: + arm-samsung-mmc-fix-build-error-when-both-dma-and-pio-mode-selected.patch added to -mm tree
On Fri, Aug 27, 2010 at 09:23:47PM +0100, Matt Fleming wrote: Best get Ben's opinion on this (now Cc'd). OK, it's been over a week and Ben hasn't replied. This fixes a build error so shouldn't wait any longer. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4] mmc: Make ID freq configurable
On Sun, Sep 05, 2010 at 09:43:36PM +0100, Chris Ball wrote:
Actually, mmc_attach_{sd,mmc}() both do release the host as part of
their failure case, so I don't think there's a problem with these two.
Ah, yep you're right, I missed that.
--
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 3/3] MMC/SD: add callback function to detect card
On Tue, Aug 31, 2010 at 10:57:25PM +0300, Adrian Hunter wrote: But now I think it should be in the mmc_rescan() function because that is where the main other use of .get_cd() is, and also the only call of .detect(). That's a very good point. Aren't we duplicating the code in mmc_rescan() with this patch? If there's something that mmc_rescan() isn't doing, wouldn't it be better to modify that function instead of pushing it down into the bus_ops detect functions? -- 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/2] sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case
On Thu, Sep 02, 2010 at 05:51:45PM +0900, Jaehoon Chung wrote: Matt Fleming wrote: From: Jaehoon Chung jh80.ch...@samsung.com If controller use SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk, controller need always polling detect In this case, always generated interrupt.Because controller checked card status. I think that is not efficiently. But if card is nonremovable, we need not always polling. So i added the check-point which is nonremovable or not Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- drivers/mmc/host/sdhci.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index f6be963..3111859 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1827,8 +1827,9 @@ int sdhci_add_host(struct sdhci_host *host) if (caps SDHCI_CAN_DO_HISPD) mmc-caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; - if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) - mmc-caps |= MMC_CAP_NEEDS_POLL; + if ((host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + !mmc_card_is_removable(mmc)) + mmc-caps |= MMC_CAP_NEEDS_POLL; mmc-ocr_avail = 0; if (caps SDHCI_CAN_VDD_330) !mmc_card_is_removable(mmc) is right? i think that is mmc_card_is_removable.. because when card is removable, host controller needs polling. + if ((host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + *mmc_card_is_removable(mmc))* + mmc-caps |= MMC_CAP_NEEDS_POLL; Sorry, I messed up the logic here. You're completely correct. With this change and patch 2/2 does your controller function correctly? -- 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 patches in-flight.
On Wed, Sep 01, 2010 at 07:49:02PM -0400, Chris Ball wrote: Hi, Here's an attempt to summarize the state of MMC patches submitted to linux-mmc@ that haven't been merged. Feel free to correct anything, especially if you have a patch that you think is waiting to be merged that I've listed without -, or that I haven't listed at all. Please also consider reviewing any patches in the review state. Thanks! Patch author | Patch subject| Next step [...] Yusuke Goda| tmio_mmc: Revise a limit of the data size| resubmit This patch is actually now called, [PATCH v2] tmio_mmc: Allow 2 byte requests in 4-bit mode and it's in the testing phase. -- 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 3/3] MMC/SD: add callback function to detect card
On Fri, Aug 27, 2010 at 08:05:13PM +0100, Chris Ball wrote:
Hi,
On Fri, Dec 04, 2009 at 03:55:09PM +0800, r66...@freescale.com wrote:
From: Jerry Huang chang-ming.hu...@freescale.com
Add callback function to check if the card has been removed.
in order to check if the card has been removed, the function
mmc_send_status will send commad CMD13 to card and ask the card to send its
status register to driver, which will generate interrupt repeatly and make
the system bad.
Therefore, get_cd callback is used to detect the card if the driver has.
Signed-off-by: Jerry Huang chang-ming.hu...@freescale.com
---
drivers/mmc/core/mmc.c |5 -
drivers/mmc/core/sd.c |5 -
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 06084db..c5c676d 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -494,7 +494,10 @@ static void mmc_detect(struct mmc_host *host)
/*
* Just check if our card has been removed.
*/
- err = mmc_send_status(host-card, NULL);
+ if (host-ops-get_cd)
+ err = !host-ops-get_cd(host);
+ else
+ err = mmc_send_status(host-card, NULL);
mmc_release_host(host);
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index cd81c39..3cf1f38 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -548,7 +548,10 @@ static void mmc_sd_detect(struct mmc_host *host)
/*
* Just check if our card has been removed.
*/
- err = mmc_send_status(host-card, NULL);
+ if (host-ops-get_cd)
+ err = !host-ops-get_cd(host);
+ else
+ err = mmc_send_status(host-card, NULL);
mmc_release_host(host);
--
1.6.4
This patchset wasn't replied to -- any comments on it from the list?
I think this change makes sense, although it needs to be a bit smarter
with error handling because the get_cd() functions can return -ENOSYS if
they are not implemented (but the function pointer is still valid).
int err = 0;
if (host-ops-get_cd) {
err = host-ops-get_cd(host);
if (err = 0)
err = !err;
}
if (!host-ops-get_cd || err 0)
err = mmc_send_status(host-card, NULL);
Thoughts?
--
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 v2] mmc: Add helper function to check if a card is removable
There are two checks that need to be made when determining whether a
card is removable. A host controller may set MMC_CAP_NONREMOVABLE if the
controller does not support removing cards (e.g. eMMC), in which case
the card is physically non-removable. Also the 'mmc_assume_removable'
module parameter can be configured at module load time, in which case
the card may be logically non-removable.
A helper function keeps the logic in one place so that code always
checks both conditions.
Signed-off-by: Matt Fleming m...@console-pimps.org
---
Guys, it'd be good if someone could give me a Tested-by: for this patch
just to make sure that it works as intended. Jaehoon, Kyungmin, does
this patch work for you?
drivers/mmc/core/core.h |1 -
drivers/mmc/core/mmc.c |2 +-
drivers/mmc/core/sd.c|2 +-
include/linux/mmc/host.h |8
4 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/core/core.h b/drivers/mmc/core/core.h
index 9d9eef5..a2ca770 100644
--- a/drivers/mmc/core/core.h
+++ b/drivers/mmc/core/core.h
@@ -58,7 +58,6 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr);
/* Module parameters */
extern int use_spi_crc;
-extern int mmc_assume_removable;
/* Debugfs information for hosts and cards */
void mmc_add_host_debugfs(struct mmc_host *host);
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index dcfc921..66c4a59 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -718,7 +718,7 @@ static void mmc_attach_bus_ops(struct mmc_host *host)
{
const struct mmc_bus_ops *bus_ops;
- if (host-caps MMC_CAP_NONREMOVABLE || !mmc_assume_removable)
+ if (!mmc_card_is_removable(host))
bus_ops = mmc_ops_unsafe;
else
bus_ops = mmc_ops;
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 0f52410..bc745e1 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -750,7 +750,7 @@ static void mmc_sd_attach_bus_ops(struct mmc_host *host)
{
const struct mmc_bus_ops *bus_ops;
- if (host-caps MMC_CAP_NONREMOVABLE || !mmc_assume_removable)
+ if (!mmc_card_is_removable(host))
bus_ops = mmc_sd_ops_unsafe;
else
bus_ops = mmc_sd_ops;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 09dbb90..c920cfc 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -272,5 +272,13 @@ static inline void mmc_set_disable_delay(struct mmc_host
*host,
host-disable_delay = disable_delay;
}
+/* Module parameter */
+extern int mmc_assume_removable;
+
+static inline int mmc_card_is_removable(struct mmc_host *host)
+{
+ return (!(host-caps MMC_CAP_NONREMOVABLE) mmc_assume_removable);
+}
+
#endif
--
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
Re: [PATCH 1/3] omap4 hsmmc : Adding card detect support for MMC1
On Mon, Aug 30, 2010 at 11:18:23PM +0530, kishore kadiyala wrote:
Adding card detect callback function and card detect configuration
function for MMC1 Controller.
Card detect configuration function does initial configuration of the
MMC Control PullUp-PullDown registers of Phoenix.
For MMC1 Controller, Card detect interrupt source is
twl6030 and the card detect call back function provides card present/absent
status by reading MMC Control register.
Cc: Tony Lindgren t...@atomide.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Andrew Morton a...@linux-foundation.org
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
[...]
@@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
+ if (twl_class_is_6030()) {
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+ REG_INT_MSK_STS_B);
+ }
+
+ /*
+ * Intially Configuring MMC_CTRL for receving interrupts
+ * Card status on TWL6030 for MMC1
+ */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read MMCCTRL, error %d\n, ret);
+ return ret;
+ }
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
+ }
Shouldn't this be
pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
return ret;
?
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
+ ret);
Shouldn't this be,
pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
ret);
return ret;
?
--
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: disable MMC_CAP_NEEDS_POLL in nonremovable case
On Fri, Aug 27, 2010 at 07:55:44PM +0800, Gao, Yunpeng wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Kyungmin Park Sent: Friday, August 27, 2010 3:15 PM To: Matt Fleming Cc: Jaehoon Chung; linux-mmc@vger.kernel.org; Marek Szyprowski; Andrew Morton; Ben Dooks Subject: Re: [PATCH] sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case On Fri, Aug 27, 2010 at 4:09 PM, Matt Fleming m...@console-pimps.org wrote: On Fri, Aug 27, 2010 at 03:34:54PM +0900, Jaehoon Chung wrote: If controller use SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk, controller need always polling detect In this case, always generated interrupt.Because controller checked card status. I think that is not efficiently. But if card is nonremovable, we need not always polling. So i added the check-point which is nonremovable or not Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- drivers/mmc/host/sdhci.c | 5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 401527d..4bc5d3c 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1826,8 +1826,9 @@ int sdhci_add_host(struct sdhci_host *host) if (caps SDHCI_CAN_DO_HISPD) mmc-caps |= MMC_CAP_SD_HIGHSPEED; - if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) - mmc-caps |= MMC_CAP_NEEDS_POLL; + if ((host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + !(host-mmc-caps MMC_CAP_NONREMOVABLE)) + mmc-caps |= MMC_CAP_NEEDS_POLL; Since module parameter 'mmc_assume_removable' (defined in core.c) also controls the nonremovable attribute of the mmc/eMMC device, will it be better to also check value of 'mmc_assume_removable' here? Thanks. Yeah, I think that check is also needed. I've got a couple of patches that I'll reply to this thread with. There should really be a helper function for determining when a card is either physially non-removable (eMMC) or logically non-removable (mmc_assume_removable == 0). -- 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 1/2] mmc: Add helper function to check if a card is removable
There are two checks that need to be made when determining whether a
card is removable. A host controller may set MMC_CAP_NONREMOVABLE if the
controller does not support removing cards (e.g. eMMC), in which case
the card is physically non-removable. Also the 'mmc_assume_removable'
module parameter can be configured at module load time, in which case
the card may be logically non-removable.
A helper function keeps the logic in one place so that code always
checks both conditions.
Signed-off-by: Matt Fleming m...@console-pimps.org
---
drivers/mmc/core/mmc.c |2 +-
drivers/mmc/core/sd.c|2 +-
include/linux/mmc/host.h |7 +++
3 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index dcfc921..66c4a59 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -718,7 +718,7 @@ static void mmc_attach_bus_ops(struct mmc_host *host)
{
const struct mmc_bus_ops *bus_ops;
- if (host-caps MMC_CAP_NONREMOVABLE || !mmc_assume_removable)
+ if (!mmc_card_is_removable(host))
bus_ops = mmc_ops_unsafe;
else
bus_ops = mmc_ops;
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 0f52410..bc745e1 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -750,7 +750,7 @@ static void mmc_sd_attach_bus_ops(struct mmc_host *host)
{
const struct mmc_bus_ops *bus_ops;
- if (host-caps MMC_CAP_NONREMOVABLE || !mmc_assume_removable)
+ if (!mmc_card_is_removable(host))
bus_ops = mmc_sd_ops_unsafe;
else
bus_ops = mmc_sd_ops;
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 09dbb90..cf4b71f 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -272,5 +272,12 @@ static inline void mmc_set_disable_delay(struct mmc_host
*host,
host-disable_delay = disable_delay;
}
+extern int mmc_assume_removable;
+
+static inline int mmc_card_is_removable(struct mmc_host *host)
+{
+ return (!(host-caps MMC_CAP_NONREMOVABLE) || mmc_assume_removable);
+}
+
#endif
--
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
[PATCH 2/2] sdhci: disable MMC_CAP_NEEDS_POLL in nonremovable case
From: Jaehoon Chung jh80.ch...@samsung.com If controller use SDHCI_QUIRK_BROKEN_CARD_DETECTION quirk, controller need always polling detect In this case, always generated interrupt.Because controller checked card status. I think that is not efficiently. But if card is nonremovable, we need not always polling. So i added the check-point which is nonremovable or not Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com --- drivers/mmc/host/sdhci.c |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index f6be963..3111859 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1827,8 +1827,9 @@ int sdhci_add_host(struct sdhci_host *host) if (caps SDHCI_CAN_DO_HISPD) mmc-caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; - if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) - mmc-caps |= MMC_CAP_NEEDS_POLL; + if ((host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) + !mmc_card_is_removable(mmc)) + mmc-caps |= MMC_CAP_NEEDS_POLL; mmc-ocr_avail = 0; if (caps SDHCI_CAN_VDD_330) -- 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
Re: [PATCH 1/2] mmc: Add helper function to check if a card is removable
On Sat, Aug 28, 2010 at 03:13:09PM +0100, Ben Hutchings wrote:
On Sat, 2010-08-28 at 14:53 +0100, Matt Fleming wrote:
[...]
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -272,5 +272,12 @@ static inline void mmc_set_disable_delay(struct
mmc_host *host,
host-disable_delay = disable_delay;
}
+extern int mmc_assume_removable;
This variable is already declared in drivers/mmc/core/core.h. Either
remove the declaration from there or define the following function there
instead of here.
Sure, I'll remove the declaration from drivers/mmc/core/core.h.
+static inline int mmc_card_is_removable(struct mmc_host *host)
+{
+ return (!(host-caps MMC_CAP_NONREMOVABLE) || mmc_assume_removable);
+}
+
That '||' should be an ''.
Oops, yes, it should be.
Thanks for the review.
--
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 RESEND] at91_mci.c: use resource_size()
[Adding maintainer to CC]
On Fri, Aug 27, 2010 at 08:08:13PM +0100, Chris Ball wrote:
From: H Hartley Sweeten hswee...@visionengravers.com
Date: Mon, 14 Dec 2009 14:10:26 -0500
Use resource_size().
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
[cjb: rebased patch against Linus]
Signed-off-by: Chris Ball c...@laptop.org
---
drivers/mmc/host/at91_mci.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/at91_mci.c b/drivers/mmc/host/at91_mci.c
index 5f3a599..3995db3 100644
--- a/drivers/mmc/host/at91_mci.c
+++ b/drivers/mmc/host/at91_mci.c
@@ -927,7 +927,7 @@ static int __init at91_mci_probe(struct platform_device
*pdev)
if (!res)
return -ENXIO;
- if (!request_mem_region(res-start, res-end - res-start + 1,
DRIVER_NAME))
+ if (!request_mem_region(res-start, resource_size(res), DRIVER_NAME))
return -EBUSY;
mmc = mmc_alloc_host(sizeof(struct at91mci_host), pdev-dev);
@@ -1016,7 +1016,7 @@ static int __init at91_mci_probe(struct platform_device
*pdev)
/*
* Map I/O region
*/
- host-baseaddr = ioremap(res-start, res-end - res-start + 1);
+ host-baseaddr = ioremap(res-start, resource_size(res));
if (!host-baseaddr) {
ret = -ENOMEM;
goto fail1;
@@ -1092,7 +1092,7 @@ fail4b:
fail5:
mmc_free_host(mmc);
fail6:
- release_mem_region(res-start, res-end - res-start + 1);
+ release_mem_region(res-start, resource_size(res));
dev_err(pdev-dev, probe failed, err %d\n, ret);
return ret;
}
@@ -1137,7 +1137,7 @@ static int __exit at91_mci_remove(struct
platform_device *pdev)
iounmap(host-baseaddr);
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- release_mem_region(res-start, res-end - res-start + 1);
+ release_mem_region(res-start, resource_size(res));
mmc_free_host(mmc);
platform_set_drvdata(pdev, NULL);
--
1.7.0.1
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] atmel-mci.c: use resource size()
[Adding Nicolas to Cc] On Fri, Aug 27, 2010 at 08:09:55PM +0100, Chris Ball wrote: From: H Hartley Sweeten hswee...@visionengravers.com Date: Mon, 14 Dec 2009 14:11:56 -0500 Use resource_size(). Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com [cjb: rebased patch against Linus] Signed-off-by: Chris Ball c...@laptop.org --- drivers/mmc/host/atmel-mci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c index 95ef864..1d4e546 100644 --- a/drivers/mmc/host/atmel-mci.c +++ b/drivers/mmc/host/atmel-mci.c @@ -1777,7 +1777,7 @@ static int __init atmci_probe(struct platform_device *pdev) } ret = -ENOMEM; - host-regs = ioremap(regs-start, regs-end - regs-start + 1); + host-regs = ioremap(regs-start, resource_size(regs)); if (!host-regs) goto err_ioremap; -- 1.7.0.1 -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RESEND] au1xmmc.c: use resource_size()
[Adding maintainer to CC]
On Fri, Aug 27, 2010 at 08:11:34PM +0100, Chris Ball wrote:
From: H Hartley Sweeten hswee...@visionengravers.com
Date: Mon, 14 Dec 2009 14:28:06 -0500
Use resource_size().
Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com
[cjb: rebased patch against Linus]
Signed-off-by: Chris Ball c...@laptop.org
---
drivers/mmc/host/au1xmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/au1xmmc.c b/drivers/mmc/host/au1xmmc.c
index c8da5d3..e14b866 100644
--- a/drivers/mmc/host/au1xmmc.c
+++ b/drivers/mmc/host/au1xmmc.c
@@ -964,7 +964,7 @@ static int __devinit au1xmmc_probe(struct platform_device
*pdev)
goto out1;
}
- host-ioarea = request_mem_region(r-start, r-end - r-start + 1,
+ host-ioarea = request_mem_region(r-start, resource_size(r),
pdev-name);
if (!host-ioarea) {
dev_err(pdev-dev, mmio already in use\n);
--
1.7.0.1
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sdhci - add public definition of quirks
On Fri, Aug 27, 2010 at 08:28:23PM +0100, Chris Ball wrote: Hi, Any comments on this patch from the list? Are there no users of this patch? Who would want this? We generally don't add infrastructure to the kernel without a user. -- 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: + arm-samsung-mmc-fix-build-error-when-both-dma-and-pio-mode-selected.patch added to -mm tree
Best get Ben's opinion on this (now Cc'd). On Fri, Aug 27, 2010 at 01:03:39PM -0700, Andrew Morton wrote: The patch titled ARM: SAMSUNG: MMC: fix build error when both DMA and PIO mode selected has been added to the -mm tree. Its filename is arm-samsung-mmc-fix-build-error-when-both-dma-and-pio-mode-selected.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: ARM: SAMSUNG: MMC: fix build error when both DMA and PIO mode selected From: Jiri Pinkava jiri.pink...@vscht.cz Date: Tue, 25 May 2010 09:48:58 +0200 [cjb: fix line-wrapped patch] Signed-off-by: Jiri Pinkava jiri.pink...@vscht.cz Signed-off-by: Chris Ball c...@laptop.org Cc: Matt Fleming m...@console-pimps.org Cc: Russell King r...@arm.linux.org.uk Cc: linux-mmc@vger.kernel.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/mmc/host/s3cmci.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/mmc/host/s3cmci.c~arm-samsung-mmc-fix-build-error-when-both-dma-and-pio-mode-selected drivers/mmc/host/s3cmci.c --- a/drivers/mmc/host/s3cmci.c~arm-samsung-mmc-fix-build-error-when-both-dma-and-pio-mode-selected +++ a/drivers/mmc/host/s3cmci.c @@ -1600,7 +1600,7 @@ static int __devinit s3cmci_probe(struct host-pio_active= XFER_NONE; #ifdef CONFIG_MMC_S3C_PIODMA - host-dodma = host-pdata-dma; + host-dodma = host-pdata-use_dma; #endif host-mem = platform_get_resource(pdev, IORESOURCE_MEM, 0); _ Patches currently in -mm which might be from jiri.pink...@vscht.cz are arm-samsung-mmc-fix-build-error-when-both-dma-and-pio-mode-selected.patch -- 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 RESEND] au1xmmc.c: use resource_size()
On Sat, Aug 28, 2010 at 12:38:56AM +0200, Manuel Lauss wrote: Wasn't that posted ages ago? I'm fine with it. Yep, but it never got merged. Thanks for the ACK. -- 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] tmio_mmc: Prevents unexpected status clear
On Thu, 26 Aug 2010 09:53:33 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Hi Matt, Andrew
Andrew Morton wrote:
On Wed, 25 Aug 2010 23:11:07 +0100
Matt Fleming m...@console-pimps.org wrote:
On Thu, 15 Jul 2010 13:25:52 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Tue, 13 Jul 2010 10:16:39 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Hi Andrew
Thank you for your comment.
#define ack_mmc_irqs(host, i) \
do { \
- u32 mask;\
- mask = sd_ctrl_read32((host), CTL_STATUS); \
- mask = ~((i) TMIO_MASK_IRQ); \
- sd_ctrl_write32((host), CTL_STATUS, mask); \
+ sd_ctrl_write32((host), CTL_STATUS, ~(i)); \
} while (0)
Can we have a better changelog please?
What was wrong with the old code?
How does the patch fix it?
What are the user-visible runtime effects of the bug?
(It looks like that was a pretty gross bug - how did it pass testing??)
Example
- CMD53(Single block read / Received data size : 64Byte)
1) Send CMD53
2) Receive CMD53 response
3) Call tmio_mmc_cmd_irq(host, status);
-- original code
#define ack_mmc_irqs(host, i) \
do { \
u32 mask;\
mask = sd_ctrl_read32((host), CTL_STATUS); \
case 1
mask = ~((i) TMIO_MASK_IRQ); \
case 2
sd_ctrl_write32((host), CTL_STATUS, mask); \
} while (0)
-
TMIO_STAT_RXRDY status will be cleared by sd_ctrl_write32((host),
CTL_STATUS, mask);
if TMIO_STAT_RXRDY becomes effective between case 1 and case 2
.
This causes the phenomenon that a TMIO_STAT_RXRDY interrupt does not
occur.
When received data are small, it rarely occurs.
OK..
But with both this patch and tmio_mmc-revise-limit-on-data-size.patch
the changelogs fail to describe the impact of the bug upon our users.
So when I sit here trying to work out whether the patches should be
applied to 2.6.35 and whether they should be backported into -stable, I
don't have enough information.
What are your thoughts on this?
Goda, do you have any more ideas on updating the changelog for this
patch? It looks to me like this patch is a candidate for stable
(whereas the tmio_mmc-revise-limit-on-data-size.patch is not, sorry
about replying to that one first, I'm reading my mail backwards)
because, without this patch, it's possible to miss interrupts because
the ack_mmc_irqs() macro clears bit in the CTL_STATUS register that it
should not do? Is that correct?
If that is the case then would this be a more appropriate changelog,
tmio_mmc: Don't clear unhandled pending interrupts
Previously, it was possible for ack_mmc_irqs() to clear pending
interrupt bits in the CTL_STATUS register, even though the interrupt
handler had not been called. This was because of a race that existed
when doing a read-modify-write sequence on CTL_STATUS. After the
read step in this sequence, if an interrupt occurred (causing one of the
bits in CTL_STATUS to be set) the write step would inadvertently clear
it.
This patch eliminates this race by only writing to CTL_STATUS and
clearing the interrupts that were passed as an argument to
ack_mmc_irqs().
hm, I seem to have secretly dropped this patch as well.
Oh well. I restored it as
tmio_mmc-dont-clear-unhandled-pending-interrupts.patch and tagged it
for a -stable backport. Unless I hear otherwise I'll send it in to
Linus when we return from Brazil a couple of weeks from now.
Thank you for your actions.
I agree to new changelog.
In fact, I contributed the patch which changed changelog.
http://www.spinics.net/lists/linux-mmc/msg02623.html
http://www.spinics.net/lists/linux-mmc/msg02624.html
However, these will not be necessary.
Oh, I missed these. Sorry!
Andrew, this bit of Goda's changelog is worth adding to
tmio_mmc-dont-clear-unhandled-pending-interrupts.patch
Observed with the TMIO_STAT_RXRDY bit together with CMD53
on AR6002 and BCM4318 SDIO cards in polled mode.
--
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-add-support-for-the-marvell-platform-sdhci-controller.patch added to -mm tree
On Wed, 25 Aug 2010 16:16:25 -0700 a...@linux-foundation.org wrote: The patch titled mmx: add support for the Marvell platform SDHCI controller has been added to the -mm tree. Its filename is mmc-add-support-for-the-marvell-platform-sdhci-controller.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: mmx: add support for the Marvell platform SDHCI controller From: Saeed Bishara sa...@marvell.com Implement a driver for the platfrom SDHCI controllers that is found on some of Marvell's SoC's. Signed-off-by: Saeed Bishara sa...@marvell.com Cc: 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| 12 + drivers/mmc/host/Makefile |1 drivers/mmc/host/sdhci-mv.c | 243 ++ 3 files changed, 256 insertions(+) Reviewed-by: Matt Fleming m...@console-pimps.org -- 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] tmio_mmc: Revise a limit of the data size
On Thu, Aug 26, 2010 at 02:50:09AM +0100, Ian Molton wrote: Probably dropped because I complained about two things, 1) The patch doesnt check what the hardware is underneath before arbitrarily changing the parameters relied on by some hardware Has anyone thought about adding a caps or flags field to the tmio_mmc_host structure so that platform code set a bit if it can't do 2-byte data block transfers? -- 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] tmio_mmc: Prevents unexpected status clear
On Thu, Aug 26, 2010 at 03:58:38PM +0900, Magnus Damm wrote: Hi Matt, Just FYI, the newer version of these patches also have a whole bunch of acked-by and tested-by tags, see this email: http://lkml.org/lkml/2010/8/20/429 Thanks for your help! Argh, right. Claws-mail searching has completely failed me. I didn't even see that thread when searching to tmio_mmc. Back to mutt.. Andrew, can you drop the patch with my changelog and pick up the one in that thread seeing as it's got all the tags and a new changelog? Thanks. -- 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] tmio_mmc: Prevents unexpected status clear
On Thu, Aug 26, 2010 at 03:16:40PM -0700, Andrew Morton wrote: On Thu, 26 Aug 2010 23:10:24 +0100 Matt Fleming m...@console-pimps.org wrote: I've stuck my oar in and confused everybody now, it seems. I've just unconfused myself my dropping the patch ;) Please send new one(s) when the dust has settled? Sure thing. The only tmio_mmc patch in my tree at present is tmio_mmc-dont-clear-unhandled-pending-interrupts: From: Yusuke Goda yusuke.goda...@renesas.com Previously, it was possible for ack_mmc_irqs() to clear pending interrupt bits in the CTL_STATUS register, even though the interrupt handler had not been called. This was because of a race that existed when doing a read-modify-write sequence on CTL_STATUS. After the read step in this sequence, if an interrupt occurred (causing one of the bits in CTL_STATUS to be set) the write step would inadvertently clear it. This patch eliminates this race by only writing to CTL_STATUS and clearing the interrupts that were passed as an argument to ack_mmc_irqs(). Would you mind adding this snippet to the end of the changelog? Observed with the TMIO_STAT_RXRDY bit together with CMD53 on AR6002 and BCM4318 SDIO cards in polled mode. And these tags, Acked-by: Magnus Damm d...@opensource.se Tested-by: Arnd Hannemann a...@arndnet.de Acked-by: Ian Molton i...@mnementh.co.uk -- 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] tmio_mmc: Revise a limit of the data size
On Tue, 13 Jul 2010 11:32:33 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Hi Andrew
Andrew Morton wrote:
On Wed, 07 Jul 2010 11:01:20 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Signed-off-by: Yusuke Goda yusuke.goda...@renesas.com
---
drivers/mmc/host/tmio_mmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/tmio_mmc.c b/drivers/mmc/host/tmio_mmc.c
index ee7d0a5..cac1c97 100644
--- a/drivers/mmc/host/tmio_mmc.c
+++ b/drivers/mmc/host/tmio_mmc.c
@@ -661,7 +661,7 @@ static int tmio_mmc_start_data(struct tmio_mmc_host
*host,
data-blksz, data-blocks);
/* Hardware cannot perform 1 and 2 byte requests in 4 bit mode */
- if (data-blksz 4 host-mmc-ios.bus_width == MMC_BUS_WIDTH_4) {
+ if (data-blksz 2 host-mmc-ios.bus_width == MMC_BUS_WIDTH_4) {
pr_err(%s: %d byte block unsupported in 4 bit mode\n,
mmc_hostname(host-mmc), data-blksz);
return -EINVAL;
Again, please provide a suitable description for this change.
I think the data size is not limited by MMC_BUS_WIDTH_x.
I confirmed that data transmission of 2Byte was performed without a problem.
This patch hasn't been picked up. I'm assuming that's because Andrew is
still unhappy with the changelog.
Andrew, how about something like,
When running in 4-bit bus width mode, it is entirely possible to
transfer data in block sizes of 2 bytes and larger. Relax the
conditional check to allow 2-byte data block transfers which were
previously disallowed.
Yusuke, have I interpreted your changelog correctly? Also note that
your patch should remove the comment above the conditional that says,
Hardware cannot perform 1 and 2 byte requests in 4 bit mode.
--
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] tmio_mmc: Prevents unexpected status clear
On Thu, 15 Jul 2010 13:25:52 -0700
Andrew Morton a...@linux-foundation.org wrote:
On Tue, 13 Jul 2010 10:16:39 +0900
Yusuke Goda yusuke.goda...@renesas.com wrote:
Hi Andrew
Thank you for your comment.
#define ack_mmc_irqs(host, i) \
do { \
-u32 mask;\
-mask = sd_ctrl_read32((host), CTL_STATUS); \
-mask = ~((i) TMIO_MASK_IRQ); \
-sd_ctrl_write32((host), CTL_STATUS, mask); \
+sd_ctrl_write32((host), CTL_STATUS, ~(i)); \
} while (0)
Can we have a better changelog please?
What was wrong with the old code?
How does the patch fix it?
What are the user-visible runtime effects of the bug?
(It looks like that was a pretty gross bug - how did it pass testing??)
Example
- CMD53(Single block read / Received data size : 64Byte)
1) Send CMD53
2) Receive CMD53 response
3) Call tmio_mmc_cmd_irq(host, status);
-- original code
#define ack_mmc_irqs(host, i) \
do { \
u32 mask;\
mask = sd_ctrl_read32((host), CTL_STATUS); \
case 1
mask = ~((i) TMIO_MASK_IRQ); \
case 2
sd_ctrl_write32((host), CTL_STATUS, mask); \
} while (0)
-
TMIO_STAT_RXRDY status will be cleared by sd_ctrl_write32((host),
CTL_STATUS, mask);
if TMIO_STAT_RXRDY becomes effective between case 1 and case 2 .
This causes the phenomenon that a TMIO_STAT_RXRDY interrupt does not occur.
When received data are small, it rarely occurs.
OK..
But with both this patch and tmio_mmc-revise-limit-on-data-size.patch
the changelogs fail to describe the impact of the bug upon our users.
So when I sit here trying to work out whether the patches should be
applied to 2.6.35 and whether they should be backported into -stable, I
don't have enough information.
What are your thoughts on this?
Goda, do you have any more ideas on updating the changelog for this
patch? It looks to me like this patch is a candidate for stable
(whereas the tmio_mmc-revise-limit-on-data-size.patch is not, sorry
about replying to that one first, I'm reading my mail backwards)
because, without this patch, it's possible to miss interrupts because
the ack_mmc_irqs() macro clears bit in the CTL_STATUS register that it
should not do? Is that correct?
If that is the case then would this be a more appropriate changelog,
tmio_mmc: Don't clear unhandled pending interrupts
Previously, it was possible for ack_mmc_irqs() to clear pending
interrupt bits in the CTL_STATUS register, even though the interrupt
handler had not been called. This was because of a race that existed
when doing a read-modify-write sequence on CTL_STATUS. After the
read step in this sequence, if an interrupt occurred (causing one of the
bits in CTL_STATUS to be set) the write step would inadvertently clear
it.
This patch eliminates this race by only writing to CTL_STATUS and
clearing the interrupts that were passed as an argument to
ack_mmc_irqs().
--
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] tmio_mmc: Revise a limit of the data size
On Wed, 25 Aug 2010 15:05:02 -0700
Andrew Morton a...@linux-foundation.org wrote:
Actually I don't know what happened with this. I merged it on July 8
and appear to have dropped it on July 27, but I can't find its
removed-from-mm email so I don't know why I dropped it. Weird.
Oh, interesting.
Oh well, I merged it again. Is 2.6.37 an appropriate merge schedule?
I'll defer that to Goda and Paul but that seems reasonable to me.
Yusuke, have I interpreted your changelog correctly? Also note that
your patch should remove the comment above the conditional that says,
Hardware cannot perform 1 and 2 byte requests in 4 bit mode.
this?
--- a/drivers/mmc/host/tmio_mmc.c~tmio_mmc-revise-a-limit-of-the-data-size-fix
+++ a/drivers/mmc/host/tmio_mmc.c
@@ -660,7 +660,6 @@ static int tmio_mmc_start_data(struct tm
pr_debug(setup data transfer: blocksize %08x nr_blocks %d\n,
data-blksz, data-blocks);
- /* Hardware cannot perform 1 and 2 byte requests in 4 bit mode */
if (data-blksz 2 host-mmc-ios.bus_width == MMC_BUS_WIDTH_4) {
pr_err(%s: %d byte block unsupported in 4 bit mode\n,
mmc_hostname(host-mmc), data-blksz);
_
I was thinking more like changing the comment to say Hardware cannot
perform 1 byte requests in 4 bit mode but that's evident from the
check. So sure, removing it seems sane.
--
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: add support for the Marvell platform SDHCI controller
On Tue, 22 Jun 2010 17:09:02 +0300 Saeed Bishara sa...@marvell.com wrote: This patch implements the driver for the platfrom SDHCI controllers that found on some of Marvell's SoC's. Signed-off-by: Saeed Bishara sa...@marvell.com --- drivers/mmc/host/Kconfig| 12 ++ drivers/mmc/host/Makefile |1 + drivers/mmc/host/sdhci-mv.c | 243 +++ 3 files changed, 256 insertions(+), 0 deletions(-) create mode 100644 drivers/mmc/host/sdhci-mv.c Andrew, any reason this hasn't been picked up? (I noticed you weren't on the CC). -- 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: MMC 4.4 DDR support
On Sat, Aug 21, 2010 at 06:37:45PM -0400, Chris Ball wrote: Hi, Hm is there some problem with this patch or has the processing of it simply stalled? When I read the thread I cannot see Hanumaths answers on the list but it looks mainly like the patch is OK and there is some chit-chat. Can it be picked up? Everyone is going to need DDR MMC for their eMMCs soon-ish. I'd like to dedicate more time to mmc/. Do you think it'd be useful for me to catch all the patches sent to linux-mmc@ into a public Git tree, and periodically report on what went upstream via akpm and what's still waiting? It's possible Andrew has a reason that hasn't been picked up yet. Maybe what we really need is to get patchwork setup for the linux-mmc list? Other subsystem maintainers swear by it. That way, it'd be much harder for patches to go unnoticed. -- 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/1] sdhci: support MMC_CAP_MMC_HIGHSPEED
On Mon, Aug 16, 2010 at 09:22:30AM -0400, zhangfei gao wrote: From 165986b1ce3da7de57089ceb4547e84a5b530e64 Mon Sep 17 00:00:00 2001 From: Zhangfei Gao zg...@marvell.com Date: Mon, 16 Aug 2010 21:15:32 -0400 Subject: [PATCH] sdhci: support MMC_CAP_MMC_HIGHSPEED Signed-off-by: Zhangfei Gao zg...@marvell.com --- drivers/mmc/host/sdhci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index 7855121..913555e 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -1823,7 +1823,7 @@ int sdhci_add_host(struct sdhci_host *host) mmc-caps |= MMC_CAP_4_BIT_DATA; if (caps SDHCI_CAN_DO_HISPD) - mmc-caps |= MMC_CAP_SD_HIGHSPEED; + mmc-caps |= MMC_CAP_SD_HIGHSPEED | MMC_CAP_MMC_HIGHSPEED; if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION) mmc-caps |= MMC_CAP_NEEDS_POLL; Acked-by: Matt Fleming m...@console-pimps.org -- 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 1/1]sdhci support 10 bit divided clock Mode for spec 3.0
On Tue, Aug 17, 2010 at 07:08:57AM -0400, zhangfei gao wrote:
Thanks for your carefully review, my mistake.
update the patch to distinguish spec 2.0 and 3.0, help review again.
From 9701da8440b847d8e061107fa6d25bd77698e577 Mon Sep 17 00:00:00 2001
From: Zhangfei Gao zg...@marvell.com
Date: Fri, 6 Aug 2010 07:10:01 +0800
Subject: [PATCH] sdhci: support 10-bit divided clock Mode
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: Matt Fleming m...@console-pimps.org
Cc: Micha? Miros?aw mir...@gmail.com
Cc: David Vrabel david.vra...@csr.com
Signed-off-by: Zhangfei Gao zg...@marvell.com
---
drivers/mmc/host/sdhci.c | 22 +-
drivers/mmc/host/sdhci.h |5 +
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 913555e..7ed6f1c 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1001,13 +1001,25 @@ static void sdhci_set_clock(struct sdhci_host
*host, unsigned int clock)
if (clock == 0)
goto out;
- for (div = 1;div 256;div *= 2) {
- if ((host-max_clk / div) = clock)
- break;
+ if (host-version = SDHCI_SPEC_300) {
+ if(host-max_clk = clock)
+ div = 1;
+ else {
+ for (div = 2; div 2046; div += 2) {
+ if ((host-max_clk / div) = clock)
+ break;
+ }
+ }
+ } else {
+ for (div = 1;div 256;div *= 2) {
+ if ((host-max_clk / div) = clock)
+ break;
+ }
}
div = 1;
- clk = div SDHCI_DIVIDER_SHIFT;
+ clk = (div SDHCI_DIV_MASK) SDHCI_DIVIDER_SHIFT;
+ clk |= ((div SDHCI_DIV_HI_MASK) SDHCI_DIV_MASK_LEN)
SDHCI_DIVIDER_HI_SHIFT;
clk |= SDHCI_CLOCK_INT_EN;
sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
@@ -1707,7 +1719,7 @@ int sdhci_add_host(struct sdhci_host *host)
host-version = sdhci_readw(host, SDHCI_HOST_VERSION);
host-version = (host-version SDHCI_SPEC_VER_MASK)
SDHCI_SPEC_VER_SHIFT;
- if (host-version SDHCI_SPEC_200) {
+ if (host-version SDHCI_SPEC_300) {
printk(KERN_ERR %s: Unknown controller version (%d).
You may experience problems.\n, mmc_hostname(mmc),
host-version);
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 036cfae..50860dc 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -86,6 +86,10 @@
#define SDHCI_CLOCK_CONTROL 0x2C
#define SDHCI_DIVIDER_SHIFT 8
+#define SDHCI_DIVIDER_HI_SHIFT 6
+#define SDHCI_DIV_MASK 0xFF
+#define SDHCI_DIV_MASK_LEN 8
+#define SDHCI_DIV_HI_MASK 0x300
#define SDHCI_CLOCK_CARD_EN 0x0004
#define SDHCI_CLOCK_INT_STABLE 0x0002
#define SDHCI_CLOCK_INT_EN 0x0001
@@ -178,6 +182,7 @@
#define SDHCI_SPEC_VER_SHIFT0
#define SDHCI_SPEC_100 0
#define SDHCI_SPEC_200 1
+#define SDHCI_SPEC_300 2
struct sdhci_ops;
--
1.7.0.4
From 9701da8440b847d8e061107fa6d25bd77698e577 Mon Sep 17 00:00:00 2001
From: Zhangfei Gao zg...@marvell.com
Date: Fri, 6 Aug 2010 07:10:01 +0800
Subject: [PATCH] sdhci: support 10-bit divided clock Mode
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Cc: Matt Fleming m...@console-pimps.org
Cc: Micha?? Miros??aw mir...@gmail.com
Cc: David Vrabel david.vra...@csr.com
Signed-off-by: Zhangfei Gao zg...@marvell.com
---
drivers/mmc/host/sdhci.c | 22 +-
drivers/mmc/host/sdhci.h |5 +
2 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 913555e..7ed6f1c 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1001,13 +1001,25 @@ static void sdhci_set_clock(struct sdhci_host *host,
unsigned int clock)
if (clock == 0)
goto out;
- for (div = 1;div 256;div *= 2) {
- if ((host-max_clk / div) = clock)
- break;
+ if (host-version = SDHCI_SPEC_300) {
+ if(host-max_clk = clock)
+ div = 1;
+ else {
+ for (div = 2; div 2046; div += 2) {
+ if ((host-max_clk / div) = clock)
+ break;
+ }
+ }
+ } else {
+ for (div = 1;div 256;div *= 2) {
+ if ((host-max_clk / div) = clock)
+ break;
+ }
}
div = 1;
- clk = div SDHCI_DIVIDER_SHIFT;
+ clk = (div SDHCI_DIV_MASK) SDHCI_DIVIDER_SHIFT
Re: [patch v2 1/1]sdhci support 10 bit divided clock Mode for spec 3.0
On Mon, Aug 16, 2010 at 05:07:15PM +0100, David Vrabel wrote:
zhangfei gao wrote:
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 913555e..32dcac9 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
[...]
@@ -1001,13 +1001,23 @@ static void sdhci_set_clock(struct sdhci_host
*host, unsigned int clock)
if (clock == 0)
goto out;
- for (div = 1;div 256;div *= 2) {
- if ((host-max_clk / div) = clock)
- break;
+ if (host-version = SDHCI_SPEC_300)
+ max_div = 2046;
+ else
+ max_div = 256;
+
+ if(host-max_clk = clock)
+ div = 1;
+ else {
+ for (div = 2; div max_div; div += 2) {
+ if ((host-max_clk / div) = clock)
+ break;
+ }
This isn't correct. The divisor must be a power of two for 2.00
controllers.
Sorry, I did mean to reply to this sooner but I've been travelling. Yeah
David, you're right. Zhangfei, have you confused the Programmable Clock
Mode in the 3.00 spec here with 10-bit Divided Clock Mode?
Both 8-bit Divided Clock Mode and 10-bit Divided Clock Mode require the
divisor to be a power of two. Support for Programmable Clock Mode would
require a bit more work because not all clock multiplier values are
valid. Support for that should be done as a separate patch.
--
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 1/1]sdhci support 10 bit divided clock Mode for spec 3.0
On Mon, Aug 16, 2010 at 07:54:14PM +0100, David Vrabel wrote: Matt Fleming wrote: Sorry, I did mean to reply to this sooner but I've been travelling. Yeah David, you're right. Zhangfei, have you confused the Programmable Clock Mode in the 3.00 spec here with 10-bit Divided Clock Mode? Both 8-bit Divided Clock Mode and 10-bit Divided Clock Mode require the divisor to be a power of two. The power-of-two requirement only applies to 2.00 controller. From section 2.2.14 of the spec. (2) 10-bit Divided Clock Mode Host Controller Version 3.00 supports this mandatory mode instead of the 8-bit Divided Clock Mode. The length of divider is extended to 10bits and all divider values shall be supported. 3.00 dividers can be any multiple of two. Yep, you're right. I misread the spec. My bad. -- 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
Running out of SDHCI quirk space (Re: [PATCH 1/3 v2] sdhci: Add auto CMD12 support for eSDHC driver)
On Tue, Aug 03, 2010 at 04:43:46PM -0700, Andrew Morton wrote:
On Tue, 3 Aug 2010 11:11:10 +0800
Roy Zang tie-fei.z...@freescale.com wrote:
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -240,6 +240,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_CAP_CLOCK_BASE_BROKEN (125)
/* Controller cannot support End Attribute in NOP ADMA descriptor */
#define SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC (126)
+/* Controller uses Auto CMD12 command to stop the transfer */
+#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (127)
This becomes 129 in my tree.
We're about to run out. What happens then?
I've been wondering for a while now if many of the quirks should be
hidden behind function pointers. While we could of course extend the
quirk space, I think that's kinda missing the point that quirks are
being used too liberally. Take SDHCI_QUIRK_SINGLE_POWER_WRITE in
drivers/mmc/host/sdhci.c:sdhci_set_power(). Really, that quirk should
probably be hidden inside a set_power() function in the sdhci_ops
structure.
I'm gonna have a go at trying to remove some of the quirks that don't
make sense being quirks. I'll post the series when I'm done.
Does anyone think that this approach is crazy?
--
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/1]sdhci: sdhc spec 3.0 add some modification
On Mon, Aug 09, 2010 at 08:33:16PM +0800, zhangfei gao wrote: Thanks for your careful review, in our platform, we use max/min for the max_div, so miss this modification :( Update the patch, help review again. What do you mean? Where does max/min come from? It would definitely be best if everybody uses the same code to calculate max_div. Have you tested the max_div changes? Are you now using this patch on your platform or are you still maintaining a patch to do it a different way? If you've got a separate patch and it does this things better than the way we currently do them, get it upstream! :-) -- 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: add SDHCI driver for STM platforms.
On Wed, Aug 04, 2010 at 07:47:21AM +0200, Peppe CAVALLARO wrote: Yes, we can do it. The driver will be merged next. It is not a problem for me ;-). Fantastic! -- 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: MXC MMC and Libertas_sdio
On Fri, 23 Jul 2010 13:59:38 +0200, Andreas Feuersinger andreas.feuersin...@spintower.eu wrote: Cc'ing libertas-...@lists.infradead.org Hi, I'm trying to use the libertas driver on MX27 based hardware. I'm using kernel v2.6.22 with libertas and sdio driver ported (mainly 2.6.34). The Wlan device is Marvel SD8686 connected via sdio. Loading of firmware seems to work using a block size of 512 sdio_set_block_size(card-func, 512); after loading the firmware I get the following output: libertas: waiting for firmware to boot libertas: sdio read scratch libertas: sdio scratch 0 ; ret: 0 libertas: sdio read scratch libertas: sdio scratch 0 ; ret: 0 libertas: sdio read scratch libertas: sdio scratch 0 ; ret: 0 libertas: sdio read scratch libertas: sdio scratch 220 ; ret: 0 libertas: sdio host to card type 1, bytes 46 libertas: sdio host to card worker libertas: sdio read scratch libertas: sdio scratch 50 ; ret: 0 libertas: sdio card to host size 50 libertas: sdio card to host status: 10 libertas: card-buffer[0] 0 card-buffer[1] 0 packet of type 1 and size 0 bytes libertas: sdio handle cmd libertas: response packet too large (4294967292 bytes) libertas: problem fetching packet from firmware The latest output goes on forever. Canceling the modprobe command results in a Network Interface: Strg+C libertas: eth1: Marvell WLAN 802.11 adapter However the problem fetching packet from firmware remains and the device does not work. I tried several Firmware Versions all resulting as described above. If I use 32 instead of 512 for the block size the kernel hangs after loading helper firmware during the loading process of the real firmware. I read about Daniel Mack doing similar stuff for mx31 based systems. Did he/you has/have success in that and what were your problems? I appreciate any help/hints where to dig for the error. Thanks, Andreas -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/8] sdhci: Move real work out of an atomic context
On Wed, 14 Jul 2010 17:07:28 +0400, Anton Vorontsov avoront...@mvista.com wrote: Hi all, Currently the sdhci driver does everything in the atomic context. And what is worse, PIO transfers are made from the IRQ handler. This causes huge latencies (up to 120 ms). On some P2020 SOCs, DMA and card detection is broken, which means that kernel polls for the card via PIO transfers every second. Needless to say that this is quite bad. So, this patch set reworks sdhci code to avoid atomic context, almost completely. We only do two device memory operations in the atomic context, and all the rest is threaded. I noticed no throughput drop neither with PIO transfers nor with DMA (tested on MPC8569E CPU), while latencies should be greatly improved. I haven't had time to read these patches in detail yet but they all seem to be sensible changes. A very nice series! -- 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
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: [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 --- Changes since v1 - Do not request IRQ with IRQF_DISABLED since it is a noop now - Use a generous slack for the timeout timer. It does not need to be accurate. Changes since v2 - Use sg_mapping_to iterate over sg elements in mmc read and write functions - Use bitops instead of a spinlock and a variable for testing whether a request has been finished. - Rework irq and timeout handling in order to get rid of locking in hot paths Acked-by: Matt Fleming m...@console-pimps.org Are you planning on maintaining this driver? If so, it'd be a good idea to update MAINTAINERS. -- 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: change initial clock setting
On Mon, 21 Jun 2010 13:29:21 +0900, Jaehoon Chung jh80.ch...@samsung.com wrote: On 2010-06-18 오후 9:42, Matt Fleming wrote: On Fri, 18 Jun 2010 13:05:44 +0900, Jaehoon Chung jh80.ch...@samsung.com wrote: This patch is bug fixed.. I think that host-ios.clock(initial clock) will be set lower than 400KHz. But in this code, if host-f_min is higher than 400KHz, print warning message and set higher than 400KHz. And We use SDHCI_QUIRK_NONSTANDARD_CLOCK..so using get_min_clock function. but didn't effect nothing through used get_min_clock function. I'm a little confused. What problem are you fixing with this patch? What issue are you seeing? SDHCI_QUIRK_NONSTANDARD_CLOCK is only for sdhci. If this is the old my card won't initialise at 400kHz chestnut I don't think a solution has ever been agreed upon. The problem was that while some cards won't initialise at 400kHz, some controllers will try to initialise at too low a frequency which causes other problems. Sascha Hauer explains the reason for setting ios.clock to 400kHz here, http://lkml.org/lkml/2010/1/5/120 So I think your patch will cause problems. Which driver are you using? The driver should have set the f_min value to be = 400kHz. Maybe it is a good idea to set the value of ios.clock to 400kHz if the driver has set a bogus f_min value, we will at least have a fighting chance of initialising the card (though I would say that the driver was broken, but at least core.c will print a warning). when ios.clock is higher than 400KHz, why not change 400KHz?(if 400KHz seemed like good value) if clock value is higher than 400KHz, i think card can't initialize...maybe I think this part of your patch is OK. when sdhci controller set f_min value(ie, 300KHz), clock changed 400KHz in core.c. just this code purpose to print warning message? Well, the purpose of the code is to set the clock to 400kHz if the value of f_min is too low, as having a low value can cause some controllers to break. -- 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: add support for the Marvell platform SDHCI controller
On Tue, 22 Jun 2010 17:09:02 +0300, Saeed Bishara sa...@marvell.com wrote:
This patch implements the driver for the platfrom SDHCI controllers that
found on some of Marvell's SoC's.
Signed-off-by: Saeed Bishara sa...@marvell.com
That's a nice, small driver ;-)
[...]
+
+ if (!devm_request_mem_region(pdev-dev, iomem-start,
+ resource_size(iomem),
+ mmc_hostname(host-mmc))) {
+ dev_err(pdev-dev, cannot request region\n);
+ ret = -EBUSY;
+ goto err_request;
+ }
+
+ host-ioaddr = devm_ioremap(pdev-dev, iomem-start,
+ resource_size(iomem));
+ if (!host-ioaddr) {
+ dev_err(pdev-dev, failed to remap registers\n);
+ ret = -ENOMEM;
+ goto err_request;
+ }
If you fail to remap the registers shouldn't you release the mem_region
you've allocated above?
+
+#if defined(CONFIG_HAVE_CLK)
+ mv_host-clk = clk_get(pdev-dev, NULL);
+ if (IS_ERR(mv_host-clk))
+ dev_notice(pdev-dev, cannot get clkdev\n);
+ else
+ clk_enable(mv_host-clk);
+#endif
+
+ ret = sdhci_add_host(host);
+ if (ret)
+ goto err_request;
Likewise here, I think you should be iounmap()'ing the registers if this
fails. Otherwise this looks good.
--
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: add support for the Marvell platform SDHCI controller
On Wed, 23 Jun 2010 15:11:04 +0300, saeed bishara saeed.bish...@gmail.com wrote: the point behind the devm_ (device managed) resouce allocation is not to do the free explicitly, the kernel does that on behalf of the driver. Oops, sorry I missed that. I must have been hungry, it was near lunchtime. -- 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 18/26] MMC: Add JZ4740 mmc driver
On Sat, 19 Jun 2010 07:08:23 +0200, Lars-Peter Clausen l...@metafoo.de wrote:
This patch adds support for the mmc controller on JZ4740 SoCs.
Hey Lars-Peter,
I had a quick look over this patch and it looks OK. Just a few comments.
+static void jz4740_mmc_timeout(unsigned long data)
+{
+ struct jz4740_mmc_host *host = (struct jz4740_mmc_host *)data;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-lock, flags);
+ if (!host-waiting) {
+ spin_unlock_irqrestore(host-lock, flags);
+ return;
+ }
+
+ host-waiting = 0;
+
+ spin_unlock_irqrestore(host-lock, flags);
+
+ host-req-cmd-error = -ETIMEDOUT;
+ jz4740_mmc_request_done(host);
+}
+
Taking a spinlock and disabling interrupts seems like too much overhead
to simply test and clear a bit. Wouldn't it be better to implement this
with test_and_clear_bit(), which on MIPS will likely be implemented with
ll/sc instructions? It's particularly important to keep this
low-overhead since this bit is modified in the interrupt handler.
+static void jz4740_mmc_request_done(struct jz4740_mmc_host *host)
+{
+ struct mmc_request *req;
+ unsigned long flags;
+
+ spin_lock_irqsave(host-lock, flags);
+ req = host-req;
+ host-req = NULL;
+ host-waiting = 0;
+ spin_unlock_irqrestore(host-lock, flags);
+
+ if (!unlikely(req))
+ return;
+
+ mmc_request_done(host-mmc, req);
+}
+
Am I right in thinking that this spinlock guards against the interrupt
handler and the timeout function running at the same time? So it's not
really possible to drop the spinlock from here?
--
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: change initial clock setting
On Fri, 18 Jun 2010 13:05:44 +0900, Jaehoon Chung jh80.ch...@samsung.com wrote: This patch is bug fixed.. I think that host-ios.clock(initial clock) will be set lower than 400KHz. But in this code, if host-f_min is higher than 400KHz, print warning message and set higher than 400KHz. And We use SDHCI_QUIRK_NONSTANDARD_CLOCK..so using get_min_clock function. but didn't effect nothing through used get_min_clock function. I'm a little confused. What problem are you fixing with this patch? What issue are you seeing? SDHCI_QUIRK_NONSTANDARD_CLOCK is only for sdhci. If this is the old my card won't initialise at 400kHz chestnut I don't think a solution has ever been agreed upon. The problem was that while some cards won't initialise at 400kHz, some controllers will try to initialise at too low a frequency which causes other problems. Sascha Hauer explains the reason for setting ios.clock to 400kHz here, http://lkml.org/lkml/2010/1/5/120 So I think your patch will cause problems. Which driver are you using? The driver should have set the f_min value to be = 400kHz. Maybe it is a good idea to set the value of ios.clock to 400kHz if the driver has set a bogus f_min value, we will at least have a fighting chance of initialising the card (though I would say that the driver was broken, but at least core.c will print a warning). -- 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: [Bug 15836] Commit 6ad696d2cf535772dff659298ec7e7260e344595 breaks my SD card reader [197b:2381]
On Tue, 27 Apr 2010 12:59:17 +0200, Stephan Suerken abs...@olurdix.de wrote: On Mon, 2010-04-26 at 13:58 -0700, Andrew Morton wrote: (...) https://bugzilla.kernel.org/show_bug.cgi?id=15836 OK, I give up. Ok, I guess it would be very helpful, first of all, if someone could affirm the buggy behavior on the same or similar hardware with kernels =2.6.32. The bug occurs on a HP HDX 16 laptop; attaching some hardware information... Stephan, this one definitely looks strange. Have you tried running other diagnostic tools on you SD card, e.g. fsck? How about on your hard disks or other mass storage devices? Is it always the same block that's reported as bad? Were you doing any suspend/hibernation during these tests? It might also be an idea to turn on CONFIG_DEBUG_PAGEALLOC and run badblocks again. If you turn off CONFIG_HOTPLUG and CONFIG_HIBERNATION on a recent kernel does it work then? I'm pretty stumped as to what is going on here... -- 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] sdhci: Rename SDHCI I/O accessor functions
Unfortunately some architectures #define their read{b,w,l} and
write{b,w,l} I/O accessors which makes the SDHCI I/O accessor functions
of the same names subject to preprocessing. This leads to the following
compiler error,
In file included from drivers/mmc/host/sdhci.c:26:
drivers/mmc/host/sdhci.h:318:35: error: macro writel passed 3 arguments, but
takes just 2
Rename the SDHCI I/O functions so that CONFIG_MMC_SDHCI_IO_ACCESSORS can
be enabled for architectures that implement their read{b,w,l} and
write{b,w,l} functions with macros.
Acked-by: Anton Vorontsov cbouatmai...@gmail.com
Signed-off-by: Matt Fleming m...@console-pimps.org
---
drivers/mmc/host/sdhci-of-esdhc.c | 12 ++--
drivers/mmc/host/sdhci-of-hlwd.c | 12 ++--
drivers/mmc/host/sdhci.h | 36 ++--
3 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index d5b11a1..c8623de 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -129,12 +129,12 @@ struct sdhci_of_data sdhci_esdhc = {
SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET |
SDHCI_QUIRK_NO_CARD_NO_RESET,
.ops = {
- .readl = sdhci_be32bs_readl,
- .readw = esdhc_readw,
- .readb = sdhci_be32bs_readb,
- .writel = sdhci_be32bs_writel,
- .writew = esdhc_writew,
- .writeb = esdhc_writeb,
+ .read_l = sdhci_be32bs_readl,
+ .read_w = esdhc_readw,
+ .read_b = sdhci_be32bs_readb,
+ .write_l = sdhci_be32bs_writel,
+ .write_w = esdhc_writew,
+ .write_b = esdhc_writeb,
.set_clock = esdhc_set_clock,
.enable_dma = esdhc_enable_dma,
.get_max_clock = esdhc_get_max_clock,
diff --git a/drivers/mmc/host/sdhci-of-hlwd.c b/drivers/mmc/host/sdhci-of-hlwd.c
index 35117f3..68ddb75 100644
--- a/drivers/mmc/host/sdhci-of-hlwd.c
+++ b/drivers/mmc/host/sdhci-of-hlwd.c
@@ -55,11 +55,11 @@ struct sdhci_of_data sdhci_hlwd = {
.quirks = SDHCI_QUIRK_32BIT_DMA_ADDR |
SDHCI_QUIRK_32BIT_DMA_SIZE,
.ops = {
- .readl = sdhci_be32bs_readl,
- .readw = sdhci_be32bs_readw,
- .readb = sdhci_be32bs_readb,
- .writel = sdhci_hlwd_writel,
- .writew = sdhci_hlwd_writew,
- .writeb = sdhci_hlwd_writeb,
+ .read_l = sdhci_be32bs_readl,
+ .read_w = sdhci_be32bs_readw,
+ .read_b = sdhci_be32bs_readb,
+ .write_l = sdhci_hlwd_writel,
+ .write_w = sdhci_hlwd_writew,
+ .write_b = sdhci_hlwd_writeb,
},
};
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 842f46f..68de5cf 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -294,12 +294,12 @@ struct sdhci_host {
struct sdhci_ops {
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
- u32 (*readl)(struct sdhci_host *host, int reg);
- u16 (*readw)(struct sdhci_host *host, int reg);
- u8 (*readb)(struct sdhci_host *host, int reg);
- void(*writel)(struct sdhci_host *host, u32 val, int reg);
- void(*writew)(struct sdhci_host *host, u16 val, int reg);
- void(*writeb)(struct sdhci_host *host, u8 val, int reg);
+ u32 (*read_l)(struct sdhci_host *host, int reg);
+ u16 (*read_w)(struct sdhci_host *host, int reg);
+ u8 (*read_b)(struct sdhci_host *host, int reg);
+ void(*write_l)(struct sdhci_host *host, u32 val, int reg);
+ void(*write_w)(struct sdhci_host *host, u16 val, int reg);
+ void(*write_b)(struct sdhci_host *host, u8 val, int reg);
#endif
void(*set_clock)(struct sdhci_host *host, unsigned int clock);
@@ -314,48 +314,48 @@ struct sdhci_ops {
static inline void sdhci_writel(struct sdhci_host *host, u32 val, int reg)
{
- if (unlikely(host-ops-writel))
- host-ops-writel(host, val, reg);
+ if (unlikely(host-ops-write_l))
+ host-ops-write_l(host, val, reg);
else
writel(val, host-ioaddr + reg);
}
static inline void sdhci_writew(struct sdhci_host *host, u16 val, int reg)
{
- if (unlikely(host-ops-writew))
- host-ops-writew(host, val, reg);
+ if (unlikely(host-ops-write_w))
+ host-ops-write_w(host, val, reg);
else
writew(val, host-ioaddr + reg);
}
static inline void sdhci_writeb(struct sdhci_host *host, u8 val, int reg)
{
- if (unlikely(host-ops-writeb))
- host-ops-writeb(host, val, reg);
+ if (unlikely(host-ops-write_b))
+ host-ops-write_b
Re: mmc: sdhci.h compile error
On Mon, 26 Apr 2010 15:46:31 +0800, zhangfei gao zhangfei@gmail.com wrote: Hi, Matt We also rename the function name to pass compile. Besides, here is typo error drivers/mmc/host/sdhci.h, though it is not a big deal. Good catch! How did you notice that? Did you see a failure at runtime or did you spot it by reading the code? If you were seeing a bug at runtime then this patch should also be sent to sta...@kernel.org. I don't have any hardware to test this patch but the change looks like it makes sense. -- 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: sdhci.h compile error
On Tue, 27 Apr 2010 11:45:28 +0800, zhangfei gao zhangfei@gmail.com wrote: Fortunately, the typo does not impact the stability. We found the typo when debugging our silicon issue, however, nothing impove after the fix :) OK, thanks. In that case it probably doesn't need to go to -stable. You can add Reviewed-by: Matt Fleming m...@console-pimps.org to your patch. -- 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: sdhci.h compile error
On Wed, 21 Apr 2010 19:43:32 +0800, zhangfei gao zhangfei@gmail.com wrote:
There is compile error when we enable CONFIG_MMC_SDHCI_IO_ACCESSORS,
and include header file #include sdhci.h
error: macro writel passed 3 arguments, but takes just 2
Interesting...
It was Anton Vorontsov that added this code; presumably the code has
never been compiled for an ARM board (or any other architecture that
#define's their I/O accessors in asm/io.h).
The writel is treated as macro and it is already defined in ARM.
The workaround is modify the name of ops writel.
It would be better if all architectures declared their I/O accessors as
static inline, but I'm not volunteering to touch all those headers ;-)
Renaming the SDHCI ops is definitely the easiest option. Anton, do you
have a problem with the attached patch to rename the SDHCI accessor
functions?
Is there anybody also see such issue, and my platform is ARM.
I'm curious to know why you need to set MMC_SDHCI_IO_ACCESSORS. Does
your board have weird I/O memory access requirements? This option is
pretty specialized.
--
From d9c3a1666ea7597c21a68e44f3b5a2de0a6932b6 Mon Sep 17 00:00:00 2001
Message-Id:
d9c3a1666ea7597c21a68e44f3b5a2de0a6932b6.1272234369.git.m...@console-pimps.org
From: Matt Fleming m...@console-pimps.org
Date: Sun, 25 Apr 2010 23:14:34 +0100
Subject: [PATCH] sdhci: Rename SDHCI I/O accessor functions
Unfortunately some architectures #define their read{b,w,l} and
write{b,w,l} I/O accessors which makes the SDHCI I/O accessor functions
of the same names subject to preprocessing. This leads to the following
compiler error,
In file included from drivers/mmc/host/sdhci.c:26:
drivers/mmc/host/sdhci.h:318:35: error: macro writel passed 3 arguments, but
takes just 2
Rename the SDHCI I/O functions so that CONFIG_MMC_SDHCI_IO_ACCESSORS can
be enabled for architectures that implement their read{b,w,l} and
write{b,w,l} functions with macros.
Signed-off-by: Matt Fleming m...@console-pimps.org
---
drivers/mmc/host/sdhci-of-esdhc.c | 12 ++--
drivers/mmc/host/sdhci-of-hlwd.c | 12 ++--
drivers/mmc/host/sdhci.h | 36 ++--
3 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c
b/drivers/mmc/host/sdhci-of-esdhc.c
index d5b11a1..c8623de 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -129,12 +129,12 @@ struct sdhci_of_data sdhci_esdhc = {
SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET |
SDHCI_QUIRK_NO_CARD_NO_RESET,
.ops = {
- .readl = sdhci_be32bs_readl,
- .readw = esdhc_readw,
- .readb = sdhci_be32bs_readb,
- .writel = sdhci_be32bs_writel,
- .writew = esdhc_writew,
- .writeb = esdhc_writeb,
+ .read_l = sdhci_be32bs_readl,
+ .read_w = esdhc_readw,
+ .read_b = sdhci_be32bs_readb,
+ .write_l = sdhci_be32bs_writel,
+ .write_w = esdhc_writew,
+ .write_b = esdhc_writeb,
.set_clock = esdhc_set_clock,
.enable_dma = esdhc_enable_dma,
.get_max_clock = esdhc_get_max_clock,
diff --git a/drivers/mmc/host/sdhci-of-hlwd.c b/drivers/mmc/host/sdhci-of-hlwd.c
index 35117f3..68ddb75 100644
--- a/drivers/mmc/host/sdhci-of-hlwd.c
+++ b/drivers/mmc/host/sdhci-of-hlwd.c
@@ -55,11 +55,11 @@ struct sdhci_of_data sdhci_hlwd = {
.quirks = SDHCI_QUIRK_32BIT_DMA_ADDR |
SDHCI_QUIRK_32BIT_DMA_SIZE,
.ops = {
- .readl = sdhci_be32bs_readl,
- .readw = sdhci_be32bs_readw,
- .readb = sdhci_be32bs_readb,
- .writel = sdhci_hlwd_writel,
- .writew = sdhci_hlwd_writew,
- .writeb = sdhci_hlwd_writeb,
+ .read_l = sdhci_be32bs_readl,
+ .read_w = sdhci_be32bs_readw,
+ .read_b = sdhci_be32bs_readb,
+ .write_l = sdhci_hlwd_writel,
+ .write_w = sdhci_hlwd_writew,
+ .write_b = sdhci_hlwd_writeb,
},
};
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 842f46f..68de5cf 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -294,12 +294,12 @@ struct sdhci_host {
struct sdhci_ops {
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
- u32 (*readl)(struct sdhci_host *host, int reg);
- u16 (*readw)(struct sdhci_host *host, int reg);
- u8 (*readb)(struct sdhci_host *host, int reg);
- void(*writel)(struct sdhci_host *host, u32 val, int reg);
- void(*writew)(struct sdhci_host *host, u16 val, int reg);
- void(*writeb)(struct sdhci_host *host, u8 val, int reg);
+ u32 (*read_l)(struct sdhci_host *host, int reg);
+ u16 (*read_w)(struct
Re: mmc_spi and flash cards
On Thu, 14 Jan 2010 16:09:05 -0500, Cliff Brake cliff.br...@gmail.com wrote: I wonder if there is something wrong with the previous READ_MULTIPLE_BLOCK command, and that is what the cards are complaining about, not the STOP_TRANSMISSION command? If there was some wrong with the READ_MULTIPLE_BLOCK command the card should have complained before the host started reading data. I'm decoding the READ_MULTIPLE_BLOCK arguments next Your best bet is probably going to be getting a 'scope on the bus. -- 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_spi and flash cards
On Mon, 28 Dec 2009 12:58:28 -0500, Cliff Brake cliff.br...@gmail.com wrote:
STOP_TRANSMISSION
bit 3 - R1_SPI_COM_CRC (the CRC of the last command failed)
mmc0: req done (CMD18): 0:
mmc0: 4096 bytes transferred: 0
mmc0: (CMD12): -84: 0008
That's weird.
mmc_spi spi1.0: mmc_spi: CMD12, resp R1B
mmc_spi spi1.0: ... CMD12 response SPI_R1B: resp 0040
bit 6, R1_SPI_PARAMETER (commands argument, block length) was out of
allowed range for this card.
And that just seems completely bogus; the STOP_TRANSMISSION command
doesn't require any parameters.
Having read mmc_spi_response_get() I'm wondering if it's actually trying
to interpret a busy signal as a response code. Would you mind giving
this patch a go and seeing if the BUG_ON() triggers?
diff --git a/drivers/mmc/host/mmc_spi.c b/drivers/mmc/host/mmc_spi.c
index d55fe4f..3e36ff4 100644
--- a/drivers/mmc/host/mmc_spi.c
+++ b/drivers/mmc/host/mmc_spi.c
@@ -310,6 +310,7 @@ static int mmc_spi_response_get(struct mmc_spi_host *host,
checkstatus:
bitshift = 0;
+ BUG_ON(*cp == 0xff);
if (*cp 0x80) {
/* Houston, we have an ugly card with a bit-shifted response */
rotator = *cp++ 8;
--
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] sdio: Fix reference counting in sdio_remove_func()
On Wed, Dec 02, 2009 at 09:22:19AM +, Daniel Drake wrote: sdio_remove_func() needs to be more careful about reference counting. It can be called in error paths where sdio_add_func() has never been called e.g. mmc_attach_sdio error path -- mmc_sdio_remove -- sdio_remove_func Signed-off-by: Daniel Drake d...@laptop.org Reviewed-by: Matt Fleming m...@console-pimps.org -- 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] sdio: Initialise SDIO functions and update card-sdio_funcs in lockstep
We need to accurately track how many SDIO functions have been
initialised (and keep card-sdio_funcs in sync) so that we don't try to
remove more functions than we initialised if we hit the error path in
mmc_attach_sdio().
Without this patch if we hit the error path in mmc_attach_sdio() we run
the risk of deferencing invalid memory in sdio_remove_func(), leading to
a crash.
Signed-off-by: Matt Fleming m...@console-pimps.org
---
drivers/mmc/core/sdio.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index cdb845b..8002797 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -516,7 +516,8 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
* The number of functions on the card is encoded inside
* the ocr.
*/
- card-sdio_funcs = funcs = (ocr 0x7000) 28;
+ funcs = (ocr 0x7000) 28;
+ card-sdio_funcs = 0;
/*
* If needed, disconnect card detection pull-up resistor.
@@ -528,7 +529,7 @@ int mmc_attach_sdio(struct mmc_host *host, u32 ocr)
/*
* Initialize (but don't add) all present functions.
*/
- for (i = 0;i funcs;i++) {
+ for (i = 0;i funcs;i++, card-sdio_funcs++) {
err = sdio_init_func(host-card, i + 1);
if (err)
goto remove;
--
1.6.4.rc0
--
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: TMIO MMC: full patchset.
On Tue, Sep 29, 2009 at 01:52:50PM +0100, Ian Molton wrote:
From bc0e0adbc24cb7bf8c0119e65d43b42410ce316a Mon Sep 17 00:00:00 2001
From: Ian Molton i...@mnementh.co.uk
Date: Tue, 29 Sep 2009 13:39:29 +0100
Subject: [PATCH 5/5] MMC: Retry initialisation at a lower frequency if it
times out
This patch retrys the MMC card initialisation at a lower frequency
if it fails. It is needed on certain tmio controllers with fussy cards.
Signed-off-by: Ian Molton i...@mnementh.co.uk
---
drivers/mmc/core/mmc.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 06084db..03e782f 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -295,13 +295,17 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
struct mmc_card *oldcard)
{
struct mmc_card *card;
- int err;
+ int err, slow_retry = 0;
u32 cid[4];
unsigned int max_dtr;
BUG_ON(!host);
WARN_ON(!host-claimed);
+retry:
+ if (slow_retry)
+ mmc_set_clock(host, host-f_min);
+
/*
* Since we're changing the OCR value, we seem to
* need to tell some cards to go back to the idle
@@ -464,6 +468,11 @@ free_card:
mmc_remove_card(card);
err:
+ if (err == -ETIMEDOUT host-f_min 40) {
+ slow_retry = 1;
+ goto retry;
+ }
+
return err;
}
--
1.6.3.3
I'm not sure that propagating this magical 400kHz constant around the
MMC code is the best way to go. It could do with a #define.
You're the second person to run into issues with the lower limit
initialisation patch. Does anybody know where that value came from? Is
it definitely the best value to use or has it just been picked out of
the air?
--
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] sdio: add MMC_CAP_VDD_165_195 host capability
On Mon, Sep 28, 2009 at 03:59:00PM -0700, Andrew Morton wrote:
On Mon, 28 Sep 2009 19:10:48 +0100
Matt Fleming m...@console-pimps.org wrote:
+ if ((ocr MMC_VDD_165_195) !(host-caps MMC_CAP_VDD_165_195)) {
+ printk(KERN_WARNING %s: SDIO card claims to support the
+ incompletely defined 'low voltage range'. This
+ will be ignored.\n, mmc_hostname(host));
+ ocr = ~MMC_VDD_165_195;
+ }
+
host-ocr = mmc_select_voltage(host, ocr);
/*
I know you copied this warning from the old code
It'd be better to avoid copying anything at all. Are we missing
code-sharing opportunities here?
No, Ohad's commit 27cce39f555def6f5ebe7f03d69ccc44ab25f0b2 sdio: do not
ignore MMC_VDD_165_195 deleted this warning and this commit is just
bringing it back from the dead.
It seems that Philip and David have other ideas on how they want to
handle this voltage range so this patch probably doesn't need picking
up.
--
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/1] CMD12 error recovery support for SD cards
On Wed, Sep 16, 2009 at 04:09:11PM +0530, Mahadev Cholachagudda wrote: Dear All, I've a kernel code base of 2.6.28.9, where in I find that CMD12 error recovery is not been implemented. It is a wise idea to implement CMD12 error recovery, that involves sending CMD13 to get the status of the card. If the card is in trans state, it means CMD12 error shall be treated as successfull. If card state is not in trans, then we have to send CMD12 again to stop the data transfer and then checking of the card status through CMD13. This sequence is detailed in the Simplified Host Controller specification on SDCard website. I believe this is the case for any controller, though I may be wrong. With the modification done to the code which is attached as patch to the latest mmc git, it is working at our site. And we do see some errors with the SDIO controller (proprietary but meets Standard SD host controller specification) that we are using. Request you to comment on the patch. In principal this patch seems OK. However, I recommend reading Documentation/CodingStyle and sending this patch again once you've fixed up the coding style and whitespace errors. Is there a specific reason that you have used mmc_wait_for_req() instead of mmc_wait_for_cmd() and reusing the cmd local variable? The empty else clauses can also probably be deleted. -- 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
