Re: [PATCH V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
Hi Wolfram, On Wed, Feb 23, 2011 at 02:51:53PM +0100, Wolfram Sang wrote: Take #3, changes: * also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25) * remove unconditional BROKEN_CARD_DETECTION (leftover) * improved kernel-doc about unused GPIO * added tags from Eric Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you have a chance to retest on mx51? What about the FSL guys? :) I'm testing it on mx25 3ds and mx51 babbage. Both card-detect and write-protect are working on mx25 3ds, but write-protect has some problem on babbage, and I need some time to figure it out. Also it's not testable on mx35 3ds board, as these two gpio pins are routed to a MCU which needs the I2C access. Do we have this support on mainline? -- Regards, Shawn -- 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 2/3] mmc: cb710: Return err value in cb710_wait_while_busy()
On Wed, Feb 23, 2011 at 11:17:43PM +, Chris Ball wrote: Fixes: drivers/mmc/host/cb710-mmc.c: In function ‘cb710_wait_while_busy’: drivers/mmc/host/cb710-mmc.c:182:6: warning: variable ‘err’ set but not used [-Wunused-but-set-variable] Signed-off-by: Chris Ball c...@laptop.org Cc: Michał Mirosław mirq-li...@rere.qmqm.pl Cc: Wolfram Sang w.s...@pengutronix.de Acked-by: Wolfram Sang w.s...@pengutronix.de -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: MMC quirks relating to performance/lifetime.
On Wednesday 23 February 2011, Andrei Warkentin wrote: I am more concerned with workarounds that depend on access size (like the toshiba one) and that modify the MMC commands sent (using reliable writes, like the Toshiba one, or putting parameters differently like the Sandisk erase workaround). It's these kinds of workarounds that the quirks framework is meant to address. I don't think it's a good idea to pollute mmc_blk_issue_rw_rq and mmc_blk_issue_discard_rq with if()-elsed workarounds, because it's going to quickly complicate the logic, and get out of hand and unmanageable the more cards are added. I'm trying to avoid having to make any changes to card/block.c as part of making quirk workarounds. The only cost when compared to an if-else will be one O(log n) quirk lookup, where n is either one or something close that (since the search is only done for quirks per mmc_blk_data), and one callback invoked after brq.data.sg_len = mmc_queue_map_sg(mq); so it can patch up mrq as necessary. Unlike the sysfs interface, the code does not need to be future-proof, it can always be changed if we feel the code becomes more maintainable by doing it another way. The approach that I'd like to see here is: * Start out with an ad-hoc patch for a quirk (like the one you already have). * Add a boolean variable to enable it per card. * Get performance data for this quirk to show that it's useful in real-world workloads for some cards but counterproductive for others * Get the patch into the mmc tree. * Repeat for the next quirk * When the code becomes overly complicated after adding all the quirks, decide on a good strategy to move the code around, and do a new patch. I understand that you are convinced that you will need the indirect function calls in the end. That is fine, just don't add them before they are actually needed -- that would only make it harder for you to get the first patch included. Note that the situation is very different for user interfaces such as sysfs: You need to plan ahead because once the interface is merged upstream, it can never be changed. When you submit a patch that introduces a new sysfs interface, it has to be documented, and you have to convince the reviewers that it is sufficient to cover all the cases it is designed for, while at the same time it is the most simple way to achieve this. Arnd -- 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 0/5] OMAP: HSMMC: hwmod adaptation
Hi Kishore, On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote: Adding hwmod data for hsmmc device on OMAP2430/OMAP3/OMAP4. Adapting the omap_hsmmc driver to hwmod framework. The patch series is based on -rc6 and tested on OMAP2430, OMAP3430SDP OMAP4430SDP. Could you rebase it on top of omap-for-linus, it does apply for the moment. Thanks, Benoit V3: --- Omap2420 platform consists of mmc block as in omap1 and not the hsmmc block as present in omap2430, omap3, omap4 platforms. The series takes care of hwmod adaptation of hsmmc drivers and thus excluding the omap2420 platforms. The patch series has dependency on : 1)https://patchwork.kernel.org/patch/585281/ 2)https://patchwork.kernel.org/patch/538301/ V2: --- http://www.spinics.net/lists/linux-omap/msg45443.html V1: --- http://www.spinics.net/lists/linux-mmc/msg05689.html Anand Gadiyar (1): OMAP4: hwmod data: enable HSMMC Kishore Kadiyala (2): OMAP: hwmod data: Add dev_attr and use in the host driver OMAP: adapt hsmmc to hwmod framework Paul Walmsley (2): OMAP2430: hwmod data: Add HSMMC OMAP3: hwmod data: Add HSMMC arch/arm/mach-omap2/devices.c | 251 arch/arm/mach-omap2/hsmmc.c| 153 -- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 155 + arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 221 arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 26 +++- arch/arm/mach-omap2/prcm-common.h |4 + arch/arm/plat-omap/include/plat/mmc.h | 24 +-- drivers/mmc/host/omap_hsmmc.c |4 +- 8 files changed, 554 insertions(+), 284 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-omap 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 v3 3/5] OMAP4: hwmod data: enable HSMMC
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
From: Anand Gadiyargadi...@ti.com
Enabling hsmmc hwmod for OMAP4
Signed-off-by: Anand Gadiyargadi...@ti.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
CC: Kevin Hilmankhil...@deeprootsystems.com
Acked-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 79a8601..dd39e75 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5077,11 +5077,11 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[]
= {
omap44xx_mcspi4_hwmod,
/* mmc class */
-/* omap44xx_mmc1_hwmod, */
-/* omap44xx_mmc2_hwmod, */
-/* omap44xx_mmc3_hwmod, */
-/* omap44xx_mmc4_hwmod, */
-/* omap44xx_mmc5_hwmod, */
+ omap44xx_mmc1_hwmod,
+ omap44xx_mmc2_hwmod,
+ omap44xx_mmc3_hwmod,
+ omap44xx_mmc4_hwmod,
+ omap44xx_mmc5_hwmod,
/* mpu class */
omap44xx_mpu_hwmod,
--
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 4/5] OMAP: hwmod data: Add dev_attr and use in the host driver
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
Add a device attribute to hwmod data of omap2430, omap3, omap4.
Currently the device attribute holds information regarding dual volt MMC card
support by the controller which will be later passed to the host driver via
platform data.
Signed-off-by: Kevin Hilmankhil...@deeprootsystems.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
Cc: Paul Walmsleyp...@pwsan.com
There are few minor comments to fix hence the:
Almost-Acked-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |9 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16
arch/arm/plat-omap/include/plat/mmc.h | 10 ++
drivers/mmc/host/omap_hsmmc.c |4 ++--
5 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 4d45b7d..e050355 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -19,6 +19,7 @@
#includeplat/i2c.h
#includeplat/gpio.h
#includeplat/mcspi.h
+#includeplat/mmc.h
#include omap_hwmod_common_data.h
@@ -1290,6 +1291,10 @@ static struct omap_hwmod_class mmc_class = {
/* MMC/SD/SDIO1 */
+static struct mmc_dev_attr mmc1_dev_attr = {
Could you rename the struct omap_mmc_dev_attr to stick to the convention?
The dev_attr should be just above static struct omap_hwmod. See the
OMAP4 example below.
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod_irq_info mmc1_mpu_irqs[] = {
{ .irq = 83 },
};
@@ -1328,11 +1333,14 @@ static struct omap_hwmod omap2430_mmc1_hwmod = {
.slaves = omap2430_mmc1_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_mmc1_slaves),
.class =mmc_class,
+ .dev_attr =mmc1_dev_attr,
dev_attr should be above .slaves.
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP2430),
};
/* MMC/SD/SDIO2 */
+static struct mmc_dev_attr mmc2_dev_attr;
If you do not have any dev_attr for that instance, do not add it here
and test for null pointer in your driver.
This comment applies for all instances in all OMAPs.
+
static struct omap_hwmod_irq_info mmc2_mpu_irqs[] = {
{ .irq = 86 },
};
@@ -1371,6 +1379,7 @@ static struct omap_hwmod omap2430_mmc2_hwmod = {
.slaves = omap2430_mmc2_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_mmc2_slaves),
.class =mmc_class,
+ .dev_attr =mmc2_dev_attr,
Not needed if there is not data in the structure.
[...]
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index dd39e75..6c4ccfd 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -25,6 +25,7 @@
#includeplat/gpio.h
#includeplat/dma.h
#includeplat/mcspi.h
+#includeplat/mmc.h
#include omap_hwmod_common_data.h
@@ -3383,6 +3384,10 @@ static struct omap_hwmod_class omap44xx_mmc_hwmod_class
= {
};
/* mmc1 */
+static struct mmc_dev_attr omap_mmc1_dev_attr = {
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod_irq_info omap44xx_mmc1_irqs[] = {
{ .irq = 83 + OMAP44XX_IRQ_GIC_START },
};
@@ -3437,10 +3442,14 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc1_slaves),
.masters= omap44xx_mmc1_masters,
.masters_cnt= ARRAY_SIZE(omap44xx_mmc1_masters),
+ .dev_attr =omap_mmc1_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
/* mmc2 */
+static struct omap_hwmod omap44xx_mmc2_hwmod;
+static struct mmc_dev_attr omap_mmc2_dev_attr;
+
static struct omap_hwmod_irq_info omap44xx_mmc2_irqs[] = {
{ .irq = 86 + OMAP44XX_IRQ_GIC_START },
};
@@ -3495,11 +3504,13 @@ static struct omap_hwmod omap44xx_mmc2_hwmod = {
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc2_slaves),
.masters= omap44xx_mmc2_masters,
.masters_cnt= ARRAY_SIZE(omap44xx_mmc2_masters),
+ .dev_attr =omap_mmc2_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
/* mmc3 */
static struct omap_hwmod omap44xx_mmc3_hwmod;
+static struct mmc_dev_attr omap_mmc3_dev_attr;
static struct omap_hwmod_irq_info omap44xx_mmc3_irqs[] = {
{ .irq = 94 + OMAP44XX_IRQ_GIC_START },
};
@@ -3547,11 +3558,13 @@ static struct omap_hwmod omap44xx_mmc3_hwmod = {
},
.slaves = omap44xx_mmc3_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc3_slaves),
+ .dev_attr =omap_mmc3_dev_attr,
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP4430),
};
/* mmc4 */
static struct omap_hwmod omap44xx_mmc4_hwmod;
+static struct mmc_dev_attr
[PATCH 1/1]mmc: fix division by zero when calculate mmc erase time
Since if clock gating feature is enabled, the clock frequency may be zero when host clock is gated. In such scenario, mmc_set_mmc_erase_timeout() may have a division by zero bug. So this patch used mmc_host_clk_rate() to fix this. Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com --- drivers/mmc/core/core.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 34a7e8c..12d0eb8 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1201,8 +1201,14 @@ static void mmc_set_mmc_erase_timeout(struct mmc_card *card, * less but not that much less, so fudge it by multiplying by 2. */ timeout_clks = 1; - timeout_us += (timeout_clks * 1000) / - (card-host-ios.clock / 1000); + + /* +* at this moment, host controller maybe clock gated, so make +* sure we can get a correct host clock freq. +*/ + if (mmc_host_clk_rate(card-host)) + timeout_us += (timeout_clks * 1000) / + (mmc_host_clk_rate(card-host) / 1000); erase_timeout = timeout_us / 1000; -- 1.6.6.1 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1]mmc: set timeout for SDHCI host before sending busy cmd
Set the timeout control register for SDHCI host when it needs to send some
commands which need busy signal. Use the maximum timeout value will be safe.
Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com
---
drivers/mmc/host/sdhci.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9e15f41..32b7475 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -40,7 +40,6 @@
static unsigned int debug_quirks = 0;
-static void sdhci_prepare_data(struct sdhci_host *, struct mmc_data *);
static void sdhci_finish_data(struct sdhci_host *);
static void sdhci_send_command(struct sdhci_host *, struct mmc_command *);
@@ -651,16 +650,23 @@ static void sdhci_set_transfer_irqs(struct sdhci_host
*host)
sdhci_clear_set_irqs(host, dma_irqs, pio_irqs);
}
-static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
+static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command
*cmd)
{
u8 count;
u8 ctrl;
+ struct mmc_data *data = cmd-data;
int ret;
WARN_ON(host-data);
- if (data == NULL)
+ if (data == NULL) {
+ /*
+* set timeout to be maximum value for command with busy signal.
+*/
+ if (cmd-flags MMC_RSP_BUSY)
+ sdhci_writeb(host, 0xE, SDHCI_TIMEOUT_CONTROL);
return;
+ }
/* Sanity checks */
BUG_ON(data-blksz * data-blocks 524288);
@@ -920,7 +926,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
host-cmd = cmd;
- sdhci_prepare_data(host, cmd-data);
+ sdhci_prepare_data(host, cmd);
sdhci_writel(host, cmd-arg, SDHCI_ARGUMENT);
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
Wolfram Sang w.s...@pengutronix.de writes: Hi, Take #3, changes: * also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25) * remove unconditional BROKEN_CARD_DETECTION (leftover) * improved kernel-doc about unused GPIO * added tags from Eric Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you have a chance to retest on mx51? What about the FSL guys? :) I'm getting a hard freeze on my efika sb and mx once I remove the unconditional BROKEN_CARD_DETECTION flag. I'm still investigating the issue. I'll keep you informed if I find something. Arnaud -- 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 5/5] OMAP: adapt hsmmc to hwmod framework
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
Changes involves:
1) Remove controller reset in devices.c which is taken care of
by hwmod framework.
2) Removing all base address macro defines except keeping one for OMAP2420.
3) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device attribute.
Signed-off-by: Paul Walmsleyp...@pwsan.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
CC: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/devices.c | 251 -
arch/arm/mach-omap2/hsmmc.c | 153 ++--
arch/arm/plat-omap/include/plat/mmc.h | 14 --
3 files changed, 141 insertions(+), 277 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 7b35c87..2d2deb6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -503,112 +503,6 @@ static inline void omap_init_aes(void) { }
/*-*/
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-
-#define MMCHS_SYSCONFIG0x0010
-#define MMCHS_SYSCONFIG_SWRESET(1 1)
-#define MMCHS_SYSSTATUS0x0014
-#define MMCHS_SYSSTATUS_RESETDONE (1 0)
-
-static struct platform_device dummy_pdev = {
- .dev = {
- .bus =platform_bus_type,
- },
-};
-
-/**
- * omap_hsmmc_reset() - Full reset of each HS-MMC controller
- *
- * Ensure that each MMC controller is fully reset. Controllers
- * left in an unknown state (by bootloader) may prevent retention
- * or OFF-mode. This is especially important in cases where the
- * MMC driver is not enabled, _or_ built as a module.
- *
- * In order for reset to work, interface, functional and debounce
- * clocks must be enabled. The debounce clock comes from func_32k_clk
- * and is not under SW control, so we only enable i- and f-clocks.
- **/
-static void __init omap_hsmmc_reset(void)
-{
- u32 i, nr_controllers;
- struct clk *iclk, *fclk;
-
- if (cpu_is_omap242x())
- return;
-
- nr_controllers = cpu_is_omap44xx() ? OMAP44XX_NR_MMC :
- (cpu_is_omap34xx() ? OMAP34XX_NR_MMC : OMAP24XX_NR_MMC);
-
- for (i = 0; i nr_controllers; i++) {
- u32 v, base = 0;
- struct device *dev =dummy_pdev.dev;
-
- switch (i) {
- case 0:
- base = OMAP2_MMC1_BASE;
- break;
- case 1:
- base = OMAP2_MMC2_BASE;
- break;
- case 2:
- base = OMAP3_MMC3_BASE;
- break;
- case 3:
- if (!cpu_is_omap44xx())
- return;
- base = OMAP4_MMC4_BASE;
- break;
- case 4:
- if (!cpu_is_omap44xx())
- return;
- base = OMAP4_MMC5_BASE;
- break;
- }
-
- if (cpu_is_omap44xx())
- base += OMAP4_MMC_REG_OFFSET;
-
- dummy_pdev.id = i;
- dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
- iclk = clk_get(dev, ick);
- if (IS_ERR(iclk))
- goto err1;
- if (clk_enable(iclk))
- goto err2;
-
- fclk = clk_get(dev, fck);
- if (IS_ERR(fclk))
- goto err3;
- if (clk_enable(fclk))
- goto err4;
-
- omap_writel(MMCHS_SYSCONFIG_SWRESET, base + MMCHS_SYSCONFIG);
- v = omap_readl(base + MMCHS_SYSSTATUS);
- while (!(omap_readl(base + MMCHS_SYSSTATUS)
-MMCHS_SYSSTATUS_RESETDONE))
- cpu_relax();
-
- clk_disable(fclk);
- clk_put(fclk);
- clk_disable(iclk);
- clk_put(iclk);
- }
- return;
-
-err4:
- clk_put(fclk);
-err3:
- clk_disable(iclk);
-err2:
- clk_put(iclk);
-err1:
- printk(KERN_WARNING %s: Unable to enable clocks for MMC%d,
- cannot reset.\n, __func__, i);
-}
-#else
-static inline void omap_hsmmc_reset(void) {}
-#endif
-
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
static inline void omap242x_mmc_mux(struct omap_mmc_platform_data
@@ -665,150 +559,6 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data **mmc_data)
#endif
-#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
-
-static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
-
RE: [PATCH 1/1]mmc: fix division by zero when calculate mmc erase time
-Original Message- From: Marc Koschewski [mailto:m...@osknowledge.org] Sent: Thursday, February 24, 2011 7:38 PM To: Dong, Chuanxiao Cc: linux-mmc@vger.kernel.org; c...@laptop.org; adrian.hun...@nokia.com; linus.wall...@linaro.org; linux-ker...@vger.kernel.org Subject: Re: [PATCH 1/1]mmc: fix division by zero when calculate mmc erase time Hi, * Chuanxiao Dong chuanxiao.d...@intel.com [2011-02-24 19:18:01 +0800]: Since if clock gating feature is enabled, the clock frequency may be zero when host clock is gated. In such scenario, mmc_set_mmc_erase_timeout() may have a division by zero bug. So this patch used mmc_host_clk_rate() to fix this. Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com --- drivers/mmc/core/core.c | 10 -- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 34a7e8c..12d0eb8 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1201,8 +1201,14 @@ static void mmc_set_mmc_erase_timeout(struct mmc_card *card, * less but not that much less, so fudge it by multiplying by 2. */ timeout_clks = 1; - timeout_us += (timeout_clks * 1000) / - (card-host-ios.clock / 1000); + + /* +* at this moment, host controller maybe clock gated, so make +* sure we can get a correct host clock freq. +*/ + if (mmc_host_clk_rate(card-host)) + timeout_us += (timeout_clks * 1000) / + (mmc_host_clk_rate(card-host) / 1000); Why don't you just reuse mmc_host_clk_rate()'s result instead of calling it twice? This is a incline function and just return host-ios.clock. Reuse mmc_host_clk_rate()'s result need to add a new variable to save the value. Thanks Chuanxiao -- 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]mmc: fix division by zero when calculate mmc erase time
* Dong, Chuanxiao chuanxiao.d...@intel.com [2011-02-24 20:09:59 +0800]:
-Original Message-
From: Marc Koschewski [mailto:m...@osknowledge.org]
Sent: Thursday, February 24, 2011 7:38 PM
To: Dong, Chuanxiao
Cc: linux-mmc@vger.kernel.org; c...@laptop.org; adrian.hun...@nokia.com;
linus.wall...@linaro.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 1/1]mmc: fix division by zero when calculate mmc erase
time
Hi,
* Chuanxiao Dong chuanxiao.d...@intel.com [2011-02-24 19:18:01 +0800]:
Since if clock gating feature is enabled, the clock frequency may be zero
when
host clock is gated. In such scenario, mmc_set_mmc_erase_timeout() may
have a
division by zero bug.
So this patch used mmc_host_clk_rate() to fix this.
Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com
---
drivers/mmc/core/core.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 34a7e8c..12d0eb8 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1201,8 +1201,14 @@ static void mmc_set_mmc_erase_timeout(struct
mmc_card *card,
* less but not that much less, so fudge it by multiplying by 2.
*/
timeout_clks = 1;
- timeout_us += (timeout_clks * 1000) /
- (card-host-ios.clock / 1000);
+
+ /*
+ * at this moment, host controller maybe clock gated, so make
+ * sure we can get a correct host clock freq.
+ */
+ if (mmc_host_clk_rate(card-host))
+ timeout_us += (timeout_clks * 1000) /
+ (mmc_host_clk_rate(card-host) / 1000);
Why don't you just reuse mmc_host_clk_rate()'s result instead of calling it
twice?
This is a incline function and just return host-ios.clock. Reuse
mmc_host_clk_rate()'s result need to add a new variable to save the value.
It's not inline on trunk and it spinlocks.
drivers/mmc/core/host.c:195
194 */
195 unsigned int mmc_host_clk_rate(struct mmc_host *host)
196 {
Cheers,
Marc
Thanks
Chuanxiao
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Marc Koschewski
--
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]mmc: fix division by zero when calculate mmc erase time
-Original Message-
From: Marc Koschewski [mailto:m...@osknowledge.org]
Sent: Thursday, February 24, 2011 8:23 PM
To: Dong, Chuanxiao
Cc: linux-mmc@vger.kernel.org; c...@laptop.org; adrian.hun...@nokia.com;
linus.wall...@linaro.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 1/1]mmc: fix division by zero when calculate mmc erase
time
* Dong, Chuanxiao chuanxiao.d...@intel.com [2011-02-24 20:09:59 +0800]:
-Original Message-
From: Marc Koschewski [mailto:m...@osknowledge.org]
Sent: Thursday, February 24, 2011 7:38 PM
To: Dong, Chuanxiao
Cc: linux-mmc@vger.kernel.org; c...@laptop.org; adrian.hun...@nokia.com;
linus.wall...@linaro.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 1/1]mmc: fix division by zero when calculate mmc erase
time
Hi,
* Chuanxiao Dong chuanxiao.d...@intel.com [2011-02-24 19:18:01 +0800]:
Since if clock gating feature is enabled, the clock frequency may be
zero when
host clock is gated. In such scenario, mmc_set_mmc_erase_timeout() may
have a
division by zero bug.
So this patch used mmc_host_clk_rate() to fix this.
Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com
---
drivers/mmc/core/core.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 34a7e8c..12d0eb8 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1201,8 +1201,14 @@ static void mmc_set_mmc_erase_timeout(struct
mmc_card *card,
* less but not that much less, so fudge it by
multiplying by 2.
*/
timeout_clks = 1;
- timeout_us += (timeout_clks * 1000) /
- (card-host-ios.clock / 1000);
+
+ /*
+* at this moment, host controller maybe clock gated,
so make
+* sure we can get a correct host clock freq.
+*/
+ if (mmc_host_clk_rate(card-host))
+ timeout_us += (timeout_clks * 1000) /
+ (mmc_host_clk_rate(card-host) /
1000);
Why don't you just reuse mmc_host_clk_rate()'s result instead of calling
it
twice?
This is a incline function and just return host-ios.clock. Reuse
mmc_host_clk_rate()'s result need to add a new variable to save the value.
It's not inline on trunk and it spinlocks.
drivers/mmc/core/host.c:195
194 */
195 unsigned int mmc_host_clk_rate(struct mmc_host *host)
196 {
OK. With the clock gating framework enabled... I agree. So, what do you think?
Add a new variable is better?
Thanks
Chuanxiao
--
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]mmc: fix division by zero when calculate mmc erase time
* Dong, Chuanxiao chuanxiao.d...@intel.com [2011-02-24 20:25:21 +0800]:
-Original Message-
From: Marc Koschewski [mailto:m...@osknowledge.org]
Sent: Thursday, February 24, 2011 8:23 PM
To: Dong, Chuanxiao
Cc: linux-mmc@vger.kernel.org; c...@laptop.org; adrian.hun...@nokia.com;
linus.wall...@linaro.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 1/1]mmc: fix division by zero when calculate mmc erase
time
* Dong, Chuanxiao chuanxiao.d...@intel.com [2011-02-24 20:09:59 +0800]:
-Original Message-
From: Marc Koschewski [mailto:m...@osknowledge.org]
Sent: Thursday, February 24, 2011 7:38 PM
To: Dong, Chuanxiao
Cc: linux-mmc@vger.kernel.org; c...@laptop.org; adrian.hun...@nokia.com;
linus.wall...@linaro.org; linux-ker...@vger.kernel.org
Subject: Re: [PATCH 1/1]mmc: fix division by zero when calculate mmc
erase
time
Hi,
* Chuanxiao Dong chuanxiao.d...@intel.com [2011-02-24 19:18:01 +0800]:
Since if clock gating feature is enabled, the clock frequency may be
zero when
host clock is gated. In such scenario, mmc_set_mmc_erase_timeout() may
have a
division by zero bug.
So this patch used mmc_host_clk_rate() to fix this.
Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com
---
drivers/mmc/core/core.c | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 34a7e8c..12d0eb8 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1201,8 +1201,14 @@ static void mmc_set_mmc_erase_timeout(struct
mmc_card *card,
* less but not that much less, so fudge it by
multiplying by 2.
*/
timeout_clks = 1;
- timeout_us += (timeout_clks * 1000) /
- (card-host-ios.clock / 1000);
+
+ /*
+ * at this moment, host controller maybe clock gated,
so make
+ * sure we can get a correct host clock freq.
+ */
+ if (mmc_host_clk_rate(card-host))
+ timeout_us += (timeout_clks * 1000) /
+ (mmc_host_clk_rate(card-host) /
1000);
Why don't you just reuse mmc_host_clk_rate()'s result instead of
calling it
twice?
This is a incline function and just return host-ios.clock. Reuse
mmc_host_clk_rate()'s result need to add a new variable to save the value.
It's not inline on trunk and it spinlocks.
drivers/mmc/core/host.c:195
194 */
195 unsigned int mmc_host_clk_rate(struct mmc_host *host)
196 {
OK. With the clock gating framework enabled... I agree. So, what do you
think? Add a new variable is better?
I personally would prefer the variable over the spinlock and function call, yes.
And calling the same method with the same parameters on a line and another
time on the next line is generally a bad idea I think. But maybe that's kind
of a 'taste', moreover. It just hit my eye when I saw it...
Cheers,
Marc
Thanks
Chuanxiao
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Marc Koschewski
--
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]mmc: fix division by zero when calculate mmc erase time
2011/2/24 Chuanxiao Dong chuanxiao.d...@intel.com: Since if clock gating feature is enabled, the clock frequency may be zero when host clock is gated. In such scenario, mmc_set_mmc_erase_timeout() may have a division by zero bug. So this patch used mmc_host_clk_rate() to fix this. Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com Acked-by: Linus Walleij linus.wall...@linaro.org Actually I think these divide-by zero bugs were there before since clock 0 is perfectly legal, we just didn't trigger them before. Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] mmc: mxs-mmc: add mmc host driver for i.MX23/28
Please ignore the message which is the one I sent a few days ago and I thought it did not get through. On Tue, Feb 22, 2011 at 04:09:06PM +0800, Shawn Guo wrote: Hi Wolfram, On Mon, Feb 21, 2011 at 06:40:16PM +0100, Wolfram Sang wrote: Shawn, On Mon, Feb 21, 2011 at 06:35:28PM +0800, Shawn Guo wrote: This adds the mmc host driver for Freescale MXS-based SoC i.MX23/28. The driver calls into mxs-dma via generic dmaengine api for both pio and data transfer. Thanks Chris Ball for the indentation patch. Signed-off-by: Shawn Guo shawn@freescale.com Reviewed-by: Arnd Bergmann a...@arndb.de What throughput rates do you get on a mx28-regulated slot serving a card at 50Mhz? This is poor here (55kb/s) while it is OK at 25Mhz. Could be a To make sure we are on the same page, can you share me the test you ran? And I can give it a try on my board. board issue though (or we can fix it later), rest works fine, thus: Tested-by: Wolfram Sang w.s...@pengutronix.de -- Regards, Shawn ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel -- Regards, Shawn -- 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 5/5] OMAP: adapt hsmmc to hwmod framework
On Thu, Feb 24, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote:
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
Changes involves:
1) Remove controller reset in devices.c which is taken care of
by hwmod framework.
2) Removing all base address macro defines except keeping one for
OMAP2420.
3) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device attribute.
Signed-off-by: Paul Walmsleyp...@pwsan.com
Signed-off-by: Kishore Kadiyalakishore.kadiy...@ti.com
Cc: Benoit Coussonb-cous...@ti.com
CC: Kevin Hilmankhil...@deeprootsystems.com
---
arch/arm/mach-omap2/devices.c | 251
-
arch/arm/mach-omap2/hsmmc.c | 153 ++--
arch/arm/plat-omap/include/plat/mmc.h | 14 --
3 files changed, 141 insertions(+), 277 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 7b35c87..2d2deb6 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -503,112 +503,6 @@ static inline void omap_init_aes(void) { }
/*-*/
-#if defined(CONFIG_ARCH_OMAP3) || defined(CONFIG_ARCH_OMAP4)
-
-#define MMCHS_SYSCONFIG 0x0010
-#define MMCHS_SYSCONFIG_SWRESET (1 1)
-#define MMCHS_SYSSTATUS 0x0014
-#define MMCHS_SYSSTATUS_RESETDONE (1 0)
-
-static struct platform_device dummy_pdev = {
- .dev = {
- .bus =platform_bus_type,
- },
-};
-
-/**
- * omap_hsmmc_reset() - Full reset of each HS-MMC controller
- *
- * Ensure that each MMC controller is fully reset. Controllers
- * left in an unknown state (by bootloader) may prevent retention
- * or OFF-mode. This is especially important in cases where the
- * MMC driver is not enabled, _or_ built as a module.
- *
- * In order for reset to work, interface, functional and debounce
- * clocks must be enabled. The debounce clock comes from func_32k_clk
- * and is not under SW control, so we only enable i- and f-clocks.
- **/
-static void __init omap_hsmmc_reset(void)
-{
- u32 i, nr_controllers;
- struct clk *iclk, *fclk;
-
- if (cpu_is_omap242x())
- return;
-
- nr_controllers = cpu_is_omap44xx() ? OMAP44XX_NR_MMC :
- (cpu_is_omap34xx() ? OMAP34XX_NR_MMC : OMAP24XX_NR_MMC);
-
- for (i = 0; i nr_controllers; i++) {
- u32 v, base = 0;
- struct device *dev =dummy_pdev.dev;
-
- switch (i) {
- case 0:
- base = OMAP2_MMC1_BASE;
- break;
- case 1:
- base = OMAP2_MMC2_BASE;
- break;
- case 2:
- base = OMAP3_MMC3_BASE;
- break;
- case 3:
- if (!cpu_is_omap44xx())
- return;
- base = OMAP4_MMC4_BASE;
- break;
- case 4:
- if (!cpu_is_omap44xx())
- return;
- base = OMAP4_MMC5_BASE;
- break;
- }
-
- if (cpu_is_omap44xx())
- base += OMAP4_MMC_REG_OFFSET;
-
- dummy_pdev.id = i;
- dev_set_name(dummy_pdev.dev, mmci-omap-hs.%d, i);
- iclk = clk_get(dev, ick);
- if (IS_ERR(iclk))
- goto err1;
- if (clk_enable(iclk))
- goto err2;
-
- fclk = clk_get(dev, fck);
- if (IS_ERR(fclk))
- goto err3;
- if (clk_enable(fclk))
- goto err4;
-
- omap_writel(MMCHS_SYSCONFIG_SWRESET, base +
MMCHS_SYSCONFIG);
- v = omap_readl(base + MMCHS_SYSSTATUS);
- while (!(omap_readl(base + MMCHS_SYSSTATUS)
- MMCHS_SYSSTATUS_RESETDONE))
- cpu_relax();
-
- clk_disable(fclk);
- clk_put(fclk);
- clk_disable(iclk);
- clk_put(iclk);
- }
- return;
-
-err4:
- clk_put(fclk);
-err3:
- clk_disable(iclk);
-err2:
- clk_put(iclk);
-err1:
- printk(KERN_WARNING %s: Unable to enable clocks for MMC%d,
- cannot reset.\n, __func__, i);
-}
-#else
-static inline void omap_hsmmc_reset(void) {}
-#endif
-
#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
static inline void omap242x_mmc_mux(struct omap_mmc_platform_data
@@ -665,150 +559,6 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data
Re: [PATCH v3 5/5] OMAP: adapt hsmmc to hwmod framework
On Thu, Feb 24, 2011 at 11:58 AM, Varadarajan, Charulatha ch...@ti.com wrote:
Kishore,
On Wed, Feb 23, 2011 at 23:17, Kishore Kadiyala kishore.kadiy...@ti.com
wrote:
Changes involves:
1) Remove controller reset in devices.c which is taken care of
by hwmod framework.
2) Removing all base address macro defines except keeping one for OMAP2420.
why?
Will mention the details in the log
3) Using omap-device layer to register device and utilizing data from
hwmod data file for base address, dma channel number, Irq_number,
device attribute.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
CC: Kevin Hilman khil...@deeprootsystems.com
---
arch/arm/mach-omap2/devices.c | 251
-
arch/arm/mach-omap2/hsmmc.c | 153 ++--
arch/arm/plat-omap/include/plat/mmc.h | 14 --
3 files changed, 141 insertions(+), 277 deletions(-)
snip
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 34272e4..b6e1eae 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -16,7 +16,11 @@
#include mach/hardware.h
#include plat/mmc.h
#include plat/omap-pm.h
+#include plat/mux.h
+#include plat/omap_hwmod.h
+#include plat/omap_device.h
+#include mux.h
#include hsmmc.h
#include control.h
@@ -30,7 +34,7 @@ static u16 control_mmc1;
static struct hsmmc_controller {
char name[HSMMC_NAME_LEN + 1];
-} hsmmc[OMAP34XX_NR_MMC];
+} hsmmc[OMAP44XX_NR_MMC];
Why do you have a dependency on OMAP44XX_NR_MMC? You should get
this kind of information using number of iterations in *_hwmod_each_by_class.
Ok , will remove
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
@@ -204,7 +208,141 @@ static int nop_mmc_set_power(struct device *dev, int
slot, int power_on,
return 0;
}
-static struct omap_mmc_platform_data *hsmmc_data[OMAP34XX_NR_MMC]
__initdata;
+static inline void omap2_mmc_mux(struct omap_mmc_platform_data
*mmc_controller,
+ int controller_nr)
+{
+ if ((mmc_controller-slots[0].switch_pin 0) \
+ (mmc_controller-slots[0].switch_pin OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-slots[0].switch_pin,
+ OMAP_PIN_INPUT_PULLUP);
+ if ((mmc_controller-slots[0].gpio_wp 0) \
+ (mmc_controller-slots[0].gpio_wp OMAP_MAX_GPIO_LINES))
+ omap_mux_init_gpio(mmc_controller-slots[0].gpio_wp,
+ OMAP_PIN_INPUT_PULLUP);
+ if (cpu_is_omap34xx()) {
+ if (controller_nr == 0) {
+ omap_mux_init_signal(sdmmc1_clk,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_cmd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat0,
+ OMAP_PIN_INPUT_PULLUP);
+ if (mmc_controller-slots[0].caps
+ (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
+ omap_mux_init_signal(sdmmc1_dat1,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat2,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat3,
+ OMAP_PIN_INPUT_PULLUP);
+ }
+ if (mmc_controller-slots[0].caps
+ MMC_CAP_8_BIT_DATA) {
+ omap_mux_init_signal(sdmmc1_dat4,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat5,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat6,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc1_dat7,
+ OMAP_PIN_INPUT_PULLUP);
+ }
+ }
+ if (controller_nr == 1) {
+ /* MMC2 */
+ omap_mux_init_signal(sdmmc2_clk,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc2_cmd,
+ OMAP_PIN_INPUT_PULLUP);
+ omap_mux_init_signal(sdmmc2_dat0,
+ OMAP_PIN_INPUT_PULLUP);
+
+ /*
+ * For 8 wire configurations, Lines DAT4, 5, 6 and 7
+ * need to be muxed in the board-*.c
Re: [PATCH v3 4/5] OMAP: hwmod data: Add dev_attr and use in the host driver
On Thu, Feb 24, 2011 at 11:30 AM, Varadarajan, Charulatha ch...@ti.com wrote:
Kishore,
On Wed, Feb 23, 2011 at 23:17, Kishore Kadiyala kishore.kadiy...@ti.com
wrote:
Add a device attribute to hwmod data of omap2430, omap3, omap4.
Currently the device attribute holds information regarding dual volt MMC card
support by the controller which will be later passed to the host driver via
platform data.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 9 +
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 12
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16
arch/arm/plat-omap/include/plat/mmc.h | 10 ++
drivers/mmc/host/omap_hsmmc.c | 4 ++--
5 files changed, 49 insertions(+), 2 deletions(-)
snip
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index e5de5d4..7853130 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -43,6 +43,13 @@
#define OMAP_MMC_MAX_SLOTS 2
+/* omap_hwmod integration data */
What is omap_hwmod integration data ? Pls clarify.
+#define OMAP_HSMMC_SUPPORTS_DUAL_VOLT BIT(1)
+
+struct mmc_dev_attr {
+ u8 flags;
+};
+
struct omap_mmc_platform_data {
/* back-link to device */
struct device *dev;
@@ -71,6 +78,9 @@ struct omap_mmc_platform_data {
u64 dma_mask;
+ /* Integrating attributes from the omap_hwmod layer */
+ u8 controller_dev_attr;
+
/* Register offset deviation */
u16 reg_offset;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 078fdf1..160cc95 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1555,7 +1555,7 @@ static void omap_hsmmc_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
break;
}
- if (host-id == OMAP_MMC1_DEVID) {
+ if (host-pdata-controller_dev_attr
OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
Where is pdata-controller_dev_attr getting populated? I don't see the
dev_attr from the
hwmod database used anywhere in this patch.
good catch ,
the changes in the driver should be part of last patch.
/* Only MMC1 can interface at 3V without some flavor
* of external transceiver; but they all handle 1.8V.
*/
@@ -1647,7 +1647,7 @@ static void omap_hsmmc_conf_bus_power(struct
omap_hsmmc_host *host)
u32 hctl, capa, value;
/* Only MMC1 supports 3.0V */
- if (host-id == OMAP_MMC1_DEVID) {
+ if (host-pdata-controller_dev_attr
OMAP_HSMMC_SUPPORTS_DUAL_VOLT) {
Ditto.
hctl = SDVS30;
capa = VS30 | VS18;
} else {
--
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/1]mmc: set timeout for SDHCI host before sending busy cmd
Hi
This patch looks like this. I sent to the RFC patch..
http://marc.info/?l=linux-mmcm=129109794815028w=3
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/host/sdhci.c |6 +-
include/linux/mmc/sdhci.h |3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 782c0ee..3b93d97 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -655,8 +655,12 @@ static void sdhci_prepare_data(struct sdhci_host
*host, struct mmc_data *data)
WARN_ON(host-data);
- if (data == NULL)
+ if (data == NULL) {
+ if ((host-quirks SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL)
+ (host-cmd-flags MMC_RSP_BUSY))
+ sdhci_writel(host, 0xE, SDHCI_TIMEOUT_CONTROL);
return;
+ }
/* Sanity checks */
BUG_ON(data-blksz * data-blocks 524288);
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 1fdc673..315ff49 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -83,7 +83,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (128)
/* Controller doesn't have HISPD bit field in HI-SPEED SD card */
#define SDHCI_QUIRK_NO_HISPD_BIT (129)
-
+/* Controller need set data timeout value when card is busy */
+#define SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL (130)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.6.0.4
2011/2/24 Chuanxiao Dong chuanxiao.d...@intel.com:
Set the timeout control register for SDHCI host when it needs to send some
commands which need busy signal. Use the maximum timeout value will be safe.
Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com
---
drivers/mmc/host/sdhci.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9e15f41..32b7475 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -40,7 +40,6 @@
static unsigned int debug_quirks = 0;
-static void sdhci_prepare_data(struct sdhci_host *, struct mmc_data *);
static void sdhci_finish_data(struct sdhci_host *);
static void sdhci_send_command(struct sdhci_host *, struct mmc_command *);
@@ -651,16 +650,23 @@ static void sdhci_set_transfer_irqs(struct sdhci_host
*host)
sdhci_clear_set_irqs(host, dma_irqs, pio_irqs);
}
-static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data
*data)
+static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command
*cmd)
{
u8 count;
u8 ctrl;
+ struct mmc_data *data = cmd-data;
int ret;
WARN_ON(host-data);
- if (data == NULL)
+ if (data == NULL) {
+ /*
+ * set timeout to be maximum value for command with busy
signal.
+ */
+ if (cmd-flags MMC_RSP_BUSY)
+ sdhci_writeb(host, 0xE, SDHCI_TIMEOUT_CONTROL);
return;
+ }
/* Sanity checks */
BUG_ON(data-blksz * data-blocks 524288);
@@ -920,7 +926,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
host-cmd = cmd;
- sdhci_prepare_data(host, cmd-data);
+ sdhci_prepare_data(host, cmd);
sdhci_writel(host, cmd-arg, SDHCI_ARGUMENT);
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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 5/5] OMAP: adapt hsmmc to hwmod framework
On 2/24/2011 2:55 PM, Kadiyala, Kishore wrote:
On Thu, Feb 24, 2011 at 5:19 PM, Cousson, Benoitb-cous...@ti.com wrote:
On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote:
[...]
static struct hsmmc_controller {
charname[HSMMC_NAME_LEN + 1];
-} hsmmc[OMAP34XX_NR_MMC];
+} hsmmc[OMAP44XX_NR_MMC];
I do not know the details of that driver, so this comment might be
completely irrelevant, but in theory, such static table should not be
necessary since the driver core already maintain a list of all instances
bound to it.
I agree, but this is used in slot data for the controller and is used
in the driver
to create a /sys entry.
I guess the sysfs should be able to use only the device instance.
I will try to avoid the OMAP44XX_NR_MMC dependency.
[...]
+static struct omap_mmc_platform_data *hsmmc_data[OMAP44XX_NR_MMC]
__initdata;
Same concern than for hsmmc, why do you need static table here?
Agree, will remove static declaration.
And why do you need another structure? The omap2_hsmmc_info should already
be in a pdata kind of structure.
The board file should just populate a table of pdata that you will use
during init.
No, omap2_hsmmc_info is intermediate structure used by the boards
files to update
some basic info of the controller, based on which the pdata is
populated in hsmmc.c.
This is the point, I guess you can potentially directly fill partially a
pdata with controller information in the board file to avoid that
intermediate structure.
[...]
+ name = mmci-omap-hs;
Could you please rename the device to have something in the form: omap_?
In that case omap_mmc should be good. The hs is just a indication of one
of the mmc instance capability and does not have to be in the device name
since there is no none-hs instance.
I understood your concern but omap1,omap2420 uses mmc driver while
omap2430, omap3 , omap4 has hsmmc driver.
OK, it makes sense then.
omap1, omap2420 boards have device name as mmci-omap currently, but
if they undergo
the similar change as proposed above then it looks like omap_mmc
Therefore for hsmmc driver, I will be happy to have something like omap_hsmmc
please let me know if this is fine.
Excellent, that's fine for me.
Thanks,
Benoit
--
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: mxs-mmc: add mmc host driver for i.MX23/28
Hi Wolfram, On Mon, Feb 21, 2011 at 06:40:16PM +0100, Wolfram Sang wrote: Shawn, On Mon, Feb 21, 2011 at 06:35:28PM +0800, Shawn Guo wrote: This adds the mmc host driver for Freescale MXS-based SoC i.MX23/28. The driver calls into mxs-dma via generic dmaengine api for both pio and data transfer. Thanks Chris Ball for the indentation patch. Signed-off-by: Shawn Guo shawn@freescale.com Reviewed-by: Arnd Bergmann a...@arndb.de What throughput rates do you get on a mx28-regulated slot serving a card at 50Mhz? This is poor here (55kb/s) while it is OK at 25Mhz. Could be a To make sure we are on the same page, can you share me the test you ran? And I can give it a try on my board. board issue though (or we can fix it later), rest works fine, thus: Tested-by: Wolfram Sang w.s...@pengutronix.de -- Regards, Shawn -- 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: support DDR mode
On Thu, Feb 24, 2011 at 10:22:05AM +, Will Newton wrote: On Thu, Feb 24, 2011 at 4:46 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: This patch is applied DDR mode in dw_mmc. DW_MMC is supported DDR mode. If set any bit in UHS_REG bit[16:31], the card of that slot is supported DDR mode. For example, if UHS_REG[16] is set, card number 0 is DDR mode. Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com This looks ok to me. Acked-by: Will Newton will.new...@imgtec.com Thanks, pushed to mmc-next for .39. -- 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
Re: [PATCH V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
On Thu, Feb 24, 2011 at 11:51:28PM +0800, Shawn Guo wrote:
On Thu, Feb 24, 2011 at 04:18:05PM +0800, Shawn Guo wrote:
Hi Wolfram,
On Wed, Feb 23, 2011 at 02:51:53PM +0100, Wolfram Sang wrote:
Take #3, changes:
* also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25)
* remove unconditional BROKEN_CARD_DETECTION (leftover)
* improved kernel-doc about unused GPIO
* added tags from Eric
Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you
have a
chance to retest on mx51? What about the FSL guys? :)
I'm testing it on mx25 3ds and mx51 babbage. Both card-detect and
write-protect are working on mx25 3ds, but write-protect has some
problem on babbage, and I need some time to figure it out.
I just figured out why wp_gpio does not work on mx51.
+ if (cpu_is_mx25() || cpu_is_mx35()) {
+ /* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
host-quirks |= SDHCI_QUIRK_NO_MULTIBLOCK;
+ /* write_protect can't be routed to controller, use gpio */
+ sdhci_esdhc_ops.get_ro = esdhc_pltfm_get_ro;
+ }
Would it make sense to do the same for mx51? On babbage board,
SD1_WP is routed to controller, but SD2_WP is not, so we have to use
gpio for SD2 write_protect.
We should probably have esdhc_pltfm_get_ro whenever platform provides
a wp_gpio, and fall on controller SD_WP only when platform does not
provide the wp_gpio.
--
Regards,
Shawn
--
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 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
On Thu, Feb 24, 2011 at 04:18:05PM +0800, Shawn Guo wrote:
Hi Wolfram,
On Wed, Feb 23, 2011 at 02:51:53PM +0100, Wolfram Sang wrote:
Take #3, changes:
* also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25)
* remove unconditional BROKEN_CARD_DETECTION (leftover)
* improved kernel-doc about unused GPIO
* added tags from Eric
Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you have
a
chance to retest on mx51? What about the FSL guys? :)
I'm testing it on mx25 3ds and mx51 babbage. Both card-detect and
write-protect are working on mx25 3ds, but write-protect has some
problem on babbage, and I need some time to figure it out.
I just figured out why wp_gpio does not work on mx51.
+ if (cpu_is_mx25() || cpu_is_mx35()) {
+ /* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
host-quirks |= SDHCI_QUIRK_NO_MULTIBLOCK;
+ /* write_protect can't be routed to controller, use gpio */
+ sdhci_esdhc_ops.get_ro = esdhc_pltfm_get_ro;
+ }
Would it make sense to do the same for mx51? On babbage board,
SD1_WP is routed to controller, but SD2_WP is not, so we have to use
gpio for SD2 write_protect.
--
Regards,
Shawn
--
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 0/5] OMAP: HSMMC: hwmod adaptation
Hi Benoit, On Thu, Feb 24, 2011 at 3:49 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Kishore, On 2/23/2011 6:47 PM, Kadiyala, Kishore wrote: Adding hwmod data for hsmmc device on OMAP2430/OMAP3/OMAP4. Adapting the omap_hsmmc driver to hwmod framework. The patch series is based on -rc6 and tested on OMAP2430, OMAP3430SDP OMAP4430SDP. Could you rebase it on top of omap-for-linus, it does apply for the moment. Sure, I will repost new version based on omap-for-linus with comments fixed. snip Regards, Kishore -- 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]mmc: set timeout for SDHCI host before sending busy cmd
On Feb 24, 2011, at 6:54 AM, Dong, Chuanxiao wrote:
Great. Maybe we wouldn't need to add this quirk since give a maximum timeout
value is safe for all host controller I think. We would better save the quirk
for other really critical silicon bugs.
proposed this a while ago and strongly support just removing the quirk for
broken timeout and setting the timeout value to maximum of 0xE.
This also handles the case of the sd device having a timeout value too low. In
my testing I have come across SD cards that do not provide the correct value.
We force our pxa168, pxa910, and mmp2 controllers to have 0xE.
Philip
-Original Message-
From: Jae hoon Chung [mailto:jh80.ch...@gmail.com]
Sent: Thursday, February 24, 2011 10:18 PM
To: Dong, Chuanxiao
Cc: linux-mmc@vger.kernel.org; c...@laptop.org; linux-ker...@vger.kernel.org;
a...@arndb.de; Kyungmin Park
Subject: Re: [PATCH 1/1]mmc: set timeout for SDHCI host before sending busy
cmd
Hi
This patch looks like this. I sent to the RFC patch..
http://marc.info/?l=linux-mmcm=129109794815028w=3
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/host/sdhci.c |6 +-
include/linux/mmc/sdhci.h |3 ++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 782c0ee..3b93d97 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -655,8 +655,12 @@ static void sdhci_prepare_data(struct sdhci_host
*host, struct mmc_data *data)
WARN_ON(host-data);
- if (data == NULL)
+ if (data == NULL) {
+ if ((host-quirks SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL)
+ (host-cmd-flags MMC_RSP_BUSY))
+ sdhci_writel(host, 0xE, SDHCI_TIMEOUT_CONTROL);
return;
+ }
/* Sanity checks */
BUG_ON(data-blksz * data-blocks 524288);
diff --git a/include/linux/mmc/sdhci.h b/include/linux/mmc/sdhci.h
index 1fdc673..315ff49 100644
--- a/include/linux/mmc/sdhci.h
+++ b/include/linux/mmc/sdhci.h
@@ -83,7 +83,8 @@ struct sdhci_host {
#define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 (128)
/* Controller doesn't have HISPD bit field in HI-SPEED SD card */
#define SDHCI_QUIRK_NO_HISPD_BIT (129)
-
+/* Controller need set data timeout value when card is busy */
+#define SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL (130)
int irq;/* Device IRQ */
void __iomem *ioaddr; /* Mapped address */
--
1.6.0.4
2011/2/24 Chuanxiao Dong chuanxiao.d...@intel.com:
Set the timeout control register for SDHCI host when it needs to send some
commands which need busy signal. Use the maximum timeout value will be safe.
Signed-off-by: Chuanxiao Dong chuanxiao.d...@intel.com
---
drivers/mmc/host/sdhci.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9e15f41..32b7475 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -40,7 +40,6 @@
static unsigned int debug_quirks = 0;
-static void sdhci_prepare_data(struct sdhci_host *, struct mmc_data *);
static void sdhci_finish_data(struct sdhci_host *);
static void sdhci_send_command(struct sdhci_host *, struct mmc_command
*);
@@ -651,16 +650,23 @@ static void sdhci_set_transfer_irqs(struct sdhci_host
*host)
sdhci_clear_set_irqs(host, dma_irqs, pio_irqs);
}
-static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data
*data)
+static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_command
*cmd)
{
u8 count;
u8 ctrl;
+ struct mmc_data *data = cmd-data;
int ret;
WARN_ON(host-data);
- if (data == NULL)
+ if (data == NULL) {
+ /*
+* set timeout to be maximum value for command with busy
signal.
+*/
+ if (cmd-flags MMC_RSP_BUSY)
+ sdhci_writeb(host, 0xE,
SDHCI_TIMEOUT_CONTROL);
return;
+ }
/* Sanity checks */
BUG_ON(data-blksz * data-blocks 524288);
@@ -920,7 +926,7 @@ static void sdhci_send_command(struct sdhci_host *host,
struct mmc_command *cmd)
host-cmd = cmd;
- sdhci_prepare_data(host, cmd-data);
+ sdhci_prepare_data(host, cmd);
sdhci_writel(host, cmd-arg, SDHCI_ARGUMENT);
--
1.6.6.1
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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
Re: [PATCH] mmc: core: add comment why sdio_reset is done at init time
Hi Philip, On Sun, Feb 13, 2011 at 11:12:28PM -0800, Philip Rakity wrote: sdio_reset sends a CMD52 to reset the sdio card. This is highly recommended for sdio cards being reinitialized. Since we do not know if the card is being reinitialized we just send the command. SD/eMMC cards are supposed to ignore the CMD before the CMD0. Document why we are doing this. Signed-off-by: Philip Rakity prak...@marvell.com --- drivers/mmc/core/core.c |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c index 34a7e8c..d9fb0d3 100644 --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -1494,6 +1494,12 @@ static int mmc_rescan_try_freq(struct mmc_host *host, unsigned freq) mmc_hostname(host), __func__, host-f_init); #endif mmc_power_up(host); + + /* + * sdio_reset sends CMD52 to reset card. Since we do not know + * if the card is being re-initialzed just send it. CMD52 + * should be ignored by SD/eMMC cards + */ sdio_reset(host); mmc_go_idle(host); Thanks, pushed to mmc-next for .39. -- 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
Re: [PATCH V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
Hi Arnaud,
On 24/02/2011 12:40, Arnaud Patard (Rtp) wrote:
Wolfram Sangw.s...@pengutronix.de writes:
Hi,
Take #3, changes:
* also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25)
* remove unconditional BROKEN_CARD_DETECTION (leftover)
* improved kernel-doc about unused GPIO
* added tags from Eric
Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you have a
chance to retest on mx51? What about the FSL guys? :)
I'm getting a hard freeze on my efika sb and mx once I remove the
unconditional BROKEN_CARD_DETECTION flag. I'm still investigating the
issue. I'll keep you informed if I find something.
may you please test the attached patch. It may give someone with a better
knowledge of sdhci than me an idea of what is wrong.
Here are the workaround this patch add :
- we can't let enable or disable irq enabled when the card is present/not
present, else the irq triger again which explains why you get the freeze - so
we must rely on the card presence bit to enable the right interrupt,
- we can't turn the clock off if we want the card detect to work when the card
is removed - as a quick workaround this patch prevents sdhci_set_clock from
turning off the clocks when the SDHCI_INT_CARD_INSERT interrupt is enabled.
Also, I had to change the MX51_PAD_GPIO1_0__SD1_CD pad setting as follows to
enable the internal pull up :
_MX51_PAD_GPIO1_0__SD1_CD | MUX_PAD_CTRL(PAD_CTL_PUS_22K_UP |
PAD_CTL_PKE | PAD_CTL_SRE_FAST |
PAD_CTL_DSE_HIGH | PAD_CTL_PUE | PAD_CTL_HYS),
Eric
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c b/drivers/mmc/host/sdhci-esdhc-imx.c
index 8ac039a..be11151 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -217,6 +217,8 @@ static int esdhc_pltfm_init(struct sdhci_host *host, struct sdhci_pltfm_data *pd
/* Now we have a working card_detect again */
host-quirks = ~SDHCI_QUIRK_BROKEN_CARD_DETECTION;
}
+ if (cpu_is_mx51())
+ host-quirks = ~SDHCI_QUIRK_BROKEN_CARD_DETECTION;
return 0;
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 9e15f41..11ef076 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -127,10 +127,14 @@ static void sdhci_set_card_detection(struct sdhci_host *host, bool enable)
if (host-quirks SDHCI_QUIRK_BROKEN_CARD_DETECTION)
return;
- if (enable)
+ sdhci_mask_irqs(host, irqs);
+ if (enable) {
+ if (!(sdhci_readl(host, SDHCI_PRESENT_STATE) SDHCI_CARD_PRESENT))
+ irqs = SDHCI_INT_CARD_INSERT;
+ else
+ irqs = SDHCI_INT_CARD_REMOVE;
sdhci_unmask_irqs(host, irqs);
- else
- sdhci_mask_irqs(host, irqs);
+ }
}
static void sdhci_enable_card_detection(struct sdhci_host *host)
@@ -992,6 +996,9 @@ static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
u16 clk;
unsigned long timeout;
+ if ((clock == 0) (SDHCI_INT_CARD_INSERT sdhci_readl(host, SDHCI_INT_ENABLE)))
+ goto out;
+
if (clock == host-clock)
return;
@@ -1001,6 +1008,7 @@ static void sdhci_set_clock(struct sdhci_host *host, unsigned int clock)
return;
}
+
sdhci_writew(host, 0, SDHCI_CLOCK_CONTROL);
if (clock == 0)
@@ -1583,9 +1591,18 @@ static irqreturn_t sdhci_irq(int irq, void *dev_id)
DBG(*** %s got interrupt: 0x%08x\n,
mmc_hostname(host-mmc), intmask);
- if (intmask (SDHCI_INT_CARD_INSERT | SDHCI_INT_CARD_REMOVE)) {
- sdhci_writel(host, intmask (SDHCI_INT_CARD_INSERT |
- SDHCI_INT_CARD_REMOVE), SDHCI_INT_STATUS);
+ if (intmask SDHCI_INT_CARD_INSERT) {
+ sdhci_unmask_irqs(host, SDHCI_INT_CARD_REMOVE);
+ sdhci_mask_irqs(host, SDHCI_INT_CARD_INSERT);
+ sdhci_writel(host, intmask SDHCI_INT_CARD_INSERT,
+ SDHCI_INT_STATUS);
+ tasklet_schedule(host-card_tasklet);
+ }
+ if (intmask SDHCI_INT_CARD_REMOVE) {
+ sdhci_unmask_irqs(host, SDHCI_INT_CARD_INSERT);
+ sdhci_mask_irqs(host, SDHCI_INT_CARD_REMOVE);
+ sdhci_writel(host, intmask SDHCI_INT_CARD_REMOVE,
+ SDHCI_INT_STATUS);
tasklet_schedule(host-card_tasklet);
}
[PATCH v4 3/6] OMAP4: hwmod data: enable HSMMC
From: Anand Gadiyar gadi...@ti.com
Enabling hsmmc hwmod for OMAP4
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Benoit Coussonb-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index 79a8601..dd39e75 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -5077,11 +5077,11 @@ static __initdata struct omap_hwmod *omap44xx_hwmods[]
= {
omap44xx_mcspi4_hwmod,
/* mmc class */
-/* omap44xx_mmc1_hwmod, */
-/* omap44xx_mmc2_hwmod, */
-/* omap44xx_mmc3_hwmod, */
-/* omap44xx_mmc4_hwmod, */
-/* omap44xx_mmc5_hwmod, */
+ omap44xx_mmc1_hwmod,
+ omap44xx_mmc2_hwmod,
+ omap44xx_mmc3_hwmod,
+ omap44xx_mmc4_hwmod,
+ omap44xx_mmc5_hwmod,
/* mpu class */
omap44xx_mpu_hwmod,
--
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 v4 0/6] OMAP: HSMMC: hwmod adaptation
Adding hwmod data for hsmmc device on OMAP2430/OMAP3/OMAP4. Adapting the omap_hsmmc driver to hwmod framework. The patch series is based on omap-for-linus and tested on OMAP2430, OMAP3430SDP OMAP4430SDP. Also boot tested on OMAP2420SDP. V4: --- Omap2420 platform consists of mmc block as in omap1 and not the hsmmc block as present in omap2430, omap3, omap4 platforms. The series takes care of hwmod adaptation of hsmmc drivers and thus excluding the omap2420 platforms. Also includes renaming of device driver name. The patch series has dependency on : 1)https://patchwork.kernel.org/patch/585281/ 2)https://patchwork.kernel.org/patch/538301/ V3: -- http://www.spinics.net/lists/linux-omap/msg46783.html V2: --- http://www.spinics.net/lists/linux-omap/msg45443.html V1: --- http://www.spinics.net/lists/linux-mmc/msg05689.html Anand Gadiyar (1): OMAP4: hwmod data: enable HSMMC Kishore Kadiyala (2): OMAP: hwmod data: Add dev_attr and use in the host driver OMAP: adapt hsmmc to hwmod framework OMAP: hsmmc: Rename the device and driver Paul Walmsley (2): OMAP2430: hwmod data: Add HSMMC OMAP3: hwmod data: Add HSMMC arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |6 +- arch/arm/mach-omap2/board-4430sdp.c |4 +- arch/arm/mach-omap2/board-devkit8000.c |2 +- arch/arm/mach-omap2/board-igep0020.c |6 +- arch/arm/mach-omap2/board-igep0030.c |6 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |6 +- arch/arm/mach-omap2/board-omap4panda.c |4 +- arch/arm/mach-omap2/board-rm680.c|2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |8 +- arch/arm/mach-omap2/board-zoom-peripherals.c |2 +- arch/arm/mach-omap2/clock2430_data.c | 12 +- arch/arm/mach-omap2/clock3xxx_data.c | 12 +- arch/arm/mach-omap2/clock44xx_data.c | 20 +- arch/arm/mach-omap2/devices.c| 251 arch/arm/mach-omap2/hsmmc.c | 417 +- arch/arm/mach-omap2/omap_hwmod_2430_data.c | 152 ++ arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 215 + arch/arm/mach-omap2/omap_hwmod_44xx_data.c | 16 +- arch/arm/mach-omap2/prcm-common.h|4 + arch/arm/plat-omap/include/plat/mmc.h| 29 +-- drivers/mmc/host/omap_hsmmc.c|6 +- 23 files changed, 713 insertions(+), 471 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/6] OMAP: hwmod data: Add dev_attr and use in the host driver
Add a device attribute to hwmod data of omap2430, omap3, omap4.
Currently the device attribute holds information regarding dual volt MMC card
support by the controller which will be later passed to the host driver via
platform data.
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c |6 ++
arch/arm/mach-omap2/omap_hwmod_44xx_data.c |6 ++
arch/arm/plat-omap/include/plat/mmc.h |9 +
4 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index 9c99083..cbb7c9d 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -19,6 +19,7 @@
#include plat/i2c.h
#include plat/gpio.h
#include plat/mcspi.h
+#include plat/mmc.h
#include plat/l3_2xxx.h
#include omap_hwmod_common_data.h
@@ -1568,6 +1569,10 @@ static struct omap_hwmod_class mmc_class = {
/* MMC/SD/SDIO1 */
+static struct omap_mmc_dev_attr mmc1_dev_attr = {
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod_irq_info mmc1_mpu_irqs[] = {
{ .irq = 83 },
};
@@ -1603,6 +1608,7 @@ static struct omap_hwmod omap2430_mmc1_hwmod = {
.idlest_idle_bit = OMAP2430_ST_MMCHS1_SHIFT,
},
},
+ .dev_attr = mmc1_dev_attr,
.slaves = omap2430_mmc1_slaves,
.slaves_cnt = ARRAY_SIZE(omap2430_mmc1_slaves),
.class = mmc_class,
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index d4e734e..7fa2dfb 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -22,6 +22,7 @@
#include plat/l4_3xxx.h
#include plat/i2c.h
#include plat/gpio.h
+#include plat/mmc.h
#include plat/smartreflex.h
#include plat/mcspi.h
@@ -2292,6 +2293,10 @@ static struct omap_hwmod_class mmc_class = {
/* MMC/SD/SDIO1 */
+static struct omap_mmc_dev_attr mmc1_dev_attr = {
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod_irq_info mmc1_mpu_irqs[] = {
{ .irq = 83, },
};
@@ -2327,6 +2332,7 @@ static struct omap_hwmod omap3xxx_mmc1_hwmod = {
.idlest_idle_bit = OMAP3430_ST_MMC1_SHIFT,
},
},
+ .dev_attr = mmc1_dev_attr,
.slaves = omap3xxx_mmc1_slaves,
.slaves_cnt = ARRAY_SIZE(omap3xxx_mmc1_slaves),
.class = mmc_class,
diff --git a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
index dd39e75..28031e3 100644
--- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
@@ -25,6 +25,7 @@
#include plat/gpio.h
#include plat/dma.h
#include plat/mcspi.h
+#include plat/mmc.h
#include omap_hwmod_common_data.h
@@ -3383,6 +3384,10 @@ static struct omap_hwmod_class omap44xx_mmc_hwmod_class
= {
};
/* mmc1 */
+static struct omap_mmc_dev_attr mmc1_dev_attr = {
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod_irq_info omap44xx_mmc1_irqs[] = {
{ .irq = 83 + OMAP44XX_IRQ_GIC_START },
};
@@ -3433,6 +3438,7 @@ static struct omap_hwmod omap44xx_mmc1_hwmod = {
.clkctrl_reg = OMAP4430_CM_L3INIT_MMC1_CLKCTRL,
},
},
+ .dev_attr = mmc1_dev_attr,
.slaves = omap44xx_mmc1_slaves,
.slaves_cnt = ARRAY_SIZE(omap44xx_mmc1_slaves),
.masters= omap44xx_mmc1_masters,
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index e5de5d4..a7afab0 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -43,6 +43,12 @@
#define OMAP_MMC_MAX_SLOTS 2
+#define OMAP_HSMMC_SUPPORTS_DUAL_VOLT BIT(1)
+
+struct omap_mmc_dev_attr {
+ u8 flags;
+};
+
struct omap_mmc_platform_data {
/* back-link to device */
struct device *dev;
@@ -71,6 +77,9 @@ struct omap_mmc_platform_data {
u64 dma_mask;
+ /* Integrating attributes from the omap_hwmod layer */
+ u8 controller_flags;
+
/* Register offset deviation */
u16 reg_offset;
--
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 v4 1/6] OMAP2430: hwmod data: Add HSMMC
From: Paul Walmsley p...@pwsan.com
Update the omap2430 hwmod data with the HSMMC info.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_2430_data.c | 146
1 files changed, 146 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
index de0015d..9c99083 100644
--- a/arch/arm/mach-omap2/omap_hwmod_2430_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_2430_data.c
@@ -54,6 +54,8 @@ static struct omap_hwmod omap2430_dma_system_hwmod;
static struct omap_hwmod omap2430_mcspi1_hwmod;
static struct omap_hwmod omap2430_mcspi2_hwmod;
static struct omap_hwmod omap2430_mcspi3_hwmod;
+static struct omap_hwmod omap2430_mmc1_hwmod;
+static struct omap_hwmod omap2430_mmc2_hwmod;
/* L3 - L4_CORE interface */
static struct omap_hwmod_ocp_if omap2430_l3_main__l4_core = {
@@ -250,6 +252,42 @@ static struct omap_hwmod_ocp_if
*omap2430_usbhsotg_slaves[] = {
omap2430_l4_core__usbhsotg,
};
+/* L4 CORE - MMC1 interface */
+static struct omap_hwmod_addr_space omap2430_mmc1_addr_space[] = {
+ {
+ .pa_start = 0x4809c000,
+ .pa_end = 0x4809c1ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__mmc1 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mmc1_hwmod,
+ .clk= mmchs1_ick,
+ .addr = omap2430_mmc1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap2430_mmc1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
+/* L4 CORE - MMC2 interface */
+static struct omap_hwmod_addr_space omap2430_mmc2_addr_space[] = {
+ {
+ .pa_start = 0x480b4000,
+ .pa_end = 0x480b41ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap2430_l4_core__mmc2 = {
+ .master = omap2430_l4_core_hwmod,
+ .slave = omap2430_mmc2_hwmod,
+ .addr = omap2430_mmc2_addr_space,
+ .clk= mmchs2_ick,
+ .addr_cnt = ARRAY_SIZE(omap2430_mmc2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+};
+
/* Slave interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2430_l4_core_slaves[] = {
omap2430_l3_main__l4_core,
@@ -258,6 +296,8 @@ static struct omap_hwmod_ocp_if *omap2430_l4_core_slaves[]
= {
/* Master interfaces on the L4_CORE interconnect */
static struct omap_hwmod_ocp_if *omap2430_l4_core_masters[] = {
omap2430_l4_core__l4_wkup,
+ omap2430_l4_core__mmc1,
+ omap2430_l4_core__mmc2,
};
/* L4 CORE */
@@ -1508,6 +1548,110 @@ static struct omap_hwmod omap2430_usbhsotg_hwmod = {
+/* MMC/SD/SDIO common */
+
+static struct omap_hwmod_class_sysconfig mmc_sysc = {
+ .rev_offs = 0x1fc,
+ .sysc_offs = 0x10,
+ .syss_offs = 0x14,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class mmc_class = {
+ .name = mmc,
+ .sysc = mmc_sysc,
+};
+
+/* MMC/SD/SDIO1 */
+
+static struct omap_hwmod_irq_info mmc1_mpu_irqs[] = {
+ { .irq = 83 },
+};
+
+static struct omap_hwmod_dma_info mmc1_sdma_reqs[] = {
+ { .name = tx, .dma_req = 61 }, /* DMA_MMC1_TX */
+ { .name = rx, .dma_req = 62 }, /* DMA_MMC1_RX */
+};
+
+static struct omap_hwmod_opt_clk mmc1_opt_clks[] = {
+ { .role = dbck, .clk = mmchsdb_fck },
+};
+
+static struct omap_hwmod_ocp_if *omap2430_mmc1_slaves[] = {
+ omap2430_l4_core__mmc1,
+};
+
+static struct omap_hwmod omap2430_mmc1_hwmod = {
+ .name = mmc1,
+ .mpu_irqs = mmc1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(mmc1_mpu_irqs),
+ .sdma_reqs = mmc1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(mmc1_sdma_reqs),
+ .opt_clks = mmc1_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(mmc1_opt_clks),
+ .main_clk = mmchs1_fck,
+ .prcm = {
+ .omap2 = {
+ .module_offs = CORE_MOD,
+ .prcm_reg_id = 2,
+ .module_bit = OMAP2430_EN_MMCHS1_SHIFT,
+ .idlest_reg_id = 2,
+ .idlest_idle_bit = OMAP2430_ST_MMCHS1_SHIFT,
+ },
+ },
+ .slaves = omap2430_mmc1_slaves,
+ .slaves_cnt =
[PATCH v4 2/6] OMAP3: hwmod data: Add HSMMC
From: Paul Walmsley p...@pwsan.com
Update the omap3 hwmod data with the HSMMC info.
Signed-off-by: Paul Walmsley p...@pwsan.com
Signed-off-by: Kevin Hilman khil...@deeprootsystems.com
Signed-off-by: Rajendra Nayak rna...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Benoit Cousson b-cous...@ti.com
---
arch/arm/mach-omap2/omap_hwmod_3xxx_data.c | 209
arch/arm/mach-omap2/prcm-common.h |4 +
2 files changed, 213 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
index e9d0012..d4e734e 100644
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -68,6 +68,9 @@ static struct omap_hwmod omap34xx_mcspi1;
static struct omap_hwmod omap34xx_mcspi2;
static struct omap_hwmod omap34xx_mcspi3;
static struct omap_hwmod omap34xx_mcspi4;
+static struct omap_hwmod omap3xxx_mmc1_hwmod;
+static struct omap_hwmod omap3xxx_mmc2_hwmod;
+static struct omap_hwmod omap3xxx_mmc3_hwmod;
static struct omap_hwmod am35xx_usbhsotg_hwmod;
static struct omap_hwmod omap3xxx_dma_system_hwmod;
@@ -158,6 +161,63 @@ static struct omap_hwmod_ocp_if omap3xxx_l4_core__l4_wkup
= {
.user = OCP_USER_MPU | OCP_USER_SDMA,
};
+/* L4 CORE - MMC1 interface */
+static struct omap_hwmod_addr_space omap3xxx_mmc1_addr_space[] = {
+ {
+ .pa_start = 0x4809c000,
+ .pa_end = 0x4809c1ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmc1 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_mmc1_hwmod,
+ .clk= mmchs1_ick,
+ .addr = omap3xxx_mmc1_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_mmc1_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .flags = OMAP_FIREWALL_L4
+};
+
+/* L4 CORE - MMC2 interface */
+static struct omap_hwmod_addr_space omap3xxx_mmc2_addr_space[] = {
+ {
+ .pa_start = 0x480b4000,
+ .pa_end = 0x480b41ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmc2 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_mmc2_hwmod,
+ .clk= mmchs2_ick,
+ .addr = omap3xxx_mmc2_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_mmc2_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .flags = OMAP_FIREWALL_L4
+};
+
+/* L4 CORE - MMC3 interface */
+static struct omap_hwmod_addr_space omap3xxx_mmc3_addr_space[] = {
+ {
+ .pa_start = 0x480ad000,
+ .pa_end = 0x480ad1ff,
+ .flags = ADDR_TYPE_RT,
+ },
+};
+
+static struct omap_hwmod_ocp_if omap3xxx_l4_core__mmc3 = {
+ .master = omap3xxx_l4_core_hwmod,
+ .slave = omap3xxx_mmc3_hwmod,
+ .clk= mmchs3_ick,
+ .addr = omap3xxx_mmc3_addr_space,
+ .addr_cnt = ARRAY_SIZE(omap3xxx_mmc3_addr_space),
+ .user = OCP_USER_MPU | OCP_USER_SDMA,
+ .flags = OMAP_FIREWALL_L4
+};
+
/* L4 CORE - UART1 interface */
static struct omap_hwmod_addr_space omap3xxx_uart1_addr_space[] = {
{
@@ -2212,11 +2272,160 @@ static struct omap_hwmod am35xx_usbhsotg_hwmod = {
.omap_chip = OMAP_CHIP_INIT(CHIP_IS_OMAP3430ES3_1)
};
+/* MMC/SD/SDIO common */
+
+static struct omap_hwmod_class_sysconfig mmc_sysc = {
+ .rev_offs = 0x1fc,
+ .sysc_offs = 0x10,
+ .syss_offs = 0x14,
+ .sysc_flags = (SYSC_HAS_CLOCKACTIVITY | SYSC_HAS_SIDLEMODE |
+ SYSC_HAS_ENAWAKEUP | SYSC_HAS_SOFTRESET |
+ SYSC_HAS_AUTOIDLE | SYSS_HAS_RESET_STATUS),
+ .idlemodes = (SIDLE_FORCE | SIDLE_NO | SIDLE_SMART),
+ .sysc_fields= omap_hwmod_sysc_type1,
+};
+
+static struct omap_hwmod_class mmc_class = {
+ .name = mmc,
+ .sysc = mmc_sysc,
+};
+
+/* MMC/SD/SDIO1 */
+
+static struct omap_hwmod_irq_info mmc1_mpu_irqs[] = {
+ { .irq = 83, },
+};
+
+static struct omap_hwmod_dma_info mmc1_sdma_reqs[] = {
+ { .name = tx, .dma_req = 61, },
+ { .name = rx, .dma_req = 62, },
+};
+
+static struct omap_hwmod_opt_clk mmc1_opt_clks[] = {
+ { .role = dbck, .clk = omap_32k_fck, },
+};
+
+static struct omap_hwmod_ocp_if *omap3xxx_mmc1_slaves[] = {
+ omap3xxx_l4_core__mmc1,
+};
+
+static struct omap_hwmod omap3xxx_mmc1_hwmod = {
+ .name = mmc1,
+ .mpu_irqs = mmc1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(mmc1_mpu_irqs),
+ .sdma_reqs = mmc1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(mmc1_sdma_reqs),
+ .opt_clks =
[PATCH v4 6/6] OMAP: hsmmc: Rename the device and driver
Modifying the device driver name from mmci-omap-hs to
omap_hsmmc.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
Cc: Chris Ball c...@laptop.org
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/board-2430sdp.c |2 +-
arch/arm/mach-omap2/board-3430sdp.c |6 +++---
arch/arm/mach-omap2/board-4430sdp.c |4 ++--
arch/arm/mach-omap2/board-devkit8000.c |2 +-
arch/arm/mach-omap2/board-igep0020.c |6 +++---
arch/arm/mach-omap2/board-igep0030.c |6 +++---
arch/arm/mach-omap2/board-omap3evm.c |2 +-
arch/arm/mach-omap2/board-omap3pandora.c |6 +++---
arch/arm/mach-omap2/board-omap4panda.c |4 ++--
arch/arm/mach-omap2/board-rm680.c|2 +-
arch/arm/mach-omap2/board-rx51-peripherals.c |8
arch/arm/mach-omap2/board-zoom-peripherals.c |2 +-
arch/arm/mach-omap2/clock2430_data.c | 12 ++--
arch/arm/mach-omap2/clock3xxx_data.c | 12 ++--
arch/arm/mach-omap2/clock44xx_data.c | 20 ++--
arch/arm/mach-omap2/hsmmc.c |2 +-
drivers/mmc/host/omap_hsmmc.c|2 +-
17 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/arch/arm/mach-omap2/board-2430sdp.c
b/arch/arm/mach-omap2/board-2430sdp.c
index cc42d47..ab0880b 100644
--- a/arch/arm/mach-omap2/board-2430sdp.c
+++ b/arch/arm/mach-omap2/board-2430sdp.c
@@ -149,7 +149,7 @@ static void __init omap_2430sdp_init_early(void)
}
static struct regulator_consumer_supply sdp2430_vmmc1_supplies[] = {
- REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0),
+ REGULATOR_SUPPLY(vmmc, omap_hsmmc.0),
};
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
diff --git a/arch/arm/mach-omap2/board-3430sdp.c
b/arch/arm/mach-omap2/board-3430sdp.c
index 8950ecc..40b0174 100644
--- a/arch/arm/mach-omap2/board-3430sdp.c
+++ b/arch/arm/mach-omap2/board-3430sdp.c
@@ -410,15 +410,15 @@ static struct regulator_consumer_supply
sdp3430_vpll2_supplies[] = {
};
static struct regulator_consumer_supply sdp3430_vmmc1_supplies[] = {
- REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0),
+ REGULATOR_SUPPLY(vmmc, omap_hsmmc.0),
};
static struct regulator_consumer_supply sdp3430_vsim_supplies[] = {
- REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.0),
+ REGULATOR_SUPPLY(vmmc_aux, omap_hsmmc.0),
};
static struct regulator_consumer_supply sdp3430_vmmc2_supplies[] = {
- REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1),
+ REGULATOR_SUPPLY(vmmc, omap_hsmmc.1),
};
/*
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index 1a943be..cca2fbc 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -367,13 +367,13 @@ static struct omap2_hsmmc_info mmc[] = {
static struct regulator_consumer_supply sdp4430_vaux_supply[] = {
{
.supply = vmmc,
- .dev_name = mmci-omap-hs.1,
+ .dev_name = omap_hsmmc.1,
},
};
static struct regulator_consumer_supply sdp4430_vmmc_supply[] = {
{
.supply = vmmc,
- .dev_name = mmci-omap-hs.0,
+ .dev_name = omap_hsmmc.0,
},
};
diff --git a/arch/arm/mach-omap2/board-devkit8000.c
b/arch/arm/mach-omap2/board-devkit8000.c
index 54abdd0..c9170f4 100644
--- a/arch/arm/mach-omap2/board-devkit8000.c
+++ b/arch/arm/mach-omap2/board-devkit8000.c
@@ -140,7 +140,7 @@ static void devkit8000_panel_disable_dvi(struct
omap_dss_device *dssdev)
}
static struct regulator_consumer_supply devkit8000_vmmc1_supply =
- REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
+ REGULATOR_SUPPLY(vmmc, omap_hsmmc.0);
/* ads7846 on SPI */
diff --git a/arch/arm/mach-omap2/board-igep0020.c
b/arch/arm/mach-omap2/board-igep0020.c
index 54e6318..1877c28 100644
--- a/arch/arm/mach-omap2/board-igep0020.c
+++ b/arch/arm/mach-omap2/board-igep0020.c
@@ -250,7 +250,7 @@ static inline void __init igep2_init_smsc911x(void) { }
#endif
static struct regulator_consumer_supply igep2_vmmc1_supply =
- REGULATOR_SUPPLY(vmmc, mmci-omap-hs.0);
+ REGULATOR_SUPPLY(vmmc, omap_hsmmc.0);
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data igep2_vmmc1 = {
@@ -268,7 +268,7 @@ static struct regulator_init_data igep2_vmmc1 = {
};
static struct regulator_consumer_supply igep2_vio_supply =
- REGULATOR_SUPPLY(vmmc_aux, mmci-omap-hs.1);
+ REGULATOR_SUPPLY(vmmc_aux, omap_hsmmc.1);
static struct regulator_init_data igep2_vio = {
.constraints = {
@@ -286,7 +286,7 @@ static struct regulator_init_data igep2_vio = {
};
static struct regulator_consumer_supply igep2_vmmc2_supply =
- REGULATOR_SUPPLY(vmmc, mmci-omap-hs.1);
+ REGULATOR_SUPPLY(vmmc, omap_hsmmc.1);
static struct
Re: [PATCH V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
On Fri, Feb 25, 2011 at 12:03:01AM +0800, Shawn Guo wrote:
On Thu, Feb 24, 2011 at 11:51:28PM +0800, Shawn Guo wrote:
On Thu, Feb 24, 2011 at 04:18:05PM +0800, Shawn Guo wrote:
Hi Wolfram,
On Wed, Feb 23, 2011 at 02:51:53PM +0100, Wolfram Sang wrote:
Take #3, changes:
* also intercept calls to SDHCI_SIGNAL_ENABLE (needed on mx25)
* remove unconditional BROKEN_CARD_DETECTION (leftover)
* improved kernel-doc about unused GPIO
* added tags from Eric
Tested now by me and Marc on mx35, Eric on mx25/35/51. Arnaud, did you
have a
chance to retest on mx51? What about the FSL guys? :)
I'm testing it on mx25 3ds and mx51 babbage. Both card-detect and
write-protect are working on mx25 3ds, but write-protect has some
problem on babbage, and I need some time to figure it out.
I just figured out why wp_gpio does not work on mx51.
+ if (cpu_is_mx25() || cpu_is_mx35()) {
+ /* Fix errata ENGcm07207 present on i.MX25 and i.MX35 */
host-quirks |= SDHCI_QUIRK_NO_MULTIBLOCK;
+ /* write_protect can't be routed to controller, use gpio */
+ sdhci_esdhc_ops.get_ro = esdhc_pltfm_get_ro;
+ }
Would it make sense to do the same for mx51? On babbage board,
SD1_WP is routed to controller, but SD2_WP is not, so we have to use
gpio for SD2 write_protect.
We should probably have esdhc_pltfm_get_ro whenever platform provides
a wp_gpio, and fall on controller SD_WP only when platform does not
provide the wp_gpio.
OK, will think about it. Thanks for testing!
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH 1/1]mmc: set timeout for SDHCI host before sending busy cmd
On Thu, Feb 24, 2011 at 08:15:04PM +, Chris Ball wrote: On Thu, Feb 24, 2011 at 10:32:30AM -0800, Philip Rakity wrote: proposed this a while ago and strongly support just removing the quirk for broken timeout and setting the timeout value to maximum of 0xE. This also handles the case of the sd device having a timeout value too low. In my testing I have come across SD cards that do not provide the correct value. We force our pxa168, pxa910, and mmp2 controllers to have 0xE. Yeah, OLPC's CaFe controller -- which might be the same hardware as yours, actually -- has the same problem. Does anyone know of a reason (beyond strict spec-compliance, I suppose) for honoring the timeout value rather than using 0xE everywhere? If not, I'm willing to try out Philip's suggestion. +1. A full cycle in linux-next might an idea to be on the safe side? That would be 2.6.40-material then. Or too slow? Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH 1/1]mmc: set timeout for SDHCI host before sending busy cmd
Hi, On Thu, Feb 24, 2011 at 09:43:52PM +0100, Wolfram Sang wrote: +1. A full cycle in linux-next might an idea to be on the safe side? That would be 2.6.40-material then. Or too slow? I think it could be okay to merge for .39, but that's mainly because I don't think we start getting testing with a lot of cards until patches appear in an -rc1 -- so for something that requires broad testing, I'd rather merge it for -rc1 with a plan to revert it if we find anything unexpected. But I don't have a strong opinion, so if anyone thinks there's a reason to wait (for example, an existence-proof of a card that misbehaves when configured with a max timeout value) then I'm happy to do so. Thanks, -- 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
Re: [PATCH v4 5/6] OMAP: adapt hsmmc to hwmod framework
* Kishore Kadiyala kishore.kadiy...@ti.com [110224 11:17]: Changes involves: 1) Remove controller reset in devices.c which is taken care of by hwmod framework. 2) Omap2420 platform consists of mmc block as in omap1 and not the hsmmc block as present in omap2430, omap3, omap4 platforms. Removing all base address macro defines except keeping one for OMAP2420. 3) Using omap-device layer to register device and utilizing data from hwmod data file for base address, dma channel number, Irq_number, device attribute. 4) Update the driver to use dev_attr to find whether controller supports dual volt cards This patch is too hard to read. Can you please split it into more readable patches? Thanks, Tony -- 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]mmc: set timeout for SDHCI host before sending busy cmd
On Feb 24, 2011, at 12:15 PM, Chris Ball wrote: On Thu, Feb 24, 2011 at 10:32:30AM -0800, Philip Rakity wrote: proposed this a while ago and strongly support just removing the quirk for broken timeout and setting the timeout value to maximum of 0xE. This also handles the case of the sd device having a timeout value too low. In my testing I have come across SD cards that do not provide the correct value. We force our pxa168, pxa910, and mmp2 controllers to have 0xE. Yeah, OLPC's CaFe controller -- which might be the same hardware as yours, actually -- has the same problem. different controller not same as on mmp2, pxa168, pxa910 Does anyone know of a reason (beyond strict spec-compliance, I suppose) for honoring the timeout value rather than using 0xE everywhere? If not, I'm willing to try out Philip's suggestion. Thanks, -- 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
[PATCH 1/3] dw_mmc: set fixed burst in BMOD register
This patch is applied fixed burst. If use internal DMA controller, i think that need to set this bit. I tested when set this bit or not. I found that increase performance with IDMAC Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com --- drivers/mmc/host/dw_mmc.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c index 58476c1..46e5a89 100644 --- a/drivers/mmc/host/dw_mmc.c +++ b/drivers/mmc/host/dw_mmc.c @@ -315,7 +315,7 @@ static void dw_mci_idmac_stop_dma(struct dw_mci *host) /* Stop the IDMAC running */ temp = mci_readl(host, BMOD); - temp = ~SDMMC_IDMAC_ENABLE; + temp = ~(SDMMC_IDMAC_ENABLE | SDMMC_IDMAC_FB); mci_writel(host, BMOD, temp); } @@ -384,7 +384,7 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host, unsigned int sg_len) /* Enable the IDMAC */ temp = mci_readl(host, BMOD); - temp |= SDMMC_IDMAC_ENABLE; + temp |= SDMMC_IDMAC_ENABLE | SDMMC_IDMAC_FB; mci_writel(host, BMOD, temp); /* Start it running */ -- 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/3] dw_mmc: support mmc power control with regulator
This patch is applied the power control with regulator.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 25 +
include/linux/mmc/dw_mmc.h |2 ++
2 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 46e5a89..338fedc 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -32,6 +32,7 @@
#include linux/mmc/mmc.h
#include linux/mmc/dw_mmc.h
#include linux/bitops.h
+#include linux/regulator/consumer.h
#include dw_mmc.h
@@ -1438,6 +1439,13 @@ static int __init dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
}
#endif /* CONFIG_MMC_DW_IDMAC */
+ host-vmmc = regulator_get(mmc_dev(mmc), vmmc);
+ if (IS_ERR(host-vmmc)) {
+ printk(KERN_INFO %s: no vmmc regulator found\n,
mmc_hostname(mmc));
+ host-vmmc = NULL;
+ } else
+ regulator_enable(host-vmmc);
+
if (dw_mci_get_cd(mmc))
set_bit(DW_MMC_CARD_PRESENT, slot-flags);
else
@@ -1701,6 +1709,12 @@ err_dmaunmap:
host-sg_cpu, host-sg_dma);
iounmap(host-regs);
+ if (host-vmmc) {
+ regulator_disable(host-vmmc);
+ regulator_put(host-vmmc);
+ }
+
+
err_freehost:
kfree(host);
return ret;
@@ -1732,6 +1746,11 @@ static int __exit dw_mci_remove(struct platform_device
*pdev)
if (host-use_dma host-dma_ops-exit)
host-dma_ops-exit(host);
+ if (host-vmmc) {
+ regulator_disable(host-vmmc);
+ regulator_put(host-vmmc);
+ }
+
iounmap(host-regs);
kfree(host);
@@ -1762,6 +1781,9 @@ static int dw_mci_suspend(struct platform_device *pdev,
pm_message_t mesg)
}
}
+ if (host-vmmc)
+ regulator_disable(host-vmmc);
+
return 0;
}
@@ -1770,6 +1792,9 @@ static int dw_mci_resume(struct platform_device *pdev)
int i, ret;
struct dw_mci *host = platform_get_drvdata(pdev);
+ if (host-vmmc)
+ regulator_enable(host-vmmc);
+
for (i = 0; i host-num_slots; i++) {
struct dw_mci_slot *slot = host-slot[i];
if (!slot)
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index 3f22c20..a39c497 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -151,6 +151,8 @@ struct dw_mci {
/* Workaround flags */
u32 quirks;
+
+ struct regulator*vmmc; /* Power regulator */
};
/* DMA ops for Internal/External DMAC interface */
--
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 3/3] dw_mmc: add quirks unreliable detect and capabilities
This patch added quirks and capabilities in platdata.
Some card didn't use the CDn pin. In that case, We assume card inserted,
then the card initialized or not.
And Some board need other capabilities. So added capabilities in board platdata.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/host/dw_mmc.c | 10 --
include/linux/mmc/dw_mmc.h | 10 +++---
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 338fedc..6c01b1e 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -730,7 +730,9 @@ static int dw_mci_get_cd(struct mmc_host *mmc)
struct dw_mci_board *brd = slot-host-pdata;
/* Use platform get_cd function, else try onboard card detect */
- if (brd-get_cd)
+ if (brd-quirks DW_MCI_QUIRK_BROKEN_CARD_DETECTION)
+ present = 1;
+ else if (brd-get_cd)
present = !brd-get_cd(slot-id);
else
present = (mci_readl(slot-host, CDETECT) (1 slot-id))
@@ -1408,7 +1410,11 @@ static int __init dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
if (host-pdata-setpower)
host-pdata-setpower(id, 0);
- mmc-caps = 0;
+ if (host-pdata-caps)
+ mmc-caps = host-pdata-caps;
+ else
+ mmc-caps = 0;
+
if (host-pdata-get_bus_wd)
if (host-pdata-get_bus_wd(slot-id) = 4)
mmc-caps |= MMC_CAP_4_BIT_DATA;
diff --git a/include/linux/mmc/dw_mmc.h b/include/linux/mmc/dw_mmc.h
index a39c497..45b9298 100644
--- a/include/linux/mmc/dw_mmc.h
+++ b/include/linux/mmc/dw_mmc.h
@@ -168,11 +168,13 @@ struct dw_mci_dma_ops {
/* IP Quirks/flags. */
/* DTO fix for command transmission with IDMAC configured */
-#define DW_MCI_QUIRK_IDMAC_DTO BIT(0)
+#define DW_MCI_QUIRK_IDMAC_DTO BIT(0)
/* delay needed between retries on some 2.11a implementations */
-#define DW_MCI_QUIRK_RETRY_DELAY BIT(1)
+#define DW_MCI_QUIRK_RETRY_DELAY BIT(1)
/* High Speed Capable - Supports HS cards (upto 50MHz) */
-#define DW_MCI_QUIRK_HIGHSPEED BIT(2)
+#define DW_MCI_QUIRK_HIGHSPEED BIT(2)
+/* Unreliable card detection */
+#define DW_MCI_QUIRK_BROKEN_CARD_DETECTION BIT(3)
struct dma_pdata;
@@ -192,6 +194,8 @@ struct dw_mci_board {
u32 quirks; /* Workaround / Quirk flags */
unsigned int bus_hz; /* Bus speed */
+ unsigned int caps; /* Capabilities */
+
/* delay in mS before detecting cards after interrupt */
u32 detect_delay_ms;
--
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 2/3] sdhci-pci : Enable runtime PM support
Rafael, Any comments here? It's getting enabled by drivers/pci/pci-driver.c:local_pci_probe(), before the sdhci-pci probe function runs. local_pci_probe() does: /* Unbound PCI devices are always set to disabled and suspended. * During probe, the device is set to enabled and active and the * usage count is incremented. If the driver supports runtime PM, * it should call pm_runtime_put_noidle() in its probe routine and * pm_runtime_get_noresume() in its remove routine. */ pm_runtime_get_noresume(dev); pm_runtime_set_active(dev); pm_runtime_enable(dev); OK. Sounds like it is a change post 2.6.37. So we need to replace the current sdhci runtime_pm initialization by what is in this comments. Maybe Rafael can advice on this. The controller advertises the ability to generate PME wakeups from D3 in its PCI capabilities; perhaps we just aren't programming it properly. I don't see anything in your patch that would set SDHCI wakeup bits or unmask card insertion/removal IRQs -- maybe that could be it? My understanding is the pci driver is not supposed to do any set_power_state/pci_save_state/wake_enable. Everything is supposed to be generically handle by pci frameworks's runtime_pm impl. Need confirmation from Rafael. Regards, Pierre - Intel Corporation SAS (French simplified joint stock company) Registered headquarters: Les Montalets- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] dw_mmc: didn't support multiple blocks of weird length?
Hi..
I didn't understand this point..
Plz let me explain this code..
why need this function (dw_mci_queue_request(host, slot, mrq)?
static void dw_mci_queue_request(struct dw_mci *host, struct dw_mci_slot *slot,
struct mmc_request *mrq)
{
dev_vdbg(slot-mmc-class_dev, queue request: state=%d\n,
host-state);
spin_lock_bh(host-lock);
slot-mrq = mrq;
if (host-state == STATE_IDLE) {
host-state = STATE_SENDING_CMD;
dw_mci_start_request(host, slot);
} else {
list_add_tail(slot-queue_node, host-queue);
}
spin_unlock_bh(host-lock);
}
static void dw_mci_request(struct mmc_host *mmc, struct mmc_request *mrq)
{
struct dw_mci_slot *slot = mmc_priv(mmc);
struct dw_mci *host = slot-host;
WARN_ON(slot-mrq);
if (!test_bit(DW_MMC_CARD_PRESENT, slot-flags)) {
mrq-cmd-error = -ENOMEDIUM;
mmc_request_done(mmc, mrq);
return;
}
/* We don't support multiple blocks of weird lengths. */
dw_mci_queue_request(host, slot, mrq);
}
--
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
