On Dec 1, 2010, at 11:40 PM, Jaehoon Chung wrote:
> Philip Rakity wrote: >> On Dec 1, 2010, at 4:29 AM, Jaehoon Chung wrote: >> >>> Philip Rakity wrote: >>>> On Nov 30, 2010, at 9:44 PM, Jaehoon Chung wrote: >>>> >>>>> Philip Rakity wrote: >>>>>> 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.. >> >> >> 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. > >> BTW-- are you using sdhci.c as the SD Controller ? > > Yes .I'm using sdhci.c as SD Controller.. > >> >>> Thanks >>> >>>>>> 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... >>>>> >>>>>> ________________________________________ >>>>>> From: linux-mmc-ow...@vger.kernel.org [linux-mmc-ow...@vger.kernel.org] >>>>>> On Behalf Of Jaehoon Chung [jh80.ch...@samsung.com] >>>>>> Sent: Tuesday, November 30, 2010 3:37 AM >>>>>> To: Wolfram Sang >>>>>> Cc: linux-mmc@vger.kernel.org; Chris Ball; kyungmin Park; Andrew Morton; >>>>>> m...@console-pimps.org >>>>>> Subject: Re: [RFC Patch] SDHCI: add quirk for data timeout value when >>>>>> card busy. >>>>>> >>>>>>>> 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) >>>>>> >>>>>> >>>>>>>> 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? >>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Wolfram >>>>>>> >>>>>> -- >>>>>> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >>>>>> the body of a message to majord...@vger.kernel.org >>>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>>>>> >>>> >> >> > -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
