Re: MMC quirks relating to performance/lifetime.
On Friday 25 February 2011, Andrei Warkentin wrote: Yup. I understand :-). That's the strategy I'm going to follow. For page_size-alignment/splitting I'm looking at the block layer now. Is that the right approach or should I still submit a (cleaned up) patch to mmc/card/block.c for that performance improvement. I guess it should live in block/cfq-iosched in the long run, but I don't know how easy it is to implement it there for test purposes. It may be easier to prototype it in the mmc code, since you are more familiar with that already, post that patch together with benchmark results and then do a new patch for the final solution. We'll need more benchmarking to figure out if that should be applied for all nonrotational storage, or if there are cases where it actually hurts performance to split requests on page boundaries. If it turns out to be a good idea in general, we won't even need a sysfs interface for enabling it, just one for reading/writing the underlying page size. The other (Toshiba quirk) is obviously a quirk belonging to mmc/card/block.c. Makes sense. 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 v4 5/6] OMAP: adapt hsmmc to hwmod framework
snip
- if (cpu_is_omap44xx())
- mmc-reg_offset = OMAP4_MMC_REG_OFFSET;
- else
- mmc-reg_offset = 0;
+static struct omap_mmc_platform_data *mmc __initdata;
can you pass this *mmc as another argument to omap_hsmmc_pdata_init
so that this static initdata can be removed ?
- mmc-get_context_loss_count = hsmmc_get_context_loss;
+static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c)
+{
+ char *hc_name;
- mmc-slots[0].switch_pin = c-gpio_cd;
- mmc-slots[0].gpio_wp = c-gpio_wp;
+ if (!c-mmc) {
+ pr_debug(MMC%d: no such controller\n, c-mmc);
+ return -ENXIO;
+ }
- mmc-slots[0].remux = c-remux;
- mmc-slots[0].init_card = c-init_card;
+ hc_name = kzalloc(sizeof(char) * (HSMMC_NAME_LEN + 1), GFP_KERNEL);
+ if (!hc_name) {
+ pr_err(Cannot allocate memory for controller slot name\n);
+ kfree(hc_name);
+ return -ENOMEM;
+ }
- if (c-cover_only)
- mmc-slots[0].cover = 1;
+ if (c-name)
+ strncpy(hc_name, c-name, HSMMC_NAME_LEN);
+ else
+ snprintf(hc_name, (HSMMC_NAME_LEN + 1), mmc%islot%i,
+ c-mmc, 1);
+ mmc-slots[0].name = hc_name;
+ mmc-nr_slots = 1;
snip
--
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 0/6] OMAP: HSMMC: hwmod adaptation
Hi Kishore, On 2/24/2011 8:26 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 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/ This is still not omap-for-linus (at 7cab871)... I cannot apply the series on it:-( Benoit 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
Re: [PATCH v4 0/6] OMAP: HSMMC: hwmod adaptation
Hi Benoit, On Fri, Feb 25, 2011 at 6:24 PM, Cousson, Benoit b-cous...@ti.com wrote: Hi Kishore, On 2/24/2011 8:26 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 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/ This is still not omap-for-linus (at 7cab871)... I cannot apply the series on it:-( The patch series has dependency on link (1) mentioned above [Opening link is throwing error] , below is the new link http://www.mail-archive.com/linux-omap@vger.kernel.org/msg45190.html Could you please check once. 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 v4 0/6] OMAP: HSMMC: hwmod adaptation
On 2/25/2011 2:06 PM, Kadiyala, Kishore wrote: Hi Benoit, On Fri, Feb 25, 2011 at 6:24 PM, Cousson, Benoitb-cous...@ti.com wrote: Hi Kishore, On 2/24/2011 8:26 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 omap-for-linus and tested on OMAP2430, OMAP3430SDPOMAP4430SDP. 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 devicedriver name. The patch series has dependency on : 1)https://patchwork.kernel.org/patch/585281/ That link is broken... that's why it's tricky to get the dependency... 2)https://patchwork.kernel.org/patch/538301/ This is still not omap-for-linus (at 7cab871)... I cannot apply the series on it:-( The patch series has dependency on link (1) mentioned above [Opening link is throwing error] , below is the new link http://www.mail-archive.com/linux-omap@vger.kernel.org/msg45190.html Could you please check once. OK so in fact none of these patches are yet in omap-for-linus. It should be OK for me, because I can apply the hwmod data patch at least. I'll send you my comment on the data in 1 minute... 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 v4 4/6] OMAP: hwmod data: Add dev_attr and use in the host driver
Hi Kishore,
On 2/24/2011 8:26 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
Acked-by: Benoit Cousson b-cous...@ti.com
I slightly moved the OMAP4 dev_attr as discussed in my previous comment
to the right place.
The updated patch is below.
Thanks,
Benoit
---
commit 07385426ddbe1d1154a051474eef628a33f58f73
Author: kishore kadiyala kishore.kadiy...@ti.com
Date: Thu Feb 24 19:26:52 2011 +
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
Acked-by: Benoit Cousson b-cous...@ti.com
Cc: Paul Walmsley p...@pwsan.com
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..e981c5b 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
@@ -3420,6 +3421,11 @@ static struct omap_hwmod_ocp_if
*omap44xx_mmc1_slaves[] = {
omap44xx_l4_per__mmc1,
};
+/* mmc1 dev_attr */
+static struct omap_mmc_dev_attr mmc1_dev_attr = {
+ .flags = OMAP_HSMMC_SUPPORTS_DUAL_VOLT,
+};
+
static struct omap_hwmod omap44xx_mmc1_hwmod = {
.name = mmc1,
.class = omap44xx_mmc_hwmod_class,
@@ -3433,6 +3439,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 f57f36a..b30e0a4 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
Re: [PATCH v4 5/6] OMAP: adapt hsmmc to hwmod framework
On Fri, Feb 25, 2011 at 6:20 PM, Krishnamoorthy, Balaji T
balaj...@ti.com wrote:
snip
- if (cpu_is_omap44xx())
- mmc-reg_offset = OMAP4_MMC_REG_OFFSET;
- else
- mmc-reg_offset = 0;
+static struct omap_mmc_platform_data *mmc __initdata;
can you pass this *mmc as another argument to omap_hsmmc_pdata_init
so that this static initdata can be removed ?
Agree, will go with as said
- mmc-get_context_loss_count = hsmmc_get_context_loss;
+static int __init omap_hsmmc_pdata_init(struct omap2_hsmmc_info *c)
+{
+ char *hc_name;
- mmc-slots[0].switch_pin = c-gpio_cd;
- mmc-slots[0].gpio_wp = c-gpio_wp;
+ if (!c-mmc) {
+ pr_debug(MMC%d: no such controller\n, c-mmc);
+ return -ENXIO;
+ }
- mmc-slots[0].remux = c-remux;
- mmc-slots[0].init_card = c-init_card;
+ hc_name = kzalloc(sizeof(char) * (HSMMC_NAME_LEN + 1), GFP_KERNEL);
+ if (!hc_name) {
+ pr_err(Cannot allocate memory for controller slot name\n);
+ kfree(hc_name);
+ return -ENOMEM;
+ }
- if (c-cover_only)
- mmc-slots[0].cover = 1;
+ if (c-name)
+ strncpy(hc_name, c-name, HSMMC_NAME_LEN);
+ else
+ snprintf(hc_name, (HSMMC_NAME_LEN + 1), mmc%islot%i,
+ c-mmc, 1);
+ mmc-slots[0].name = hc_name;
+ mmc-nr_slots = 1;
snip
--
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
On Fri, Feb 25, 2011 at 07:33:12AM +, Tardy, Pierre wrote: 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. The core can only enable PME generation, it can't configure what generates PMEs. There's a register in sdhci that needs to be programmed to enable wakeups on card insert/removal/interrupt. If you don't then you won't get a PME no matter what the core does. -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] mmc: sh_mmcif: support aggressive clock gating
To support MMC aggressive clock gating the driver has to stop the interface
clock, when the .set_ios() method is called with .clock == 0.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Tested on ap4evb and ecovec
drivers/mmc/host/sh_mmcif.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 12884c2..3d735da 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -850,15 +850,15 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
struct sh_mmcif_host *host = mmc_priv(mmc);
struct sh_mmcif_plat_data *p = host-pd-dev.platform_data;
- if (ios-power_mode == MMC_POWER_OFF) {
+ if (ios-power_mode == MMC_POWER_UP) {
+ if (p-set_pwr)
+ p-set_pwr(host-pd, ios-power_mode);
+ } else if (ios-power_mode == MMC_POWER_OFF || !ios-clock) {
/* clock stop */
sh_mmcif_clock_control(host, 0);
- if (p-down_pwr)
+ if (ios-power_mode == MMC_POWER_OFF p-down_pwr)
p-down_pwr(host-pd);
return;
- } else if (ios-power_mode == MMC_POWER_UP) {
- if (p-set_pwr)
- p-set_pwr(host-pd, ios-power_mode);
}
if (ios-clock)
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5 0/8] OMAP: HSMMC: hwmod adaptation
Adding hwmod data for hsmmc device on OMAP2430/OMAP3/OMAP4. Adapting the omap_hsmmc driver to hwmod framework. 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 spliting out the mmc device init for omap2420 and takes care of hwmod adaptation for hsmmc drivers. This was already posted at : http://www.mail-archive.com/linux-omap@vger.kernel.org/msg45190.html Also includes renaming of device driver name. The patch series is based on omap-for-linus and tested on OMAP2430, OMAP3430SDP OMAP4430SDP. Also boot tested on OMAP2420SDP. V4: --- http://www.spinics.net/lists/linux-mmc/msg06237.html 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 (2): omap: mmc: split out init for 2420 OMAP4: hwmod data: enable HSMMC Kishore Kadiyala (4): OMAP: hwmod data: Add dev_attr and use in the host driver OMAP: hsmmc: Move mux configuration to hsmmc.c 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-n8x0.c |2 +- 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| 293 ++ arch/arm/mach-omap2/hsmmc.c | 419 +- 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 | 18 +- arch/arm/mach-omap2/prcm-common.h|4 + arch/arm/plat-omap/include/plat/mmc.h| 29 +- drivers/mmc/host/omap_hsmmc.c|6 +- 24 files changed, 753 insertions(+), 479 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 v5 1/8] omap: mmc: split out init for 2420
From: Anand Gadiyar gadi...@ti.com
The MMC controller on the OMAP2420 is different from those
on the OMAP2430, OMAP3 and OMAP4 families - all of the latter
are identical. The one on the OMAP2420 is closer to that
on OMAP1 chips.
Currently, the n8x0 is the only OMAP2420 platform supported
in mainline which registers the MMC controller. Upcoming
changes to register the controllers using hwmod data are
potentially invasive. To reduce the risk, separate out the
2420 controller registration from the common init function
and update its only user. Also seperating out mux settings
for OMAP2420.
Signed-off-by: Anand Gadiyar gadi...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Chris Ball c...@laptop.org
---
arch/arm/mach-omap2/board-n8x0.c |2 +-
arch/arm/mach-omap2/devices.c | 88 +
arch/arm/plat-omap/include/plat/mmc.h |4 ++
3 files changed, 61 insertions(+), 33 deletions(-)
diff --git a/arch/arm/mach-omap2/board-n8x0.c b/arch/arm/mach-omap2/board-n8x0.c
index b36cbd2..e710cd9 100644
--- a/arch/arm/mach-omap2/board-n8x0.c
+++ b/arch/arm/mach-omap2/board-n8x0.c
@@ -536,7 +536,7 @@ static void __init n8x0_mmc_init(void)
}
mmc_data[0] = mmc1_data;
- omap2_init_mmc(mmc_data, OMAP24XX_NR_MMC);
+ omap242x_init_mmc(mmc_data);
}
#else
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 9ee876f..100bb42 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -650,11 +650,10 @@ err1:
static inline void omap_hsmmc_reset(void) {}
#endif
-#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE) || \
- defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
+#if defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE)
-static inline void omap2_mmc_mux(struct omap_mmc_platform_data *mmc_controller,
- int controller_nr)
+static inline void omap242x_mmc_mux(struct omap_mmc_platform_data
+ *mmc_controller)
{
if ((mmc_controller-slots[0].switch_pin 0) \
(mmc_controller-slots[0].switch_pin OMAP_MAX_GPIO_LINES))
@@ -665,33 +664,61 @@ static inline void omap2_mmc_mux(struct
omap_mmc_platform_data *mmc_controller,
omap_mux_init_gpio(mmc_controller-slots[0].gpio_wp,
OMAP_PIN_INPUT_PULLUP);
- if (cpu_is_omap2420() controller_nr == 0) {
- omap_mux_init_signal(sdmmc_cmd, 0);
- omap_mux_init_signal(sdmmc_clki, 0);
- omap_mux_init_signal(sdmmc_clko, 0);
- omap_mux_init_signal(sdmmc_dat0, 0);
- omap_mux_init_signal(sdmmc_dat_dir0, 0);
- omap_mux_init_signal(sdmmc_cmd_dir, 0);
- if (mmc_controller-slots[0].caps MMC_CAP_4_BIT_DATA) {
- omap_mux_init_signal(sdmmc_dat1, 0);
- omap_mux_init_signal(sdmmc_dat2, 0);
- omap_mux_init_signal(sdmmc_dat3, 0);
- omap_mux_init_signal(sdmmc_dat_dir1, 0);
- omap_mux_init_signal(sdmmc_dat_dir2, 0);
- omap_mux_init_signal(sdmmc_dat_dir3, 0);
- }
+ omap_mux_init_signal(sdmmc_cmd, 0);
+ omap_mux_init_signal(sdmmc_clki, 0);
+ omap_mux_init_signal(sdmmc_clko, 0);
+ omap_mux_init_signal(sdmmc_dat0, 0);
+ omap_mux_init_signal(sdmmc_dat_dir0, 0);
+ omap_mux_init_signal(sdmmc_cmd_dir, 0);
+ if (mmc_controller-slots[0].caps MMC_CAP_4_BIT_DATA) {
+ omap_mux_init_signal(sdmmc_dat1, 0);
+ omap_mux_init_signal(sdmmc_dat2, 0);
+ omap_mux_init_signal(sdmmc_dat3, 0);
+ omap_mux_init_signal(sdmmc_dat_dir1, 0);
+ omap_mux_init_signal(sdmmc_dat_dir2, 0);
+ omap_mux_init_signal(sdmmc_dat_dir3, 0);
+ }
- /*
-* Use internal loop-back in MMC/SDIO Module Input Clock
-* selection
-*/
- if (mmc_controller-slots[0].internal_clock) {
- u32 v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
- v |= (1 24);
- omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
- }
+ /*
+* Use internal loop-back in MMC/SDIO Module Input Clock
+* selection
+*/
+ if (mmc_controller-slots[0].internal_clock) {
+ u32 v = omap_ctrl_readl(OMAP2_CONTROL_DEVCONF0);
+ v |= (1 24);
+ omap_ctrl_writel(v, OMAP2_CONTROL_DEVCONF0);
+ }
+}
+
+void __init omap242x_init_mmc(struct omap_mmc_platform_data **mmc_data)
+{
+ char *name = mmci-omap;
+
+ if (!mmc_data[0]) {
+ pr_err(%s fails: Incomplete platform
[PATCH v5 8/8] 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
Acked-by: Benoit Coussonb-cous...@ti.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 regulator_init_data igep2_vmmc2 = {
.constraints= {
diff --git a/arch/arm/mach-omap2/board-igep0030.c
[PATCH v5 4/8] 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 v5 6/8] OMAP: hsmmc: Move mux configuration to hsmmc.c
Moving the definition of mux setting API from devices.c to hsmmc.c
and renaming it from omap2_mmc_mux to omap_hsmmc_mux.
Also calling omap_hsmmc_mux from omap2_hsmmc_init.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Chris Ball c...@laptop.org
Cc: Tony Lindgren t...@atomide.com
---
arch/arm/mach-omap2/devices.c | 83
arch/arm/mach-omap2/hsmmc.c | 84 +
2 files changed, 84 insertions(+), 83 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 100bb42..2f4a598 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -708,87 +708,6 @@ void __init omap242x_init_mmc(struct
omap_mmc_platform_data **mmc_data)
#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,
- 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 files
-*/
- if (mmc_controller-slots[0].caps
- (MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA)) {
- omap_mux_init_signal(sdmmc2_dat1,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(sdmmc2_dat2,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(sdmmc2_dat3,
- OMAP_PIN_INPUT_PULLUP);
- }
- if (mmc_controller-slots[0].caps
- MMC_CAP_8_BIT_DATA) {
- omap_mux_init_signal(sdmmc2_dat4.sdmmc2_dat4,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(sdmmc2_dat5.sdmmc2_dat5,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(sdmmc2_dat6.sdmmc2_dat6,
- OMAP_PIN_INPUT_PULLUP);
- omap_mux_init_signal(sdmmc2_dat7.sdmmc2_dat7,
-
[PATCH v5 7/8] OMAP: adapt hsmmc to hwmod framework
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
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 | 168
arch/arm/mach-omap2/hsmmc.c | 343 ++--
arch/arm/plat-omap/include/plat/mmc.h | 20 +--
drivers/mmc/host/omap_hsmmc.c |4 +-
4 files changed, 196 insertions(+), 339 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2f4a598..31632ac 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -544,112 +544,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
@@ -706,67 +600,6 @@ void __init omap242x_init_mmc(struct
[PATCH v5 2/8] 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..a1c3c5e 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 omap2430_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 omap2430_mmc_class = {
+ .name = mmc,
+ .sysc = omap2430_mmc_sysc,
+};
+
+/* MMC/SD/SDIO1 */
+
+static struct omap_hwmod_irq_info omap2430_mmc1_mpu_irqs[] = {
+ { .irq = 83 },
+};
+
+static struct omap_hwmod_dma_info omap2430_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 omap2430_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 = omap2430_mmc1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_mmc1_mpu_irqs),
+ .sdma_reqs = omap2430_mmc1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2430_mmc1_sdma_reqs),
+ .opt_clks = omap2430_mmc1_opt_clks,
+ .opt_clks_cnt = ARRAY_SIZE(omap2430_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,
[PATCH v5 3/8] 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..7726932 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 omap34xx_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 omap34xx_mmc_class = {
+ .name = mmc,
+ .sysc = omap34xx_mmc_sysc,
+};
+
+/* MMC/SD/SDIO1 */
+
+static struct omap_hwmod_irq_info omap34xx_mmc1_mpu_irqs[] = {
+ { .irq = 83, },
+};
+
+static struct omap_hwmod_dma_info omap34xx_mmc1_sdma_reqs[] = {
+ { .name = tx, .dma_req = 61, },
+ { .name = rx, .dma_req = 62, },
+};
+
+static struct omap_hwmod_opt_clk omap34xx_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 = omap34xx_mmc1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap34xx_mmc1_mpu_irqs),
+ .sdma_reqs = omap34xx_mmc1_sdma_reqs,
+
Re: [PATCH] mmc: sh_mmcif: support aggressive clock gating
Hi Guennadi,
On Fri, Feb 25, 2011 at 04:58:38PM +0100, Guennadi Liakhovetski wrote:
To support MMC aggressive clock gating the driver has to stop the interface
clock, when the .set_ios() method is called with .clock == 0.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Tested on ap4evb and ecovec
drivers/mmc/host/sh_mmcif.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/sh_mmcif.c b/drivers/mmc/host/sh_mmcif.c
index 12884c2..3d735da 100644
--- a/drivers/mmc/host/sh_mmcif.c
+++ b/drivers/mmc/host/sh_mmcif.c
@@ -850,15 +850,15 @@ static void sh_mmcif_set_ios(struct mmc_host *mmc,
struct mmc_ios *ios)
struct sh_mmcif_host *host = mmc_priv(mmc);
struct sh_mmcif_plat_data *p = host-pd-dev.platform_data;
- if (ios-power_mode == MMC_POWER_OFF) {
+ if (ios-power_mode == MMC_POWER_UP) {
+ if (p-set_pwr)
+ p-set_pwr(host-pd, ios-power_mode);
+ } else if (ios-power_mode == MMC_POWER_OFF || !ios-clock) {
/* clock stop */
sh_mmcif_clock_control(host, 0);
- if (p-down_pwr)
+ if (ios-power_mode == MMC_POWER_OFF p-down_pwr)
p-down_pwr(host-pd);
return;
- } else if (ios-power_mode == MMC_POWER_UP) {
- if (p-set_pwr)
- p-set_pwr(host-pd, ios-power_mode);
}
if (ios-clock)
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: [RFC] dw_mmc: didn't support multiple blocks of weird length?
On Fri, Feb 25, 2011 at 7:35 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: Hi.. I didn't understand this point.. Plz let me explain this code.. why need this function (dw_mci_queue_request(host, slot, mrq)? I don't think there would be any problem merging those two functions. Also I would be happy to see the comment deleted, it doesn't really make sense. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] dw_mmc: support mmc power control with regulator
On Fri, Feb 25, 2011 at 2:08 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: 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(-) This looks ok from an mmc point of view. I'm not that familiar with the regulator API however, so it would be good to get a review from someone who is. Acked-by: Will Newton will.new...@imgtec.com -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sdhci: always use max timeout for xfers
Hi Philip,
On Fri, Feb 25, 2011 at 09:54:35AM -0800, Philip Rakity wrote:
Rather then special case busy etc .. lets just use the max value.
OK.
Did not remove BROKEN_TIMEOUT QUIRK so existing code will compile
we can remove this once existing platform drivers delete usage and get
quirk back.
If we wait for that, we'll probably wait till eternity ;) I'd vote that
removing the quirk should be part of the patch.
Patch starts after
=
The usual nomenclature is that such comments simply go between '---' and the
diffstat. Most tools are prepared for this...
The card/host controller may sometimes return a value that is
too low and cause the h/w to timeout a transfer that would have
worked. Using the maximum value avoids this.
Signed-off-by: Philip Rakity prak...@marvell.com
---
... to handle them here.
drivers/mmc/host/sdhci.c | 48 -
1 files changed, 5 insertions(+), 43 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 655617c..dd99da8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -592,53 +592,15 @@ static void sdhci_adma_table_post(struct sdhci_host
*host,
data-sg_len, direction);
}
-static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_data *data)
+static inline u8 sdhci_calc_timeout(void)
{
- u8 count;
- unsigned target_timeout, current_timeout;
-
/*
- * If the host controller provides us with an incorrect timeout
- * value, just skip the check and use 0xE. The hardware may take
+ * The host controller/card can provide us with an incorrect timeout
+ * value, just use the maximum value 0xE. The hardware may take
* longer to time out, but that's much better than having a too-short
* timeout value.
*/
- if (host-quirks SDHCI_QUIRK_BROKEN_TIMEOUT_VAL)
- return 0xE;
-
- /* timeout in us */
- target_timeout = data-timeout_ns / 1000 +
- data-timeout_clks / host-clock;
-
- if (host-quirks SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK)
- host-timeout_clk = host-clock / 1000;
This quirk could go then as well?
-
- /*
- * Figure out needed cycles.
- * We do this in steps in order to fit inside a 32 bit int.
- * The first step is the minimum timeout, which will have a
- * minimum resolution of 6 bits:
- * (1) 2^13*1000 2^22,
- * (2) host-timeout_clk 2^16
- * =
- * (1) / (2) 2^6
- */
- count = 0;
- current_timeout = (1 13) * 1000 / host-timeout_clk;
- while (current_timeout target_timeout) {
- count++;
- current_timeout = 1;
- if (count = 0xF)
- break;
- }
-
- if (count = 0xF) {
- printk(KERN_WARNING %s: Too large timeout requested!\n,
- mmc_hostname(host-mmc));
- count = 0xE;
- }
-
- return count;
+ return 0xE;
Why don't you remove the function entirely?
}
static void sdhci_set_transfer_irqs(struct sdhci_host *host)
@@ -671,7 +633,7 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_data *data)
host-data = data;
host-data_early = 0;
- count = sdhci_calc_timeout(host, data);
+ count = sdhci_calc_timeout();
sdhci_writeb(host, count, SDHCI_TIMEOUT_CONTROL);
if (host-flags (SDHCI_USE_SDMA | SDHCI_USE_ADMA))
Thanks,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH] sdhci: always use max timeout for xfers
On Feb 25, 2011, at 10:02 AM, Wolfram Sang wrote:
Hi Philip,
On Fri, Feb 25, 2011 at 09:54:35AM -0800, Philip Rakity wrote:
Rather then special case busy etc .. lets just use the max value.
OK.
Did not remove BROKEN_TIMEOUT QUIRK so existing code will compile
we can remove this once existing platform drivers delete usage and get
quirk back.
If we wait for that, we'll probably wait till eternity ;) I'd vote that
removing the quirk should be part of the patch.
I concur (see below)
Patch starts after
=
The usual nomenclature is that such comments simply go between '---' and the
diffstat. Most tools are prepared for this...
The card/host controller may sometimes return a value that is
too low and cause the h/w to timeout a transfer that would have
worked. Using the maximum value avoids this.
Signed-off-by: Philip Rakity prak...@marvell.com
---
... to handle them here.
drivers/mmc/host/sdhci.c | 48 -
1 files changed, 5 insertions(+), 43 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 655617c..dd99da8 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -592,53 +592,15 @@ static void sdhci_adma_table_post(struct sdhci_host
*host,
data-sg_len, direction);
}
-static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_data *data)
+static inline u8 sdhci_calc_timeout(void)
{
-u8 count;
-unsigned target_timeout, current_timeout;
-
/*
- * If the host controller provides us with an incorrect timeout
- * value, just skip the check and use 0xE. The hardware may take
+ * The host controller/card can provide us with an incorrect timeout
+ * value, just use the maximum value 0xE. The hardware may take
* longer to time out, but that's much better than having a too-short
* timeout value.
*/
-if (host-quirks SDHCI_QUIRK_BROKEN_TIMEOUT_VAL)
-return 0xE;
-
-/* timeout in us */
-target_timeout = data-timeout_ns / 1000 +
-data-timeout_clks / host-clock;
-
-if (host-quirks SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK)
-host-timeout_clk = host-clock / 1000;
This quirk could go then as well?
I am all for that -- did not want to touch other drivers but will remove for
sdhci-pxa if
patch is okay.
-
-/*
- * Figure out needed cycles.
- * We do this in steps in order to fit inside a 32 bit int.
- * The first step is the minimum timeout, which will have a
- * minimum resolution of 6 bits:
- * (1) 2^13*1000 2^22,
- * (2) host-timeout_clk 2^16
- * =
- * (1) / (2) 2^6
- */
-count = 0;
-current_timeout = (1 13) * 1000 / host-timeout_clk;
-while (current_timeout target_timeout) {
-count++;
-current_timeout = 1;
-if (count = 0xF)
-break;
-}
-
-if (count = 0xF) {
-printk(KERN_WARNING %s: Too large timeout requested!\n,
-mmc_hostname(host-mmc));
-count = 0xE;
-}
-
-return count;
+return 0xE;
Why don't you remove the function entirely?
better to rename it --- to set_maximum_timeout since a little clearer.
left the old name for historical reasons -- if no need I will change it
}
static void sdhci_set_transfer_irqs(struct sdhci_host *host)
@@ -671,7 +633,7 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_data *data)
host-data = data;
host-data_early = 0;
-count = sdhci_calc_timeout(host, data);
+count = sdhci_calc_timeout();
sdhci_writeb(host, count, SDHCI_TIMEOUT_CONTROL);
if (host-flags (SDHCI_USE_SDMA | SDHCI_USE_ADMA))
Thanks,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] sdhci: always use max timeout for xfers
- return count; + return 0xE; Why don't you remove the function entirely? better to rename it --- to set_maximum_timeout since a little clearer. left the old name for historical reasons -- if no need I will change it I'd suggest... } static void sdhci_set_transfer_irqs(struct sdhci_host *host) @@ -671,7 +633,7 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data) host-data = data; host-data_early = 0; - count = sdhci_calc_timeout(host, data); + count = sdhci_calc_timeout(); sdhci_writeb(host, count, SDHCI_TIMEOUT_CONTROL); using SDHCI_TIMEOUT_MAX here instead of count with a proper define in sdhci.h. -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
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 --- Hi Wolfram, What about changing return 0 into return err? It gets checked in cb710_mmc_powerup(). Thanks, good idea. - Chris. drivers/mmc/host/cb710-mmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/cb710-mmc.c b/drivers/mmc/host/cb710-mmc.c index 66b4ce5..ce2a47b 100644 --- a/drivers/mmc/host/cb710-mmc.c +++ b/drivers/mmc/host/cb710-mmc.c @@ -205,7 +205,7 @@ static int cb710_wait_while_busy(struct cb710_slot *slot, uint8_t mask) WAIT12: waited %d loops, mask %02X, entry val %08X, exit val %08X\n, limit, mask, e, x); #endif - return 0; + return err; } static void cb710_mmc_set_transfer_size(struct cb710_slot *slot, This patch is good. This part is not completely demystified though, and some parts of the code don't care about this function's return value. Acked-by: Michał Mirosław mirq-li...@rere.qmqm.pl -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] sdhci: always use max timeout for xfers
v2
use define for max timeout. remove subroutine call and just
set the register directly
v1
The card/host controller may sometimes return a value that is
too low and cause the h/w to timeout a transfer that would have
worked. Using the maximum value avoids this.
Signed-off-by: Philip Rakity prak...@marvell.com
---
drivers/mmc/host/sdhci.c | 59 +
drivers/mmc/host/sdhci.h |1 +
2 files changed, 8 insertions(+), 52 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 655617c..d615173 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -592,55 +592,6 @@ static void sdhci_adma_table_post(struct sdhci_host *host,
data-sg_len, direction);
}
-static u8 sdhci_calc_timeout(struct sdhci_host *host, struct mmc_data *data)
-{
- u8 count;
- unsigned target_timeout, current_timeout;
-
- /*
-* If the host controller provides us with an incorrect timeout
-* value, just skip the check and use 0xE. The hardware may take
-* longer to time out, but that's much better than having a too-short
-* timeout value.
-*/
- if (host-quirks SDHCI_QUIRK_BROKEN_TIMEOUT_VAL)
- return 0xE;
-
- /* timeout in us */
- target_timeout = data-timeout_ns / 1000 +
- data-timeout_clks / host-clock;
-
- if (host-quirks SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK)
- host-timeout_clk = host-clock / 1000;
-
- /*
-* Figure out needed cycles.
-* We do this in steps in order to fit inside a 32 bit int.
-* The first step is the minimum timeout, which will have a
-* minimum resolution of 6 bits:
-* (1) 2^13*1000 2^22,
-* (2) host-timeout_clk 2^16
-* =
-* (1) / (2) 2^6
-*/
- count = 0;
- current_timeout = (1 13) * 1000 / host-timeout_clk;
- while (current_timeout target_timeout) {
- count++;
- current_timeout = 1;
- if (count = 0xF)
- break;
- }
-
- if (count = 0xF) {
- printk(KERN_WARNING %s: Too large timeout requested!\n,
- mmc_hostname(host-mmc));
- count = 0xE;
- }
-
- return count;
-}
-
static void sdhci_set_transfer_irqs(struct sdhci_host *host)
{
u32 pio_irqs = SDHCI_INT_DATA_AVAIL | SDHCI_INT_SPACE_AVAIL;
@@ -654,7 +605,6 @@ static void sdhci_set_transfer_irqs(struct sdhci_host *host)
static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
{
- u8 count;
u8 ctrl;
int ret;
@@ -671,8 +621,13 @@ static void sdhci_prepare_data(struct sdhci_host *host,
struct mmc_data *data)
host-data = data;
host-data_early = 0;
- count = sdhci_calc_timeout(host, data);
- sdhci_writeb(host, count, SDHCI_TIMEOUT_CONTROL);
+ /*
+* The host controller/card can provide us with an incorrect timeout
+* value, just use the maximum value 0xE. The hardware may take
+* longer to time out, but that's much better than having a too-short
+* timeout value.
+*/
+ sdhci_writeb(host, SDHCI_TIMEOUT_MAX, SDHCI_TIMEOUT_CONTROL);
if (host-flags (SDHCI_USE_SDMA | SDHCI_USE_ADMA))
host-flags |= SDHCI_REQ_USE_DMA;
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 1f032c0..19b4d41 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -103,6 +103,7 @@
#define SDHCI_CLOCK_INT_EN0x0001
#define SDHCI_TIMEOUT_CONTROL 0x2E
+#define SDHCI_TIMEOUT_MAX 0xE
#define SDHCI_SOFTWARE_RESET 0x2F
#define SDHCI_RESET_ALL 0x01
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 2/3] sdhci-pci : Enable runtime PM support
On Friday, February 25, 2011, Matthew Garrett wrote: On Fri, Feb 25, 2011 at 07:33:12AM +, Tardy, Pierre wrote: 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. The core can only enable PME generation, it can't configure what generates PMEs. There's a register in sdhci that needs to be programmed to enable wakeups on card insert/removal/interrupt. If you don't then you won't get a PME no matter what the core does. That's correct. The driver shoulnd't touch the generic-PCI part of wakeup preparation, but it _should_ configure the device-specific part of it. It's quite similar to network adapters where you have to configure the adapter to react to magic packets, for example, in addition to the PCI PME setup done by the core. Thanks, Rafael -- 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
Eric Benard e...@eukrea.com writes: Hi Arnaud, Salut ! 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. I've tested this patch on my efikamx and this patch does solve the issue. I didn't test on the efika smartbook but I guess it'll be fine here too. Thanks. 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, so, we're getting an interrupt storm, right ? can't it be fixed by setting a different irq type ? - 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), It worked without changing this. 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 V2] sdhci: always use max timeout for xfers
On Fri, Feb 25, 2011 at 10:49:25AM -0800, Philip Rakity wrote: v2 use define for max timeout. remove subroutine call and just set the register directly The generic description goes above the --- line, the incremental history of the patch usually below. v1 The card/host controller may sometimes return a value that is too low and cause the h/w to timeout a transfer that would have worked. Using the maximum value avoids this. Signed-off-by: Philip Rakity prak...@marvell.com What is there seems ok, but it is not enough yet. The quirks can also go from the users. After that, it gets even more complicated; after this patch 'host-timeout_clk' becomes obsolete which should probably cleaned up in a later patch together with host-ops-get_timeout_clk. H, that needs careful auditing. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH v2 5/5] mmc: sdhci-esdhc: enable esdhc on imx53
On Tue, Feb 22, 2011 at 06:13:26PM +0800, Richard Zhu wrote:
Fix the NO INT in the Multi-BLK IO in SD/MMC, and
Multi-BLK read in SDIO
This description is too short. Why does it not work before, and why does
this patch help?
Signed-off-by: Richard Zhu hong-xing@freescale.com
---
drivers/mmc/host/sdhci-esdhc-imx.c | 41
+++-
drivers/mmc/host/sdhci-esdhc.h |5
2 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 9b82910..a09f786 100644
--- a/drivers/mmc/host/sdhci-esdhc-imx.c
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -17,6 +17,8 @@
#include linux/clk.h
#include linux/mmc/host.h
#include linux/mmc/sdhci-pltfm.h
+#include linux/mmc/mmc.h
+#include linux/mmc/sdio.h
#include mach/hardware.h
#include sdhci.h
#include sdhci-pltfm.h
@@ -38,6 +40,27 @@ static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
return readw(host-ioaddr + reg);
}
+static void esdhc_writel_le(struct sdhci_host *host, u32 val, int reg)
+{
+ switch (reg) {
+ case SDHCI_INT_STATUS:
+ /*
+ * Fix no INT bug in SDIO MULTI-BLK read
+ * clear bit1 of Vendor Spec registor after TC
+ */
Same for this comment. Make it more descriptive, please
+ if (val SDHCI_INT_DATA_END) {
+ u32 v;
+ v = readl(host-ioaddr + SDHCI_VENDOR_SPEC);
+ if (v 0x2) {
+ v = (~0x2);
Braces not needed.
+ writel(v, host-ioaddr + SDHCI_VENDOR_SPEC);
+ }
Can't you clear it unconditionally?
+ }
+ break;
+ }
+ writel(val, host-ioaddr + reg);
+}
+
static void esdhc_writew_le(struct sdhci_host *host, u16 val, int reg)
{
struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
@@ -45,12 +68,27 @@ static void esdhc_writew_le(struct sdhci_host *host, u16
val, int reg)
switch (reg) {
case SDHCI_TRANSFER_MODE:
/*
+ * Fix no INT bug in SDIO MULTI-BLK read
+ * set bit1 of Vendor Spec registor
+ */
+ if ((host-cmd-opcode == SD_IO_RW_EXTENDED)
+ (host-cmd-data-blocks 1)
+ (host-cmd-data-flags MMC_DATA_READ)) {
+ u32 v;
+ v = readl(host-ioaddr + SDHCI_VENDOR_SPEC);
+ v |= 0x2;
+ writel(v, host-ioaddr + SDHCI_VENDOR_SPEC);
+ }
+ /*
* Postpone this write, we must do it together with a
* command write that is down below.
*/
pltfm_host-scratchpad = val;
return;
case SDHCI_COMMAND:
+ /*Set the CMD_TYPE of the CMD12, fix no INT in MULTI_BLK IO */
+ if (host-cmd-opcode == MMC_STOP_TRANSMISSION)
+ val |= SDHCI_CMD_ABORTCMD;
Can't we handle it the same way than the SDIO case? I have to admit,
even after reading the docs, I don't fully get what this bit1 is about.
writel(val 16 | pltfm_host-scratchpad,
host-ioaddr + SDHCI_TRANSFER_MODE);
return;
@@ -113,7 +151,7 @@ static int esdhc_pltfm_init(struct sdhci_host *host,
struct sdhci_pltfm_data *pd
clk_enable(clk);
pltfm_host-clk = clk;
- if (cpu_is_mx35() || cpu_is_mx51())
+ if (!cpu_is_mx25())
host-quirks |= SDHCI_QUIRK_BROKEN_TIMEOUT_VAL;
/* Fix errata ENGcm07207 which is present on i.MX25 and i.MX35 */
@@ -133,6 +171,7 @@ static void esdhc_pltfm_exit(struct sdhci_host *host)
static struct sdhci_ops sdhci_esdhc_ops = {
.read_w = esdhc_readw_le,
+ .write_l = esdhc_writel_le,
You are applying it for all imx-versions?
.write_w = esdhc_writew_le,
.write_b = esdhc_writeb_le,
.set_clock = esdhc_set_clock,
diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
index 303cde0..c93168c 100644
--- a/drivers/mmc/host/sdhci-esdhc.h
+++ b/drivers/mmc/host/sdhci-esdhc.h
@@ -43,6 +43,11 @@
#define ESDHC_HOST_CONTROL_RES 0x05
+/* Abort type definition in the command register */
+#define SDHCI_CMD_ABORTCMD 0xC0
So, this is vendor-specific, too?
+/* VENDOR SPEC register */
+#define SDHCI_VENDOR_SPEC0xC0
+
static inline void esdhc_set_clock(struct sdhci_host *host, unsigned int
clock)
{
int pre_div = 2;
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/ |
signature.asc
Description: Digital signature
Re: [PATCH v5 7/8] OMAP: adapt hsmmc to hwmod framework
* Kishore Kadiyala kishore.kadiy...@ti.com [110225 09:00]: +static int omap_mmc_init(struct omap_hwmod *oh, void *hsmmcinfo) ... + static int mmc_num; + + c += mmc_num; This does not look right.. 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 v5 7/8] OMAP: adapt hsmmc to hwmod framework
* Tony Lindgren t...@atomide.com [110225 12:42]: * Kishore Kadiyala kishore.kadiy...@ti.com [110225 09:00]: +static int omap_mmc_init(struct omap_hwmod *oh, void *hsmmcinfo) ... + static int mmc_num; + + c += mmc_num; This does not look right.. So since mmc_num is static, it gets initialized to 0, then increased for each call.. What if you want to intialize controller 1 and 3 but not 2? Also, why do you pass void *hsmmcinfo to the function and then cast it to struct omap2_hsmmc_inf *? Why not pass struct omap2_hsmmc_info * to start with? Regards, 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 V3 0/5] sdhci-esdhc-imx: use gpio for write protection and card detection
Hi, On 25/02/2011 20:31, Arnaud Patard (Rtp) wrote: Eric Benarde...@eukrea.com writes: 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. I've tested this patch on my efikamx and this patch does solve the issue. I didn't test on the efika smartbook but I guess it'll be fine here too. Thanks. good. Now we have to find can how this code be integrated properly in the sdhci driver. 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, so, we're getting an interrupt storm, right ? can't it be fixed by setting a different irq type ? no this seems to be the way the SDHCI works, at least the i.MX51 ref manual says : - When the CRM bit is cleared, if no card is inserted it is immediately set again: this can be prevented by clearing the card removal status enable bit in interrupt status enable register. - When the CIN bit is cleared, if a card is inserted it is immediately set again: this can be prevented by clearing the card inserted status enable bit in interrupt status enable register. As, unless I'm mistaken, sdhci host actually consider card detect as broken by default, I think this code in not actually used so it may not be really tested. - 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), It worked without changing this. this could mean you have an external pull up resistor on the board which was not the case on the prototype I was working on which is partially mounted ;-) Eric -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 2/8] OMAP2430: hwmod data: Add HSMMC
Hello Kishore,
There are several problems with this data that generate warning messages
on boot on 2430SDP.
Did you actually test this on 2430SDP? The warning messages would have
been obvious in the boot log.
Comments below:
On Fri, 25 Feb 2011, Kishore Kadiyala wrote:
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..a1c3c5e 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 omap2430_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 omap2430_mmc_class = {
+ .name = mmc,
+ .sysc = omap2430_mmc_sysc,
+};
+
+/* MMC/SD/SDIO1 */
+
+static struct omap_hwmod_irq_info omap2430_mmc1_mpu_irqs[] = {
+ { .irq = 83 },
+};
+
+static struct omap_hwmod_dma_info omap2430_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 omap2430_mmc1_opt_clks[] = {
+ { .role = dbck, .clk = mmchsdb_fck },
This is not the correct name of the clock. This generates warnings on
boot and prevents the HSMMC block from being soft-reset.
+};
+
+static struct omap_hwmod_ocp_if *omap2430_mmc1_slaves[] = {
+ omap2430_l4_core__mmc1,
+};
+
+static struct omap_hwmod omap2430_mmc1_hwmod = {
+ .name = mmc1,
+ .mpu_irqs = omap2430_mmc1_mpu_irqs,
+ .mpu_irqs_cnt = ARRAY_SIZE(omap2430_mmc1_mpu_irqs),
+ .sdma_reqs = omap2430_mmc1_sdma_reqs,
+ .sdma_reqs_cnt = ARRAY_SIZE(omap2430_mmc1_sdma_reqs),
+ .opt_clks =
Re: [PATCH] MMC: omap_hsmmc: enable interface clock before calling mmc_host_enable()
Hi Chris,
would you like to take this one, or should we merge it through the OMAP
tree?
- Paul
From: Paul Walmsley p...@pwsan.com
Date: Fri, 25 Feb 2011 18:22:08 -0700
Subject: [PATCH] MMC: omap_hsmmc: enable interface clock before calling
mmc_host_enable()
The code path entered via mmc_host_enable() can include register
accesses to the HSMMC IP block. For this to work, both the device
interface clock and functional clock need to be enabled before
mmc_host_enable() is called. However, omap_hsmmc_probe() calls
mmc_host_enable() before enabling the device interface clock.
Fix by calling mmc_host_enable() after the device interface clock is
enabled.
Signed-off-by: Paul Walmsley p...@pwsan.com
Cc: Madhusudhan Chikkature Rajashekar madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Tero Kristo tero.kri...@nokia.com
Acked-by: Madhusudhan Chikkature Rajashekar madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 078fdf1..0cf0d89 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2101,14 +2101,14 @@ static int __init omap_hsmmc_probe(struct
platform_device *pdev)
/* we start off in DISABLED state */
host-dpm_state = DISABLED;
- if (mmc_host_enable(host-mmc) != 0) {
+ if (clk_enable(host-iclk) != 0) {
clk_put(host-iclk);
clk_put(host-fclk);
goto err1;
}
- if (clk_enable(host-iclk) != 0) {
- mmc_host_disable(host-mmc);
+ if (mmc_host_enable(host-mmc) != 0) {
+ clk_disable(host-iclk);
clk_put(host-iclk);
clk_put(host-fclk);
goto err1;
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MMC: omap_hsmmc: enable interface clock before calling mmc_host_enable()
Hi Paul, On Fri, Feb 25, 2011 at 06:26:45PM -0700, Paul Walmsley wrote: Hi Chris, would you like to take this one, or should we merge it through the OMAP tree? Thanks for asking -- OMAP folks seem to like merging patches to host/*omap* directly through the OMAP tree, and that's fine with me; I don't want to get in the way of a good workflow with responsive maintainers. I do like the patches to be CC'd to linux-mmc@ (this one was, thanks), and I read them and will yell if something looks bogus to me. - Chris. -- 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] MMC: omap_hsmmc: enable interface clock before calling mmc_host_enable()
Hi Chris, On Sat, 26 Feb 2011, Chris Ball wrote: Thanks for asking -- OMAP folks seem to like merging patches to host/*omap* directly through the OMAP tree, and that's fine with me; I don't want to get in the way of a good workflow with responsive maintainers. I do like the patches to be CC'd to linux-mmc@ (this one was, thanks), and I read them and will yell if something looks bogus to me. thanks, will queue it here. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V2] arm: mach-mmp: brownstone.c support multiple sd slots
Support multiple sd/eMMC interfaces. enable mmc1, 2, and 3.
mmc2 is used eMMC and slot is marked PERMANENT and 8 bit device.
mmc1 is used for Wifi and slot is marked PERMANENT
Note: eMMC (mmc2) is set to initialize first to workaround a problem
where booting in logical order requires mmc create work queue
to be multi-threaded otherwise boot process hangs. BUG report
send to linux-mmc and linux-kernel mailing list.
Wifi (mmc1) requires we enable power on the device by toggling
the gpio lines for power and reset.
Signed-off-by: Philip Rakity prak...@marvell.com
---
arch/arm/mach-mmp/brownstone.c | 42
1 files changed, 42 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-mmp/brownstone.c b/arch/arm/mach-mmp/brownstone.c
index 7bb78fd..36d5b82 100644
--- a/arch/arm/mach-mmp/brownstone.c
+++ b/arch/arm/mach-mmp/brownstone.c
@@ -19,6 +19,7 @@
#include linux/regulator/max8649.h
#include linux/regulator/fixed.h
#include linux/mfd/max8925.h
+#include linux/delay.h
#include asm/mach-types.h
#include asm/mach/arch.h
@@ -180,6 +181,45 @@ static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc0 = {
.max_speed = 2500,
};
+static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc1 = {
+ .flags = PXA_FLAG_CARD_PERMANENT,
+};
+
+static struct sdhci_pxa_platdata mmp2_sdh_platdata_mmc2 = {
+ .flags = PXA_FLAG_CARD_PERMANENT |
+ PXA_FLAG_SD_8_BIT_CAPABLE_SLOT,
+};
+
+static void __init mmc_sdio_wifi(void)
+{
+ int poweron;
+ int reset;
+
+ poweron = mfp_to_gpio(GPIO57_GPIO);
+ reset = mfp_to_gpio(GPIO58_GPIO);
+
+ if(gpio_request(reset, sd8xxx reset)) {
+ printk(KERN_INFO gpio %d request failed\n, reset);
+ return;
+ }
+
+ if(gpio_request(poweron, sd8xxx PDn)) {
+ gpio_free(reset);
+ printk(KERN_INFO gpio %d request failed\n, poweron);
+ return;
+ }
+
+ gpio_direction_output(poweron, 1);
+ msleep (1);
+ gpio_direction_output(reset, 0);
+ msleep (1);
+ gpio_direction_output(reset, 1);
+ gpio_free(reset);
+ gpio_free(poweron);
+
+ mmp2_add_sdhost(1, mmp2_sdh_platdata_mmc1); /* Wifi */
+}
+
static void __init brownstone_init(void)
{
mfp_config(ARRAY_AND_SIZE(brownstone_pin_config));
@@ -188,7 +228,9 @@ static void __init brownstone_init(void)
mmp2_add_uart(1);
mmp2_add_uart(3);
mmp2_add_twsi(1, NULL, ARRAY_AND_SIZE(brownstone_twsi1_info));
+ mmp2_add_sdhost(2, mmp2_sdh_platdata_mmc2); /* eMMC */
mmp2_add_sdhost(0, mmp2_sdh_platdata_mmc0); /* SD/MMC */
+ mmc_sdio_wifi();
/* enable 5v regulator */
platform_device_register(brownstone_v_5vp_device);
--
1.7.0.4--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
