SDHCI: add quirk for data timeout value when card busy.

RFC PATCH In review Jaehoon Chung 3 participants 15 messages Nov 30, 2010 – Dec 2, 2010

Subsystems (2)

MMC, SD and SDIO Secure digital host controller interface (SDHCI) driver

lore

Share & tools

lore

Jaehoon Chung

author

2010-11-30 06:18 UTC #0 lore raw

RFC PATCH 1/1 SDHCI: add quirk for data timeout value when card busy.

This patch is added quirks for data timeout value.

Some card have problem when suspend/resume. CMD6(switch command) to switch the bus to high speed mode and to set the bus width.

After resuming, the card was initialized...in that time, some card need set a correct timeout value.
so we add SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL.

Let me know any comment, plz.

Signed-off-by Jaehoon Chung <[email protected]>

Signed-off-by Kyungmin Park <[email protected]>

---
 drivers/mmc/host/sdhci.c  |    6 +++++-
 include/linux/mmc/sdhci.h |    3 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

drivers/mmc/host/sdhci.c +5 -1

index 782c0ee..3b93d97 100644
@@ -655,8 +655,12 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
 
 	WARN_ON(host->data);
 
-	if (data == NULL)
+	if (data == NULL) {
+		if ((host->quirks & SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL) &&
+				(host->cmd->flags & MMC_RSP_BUSY))
+			sdhci_writel(host, 0xE, SDHCI_TIMEOUT_CONTROL);
 		return;
+	}
 
 	/* Sanity checks */
 	BUG_ON(data->blksz * data->blocks > 524288);

include/linux/mmc/sdhci.h +2 -1

index 1fdc673..315ff49 100644
@@ -83,7 +83,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12		(1<<28)
 /* Controller doesn't have HISPD bit field in HI-SPEED SD card */
 #define SDHCI_QUIRK_NO_HISPD_BIT			(1<<29)
-
+/* Controller need set data timeout value when card is busy */
+#define SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL		(1<<30)
 	int irq;		/* Device IRQ */
 	void __iomem *ioaddr;	/* Mapped address */

Signature · 4 lines

1.6.0.4

Thanks
Jaehoon Chung

The problem is a little more complicated then this. During out testing of multiple sd/mmc cards we found some cards that gave incorrect timeout values. The solution was to define the existing quirk to force the timeout to 0xe.

The timeout problems had nothing to do with the controller being broken nor with suspend/resume.

________________________________________
From: [email protected] [[email protected]] On Behalf Of Jaehoon Chung [[email protected]]
Sent: Monday, November 29, 2010 10:13 PM
To: [email protected]
Cc: Chris Ball; kyungmin Park; Andrew Morton; [email protected]
Subject: [RFC Patch] SDHCI: add quirk for data timeout value when card busy.

This patch is added quirks for data timeout value.

Some card have problem when suspend/resume. CMD6(switch command) to switch the bus to high speed mode and to set the bus width.

After resuming, the card was initialized...in that time, some card need set a correct timeout value.
so we add SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL.

Let me know any comment, plz.

Signed-off-by Jaehoon Chung <[email protected]>

Signed-off-by Kyungmin Park <[email protected]>

---
 drivers/mmc/host/sdhci.c  |    6 +++++-
 include/linux/mmc/sdhci.h |    3 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

drivers/mmc/host/sdhci.c +5 -1

index 782c0ee..3b93d97 100644
@@ -655,8 +655,12 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
 
        WARN_ON(host->data);
 
-       if (data == NULL)
+       if (data == NULL) {
+               if ((host->quirks & SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL) &&
+                               (host->cmd->flags & MMC_RSP_BUSY))
+                       sdhci_writel(host, 0xE, SDHCI_TIMEOUT_CONTROL);
                return;
+       }
 
        /* Sanity checks */
        BUG_ON(data->blksz * data->blocks > 524288);

include/linux/mmc/sdhci.h +2 -1

index 1fdc673..315ff49 100644
@@ -83,7 +83,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12             (1<<28)
 /* Controller doesn't have HISPD bit field in HI-SPEED SD card */
 #define SDHCI_QUIRK_NO_HISPD_BIT                       (1<<29)
-
+/* Controller need set data timeout value when card is busy */
+#define SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL               (1<<30)
        int irq;                /* Device IRQ */
        void __iomem *ioaddr;   /* Mapped address */

--
1.6.0.4

Thanks
Jaehoon Chung

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Jaehoon Chung

author

2010-11-30 07:15 UTC #2 lore raw

Hi Philip.

I know defined that quirk to force the timeout to 0xe. But..i found some card occured data timeout error when suspend/resume.

actually you can confuse quirk's name..because i use temporary that. (if need change quirk name, i can)

The problem is below.

1. card probe is done
2. card suspend entered
3. when card resuming, appeared data timeout error. then card removed.

I understood this problem that occured interrupt at incorret time. (during send cmd6, occured fire busy)
So need set timeout value at Timeout register, in order to not occur interrupt.

And this problem appeared from specific card, so i think good that used quirk

Quoted 74 lines · Philip Rakity

The problem is a little more complicated then this. During out testing of multiple sd/mmc cards we found some cards that gave incorrect timeout values. The solution was to define the existing quirk to force the timeout to 0xe.
The timeout problems had nothing to do with the controller being broken nor with suspend/resume.
________________________________________
From: [email protected] [[email protected]] On Behalf Of Jaehoon Chung [[email protected]]
Sent: Monday, November 29, 2010 10:13 PM
To: [email protected]
Cc: Chris Ball; kyungmin Park; Andrew Morton; [email protected]
Subject: [RFC Patch] SDHCI: add quirk for data timeout value when card busy.
This patch is added quirks for data timeout value.
Some card have problem when suspend/resume. CMD6(switch command) to switch the bus to high speed mode and to set the bus width.
After resuming, the card was initialized...in that time, some card need set a correct timeout value.
so we add SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL.
Let me know any comment, plz.
Signed-off-by Jaehoon Chung <[email protected]>
Signed-off-by Kyungmin Park <[email protected]>
---
 drivers/mmc/host/sdhci.c  |    6 +++++-
 include/linux/mmc/sdhci.h |    3 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)
drivers/mmc/host/sdhci.c +5 -1
index 782c0ee..3b93d97 100644
@@ -655,8 +655,12 @@ static void sdhci_prepare_data(struct sdhci_host *host, struct mmc_data *data)
 
        WARN_ON(host->data);
 
-       if (data == NULL)
+       if (data == NULL) {
+               if ((host->quirks & SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL) &&
+                               (host->cmd->flags & MMC_RSP_BUSY))
+                       sdhci_writel(host, 0xE, SDHCI_TIMEOUT_CONTROL);
                return;
+       }
 
        /* Sanity checks */
        BUG_ON(data->blksz * data->blocks > 524288);
include/linux/mmc/sdhci.h +2 -2
index 1fdc673..315ff49 100644
@@ -83,7 +83,8 @@ struct sdhci_host {
 #define SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12             (1<<28)
 /* Controller doesn't have HISPD bit field in HI-SPEED SD card */
 #define SDHCI_QUIRK_NO_HISPD_BIT                       (1<<29)
-
+/* Controller need set data timeout value when card is busy */
+#define SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL               (1<<30)
        int irq;                /* Device IRQ */
        void __iomem *ioaddr;   /* Mapped address */
 
--
1.6.0.4
Thanks
Jaehoon Chung
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Wolfram Sang

2010-11-30 09:56 UTC #3 lore raw

In reply to Jaehoon Chung

Hi,

Quoted 9 lines · Jaehoon Chung

This patch is added quirks for data timeout value.
Some card have problem when suspend/resume. CMD6(switch command) to switch the bus to high speed mode and to set the bus width.
After resuming, the card was initialized...in that time, some card need set a correct timeout value.
so we add SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL.

If this is a flaw of the _card_, why do we need a controller quirk here? Shouldn't this happen for all sdhci-controllers?

Kind regards,

Wolfram

Signature · 2 lines

Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Jaehoon Chung

author

2010-11-30 10:13 UTC #4 lore raw

Hi Wolfram.

Maybe, happen for all sdhci-controllers...

Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..

Thanks,
Jaehoon Chung

Quoted 20 lines · Wolfram Sang

Hi,
Quoted 9 lines · Jaehoon Chung
This patch is added quirks for data timeout value.
Some card have problem when suspend/resume. CMD6(switch command) to switch the bus to high speed mode and to set the bus width.
After resuming, the card was initialized...in that time, some card need set a correct timeout value.
so we add SDHCI_QUIRK_SET_DATA_TIMEOUT_VAL.
If this is a flaw of the _card_, why do we need a controller quirk here? Shouldn't this happen for all sdhci-controllers?
Kind regards,
Wolfram

Wolfram Sang

2010-11-30 10:54 UTC #5 lore raw

Quoted 2 lines

Maybe, happen for all sdhci-controllers...

My point is: If it is needed for all SDHCI-controllers, we don't need a quirk and can apply your code unconditionally.

Quoted 2 lines

Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..

Can we find out if this is a general issue?

Regards,

Wolfram

Signature · 2 lines

Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Jaehoon Chung

author

2010-11-30 11:37 UTC #6 lore raw

Quoted 5 lines

Quoted 1 line
Maybe, happen for all sdhci-controllers...
My point is: If it is needed for all SDHCI-controllers, we don't need a quirk and can apply your code unconditionally.

You're right. But i'm not sure, happen for all sdhci-controller. so i send to RFC patch..
I also hope apply my code unconditionally.

the reason using quirk...every card didn't happen this issue.. if not happen this issue, we need not set timeout value..at that time..

when needs, entered and set timeout value..(conditionally)

Quoted 5 lines

Quoted 2 lines
Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..
Can we find out if this is a general issue?

Hmm..i'm sure you can find out this issue.. Have ever find out this issue(similar case)..anybody?

Quoted 4 lines

Regards,
Wolfram

Philip Rakity

2010-11-30 16:02 UTC #7 lore raw

Can we just remove the quirk for broken timeout and just set the timeout to 0xe in sdhci.c?

The problem with the quirk is you need to know when to set it and the problem with the existing quirk is that one has to set it to work with bad cards.
________________________________________
From: [email protected] [[email protected]] On Behalf Of Jaehoon Chung [[email protected]]
Sent: Tuesday, November 30, 2010 3:37 AM
To: Wolfram Sang
Cc: [email protected]; Chris Ball; kyungmin Park; Andrew Morton; [email protected]
Subject: Re: [RFC Patch] SDHCI: add quirk for data timeout value when card busy.

Quoted 5 lines

Quoted 1 line
Maybe, happen for all sdhci-controllers...
My point is: If it is needed for all SDHCI-controllers, we don't need a quirk and can apply your code unconditionally.

You're right. But i'm not sure, happen for all sdhci-controller. so i send to RFC patch..
I also hope apply my code unconditionally.

the reason using quirk...every card didn't happen this issue.. if not happen this issue, we need not set timeout value..at that time..

when needs, entered and set timeout value..(conditionally)

Quoted 5 lines

Quoted 2 lines
Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..
Can we find out if this is a general issue?

Hmm..i'm sure you can find out this issue.. Have ever find out this issue(similar case)..anybody?

Quoted 4 lines

Regards,
Wolfram

--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Jaehoon Chung

author

2010-12-01 05:44 UTC #8 lore raw

Quoted 1 line · Philip Rakity

Can we just remove the quirk for broken timeout and just set the timeout to 0xe in sdhci.c?

you means that set the timeout to 0xe without broken timeout in sdhci.c?

Quoted 2 lines

The problem with the quirk is you need to know when to set it and the problem with the existing quirk is that one has to set it to work with bad cards.

I know when use quirk...and what use one...

Quoted 40 lines

________________________________________
From: [email protected] [[email protected]] On Behalf Of Jaehoon Chung [[email protected]]
Sent: Tuesday, November 30, 2010 3:37 AM
To: Wolfram Sang
Cc: [email protected]; Chris Ball; kyungmin Park; Andrew Morton; [email protected]
Subject: Re: [RFC Patch] SDHCI: add quirk for data timeout value when card busy.
Quoted 4 lines
Quoted 1 line
Maybe, happen for all sdhci-controllers...
My point is: If it is needed for all SDHCI-controllers, we don't need a quirk and can apply your code unconditionally.
You're right. But i'm not sure, happen for all sdhci-controller. so i send to RFC patch..
I also hope apply my code unconditionally.
the reason using quirk...every card didn't happen this issue.. if not happen this issue, we need not set timeout value..at that time..
when needs, entered and set timeout value..(conditionally)
Quoted 4 lines
Quoted 2 lines
Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..
Can we find out if this is a general issue?
Hmm..i'm sure you can find out this issue.. Have ever find out this issue(similar case)..anybody?
Quoted 4 lines
Regards,
Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Philip Rakity

2010-12-01 05:51 UTC #9 lore raw

Quoted 4 lines · Jaehoon Chung

Quoted 1 line · Philip Rakity
Can we just remove the quirk for broken timeout and just set the timeout to 0xe in sdhci.c?
you means that set the timeout to 0xe without broken timeout in sdhci.c?

yes

but I also think we should remove the quirk and change sdhci.c to use 0xe ALL THE TIME. I do not see a downside to doing this other than a longer timeout period. Considering the broken cards that are out there in practice one needs to set it to this value anyway for cards to work.

Quoted 47 lines

Quoted 3 lines
The problem with the quirk is you need to know when to set it and the problem with the existing quirk is that one has to set it to work with bad cards.
I know when use quirk...and what use one...
Quoted 40 lines
________________________________________
From: [email protected] [[email protected]] On Behalf Of Jaehoon Chung [[email protected]]
Sent: Tuesday, November 30, 2010 3:37 AM
To: Wolfram Sang
Cc: [email protected]; Chris Ball; kyungmin Park; Andrew Morton; [email protected]
Subject: Re: [RFC Patch] SDHCI: add quirk for data timeout value when card busy.
Quoted 4 lines
Quoted 1 line
Maybe, happen for all sdhci-controllers...
My point is: If it is needed for all SDHCI-controllers, we don't need a quirk and can apply your code unconditionally.
You're right. But i'm not sure, happen for all sdhci-controller. so i send to RFC patch..
I also hope apply my code unconditionally.
the reason using quirk...every card didn't happen this issue.. if not happen this issue, we need not set timeout value..at that time..
when needs, entered and set timeout value..(conditionally)
Quoted 4 lines
Quoted 2 lines
Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..
Can we find out if this is a general issue?
Hmm..i'm sure you can find out this issue.. Have ever find out this issue(similar case)..anybody?
Quoted 4 lines
Regards,
Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Jaehoon Chung

author

2010-12-01 12:29 UTC #10 lore raw

Quoted 12 lines · Philip Rakity

Quoted 3 lines · Jaehoon Chung
Quoted 1 line · Philip Rakity
Can we just remove the quirk for broken timeout and just set the timeout to 0xe in sdhci.c?
you means that set the timeout to 0xe without broken timeout in sdhci.c?
yes
but I also think we should remove the quirk and change sdhci.c to use 0xe ALL THE TIME. I do not see a downside to doing this other than a longer timeout period. Considering the broken cards that are out there in practice one needs to set it to this value anyway for cards to work.

If we set the fixed timeout value to 0xe, we should remove the broken timeout value. right. But in my patch, nevertheless i used the broken timeout value quirk, need to reset timeout value at that time. Because if didn't set timeout value, broken card fire busy state..so happen the data timeout error.

Anyway, your opinion seem good..
Thanks

Quoted 42 lines

Quoted 40 lines
Quoted 1 line
The problem with the quirk is you need to know when to set it and the problem with the existing quirk is that one has to set it to work with bad cards.
I know when use quirk...and what use one...
Quoted 37 lines
________________________________________
From: [email protected] [[email protected]] On Behalf Of Jaehoon Chung [[email protected]]
Sent: Tuesday, November 30, 2010 3:37 AM
To: Wolfram Sang
Cc: [email protected]; Chris Ball; kyungmin Park; Andrew Morton; [email protected]
Subject: Re: [RFC Patch] SDHCI: add quirk for data timeout value when card busy.
Quoted 4 lines
Quoted 1 line
Maybe, happen for all sdhci-controllers...
My point is: If it is needed for all SDHCI-controllers, we don't need a quirk and can apply your code unconditionally.
You're right. But i'm not sure, happen for all sdhci-controller. so i send to RFC patch..
I also hope apply my code unconditionally.
the reason using quirk...every card didn't happen this issue.. if not happen this issue, we need not set timeout value..at that time..
when needs, entered and set timeout value..(conditionally)
Quoted 4 lines
Quoted 2 lines
Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..
Can we find out if this is a general issue?
Hmm..i'm sure you can find out this issue.. Have ever find out this issue(similar case)..anybody?
Quoted 4 lines
Regards,
Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Philip Rakity

2010-12-01 16:21 UTC #11 lore raw

Quoted 14 lines · Jaehoon Chung

Quoted 12 lines · Philip Rakity
Quoted 3 lines · Jaehoon Chung
Quoted 1 line · Philip Rakity
Can we just remove the quirk for broken timeout and just set the timeout to 0xe in sdhci.c?
you means that set the timeout to 0xe without broken timeout in sdhci.c?
yes
but I also think we should remove the quirk and change sdhci.c to use 0xe ALL THE TIME. I do not see a downside to doing this other than a longer timeout period. Considering the broken cards that are out there in practice one needs to set it to this value anyway for cards to work.

Quoted 5 lines

If we set the fixed timeout value to 0xe, we should remove the broken timeout value. right. But in my patch, nevertheless i used the broken timeout value quirk, need to reset timeout value at that time. Because if didn't set timeout value, broken card fire busy state..so happen the data timeout error.
Anyway, your opinion seem good..

The timeout value in the host controller should not change once it is set. It s not supposed to change value on reset (for example).

Curious -- if you read the value when you are in the busy state before you set it -- what value is there. BTW-- are you using sdhci.c as the SD Controller ?

Quoted 45 lines

Thanks
Quoted 42 lines
Quoted 40 lines
Quoted 1 line
The problem with the quirk is you need to know when to set it and the problem with the existing quirk is that one has to set it to work with bad cards.
I know when use quirk...and what use one...
Quoted 37 lines
________________________________________
From: [email protected] [[email protected]] On Behalf Of Jaehoon Chung [[email protected]]
Sent: Tuesday, November 30, 2010 3:37 AM
To: Wolfram Sang
Cc: [email protected]; Chris Ball; kyungmin Park; Andrew Morton; [email protected]
Subject: Re: [RFC Patch] SDHCI: add quirk for data timeout value when card busy.
Quoted 4 lines
Quoted 1 line
Maybe, happen for all sdhci-controllers...
My point is: If it is needed for all SDHCI-controllers, we don't need a quirk and can apply your code unconditionally.
You're right. But i'm not sure, happen for all sdhci-controller. so i send to RFC patch..
I also hope apply my code unconditionally.
the reason using quirk...every card didn't happen this issue.. if not happen this issue, we need not set timeout value..at that time..
when needs, entered and set timeout value..(conditionally)
Quoted 4 lines
Quoted 2 lines
Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..
Can we find out if this is a general issue?
Hmm..i'm sure you can find out this issue.. Have ever find out this issue(similar case)..anybody?
Quoted 4 lines
Regards,
Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Jaehoon Chung

author

2010-12-02 07:40 UTC #12 lore raw

Quoted 18 lines · Philip Rakity

Quoted 16 lines · Jaehoon Chung
Quoted 11 lines · Philip Rakity
Quoted 3 lines · Jaehoon Chung
Quoted 1 line · Philip Rakity
Can we just remove the quirk for broken timeout and just set the timeout to 0xe in sdhci.c?
you means that set the timeout to 0xe without broken timeout in sdhci.c?
yes
but I also think we should remove the quirk and change sdhci.c to use 0xe ALL THE TIME. I do not see a downside to doing this other than a longer timeout period. Considering the broken cards that are out there in practice one needs to set it to this value anyway for cards to work.
If we set the fixed timeout value to 0xe, we should remove the broken timeout value. right. But in my patch, nevertheless i used the broken timeout value quirk, need to reset timeout value at that time. Because if didn't set timeout value, broken card fire busy state..so happen the data timeout error.

Quoted 7 lines

Quoted 1 line
Anyway, your opinion seem good..
The timeout value in the host controller should not change once it is set. It s not supposed to change value on reset (for example).
Curious -- if you read the value when you are in the busy state before you set it -- what value is there.

I checked the timeout value to 0xa (i didn't use broken timeout value. if i used that quirk, set to 0xe) When suspend/resume..timeout value set to 0x0...so i set them...

Quoted 1 line

BTW-- are you using sdhci.c as the SD Controller ?

Yes .I'm using sdhci.c as SD Controller..

Quoted 46 lines

Quoted 44 lines
Thanks
Quoted 41 lines
Quoted 40 lines
Quoted 1 line
The problem with the quirk is you need to know when to set it and the problem with the existing quirk is that one has to set it to work with bad cards.
I know when use quirk...and what use one...
Quoted 37 lines
________________________________________
From: [email protected] [[email protected]] On Behalf Of Jaehoon Chung [[email protected]]
Sent: Tuesday, November 30, 2010 3:37 AM
To: Wolfram Sang
Cc: [email protected]; Chris Ball; kyungmin Park; Andrew Morton; [email protected]
Subject: Re: [RFC Patch] SDHCI: add quirk for data timeout value when card busy.
Quoted 4 lines
Quoted 1 line
Maybe, happen for all sdhci-controllers...
My point is: If it is needed for all SDHCI-controllers, we don't need a quirk and can apply your code unconditionally.
You're right. But i'm not sure, happen for all sdhci-controller. so i send to RFC patch..
I also hope apply my code unconditionally.
the reason using quirk...every card didn't happen this issue.. if not happen this issue, we need not set timeout value..at that time..
when needs, entered and set timeout value..(conditionally)
Quoted 4 lines
Quoted 2 lines
Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..
Can we find out if this is a general issue?
Hmm..i'm sure you can find out this issue.. Have ever find out this issue(similar case)..anybody?
Quoted 4 lines
Regards,
Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Wolfram Sang

2010-12-02 09:09 UTC #13 lore raw

Quoted 7 lines

Quoted 4 lines
The timeout value in the host controller should not change once it is set. It s not supposed to change value on reset (for example).
Curious -- if you read the value when you are in the busy state before you set it -- what value is there.
I checked the timeout value to 0xa (i didn't use broken timeout value. if i used that quirk, set to 0xe) When suspend/resume..timeout value set to 0x0...so i set them...

What I don't see at the moment is why this issue happens after resume but not after initial boot. Do you have an idea?

Signature · 2 lines

Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

Philip Rakity

2010-12-02 16:04 UTC #14 lore raw

In reply to Jaehoon Chung

Quoted 22 lines · Jaehoon Chung

Quoted 21 lines · Philip Rakity
Quoted 17 lines · Jaehoon Chung
Quoted 11 lines · Philip Rakity
Quoted 3 lines · Jaehoon Chung
Quoted 1 line · Philip Rakity
Can we just remove the quirk for broken timeout and just set the timeout to 0xe in sdhci.c?
you means that set the timeout to 0xe without broken timeout in sdhci.c?
yes
but I also think we should remove the quirk and change sdhci.c to use 0xe ALL THE TIME. I do not see a downside to doing this other than a longer timeout period. Considering the broken cards that are out there in practice one needs to set it to this value anyway for cards to work.
If we set the fixed timeout value to 0xe, we should remove the broken timeout value. right. But in my patch, nevertheless i used the broken timeout value quirk, need to reset timeout value at that time. Because if didn't set timeout value, broken card fire busy state..so happen the data timeout error.
Anyway, your opinion seem good..

Quoted 7 lines

Quoted 4 lines
The timeout value in the host controller should not change once it is set. It s not supposed to change value on reset (for example).
Curious -- if you read the value when you are in the busy state before you set it -- what value is there.
I checked the timeout value to 0xa (i didn't use broken timeout value. if i used that quirk, set to 0xe) When suspend/resume..timeout value set to 0x0...so i set them...

Somewhere in the code the value is being reset or when the hardware does a reset it is being cleared. Add code to the sdhci reset logic to check if it happens there. if so --> then controller issue.

If you have a test I can run. I can try to reproduce the problem on my controller and if so then it is in the standard code and just need to find it.

Quoted 52 lines

Quoted 2 lines
BTW-- are you using sdhci.c as the SD Controller ?
Yes .I'm using sdhci.c as SD Controller..
Quoted 46 lines
Quoted 44 lines
Thanks
Quoted 41 lines
Quoted 40 lines
Quoted 1 line
The problem with the quirk is you need to know when to set it and the problem with the existing quirk is that one has to set it to work with bad cards.
I know when use quirk...and what use one...
Quoted 37 lines
________________________________________
From: [email protected] [[email protected]] On Behalf Of Jaehoon Chung [[email protected]]
Sent: Tuesday, November 30, 2010 3:37 AM
To: Wolfram Sang
Cc: [email protected]; Chris Ball; kyungmin Park; Andrew Morton; [email protected]
Subject: Re: [RFC Patch] SDHCI: add quirk for data timeout value when card busy.
Quoted 4 lines
Quoted 1 line
Maybe, happen for all sdhci-controllers...
My point is: If it is needed for all SDHCI-controllers, we don't need a quirk and can apply your code unconditionally.
You're right. But i'm not sure, happen for all sdhci-controller. so i send to RFC patch..
I also hope apply my code unconditionally.
the reason using quirk...every card didn't happen this issue.. if not happen this issue, we need not set timeout value..at that time..
when needs, entered and set timeout value..(conditionally)
Quoted 4 lines
Quoted 2 lines
Card is configurable with eMMC spec..But sdhci-controller didn't support that card. So SDHCI controller need to use quriks..
Can we find out if this is a general issue?
Hmm..i'm sure you can find out this issue.. Have ever find out this issue(similar case)..anybody?
Quoted 4 lines
Regards,
Wolfram
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html