[PATCH] ARM: OMAP3 PM:Save and restore EMU context across MPU OFF
EMU domain is part of MPU subsystem, save and restore CM_CLKSTCTRL of
EMU domain across MPU OFF instead of CORE OFF. Though CM belongs to CORE
power domain, this register is of cold reset type and gets reset upon
MPU domain wakeup from OFF.
Embedded trace debug tools like Serial Trace Interface(sti) using
EMU domain loses connection across MPU OFF. The patch fixes this issue
Signed-off-by: Madhusudhan Gowda madhusudhan.go...@elektrobit.com
---
arch/arm/mach-omap2/cm2xxx_3xxx.c | 16
arch/arm/mach-omap2/cm2xxx_3xxx.h |2 ++
arch/arm/mach-omap2/pm34xx.c |8
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.c
b/arch/arm/mach-omap2/cm2xxx_3xxx.c
index 04d39cd..4f98e17 100644
--- a/arch/arm/mach-omap2/cm2xxx_3xxx.c
+++ b/arch/arm/mach-omap2/cm2xxx_3xxx.c
@@ -301,6 +301,18 @@ struct omap3_cm_regs {
static struct omap3_cm_regs cm_context;
+void omap3_emu_save_context(void)
+{
+ cm_context.emu_cm_clkstctrl =
+ omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, OMAP2_CM_CLKSTCTRL);
+}
+
+void omap3_emu_restore_context(void)
+{
+ omap2_cm_write_mod_reg(cm_context.emu_cm_clkstctrl, OMAP3430_EMU_MOD,
+ OMAP2_CM_CLKSTCTRL);
+}
+
void omap3_cm_save_context(void)
{
cm_context.iva2_cm_clksel1 =
@@ -318,8 +330,6 @@ void omap3_cm_save_context(void)
omap2_cm_read_mod_reg(OMAP3430_PER_MOD, CM_CLKSEL);
cm_context.emu_cm_clksel =
omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, CM_CLKSEL1);
- cm_context.emu_cm_clkstctrl =
- omap2_cm_read_mod_reg(OMAP3430_EMU_MOD, OMAP2_CM_CLKSTCTRL);
/*
* As per erratum i671, ROM code does not respect the PER DPLL
* programming scheme if CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL == 1.
@@ -449,8 +459,6 @@ void omap3_cm_restore_context(void)
CM_CLKSEL);
omap2_cm_write_mod_reg(cm_context.emu_cm_clksel, OMAP3430_EMU_MOD,
CM_CLKSEL1);
- omap2_cm_write_mod_reg(cm_context.emu_cm_clkstctrl, OMAP3430_EMU_MOD,
- OMAP2_CM_CLKSTCTRL);
/*
* As per erratum i671, ROM code does not respect the PER DPLL
* programming scheme if CM_AUTOIDLE_PLL.AUTO_PERIPH_DPLL == 1.
diff --git a/arch/arm/mach-omap2/cm2xxx_3xxx.h
b/arch/arm/mach-omap2/cm2xxx_3xxx.h
index 088bbad..ffb0195 100644
--- a/arch/arm/mach-omap2/cm2xxx_3xxx.h
+++ b/arch/arm/mach-omap2/cm2xxx_3xxx.h
@@ -150,6 +150,8 @@ extern void
omap2xxx_cm_set_apll96_auto_low_power_stop(void);
# ifndef __ASSEMBLER__
extern void omap3_cm_save_context(void);
extern void omap3_cm_restore_context(void);
+extern void omap3_emu_save_context(void);
+extern void omap3_emu_restore_context(void);
# endif
#endif
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index fc69875..b05dc02 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -315,6 +315,10 @@ void omap_sram_idle(void)
if (pwrdm_read_pwrst(neon_pwrdm) == PWRDM_POWER_ON)
pwrdm_set_next_pwrst(neon_pwrdm, mpu_next_state);
+ /* EMU */
+ if (mpu_next_state == PWRDM_POWER_OFF)
+ omap3_emu_save_context();
+
/* Enable IO-PAD and IO-CHAIN wakeups */
per_next_state = pwrdm_read_next_pwrst(per_pwrdm);
core_next_state = pwrdm_read_next_pwrst(core_pwrdm);
@@ -377,6 +381,10 @@ void omap_sram_idle(void)
core_next_state == PWRDM_POWER_OFF)
sdrc_write_reg(sdrc_pwr, SDRC_POWER);
+ /* EMU */
+ if (pwrdm_read_prev_pwrst(mpu_pwrdm) == PWRDM_POWER_OFF)
+ omap3_emu_restore_context();
+
/* CORE */
if (core_next_state PWRDM_POWER_ON) {
core_prev_state = pwrdm_read_prev_pwrst(core_pwrdm);
--
1.7.5.4
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.
--
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
Re: [PATCH] MMC: omap_hsmmc: enable interface clock before calling mmc_host_enable()
On Tue, Dec 7, 2010 at 5:27 PM, Paul Walmsley p...@pwsan.com wrote:
In the OMAP HSMMC driver, 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. This can
crash the kernel with:
Unhandled fault: external abort on non-linefetch (0x1028) at 0xfa09c014
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 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 5d46021..58a2c5e 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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP HSMMC problems with off-mode
Paul, Last I tested OFF mode was after Adrian's power saving series was merged. I tested it on Kevin PM branch then and it was functional on my omap3 board. I need to check on the latest commit. Did you see this problem in suspend/resume path or the cpuidle path? Regards, Madhu On Tue, Dec 7, 2010 at 12:21 PM, Paul Walmsley p...@pwsan.com wrote: Madhusudhan, On my OMAP35xx BeagleBoard here, HSMMC is non-functional after returning from dynamic off-mode. The MMC LED turns on and stays on, and the process hangs, although the rest of the system still seems to run. Looks like you're listed as the maintainer for this code. Do you know why this is, and what can be done to fix it? This is using linux-omap master at commit a04fd22204b13ce34a3f8a8157f83c44d64f8da9, using omap2plus_defconfig with DSS configured in. My boot and root partitions are on MMC. Following are the commands I used to reproduce this problem. regards - Paul echo 1 /debug/pm_debug/sleep_while_idle echo 1 /debug/pm_debug/enable_off_mode echo 5 /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout -- 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
Re: OMAP HSMMC problems with off-mode
On Tue, Dec 7, 2010 at 1:51 PM, Adrian Hunter adrian.hun...@nokia.com wrote: On 07/12/10 20:21, ext Paul Walmsley wrote: Madhusudhan, On my OMAP35xx BeagleBoard here, HSMMC is non-functional after returning from dynamic off-mode. The MMC LED turns on and stays on, and the process hangs, although the rest of the system still seems to run. Looks like you're listed as the maintainer for this code. Do you know why this is, and what can be done to fix it? It is at least because omap_pm_get_dev_context_loss_count() is not implemented. Tero Kristo was looking at that recently. Yes. I agree that is the problem. In the .32 kernel I had hooked it to get_last_off_on_transaction_id which helped. But that functionality does not exist anymore. So something equivalent to tell the driver when the OFF was hit will make it work. Regards, Madhu This is using linux-omap master at commit a04fd22204b13ce34a3f8a8157f83c44d64f8da9, using omap2plus_defconfig with DSS configured in. My boot and root partitions are on MMC. Following are the commands I used to reproduce this problem. regards - Paul echo 1 /debug/pm_debug/sleep_while_idle echo 1 /debug/pm_debug/enable_off_mode echo 5 /sys/devices/platform/omap/omap-hsuart.0/sleep_timeout echo 5 /sys/devices/platform/omap/omap-hsuart.1/sleep_timeout echo 5 /sys/devices/platform/omap/omap-hsuart.2/sleep_timeout -- 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
RE: [PATCH v2] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but no wakeup sources
Hi Thomas / Kevin,
I did verify Thomas Petazzoni's patch - [PATCH] omap: prcm: switch to a
chained IRQ handler mechanism, and I have below questions or comments.
1. I see for each WKUP_ST or IO_ST interrupt the _prcm_int_handle_wakeup
handler is getting called 2 times which impacts on performance.
printk(irq:%d,%d\n,irq,c); just before returning from the handler shows.
[ 221.966308] irq wkst:377,2
[ 221.968597] irq wkst:377,0
I see, the code checking the below warning is removed, won't it be good to
retain this check ?
WARN(c == 0, prcm: WARNING: PRCM indicated
MPU wakeup but no wakeup sources
are marked\n);
Also need to address the corner case issue, for which I submitted the patch
fix.
[ 222.002563] irq wkst:368,3
[ 222.004913] irq iost:377,0
Regards
Gowda
From: ext Kevin Hilman [khil...@deeprootsystems.com]
Sent: Friday, November 19, 2010 6:36 PM
To: Gowda Madhusudhan.1 (EXT-Elektrobit/Helsinki)
Cc: linux-omap@vger.kernel.org; p...@pwsan.com
Subject: Re: [PATCH v2] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but
no wakeup sources
Madhusudhan Gowda ext-madhusudhan.1.go...@nokia.com writes:
A corner case where prcm_interrupt handler is handling the WKST_WKUP and
before acknowledging the wakeup sources if an IO Pad wakeup ST_IO is
indicated then hits the below warning since the wakeup sources are already
cleared.
WARN(c == 0, prcm: WARNING: PRCM indicated
MPU wakeup but no wakeup sources
are marked\n);
Since the above warning condition is only valid if the prcm_interrupt
handler is called but no wakeup sources are marked in first iteration.
The patch fixes this corner case.
Updated after Paul Walmsley's only handle selected PRCM interrupts patch.
Can you have a look at the recent work by Thomas Petazzoni:
[PATCH] omap: prcm: switch to a chained IRQ handler mechanism
where the PRCM IRQ handler is broken up to see if this problem still
exists? I suspect the problem is gone as each type of interrupt is
separated out, but should be verified.
Kevin
Signed-off-by: Madhusudhan Gowda ext-madhusudhan.1.go...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..2ed3662 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -266,6 +266,7 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
{
u32 irqenable_mpu, irqstatus_mpu;
int c = 0;
+ int ct = 0;
irqenable_mpu = prm_read_mod_reg(OCP_MOD,
OMAP3_PRM_IRQENABLE_MPU_OFFSET);
@@ -277,13 +278,15 @@ static irqreturn_t prcm_interrupt_handler (int irq,
void *dev_id)
if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
OMAP3430_IO_ST_MASK)) {
c = _prcm_int_handle_wakeup();
+ ct++;
/*
* Is the MPU PRCM interrupt handler racing with the
* IVA2 PRCM interrupt handler ?
*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
- but no wakeup sources are marked\n);
+ WARN(!c (ct == 1), prcm: WARNING: PRCM indicated
+ MPU wakeup but no wakeup sources
+ are marked\n);
} else {
/* XXX we need to expand our PRCM interrupt handler */
WARN(1, prcm: WARNING: PRCM interrupt received, but
--
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
[PATCH] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but no wakeup sources
A corner case where prcm_interrupt handler is handling the WKST_WKUP and
before acknowledging the wakeup sources if an IO Pad wakeup ST_IO is
indicated then hits the below warning since the wakeup sources are already
cleared.
WARN(c == 0, prcm: WARNING: PRCM indicated
MPU wakeup but no wakeup sources
are marked\n);
Since the above warning condition is only valid if the prcm_interrupt
handler is called but no wakeup sources are marked in first iteration.
The patch fixes this corner case.
Updated after Paul Walmsley's only handle selected PRCM interrupts patch.
Signed-off-by: Madhusudhan Gowda ext-madhusudhan.1.go...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..d9a35d7 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -266,6 +266,7 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
{
u32 irqenable_mpu, irqstatus_mpu;
int c = 0;
+ int ct = 0;
irqenable_mpu = prm_read_mod_reg(OCP_MOD,
OMAP3_PRM_IRQENABLE_MPU_OFFSET);
@@ -277,13 +278,16 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
OMAP3430_IO_ST_MASK)) {
c = _prcm_int_handle_wakeup();
+ ct++;
/*
* Is the MPU PRCM interrupt handler racing with the
* IVA2 PRCM interrupt handler ?
*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
-but no wakeup sources are marked\n);
+ if (ct == 1)
+ WARN(c == 0, prcm: WARNING: PRCM indicated
+ MPU wakeup but no wakeup sources
+ are marked\n);
} else {
/* XXX we need to expand our PRCM interrupt handler */
WARN(1, prcm: WARNING: PRCM interrupt received, but
--
1.6.3.3
--
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
RE: [PATCH] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but no wakeup sources
Yes Balbi. I will incorporate your comments.
Regards
Gowda
From: linux-omap-ow...@vger.kernel.org [linux-omap-ow...@vger.kernel.org] On
Behalf Of ext Felipe Balbi [ba...@ti.com]
Sent: Friday, November 19, 2010 1:47 PM
To: Gowda Madhusudhan.1 (EXT-Elektrobit/Helsinki)
Cc: linux-omap@vger.kernel.org; p...@pwsan.com
Subject: Re: [PATCH] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but no
wakeup sources
Hi,
On Fri, Nov 19, 2010 at 01:26:33PM +0200, Madhusudhan Gowda wrote:
@@ -277,13 +278,16 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
OMAP3430_IO_ST_MASK)) {
c = _prcm_int_handle_wakeup();
+ ct++;
/*
* Is the MPU PRCM interrupt handler racing with the
* IVA2 PRCM interrupt handler ?
*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
- but no wakeup sources are marked\n);
+ if (ct == 1)
+ WARN(c == 0, prcm: WARNING: PRCM indicated
+ MPU wakeup but no wakeup sources
+ are marked\n);
WARN(!c (ct == 1), prcm: WARNING: PRCM indicated
MPU wakeup but no wakeup sources
are marked\n);
would do it? Then you don't need the extra if ().
--
balbi
--
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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] OMAP3: PM: PRCM interrupt: Fix warning MPU wakeup but no wakeup sources
A corner case where prcm_interrupt handler is handling the WKST_WKUP and
before acknowledging the wakeup sources if an IO Pad wakeup ST_IO is
indicated then hits the below warning since the wakeup sources are already
cleared.
WARN(c == 0, prcm: WARNING: PRCM indicated
MPU wakeup but no wakeup sources
are marked\n);
Since the above warning condition is only valid if the prcm_interrupt
handler is called but no wakeup sources are marked in first iteration.
The patch fixes this corner case.
Updated after Paul Walmsley's only handle selected PRCM interrupts patch.
Signed-off-by: Madhusudhan Gowda ext-madhusudhan.1.go...@nokia.com
---
arch/arm/mach-omap2/pm34xx.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 75c0cd1..2ed3662 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -266,6 +266,7 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
{
u32 irqenable_mpu, irqstatus_mpu;
int c = 0;
+ int ct = 0;
irqenable_mpu = prm_read_mod_reg(OCP_MOD,
OMAP3_PRM_IRQENABLE_MPU_OFFSET);
@@ -277,13 +278,15 @@ static irqreturn_t prcm_interrupt_handler (int irq, void
*dev_id)
if (irqstatus_mpu (OMAP3430_WKUP_ST_MASK |
OMAP3430_IO_ST_MASK)) {
c = _prcm_int_handle_wakeup();
+ ct++;
/*
* Is the MPU PRCM interrupt handler racing with the
* IVA2 PRCM interrupt handler ?
*/
- WARN(c == 0, prcm: WARNING: PRCM indicated MPU wakeup
-but no wakeup sources are marked\n);
+ WARN(!c (ct == 1), prcm: WARNING: PRCM indicated
+ MPU wakeup but no wakeup sources
+ are marked\n);
} else {
/* XXX we need to expand our PRCM interrupt handler */
WARN(1, prcm: WARNING: PRCM interrupt received, but
--
1.6.3.3
--
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
RE: omap4: hsmmc: Fix improper card detection while booting
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of kishore kadiyala
Sent: Monday, November 15, 2010 3:09 AM
To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org
Subject: omap4: hsmmc: Fix improper card detection while booting
While booting OMAP4 ES2.0 boards, cards on MMC1 and MMC2 controllers
are not getting detected some times.
During reset of command/data line, wrong pointer to base address
was passed while read operation to SYSCTL register, thus impacting
the updated reset logic.
Passing correct base address fixes the issue.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Acked-by: Felipie Balbi ba...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Chris Ball c...@laptop.org
Cc: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 82a1079..5d46021 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1002,7 +1002,7 @@ static inline void
omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host
*host,
* Monitor a 0-1 transition first
*/
if (mmc_slot(host).features HSMMC_HAS_UPDATED_RESET) {
- while ((!(OMAP_HSMMC_READ(host, SYSCTL) bit))
+ while ((!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
(i++ limit))
cpu_relax();
}
--
1.7.1
Ack.
Acked-by: Madhusudhan Chikkature madhu...@ti.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
--
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
RE: [PATCH] omap4: pandaboard: fix up mmc card detect logic
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Friday, October 15, 2010 8:25 AM
To: l-o
Cc: Dave; Nishanth Menon; Tony Lindgren; Madhusudhan Chikkature; Adrian
Hunter; Samuel Ortiz
Subject: [PATCH] omap4: pandaboard: fix up mmc card detect logic
For MMC1 Controller, card detect interrupt source is
twl6030 which is non-gpio. The card detect call back function provides
card present/absent status by reading MMC Control register present
on twl6030. This functionality was introduced in mfd tree on
track to kernel.org
Sync pandaboard to the same and make mmc work.
Cc: Tony Lindgren t...@atomide.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Kishore Kadiyala kishore.kadiy...@ti.com
The patch looks good.
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
---
Depends on
http://git.kernel.org/?p=linux/kernel/git/sameo/mfd-
2.6.git;a=commitdiff;h=1bf5197061a4aec99e9fd4f92d4a543310f83585;hp=0c9b33e
5a23e2053165c9e303b3a3cf1b2b8
This patch probably should be squashed to that.
arch/arm/mach-omap2/board-omap4panda.c | 15 ---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-
omap2/board-omap4panda.c
index a9d8a19..47cc8d2 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -160,10 +160,19 @@ static int omap4_twl6030_hsmmc_late_init(struct
device *dev)
struct platform_device, dev);
struct omap_mmc_platform_data *pdata = dev-platform_data;
+ if (!pdata) {
+ dev_err(dev, %s: NULL platform data\n, __func__);
+ return -EINVAL;
+ }
/* Setting MMC1 Card detect Irq */
- if (pdev-id == 0)
- pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
- MMCDETECT_INTR_OFFSET;
+ if (pdev-id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+ if (ret)
+ dev_err(dev, %s: Error card detect config(%d)\n,
+ __func__, ret);
+ else
+ pdata-slots[0].card_detect =
twl6030_mmc_card_detect;
+ }
return ret;
}
--
1.6.3.3
--
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
RE: [Omapandroid-discussion] Difference between twl4030_hsmmc_infoand omap_mmc_platform_data
-Original Message- From: omapandroid-discussion-boun...@gforge.ti.com [mailto:omapandroid- discussion-boun...@gforge.ti.com] On Behalf Of Elvis Dowson Sent: Thursday, October 14, 2010 6:19 PM To: Nishanth Menon Cc: Linux OMAP Mailing List; omapandroid-discuss...@omapzoom.org Subject: Re: [Omapandroid-discussion] Difference between twl4030_hsmmc_infoand omap_mmc_platform_data Hi, On Oct 15, 2010, at 2:56 AM, Nishanth Menon wrote: mainline does it this way: board files report using omap2_hsmmc_info[2] to hsmmc.c using omap2_hsmmc_init[3] - hsmmc.c converts them to required datastructures that omap_hsmmc.c uses.. What is the relationship between twl4030 and hsmmc controller in this chain, especially with respect to MMC2? Twl4030 is the power chip. Its LDOs are modeled through the regulator framework used by MMC1 and MMC2. On OMAP3 the card detect is from the GPIO module of twl4030. Regards, Madhu Best regards, Elvis ___ Omapandroid-discussion mailing list omapandroid-discuss...@gforge.ti.com https://gforge.ti.com/mailman/listinfo/omapandroid-discussion -- 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
RE: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
-Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Thursday, October 07, 2010 8:57 AM To: Mike Rapoport Cc: Madhusudhan Chikkature; David Vrabel; Chris Ball; linux- m...@vger.kernel.org; linux-omap@vger.kernel.org; Adrian Hunter Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) On Thu, Oct 7, 2010 at 12:15 AM, Mike Rapoport m...@compulab.co.il wrote: Hi Madhu, Madhusudhan Chikkature wrote: snip You are correct! The version of the patch in the repo indeed has 'out' in the wrong place and generates a compile error. Could you post the patch you are using and I will try to reproduce what you are seeing on my hardware? Best we all work from exactly the same patch! Steve Yes. I think that check breaking the compilation is not needed. How about the below version? It just removes that check. This version should apply fine on the latest kernel. I did a sanity test of MMC/SD cards on OMAP4 SDP. Steve or Mike can check if SDIO interrupts are working. With you patch I get the same: libertas_sdio: Libertas SDIO driver libertas_sdio: Copyright Pierre Ossman libertas: command 0x0003 timed out libertas: Timeout submitting command 0x0003 libertas: PREP_CMD: command 0x0003 failed: -110 libertas_sdio: probe of mmc1:0001:1 failed with error -110 I can confirm exactly the same behavior on my hardware with this version of the patch. Steve, Okay. Did the version you had in your tree worked? I just want to check if I messed up something in my patch. Regards, Madhu Steve -- 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
RE: [PATCH 5/6] save and restore etm state across core OFF modes
Hi,
+ bne debug_restore /* loop till done */
+ str r5, [r6, #ETMMR_OSSRR] /* clear lock */
I had informed Alexander about the missing OSLAR to clear the lock and also
the do_etm_save value does not retain across coreoff since sram size may vary
across coreoffs. We need to save this do_etm_save value to sdram along with the
jtag etm debug context and restore it to do_etm_save.
Thanks
Gowda
From: Eduardo Valentin [eduardo.valen...@nokia.com]
Sent: Wednesday, October 06, 2010 2:22 PM
To: Valentin Eduardo (Nokia-MS/Helsinki)
Cc: ext virtu...@slind.org; t...@atomide.com; linux-omap@vger.kernel.org;
khil...@deeprootsystems.com; r-woodru...@ti.com; Gowda Madhusudhan.1
(EXT-Elektrobit/Helsinki)
Subject: Re: [PATCH 5/6] save and restore etm state across core OFF modes
Hey,
I think Gowda had also some thoughts about this patch. Cc'ing him.
BR,
On Wed, Oct 06, 2010 at 10:35:09AM +0200, Valentin Eduardo (Nokia-D/Helsinki)
wrote:
Hello Alexander,
Few points as follows,
On Sat, May 01, 2010 at 07:38:20PM +0200, ext virtu...@slind.org wrote:
From: Alexander Shishkin virtu...@slind.org
This prevents ETM stalls whenever core enters OFF mode. Original patch
author is Richard Woodruff r-woodru...@ti.com.
This version of the patch makes use of the ETM OS save/restore mechanism,
which takes about 55 words in omap3_arm_context[] instead of 128. Also,
saving ETM context can be switched on/off at runtime.
Signed-off-by: Alexander Shishkin virtu...@slind.org
CC: Richard Woodruff r-woodru...@ti.com
---
arch/arm/mach-omap2/Kconfig |9 ++
arch/arm/mach-omap2/control.c |2 +-
arch/arm/mach-omap2/sleep34xx.S | 135
+
arch/arm/plat-omap/include/plat/control.h |2 +-
4 files changed, 146 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 2455dcc..5460bfe 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -150,6 +150,15 @@ config MACH_OMAP_4430SDP
bool OMAP 4430 SDP board
depends on ARCH_OMAP4
+config ENABLE_OFF_MODE_JTAG_ETM_DEBUG
+ bool Enable hardware emulation context save and restore
+ depends on ARCH_OMAP3
+ default y
+ help
+ This option enables JTAG ETM debugging across power states.
+ With out this option emulation features are reset across OFF
+ mode state changes.
+
config OMAP3_EMU
bool OMAP3 debugging peripherals
depends on ARCH_OMAP3
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index 43f8a33..70b1674 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -93,7 +93,7 @@ void *omap3_secure_ram_storage;
* The address is stored in scratchpad, so that it can be used
* during the restore path.
*/
-u32 omap3_arm_context[128];
+u32 omap3_arm_context[256];
struct omap3_control_regs {
u32 sysconfig;
diff --git a/arch/arm/mach-omap2/sleep34xx.S
b/arch/arm/mach-omap2/sleep34xx.S
index d522cd7..cd6a1d4 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -28,6 +28,7 @@
#include asm/assembler.h
#include mach/io.h
#include plat/control.h
+#include asm/hardware/coresight.h
#include cm.h
#include prm.h
@@ -226,6 +227,18 @@ loop:
nop
bl wait_sdrc_ok
+#ifdef CONFIG_ENABLE_OFF_MODE_JTAG_ETM_DEBUG
+ /*
+* Restore Coresight debug registers
+*/
+ ldr r6, debug_vbase /* base Vaddr of CortexA8-Debug */
+ ldr r4, debug_xlar_key /* get lock key for OSLAR */
+ bl unlock_debug/* remove global lock if set */
+ ldr r6, etm_vbase /* base Vaddr of ETM */
+ bl unlock_debug/* remove global lock if set */
+ str r6, [r6, #ETMMR_OSLAR] /* clear OSLAR lock using non-key */
+#endif
+
ldmfd sp!, {r0-r12, pc} @ restore regs and return
restore_es3:
/*b restore_es3*/ @ Enable to debug restore code
@@ -385,6 +398,44 @@ logic_l1_restore:
/*normal memory remap register */
MCR p15, 0, r5, c10, c2, 1
+#ifdef CONFIG_ENABLE_OFF_MODE_JTAG_ETM_DEBUG
+ /*
+* Restore Coresight debug registers
+*/
+ ldr r6, debug_pbase /* base paddr of CortexA8-Debug */
+ ldr r4, debug_xlar_key /* get lock key for OSLAR */
+ bl unlock_debug/* remove global lock if set */
+ str r4, [r6, #ETMMR_OSLAR] /* reset-pointer (already locked) */
+ ldr r4, [r6, #ETMMR_OSSRR] /* dummy read */
+ ldr r4, [r3], #4/* load save size */
+ cmp r4, #0 /* check for zero */
+debug_restore:
+ itttne /* t2/compat if-then block */
+ ldrne r5, [r3
Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
snip
You are correct! The version of the patch in the repo indeed has
'out' in the wrong place and generates a compile error.
Could you post the patch you are using and I will try to reproduce
what you are seeing on my hardware? Best we all work from exactly the
same patch!
Steve
Yes. I think that check breaking the compilation is not needed. How about the
below version? It just removes that check.
This version should apply fine on the latest kernel. I did a sanity test of
MMC/SD cards on OMAP4 SDP.
Steve or Mike can check if SDIO interrupts are working.
Regards,
Madhu
From 08b77fd388f19f5df3758a2c59dcdec280f373c8 Mon Sep 17 00:00:00 2001
From: David Vrabel david.vra...@csr.com
Date: Wed, 6 Oct 2010 12:39:18 -0500
Subject: [PATCH 1/2] mmc: omap_hsmmc: enable SDIO card interrupts
Enable the use of SDIO card interrupts.
FCLK must be enabled while SDIO interrupts are enabled or the MMC
module won't wake-up (even though ENAWAKEUP in SYSCONFIG and IWE in
HTCL have been set). Enabling the MMC module to wake-up would require
configuring the MMC module (and the mmci_dat[1] GPIO when the CORE
power domain is OFF) as wake-up sources in the PRCM.
The writes to STAT and ISE when starting a command are unnecessary and
have been removed.
Signed-off-by: David Vrabel david.vra...@csr.com
---
drivers/mmc/host/omap_hsmmc.c | 72 +
1 files changed, 65 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4693e62..948dd9a 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -66,6 +66,7 @@
#define SDVS_MASK 0x0E00
#define SDVSCLR0xF1FF
#define SDVSDET0x0400
+#define ENAWAKEUP (1 2)
#define AUTOIDLE 0x1
#define SDBP (1 8)
#define DTO0xe
@@ -76,9 +77,12 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
+#define CIRQ_ENABLE(1 8)
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
#define DTO_ENABLE (1 20)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
@@ -87,10 +91,12 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define IWE(1 24)
#define DW8(1 5)
#define CC 0x1
#define TC 0x02
#define OD 0x1
+#define CIRQ (1 8)
#define ERR(1 15)
#define CMD_TIMEOUT(1 16)
#define DATA_TIMEOUT (1 20)
@@ -184,6 +190,7 @@ struct omap_hsmmc_host {
int reqs_blocked;
int use_reg;
int req_in_progress;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -551,6 +558,9 @@ static void omap_hsmmc_enable_irq(struct omap_hsmmc_host
*host,
if (cmd-opcode == MMC_ERASE)
irq_mask = ~DTO_ENABLE;
+ if (host-sdio_int)
+ irq_mask |= CIRQ;
+
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, irq_mask);
OMAP_HSMMC_WRITE(host-base, IE, irq_mask);
@@ -603,7 +613,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE | ENAWAKEUP);
if (host-id == OMAP_MMC1_DEVID) {
if (host-power_mode != MMC_POWER_OFF
@@ -618,7 +628,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
}
OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | hctl);
+ OMAP_HSMMC_READ(host-base, HCTL) | hctl | IWE);
OMAP_HSMMC_WRITE(host-base, CAPA,
OMAP_HSMMC_READ(host-base, CAPA) | capa);
@@ -1019,6 +1029,7 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
{
struct mmc_data *data;
int end_cmd = 0, end_trans = 0;
+ bool card_irq = false;
if (!host-req_in_progress) {
do {
@@ -1032,6 +1043,9 @@ static void omap_hsmmc_do_irq(struct omap_hsmmc_host
*host, int status)
data = host-data;
dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+ if (status CIRQ)
+ card_irq = true;
+
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1087,6 +1101,9 @@
RE: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
-Original Message- From: David Vrabel [mailto:david.vra...@csr.com] Sent: Wednesday, October 06, 2010 2:02 PM To: Madhusudhan Chikkature Cc: Steve Sakoman; Mike Rapoport; Chris Ball; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; Adrian Hunter Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) Madhusudhan Chikkature wrote: This version should apply fine on the latest kernel. I did a sanity test of MMC/SD cards on OMAP4 SDP. This /looks/ okay to me, but I can't test it. From 08b77fd388f19f5df3758a2c59dcdec280f373c8 Mon Sep 17 00:00:00 2001 From: David Vrabel david.vra...@csr.com Date: Wed, 6 Oct 2010 12:39:18 -0500 Subject: [PATCH 1/2] mmc: omap_hsmmc: enable SDIO card interrupts [...] The writes to STAT and ISE when starting a command are unnecessary and have been removed. Remove this last paragraph from the description as it isn't applicable any more. Sure. Regards, Madhu David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- 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
RE: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
-Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Monday, October 04, 2010 11:32 AM To: Mike Rapoport Cc: David Vrabel; Chris Ball; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; madhu...@ti.com Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) On Wed, Sep 1, 2010 at 11:02 PM, Mike Rapoport m...@compulab.co.il wrote: David Vrabel wrote: On 27/08/2010 20:22, Chris Ball wrote: Hi David, On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. Changes since v1: - (hopefully) get all cards working again by removing a second call to read MMCi_STAT in the interrupt handler. - flush posted writes after enabling/disabling SDIO interrupts. - tweak the FIXME commit on disabling FCLK to better match what really going on (at least I think so anyway). David Vrabel (2): mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts Looks like this patchset wasn't merged. Mike Rapoport replied with a fix for libertas. Would you like to resubmit it? I thought Madhu had picked this up and was going to submit it. Regardless of whether that is the case, I think it needs to be submitted by someone who can run mainline kernels (I can't) and ideally someone who can test it with SDIO cards. I'll try to update the patches in the next few days. Any update on the status of these patches? I'm happy to help test! Steve, I have not been able to test SDIO card interrupts. If you could help test that it's great. Regards, Madhu Steve -- 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
RE: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2)
-Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Monday, October 04, 2010 11:57 AM To: Madhusudhan Cc: Mike Rapoport; David Vrabel; Chris Ball; linux-...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) On Mon, Oct 4, 2010 at 9:45 AM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Monday, October 04, 2010 11:32 AM To: Mike Rapoport Cc: David Vrabel; Chris Ball; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; madhu...@ti.com Subject: Re: [PATCH 0/2] mmc: omap_hsmmc: support SDIO cards (#2) On Wed, Sep 1, 2010 at 11:02 PM, Mike Rapoport m...@compulab.co.il wrote: David Vrabel wrote: On 27/08/2010 20:22, Chris Ball wrote: Hi David, On Mon, Feb 22, 2010 at 02:24:17PM +, David Vrabel wrote: These patches add support for SDIO cards to the omap_hsmmc driver. Power management changes to prevent SDIO cards from being turned off and losing all state, and card interrupts. I've been unable to test these exact patches as I only have an N900 for testing and the N900 support in mainline is incomplete. Changes since v1: - (hopefully) get all cards working again by removing a second call to read MMCi_STAT in the interrupt handler. - flush posted writes after enabling/disabling SDIO interrupts. - tweak the FIXME commit on disabling FCLK to better match what really going on (at least I think so anyway). David Vrabel (2): mmc: omap_hsmmc: don't turn SDIO cards off when idle mmc: omap_hsmmc: enable SDIO card interrupts Looks like this patchset wasn't merged. Mike Rapoport replied with a fix for libertas. Would you like to resubmit it? I thought Madhu had picked this up and was going to submit it. Regardless of whether that is the case, I think it needs to be submitted by someone who can run mainline kernels (I can't) and ideally someone who can test it with SDIO cards. I'll try to update the patches in the next few days. Any update on the status of these patches? I'm happy to help test! Steve, I have not been able to test SDIO card interrupts. If you could help test that it's great. Where can I grab the most recent patches? The original set don't apply cleanly. Yes. They may not apply. I can rebase them and send it to you for testing. Are you using the two patches posted by David Vrabel? Regards, Madhu Steve -- 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
[PATCH V2] OMAP4 ES2: HSMMC soft reset change
The omap4 es2 hsmmc has a updated soft reset logic.After the
reset is issued monitor a 0-1 transition first. The reset of
CMD or DATA lines is complete only after a 0-1-0 transition
of SRC or SRD bits.
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
Tested-by: Anand Gadiyar gadi...@ti.com
---
arch/arm/mach-omap2/hsmmc.c |3 +++
arch/arm/plat-omap/include/plat/mmc.h |1 +
drivers/mmc/host/omap_hsmmc.c | 11 +++
3 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 87ce6ff..37f9f56 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -298,6 +298,9 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
else
mmc-slots[0].features |= HSMMC_HAS_PBIAS;
+ if (cpu_is_omap44xx() (omap_rev() OMAP4430_REV_ES1_0))
+ mmc-slots[0].features |= HSMMC_HAS_UPDATED_RESET;
+
switch (c-mmc) {
case 1:
if (mmc-slots[0].features HSMMC_HAS_PBIAS) {
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 4f819fc..2c4629a 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -103,6 +103,7 @@ struct omap_mmc_platform_data {
/* we can put the features above into this variable */
#define HSMMC_HAS_PBIAS(1 0)
+#define HSMMC_HAS_UPDATED_RESET(1 1)
unsigned features;
int switch_pin; /* gpio (card detect) */
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 53f8fa5..69858e7 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -982,6 +982,17 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host *host,
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | bit);
+ /*
+* OMAP4 ES2 and greater has an updated reset logic.
+* Monitor a 0-1 transition first
+*/
+ if (mmc_slot(host).features HSMMC_HAS_UPDATED_RESET) {
+ while ((!(OMAP_HSMMC_READ(host, SYSCTL) bit))
+(i++ limit))
+ cpu_relax();
+ }
+ i = 0;
+
while ((OMAP_HSMMC_READ(host-base, SYSCTL) bit)
(i++ limit))
cpu_relax();
--
1.7.0.4
--
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
RE: [PATCH] OMAP4: HSMMC cmd line reset change
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, September 21, 2010 9:47 AM To: Madhusudhan Cc: c...@laptop.org; linux-...@vger.kernel.org; linux-omap@vger.kernel.org; santosh.shilim...@ti.com Subject: Re: [PATCH] OMAP4: HSMMC cmd line reset change * Madhusudhan madhu...@ti.com [100920 09:06]: Please don't use cpu_is_omap tests in the drivers, drivers should be generic. Instead, just pass a feature flag in the platform_data for this feature like HSMMC_REVERSE_RESET_LOGIC or similar. This is not a feature. It is like an ERRATA fix. I am yet to receive an errata number though. How about dealing with this like an errata fix similar to the way in arch/mach-omap2/serial.c done for the uart case? Yes setting some HSMMC_ERRATA_XYZ flag works too. The mmc ip revision will not help because it really does not change to distinguish such issues. OK. Then I guess your only option is to pass the errata flag in the platform_data. Chris, Can you please drop this patch? Sorry, I spoke bit too early on this patch. I need to sort out some stuff internally (seems like it will not be released as an errata). I will post a revised version a bit later. Regards, Madhu Regards, Tony -- 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
RE: [PATCH] OMAP4: HSMMC cmd line reset change
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Friday, September 17, 2010 10:48 AM
To: Madhusudhan Chikkature
Cc: c...@laptop.org; linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
santosh.shilim...@ti.com
Subject: Re: [PATCH] OMAP4: HSMMC cmd line reset change
* Madhusudhan Chikkature madhu...@ti.com [100915 16:50]:
OMAP4: HSMMC cmd line reset change
The cmd line reset logic is changed in OMAP4 ES2. The new procedure
is to monitor a 0-1 transition and then 1-0 transition.The earlier
logic would fail on ES2 chips because the loop could exit even before
the reset is actually complete.
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 4526d27..750ba7d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -976,12 +976,19 @@ static inline void
omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host *host,
unsigned long bit)
{
unsigned long i = 0;
+ unsigned long j = 0;
unsigned long limit = (loops_per_jiffy *
msecs_to_jiffies(MMC_TIMEOUT_MS));
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | bit);
+ if (cpu_is_omap44xx() bit == SRC) {
+ while ((!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
+(j++ limit))
+ cpu_relax();
+ }
+
while ((OMAP_HSMMC_READ(host-base, SYSCTL) bit)
(i++ limit))
cpu_relax();
Please don't use cpu_is_omap tests in the drivers, drivers
should be generic.
Instead, just pass a feature flag in the platform_data for this
feature like HSMMC_REVERSE_RESET_LOGIC or similar.
This is not a feature. It is like an ERRATA fix. I am yet to receive an
errata number though. How about dealing with this like an errata fix similar
to the way in arch/mach-omap2/serial.c done for the uart case?
The mmc ip revision will not help because it really does not change to
distinguish such issues.
Regards,
Madhu
Even better, look at the mmc silicon revision number and set this
flag automatically during the driver init if possible.
Regards,
Tony
--
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
RE: [PATCH 6/7] omap4: Workaround for CMD line reset.
-Original Message- From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com] Sent: Tuesday, September 14, 2010 11:49 AM To: Chikkature Rajashekar, Madhusudhan; 'kishore kadiyala' Cc: linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com Subject: RE: [PATCH 6/7] omap4: Workaround for CMD line reset. Madhu, -Original Message- From: Chikkature Rajashekar, Madhusudhan Sent: Tuesday, September 14, 2010 9:28 PM To: 'kishore kadiyala'; Shilimkar, Santosh Cc: linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com Subject: RE: [PATCH 6/7] omap4: Workaround for CMD line reset. -Original Message- From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] Sent: Tuesday, September 14, 2010 10:47 AM To: Madhusudhan Chikkature; Santosh Shilimkar Cc: linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com Subject: Re: [PATCH 6/7] omap4: Workaround for CMD line reset. Hi Madhu, On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: From: Madhusudhan Chikkature madhu...@ti.com Add a delay after CMD line reset to accomdate the reset to complete. The SYSCTL seems to reflect SRC immediately which might not really be indicating the complete of reset. This is observed only with ES2.0 silicon Signed-off-by: Madhusudhan Chikkature madhu...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 4a8776f..1c359f0 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -986,6 +986,14 @@ static inline void omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host, (i++ limit)) cpu_relax(); + /* + * On OMAP4 ES2 the SRC is zero in the first loop itself strangely + * vs on ES1 it takes some time. + * Could be a an issue on ES2 to indicate reset complete even before + * it is complete. + */ + udelay(500); Since the above work around is applicable only for OMAP4 ES2 , shouldn't this udelay be avoided for other OMAP versions I did not post this to Linux omap at all. What patch are you talking about? I have posted this patch on Tony and Kevin's request keeping the original author. This is needed to get MMC working on ES2.0 samples. Do you have fresh version of this patch? Yes. There is a TRM update lately that explains the procedure for CMD line reset changes in ES2. I will post that patch. Regards, Madhu Regards, Santosh -- 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
[PATCH] OMAP4: HSMMC cmd line reset change
OMAP4: HSMMC cmd line reset change
The cmd line reset logic is changed in OMAP4 ES2. The new procedure
is to monitor a 0-1 transition and then 1-0 transition.The earlier
logic would fail on ES2 chips because the loop could exit even before
the reset is actually complete.
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4526d27..750ba7d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -976,12 +976,19 @@ static inline void omap_hsmmc_reset_controller_fsm(struct
omap_hsmmc_host *host,
unsigned long bit)
{
unsigned long i = 0;
+ unsigned long j = 0;
unsigned long limit = (loops_per_jiffy *
msecs_to_jiffies(MMC_TIMEOUT_MS));
OMAP_HSMMC_WRITE(host-base, SYSCTL,
OMAP_HSMMC_READ(host-base, SYSCTL) | bit);
+ if (cpu_is_omap44xx() bit == SRC) {
+ while ((!(OMAP_HSMMC_READ(host-base, SYSCTL) bit))
+(j++ limit))
+ cpu_relax();
+ }
+
while ((OMAP_HSMMC_READ(host-base, SYSCTL) bit)
(i++ limit))
cpu_relax();
--
1.7.0.4
--
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
RE: [PATCH 6/7] omap4: Workaround for CMD line reset.
-Original Message- From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] Sent: Tuesday, September 14, 2010 10:47 AM To: Madhusudhan Chikkature; Santosh Shilimkar Cc: linux-omap@vger.kernel.org; t...@atomide.com; khil...@deeprootsystems.com Subject: Re: [PATCH 6/7] omap4: Workaround for CMD line reset. Hi Madhu, On Thu, Sep 9, 2010 at 4:53 PM, Santosh Shilimkar santosh.shilim...@ti.com wrote: From: Madhusudhan Chikkature madhu...@ti.com Add a delay after CMD line reset to accomdate the reset to complete. The SYSCTL seems to reflect SRC immediately which might not really be indicating the complete of reset. This is observed only with ES2.0 silicon Signed-off-by: Madhusudhan Chikkature madhu...@ti.com --- drivers/mmc/host/omap_hsmmc.c | 8 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 4a8776f..1c359f0 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -986,6 +986,14 @@ static inline void omap_hsmmc_reset_controller_fsm(struct omap_hsmmc_host *host, (i++ limit)) cpu_relax(); + /* + * On OMAP4 ES2 the SRC is zero in the first loop itself strangely + * vs on ES1 it takes some time. + * Could be a an issue on ES2 to indicate reset complete even before + * it is complete. + */ + udelay(500); Since the above work around is applicable only for OMAP4 ES2 , shouldn't this udelay be avoided for other OMAP versions I did not post this to Linux omap at all. What patch are you talking about? Regards, Madhu Regards, Kishore + if (OMAP_HSMMC_READ(host-base, SYSCTL) bit) dev_err(mmc_dev(host-mmc), Timeout waiting on controller reset in %s\n, -- 1.6.0.4 -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6] OMAP4 HSMMC: Adding Card detect support for MMC1 on OMAP4
snip
arch/arm/mach-omap2/board-4430sdp.c | 7 +++-
drivers/mfd/twl6030-irq.c | 76
+++
drivers/mmc/host/omap_hsmmc.c | 4 +-
include/linux/i2c/twl.h | 16 +++
4 files changed, 100 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index f287461..388b96d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct
device *dev)
struct omap_mmc_platform_data *pdata = dev-platform_data;
/* Setting MMC1 Card detect Irq */
- if (pdev-id == 0)
+ if (pdev-id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+ if (ret)
+ pr_err(Failed configuring MMC1 card
detect\n);
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+ pdata-slots[0].card_detect =
twl6030_mmc_card_detect;
You are assigning an exported fn here.
What if somebody disables CONFIG_TWL4030_CORE in the omap_4430sdp_defconfig
file? Does the driver behave nicely with only loosing the hotplug
capability?
Regards,
Madhu
+ }
return ret;
}
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..c027692 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -36,6 +36,7 @@
#include linux/irq.h
#include linux/kthread.h
#include linux/i2c/twl.h
+#include linux/platform_device.h
/*
* TWL6030 (unlike its predecessors, which had two level interrupt
handling)
@@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8
offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from
Phoenix */
+ if (twl_class_is_6030()) {
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+
REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+
REG_INT_MSK_STS_B);
+ }
+
+ /*
+ * Intially Configuring MMC_CTRL for receving interrupts
+ * Card status on TWL6030 for MMC1
+ */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read MMCCTRL, error %d\n,
ret);
+ return ret;
+ }
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
TWL6030_MMCCTRL);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to write MMCCTRL, error
%d\n,
ret);
+ }
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+
TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to read CFG_INPUT_PUPD3,
error
%d\n,
+
ret);
+ }
+ reg_val = ~(MMC_PU | MMC_PD);
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
+
TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ pr_err(twl6030: Failed to write CFG_INPUT_PUPD3,
error
%d\n,
+
ret);
+ return ret;
+ }
+ return 0;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
+
+int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+ int ret = -EIO;
+ u8 read_reg;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
+
+ switch (pdev-id) {
+ case 0:
+ /*
+ * BIT0 of REG_MMC_CTRL
+ * 0 - Card not present ,1 - Card present
+ */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, read_reg,
+
TWL6030_MMCCTRL);
+ if (ret = 0)
+ ret = read_reg STS_MMC;
+ break;
+ default:
+ pr_err(Unkown MMC controller %d in %s\n, pdev-id,
__func__);
+ }
+ return ret;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect);
+
int twl6030_init_irq(int irq_num, unsigned irq_base, unsigned
irq_end)
{
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index b032828..c047b13 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -464,8 +464,6 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
RE: [PATCH v6] OMAP4 HSMMC: Adding Card detect support for MMC1 on OMAP4
-Original Message-
From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
Sent: Monday, August 02, 2010 9:33 AM
To: Andrew Morton
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
t...@atomide.com; madhu...@ti.com; adrian.hun...@nokia.com
Subject: Re: [PATCH v6] OMAP4 HSMMC: Adding Card detect support for MMC1
on OMAP4
Andrew,
Can this patch be taken now as there are no comments.
Regards,
Kishore
Kishore,
As Andrew mentioned some time back this series has to go through Linux-omap.
Tony had a comment on the below first patch in the series.
[PATCH v5 1/2] OMAP HSMMC: Adding a Flag to determine the type of Card
detect
How is the NON-GPIO card detect handled now? Is the above patch not needed
anymore?
Regards,
Madhu
On Wed, Jul 7, 2010 at 7:42 PM, kishore kadiyala
kishore.kadiy...@ti.com wrote:
Adding card detect callback function and card detect configuration
function for MMC1 Controller.
Card detect configuration function does initial configuration of the
MMC Control PullUp-PullDown registers of Phoenix.
For MMC1 Controller, Card detect interrupt source is
twl6030 and the card detect call back function provides card
present/absent
status by reading MMC Control register.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Cc: Tony Lindgren t...@atomide.com
Cc: Madhusudhan Chikkature madhu...@ti.com
Cc: Adrian Hunter adrian.hun...@nokia.com
---
V5:
https://patchwork.kernel.org/patch/106697/
https://patchwork.kernel.org/patch/106698/
V4:
http://www.mail-archive.com/linux-
m...@vger.kernel.org/msg01958.html
http://www.mail-archive.com/linux-
m...@vger.kernel.org/msg01949.html
arch/arm/mach-omap2/board-4430sdp.c | 7 +++-
drivers/mfd/twl6030-irq.c | 76
+++
drivers/mmc/host/omap_hsmmc.c | 4 +-
include/linux/i2c/twl.h | 16 +++
4 files changed, 100 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index f287461..388b96d 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct
device *dev)
struct omap_mmc_platform_data *pdata = dev-platform_data;
/* Setting MMC1 Card detect Irq */
- if (pdev-id == 0)
+ if (pdev-id == 0) {
+ ret = twl6030_mmc_card_detect_config();
+ if (ret)
+ pr_err(Failed configuring MMC1 card detect\n);
pdata-slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+ pdata-slots[0].card_detect = twl6030_mmc_card_detect;
+ }
return ret;
}
diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..c027692 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -36,6 +36,7 @@
#include linux/irq.h
#include linux/kthread.h
#include linux/i2c/twl.h
+#include linux/platform_device.h
/*
* TWL6030 (unlike its predecessors, which had two level interrupt
handling)
@@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from
Phoenix */
+ if (twl_class_is_6030()) {
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+
REG_INT_MSK_LINE_B);
+ twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+
REG_INT_MSK_STS_B);
+ }
+
+ /*
+ * Intially Configuring MMC_CTRL for receving interrupts
+ * Card status on TWL6030 for MMC1
+ */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read MMCCTRL, error %d\n,
ret);
+ return ret;
+ }
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
TWL6030_MMCCTRL);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to write MMCCTRL, error %d\n,
ret);
+ }
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+
TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ return ret;
+ pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error
%d\n,
+
ret);
+ }
+ reg_val = ~(MMC_PU | MMC_PD);
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
+
TWL6030_CFG_INPUT_PUPD3);
+ if (ret 0) {
+ pr_err(twl6030: Failed
RE: [PATCH v2] omap hsmmc: fix processing of all dma interrupts as block completion
-Original Message-
From: Venkatraman S [mailto:svenk...@ti.com]
Sent: Friday, July 16, 2010 4:21 AM
To: linux-mmc
Cc: linux-omap; Venkatraman S; Madhusudhan Chikkature; Andrew Morton
Subject: [PATCH v2] omap hsmmc: fix processing of all dma interrupts as
block completion
If other informative interrupts are enabled for
the DMA channel used by hsmmc, those are incorrectly
treated as block completion. This patch lets only the
block completion interrupt to be processed.
Signed-off-by: Venkatraman S svenk...@ti.com
CC: Madhusudhan Chikkature madhu...@ti.com
CC: Andrew Morton a...@linux-foundation.org
---
It looks like a valid case to fix.
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Changes since v1: better commit log message
drivers/mmc/host/omap_hsmmc.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index b032828..d2901f8 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1273,8 +1273,11 @@ static void omap_hsmmc_dma_cb(int lch, u16
ch_status, void *cb_data)
struct mmc_data *data = host-mrq-data;
int dma_ch, req_in_progress;
- if (ch_status OMAP2_DMA_MISALIGNED_ERR_IRQ)
- dev_dbg(mmc_dev(host-mmc), MISALIGNED_ADRS_ERR\n);
+ if (!(ch_status OMAP_DMA_BLOCK_IRQ)) {
+ dev_warn(mmc_dev(host-mmc), unexpected dma status %x\n,
+ ch_status);
+ return;
+ }
spin_lock(host-irq_lock);
if (host-dma_ch 0) {
--
1.6.3.3
--
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
RE: [PATCH 11/15] wireless: wl1271: introduce platform device support
-Original Message- From: Nicolas Pitre [mailto:n...@fluxnic.net] Sent: Wednesday, July 07, 2010 9:03 AM To: Roger Quadros Cc: Hunter Adrian (Nokia-MS/Helsinki); Ohad Ben-Cohen; linux- wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Coelho Luciano (Nokia-MS/Helsinki); a...@linux-foundation.org; San Mehat Subject: Re: [PATCH 11/15] wireless: wl1271: introduce platform device support On Wed, 7 Jul 2010, Roger Quadros wrote: On 07/06/2010 10:51 PM, Hunter Adrian (Nokia-MS/Helsinki) wrote: For eMMC in omap_hsmmc, this is all done via claim_host / release_host which call -enable() / -disable() methods. omap_hsmmc makes use of mmc_power_restore_host() which calls host-bus_ops-power_restore() which is not implemented for SDIO, but for MMC and SD it reinitializes the card. This is IMHO a really bad design. The power control decision has to come from the top, not from the bottom. And certainly not with a U-turn dependency the omap_hsmmc is using. I regret to say this, but the omap_hsmmc driver is becoming a total mess. The host controller driver has to be a dumb interface serving requests from the hardware used by the upper layer stack, not the place where decisions such as power handling should be made. Think of it like an ethernet driver. No ethernet driver in Linux is telling the IP stack when to shut down. The point is that MMC/SD core files were patched to provide this kind of a support. Any controller driver can use that framework today, right?. As an example omap_hsmmc driver was patched and it works fine. Why blame the controller driver for using a support provided by core files? Regards, Madhu Shouldn't the power control intelligence (i.e. when to turn power ON/OFF) lie with the bus drivers? Absolutely! And in the SDIO case that should lie with each function drivers. Please let's stop this omap_hsmmc madness. Nicolas -- 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
RE: [PATCH 05/15] omap: hsmmc: add virtual card detect support
-Original Message- From: Ohad Ben-Cohen [mailto:o...@wizery.com] Sent: Tuesday, July 06, 2010 6:48 AM To: Nicolas Pitre Cc: linux-wirel...@vger.kernel.org; linux-...@vger.kernel.org; linux- o...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; li...@arm.linux.org.uk; Chikkature Rajashekar Madhusudhan; Luciano Coelho; Andrew Morton; San Mehat; Pandita, Vikram Subject: Re: [PATCH 05/15] omap: hsmmc: add virtual card detect support On Tue, Jul 6, 2010 at 1:22 PM, Ohad Ben-Cohen o...@wizery.com wrote: Note: the wl1271 device does support standard card detection, but AFAIK there's a limitation to use that with the specific omap controller the device is hardwired to. I will try to get more info about that, but probably Madhu can comment on that better. Some correction and additional info: The wl1271 device has an issue which makes the standard card detect mechanism irrelevant: it is always up, even if the power enable gpio input of the device is down (the power enable input does not supply the power to the chip, it's just logical digital high/low input upon which the device reacts). That's why we must use software control for emulating card detect with that device. In addition, as far as I could find out, the card detect mechanism on the ZOOM is implemented by mechanical means, and thus is not relevant for hardwired embedded SDIO devices (I'm not even sure card detect is supported for the 3rd mmc controller). The card detect is supported through T2 GPIO interrupts only for MMC1 and MMC2. Such a mechanism is not present for MMC3 to which the WLAN chip is hardwired. Regards, Madhu -- 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
RE: simple sd card performance bug fix on OMAP
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, June 10, 2010 1:36 AM To: Madhusudhan Cc: 'Gadiyar, Anand'; 'Stephen Schwarm, CSDP'; linux-omap@vger.kernel.org Subject: Re: simple sd card performance bug fix on OMAP * Madhusudhan madhu...@ti.com [100602 20:13]: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Friday, May 28, 2010 2:55 PM To: Stephen Schwarm, CSDP; linux-omap@vger.kernel.org Subject: RE: simple sd card performance bug fix on OMAP Stephen Schwarm, CSDP wrote: I have not had time to make a formal patch for this but I thought it was significant enough just to send it out. The problem is on omap systems that use omap_hsmmc.c to run sd or mmc cards. If the system you are using has an 8 wire interface, it will only use a one wire interface to 4 wire cards (eg, sd class 4 and sd class 6). In the file driver/mmc/omap_hsmmc.c in the function omap_hsmmc_probe: at about line 1739 change: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; to: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) mmc-caps |= w; just delete the word else. This sets the MMC_CAP_4_BIT_DATA bit on interfaces that have 8 wire interfaces. We have seen a BIG performance improvement on our systems. Thanks for reporting this. A similar patch was posted a while ago and is currently marked as awaiting upstream, although it looks like it got lost again. https://patchwork.kernel.org/patch/78713/ A revised version of the same patch was posted. https://patchwork.kernel.org/patch/93519/ Tony, Can you please push this? This needs to get merged via linux-mmc list. Sure. We will repost it. Regards, Madhu Regards, Tony -- 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
RE: simple sd card performance bug fix on OMAP
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Gadiyar, Anand Sent: Friday, May 28, 2010 2:55 PM To: Stephen Schwarm, CSDP; linux-omap@vger.kernel.org Subject: RE: simple sd card performance bug fix on OMAP Stephen Schwarm, CSDP wrote: I have not had time to make a formal patch for this but I thought it was significant enough just to send it out. The problem is on omap systems that use omap_hsmmc.c to run sd or mmc cards. If the system you are using has an 8 wire interface, it will only use a one wire interface to 4 wire cards (eg, sd class 4 and sd class 6). In the file driver/mmc/omap_hsmmc.c in the function omap_hsmmc_probe: at about line 1739 change: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; to: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) mmc-caps |= w; just delete the word else. This sets the MMC_CAP_4_BIT_DATA bit on interfaces that have 8 wire interfaces. We have seen a BIG performance improvement on our systems. Thanks for reporting this. A similar patch was posted a while ago and is currently marked as awaiting upstream, although it looks like it got lost again. https://patchwork.kernel.org/patch/78713/ A revised version of the same patch was posted. https://patchwork.kernel.org/patch/93519/ Tony, Can you please push this? Regards, Madhu - Anand -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: simple sd card performance bug fix on OMAP
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Stephen Schwarm, CSDP Sent: Friday, May 28, 2010 2:05 PM To: linux-omap@vger.kernel.org Subject: simple sd card performance bug fix on OMAP I have not had time to make a formal patch for this but I thought it was significant enough just to send it out. The problem is on omap systems that use omap_hsmmc.c to run sd or mmc cards. If the system you are using has an 8 wire interface, it will only use a one wire interface to 4 wire cards (eg, sd class 4 and sd class 6). A patch to fix this was already posted on LO by Kishore. Regards, Madhu In the file driver/mmc/omap_hsmmc.c in the function omap_hsmmc_probe: at about line 1739 change: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; to: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) mmc-caps |= w; just delete the word else. This sets the MMC_CAP_4_BIT_DATA bit on interfaces that have 8 wire interfaces. We have seen a BIG performance improvement on our systems. Steve Schwarm -- 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
RE: [PATCH v4 0/5] Adding MMC Support on OMAP4430 SDP
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Tuesday, May 18, 2010 7:09 PM To: kishore kadiyala Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; madhu...@ti.com; jarkko.lavi...@nokia.com; r...@arm.linux.org.uk; p...@pwsan.com; santosh.shilim...@ti.com Subject: Re: [PATCH v4 0/5] Adding MMC Support on OMAP4430 SDP * Tony Lindgren t...@atomide.com [100517 19:45]: Hi, * kishore kadiyala kishore.kadiy...@ti.com [100515 11:15]: Adding MMC1 and MMC2 controllers support for OMAP4 V4: - Rebased to for_next branch[LO]. - The first 3 patches [1,2,3] in the series are Minimal set of changes with which MMC1/MMC2 works [No card detect for MMC1]on OMAP4 but with dependencies on following patches [Not in for_next branch] [1] I2c patches a)https://patchwork.kernel.org/patch/98937/ b)https://patchwork.kernel.org/patch/98936/ c)https://patchwork.kernel.org/patch/98939/ d)https://patchwork.kernel.org/patch/79735/ I've taken the updated versions of the I2C patches, and fixed them not to break omap3_defconfig. [2] Regulator pacth a)https://patchwork.kernel.org/patch/94054/ [3] hsmmc-clk patch a)https://patchwork.kernel.org/patch/96821/ I've picked up these too. - The patches 4,5 adds card detect feature for MMC1 I only took 1 - 3 out of the MMC patches, it's too late to start changing the other stuff. I've reposted the whole series for a quick review. FYI, the MMC on omap4 is not quite there yet at least on my board. It mostly detects the card with omap_4430sdp_defconfig, but fails always unless CONFIG_RTC_DRV_TWL92330=y.. This is without CONFIG_SMP as it oopses. I did try the omap_4430sdp_defconfig on the master branch. On my SDP the MMC cards were detected fine without any dependency on CONFIG_RTC_DRV_TWL92330. Regards, Madhu Also MMC is never detected with omap3_defconfig. Santosh Kishore, maybe take a look at that, otherwise it looks like we still don't have a very usable support for omap4. I've piled all these patches into linux-omap master branch for easy testing. Let me know if I missed some patch. Regards, Tony -- 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
RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
-Original Message- From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com] Sent: Thursday, May 06, 2010 11:52 PM To: Chikkature Rajashekar, Madhusudhan; 'kishore kadiyala' Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk; 'Adrian Hunter'; Kadiyala, Kishore; 'Tony Lindgren' Subject: RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature -Original Message- From: Chikkature Rajashekar, Madhusudhan Sent: Thursday, May 06, 2010 9:50 PM To: Shilimkar, Santosh; 'kishore kadiyala' Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux- m...@vger.kernel.org; linux-arm- ker...@lists.arm.linux.org.uk; 'Adrian Hunter'; Kadiyala, Kishore; 'Tony Lindgren' Subject: RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature -Original Message- From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com] Sent: Thursday, May 06, 2010 4:39 AM To: kishore kadiyala Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux- m...@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore; Tony Lindgren Subject: RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature -Original Message- From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] Sent: Thursday, May 06, 2010 2:32 PM To: Shilimkar, Santosh Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux- m...@vger.kernel.org; linux-arm- ker...@lists.arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore; Tony Lindgren Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature snip I am not clear about the method. The board files export the omap_mmc_platform_data. Does it imply that all board files have to change and export the capability so that it can be queried ? No. You don't have to modify the board files. This would need change in devices.c which common for all omap boards. I don't have a strong opinion on this point but just put forth an alternate way to avoid such SOC specific check in drivers. You can take call on this Agree. How about adding a flag in hsmmc.h omap_mmc_platform_data, that would take care of SDMA SDMA_DLAOD in the driver instead going with SOC check . Good idea Kishore. Venkat, Can you do what kishore is suggesting. omap_mmc_platform_data is MMC specific platform data. Why add a SDMA specific feature capability into it? Even though you add it there, you will still need to have a cpu check before that can be set in a common code. CPU checks are allowed to be in the platform files. That is where such machine/SOC specific differentiation should be done and not in the device drivers. That way device drivers remains clean and portable. I want to stop this thread here since neither the patch author nor the file maintainer thinks that cpu checks in the device drivers is bad idea. Please decide within yourself and move on. I am not saying that it is wrong. My point here is that adding this particular flag into MMC platform data to differentiate a SDMA specific feature which got introduced post certain SOC may not be needed. But you can always post your comments on the list which will be looked at by a wider audience and finally the right patch will go in. Regards, Santosh -- 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
RE: [PATCH] Disable the non working eMMC on Zoom2/3
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Thursday, May 06, 2010 10:31 AM To: Madhusudhan Cc: 'Nishanth Menon'; 'Ghorai, Sukumar'; linux-omap@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 * Madhusudhan madhu...@ti.com [100505 18:31]: -Original Message- From: Tony Lindgren [mailto:t...@atomide.com] And what about this Simulate multi mmc card as one big patch? Did not get you, what patch are you referring to? Oops sorry forgot the link: https://patchwork.kernel.org/patch/87944/ This will not help. I don't know the history of the patch but what this is intended for is to support multiple MMC cards connected to a single controller. But on the Zoom the eMMC we are talking about is connected to MMC2. Regards, Madhu Tony -- 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
RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
snip omap_mmc_platform_data is MMC specific platform data. Why add a SDMA specific feature capability into it? Even though you add it there, you will still need to have a cpu check before that can be set in a common code. CPU checks are allowed to be in the platform files. That is where such machine/SOC specific differentiation should be done and not in the device drivers. That way device drivers remains clean and portable. I want to stop this thread here since neither the patch author nor the file maintainer thinks that cpu checks in the device drivers is bad idea. Please decide within yourself and move on. I am not saying that it is wrong. My point here is that adding this particular flag into MMC platform data to differentiate a SDMA specific feature which got introduced post certain SOC may not be needed. But you can always post your comments on the list which will be looked at by a wider audience and finally the right patch will go in. Please see [1] for SOC specific feature handling. any reasons we can't handle it by adding a new feature? [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux- 2.6.git;a=blob;f=arch/arm/plat-omap/include/plat/cpu.h#l439 Yes that makes correct sense. Note that these features will exist on omap4 also so handle in a common way. Surely this will be better than adding a flag which does not belong to MMC platform data. Regards, Madhu -- Regards, Nishanth Menon -- 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
RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature
-Original Message- From: Shilimkar, Santosh [mailto:santosh.shilim...@ti.com] Sent: Thursday, May 06, 2010 4:39 AM To: kishore kadiyala Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux-...@vger.kernel.org; linux-arm-ker...@lists.arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore; Tony Lindgren Subject: RE: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature -Original Message- From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] Sent: Thursday, May 06, 2010 2:32 PM To: Shilimkar, Santosh Cc: S, Venkatraman; linux-omap@vger.kernel.org; linux- m...@vger.kernel.org; linux-arm- ker...@lists.arm.linux.org.uk; Chikkature Rajashekar, Madhusudhan; Adrian Hunter; Kadiyala, Kishore; Tony Lindgren Subject: Re: [PATCH v8 2/2] omap hsmmc: adaptation of sdma descriptor autoloading feature snip I am not clear about the method. The board files export the omap_mmc_platform_data. Does it imply that all board files have to change and export the capability so that it can be queried ? No. You don't have to modify the board files. This would need change in devices.c which common for all omap boards. I don't have a strong opinion on this point but just put forth an alternate way to avoid such SOC specific check in drivers. You can take call on this Agree. How about adding a flag in hsmmc.h omap_mmc_platform_data, that would take care of SDMA SDMA_DLAOD in the driver instead going with SOC check . Good idea Kishore. Venkat, Can you do what kishore is suggesting. omap_mmc_platform_data is MMC specific platform data. Why add a SDMA specific feature capability into it? Even though you add it there, you will still need to have a cpu check before that can be set in a common code. Regards, Santosh -- 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
RE: [PATCH v8 0/2] sDMA descriptor autoloading feature
-Original Message- From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of Venkatraman S Sent: Thursday, April 29, 2010 12:35 PM To: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; linux-arm- ker...@lists.infradead.org Cc: Madhusudhan Chikkature; Tony Lindgren; Adrian Hunter; Santosh Shilimkar Subject: [PATCH v8 0/2] sDMA descriptor autoloading feature This patch series is the introduction of new sDMA feature: descriptor autoloading (v8) and it's adoption by the OMAP HSMMC driver. The previous version (v7) was blocked on achieving proper interrupt syncronisation between the MMC and DMA callback in the HSMMC driver. Thanks to Adrian Hunter's patch, https://patchwork.kernel.org/patch/94670/ this has been cleaned up. Current version is based on for-next branch + Adrian Hunter's interrupt syncronisation patch (https://patchwork.kernel.org/patch/94670) Changes since v7: * Removed the 'fix race condition between DMA and HSMMC callback' part of the series * Added memory barries in start and resume sglist transfer for cpu buffer syncronization * Cleanup and comments This has been tested on OMAP3430, OMAP3630 and OMAP4430 SDP for MMC file transfer and as boot file system. The HSMMC driver changes look good to me. I can ACK that but am not a DMA expert to review your changes to the DMA driver. Venkatraman S: sDMA: descriptor autoloading feature MMC: omap hsmmc adoption of descriptor autoloading feature arch/arm/plat-omap/dma.c | 289 - arch/arm/plat-omap/include/plat/dma.h | 170 +++ drivers/mmc/host/omap_hsmmc.c | 148 ++--- 3 files changed, 583 insertions(+), 24 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
RE: [PATCH] Disable the non working eMMC on Zoom2/3
snip Hmm, finally got around looking into this again. Looks like the mmc is now working on my zoom3 with the current Linus' tree at commit 7c6bd2010fced38444c9fd658f4c6ce61bd185bf. So I guess something that we had in omap-fixes fixed this. Or maybe some fix for drivers/mmc? This is with the debug_ll patch applied: https://patchwork.kernel.org/patch/87532/ For the microSD card, turns out the card I used was flakey. So that should explain some of the problems. I'm almost certain I tried with two different cards earlier though. In any case, let's assume the problem is only the eMMC. Sorry, I did not get a complete picture. Your earlier email said that with Linus tree eMMC on your Zoom3 is working. Is that correct? Nope, now the microSD is working, eMMC is not working. IMHO, an omap level fix can not solve the problem with eMMC because as I can see from the log you provided above that a 16G device is detected as 1G. This is certainly due to the issue I mentioned earlier. OK This means that some production boards still have this issue with eMMC. So my patch disables the support for MMC2 on zoom boards. Would you consider that? Regards, Madhu Tony -- 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
RE: [PATCH] Disable the non working eMMC on Zoom2/3
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, April 28, 2010 2:23 PM To: Madhusudhan Cc: 'Nishanth Menon'; 'Ghorai, Sukumar'; linux-omap@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 * Tony Lindgren t...@atomide.com [100427 11:16]: * Madhusudhan madhu...@ti.com [100408 10:07]: Tony, do you care to just look up the serial number of your board? Sorry for the delay in replying, I've been travelling for a few weeks and been in meetings quite a bit. Anyways, it's a 1013037 REV A board, which seems to be production in the table above. That means we can not assume all production units have a working eMMC. Would you mind sharing your bootup log? When this device is detected something like below is a clear issue. mmcblk1: mmc1:0001 STM16G 1.00 GiB mmcblk1: p1 p2 For the eMMC I seem to have that: [0.978363] mmc1: new high speed MMC card at address 0001 [0.984344] mmcblk1: mmc1:0001 STM16G 1.00 GiB [0.989105] mmcblk1: unknown partition table ... zoom:~# fdisk -l /dev/mmcblk1 [ 120.306396] mmcblk1: retrying using single block read [ 120.503692] mmcblk1: retrying using single block read [ 120.683593] mmcblk1: error -110 transferring data, sector 2097144, nr 8, card status 0x900 [ 120.691894] end_request: I/O error, dev mmcblk1, sector 2097144 [ 120.872680] mmcblk1: error -110 transferring data, sector 2097145, nr 7, card status 0x900 ... Hmm, finally got around looking into this again. Looks like the mmc is now working on my zoom3 with the current Linus' tree at commit 7c6bd2010fced38444c9fd658f4c6ce61bd185bf. So I guess something that we had in omap-fixes fixed this. Or maybe some fix for drivers/mmc? This is with the debug_ll patch applied: https://patchwork.kernel.org/patch/87532/ For the microSD card, turns out the card I used was flakey. So that should explain some of the problems. I'm almost certain I tried with two different cards earlier though. In any case, let's assume the problem is only the eMMC. Sorry, I did not get a complete picture. Your earlier email said that with Linus tree eMMC on your Zoom3 is working. Is that correct? IMHO, an omap level fix can not solve the problem with eMMC because as I can see from the log you provided above that a 16G device is detected as 1G. This is certainly due to the issue I mentioned earlier. Regards, Madhu Regards, Tony -- 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
RE: [PATCH v2] omap_hsmmc: improve interrupt synchronisation
-Original Message-
From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of
Venkatraman S
Sent: Monday, April 26, 2010 4:01 AM
To: Adrian Hunter
Cc: Madhusudhan Chikkature; linux-mmc Mailing List; linux-omap Mailing
List
Subject: Re: [PATCH v2] omap_hsmmc: improve interrupt synchronisation
Adrian Hunter adrian.hun...@nokia.com wrote:
From ad2e1cd024ccf9144b6620cfe808893719db738f Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Wed, 14 Apr 2010 16:26:45 +0300
Subject: [PATCH] omap_hsmmc: improve interrupt synchronisation
The following changes were needed:
- do not use in_interrupt() because it will not work
with threaded interrupts
In addition, the following improvements were made:
- ensure DMA is unmapped only after the final DMA interrupt
- ensure a request is completed only after the final DMA
interrupt
- disable controller interrupts when a request is not in progress
- remove the spin-lock protecting the start of a new request from
an unexpected interrupt because the locking was complicated and
a 'req_in_progress' flag suffices (since the spin-lock only
defers
the unexpected interrupts anyway)
- instead use the spin-lock to protect the MMC interrupt handler
from the DMA interrupt handler
- remove the semaphore preventing DMA from being started while
the previous DMA is still in progress - the other changes make
that
impossible, so it is now a BUG_ON condition
- ensure the controller interrupt status is clear before exiting
the interrrupt handler
In general, these changes make the code safer but do not fix any
specific
bugs so backporting is not necessary.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
Changes from version 1:
- use a spin-lock to protect the MMC interrupt handler
from the DMA interrupt handler
- use do {} while loop instead of goto in omap_hsmmc_irq
S Venkatraman's request to use omap_hsmmc_dma_cleanup(host, 0) in
omap_hsmmc_dma_cb() was not done because the code was not
sufficiently the same.
snip
This looks good and I don't have any other comments.
I have tested, on MMC and SD cards which I have,
a) Basic file read / write
b) boot with filesystem on ext3 partition on SD card
on OMAP3 and OMAP4 SDP.
So you can add,
Tested-by: Venkatraman S svenk...@ti.com
I reviewed the V2 patch. I dont have any comments too.
Acked-by: Madhusudhan Chikkature madhu...@ti.com
--
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
RE: [PATCH 3/7] OMAP4-HSMMC: Adding Card detect support
-Original Message-
From: Tony Lindgren [mailto:t...@atomide.com]
Sent: Wednesday, April 21, 2010 2:08 PM
To: kishore kadiyala
Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org;
madhu...@ti.com; jarkko.lavi...@nokia.com; rmk+l...@arm.linux.org.uk;
santosh.shilim...@ti.com
Subject: Re: [PATCH 3/7] OMAP4-HSMMC: Adding Card detect support
* kishore kadiyala kishore.kadiy...@ti.com [100421 11:16]:
Since OMAP4's card detection doesn't support GPIO,this patch
basically moves card detection API from driver to Board file so
that it can handle in both GPIO and NON-GPIO case.
This Patch also adds a flag which can differentiate whether the
card-detect line is GPIO or NON-GPIO.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |1 +
arch/arm/mach-omap2/hsmmc.c | 74
+
arch/arm/mach-omap2/hsmmc.h |1 +
arch/arm/plat-omap/include/plat/mmc.h |3 +-
drivers/mmc/host/omap_hsmmc.c | 29 +---
5 files changed, 81 insertions(+), 27 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-
omap2/board-4430sdp.c
index eae7c80..4e8f74e 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -89,6 +89,7 @@ static struct omap2_hsmmc_info mmc[] = {
* but is a phoenix interrupt
*/
.gpio_cd= 384,
+ .cd_type= true,
.gpio_wp= -EINVAL,
},
{
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 9ad2295..ca3d4c9 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -13,6 +13,8 @@
#include linux/slab.h
#include linux/string.h
#include linux/delay.h
+#include linux/gpio.h
+#include linux/i2c/twl.h
#include mach/hardware.h
#include plat/control.h
#include plat/mmc.h
@@ -27,7 +29,11 @@ static u16 control_devconf1_offset;
#define HSMMC_NAME_LEN 9
+/* Phoenix Registers */
+#define TWL6030_MMCCTRL0xEE
This define belongs to the twl code.
static struct hsmmc_controller {
+ struct omap_mmc_platform_data *mmc;
charname[HSMMC_NAME_LEN + 1];
} hsmmc[OMAP34XX_NR_MMC];
@@ -42,6 +48,50 @@ static int hsmmc_get_context_loss(struct device *dev)
#define hsmmc_get_context_loss NULL
#endif
+static int twl_mmc_get_cover_state(struct device *dev, int slot)
+{
+ struct omap_mmc_platform_data *mmc = dev-platform_data;
+
+ /* NOTE: assumes card detect signal is active-low */
+ return !gpio_get_value_cansleep(mmc-slots[0].switch_pin);
+}
+
+static int twl_mmc_card_detect(int irq)
+{
+ unsigned i;
+ u8 read_reg;
+ unsigned res;
+
+
+ for (i = 0; i ARRAY_SIZE(hsmmc); i++) {
+ struct omap_mmc_platform_data *mmc;
+
+ mmc = hsmmc[i].mmc;
+ if (!mmc)
+ continue;
+ if (irq != mmc-slots[0].card_detect_irq)
+ continue;
+
+ if (mmc-slots[0].nongpio_cd) {
+ /* BIT0 of REG_MMC_CTRL
+* 0 - Card not present
+* 1 - Card present
+*/
+ res = twl_i2c_read_u8(TWL6030_MODULE_ID0,
+ read_reg, TWL6030_MMCCTRL);
+ if (res = 0)
+ return read_reg 0x1;
+ return !gpio_get_value_cansleep
+ (mmc-slots[0].switch_pin);
+ } else {
+ /* NOTE: assumes card detect signal is active-low */
+ return !gpio_get_value_cansleep
+ (mmc-slots[0].switch_pin);
+ }
+ }
+ return -ENOSYS;
+}
You should just register a separate twl_card_detect function during init
instead of doing these tests over and over again.
I agree. Additionally it would make sense to limit the hsmmc.c file with the
current functionality and create a new file which could get compiled for
4430 specific boards. It would be clean and will avoid brining any twl6030
specific code into hsmmc.c.
static void hsmmc1_before_set_reg(struct device *dev, int slot,
int power_on, int vdd)
{
@@ -189,8 +239,32 @@ void __init omap2_hsmmc_init(struct
omap2_hsmmc_info
mmc-get_context_loss_count = hsmmc_get_context_loss;
mmc-slots[0].switch_pin = c-gpio_cd;
+ mmc-slots[0].nongpio_cd = c-cd_type;
mmc-slots[0].gpio_wp = c-gpio_wp;
+ /* TWL Card detect can be GPIO based or NON-GPIO Based */
+ if (!c-cd_type) {
+ if (gpio_is_valid(c-gpio_cd)) {
+
RE: [PATCH v4] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message-
From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com]
Sent: Monday, April 19, 2010 10:52 AM
To: Madhusudhan
Cc: Nishanth Menon; felipe.ba...@nokia.com; m...@felipebalbi.com; Vimal
Singh; t...@atomide.com; S, Venkatraman; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; Lavinen Jarkko (Nokia-D/Helsinki)
Subject: [PATCH v4] OMAP: Fix for bus width which improves SD card's
peformance.
The previous patch was Line wrapped , resending
correct patch.
NM, Sorry I miss spelled your name correcting this time.
Regards,
Kishore
Tony,
I don't see any further comments on this patch. Can you please push this
patch?
Regards,
Madhu
From: Kishore Kadiyala kishore.kadiy...@ti.com
This patch improves low speeds for SD cards.
OMAP-MMC controller's can support maximum bus width of '8'.
when bus width is mentioned as 8 in controller data,the SD
stack will check whether bus width is 4 and if not it will
set bus width to 1 and there by degrading performance.
This patch fixes the issue and improves the performance of
SD cards.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
Signed-off-by: Venkatraman S svenk...@ti.com
Signed-off-by: Nishanth Menon n...@ti.com
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Tested-by: Jarkko Nikula jhnik...@gmail.com
---
In V4 : Updated with Nishant's comments and appened his Signed-off
In V3 : Updated with Madhu's comments and appended Tested by Nikula
In V2 : Appended Signed-off by Venkat and Ack by Madhu
Here are my experiment numbers, on a Class 6 SDHC card:
Read peformance is increased by 220%
Write Performance is increased by 52%
drivers/mmc/host/omap_hsmmc.c | 19 ---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8c97c22..9c1a60e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2091,10 +2091,23 @@ static int __init omap_hsmmc_probe(struct
mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED |
MMC_CAP_WAIT_WHILE_BUSY;
- if (mmc_slot(host).wires = 8)
- mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA);
- else if (mmc_slot(host).wires = 4)
+ switch (mmc_slot(host).wires) {
+ case 8:
+ mmc-caps |= MMC_CAP_8_BIT_DATA;
+ /* Fall through */
+ case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
+ break;
+ case 1:
+ /* Nothing to crib here */
+ case 0:
+ /* Assuming nothing was given by board, Core use's 1-Bit */
+ break;
+ default:
+ /* Completely unexpected.. Core goes with 1-Bit Width */
+ dev_crit(mmc_dev(host-mmc), Invalid width %d\n used!
+ using 1 instead\n, mmc_slot(host).wires);
+ }
if (mmc_slot(host).nonremovable)
mmc-caps |= MMC_CAP_NONREMOVABLE;
--
1.6.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap 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] OMAP: Fix for bus width which improves SD card's peformance.
snip
Point noted. try n++:
switch(mmc_slot(host).wires) {
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* Fall through */
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
case 0:
/* assuming nothing was given by board, use 1 */
case 1:
/* nothing to crib here */
break;
default:
/* Completely unexpected.. try 1 bit instead */
dev_crit(mmc_dev(host-mmc), Invalid width %d
used! using 1 instead\n,
mmc_slot(host).wires);
}
note: we should crib if the board file made a mistake here.. say it gave
10 wire or so.. I agree that we can recover by stepping back to 1 bit
mode.. but we gotta tell the log that something aint right..
Sure. It looks fine to me now.
Regards,
Madhu
--
Regards,
Nishanth Menon
--
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
RE: [PATCH] Disable the non working eMMC on Zoom2/3
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, April 07, 2010 6:50 AM To: Madhusudhan Cc: 'Nishanth Menon'; 'Ghorai, Sukumar'; linux-omap@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 * Madhusudhan madhu...@ti.com [100401 15:54]: snip Ref [1] I believe tony has the brand new zoom board - I think your assumption here might be flawed.. Wait, I just looked up the serial number on the board. The one I was using is a pilot version where this problem exists. I happen to get an other board which is production unit with ser # 1013089 Rev B. The eMMC on this board has no issue. It reports the EXT_CSD Rev 2 which is correct and works fine. http://omappedia.org/wiki/Zoom_Resources There is a table here which could help. Tony, do you care to just look up the serial number of your board? Sorry for the delay in replying, I've been travelling for a few weeks and been in meetings quite a bit. Anyways, it's a 1013037 REV A board, which seems to be production in the table above. That means we can not assume all production units have a working eMMC. Would you mind sharing your bootup log? When this device is detected something like below is a clear issue. mmcblk1: mmc1:0001 STM16G 1.00 GiB mmcblk1: p1 p2 Regards, Madhu But again there are several boards out there which could have this non-working eMMC. So what do we do?? It does not make sense to keep something enabled which does not work. There's arm kernel parameter for ATAG_REVISION that can be passed from bootloader and then the board-*.c code can initialize things accordingly based on the board revision. Regards, Tony [1] http://marc.info/?l=linux-omapm=126938456103707w=2 -- 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
RE: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Tuesday, April 06, 2010 12:01 AM To: Madhusudhan Cc: m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh'; t...@atomide.com; svenk...@ti.com; linux-omap@vger.kernel.org; linux- ker...@vger.kernel.org; jarkko.lavi...@nokia.com Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance. Hi, On Mon, Apr 05, 2010 at 12:19:29PM -0500, Madhusudhan wrote: Since the first if command already checks for the 8-bit the second check like = 4 is definitely not readable in my opinion. how come ??? Functionally do you see anything wrong with this patch?? functionally no, but (hypothetical situation) and if on omap4/5/6/whatever, omap controller supports a bigger bus width then you'll have to add a line like: + if (mmc_slot(host).wires == 16) + mmc-caps |= (MMC_CAP_16_BIT_DATA | MMC_CAP_8_BIT_DATA | + MMC_CAP_4_BIT_DATA); - if (mmc_slot(host).wires == 8) + else if (mmc_slot(host).wires == 8) do you see the problem ?? In my opinion it doesn't scale well. The point we should note here is that MMC spec supports a max bus width of 8-bit. So anything beyond 8-bit is not in the picture as of today. But, my bad on miss interpreting the snippet Felipe sent earlier. if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; I missed the fact that you removed the setting of 4-bit from the first check. I am okay with the above snippet as it is a trivial change that we are trying to patch here which fixes an important issue. Regards, Madhu -- balbi -- 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
RE: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Tuesday, April 06, 2010 11:57 AM
To: ext Nishanth Menon
Cc: Balbi Felipe (Nokia-D/Helsinki); Chikkature Rajashekar, Madhusudhan;
m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh'; t...@atomide.com;
S, Venkatraman; linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org;
Lavinen Jarkko (Nokia-D/Helsinki)
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's
peformance.
On Tue, Apr 06, 2010 at 06:55:03PM +0200, ext Nishanth Menon wrote:
some reasons why i love switch statements ;) since I dont expect other
than precisely 4 and 8 (do we expect 5,6,7 - i might be wrong).. but if
it is so, wont the following be better?
switch (mmc_slot(host).wires)
{
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* fall thru*/
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
default:
WARN(bad width);
}
I like that, but I remember Madhu (or someone else) saying he thinks
it's less readable this way. Go figure...
Well, I did not comment on the usage of switch here. Note we only need to
handle 8-bit and 4-bit.The board files need not setup 8-bit or 4-bit if the
configuration of that board is 1-bit. The driver will still work in 1-bit
mode which would mean there is nothing to do in default case and should not
err out.
Regards,
Madhu
--
balbi
--
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
RE: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message-
From: Nishanth Menon [mailto:n...@ti.com]
Sent: Tuesday, April 06, 2010 6:39 PM
To: Chikkature Rajashekar, Madhusudhan
Cc: felipe.ba...@nokia.com; m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal
Singh'; t...@atomide.com; S, Venkatraman; linux-omap@vger.kernel.org;
linux-ker...@vger.kernel.org; 'Lavinen Jarkko (Nokia-D/Helsinki)'
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's
peformance.
Chikkature Rajashekar, Madhusudhan had written, on 04/06/2010 06:23 PM,
the following:
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@nokia.com]
Sent: Tuesday, April 06, 2010 11:57 AM
To: ext Nishanth Menon
Cc: Balbi Felipe (Nokia-D/Helsinki); Chikkature Rajashekar,
Madhusudhan;
m...@felipebalbi.com; 'kishore kadiyala'; 'Vimal Singh';
t...@atomide.com;
S, Venkatraman; linux-omap@vger.kernel.org; linux-
ker...@vger.kernel.org;
Lavinen Jarkko (Nokia-D/Helsinki)
Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD
card's
peformance.
On Tue, Apr 06, 2010 at 06:55:03PM +0200, ext Nishanth Menon wrote:
some reasons why i love switch statements ;) since I dont expect other
than precisely 4 and 8 (do we expect 5,6,7 - i might be wrong).. but
if
it is so, wont the following be better?
switch (mmc_slot(host).wires)
{
case 8:
mmc-caps |= MMC_CAP_8_BIT_DATA;
/* fall thru*/
case 4:
mmc-caps |= MMC_CAP_4_BIT_DATA;
break;
default:
WARN(bad width);
}
I like that, but I remember Madhu (or someone else) saying he thinks
it's less readable this way. Go figure...
Well, I did not comment on the usage of switch here. Note we only need
to
handle 8-bit and 4-bit.The board files need not setup 8-bit or 4-bit if
the
configuration of that board is 1-bit. The driver will still work in 1-
bit
mode which would mean there is nothing to do in default case and should
not
err out.
check the attachment out.. hope that takes care of it.. just as a
reference alone ofcourse..
Nope. The default case is wrong. The assumption followed by controller
drivers is that if the board file says 4-bit or 8-bit set the capabilities
otherwise don't do any thing. The host will continue to work in 1-bit mode
which is a must. Your patch violates that (can not design a board without
connecting one data line at least :))
Also you can not say 1-bit is non-optimal because the board file dictates
the configuration based on what it is capable of. Why through a warning?
It is subjective.
Regards,
Madhu
--
Regards,
Nishanth Menon
--
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
RE: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Monday, April 05, 2010 11:49 AM To: kishore kadiyala Cc: Madhusudhan; Vimal Singh; t...@atomide.com; svenk...@ti.com; linux- o...@vger.kernel.org; linux-ker...@vger.kernel.org; jarkko.lavi...@nokia.com Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance. Hi, On Mon, Apr 05, 2010 at 06:26:16PM +0530, kishore kadiyala wrote: @@ -2091,9 +2091,9 @@ static int __init omap_hsmmc_probe(struct mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED | MMC_CAP_WAIT_WHILE_BUSY; - if (mmc_slot(host).wires = 8) - mmc-caps |= MMC_CAP_8_BIT_DATA; - else if (mmc_slot(host).wires = 4) + if (mmc_slot(host).wires == 8) + mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); + else if (mmc_slot(host).wires == 4) mmc-caps |= MMC_CAP_4_BIT_DATA; I believe it would be enough to just remove the 'else', so the code would look like: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) Since the first if command already checks for the 8-bit the second check like = 4 is definitely not readable in my opinion. Functionally do you see anything wrong with this patch?? mmc-caps |= MMC_CAP_4_BIT_DATA; -- balbi -- 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
RE: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Madhusudhan Sent: Monday, April 05, 2010 12:19 PM To: m...@felipebalbi.com; 'kishore kadiyala' Cc: 'Vimal Singh'; t...@atomide.com; svenk...@ti.com; linux- o...@vger.kernel.org; linux-ker...@vger.kernel.org; jarkko.lavi...@nokia.com Subject: RE: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance. -Original Message- From: Felipe Balbi [mailto:m...@felipebalbi.com] Sent: Monday, April 05, 2010 11:49 AM To: kishore kadiyala Cc: Madhusudhan; Vimal Singh; t...@atomide.com; svenk...@ti.com; linux- o...@vger.kernel.org; linux-ker...@vger.kernel.org; jarkko.lavi...@nokia.com Subject: Re: [PATCH v3] OMAP: Fix for bus width which improves SD card's peformance. Hi, On Mon, Apr 05, 2010 at 06:26:16PM +0530, kishore kadiyala wrote: @@ -2091,9 +2091,9 @@ static int __init omap_hsmmc_probe(struct mmc-caps |= MMC_CAP_MMC_HIGHSPEED | MMC_CAP_SD_HIGHSPEED | MMC_CAP_WAIT_WHILE_BUSY; - if (mmc_slot(host).wires = 8) - mmc-caps |= MMC_CAP_8_BIT_DATA; - else if (mmc_slot(host).wires = 4) + if (mmc_slot(host).wires == 8) + mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); + else if (mmc_slot(host).wires == 4) mmc-caps |= MMC_CAP_4_BIT_DATA; I believe it would be enough to just remove the 'else', so the code would look like: if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; if (mmc_slot(host).wires = 4) Since the first if command already checks for the 8-bit the second check like = 4 is definitely not readable in my opinion. Functionally do you see anything wrong with this patch?? Just to clarify my earlier comment on the patch was to resubmit like below: if (mmc_slot(host).wires == 8) mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); if (mmc_slot(host).wires == 4) mmc-caps |= MMC_CAP_4_BIT_DATA; IMHO, this should be good enough. Regards, Madhu mmc-caps |= MMC_CAP_4_BIT_DATA; -- balbi -- 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-omap 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] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message- From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] Sent: Thursday, April 01, 2010 1:32 AM To: Madhusudhan Cc: Vimal Singh; t...@atomide.com; svenk...@ti.com; linux- o...@vger.kernel.org; linux-ker...@vger.kernel.org; jarkko.lavi...@nokia.com Subject: Re: [PATCH-V2] OMAP: Fix for bus width which improves SD card's peformance. On Wed, Mar 31, 2010 at 10:07 PM, Madhusudhan madhu...@ti.com wrote: -Original Message- From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] Sent: Wednesday, March 31, 2010 2:03 AM To: Vimal Singh Cc: Madhusudhan; t...@atomide.com; svenk...@ti.com; linux- o...@vger.kernel.org; linux-ker...@vger.kernel.org; jarkko.lavi...@nokia.com Subject: Re: [PATCH-V2] OMAP: Fix for bus width which improves SD card's peformance. Sorry for that and here's the Updated one. From: Kishore Kadiyala kishore.kadiy...@ti.com This patch improves low speeds for SD cards. OMAP-MMC controller's can support maximum bus width of '8'. when bus width is mentioned as 8 in controller data,the SD stack will check whether bus width is 4 and if not it will set bus width to 1 and there by degrading performance. This patch fixes the issue and improves the performance of SD cards. Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com Signed-off-by: Venkatraman S svenk...@ti.com Acked-by: Madhusudhan Chikkature madhu...@ti.com --- In V2 : Appended Signed-off by Venkat and Ack by Madhu Here are my experiment numbers, on a Class 6 SDHC card: Read peformance is increased by 220% Write Performance is increased by 52% drivers/mmc/host/omap_hsmmc.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 83f0aff..8c97c22 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2092,7 +2092,7 @@ static int __init omap_hsmmc_probe(struct MMC_CAP_WAIT_WHILE_BUSY; if (mmc_slot(host).wires = 8) - mmc-caps |= MMC_CAP_8_BIT_DATA; + mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; Kishore, Since this patch is not yet pushed it makes sense to fix the readability issue. Since 8-bit is the max how about: if (mmc_slot(host).wires == 8) mmc-caps |= MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA; if (mmc_slot(host).wires == 4) mmc-caps |= MMC_CAP_4_BIT_DATA; Madhu, In the above snippet, it checks whether wires are 8 or 4 and if not neither set's capability to 1. Does it make sense to check whether the wires are 8,4,1 and if not any[8,4,1] throw error and come out. It is good enough to just check for 8-bit and 4-bit. The 1-bit does not need any explicit check since it is default. Regards, Madhu Regards, Kishore This would be little easy to read the code. Can you please repost the patch?? Regards, Madhu -- 1.6.3.3 -- 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
RE: [PATCH] Disable the non working eMMC on Zoom2/3
-Original Message-
From: Ghorai, Sukumar [mailto:s-gho...@ti.com]
Sent: Wednesday, March 31, 2010 11:03 PM
To: Chikkature Rajashekar, Madhusudhan; t...@atomide.com
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Subject: RE: [PATCH] Disable the non working eMMC on Zoom2/3
Madhu,
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Chikkature Rajashekar, Madhusudhan
Sent: 2010-04-01 05:56
To: t...@atomide.com
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Subject: [PATCH] Disable the non working eMMC on Zoom2/3
From: Madhusudhan Chikkature madhu...@ti.com
Date: Wed, 31 Mar 2010 12:29:19 -0400
Subject: [PATCH] Zoom2/3: Disable MMC
The eMMC on Zoom2/3 seems to have a lower EXT_CSD Rev.This causes the
writes to fail since the card size is not detected correctly by the MMC
core. Disable the MMC2 support for Zoom2/3.
[Ghorai] Please let us know the EXT_CSD Rev you see in zoom3 and the exact
problem. Because we never face any issue for eMMC in ZOOM3. Because we
have the same eMMC device in 3630-SDP and could have the same problem.
On Zoom3 the EXT_CSD Rev reported by eMMC is zero. See the log attached.
Hence the failures which are reported by people on the list. I had already
bought this problem up on the list previously and was discussed, right?
From the log you can also see that a 16GB device is detected as a 1GB.
Regards,
Madhu
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 30 ---
--
-
1 files changed, 0 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..ac791d2 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -102,10 +102,6 @@ static struct regulator_consumer_supply
zoom_vsim_supply = {
.supply = vmmc_aux,
};
-static struct regulator_consumer_supply zoom_vmmc2_supply = {
- .supply = vmmc,
-};
-
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -121,21 +117,6 @@ static struct regulator_init_data zoom_vmmc1 = {
.consumer_supplies = zoom_vmmc1_supply,
};
-/* VMMC2 for MMC2 card */
-static struct regulator_init_data zoom_vmmc2 = {
- .constraints = {
- .min_uV = 185,
- .max_uV = 185,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = 1,
- .consumer_supplies = zoom_vmmc2_supply,
-};
-
/* VSIM for OMAP VDD_MMC1A (i/o for DAT4..DAT7) */
static struct regulator_init_data zoom_vsim = {
.constraints = {
@@ -159,15 +140,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_wp= -EINVAL,
.power_saving = true,
},
- {
- .name = internal,
- .mmc= 2,
- .wires = 8,
- .gpio_cd= -EINVAL,
- .gpio_wp= -EINVAL,
- .nonremovable = true,
- .power_saving = true,
- },
{} /* Terminator */
};
@@ -183,7 +155,6 @@ static int zoom_twl_gpio_setup(struct device *dev,
*/
zoom_vmmc1_supply.dev = mmc[0].dev;
zoom_vsim_supply.dev = mmc[0].dev;
- zoom_vmmc2_supply.dev = mmc[1].dev;
return 0;
}
@@ -241,7 +212,6 @@ static struct twl4030_platform_data zoom_twldata = {
.keypad = zoom_kp_twl4030_data,
.codec = zoom_codec_data,
.vmmc1 = zoom_vmmc1,
- .vmmc2 = zoom_vmmc2,
.vsim = zoom_vsim,
};
--
1.6.3.3
--
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
dhcp 0x8000 madhu/uImagelo
LAN9x18 (0x9221) detected.
Read mac address: 00:08:EE:03:2A:5B
start Auto negotiation... (take ~2sec)
Auto negotiation complete, 100BaseTX, full duplex
BOOTP broadcast 1
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
*** Unhandled DHCP Option in OFFER/ACK: 43
*** Unhandled DHCP Option in OFFER/ACK: 44
*** Unhandled DHCP Option in OFFER/ACK: 46
DHCP client bound to address 128.247.79.222
TFTP from server 128.247.75.101; our IP address is 128.247.79.222; sending
through gateway
RE: [PATCH] Disable the non working eMMC on Zoom2/3
-Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Thursday, April 01, 2010 4:59 PM To: Ghorai, Sukumar Cc: Chikkature Rajashekar, Madhusudhan; t...@atomide.com; linux- o...@vger.kernel.org; linux-...@vger.kernel.org Subject: Re: [PATCH] Disable the non working eMMC on Zoom2/3 Ghorai, Sukumar had written, on 04/01/2010 01:34 PM, the following: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Chikkature Rajashekar, Madhusudhan Sent: 2010-04-01 05:56 To: t...@atomide.com Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org Subject: [PATCH] Disable the non working eMMC on Zoom2/3 From: Madhusudhan Chikkature madhu...@ti.com Date: Wed, 31 Mar 2010 12:29:19 -0400 Subject: [PATCH] Zoom2/3: Disable MMC The eMMC on Zoom2/3 seems to have a lower EXT_CSD Rev.This causes the writes to fail since the card size is not detected correctly by the MMC core. Disable the MMC2 support for Zoom2/3. [Ghorai] Please let us know the EXT_CSD Rev you see in zoom3 and the exact problem. Because we never face any issue for eMMC in ZOOM3. Because we have the same eMMC device in 3630-SDP and could have the same problem. On Zoom3 the EXT_CSD Rev reported by eMMC is zero. See the log attached. Hence the failures which are reported by people on the list. I had already bought this problem up on the list previously and was discussed, right? From the log you can also see that a 16GB device is detected as a 1GB. [Ghorai] I feel it's an issue with eMMC in pilot-board. And production- board is working fine. And I feel outside TI people having production board only. And 16GB eMMC device is a very good size to work with different things. Otherwise we are talking about MMC#2 boot, eMMC boot, 16GB eMMC device in zoom,.. all these information in different page/ link looks very misleading information, if really having such problem. I the mean time I will check this in Pilot board too and think you checked in pilot board only. Ref [1] I believe tony has the brand new zoom board - I think your assumption here might be flawed.. Wait, I just looked up the serial number on the board. The one I was using is a pilot version where this problem exists. I happen to get an other board which is production unit with ser # 1013089 Rev B. The eMMC on this board has no issue. It reports the EXT_CSD Rev 2 which is correct and works fine. http://omappedia.org/wiki/Zoom_Resources There is a table here which could help. Tony, do you care to just look up the serial number of your board? But again there are several boards out there which could have this non-working eMMC. So what do we do?? It does not make sense to keep something enabled which does not work. Regards, Madhu -- Regards, Nishanth Menon Ref: [1] http://marc.info/?l=linux-omapm=126938456103707w=2 -- 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
RE: [PATCH-V2] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message- From: kishore kadiyala [mailto:kishorek.kadiy...@gmail.com] Sent: Wednesday, March 31, 2010 2:03 AM To: Vimal Singh Cc: Madhusudhan; t...@atomide.com; svenk...@ti.com; linux- o...@vger.kernel.org; linux-ker...@vger.kernel.org; jarkko.lavi...@nokia.com Subject: Re: [PATCH-V2] OMAP: Fix for bus width which improves SD card's peformance. Sorry for that and here's the Updated one. From: Kishore Kadiyala kishore.kadiy...@ti.com This patch improves low speeds for SD cards. OMAP-MMC controller's can support maximum bus width of '8'. when bus width is mentioned as 8 in controller data,the SD stack will check whether bus width is 4 and if not it will set bus width to 1 and there by degrading performance. This patch fixes the issue and improves the performance of SD cards. Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com Signed-off-by: Venkatraman S svenk...@ti.com Acked-by: Madhusudhan Chikkature madhu...@ti.com --- In V2 : Appended Signed-off by Venkat and Ack by Madhu Here are my experiment numbers, on a Class 6 SDHC card: Read peformance is increased by 220% Write Performance is increased by 52% drivers/mmc/host/omap_hsmmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 83f0aff..8c97c22 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2092,7 +2092,7 @@ static int __init omap_hsmmc_probe(struct MMC_CAP_WAIT_WHILE_BUSY; if (mmc_slot(host).wires = 8) - mmc-caps |= MMC_CAP_8_BIT_DATA; + mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; Kishore, Since this patch is not yet pushed it makes sense to fix the readability issue. Since 8-bit is the max how about: if (mmc_slot(host).wires == 8) mmc-caps |= MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA; if (mmc_slot(host).wires == 4) mmc-caps |= MMC_CAP_4_BIT_DATA; This would be little easy to read the code. Can you please repost the patch?? Regards, Madhu -- 1.6.3.3 -- 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
RE: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3
-Original Message- From: G, Manjunath Kondaiah [mailto:manj...@ti.com] Sent: Wednesday, March 31, 2010 1:11 AM To: Chikkature Rajashekar, Madhusudhan; 'Tony Lindgren'; Pais, Allen Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Pandita, Vikram Subject: RE: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3 Master branch will work fine for omap_zoom3_defconfig. Pls make sure to use ttyS0 in bootargs. Yes. That works. Thanks, Madhu OMAP36XX ZOOM3 # boot LAN9x18 (0x9221) detected. Read mac address: 00:08:EE:03:7D:EE start Auto negotiation... (take ~2sec) Auto negotiation complete, 100BaseTX, full duplex TFTP from server 172.24.136.151; our IP address is 172.24.190.192; sending through gateway 172.24.188.1 Filename 'uImage_zoom3'. Load address: 0x8030 Loading: # # # # # ## done Bytes transferred = 1959780 (1de764 hex) ## Booting image at 8030 ... Image Name: Linux-2.6.34-rc2-07865-g2e51807 Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1959716 Bytes = 1.9 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux... done, booting the kernel. Linux version 2.6.34-rc2-07865-g2e51807 (ma...@u-host) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) ) #5 Wed Mar 31 11:51:19 IST 2010 CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: OMAP Zoom3 board Memory policy: ECC disabled, Data cache writeback OMAP3630 ES1.0 (l2cache iva sgx neon isp 192mhz_clk ) SRAM: Mapped pa 0x4020 to va 0xfe40 size: 0x10 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512 Kernel command line: console=ttyS0,115200n8 root=/dev/nfs rw nfsroot=172.24.136.151:/home/manju/fs/alsa-fs target,nolock,tcp,rsize=1024,wsize=1024 mem=128M ip=dhcp Regards, Manjunath -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Chikkature Rajashekar, Madhusudhan Sent: Wednesday, March 31, 2010 5:05 AM To: 'Tony Lindgren'; Pais, Allen Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Pandita, Vikram Subject: RE: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3 -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, March 23, 2010 10:27 AM To: Pais, Allen Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Pandita, Vikram Subject: Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3 * Pais, Allen allen.p...@ti.com [100322 22:42]: With this patch[DEBUG_LL + earlyprintk], I still haven't been able to boot the kernel. Is it working on your side. The commit am using is : a842b5f9ce70e1b738eabb4d719860070180ed1c I think you will also need the 3630 serial fixes series posted recently. I just merged those into omap-fixes-for-linus (and master) branch(es). Maybe give it a try with at commit b3c7740a120c8a7775cb63b4d094466da5c01692 + this patch? Thanks, I'll pull in those fixes. I believe the mux errors are fixed. Have a look at http://dev.omapzoom.org/?p=manju/kernel-omap3- dev.git;a=commit;h=3499f5023ee90dc6ee3868a3147b87fe22a1d9b7 Patch must have been missed some how. OK, we really should get fixes like that to mainline kernel ASAP to avoid duplicating the effort. Then at least one issue remains for zoom3 to be usable.. I'm getting tons of MMC errors trying to mount root on it: mmcblk1: error -110 transferring data, sector 2097024, nr 8, card status 0x900 end_request: I/O error, dev mmcblk1, sector 2097024 ... Any ideas if that's fixed somewhere also? Tony, What is the branch on which the kernel is built? I tried the master branch and the omap-fixes-for-linus both does not seem to boot Zoom3. Regards, Madhu Regards, Tony -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo
[PATCH] Disable the non working eMMC on Zoom2/3
From: Madhusudhan Chikkature madhu...@ti.com
Date: Wed, 31 Mar 2010 12:29:19 -0400
Subject: [PATCH] Zoom2/3: Disable MMC2
The eMMC on Zoom2/3 seems to have a lower EXT_CSD Rev.This causes the
writes to fail since the card size is not detected correctly by the MMC
core. Disable the MMC2 support for Zoom2/3.
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 30 --
1 files changed, 0 insertions(+), 30 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 6b39849..ac791d2 100644
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -102,10 +102,6 @@ static struct regulator_consumer_supply zoom_vsim_supply =
{
.supply = vmmc_aux,
};
-static struct regulator_consumer_supply zoom_vmmc2_supply = {
- .supply = vmmc,
-};
-
/* VMMC1 for OMAP VDD_MMC1 (i/o) and MMC1 card */
static struct regulator_init_data zoom_vmmc1 = {
.constraints = {
@@ -121,21 +117,6 @@ static struct regulator_init_data zoom_vmmc1 = {
.consumer_supplies = zoom_vmmc1_supply,
};
-/* VMMC2 for MMC2 card */
-static struct regulator_init_data zoom_vmmc2 = {
- .constraints = {
- .min_uV = 185,
- .max_uV = 185,
- .apply_uV = true,
- .valid_modes_mask = REGULATOR_MODE_NORMAL
- | REGULATOR_MODE_STANDBY,
- .valid_ops_mask = REGULATOR_CHANGE_MODE
- | REGULATOR_CHANGE_STATUS,
- },
- .num_consumer_supplies = 1,
- .consumer_supplies = zoom_vmmc2_supply,
-};
-
/* VSIM for OMAP VDD_MMC1A (i/o for DAT4..DAT7) */
static struct regulator_init_data zoom_vsim = {
.constraints = {
@@ -159,15 +140,6 @@ static struct omap2_hsmmc_info mmc[] __initdata = {
.gpio_wp= -EINVAL,
.power_saving = true,
},
- {
- .name = internal,
- .mmc= 2,
- .wires = 8,
- .gpio_cd= -EINVAL,
- .gpio_wp= -EINVAL,
- .nonremovable = true,
- .power_saving = true,
- },
{} /* Terminator */
};
@@ -183,7 +155,6 @@ static int zoom_twl_gpio_setup(struct device *dev,
*/
zoom_vmmc1_supply.dev = mmc[0].dev;
zoom_vsim_supply.dev = mmc[0].dev;
- zoom_vmmc2_supply.dev = mmc[1].dev;
return 0;
}
@@ -241,7 +212,6 @@ static struct twl4030_platform_data zoom_twldata = {
.keypad = zoom_kp_twl4030_data,
.codec = zoom_codec_data,
.vmmc1 = zoom_vmmc1,
- .vmmc2 = zoom_vmmc2,
.vsim = zoom_vsim,
};
--
1.6.3.3
--
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
[PATCH]OMAP HSMMC: Fix a bug in card remove scenario
From: Madhusudhan Chikkature madhu...@ti.com
Date: Wed, 31 Mar 2010 19:31:24 -0400
Subject: [PATCH] OMAP HSMMC:Fix a bug in card removal scenario
The reset of data lines when the card is removed from the cage results
in a failure.The failure is seen if the card is removed from the cage
when TC is pending after a CMD with data received CC.The reset logic leaves
the controller in a state where niether a TC is received nor DTO.
The rest code can be safely removed here since it is taken care in the IRQ
handler.
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
drivers/mmc/host/omap_hsmmc.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 83f0aff..e9caf69 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1179,15 +1179,10 @@ static void omap_hsmmc_detect(struct work_struct *work)
carddetect = -ENOSYS;
}
- if (carddetect) {
+ if (carddetect)
mmc_detect_change(host-mmc, (HZ * 200) / 1000);
- } else {
- mmc_host_enable(host-mmc);
- omap_hsmmc_reset_controller_fsm(host, SRD);
- mmc_host_lazy_disable(host-mmc);
-
+ else
mmc_detect_change(host-mmc, (HZ * 50) / 1000);
- }
}
/*
--
1.6.3.3
--
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
RE: [PATCH]omap hsmmc: fix incorrect capability reporting
-Original Message- From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of Venkatraman S Sent: Tuesday, March 30, 2010 9:37 AM To: linux-...@vger.kernel.org; linux-omap@vger.kernel.org; kishore.kadiy...@ti.com Cc: Madhusudhan Chikkature Subject: [PATCH]omap hsmmc: fix incorrect capability reporting MMC slots that support 8 bit mode also support 4 bit mode. The capability flag has to reflect this, otherwise SDHC cards operate in 1 bit mode. Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com Signed-off-by: Venkatraman S svenk...@ti.com --- drivers/mmc/host/omap_hsmmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 83f0aff..dbf83a6 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2093,7 +2093,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) if (mmc_slot(host).wires = 8) mmc-caps |= MMC_CAP_8_BIT_DATA; - else if (mmc_slot(host).wires = 4) + if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; Since 8-bit is the max how about: if (mmc_slot(host).wires == 8) mmc-caps |= MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA; if (mmc_slot(host).wires == 4) mmc-caps |= MMC_CAP_4_BIT_DATA; This would be little easy to read the code. Regards, Madhu if (mmc_slot(host).nonremovable) -- 1.6.3.3 -- 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
RE: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Tony Lindgren Sent: Tuesday, March 23, 2010 10:27 AM To: Pais, Allen Cc: linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org; Pandita, Vikram Subject: Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3 * Pais, Allen allen.p...@ti.com [100322 22:42]: With this patch[DEBUG_LL + earlyprintk], I still haven't been able to boot the kernel. Is it working on your side. The commit am using is : a842b5f9ce70e1b738eabb4d719860070180ed1c I think you will also need the 3630 serial fixes series posted recently. I just merged those into omap-fixes-for-linus (and master) branch(es). Maybe give it a try with at commit b3c7740a120c8a7775cb63b4d094466da5c01692 + this patch? Thanks, I'll pull in those fixes. I believe the mux errors are fixed. Have a look at http://dev.omapzoom.org/?p=manju/kernel-omap3- dev.git;a=commit;h=3499f5023ee90dc6ee3868a3147b87fe22a1d9b7 Patch must have been missed some how. OK, we really should get fixes like that to mainline kernel ASAP to avoid duplicating the effort. Then at least one issue remains for zoom3 to be usable.. I'm getting tons of MMC errors trying to mount root on it: mmcblk1: error -110 transferring data, sector 2097024, nr 8, card status 0x900 end_request: I/O error, dev mmcblk1, sector 2097024 ... Any ideas if that's fixed somewhere also? Tony, What is the branch on which the kernel is built? I tried the master branch and the omap-fixes-for-linus both does not seem to boot Zoom3. Regards, Madhu Regards, Tony -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: mmc errors (was Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3)
Hi Nishant, The eMMC on Zoom2 has an issue with respect to detection as a high capacity card. This was discussed on the list with Pierre sometime back. I don't have an acceptable solution to make this device work. Rather I prefer to submit a patch which disables MMC2 on these boards. You can still use MMC1 to mount your file system. This is the card you can plug in to the cage. Regards, Madhu -Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Tuesday, March 23, 2010 5:49 PM To: Tony Lindgren Cc: Pais, Allen; linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org; Pandita, Vikram; Madhusudhan Chikkature Rajashekar Subject: mmc errors (was Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3) Tony Lindgren had written, on 03/23/2010 10:27 AM, the following: [...] Then at least one issue remains for zoom3 to be usable.. I'm getting tons of MMC errors trying to mount root on it: mmcblk1: error -110 transferring data, sector 2097024, nr 8, card status 0x900 end_request: I/O error, dev mmcblk1, sector 2097024 ... I have seen this on few platforms and seem to be related to eMMC usage. Any ideas if that's fixed somewhere also? Madhu, any comments? -- Regards, Nishanth Menon -- 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
RE: mmc errors (was Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3)
-Original Message- From: Madhusudhan [mailto:madhu...@ti.com] Sent: Wednesday, March 24, 2010 10:31 AM To: 'Nishanth Menon'; 'Tony Lindgren' Cc: 'Pais, Allen'; 'linux-arm-ker...@lists.infradead.org'; 'linux- o...@vger.kernel.org'; 'Pandita, Vikram' Subject: RE: mmc errors (was Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3) Hi Nishant, The eMMC on Zoom2 has an issue with respect to detection as a high capacity card. This was discussed on the list with Pierre sometime back. I don't have an acceptable solution to make this device work. Rather I prefer to submit a patch which disables MMC2 on these boards. You can still use MMC1 to mount your file system. This is the card you can plug in to the cage. Regards, Madhu -Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Tuesday, March 23, 2010 5:49 PM To: Tony Lindgren Cc: Pais, Allen; linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org; Pandita, Vikram; Madhusudhan Chikkature Rajashekar Subject: mmc errors (was Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3) Tony Lindgren had written, on 03/23/2010 10:27 AM, the following: [...] Then at least one issue remains for zoom3 to be usable.. I'm getting tons of MMC errors trying to mount root on it: mmcblk1: error -110 transferring data, sector 2097024, nr 8, card status 0x900 end_request: I/O error, dev mmcblk1, sector 2097024 ... I have seen this on few platforms and seem to be related to eMMC usage. Any ideas if that's fixed somewhere also? Madhu, any comments? -- Regards, Nishanth Menon -- 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
RE: mmc errors (was Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3)
-Original Message- From: Nishanth Menon [mailto:n...@ti.com] Sent: Tuesday, March 23, 2010 5:49 PM To: Tony Lindgren Cc: Pais, Allen; linux-arm-ker...@lists.infradead.org; linux- o...@vger.kernel.org; Pandita, Vikram; Madhusudhan Chikkature Rajashekar Subject: mmc errors (was Re: [PATCH] arm: Fix DEBUG_LL for omap zoom2/3) Tony Lindgren had written, on 03/23/2010 10:27 AM, the following: [...] Then at least one issue remains for zoom3 to be usable.. I'm getting tons of MMC errors trying to mount root on it: mmcblk1: error -110 transferring data, sector 2097024, nr 8, card status 0x900 end_request: I/O error, dev mmcblk1, sector 2097024 ... I have seen this on few platforms and seem to be related to eMMC usage. Any ideas if that's fixed somewhere also? Madhu, any comments? Sorry about multiple replies to this mail. Just wanted to avoid top posting. The eMMC on Zoom2 has an issue with respect to detection as a high capacity card. This was discussed on the list with Pierre sometime back. I don't have an acceptable solution to make this device work. Rather I prefer to submit a patch which disables MMC2 on these boards. You can still use MMC1 to mount your file system. This is the card you can plug in to the cage. Regards, Madhu -- Regards, Nishanth Menon -- 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
RE: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature
-Original Message- From: svenk...@gmail.com [mailto:svenk...@gmail.com] On Behalf Of Venkatraman S Sent: Thursday, March 11, 2010 4:52 AM To: Madhusudhan Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature Madhusudhan madhu...@ti.com wrote: -Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Venkatraman S Sent: Monday, March 01, 2010 5:27 AM To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-omap@vger.kernel.org Subject: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature Start to use the sDMA descriptor autoloading feature. For large datablocks, the MMC driver has to repeatedly setup, program and teardown the dma channel for each element of the sglist received in omap_hsmmc_request. By using descriptor autoloading, transfers from / to each element of the sglist is pre programmed into a linked list. The sDMA driver completes the entire transaction and provides a single interrupt. Due to this, number of dma interrupts for a typical 100MB transfer on the MMC is reduced from 25000 to about 400 (approximate). Transfer speeds are improved by ~5% (Though it varies on the size of read / write improves on huge transfers) Descriptor autoloading is available only in 3630 and 4430 (as of now). Hence normal DMA mode is also retained. Tested on omap4430 sdp. Signed-off-by: Venkatraman S svenk...@ti.com I don't see any issues with this patch except the concern I had on the first patch in the series. Why is that change linked to this series? Thanks. The problem was seen only in the context of using descriptor load. Would you prefer that I post it as a separate patch ? My point is why that change is needed for this feature to work? When DMA is completed and a callback is received the ch can be freed. Once TC is received the core is notified of the same. Can the first patch be dropped? Or do you see issues? Regards, Venkat. -- 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
RE: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor autoloading feature
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Venkatraman S
Sent: Monday, March 01, 2010 5:27 AM
To: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
linux-omap@vger.kernel.org
Subject: [PATCH 03/03] omap hsmmc: adaptation of sdma descriptor
autoloading feature
Start to use the sDMA descriptor autoloading feature.
For large datablocks, the MMC driver has to repeatedly setup, program
and teardown the
dma channel for each element of the sglist received in omap_hsmmc_request.
By using descriptor autoloading, transfers from / to each element of
the sglist is pre programmed
into a linked list. The sDMA driver completes the entire transaction
and provides a single interrupt.
Due to this, number of dma interrupts for a typical 100MB transfer on the
MMC is
reduced from 25000 to about 400 (approximate). Transfer speeds are
improved by ~5%
(Though it varies on the size of read / write improves on huge
transfers)
Descriptor autoloading is available only in 3630 and 4430 (as of now).
Hence normal DMA
mode is also retained.
Tested on omap4430 sdp.
Signed-off-by: Venkatraman S svenk...@ti.com
I don't see any issues with this patch except the concern I had on the first
patch in the series. Why is that change linked to this series?
---
drivers/mmc/host/omap_hsmmc.c | 143 +++-
-
1 files changed, 122 insertions(+), 21 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 06337f6..425129b 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -102,6 +102,7 @@
#define SRD (1 26)
#define SOFTRESET(1 1)
#define RESETDONE(1 0)
+#define DMA_ICR_QUIET0xD00
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -118,6 +119,12 @@
#define OMAP_MMC_MASTER_CLOCK9600
#define DRIVER_NAME mmci-omap-hs
+#define DMA_TYPE_NODMA 0
+#define DMA_TYPE_SDMA1
+#define DMA_TYPE_SDMA_DLOAD 2
+
+#define DMA_CTRL_BUF_SIZE(PAGE_SIZE * 3)
+
/* Timeouts for entering power saving states on inactivity, msec */
#define OMAP_MMC_DISABLED_TIMEOUT100
#define OMAP_MMC_SLEEP_TIMEOUT 1000
@@ -172,7 +179,11 @@ struct omap_hsmmc_host {
u32 bytesleft;
int suspended;
int irq;
- int use_dma, dma_ch;
+ int dma_caps;
+ int dma_in_use;
+ int dma_ch;
+ void*dma_ctrl_buf;
+ dma_addr_t dma_ctrl_buf_phy;
int dma_line_tx, dma_line_rx;
int slot_id;
int got_dbclk;
@@ -768,7 +779,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
- if (host-use_dma)
+ if (host-dma_in_use)
OMAP_HSMMC_WRITE(host-base, IE,
INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE));
else
@@ -803,7 +814,7 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
cmdreg = ~(DDIR);
}
- if (host-use_dma)
+ if (host-dma_in_use)
cmdreg |= DMA_EN;
/*
@@ -850,7 +861,7 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
host-data = NULL;
- if (host-use_dma host-dma_ch != -1)
+ if (host-dma_in_use host-dma_ch != -1)
dma_unmap_sg(mmc_dev(host-mmc), data-sg, host-dma_len,
omap_hsmmc_get_dma_dir(host, data));
@@ -900,7 +911,7 @@ static void omap_hsmmc_dma_cleanup(struct
omap_hsmmc_host *host, int errno)
{
host-data-error = errno;
- if (host-use_dma host-dma_ch != -1) {
+ if (host-dma_in_use host-dma_ch != -1) {
dma_unmap_sg(mmc_dev(host-mmc), host-data-sg, host-
dma_len,
omap_hsmmc_get_dma_dir(host, host-data));
omap_free_dma(host-dma_ch);
@@ -1253,7 +1264,6 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
omap_hsmmc_get_dma_sync_dev(host, data),
!(data-flags MMC_DATA_WRITE));
- omap_start_dma(dma_ch);
}
/*
@@ -1268,21 +1278,32 @@ static void omap_hsmmc_dma_cb(int lch, u16
ch_status, void *data)
if (host-dma_ch 0)
return;
-
- host-dma_sg_idx++;
- if (host-dma_sg_idx host-dma_len) {
- /* Fire up the next transfer. */
- omap_hsmmc_config_dma_params(host, host-data,
+ if (host-dma_in_use == DMA_TYPE_SDMA) {
+
RE: [PATCH] mmc: omap_hsmmc: Fix conditional locking
-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]
Sent: Wednesday, March 03, 2010 4:16 AM
To: Madhusudhan
Cc: 'LKML'; linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Subject: RE: [PATCH] mmc: omap_hsmmc: Fix conditional locking
On Tue, 2 Mar 2010, Madhusudhan wrote:
Conditional locking on (!in_interrupt()) is broken by design and there
is no reason to keep the host-irq_lock across the call to
mmc_request_done(). Also the host-protect_card magic hack does not
depend on the context
Can you please elaborate why the existing logic is broken?
Locks are only to be held to serialize data or state.
The mmc_request_done() call does _NOT_ require that at all. So
dropping the lock there is the right thing to do.
Also conditional locking on in_interrupt() is generally a nono as it
relies on assumptions which are not necessarily true in all
circumstances. Just one simple example: interrupt threading will make
it explode nicely and it did already with the realtime patches
applied.
Such code constructs prevent us to do generic changes to the kernel
behaviour without any real good reason.
It locks at the new request and unlocks just before issuing the cmd.
Further
IRQ handler has these calls hence the !in_interrupt check.
Aside of the conditional locking I have several issues with that code:
1) The code flow is massively unreadable:
omap_hsmmc_start_command()
{
.
if (!in_interrupt())
spin_unlock_irq();
}
omap_hsmmc_request()
{
if (!in_interrupt())
spin_lock_irq();
omap_hsmmc_start_command();
}
We generally want to see the lock/unlock pairs in one function and not
having to figure out where the heck unlock happens.
2) The point of unlocking is patently wrong
omap_hsmmc_start_command()
{
.
if (!in_interrupt())
spin_unlock_irq();
---
OMAP_HSMMC_WRITE(host-base, ARG, cmd-arg);
---
OMAP_HSMMC_WRITE(host-base, CMD, cmdreg);
}
What happens, if you get a spurious interrupt here ? Same for SMP,
though you are probably protected by the core mmc code request
serialization there.
How does this patch improve that? In fact with your patch for a data
transfer cmd there are several lock-unlock calls.
1) The patch simply removes conditional locking and moves the lock
sections to those places which protect something. Aside of that it
makes the code easier to understand.
2) What's the point of not having those lock/unlocks ? On UP the
spinlock is a NOOP anyway, so you won't even notice. On SMP you
won't notice either, simply because the lock is cache hot and
almost never contended.
Sounds reasonable.Readbility is still a factor but works for me as the main
intention here is to remove the in_interrupt conditional.
Acked-by: Madhusudhan Chikkaturemadhu...@ti.com
Best Regards,
Madhu
Thanks,
tglx
--
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
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Thursday, February 18, 2010 4:16 PM To: Paul Walmsley Cc: Madhusudhan; David Vrabel; r-woodru...@ti.com; saw...@ti.com; linux- m...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts On Thu, Feb 18, 2010 at 12:21 PM, Paul Walmsley p...@pwsan.com wrote: (cc'ing Steve, Richard, Anand) There appear to be least seven SDIO card drivers in 2.6.34-rc7. At least one of these is for a TI chip - the wl1251. I think some of the Gumstix Overo OMAP3 boards are using an SDIO-connected Marvell Libertas: http://www.gumstix.com/store/catalog/product_info.php?products_id=252 That is correct, a Wi2Wi wifi module is connected via mmc2 on the Overo Air and Fire products. Steve, A dumb question. Is this Wi2Wi wifi module available as a standard SDIO card which can be plugged into a SD card cage? Or is it specifically designed for the gumstix board? Regards, Madhu Data rates are pretty low with the existing OMAP SDIO driver. Any chance this patch would improve that situation? Just added applying the patch and retesting data rates to my to do list :-) Steve David is probably testing with a Bluetooth card - maybe he can comment further. And at least I don't see a way I can test any of these features myself. Could you clarify? - Paul -- 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
RE: [PATCH] mmc: omap_hsmmc: Fix conditional locking
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Thomas Gleixner
Sent: Monday, March 01, 2010 1:02 PM
To: LKML
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org
Subject: [PATCH] mmc: omap_hsmmc: Fix conditional locking
Conditional locking on (!in_interrupt()) is broken by design and there
is no reason to keep the host-irq_lock across the call to
mmc_request_done(). Also the host-protect_card magic hack does not
depend on the context
Can you please elaborate why the existing logic is broken?
It locks at the new request and unlocks just before issuing the cmd. Further
IRQ handler has these calls hence the !in_interrupt check.
How does this patch improve that? In fact with your patch for a data
transfer cmd there are several lock-unlock calls.
Fix the mess by dropping host-irq_lock before calling
mmc_request_done().
Signed-off-by: Thomas Gleixner t...@linutronix.de
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..99a3383 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -468,14 +468,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
if (host-use_dma)
cmdreg |= DMA_EN;
- /*
- * In an interrupt context (i.e. STOP command), the spinlock is
unlocked
- * by the interrupt handler, otherwise (i.e. for a new request) it
is
- * unlocked here.
- */
- if (!in_interrupt())
- spin_unlock_irqrestore(host-irq_lock, host-flags);
-
OMAP_HSMMC_WRITE(host-base, ARG, cmd-arg);
OMAP_HSMMC_WRITE(host-base, CMD, cmdreg);
}
@@ -506,7 +498,9 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
}
host-mrq = NULL;
+ spin_unlock(host-irq_lock);
mmc_request_done(host-mmc, mrq);
+ spin_lock(host-irq_lock);
return;
}
@@ -523,7 +517,9 @@ omap_hsmmc_xfer_done(struct omap_hsmmc_host *host,
struct mmc_data *data)
if (!data-stop) {
host-mrq = NULL;
+ spin_unlock(host-irq_lock);
mmc_request_done(host-mmc, data-mrq);
+ spin_lock(host-irq_lock);
return;
}
omap_hsmmc_start_command(host, data-stop, NULL);
@@ -551,7 +547,9 @@ omap_hsmmc_cmd_done(struct omap_hsmmc_host *host,
struct mmc_command *cmd)
}
if ((host-data == NULL !host-response_busy) || cmd-error) {
host-mrq = NULL;
+ spin_unlock(host-irq_lock);
mmc_request_done(host-mmc, cmd-mrq);
+ spin_lock(host-irq_lock);
}
}
@@ -1077,37 +1075,31 @@ static void omap_hsmmc_request(struct mmc_host
*mmc, struct mmc_request *req)
struct omap_hsmmc_host *host = mmc_priv(mmc);
int err;
+ spin_lock_irqsave(host-irq_lock, host-flags);
/*
- * Prevent races with the interrupt handler because of unexpected
- * interrupts, but not if we are already in interrupt context i.e.
- * retries.
+ * Protect the card from I/O if there is a possibility
+ * it can be removed.
*/
- if (!in_interrupt()) {
- spin_lock_irqsave(host-irq_lock, host-flags);
- /*
- * Protect the card from I/O if there is a possibility
- * it can be removed.
- */
- if (host-protect_card) {
- if (host-reqs_blocked 3) {
- /*
- * Ensure the controller is left in a
consistent
- * state by resetting the command and data
state
- * machines.
- */
- omap_hsmmc_reset_controller_fsm(host, SRD);
- omap_hsmmc_reset_controller_fsm(host, SRC);
- host-reqs_blocked += 1;
- }
- req-cmd-error = -EBADF;
- if (req-data)
- req-data-error = -EBADF;
- spin_unlock_irqrestore(host-irq_lock,
host-flags);
- mmc_request_done(mmc, req);
- return;
- } else if (host-reqs_blocked)
- host-reqs_blocked = 0;
- }
+ if (host-protect_card) {
+ if (host-reqs_blocked 3) {
+ /*
+ * Ensure the controller is left in a consistent
+ * state by resetting the command and data state
+ * machines.
+ */
+ omap_hsmmc_reset_controller_fsm(host, SRD);
+ omap_hsmmc_reset_controller_fsm(host, SRC);
+ host-reqs_blocked +=
RE: [PATCH/RFC 0/4] convert HS-MMC driver to hwmod + runtime PM
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Kevin Hilman
Sent: Tuesday, February 23, 2010 6:51 PM
To: linux-omap@vger.kernel.org
Subject: Re: [PATCH/RFC 0/4] convert HS-MMC driver to hwmod + runtime PM
Kevin Hilman khil...@deeprootsystems.com writes:
This series converts the OMAP HS-MMC driver to use omap_hwmod +
runtime PM API.
Depends on MMC hwmods available in 'pm-wip/hwmods' branch of
my git tree[1] as well as previously posted runtime PM series:
[PATCH/RFC 0/2] initial runtime PM layer for OMAP
The easies way to experiment/test is to use my 'pm-wip/mmc' branch
which has all the dependencies, and is based on omap/for-next'.
It has been tested by merging with current PM branch.
[1] http://git.kernel.org/?p=linux/kernel/git/khilman/linux-omap-pm.git
A question for those of you who actually understand the MMC driver...
I'm having problems getting my head around the current PM stuff in the
MMC driver. My primary question is:
Why does the suspend hook need to re-enable the device before
suspending?
In the scenario where there is no activity on the bus the MMC clocks are
kept disabled. Now in the suspend path the MMC core will issue certain CMDs
like CMD7(to end the suspend path) to deselect the card(more of a protocol
stuff). Hence the host need to be in enabled state before letting the core
know that there is a suspend request.
When using runtime PM, the MMC device is disabled including
clocks off and regulator off (if power_savings == true) when there
is no activity.
Then, in the static suspend hook, it's re-enabled (including taking it out
of
off, re-enabling regulators etc) only to be quickly disabled again.
This seems horribly inefficient.
This is exactly for the reason I mentioned above.
I admit to not understanding the MMC layer terribly well, so can someone
enlighten me as to what is going on here?
What I am testing here is a patch on top of this series (below) that
adds a check to the static suspend hook. If the device is already
runtime suspended, then the suspend and resume hooks should be noop.
This appears to work just fine while testing on omap3evm just doing
simple read/write tests before an after suspend resume.
I did some basic testing with your previously posted patches. But my testing
was incomplete because on Zoom2 because for some reason the OFF mode was not
working even without your patches.
My concern was more with respect to OFF mode in idle path since your patches
removed context restore calls if I recall correctly. Are you able to hit
CORE OFF and then come back and do the read/write transfers in idle as well
as suspend/resume path?
Regards,
Madhu
Note that if you want to test this patch, it also depends on this
patch to runtime PM from the linux-pm list:
https://lists.linux-foundation.org/pipermail/linux-pm/2010-
February/024275.html
These are all included in an updated version of my pm-wip/mmc branch
for ease of testing. Merge it with the current PM branch, enable
CONFIG_PM_RUNTIME and test away.
Kevin
commit 166cba7679fa267ee6e6eb39fd1e871ede5ded16
Author: Kevin Hilman khil...@deeprootsystems.com
Date: Tue Feb 23 16:21:56 2010 -0800
MMC: omap_hsmmc: check for runtime-suspend in static suspend
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 16d66b9..dd027bb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -,6 +,9 @@ static int omap_hsmmc_suspend(struct device *dev)
if (host host-suspended)
return 0;
+ if (pm_is_runtime_suspended(host-dev))
+ return 0;
+
if (host) {
host-suspended = 1;
if (host-pdata-suspend) {
@@ -2260,12 +2263,6 @@ static int omap_hsmmc_suspend(struct device *dev)
}
mmc_host_disable(host-mmc);
}
-
- /*
- * HACK: extra put to compensate for DPM core keeping
- * runtime PM disabled. -- khilman
- */
- pm_runtime_put_sync(host-dev);
}
return ret;
}
@@ -2280,13 +2277,10 @@ static int omap_hsmmc_resume(struct device *dev)
if (host !host-suspended)
return 0;
- if (host) {
- /*
- * HACK: extra get to compensate for DPM core keeping
- * runtime PM disabled. -- khilman
- */
- pm_runtime_get_sync(host-dev);
+ if (pm_is_runtime_suspended(host-dev))
+ return 0;
+ if (host) {
if (mmc_host_enable(host-mmc) != 0) {
pm_runtime_suspend(host-dev);
goto clk_en_err;
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message-
From: David Vrabel [mailto:david.vra...@csr.com]
Sent: Wednesday, February 10, 2010 5:52 AM
To: linux-...@vger.kernel.org
Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP
in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
smart-idle mode.
FCLK must be enabled while SDIO interrupts are enabled or the MMC block
won't wake-up.
The writes to STAT and ISE when starting a command are unnecessary and
have been removed.
Signed-off-by: David Vrabel david.vra...@csr.com
---
As noted in the FIXME comment, I think the correct thing to do is to
always leave FCLK enabled. The clock/clockdomain subsystems should be
configuring smart-idle mode making explicit calls to disable FCLK
unnecessary. I couldn't follow the clock subsystem to see if it was
actually doing this, though.
I Just noticed that SD cards stopped working on Zoom2 if I apply this patch.
I will come back with details on what's going on in a bit unless someone
else beats me on that.
Regards,
Madhu
---
drivers/mmc/host/omap_hsmmc.c | 94
-
1 files changed, 65 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e6d8cb3..ad0f867 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -64,6 +64,7 @@
#define SDVS_MASK0x0E00
#define SDVSCLR 0xF1FF
#define SDVSDET 0x0400
+#define ENAWAKEUP(1 2)
#define AUTOIDLE 0x1
#define SDBP (1 8)
#define DTO 0xe
@@ -74,9 +75,11 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT16
+#define CIRQ_ENABLE (1 8)
#define INT_EN_MASK 0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define CTPL (1 11)
#define INIT_STREAM (1 1)
#define DP_SELECT(1 21)
#define DDIR (1 4)
@@ -84,10 +87,12 @@
#define MSBS (1 5)
#define BCE (1 1)
#define FOUR_BIT (1 1)
+#define IWE (1 24)
#define DW8 (1 5)
#define CC 0x1
#define TC 0x02
#define OD 0x1
+#define CIRQ (1 8)
#define ERR (1 15)
#define CMD_TIMEOUT (1 16)
#define DATA_TIMEOUT (1 20)
@@ -228,7 +233,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE |
ENAWAKEUP);
if (host-id == OMAP_MMC1_DEVID) {
if (host-power_mode != MMC_POWER_OFF
@@ -243,7 +248,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
}
OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | hctl);
+ OMAP_HSMMC_READ(host-base, HCTL) | hctl | IWE);
OMAP_HSMMC_WRITE(host-base, CAPA,
OMAP_HSMMC_READ(host-base, CAPA) | capa);
@@ -257,7 +262,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
+ OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK | CIRQ);
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
/* Do not initialize card-specific things if the power is off */
@@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
mmc_hostname(host-mmc), cmd-opcode, cmd-arg);
host-cmd = cmd;
- /*
- * Clear status bits and enable interrupts
- */
- OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
-
if (host-use_dma)
OMAP_HSMMC_WRITE(host-base, IE,
INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE));
@@ -638,18 +637,21 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
{
struct omap_hsmmc_host *host = dev_id;
struct mmc_data *data;
- int end_cmd = 0, end_trans = 0, status;
+ u32 status;
+ int end_cmd = 0, end_trans = 0;
+ bool card_irq = false;
spin_lock(host-irq_lock);
- if (host-mrq == NULL) {
- OMAP_HSMMC_WRITE(host-base, STAT,
- OMAP_HSMMC_READ(host-base, STAT));
- /* Flush posted write */
-
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, February 18, 2010 2:21 PM To: Madhusudhan Cc: 'David Vrabel'; sako...@gmail.com; r-woodru...@ti.com; saw...@ti.com; linux-...@vger.kernel.org; linux-omap@vger.kernel.org Subject: RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts Hi, (cc'ing Steve, Richard, Anand) On Thu, 18 Feb 2010, Madhusudhan wrote: Not to add further confusion but as far as I understand SDIO should be able to asynchronously wakeup OMAP regardless of MMC clocks being OFF . As per the SDIO spec DAT1 line is used for signaling the card interrupt to the host. The TRM clearly shows a GPIO connected to DAT1 line for wakeup through the SDIO interrupt. Wouldn't this help? Is the integration code in arch/arm/*omap* set to enable wakeup on the DAT1 ball on the OMAP? I don't see any trace of that in the code. That would surely prevent wakeup from succeeding on an off-mode enabled kernel. Sounds like there may be other problems. Why not give it a try with an SDIO card and see if you can get it to work? Definitely these are good features that are being added. Just that there are confusions around and not everyone has a setup to validate these features. Hopefully someone inside TI is validating SDIO wakeup on Linux? If I look in the mainline kernel today there is only one SDIO card driver sdio_uart.c. [p...@twilight current]$ find . -name *sdio*c -print | fgrep -v /core/ ./drivers/ssb/sdio.c ./drivers/bluetooth/btsdio.c ./drivers/bluetooth/btmrvl_sdio.c ./drivers/mmc/host/mvsdio.c ./drivers/net/wimax/i2400m/sdio-rx.c ./drivers/net/wimax/i2400m/sdio-tx.c ./drivers/net/wimax/i2400m/sdio.c ./drivers/net/wimax/i2400m/sdio-fw.c ./drivers/net/wireless/iwmc3200wifi/sdio.c ./drivers/net/wireless/libertas/if_sdio.c ./drivers/net/wireless/wl12xx/wl1251_sdio.c ./drivers/net/wireless/b43/sdio.c ./drivers/media/dvb/siano/smssdio.c [p...@twilight current]$ There appear to be least seven SDIO card drivers in 2.6.34-rc7. At least one of these is for a TI chip - the wl1251. I think some of the Gumstix Overo OMAP3 boards are using an SDIO-connected Marvell Libertas: http://www.gumstix.com/store/catalog/product_info.php?products_id=252 David is probably testing with a Bluetooth card - maybe he can comment further. And at least I don't see a way I can test any of these features myself. Could you clarify? I meant that right now I am not equipped with a setup that has a SDIO device that works to a level that this wakeup feature can be validated. Regards, Madhu - Paul -- 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
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Madhusudhan
Sent: Friday, February 19, 2010 3:05 PM
To: 'David Vrabel'; linux-...@vger.kernel.org
Cc: linux-omap@vger.kernel.org
Subject: RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message-
From: David Vrabel [mailto:david.vra...@csr.com]
Sent: Wednesday, February 10, 2010 5:52 AM
To: linux-...@vger.kernel.org
Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP
in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
smart-idle mode.
FCLK must be enabled while SDIO interrupts are enabled or the MMC block
won't wake-up.
The writes to STAT and ISE when starting a command are unnecessary and
have been removed.
Signed-off-by: David Vrabel david.vra...@csr.com
---
As noted in the FIXME comment, I think the correct thing to do is to
always leave FCLK enabled. The clock/clockdomain subsystems should be
configuring smart-idle mode making explicit calls to disable FCLK
unnecessary. I couldn't follow the clock subsystem to see if it was
actually doing this, though.
I Just noticed that SD cards stopped working on Zoom2 if I apply this
patch.
I will come back with details on what's going on in a bit unless someone
else beats me on that.
A little bit of rearranging the David's changes to the irq handler gets the
MMC/SD cards to work fine again. Changes are shown in the attached patch for
now and it should not hurt the CIRQ handling as well.
Regards,
Madhu
Regards,
Madhu
---
drivers/mmc/host/omap_hsmmc.c | 94 --
--
-
1 files changed, 65 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index e6d8cb3..ad0f867 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -64,6 +64,7 @@
#define SDVS_MASK 0x0E00
#define SDVSCLR0xF1FF
#define SDVSDET0x0400
+#define ENAWAKEUP (1 2)
#define AUTOIDLE 0x1
#define SDBP (1 8)
#define DTO0xe
@@ -74,9 +75,11 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT 16
+#define CIRQ_ENABLE(1 8)
#define INT_EN_MASK0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define CTPL (1 11)
#define INIT_STREAM(1 1)
#define DP_SELECT (1 21)
#define DDIR (1 4)
@@ -84,10 +87,12 @@
#define MSBS (1 5)
#define BCE(1 1)
#define FOUR_BIT (1 1)
+#define IWE(1 24)
#define DW8(1 5)
#define CC 0x1
#define TC 0x02
#define OD 0x1
+#define CIRQ (1 8)
#define ERR(1 15)
#define CMD_TIMEOUT(1 16)
#define DATA_TIMEOUT (1 20)
@@ -228,7 +233,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE |
ENAWAKEUP);
if (host-id == OMAP_MMC1_DEVID) {
if (host-power_mode != MMC_POWER_OFF
@@ -243,7 +248,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
}
OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | hctl);
+ OMAP_HSMMC_READ(host-base, HCTL) | hctl | IWE);
OMAP_HSMMC_WRITE(host-base, CAPA,
OMAP_HSMMC_READ(host-base, CAPA) | capa);
@@ -257,7 +262,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
+ OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK | CIRQ);
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
/* Do not initialize card-specific things if the power is off */
@@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
mmc_hostname(host-mmc), cmd-opcode, cmd-arg);
host-cmd = cmd;
- /*
-* Clear status bits and enable interrupts
-*/
- OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK
RE: [PATCH 0/3] mmc: omap_hsmmc: support SDIO cards
snip
Also, keep in mind that the buffers for transfers must begin and end on
a word boundary. The OMAP's DMA controller can only transfer whole
words to the MMC FIFO.
I've slightly modified your patch mmc: omap_hsmmc: use packet sync'd DMA
and it
seems to work now, at least with SD card and libertas_sdio:
Mike,
As per the latest discussion, David replied that this patch is not needed
and FRAME sync just works fine. So, without this patch does SDIO int
functionality work for you?
Regards,
Madhu
---
drivers/mmc/host/omap_hsmmc.c | 23 ---
1 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..5408bcb 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -114,6 +114,7 @@
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MASTER_CLOCK9600
+#define OMAP_HSMMC_FIFO_WORDS(512/4)
#define DRIVER_NAME mmci-omap-hs
/* Timeouts for entering power saving states on inactivity, msec */
@@ -884,24 +885,24 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
{
int blksz, nblk, dma_ch;
+ blksz = host-data-blksz;
+ nblk = sg_dma_len(sgl) / blksz;
+
dma_ch = host-dma_ch;
if (data-flags MMC_DATA_WRITE) {
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
- (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
+ (host-mapbase + OMAP_HSMMC_DATA), 0, blksz / 4);
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
sg_dma_address(sgl), 0, 0);
} else {
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
- (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
+ (host-mapbase + OMAP_HSMMC_DATA), 0, blksz / 4);
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
sg_dma_address(sgl), 0, 0);
}
- blksz = host-data-blksz;
- nblk = sg_dma_len(sgl) / blksz;
-
omap_set_dma_transfer_params(dma_ch, OMAP_DMA_DATA_TYPE_S32,
- blksz / 4, nblk, OMAP_DMA_SYNC_FRAME,
+ blksz / 4, nblk, OMAP_DMA_SYNC_PACKET,
omap_hsmmc_get_dma_sync_dev(host, data),
!(data-flags MMC_DATA_WRITE));
@@ -944,17 +945,9 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
void *data)
static int omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host,
struct mmc_request *req)
{
- int dma_ch = 0, ret = 0, err = 1, i;
+ int dma_ch = 0, ret = 0, err = 1;
struct mmc_data *data = req-data;
- /* Sanity check: all the SG entries must be aligned by block size.
*/
- for (i = 0; i data-sg_len; i++) {
- struct scatterlist *sgl;
-
- sgl = data-sg + i;
- if (sgl-length % data-blksz)
- return -EINVAL;
- }
if ((data-blksz % 4) != 0)
/* REVISIT: The MMC buffer increments only when MSB is
written.
* Return error for blksz which is non multiple of four.
--
1.6.4.4
David
--
Sincerely yours,
Mike.
--
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
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message- From: David Vrabel [mailto:david.vra...@csr.com] Sent: Thursday, February 18, 2010 6:16 AM To: Madhusudhan Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts Madhusudhan wrote: My question was more related to the idle path. In a scenario where you start using the SDIO functionality and after some time you leave the SDIO card idle, does the FCLK still remain enabled? Or do you see that sdio_irq_thread exits and disables the FCLK? What do you mean by leave the SDIO card idle? I meant a state where the SDIO card is not doing any active transfers. Does it work that way? Regards, Madhu David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom -- 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
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message- From: Paul Walmsley [mailto:p...@pwsan.com] Sent: Thursday, February 18, 2010 11:44 AM To: David Vrabel Cc: Madhusudhan; linux-...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts On Thu, 18 Feb 2010, David Vrabel wrote: Paul Walmsley wrote: Perhaps I'm misunderstanding what you're referring to, but it seems there is some confusion as to what target smart-idle mode does. The TI OMAP 34xx TRM is the one of the most obtuse document I've had to read. An even after multiple reads of relevant sections it still doesn't make sense. Parts are contradictory, parts are poorly explained and some bit are just plain incorrect. Yes. TI needs to also release the functional specifications for each IP block; the information in the current TRM is generally insufficient to write high-quality drivers. TI should also host a process, open to the public, to submit TRM revision and clarification requests, and to track their disposition. Paul, David, Not to add further confusion but as far as I understand SDIO should be able to asynchronously wakeup OMAP regardless of MMC clocks being OFF . As per the SDIO spec DAT1 line is used for signaling the card interrupt to the host. The TRM clearly shows a GPIO connected to DAT1 line for wakeup through the SDIO interrupt. Wouldn't this help? I don't have time to sort out any of this properly -- it works well enough for me. Thanks very much for the SDIO patches. They are appreciated. Definitely these are good features that are being added. Just that there are confusions around and not everyone has a setup to validate these features. If I look in the mainline kernel today there is only one SDIO card driver sdio_uart.c. And at least I don't see a way I can test any of these features myself. Regards, Madhu - Paul -- 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
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message- From: Nicolas Pitre [mailto:n...@fluxnic.net] Sent: Thursday, February 18, 2010 1:27 PM To: Madhusudhan Cc: 'Paul Walmsley'; 'David Vrabel'; linux-...@vger.kernel.org; linux- o...@vger.kernel.org Subject: RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts On Thu, 18 Feb 2010, Madhusudhan wrote: If I look in the mainline kernel today there is only one SDIO card driver sdio_uart.c. And at least I don't see a way I can test any of these features myself. There are many other SDIO drivers in the kernel today: - The libertas wireless driver supports many interfaces, including PCMCIA/CF, USB, SDIO and SPI. Chips known to work with the SDIO interface are the Marvell 8686 and 8688. - There is a BlueTooth HCI SDIO driver implementing the standard SDIO BlueTooth class. - The Marvell 8688 mentioned above is also a BlueTooth device through an additional SDIO function. - Intel Wireless WiMAX Connection 2400 over SDIO. And the sdio_uart.c driver can be used with SDIO GPS receivers for example. This is good information. Any known SDIO cards commercially available using the above chips? Thanks, Madhu Nicolas -- 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
RE: [PATCH 1/3] mmc: omap_hsmmc: use packet sync'd DMA
-Original Message-
From: David Vrabel [mailto:david.vra...@csr.com]
Sent: Wednesday, February 10, 2010 5:52 AM
To: linux-...@vger.kernel.org
Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
Subject: [PATCH 1/3] mmc: omap_hsmmc: use packet sync'd DMA
Use packet sync'd DMA in the omap_hsmmc driver to avoid the
restriction that transfers must be a multiple of the block size. This
is required for byte-mode transfers to SDIO cards.
What is the typical scenario here? Is it IO_RW_EXTENDED with block_mode
turned off?
Signed-off-by: David Vrabel david.vra...@csr.com
---
drivers/mmc/host/omap_hsmmc.c | 17 +
1 files changed, 5 insertions(+), 12 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..e7142a2 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -114,6 +114,7 @@
#define MMC_TIMEOUT_MS 20
#define OMAP_MMC_MASTER_CLOCK9600
+#define OMAP_HSMMC_FIFO_WORDS(512/4)
#define DRIVER_NAME mmci-omap-hs
/* Timeouts for entering power saving states on inactivity, msec */
@@ -887,12 +888,12 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
dma_ch = host-dma_ch;
if (data-flags MMC_DATA_WRITE) {
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
- (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
+ (host-mapbase + OMAP_HSMMC_DATA), 0,
OMAP_HSMMC_FIFO_WORDS);
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
sg_dma_address(sgl), 0, 0);
} else {
omap_set_dma_src_params(dma_ch, 0, OMAP_DMA_AMODE_CONSTANT,
- (host-mapbase + OMAP_HSMMC_DATA), 0, 0);
+ (host-mapbase + OMAP_HSMMC_DATA), 0,
OMAP_HSMMC_FIFO_WORDS);
omap_set_dma_dest_params(dma_ch, 0, OMAP_DMA_AMODE_POST_INC,
sg_dma_address(sgl), 0, 0);
}
@@ -901,7 +902,7 @@ static void omap_hsmmc_config_dma_params(struct
omap_hsmmc_host *host,
nblk = sg_dma_len(sgl) / blksz;
omap_set_dma_transfer_params(dma_ch, OMAP_DMA_DATA_TYPE_S32,
- blksz / 4, nblk, OMAP_DMA_SYNC_FRAME,
+ blksz / 4, nblk, OMAP_DMA_SYNC_PACKET,
omap_hsmmc_get_dma_sync_dev(host, data),
!(data-flags MMC_DATA_WRITE));
How does this configuration help? Isn't the PACKET again a multiple of
blksz?
@@ -944,17 +945,9 @@ static void omap_hsmmc_dma_cb(int lch, u16 ch_status,
void *data)
static int omap_hsmmc_start_dma_transfer(struct omap_hsmmc_host *host,
struct mmc_request *req)
{
- int dma_ch = 0, ret = 0, err = 1, i;
+ int dma_ch = 0, ret = 0, err = 1;
struct mmc_data *data = req-data;
- /* Sanity check: all the SG entries must be aligned by block size.
*/
- for (i = 0; i data-sg_len; i++) {
- struct scatterlist *sgl;
-
- sgl = data-sg + i;
- if (sgl-length % data-blksz)
- return -EINVAL;
- }
if ((data-blksz % 4) != 0)
/* REVISIT: The MMC buffer increments only when MSB is
written.
* Return error for blksz which is non multiple of four.
--
1.6.3.3
--
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
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message-
From: David Vrabel [mailto:david.vra...@csr.com]
Sent: Wednesday, February 10, 2010 5:52 AM
To: linux-...@vger.kernel.org
Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com
Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP
in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in
smart-idle mode.
FCLK must be enabled while SDIO interrupts are enabled or the MMC block
won't wake-up.
I am curious to know the system behavior with this patch. Does the FCLK
remain enabled forever if a SDIO card is detected on the bus?
The mmc_signal_sdio_irq fn seems to disable the irq and then wake up the
sdio_irq_thread which would result in enabling the FCLK back. Hence the
above question.
The writes to STAT and ISE when starting a command are unnecessary and
have been removed.
Signed-off-by: David Vrabel david.vra...@csr.com
---
As noted in the FIXME comment, I think the correct thing to do is to
always leave FCLK enabled. The clock/clockdomain subsystems should be
configuring smart-idle mode making explicit calls to disable FCLK
unnecessary. I couldn't follow the clock subsystem to see if it was
actually doing this, though.
---
drivers/mmc/host/omap_hsmmc.c | 94
-
1 files changed, 65 insertions(+), 29 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index e6d8cb3..ad0f867 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -64,6 +64,7 @@
#define SDVS_MASK0x0E00
#define SDVSCLR 0xF1FF
#define SDVSDET 0x0400
+#define ENAWAKEUP(1 2)
#define AUTOIDLE 0x1
#define SDBP (1 8)
#define DTO 0xe
@@ -74,9 +75,11 @@
#define CLKD_SHIFT 6
#define DTO_MASK 0x000F
#define DTO_SHIFT16
+#define CIRQ_ENABLE (1 8)
#define INT_EN_MASK 0x307F0033
#define BWR_ENABLE (1 4)
#define BRR_ENABLE (1 5)
+#define CTPL (1 11)
#define INIT_STREAM (1 1)
#define DP_SELECT(1 21)
#define DDIR (1 4)
@@ -84,10 +87,12 @@
#define MSBS (1 5)
#define BCE (1 1)
#define FOUR_BIT (1 1)
+#define IWE (1 24)
#define DW8 (1 5)
#define CC 0x1
#define TC 0x02
#define OD 0x1
+#define CIRQ (1 8)
#define ERR (1 15)
#define CMD_TIMEOUT (1 16)
#define DATA_TIMEOUT (1 20)
@@ -228,7 +233,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, SYSCONFIG,
- OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE);
+ OMAP_HSMMC_READ(host-base, SYSCONFIG) | AUTOIDLE |
ENAWAKEUP);
if (host-id == OMAP_MMC1_DEVID) {
if (host-power_mode != MMC_POWER_OFF
@@ -243,7 +248,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
}
OMAP_HSMMC_WRITE(host-base, HCTL,
- OMAP_HSMMC_READ(host-base, HCTL) | hctl);
+ OMAP_HSMMC_READ(host-base, HCTL) | hctl | IWE);
OMAP_HSMMC_WRITE(host-base, CAPA,
OMAP_HSMMC_READ(host-base, CAPA) | capa);
@@ -257,7 +262,7 @@ static int omap_hsmmc_context_restore(struct
omap_hsmmc_host *host)
;
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
+ OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK | CIRQ);
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
/* Do not initialize card-specific things if the power is off */
@@ -426,12 +431,6 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host, struct mmc_command *cmd,
mmc_hostname(host-mmc), cmd-opcode, cmd-arg);
host-cmd = cmd;
- /*
- * Clear status bits and enable interrupts
- */
- OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
-
if (host-use_dma)
OMAP_HSMMC_WRITE(host-base, IE,
INT_EN_MASK ~(BRR_ENABLE | BWR_ENABLE));
@@ -638,18 +637,21 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
{
struct omap_hsmmc_host *host = dev_id;
struct mmc_data *data;
- int end_cmd = 0, end_trans = 0, status;
+ u32 status;
+ int end_cmd = 0, end_trans = 0;
+ bool card_irq = false;
spin_lock(host-irq_lock);
- if (host-mrq == NULL) {
- OMAP_HSMMC_WRITE(host-base, STAT,
-
RE: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts
-Original Message- From: David Vrabel [mailto:david.vra...@csr.com] Sent: Wednesday, February 17, 2010 1:40 PM To: Madhusudhan Cc: linux-...@vger.kernel.org; linux-omap@vger.kernel.org Subject: Re: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts Madhusudhan wrote: -Original Message- From: David Vrabel [mailto:david.vra...@csr.com] Sent: Wednesday, February 10, 2010 5:52 AM To: linux-...@vger.kernel.org Cc: David Vrabel; linux-omap@vger.kernel.org; madhu...@ti.com Subject: [PATCH 3/3] mmc: omap_hsmmc: enable SDIO card interrupts Enable the use of SDIO card interrupts. This requires setting ENAWAKEUP in SYSCONFIG and IWE in HTCL to allow the MMC block to wake-up when in smart-idle mode. FCLK must be enabled while SDIO interrupts are enabled or the MMC block won't wake-up. I am curious to know the system behavior with this patch. Does the FCLK remain enabled forever if a SDIO card is detected on the bus? Only if card interrupts are enabled. The card irq is disabled when the sdio_irq_thread exits. Your patch sets up the capability to enable sdio irqs anyway. My question was more related to the idle path. In a scenario where you start using the SDIO functionality and after some time you leave the SDIO card idle, does the FCLK still remain enabled? Or do you see that sdio_irq_thread exits and disables the FCLK? Regards, Madhu This is why I think that smart-idle mode needs to be used (it's turned on by default on the MMC controller) but I don't understand the clock/clockdomain code to see if that's doing the right thing. If smart-idle mode is used then we don't need to disable FCLK manually to save power. This will simplify the driver a bit. David -- 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
RE: [PATCH/RFC 4/4] OMAP2/3 MMC: initial conversion to runtime PM
snip
err_irq:
mmc_host_disable(host-mmc);
- clk_disable(host-iclk);
+ pm_runtime_suspend(host-dev);
Why not pm_runtime_put_sync() here? It can replace the calls:
mmc_host_disable(host-mmc);
clk_disable(host-iclk);
clk_put(host-fclk);
clk_put(host-iclk);
+
if (host-got_dbclk) {
clk_disable(host-dbclk);
clk_put(host-dbclk);
@@ -2216,7 +2164,8 @@ static int omap_hsmmc_remove(struct platform_device
*pdev)
flush_scheduled_work();
mmc_host_disable(host-mmc);
- clk_disable(host-iclk);
+ pm_runtime_suspend(host-dev);
+
Ditto
clk_put(host-fclk);
clk_put(host-iclk);
if (host-got_dbclk) {
@@ -2272,7 +2221,7 @@ static int omap_hsmmc_suspend(struct device *dev)
OMAP_HSMMC_WRITE(host-base, HCTL,
OMAP_HSMMC_READ(host-base, HCTL) ~SDBP);
mmc_host_disable(host-mmc);
- clk_disable(host-iclk);
+
if (host-got_dbclk)
clk_disable(host-dbclk);
} else {
@@ -2287,6 +2236,11 @@ static int omap_hsmmc_suspend(struct device *dev)
mmc_host_disable(host-mmc);
}
+ /*
+ * HACK: extra put to compensate for DPM core keeping
+ * runtime PM disabled. -- khilman
+ */
+ pm_runtime_put_sync(host-dev);
}
return ret;
}
@@ -2302,12 +2256,14 @@ static int omap_hsmmc_resume(struct device *dev)
return 0;
if (host) {
- ret = clk_enable(host-iclk);
- if (ret)
- goto clk_en_err;
+ /*
+ * HACK: extra get to compensate for DPM core keeping
+ * runtime PM disabled. -- khilman
+ */
+ pm_runtime_get_sync(host-dev);
if (mmc_host_enable(host-mmc) != 0) {
- clk_disable(host-iclk);
+ pm_runtime_suspend(host-dev);
goto clk_en_err;
}
@@ -2346,9 +2302,37 @@ clk_en_err:
#define omap_hsmmc_resumeNULL
#endif
+/* called just before device is disabled */
+static int omap_hsmmc_runtime_suspend(struct device *dev)
+{
+ struct omap_hsmmc_host *host;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ host = platform_get_drvdata(to_platform_device(dev));
+ omap_hsmmc_context_save(host);
The context_save fn is now empty. How does it help here?
+
+ return 0;
+}
+
+/* called after device is (re)enabled, ONLY if context was lost */
+static int omap_hsmmc_runtime_resume(struct device *dev)
+{
+ struct omap_hsmmc_host *host;
+
+ dev_dbg(dev, %s\n, __func__);
+
+ host = platform_get_drvdata(to_platform_device(dev));
+ omap_hsmmc_context_restore(host);
+
+ return 0;
+}
+
static struct dev_pm_ops omap_hsmmc_dev_pm_ops = {
.suspend= omap_hsmmc_suspend,
.resume = omap_hsmmc_resume,
+ .runtime_suspend = omap_hsmmc_runtime_suspend,
+ .runtime_resume = omap_hsmmc_runtime_resume,
};
static struct platform_driver omap_hsmmc_driver = {
--
1.6.6
--
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-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP: Fix for bus width which improves SD card's peformance.
-Original Message- From: kishore kadiyala [mailto:kishore.kadiy...@ti.com] Sent: Thursday, February 11, 2010 8:20 AM To: linux-omap@vger.kernel.org; linux-ker...@vger.kernel.org Cc: jarkko.lavi...@nokia.com; madhu...@ti.com Subject: [PATCH] OMAP: Fix for bus width which improves SD card's peformance. This patch improves low speeds for SD cards. OMAP-MMC controller's can support maximum bus width of '8'. when bus width is mentioned as 8 in controller data,the SD stack will check whether bus width is 4 and if not it will set bus width to 1 and there by degrading peformance. This patch fixes the issue and improves the performance of SD cards. Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com ACK Acked-by: Madhusudhan Chikkature madhu...@ti.com --- Here are my experiment numbers, on a Class 6 SDHC card: Read peformance is increased by 220% Write Performance is increased by 52% drivers/mmc/host/omap_hsmmc.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c index 83f0aff..8c97c22 100644 --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -2092,7 +2092,7 @@ static int __init omap_hsmmc_probe(struct platform_device *pdev) MMC_CAP_WAIT_WHILE_BUSY; if (mmc_slot(host).wires = 8) - mmc-caps |= MMC_CAP_8_BIT_DATA; + mmc-caps |= (MMC_CAP_8_BIT_DATA | MMC_CAP_4_BIT_DATA); else if (mmc_slot(host).wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; -- 1.6.3.3 -- 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
RE: [PATCH] OMAP2/3: update default defconfig, towards smaller kernel
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Friday, January 29, 2010 6:27 PM To: linux-omap@vger.kernel.org Subject: [PATCH] OMAP2/3: update default defconfig, towards smaller kernel Update omap3_defconfig to work towards a minimal kernel by building most things as modules. Some drivers that cannot currently be built as modules and need to be fixed: - MMC: platform code uses MMC core regulator functions directly The below series posted to LO by Adrian fixes this issue. The core regulator calls are moved into the controller driver. [PATCH V2 0/10] omap_hsmmc changes V2 Regards, Madhu - ASoC: drivers call omap_ctrl_[read|write] directly In addition some additional changes: - use new SLUB allocator instead of SLAB (increased debugability) - compile with PREEMPT enabled by default - disable OABI_COMPAT. We should not pretend to support this IMHO - disable CPUfreq: not yet supported in mainline - disable PM_DEBUG_VERBOSE - enable fb/DSS2 as modules - disable Kprobes zImage size comparison before: 3160272 after: 2610108 Some ideas for reducing this further: - fix MMC and ASoC, then build those as modules - disable all the kernel debug features - convert MTD and all flash fs to modules Then, we should have platform specific initramfs configs so rootfs from flash, MMC, etc. could be done using modules in initramfs. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/configs/omap3_defconfig | 215 - - 1 files changed, 112 insertions(+), 103 deletions(-) diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig index 2bc80d7..247f191 100644 --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.33-rc5 -# Tue Jan 26 11:05:31 2010 +# Fri Jan 29 16:02:40 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -32,6 +32,7 @@ CONFIG_CONSTRUCTORS=y # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y @@ -105,16 +106,16 @@ CONFIG_AIO=y # Kernel Performance Events And Counters # CONFIG_VM_EVENT_COUNTERS=y +# CONFIG_SLUB_DEBUG is not set CONFIG_COMPAT_BRK=y -CONFIG_SLAB=y -# CONFIG_SLUB is not set +# CONFIG_SLAB is not set +CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y -CONFIG_OPROFILE=y +CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y -CONFIG_KPROBES=y -CONFIG_KRETPROBES=y +# CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y @@ -125,7 +126,6 @@ CONFIG_HAVE_CLK=y # CONFIG_GCOV_KERNEL is not set # CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y -CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y @@ -251,7 +251,7 @@ CONFIG_OMAP_MUX=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_OMAP_MUX_WARNINGS=y CONFIG_OMAP_MCBSP=y -# CONFIG_OMAP_MBOX_FWK is not set +CONFIG_OMAP_MBOX_FWK=m # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_32K_TIMER_HZ=128 @@ -354,13 +354,14 @@ CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 -CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set -# CONFIG_PREEMPT is not set +CONFIG_PREEMPT=y CONFIG_HZ=128 # CONFIG_THUMB2_KERNEL is not set CONFIG_AEABI=y -CONFIG_OABI_COMPAT=y +# CONFIG_OABI_COMPAT is not set +CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set # CONFIG_HIGHMEM is not set @@ -394,21 +395,12 @@ CONFIG_ATAGS_PROC=y # # CPU Power Management # -CONFIG_CPU_FREQ=y -CONFIG_CPU_FREQ_TABLE=y -# CONFIG_CPU_FREQ_DEBUG is not set -CONFIG_CPU_FREQ_STAT=y -CONFIG_CPU_FREQ_STAT_DETAILS=y -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y +# CONFIG_CPU_FREQ is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set -CONFIG_CPU_FREQ_GOV_PERFORMANCE=y -# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set -CONFIG_CPU_FREQ_GOV_USERSPACE=y -CONFIG_CPU_FREQ_GOV_ONDEMAND=y -# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # CONFIG_CPU_IDLE is not set # @@ -439,11 +431,10 @@ CONFIG_BINFMT_MISC=y # CONFIG_PM=y CONFIG_PM_DEBUG=y -CONFIG_PM_VERBOSE=y +# CONFIG_PM_VERBOSE is not set CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y -# CONFIG_PM_TEST_SUSPEND is not set CONFIG_SUSPEND_FREEZER=y # CONFIG_APM_EMULATION is not set
RE: [PATCH] OMAP2/3: update default defconfig, towards smaller kernel
-Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap- ow...@vger.kernel.org] On Behalf Of Kevin Hilman Sent: Friday, January 29, 2010 6:27 PM To: linux-omap@vger.kernel.org Subject: [PATCH] OMAP2/3: update default defconfig, towards smaller kernel Update omap3_defconfig to work towards a minimal kernel by building most things as modules. Some drivers that cannot currently be built as modules and need to be fixed: - MMC: platform code uses MMC core regulator functions directly The below series posted to LO by Adrian fixes this issue. The core regulator calls are moved into the controller driver. [PATCH V2 0/10] omap_hsmmc changes V2 Regards, Madhu - ASoC: drivers call omap_ctrl_[read|write] directly In addition some additional changes: - use new SLUB allocator instead of SLAB (increased debugability) - compile with PREEMPT enabled by default - disable OABI_COMPAT. We should not pretend to support this IMHO - disable CPUfreq: not yet supported in mainline - disable PM_DEBUG_VERBOSE - enable fb/DSS2 as modules - disable Kprobes zImage size comparison before: 3160272 after: 2610108 Some ideas for reducing this further: - fix MMC and ASoC, then build those as modules - disable all the kernel debug features - convert MTD and all flash fs to modules Then, we should have platform specific initramfs configs so rootfs from flash, MMC, etc. could be done using modules in initramfs. Signed-off-by: Kevin Hilman khil...@deeprootsystems.com --- arch/arm/configs/omap3_defconfig | 215 - - 1 files changed, 112 insertions(+), 103 deletions(-) diff --git a/arch/arm/configs/omap3_defconfig b/arch/arm/configs/omap3_defconfig index 2bc80d7..247f191 100644 --- a/arch/arm/configs/omap3_defconfig +++ b/arch/arm/configs/omap3_defconfig @@ -1,7 +1,7 @@ # # Automatically generated make config: don't edit # Linux kernel version: 2.6.33-rc5 -# Tue Jan 26 11:05:31 2010 +# Fri Jan 29 16:02:40 2010 # CONFIG_ARM=y CONFIG_SYS_SUPPORTS_APM_EMULATION=y @@ -32,6 +32,7 @@ CONFIG_CONSTRUCTORS=y # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y @@ -105,16 +106,16 @@ CONFIG_AIO=y # Kernel Performance Events And Counters # CONFIG_VM_EVENT_COUNTERS=y +# CONFIG_SLUB_DEBUG is not set CONFIG_COMPAT_BRK=y -CONFIG_SLAB=y -# CONFIG_SLUB is not set +# CONFIG_SLAB is not set +CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_TRACEPOINTS=y -CONFIG_OPROFILE=y +CONFIG_OPROFILE=m CONFIG_HAVE_OPROFILE=y -CONFIG_KPROBES=y -CONFIG_KRETPROBES=y +# CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_CLK=y @@ -125,7 +126,6 @@ CONFIG_HAVE_CLK=y # CONFIG_GCOV_KERNEL is not set # CONFIG_SLOW_WORK is not set CONFIG_HAVE_GENERIC_DMA_COHERENT=y -CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y CONFIG_BASE_SMALL=0 CONFIG_MODULES=y @@ -251,7 +251,7 @@ CONFIG_OMAP_MUX=y CONFIG_OMAP_MUX_DEBUG=y CONFIG_OMAP_MUX_WARNINGS=y CONFIG_OMAP_MCBSP=y -# CONFIG_OMAP_MBOX_FWK is not set +CONFIG_OMAP_MBOX_FWK=m # CONFIG_OMAP_MPU_TIMER is not set CONFIG_OMAP_32K_TIMER=y CONFIG_OMAP_32K_TIMER_HZ=128 @@ -354,13 +354,14 @@ CONFIG_VMSPLIT_3G=y # CONFIG_VMSPLIT_2G is not set # CONFIG_VMSPLIT_1G is not set CONFIG_PAGE_OFFSET=0xC000 -CONFIG_PREEMPT_NONE=y +# CONFIG_PREEMPT_NONE is not set # CONFIG_PREEMPT_VOLUNTARY is not set -# CONFIG_PREEMPT is not set +CONFIG_PREEMPT=y CONFIG_HZ=128 # CONFIG_THUMB2_KERNEL is not set CONFIG_AEABI=y -CONFIG_OABI_COMPAT=y +# CONFIG_OABI_COMPAT is not set +CONFIG_ARCH_HAS_HOLES_MEMORYMODEL=y # CONFIG_ARCH_SPARSEMEM_DEFAULT is not set # CONFIG_ARCH_SELECT_MEMORY_MODEL is not set # CONFIG_HIGHMEM is not set @@ -394,21 +395,12 @@ CONFIG_ATAGS_PROC=y # # CPU Power Management # -CONFIG_CPU_FREQ=y -CONFIG_CPU_FREQ_TABLE=y -# CONFIG_CPU_FREQ_DEBUG is not set -CONFIG_CPU_FREQ_STAT=y -CONFIG_CPU_FREQ_STAT_DETAILS=y -CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y +# CONFIG_CPU_FREQ is not set +# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set -CONFIG_CPU_FREQ_GOV_PERFORMANCE=y -# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set -CONFIG_CPU_FREQ_GOV_USERSPACE=y -CONFIG_CPU_FREQ_GOV_ONDEMAND=y -# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set # CONFIG_CPU_IDLE is not set # @@ -439,11 +431,10 @@ CONFIG_BINFMT_MISC=y # CONFIG_PM=y CONFIG_PM_DEBUG=y -CONFIG_PM_VERBOSE=y +# CONFIG_PM_VERBOSE is not set CONFIG_CAN_PM_TRACE=y CONFIG_PM_SLEEP=y CONFIG_SUSPEND=y -# CONFIG_PM_TEST_SUSPEND is not set CONFIG_SUSPEND_FREEZER=y # CONFIG_APM_EMULATION is not set
RE: sdio irq hack for omap_hsmmc.c (was: Re: [PATCH] OMAP35xx:SDIO IRQ Support for OMAP35xx)
Hi,
I am not an SDIO expert. But what I understand from this is that we are
missing the wakeup capability on an SDIO interrupt.
Regards,
Madhu
-Original Message-
From: John Rigby [mailto:jcri...@gmail.com]
Sent: Wednesday, January 27, 2010 5:56 PM
To: Madhusudhan
Cc: Mike Rapoport; Dirk Behme; Phaneendra Kumar Alapati; linux-
o...@vger.kernel.org; linux-...@vger.kernel.org; Adrian Hunter; Paasikivi
Teemu.3 (EXT-Ixonos/Tampere)
Subject: Re: sdio irq hack for omap_hsmmc.c (was: Re: [PATCH]
OMAP35xx:SDIO IRQ Support for OMAP35xx)
Just to be clear, my post was in response to the reported problems
with enabling sdio irqs with this patch:
http://patchwork.kernel.org/patch/69122/
The patch originator reported good results but others reported
complete failure. My hack fixed the problem for me. I believe this
much more modest patch will also fix the problem but it is untested
because I don't have a board running right now. Beware, I'm sending
this from gmail so it may get line wrapped but it is a trivial patch
so I think it is understandable.
John
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index fa94580..7af970e 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -1727,10 +1727,16 @@ static int __init omap_hsmmc_probe
omap_hsmmc_context_save(host);
+#if 0
mmc-caps |= MMC_CAP_DISABLE;
mmc_set_disable_delay(mmc, OMAP_MMC_DISABLED_TIMEOUT);
/* we start off in DISABLED state */
host-dpm_state = DISABLED;
+#else
+ /* we start off in ENABLED state */
+ host-dpm_state = ENABLED;
+ clk_enable(host-fclk);
+#endif
if (mmc_host_enable(host-mmc) != 0) {
clk_put(host-iclk);
On Wed, Jan 27, 2010 at 4:14 PM, Madhusudhan madhu...@ti.com wrote:
It is hard to comment on what is happening here without a patch. Is it a
performance issue or that SDIO functionality failure with PM enabled?
The MMC controller supports wakeup capability on the dat1 line using a
GPIO
for a SDIO interrupt. I guess that should help.
Regards,
Madhu
--
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
RE: sdio irq hack for omap_hsmmc.c (was: Re: [PATCH] OMAP35xx:SDIO IRQ Support for OMAP35xx)
It is hard to comment on what is happening here without a patch. Is it a performance issue or that SDIO functionality failure with PM enabled? The MMC controller supports wakeup capability on the dat1 line using a GPIO for a SDIO interrupt. I guess that should help. Regards, Madhu -Original Message- From: John Rigby [mailto:jcri...@gmail.com] Sent: Tuesday, January 26, 2010 11:05 AM To: Mike Rapoport Cc: Dirk Behme; Phaneendra Kumar Alapati; linux-omap@vger.kernel.org; Madhusudhan Chikkature; linux-...@vger.kernel.org; Adrian Hunter; Paasikivi Teemu.3 (EXT-Ixonos/Tampere) Subject: sdio irq hack for omap_hsmmc.c (was: Re: [PATCH] OMAP35xx:SDIO IRQ Support for OMAP35xx) Attached is a hacked omap_hsmmc.c which works with libertas on my board (very similar to beagle). This is not intended to be a solution but points in the direction of the problem. I ripped out the CONFIG_PM code and turned off all the enable/disable stuff. I also explicitly turn on the fclk at probe time. I get about 11 Mbits/sec throughput with this. Again this is a hack but it shows that the likely problem has something to do with the enable/disable code. I appears that the controller is disabled (fclk turned off) and sdio irqs get dropped as a result. -- 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
RE: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc
snip My bad, please ignore. The 3rd patch in the series seems to take care of renaming these bits. Regards, Madhu Will you be Ack'ing these patches? Sure. I will do that. The changes to hsmmc look okay to me. Having the controller driver call the mmc core regulator fns is good. Regards, Madhu -- 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
RE: [PATCH V2 0/10] omap_hsmmc changes V2
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Saturday, January 16, 2010 7:33 PM
To: Tony Lindgren
Cc: Adrian Hunter; Madhusudhan Chikkature; Paul Walmsley; linux-omap
Mailing List; linux-mmc Mailing List; Andrew Morton
Subject: [PATCH V2 0/10] omap_hsmmc changes V2
Hi
Here are some changes we need for omap_hsmmc. They are dependent on OMAP
board files so it would be simplest if the patches all went via the OMAP
tree.
This is version 2 of this patch set. Thank you Tony, Paul and Madhu for
your comments.
Changes from version 1:
- amended patch 'omap_hsmmc: Move gpio and regulator control from
board file' so that system control functions remain in the board
file
- for clarity, split patch 'omap: Rename mmc-twl4030 to hsmmc' into
'omap: Rename mmc-twl4030 files to hsmmc' and
'omap: Rename hsmmc symbols to reflect independence from twl4030'
- removed patch 'omap_hsmmc: set DVFS/PM constraints'
- added patch 'omap: Add functions for dynamic remuxing of pins'
- renamed and reworked patch 'omap: RX51: Remux to pull eMMC lines
down when powering off' (was 'omap_hsmmc: RX51: set padconfs to pull
down when powering off eMMC')
- added patch 'omap_hsmmc: Ensure regulator enable / disable are
paired'
- fixed mistakes in patch 'omap_hsmmc: Allow for a shared VccQ'
Reviewed the omap_hsmmc changes and did a sanity test on Zoom2.
Acked-by: Madhusudhan Chikkature madhu...@ti.com
Regards,
Madhu
Adrian Hunter (9):
omap_hsmmc: Move gpio and regulator control from board file
omap: Rename mmc-twl4030 files to hsmmc
omap: Rename hsmmc symbols to reflect independence from twl4030
omap: Reconnect hsmmc context loss count
omap: RX51: Remux to pull eMMC lines down when powering off
omap_hsmmc: Allow for power saving without going off
omap_hsmmc: Fix disable timeouts
omap_hsmmc: Ensure regulator enable / disable are paired
omap_hsmmc: Allow for a shared VccQ
Tony Lindgren (1):
omap: Add functions for dynamic remuxing of pins
arch/arm/configs/rx51_defconfig|4 +-
arch/arm/mach-omap2/Makefile | 28 +-
arch/arm/mach-omap2/board-2430sdp.c|6 +-
arch/arm/mach-omap2/board-3430sdp.c|6 +-
arch/arm/mach-omap2/board-cm-t35.c |6 +-
arch/arm/mach-omap2/board-igep0020.c |6 +-
arch/arm/mach-omap2/board-ldp.c|6 +-
arch/arm/mach-omap2/board-omap3beagle.c|6 +-
arch/arm/mach-omap2/board-omap3evm.c |6 +-
arch/arm/mach-omap2/board-omap3pandora.c |6 +-
arch/arm/mach-omap2/board-omap3touchbook.c |6 +-
arch/arm/mach-omap2/board-overo.c |6 +-
arch/arm/mach-omap2/board-rx51-peripherals.c | 63 +++-
arch/arm/mach-omap2/board-zoom-peripherals.c |6 +-
arch/arm/mach-omap2/hsmmc.c| 261
arch/arm/mach-omap2/{mmc-twl4030.h = hsmmc.h} | 14 +-
arch/arm/mach-omap2/mmc-twl4030.c | 537 ---
-
arch/arm/mach-omap2/mux.c | 22 +-
arch/arm/mach-omap2/mux.h | 24 +
arch/arm/plat-omap/include/plat/mmc.h | 35 ++-
drivers/mmc/host/omap_hsmmc.c | 375 -
21 files changed, 788 insertions(+), 641 deletions(-)
create mode 100644 arch/arm/mach-omap2/hsmmc.c
rename arch/arm/mach-omap2/{mmc-twl4030.h = hsmmc.h} (63%)
delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.c
Regards
Adrian
--
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
RE: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc
-Original Message- From: Adrian Hunter [mailto:adrian.hun...@nokia.com] Sent: Saturday, January 16, 2010 7:33 PM To: Tony Lindgren Cc: Adrian Hunter; Madhusudhan Chikkature; Paul Walmsley; linux-omap Mailing List; linux-mmc Mailing List; Andrew Morton Subject: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc From a65fae702aa81d4596d6fbefd2ab3c8ea87c244a Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Sun, 17 Jan 2010 02:34:22 +0200 Subject: [PATCH] omap: Rename mmc-twl4030 files to hsmmc mmc-twl4030.[ch] no longer has any dependency on twl4030 and should be renamed to reflect that. Signed-off-by: Adrian Hunter adrian.hun...@nokia.com --- arch/arm/mach-omap2/Makefile | 28 ++-- arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c|2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |2 +- arch/arm/mach-omap2/hsmmc.c | 247 ++ arch/arm/mach-omap2/hsmmc.h | 34 arch/arm/mach-omap2/mmc-twl4030.c| 247 - - arch/arm/mach-omap2/mmc-twl4030.h| 34 17 files changed, 307 insertions(+), 307 deletions(-) create mode 100644 arch/arm/mach-omap2/hsmmc.c create mode 100644 arch/arm/mach-omap2/hsmmc.h delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.c delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index b32678b..a7e4c5a 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -71,42 +71,42 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y) obj-$(CONFIG_MACH_OMAP_GENERIC) += board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP) += board-2430sdp.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP_APOLLON) += board-apollon.o obj-$(CONFIG_MACH_OMAP3_BEAGLE) += board-omap3beagle.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP_LDP) += board-ldp.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OVERO) += board-overo.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP3EVM) += board-omap3evm.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP_3430SDP) += board-3430sdp.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_NOKIA_N8X0)+= board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51)+= board-rx51.o \ board-rx51-sdram.o \ board-rx51-peripherals.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_OMAP_ZOOM2)+= board-zoom2.o \ board-zoom-peripherals.o \ -mmc-twl4030.o \ +hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_ZOOM3)+= board-zoom3.o \ board-zoom-peripherals.o \ -mmc-twl4030.o \ +hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_3630SDP) += board-3630sdp.o \ board-zoom-peripherals.o \ -mmc-twl4030.o +hsmmc.o obj-$(CONFIG_MACH_CM_T35)+= board-cm-t35.o \ -mmc-twl4030.o
RE: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc
-Original Message- From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc- ow...@vger.kernel.org] On Behalf Of Madhusudhan Sent: Wednesday, January 20, 2010 5:42 PM To: 'Adrian Hunter'; 'Tony Lindgren' Cc: 'Paul Walmsley'; 'linux-omap Mailing List'; 'linux-mmc Mailing List'; 'Andrew Morton' Subject: RE: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc -Original Message- From: Adrian Hunter [mailto:adrian.hun...@nokia.com] Sent: Saturday, January 16, 2010 7:33 PM To: Tony Lindgren Cc: Adrian Hunter; Madhusudhan Chikkature; Paul Walmsley; linux-omap Mailing List; linux-mmc Mailing List; Andrew Morton Subject: [PATCH V2 2/10] omap: Rename mmc-twl4030 files to hsmmc From a65fae702aa81d4596d6fbefd2ab3c8ea87c244a Mon Sep 17 00:00:00 2001 From: Adrian Hunter adrian.hun...@nokia.com Date: Sun, 17 Jan 2010 02:34:22 +0200 Subject: [PATCH] omap: Rename mmc-twl4030 files to hsmmc mmc-twl4030.[ch] no longer has any dependency on twl4030 and should be renamed to reflect that. Signed-off-by: Adrian Hunter adrian.hun...@nokia.com --- arch/arm/mach-omap2/Makefile | 28 ++-- arch/arm/mach-omap2/board-2430sdp.c |2 +- arch/arm/mach-omap2/board-3430sdp.c |2 +- arch/arm/mach-omap2/board-cm-t35.c |2 +- arch/arm/mach-omap2/board-igep0020.c |2 +- arch/arm/mach-omap2/board-ldp.c |2 +- arch/arm/mach-omap2/board-omap3beagle.c |2 +- arch/arm/mach-omap2/board-omap3evm.c |2 +- arch/arm/mach-omap2/board-omap3pandora.c |2 +- arch/arm/mach-omap2/board-omap3touchbook.c |2 +- arch/arm/mach-omap2/board-overo.c|2 +- arch/arm/mach-omap2/board-rx51-peripherals.c |2 +- arch/arm/mach-omap2/board-zoom-peripherals.c |2 +- arch/arm/mach-omap2/hsmmc.c | 247 ++ arch/arm/mach-omap2/hsmmc.h | 34 arch/arm/mach-omap2/mmc-twl4030.c| 247 --- -- - arch/arm/mach-omap2/mmc-twl4030.h| 34 17 files changed, 307 insertions(+), 307 deletions(-) create mode 100644 arch/arm/mach-omap2/hsmmc.c create mode 100644 arch/arm/mach-omap2/hsmmc.h delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.c delete mode 100644 arch/arm/mach-omap2/mmc-twl4030.h diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile index b32678b..a7e4c5a 100644 --- a/arch/arm/mach-omap2/Makefile +++ b/arch/arm/mach-omap2/Makefile @@ -71,42 +71,42 @@ obj-y += $(i2c-omap-m) $(i2c-omap-y) obj-$(CONFIG_MACH_OMAP_GENERIC)+= board-generic.o obj-$(CONFIG_MACH_OMAP_H4) += board-h4.o obj-$(CONFIG_MACH_OMAP_2430SDP)+= board-2430sdp.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP_APOLLON)+= board-apollon.o obj-$(CONFIG_MACH_OMAP3_BEAGLE)+= board-omap3beagle.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP_LDP)+= board-ldp.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OVERO) += board-overo.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP3EVM)+= board-omap3evm.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP3_PANDORA) += board-omap3pandora.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP_3430SDP)+= board-3430sdp.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_NOKIA_N8X0) += board-n8x0.o obj-$(CONFIG_MACH_NOKIA_RX51) += board-rx51.o \ board-rx51-sdram.o \ board-rx51-peripherals.o \ - mmc-twl4030.o + hsmmc.o obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom2.o \ board-zoom-peripherals.o \ - mmc-twl4030.o \ + hsmmc.o \ board-zoom-debugboard.o obj-$(CONFIG_MACH_OMAP_ZOOM3) += board-zoom3.o \ board-zoom-peripherals.o \ - mmc-twl4030.o \ + hsmmc.o
RE: [PATCH 1/8] omap_hsmmc: move gpio and regulator control from board file
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Wednesday, January 13, 2010 5:40 AM
To: Tony Lindgren
Cc: linux-mmc Mailing List; Adrian Hunter; Andrew Morton; linux-omap
Mailing List; Madhusudhan Chikkature
Subject: [PATCH 1/8] omap_hsmmc: move gpio and regulator control from
board file
From c2ed3074a73fc13d088c53193af546c01d1061b1 Mon Sep 17 00:00:00 2001
From: Adrian Hunter adrian.hun...@nokia.com
Date: Mon, 4 Jan 2010 13:44:36 +0200
Subject: [PATCH] omap_hsmmc: move gpio and regulator control from board
file
This patch moves the setup code for GPIO's and Voltage
Regulators from the board file mmc-twl4030.c to the
driver omap_hsmmc.c.
Moving GPIO code to the driver makes the board initialisation
code independent of when GPIO's are defined. That makes the
board initialisation now entirely independent of its original
twl4030 roots.
Moving Voltage Regulator code to the driver allows for further
development of regulator support in the core MMC code. It also
permits the MMC core to be compiled as a module, because the
board code no longer calls MMC core functions.
Signed-off-by: Adrian Hunter adrian.hun...@nokia.com
---
arch/arm/configs/rx51_defconfig |4 +-
arch/arm/mach-omap2/control.c |2 +
arch/arm/mach-omap2/mmc-twl4030.c | 419 +---
-
arch/arm/mach-omap2/mmc-twl4030.h |4 +-
arch/arm/plat-omap/include/plat/mmc.h |2 +-
drivers/mmc/host/omap_hsmmc.c | 417
+++-
6 files changed, 419 insertions(+), 429 deletions(-)
diff --git a/arch/arm/configs/rx51_defconfig
b/arch/arm/configs/rx51_defconfig
index b6eeebb..426ae94 100644
--- a/arch/arm/configs/rx51_defconfig
+++ b/arch/arm/configs/rx51_defconfig
@@ -1354,7 +1354,7 @@ CONFIG_USB_OTG_UTILS=y
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_ISP1301_OMAP is not set
CONFIG_TWL4030_USB=y
-CONFIG_MMC=y
+CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
@@ -1362,7 +1362,7 @@ CONFIG_MMC=y
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=m
-CONFIG_MMC_BLOCK_BOUNCE=y
+# CONFIG_MMC_BLOCK_BOUNCE is not set
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index cdd1f35..f3e31dc 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -162,6 +162,7 @@ u32 omap_ctrl_readl(u16 offset)
{
return __raw_readl(OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_readl);
void omap_ctrl_writeb(u8 val, u16 offset)
{
@@ -177,6 +178,7 @@ void omap_ctrl_writel(u32 val, u16 offset)
{
__raw_writel(val, OMAP_CTRL_REGADDR(offset));
}
+EXPORT_SYMBOL(omap_ctrl_writel);
#if defined(CONFIG_ARCH_OMAP3) defined(CONFIG_PM)
/*
diff --git a/arch/arm/mach-omap2/mmc-twl4030.c b/arch/arm/mach-omap2/mmc-
twl4030.c
index 0c3c72d..e846d56 100644
--- a/arch/arm/mach-omap2/mmc-twl4030.c
+++ b/arch/arm/mach-omap2/mmc-twl4030.c
@@ -9,195 +9,22 @@
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
-#include linux/err.h
-#include linux/io.h
-#include linux/module.h
-#include linux/platform_device.h
-#include linux/interrupt.h
-#include linux/delay.h
-#include linux/gpio.h
-#include linux/mmc/host.h
-#include linux/regulator/consumer.h
-
+#include linux/kernel.h
+#include linux/slab.h
+#include linux/string.h
#include mach/hardware.h
-#include plat/control.h
#include plat/mmc.h
-#include plat/board.h
#include mmc-twl4030.h
-
-#if defined(CONFIG_REGULATOR) \
- (defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE))
-
-static u16 control_pbias_offset;
-static u16 control_devconf1_offset;
+#if defined(CONFIG_MMC_OMAP_HS) || defined(CONFIG_MMC_OMAP_HS_MODULE)
#define HSMMC_NAME_LEN 9
static struct twl_mmc_controller {
- struct omap_mmc_platform_data *mmc;
- /* Vcc == configured supply
- * Vcc_alt == optional
- * - MMC1, supply for DAT4..DAT7
- * - MMC2/MMC2, external level shifter voltage supply, for
- * chip (SDIO, eMMC, etc) or transceiver (MMC2 only)
- */
- struct regulator*vcc;
- struct regulator*vcc_aux;
charname[HSMMC_NAME_LEN + 1];
} hsmmc[OMAP34XX_NR_MMC];
-static int twl_mmc_card_detect(int irq)
-{
- unsigned i;
-
- for (i = 0; i ARRAY_SIZE(hsmmc); i++) {
- struct omap_mmc_platform_data *mmc;
-
- mmc = hsmmc[i].mmc;
- if (!mmc)
- continue;
- if (irq != mmc-slots[0].card_detect_irq)
- continue;
-
- /* NOTE: assumes card detect signal is active-low */
- return !gpio_get_value_cansleep(mmc-slots[0
RE: Question about omap_hsmmc driver
Hi Enric, You see from the log there is a timeout on CMD5. This could happen because of multiple reasons. One of them is muxing of CMD/CLK lines. Or it could be due to negotiation of voltage. I would look at these things first. Regards, Madhu From: Enric Balletbò i Serra [mailto:eballe...@gmail.com] Sent: Tuesday, January 05, 2010 10:44 AM To: linux-omap@vger.kernel.org; madhu...@ti.com Subject: Question about omap_hsmmc driver Hi all, I'm having problems trying to run the SDIO WLAN module on my IGEP v2 board using the latest omap kernel (2.6.33-rc2). The SDIO WLAN module is connected to the MMC2 using 4 wires. With an older kernel ( 2.6.28 ) works fine but the same configuration with 2.6.33-rc2 do not detect the SDIO card. Any idea to solve the problem ? There is a substantial modification in this driver. Any help will be appreciated. I attached the log. Thanks in advance, Enric [ 24.521484] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522003] mmc1: clock 0Hz busmode 1 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 24.522033] mmci-omap-hs mmci-omap-hs.1: ENABLED - DISABLED [ 24.522308] mmci-omap-hs mmci-omap-hs.1: DISABLED - ENABLED [ 24.522338] mmc1: clock 0Hz busmode 1 powermode 1 cs 0 Vdd 65535 width 0 timing 0 [ 24.545104] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.568298] mmc1: clock 40Hz busmode 1 powermode 2 cs 1 Vdd 65535 width 0 timing 0 [ 24.569335] mmc1: starting CMD0 arg flags 00c0 [ 24.569366] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD0, argument 0x [ 24.569519] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 1 [ 24.569549] mmc1: req done (CMD0): 0: [ 24.572540] mmc1: clock 40Hz busmode 1 powermode 2 cs 0 Vdd 65535 width 0 timing 0 [ 24.573547] mmc1: starting CMD8 arg 00aa flags 02f5 [ 24.573577] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD8, argument 0x00aa [ 24.573913] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.573913] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.573944] mmc1: req done (CMD8): -110: [ 24.575744] mmc1: starting CMD5 arg flags 02e1 [ 24.575775] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576110] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576141] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576171] mmc1: req failed (CMD5): -110, retrying... [ 24.576171] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576507] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576538] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576568] mmc1: req failed (CMD5): -110, retrying... [ 24.576568] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.576904] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.576934] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.576934] mmc1: req failed (CMD5): -110, retrying... [ 24.576965] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD5, argument 0x [ 24.577301] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.577331] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.577331] mmc1: req done (CMD5): -110: [ 24.578247] mmc1: starting CMD55 arg flags 00f5 [ 24.578247] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.578582] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.578613] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.578643] mmc1: req done (CMD55): -110: [ 24.580444] mmc1: starting CMD55 arg flags 00f5 [ 24.580474] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.580810] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.580810] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.580841] mmc1: req done (CMD55): -110: [ 24.582641] mmc1: starting CMD55 arg flags 00f5 [ 24.582672] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.583007] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.583007] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.583038] mmc1: req done (CMD55): -110: [ 24.584899] mmc1: starting CMD55 arg flags 00f5 [ 24.584899] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD55, argument 0x [ 24.585235] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [ 24.585266] mmci-omap-hs mmci-omap-hs.1: MMC IRQ 0x18000 : ERRI CTO [ 24.585296] mmc1: req done (CMD55): -110: [ 24.587097] mmc1: starting CMD1 arg flags 00e1 [ 24.587097] mmci-omap-hs mmci-omap-hs.1: mmc1: CMD1, argument 0x [ 24.587432] mmci-omap-hs mmci-omap-hs.1: IRQ Status is 18000 [
RE: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI charger
-Original Message- From: Anton Vorontsov [mailto:avoront...@ru.mvista.com] Sent: Thursday, December 10, 2009 8:44 AM To: Felipe Balbi Cc: Grazvydas Ignotas; linux-ker...@vger.kernel.org; Madhusudhan Chikkature; linux-omap@vger.kernel.org Subject: Re: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI charger On Thu, Dec 10, 2009 at 04:21:27PM +0200, Felipe Balbi wrote: Hi, On Thu, Dec 10, 2009 at 03:18:30PM +0100, ext Anton Vorontsov wrote: Ok since it doesn't look like this will resolve soon, what about adding some DEVICE_ATTR for the time being and requiring userspace to write charge current here to start actual charging? Works for me. Let's think of the kernel charging support as an yet unimplemented feature. but if you guys are ok with this one for now. It can always be changed later :-) Yep. The only thing I'm afraid of is that once the driver is in, then nobody will bother with improving it to do the right thing. But an imperfect driver is better than none. So, what is the conclusion then? Are you planning to push the BCI charger patch currently and handle updates later? Regards, Madhu Thanks, -- Anton Vorontsov email: cbouatmai...@gmail.com irc://irc.freenode.net/bd2 -- 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
RE: [PATCH]OMAP35xx:SDIO IRQ Support for OMAP35xx
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Madhusudhan
Sent: Thursday, December 10, 2009 11:32 AM
To: 'Adrian Hunter'; 'Phaneedra Kumar Alapati'; 'Dirk Behme'
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; 'Paasikivi
Teemu.3 (EXT-Ixonos/Tampere)'
Subject: RE: [PATCH]OMAP35xx:SDIO IRQ Support for OMAP35xx
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Thursday, December 10, 2009 3:20 AM
To: Phaneedra Kumar Alapati
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Madhusudhan
Chikkature; Adrian Hunter; Paasikivi Teemu.3 (EXT-Ixonos/Tampere)
Subject: Re: [PATCH]OMAP35xx:SDIO IRQ Support for OMAP35xx
CC'ing linux-mmc list and the maintainer Madhusudhan Chikkature
and others who might be interested.
I and Dirk had reviewed this patch previously on LO.
Dirk?
Also, the patch seems to have some issue. The checkpatch.pl through the
below error.
ERROR: patch seems to be corrupt (line wrapped?)
#42: FILE: drivers/mmc/host/omap_hsmmc.c:440:
struct mmc_command *cmd,
total: 1 errors, 0 warnings, 123 lines checked
sdio/OMAP35xx.patch has style problems, please review. If any of these
errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Original Message
From: Phaneedra Kumar Alapati ph...@embwise.com
To: linux-omap@vger.kernel.org linux-omap@vger.kernel.org
CC: ph...@embwise.com ph...@embwise.com
Date: Thu, 10 Dec 2009 08:24:57 +0100
Subject: [PATCH]OMAP35xx:SDIO IRQ Support for OMAP35xx
Thread-Topic: [PATCH]OMAP35xx:SDIO IRQ Support for OMAP35xx
Thread-Index: Acp5aeARQUQJtw2USfCUiuj07cawqQ==
Message-ID: 8b7fc6a3798741d6b3e3284e1a8d7...@embwise16de1b5
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink)
Did you also test MMC/SD cards just to make sure that memory cards
functionality is not broken in any way? Just a sanity check.
Signed-off-by: Phaneendra Kumar ph...@embwise.com
Hi Phaneedra,
Overall the patch looks good based on the previous thread of discussion we
had in LO. Can you please resend the patch using git send email so that
lines are not wrapped?
Regards,
Madhu
---
drivers/mmc/host/omap_hsmmc.c | 55
1 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..fa94580 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -100,6 +100,10 @@
#define SRD(1 26)
#define SOFTRESET (1 1)
#define RESETDONE (1 0)
+#define CIRQ (1 8)
+#define CIRQ_ENABLE(1 8)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines should
come
@@ -171,6 +175,7 @@ struct omap_hsmmc_host {
int vdd;
int protect_card;
int reqs_blocked;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -436,6 +441,13 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host,
struct mmc_command *cmd,
else
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ if (host-sdio_int) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ }
+
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
if (cmd-flags MMC_RSP_136)
@@ -640,6 +652,17 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
spin_lock(host-irq_lock);
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO Card
Interrupt\n);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
OMAP_HSMMC_READ(host-base, STAT));
@@ -649,10 +672,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
return IRQ_HANDLED;
}
- data = host-data;
- status = OMAP_HSMMC_READ(host-base, STAT);
- dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
-
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1254,6 +1273,25 @@ static int
RE: [PATCH]OMAP35xx:SDIO IRQ Support for OMAP35xx
-Original Message-
From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
Sent: Thursday, December 10, 2009 3:20 AM
To: Phaneedra Kumar Alapati
Cc: linux-omap@vger.kernel.org; linux-...@vger.kernel.org; Madhusudhan
Chikkature; Adrian Hunter; Paasikivi Teemu.3 (EXT-Ixonos/Tampere)
Subject: Re: [PATCH]OMAP35xx:SDIO IRQ Support for OMAP35xx
CC'ing linux-mmc list and the maintainer Madhusudhan Chikkature
and others who might be interested.
I and Dirk had reviewed this patch previously on LO.
Dirk?
Also, the patch seems to have some issue. The checkpatch.pl through the
below error.
ERROR: patch seems to be corrupt (line wrapped?)
#42: FILE: drivers/mmc/host/omap_hsmmc.c:440:
struct mmc_command *cmd,
total: 1 errors, 0 warnings, 123 lines checked
sdio/OMAP35xx.patch has style problems, please review. If any of these
errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
Original Message
From: Phaneedra Kumar Alapati ph...@embwise.com
To: linux-omap@vger.kernel.org linux-omap@vger.kernel.org
CC: ph...@embwise.com ph...@embwise.com
Date: Thu, 10 Dec 2009 08:24:57 +0100
Subject: [PATCH]OMAP35xx:SDIO IRQ Support for OMAP35xx
Thread-Topic: [PATCH]OMAP35xx:SDIO IRQ Support for OMAP35xx
Thread-Index: Acp5aeARQUQJtw2USfCUiuj07cawqQ==
Message-ID: 8b7fc6a3798741d6b3e3284e1a8d7...@embwise16de1b5
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink)
Did you also test MMC/SD cards just to make sure that memory cards
functionality is not broken in any way? Just a sanity check.
Signed-off-by: Phaneendra Kumar ph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c | 55
1 files changed, 49 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 4b23225..fa94580 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -100,6 +100,10 @@
#define SRD (1 26)
#define SOFTRESET(1 1)
#define RESETDONE(1 0)
+#define CIRQ (1 8)
+#define CIRQ_ENABLE (1 8)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -171,6 +175,7 @@ struct omap_hsmmc_host {
int vdd;
int protect_card;
int reqs_blocked;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -436,6 +441,13 @@ omap_hsmmc_start_command(struct omap_hsmmc_host
*host,
struct mmc_command *cmd,
else
OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ if (host-sdio_int) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ }
+
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
if (cmd-flags MMC_RSP_136)
@@ -640,6 +652,17 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
spin_lock(host-irq_lock);
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc), SDIO Card
Interrupt\n);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
OMAP_HSMMC_READ(host-base, STAT));
@@ -649,10 +672,6 @@ static irqreturn_t omap_hsmmc_irq(int irq, void
*dev_id)
return IRQ_HANDLED;
}
- data = host-data;
- status = OMAP_HSMMC_READ(host-base, STAT);
- dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
-
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
omap_hsmmc_report_irq(host, status);
@@ -1254,6 +1273,25 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return mmc_slot(host).get_ro(host-dev, 0);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct omap_hsmmc_host *host = mmc_priv(mmc);
+
+ host-sdio_int = enable;
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) | CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) | CIRQ_ENABLE));
+ } else {
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) (~CIRQ_ENABLE
RE: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI charger
-Original Message-
From: Grazvydas Ignotas [mailto:nota...@gmail.com]
Sent: Monday, November 30, 2009 3:33 PM
To: Madhusudhan
Cc: linux-ker...@vger.kernel.org; Anton Vorontsov; linux-
o...@vger.kernel.org
Subject: Re: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI
charger
On Mon, Nov 30, 2009 at 8:45 PM, Madhusudhan madhu...@ti.com wrote:
-Original Message-
From: Grazvydas Ignotas [mailto:nota...@gmail.com]
Sent: Friday, November 27, 2009 8:44 AM
To: linux-ker...@vger.kernel.org
Cc: Anton Vorontsov; Madhusudhan Chikkature; linux-
o...@vger.kernel.org;
Grazvydas Ignotas
Subject: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI
charger
TWL4030/TPS65950 is a multi-function device with integrated charger,
which allows charging from AC or USB. This driver enables the
charger and provides several monitoring functions.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
For this driver to work, TWL4030-core needs to be patched to use
correct macros so that it registers twl4030_bci platform_device.
I'll send patches for this later.
drivers/power/Kconfig |7 +
drivers/power/Makefile |1 +
drivers/power/twl4030_charger.c | 499
Is the file name changed from twl4030_bci_battery.c to twl4030_charger.c
because it mainly supports voltage monitoring only while charging? If yes,
potentially we can add support for monitoring also in discharge state. Do
we intend to change the file name then?
Does the hardware support any monitoring in discharge state? I'm
unable to get any readings, only frozen values (that never update)
from what it had when it was charging. Here is TI confirmation that at
least temperature monitoring won't work while discharging:
http://e2e.ti.com/forums/p/8202/31818.aspx#31818
For this reason I consider BCI a charger.
In the discharge path BCI might not update the registers. It is worth
experiment to try and use MADC conversion to get the values. A driver for
madc is being currently discussed. See the patch:
http://patchwork.kernel.org/patch/62746/
We can try this once the madc driver is accepted in mainline and submit an
update patch to the BCI driver. As a first step I agree that the current BCI
patch should go upstream.
Reviewed-by: Madhusudhan Chikkature madhu...@ti.com
Thanks,
Madhu
Also adding the tested-on info could be helpful here.
ok
snip
+ case POWER_SUPPLY_PROP_VOLTAGE_NOW:
+ /* charging must be active for meaningful result */
+ if (!is_charging) {
How about putting a kern_info here?
That would potentially flood dmesg, will just return -EINVAL like
Anton suggests.
+ val-intval = 0;
+ break;
+ }
+ ret = twl4030_get_voltage(voltage_reg);
+ if (ret 0)
+ return ret;
+ val-intval = ret;
+ break;
+ case POWER_SUPPLY_PROP_CURRENT_NOW:
+ if (!is_charging) {
+ val-intval = 0;
Ditto
+ break;
+ }
+ /* current measurement is shared between AC and USB */
+ ret = twl4030_charger_get_current();
+ if (ret 0)
+ return ret;
+ val-intval = ret;
+ break;
+ case POWER_SUPPLY_PROP_ONLINE:
Does this indicate the source of charging like USB or AC??
There are 2 charging devices registered now, AC and USB, each returns
it's state. This is what most other drivers do.
I'll send v2 later, it will also have more accurate voltage formulas I
got from TI.
--
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
RE: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI charger
-Original Message-
From: Grazvydas Ignotas [mailto:nota...@gmail.com]
Sent: Friday, November 27, 2009 8:44 AM
To: linux-ker...@vger.kernel.org
Cc: Anton Vorontsov; Madhusudhan Chikkature; linux-omap@vger.kernel.org;
Grazvydas Ignotas
Subject: [PATCH] power_supply: Add driver for TWL4030/TPS65950 BCI charger
TWL4030/TPS65950 is a multi-function device with integrated charger,
which allows charging from AC or USB. This driver enables the
charger and provides several monitoring functions.
Signed-off-by: Grazvydas Ignotas nota...@gmail.com
---
For this driver to work, TWL4030-core needs to be patched to use
correct macros so that it registers twl4030_bci platform_device.
I'll send patches for this later.
drivers/power/Kconfig |7 +
drivers/power/Makefile |1 +
drivers/power/twl4030_charger.c | 499
Is the file name changed from twl4030_bci_battery.c to twl4030_charger.c
because it mainly supports voltage monitoring only while charging? If yes,
potentially we can add support for monitoring also in discharge state. Do we
intend to change the file name then?
Also adding the tested-on info could be helpful here.
+++
3 files changed, 507 insertions(+), 0 deletions(-)
create mode 100644 drivers/power/twl4030_charger.c
diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index cea6cef..95d7e60 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -110,4 +110,11 @@ config CHARGER_PCF50633
help
Say Y to include support for NXP PCF50633 Main Battery Charger.
+config CHARGER_TWL4030
+ tristate OMAP TWL4030 BCI charger driver
+ depends on TWL4030_CORE
+ default y
+ help
+ Say Y here to enable support for TWL4030 Battery Charge Interface.
+
endif # POWER_SUPPLY
diff --git a/drivers/power/Makefile b/drivers/power/Makefile
index b96f29d..9cea9b5 100644
--- a/drivers/power/Makefile
+++ b/drivers/power/Makefile
@@ -29,3 +29,4 @@ obj-$(CONFIG_BATTERY_BQ27x00) += bq27x00_battery.o
obj-$(CONFIG_BATTERY_DA9030) += da9030_battery.o
obj-$(CONFIG_BATTERY_MAX17040) += max17040_battery.o
obj-$(CONFIG_CHARGER_PCF50633) += pcf50633-charger.o
+obj-$(CONFIG_CHARGER_TWL4030)+= twl4030_charger.o
diff --git a/drivers/power/twl4030_charger.c
b/drivers/power/twl4030_charger.c
new file mode 100644
index 000..604dd56
--- /dev/null
+++ b/drivers/power/twl4030_charger.c
@@ -0,0 +1,499 @@
+/*
+ * TWL4030/TPS65950 BCI (Battery Charger Interface) driver
+ *
+ * Copyright (C) 2009 Gražvydas Ignotas nota...@gmail.com
+ *
+ * based on twl4030_bci_battery.c by TI
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/interrupt.h
+#include linux/i2c/twl4030.h
+#include linux/power_supply.h
+
+#define REG_BCIMSTATEC 0x02
+#define REG_BCIICHG 0x08
+#define REG_BCIVAC 0x0a
+#define REG_BCIVBUS 0x0c
+#define REG_BCIMFSTS40x10
+#define REG_BCICTL1 0x23
+
+#define REG_BOOT_BCI 0x07
+#define REG_STS_HW_CONDITIONS0x0f
+
+#define BCIAUTOWEN 0x20
+#define CONFIG_DONE 0x10
+#define CVENAC 0x04
+#define BCIAUTOUSB 0x02
+#define BCIAUTOAC0x01
+#define BCIMSTAT_MASK0x3F
+#define STS_VBUS 0x80
+#define STS_CHG 0x02
+#define STS_USB_ID 0x04
+#define CGAIN0x20
+#define USBFASTMCHG 0x04
+
+#define STATEC_USB 0x10
+#define STATEC_AC0x20
+#define STATEC_STATUS_MASK 0x0f
+#define STATEC_QUICK10x02
+#define STATEC_QUICK70x07
+#define STATEC_COMPLETE1 0x0b
+#define STATEC_COMPLETE4 0x0e
+
+#define BCI_DELAY100
+
+struct twl4030_bci_device_info {
+ struct power_supply ac;
+ struct power_supply usb;
+ struct delayed_work bat_work;
+ boolstarted;
+};
+
+/*
+ * clear and set bits on an given register on a given module
+ */
+static int twl4030_clear_set(u8 mod_no, u8 clear, u8 set, u8 reg)
+{
+ u8 val = 0;
+ int ret;
+
+ ret = twl4030_i2c_read_u8(mod_no, val, reg);
+ if (ret)
+ return ret;
+
+ val = ~clear;
+ val |= set;
+
+ return twl4030_i2c_write_u8(mod_no, val, reg);
+}
+
+static int twl4030bci_read_adc_val(u8 reg)
+{
+ int ret, temp;
+ u8 val;
+
+ /* read MSB */
+ ret = twl4030_i2c_read_u8
[PATCH] Zoom2/3:Update hsmmc board config params
From: Madhusudhan Chikkature madhu...@ti.com
Subject: [PATCH] Zoom2/3:Update hsmmc board config params.
Update the hsmmc zoom peripheral configuration to support:
Power saving mode
mmc2 8-bit support
Configure mmc2 as non removable
Signed-off-by: Madhusudhan Chikkature madhu...@ti.com
---
arch/arm/mach-omap2/board-zoom-peripherals.c | 13 -
1 files changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/board-zoom-peripherals.c
b/arch/arm/mach-omap2/board-zoom-peripherals.c
index 221a8e3..258794d 100755
--- a/arch/arm/mach-omap2/board-zoom-peripherals.c
+++ b/arch/arm/mach-omap2/board-zoom-peripherals.c
@@ -152,14 +152,20 @@ static struct regulator_init_data zoom_vsim = {
static struct twl4030_hsmmc_info mmc[] __initdata = {
{
+ .name = external,
.mmc= 1,
.wires = 4,
.gpio_wp= -EINVAL,
+ .power_saving = true,
},
{
+ .name = internal,
.mmc= 2,
- .wires = 4,
+ .wires = 8,
+ .gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
+ .nonremovable = true,
+ .power_saving = true,
},
{} /* Terminator */
};
@@ -167,11 +173,8 @@ static struct twl4030_hsmmc_info mmc[] __initdata = {
static int zoom_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
- /* gpio + 0 is mmc0_cd (input/IRQ),
-* gpio + 1 is mmc1_cd (input/IRQ)
-*/
+ /* gpio + 0 is mmc0_cd (input/IRQ) */
mmc[0].gpio_cd = gpio + 0;
- mmc[1].gpio_cd = gpio + 1;
twl4030_mmc_init(mmc);
/* link regulators to MMC adapters ... we know the
--
1.6.0.4
--
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
RE: MMC related patches
-Original Message- From: Tony Lindgren [mailto:t...@atomide.com] Sent: Wednesday, November 11, 2009 8:30 PM To: Madhusudhan Cc: linux-omap@vger.kernel.org Subject: Re: MMC related patches * Madhusudhan madhu...@ti.com [09 16:02]: Hi Tony, Just a ping on the below patches. I did not see any comments on them. Are you planning to push them? Regards, Madhu http://marc.info/?l=linux-omapm=125668573422479w=2 http://marc.info/?l=linux-omapm=125624185318767w=2 OK, adding. http://marc.info/?l=linux-omapm=125623349405262w=2 This needs to be refreshed against board-zoom-peripherals.c now in omap for-next. But if it depends on 3630 mux patch, let's wait on that until we have the new mux framework. Sure, I will rebase and send a new patch. It should not have any dependency on 3630 mux patch. http://marc.info/?l=linux-omapm=125623339105103w=2 http://marc.info/?l=linux-omapm=125623327504912w=2 Adding. Also, this needs to be refreshed: http://patchwork.kernel.org/patch/45196/ This one is an omap4 mmc patch which is already in the tree. Why does this need to be refreshed? Regards, Madhu Thanks for summarizing the patches, that always helps. Maybe use patchwork.kernel.org links the next time, as I can directly apply from those? Or even better, just set a git branch against some static commit :) (Not against for-next as that's still changing) BTW, some of these patches I had to unwrap manually again.. Regards, Tony -- 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
MMC related patches
Hi Tony, Just a ping on the below patches. I did not see any comments on them. Are you planning to push them? Regards, Madhu http://marc.info/?l=linux-omapm=125668573422479w=2 http://marc.info/?l=linux-omapm=125624185318767w=2 http://marc.info/?l=linux-omapm=125623349405262w=2 http://marc.info/?l=linux-omapm=125623339105103w=2 http://marc.info/?l=linux-omapm=125623327504912w=2 -- 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
RE: [PATCH] OMAP35xx : Add SDIO IRQ Support for OMAP35xx
-Original Message-
From: Phaneedra Kumar Alapati [mailto:ph...@embwise.com]
Sent: Friday, November 06, 2009 3:13 AM
To: linux-omap@vger.kernel.org
Cc: 'Madhusudhan'; 'Dirk Behme'; 'Grosen Mark'; 'Gole Anant';
'Sriramakrishnan'
Subject: [PATCH] OMAP35xx : Add SDIO IRQ Support for OMAP35xx
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink).
Signed-off-by: Phaneendra Kumar Alapati ph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c | 61
-
1 files changed, 54 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 1cf9cfb..fe1a2da 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -92,6 +92,10 @@
#define DUAL_VOLT_OCR_BIT7
#define SRC (1 25)
#define SRD (1 26)
+#define CIRQ (1 8)
+#define CIRQ_ENABLE (1 8)
+#define CTPL (1 11)
+#define CLKEXTFREE (1 16)
/*
* FIXME: Most likely all the data using these _DEVID defines should come
@@ -149,6 +153,7 @@ struct mmc_omap_host {
int slot_id;
int dbclk_enabled;
int response_busy;
+ int sdio_int;
struct omap_mmc_platform_data *pdata;
};
@@ -240,8 +245,13 @@ mmc_omap_start_command(struct mmc_omap_host *host,
struct mmc_command *cmd,
* Clear status bits and enable interrupts
*/
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
- OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
This does not look like the latest code. The driver in the LO master
configures IE under the check if(host-use_dma).How come your code does
not have that? You need to rebase your patch on the latest.
+ if (host-sdio_int) {
+ OMAP_HSMMC_WRITE(host-base, ISE, (INT_EN_MASK |
CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE, (INT_EN_MASK |
CIRQ_ENABLE));
+ } else {
+ OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
+ OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ }
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
@@ -430,17 +440,26 @@ static irqreturn_t mmc_omap_irq(int irq, void
*dev_id)
struct mmc_data *data;
int end_cmd = 0, end_trans = 0, status;
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
+
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ if (status CIRQ) {
+ dev_dbg(mmc_dev(host-mmc),
+ SDIO CARD interrupt\n);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
+
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
- OMAP_HSMMC_READ(host-base, STAT));
+ OMAP_HSMMC_READ(host-base, STAT));
Nope. Looks like you missed my comment on this extra tab.
/* Flush posted write */
OMAP_HSMMC_READ(host-base, STAT);
return IRQ_HANDLED;
}
- data = host-data;
- status = OMAP_HSMMC_READ(host-base, STAT);
- dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
if (status ERR) {
#ifdef CONFIG_MMC_DEBUG
@@ -932,6 +951,29 @@ static int omap_hsmmc_get_ro(struct mmc_host *mmc)
return pdata-slots[0].get_ro(host-dev, 0);
}
+static void omap_hsmmc_enable_sdio_irq(struct mmc_host *mmc, int enable)
+{
+ struct mmc_omap_host *host = mmc_priv(mmc);
+
+ host-sdio_int = enable;
+ if (enable) {
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE) |
+ CIRQ_ENABLE));
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE) |
+ CIRQ_ENABLE));
+ } else {
+ OMAP_HSMMC_WRITE(host-base, IE,
+ (OMAP_HSMMC_READ(host-base, IE)
+ (~CIRQ_ENABLE)));
+ OMAP_HSMMC_WRITE(host-base, ISE,
+ (OMAP_HSMMC_READ(host-base, ISE)
+ (~CIRQ_ENABLE)));
+ }
+
+}
+
static void omap_hsmmc_init(struct mmc_omap_host *host)
{
u32 hctl, capa, value;
@@ -964,7 +1006,7 @@ static struct mmc_host_ops mmc_omap_ops = {
.set_ios = omap_mmc_set_ios,
.get_cd = omap_hsmmc_get_cd,
.get_ro = omap_hsmmc_get_ro,
- /* NYET -- enable_sdio_irq */
+ .enable_sdio_irq = omap_hsmmc_enable_sdio_irq,
};
static int __init
RE: [PATCH] OMAP35xx: Added SDIO IRQ support
(struct platform_device *pdev) @@ -1011,6 +1054,7 @@ static int __init omap_mmc_probe(struct platform_device *pdev) host-irq = irq; host-id= pdev-id; host-slot_id = 0; + host-sdio_int = 0; Not needed. host-mapbase = res-start; host-base = ioremap(host-mapbase, SZ_4K); @@ -1080,6 +1124,10 @@ static int __init omap_mmc_probe(struct platform_device *pdev) else if (pdata-slots[host-slot_id].wires = 4) mmc-caps |= MMC_CAP_4_BIT_DATA; + mmc-caps |= MMC_CAP_SDIO_IRQ; + OMAP_HSMMC_WRITE(host-base, CON, + OMAP_HSMMC_READ(host-base, CON) | (CTPL | CLKEXTFREE)); How about moving this to enable_sdio_irq so that these are done for SDIO alone? Also can be disabled in the same fn. Regards, Madhusudhan + omap_hsmmc_init(host); /* Select DMA lines */ -- 1.6.0.4 -- 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-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] OMAP35xx: Added SDIO IRQ support
-Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Wednesday, October 28, 2009 2:48 PM
To: Madhusudhan; 'Phaneendra Kumar Alapati'
Cc: linux-omap@vger.kernel.org
Subject: Re: [PATCH] OMAP35xx: Added SDIO IRQ support
Madhusudhan wrote:
-Original Message-
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Phaneendra Kumar Alapati
Sent: Wednesday, October 28, 2009 8:19 AM
To: linux-omap@vger.kernel.org
Subject: [PATCH] OMAP35xx: Added SDIO IRQ support
This patch adds SDIO IRQ support for omap hsmmc driver.
Signed-off-by: Phaneendra Kumar Alapati ph...@embwise.com
---
drivers/mmc/host/omap_hsmmc.c |62 ++--
1 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/omap_hsmmc.c
b/drivers/mmc/host/omap_hsmmc.c
index 1cf9cfb..a540626 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -92,6 +92,10 @@
#define DUAL_VOLT_OCR_BIT 7
#define SRC (1 25)
#define SRD (1 26)
+#define OMAP_HSMMC_CARD_INT BIT(8)
+#define SDIO_INT_EN BIT(8)
Why multiple defines of the same? One of them should be enough.
What I think meant here is
#define CIRQ (1 8)
#define CIRQ_ENABLE (1 8)
One is for the status register, the other is for the interrupt enable
registers. To be compatible with the TRM, I would use both in this way.
+#define CTPL BIT(11)
+#define CLKEXTFREEBIT(16)
Can we define them in the same way as other defines to maintain
uniformity?
Yes, ack.
/*
* FIXME: Most likely all the data using these _DEVID defines should
come
@@ -149,6 +153,7 @@ struct mmc_omap_host {
int slot_id;
int dbclk_enabled;
int response_busy;
+ int sdio_int;
What purpose does this serve? IMHO, this is not needed.
Hmm. This is set to != 0 in omap_hsmmc_enable_sdio_irq() when IRQs are
enabled. Then in mmc_omap_start_command() these interrupts are enabled
again if sdio_int is != 0. Yes, looks unneeded, indeed. But maybe
there is some trick ;)
struct omap_mmc_platform_data *pdata;
};
@@ -240,8 +245,13 @@ mmc_omap_start_command(struct mmc_omap_host
*host, struct mmc_command *cmd,
Patch is line wrapped by mailer.
* Clear status bits and enable interrupts
*/
OMAP_HSMMC_WRITE(host-base, STAT, STAT_CLEAR);
- OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
- OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ if (host-sdio_int) {
+ OMAP_HSMMC_WRITE(host-base, ISE, (INT_EN_MASK |
SDIO_INT_EN));
+ OMAP_HSMMC_WRITE(host-base, IE, (INT_EN_MASK |
SDIO_INT_EN));
Why? It is being taken care in enable_sdio_irq.
Yes, why?
+ } else {
+ OMAP_HSMMC_WRITE(host-base, ISE, INT_EN_MASK);
+ OMAP_HSMMC_WRITE(host-base, IE, INT_EN_MASK);
+ }
host-response_busy = 0;
if (cmd-flags MMC_RSP_PRESENT) {
@@ -430,17 +440,27 @@ static irqreturn_t mmc_omap_irq(int irq, void
*dev_id)
struct mmc_data *data;
int end_cmd = 0, end_trans = 0, status;
+ data = host-data;
+ status = OMAP_HSMMC_READ(host-base, STAT);
+ dev_dbg(mmc_dev(host-mmc), IRQ Status is %x\n, status);
Why are these moved up?
Yes, why? Why not move the block below down instead?
+
+ if (host-mmc-caps MMC_CAP_SDIO_IRQ) {
+ if (status OMAP_HSMMC_CARD_INT) {
+ dev_dbg(mmc_dev(host-mmc),
+ SDIO CARD interrupt status %x\n,
+ status);
+ mmc_signal_sdio_irq(host-mmc);
+ }
+ }
- It makes no sense to print status in dev_dbg here again, as it is
already printed some lines above. Something like
dev_dbg(mmc_dev(host-mmc), SDIO interrupt\n);
would be sufficient here.
- Why isn't IRQ acknowledged here? I.e. why not doing something like
OMAP_HSMMC_WRITE(host-base, IE, OMAP_HSMMC_READ(host-base, IE)
~(CIRQ_ENABLE));
here?
That is not needed because of the below implementation:
static inline void mmc_signal_sdio_irq(struct mmc_host *host)
{
host-ops-enable_sdio_irq(host, 0);
wake_up_process(host-sdio_irq_thread);
}
The host is asked to disable the irq inherently.
Regards,
Madhu
- No return IRQ_HANDLED; here? Mmm, maybe this makes sense.
if (host-mrq == NULL) {
OMAP_HSMMC_WRITE(host-base, STAT,
- OMAP_HSMMC_READ(host-base, STAT));
+ OMAP_HSMMC_READ(host-base, STAT));
This just adds a tab space. Not needed.
Ack.
/* Flush posted write */
OMAP_HSMMC_READ(host-base, STAT);
return IRQ_HANDLED;
}
- data = host-data;
- status
