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
Hi Madhu, On Wed, Sep 22, 2010 at 12:13:51PM -0500, Madhusudhan wrote: 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. No problem, I dropped this after seeing Tony's comments. I'll keep an eye out for a new patch with his ACK. Thanks, -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- 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
* 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. 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] 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.
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] OMAP4: HSMMC cmd line reset change
Hi Madhu,
On Thu, Sep 16, 2010 at 05:28:11AM +0530, Madhusudhan Chikkature wrote:
OMAP4: HSMMC cmd line reset change
Please don't repeat the subject line like this -- git am will put it
into the patch twice. You can either leave the subject line out of the
body of the mail altogether, or put Subject: in front of it.
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,
(This was line-wrapped, I fixed it.)
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
Thanks, pushed to mmc-next.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
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
