From: Jaehoon Chung <jh80.chung@samsung.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 4/4] mmc: add workaround for eSDHC erratum A009620
Date: Wed, 27 Jul 2016 20:21:04 +0900 [thread overview]
Message-ID: <57989920.4010904@samsung.com> (raw)
In-Reply-To: <HE1PR04MB08898AE5B3C06EB897618A74F80F0@HE1PR04MB0889.eurprd04.prod.outlook.com>
On 07/27/2016 04:10 PM, Yangbo Lu wrote:
>> -----Original Message-----
>> From: york sun
>> Sent: Tuesday, July 26, 2016 1:38 AM
>> To: Yangbo Lu; u-boot at lists.denx.de
>> Subject: Re: [PATCH 4/4] mmc: add workaround for eSDHC erratum A009620
>>
>> On 05/20/2016 03:20 AM, Yangbo Lu wrote:
>>> Erratum Title:
>>> Data timeout error not getting set in case of command with busy
>>> response (R1b) as well as for busy period after last write block
>>> transfer.
>>>
>>> Description:
>>> In the event that a busy timeout occurs for a command with a busy
>>> response (e.g. R1b response) as well as busy period after the last
>>> write block, the eSDHC does not set the IRQSTAT[DTOE] bit or the
>>> IRQSTAT[TC]. Therefore, the current command transfer is never completed.
>>>
>>> Workaround:
>>> Workaround for CMD with busy:
>>> Don't set the XFRTYP[RSP]=2'b11 for commands with busy response and
>>> poll the busy status of the card from the PRSSTAT[DLSL]
>>>
>>> Workaround for busy period after last write block:
>>> 1. After the command completion interrupt (IRQSTAT[CC]), wait for
>>> de-assertion of PRSTAT[WTA].
>>> 2. Once PRSTAT[WTA] is de-asserted, start the software timer and poll
>>> the busy signal (DAT0) using PRSTAT[DLSL[0]].
>>> 3. Wait for DAT0 signal to go high (which indicate transfer complete)
>>> or software timer expiry (which indicate data timeout error).
>>> 4. Issue soft reset for data (SYSCTL[RSTD]).
>>> 5. In case of data timeout error (detected in step 3) perform the
>>> error recovery.
>>>
>>> The workaround for CMD with busy has already been applied in eSDHC
>>> driver. This patch is to add workaround for the 2nd issue, and the
>>> fixup platforms include PowerPC(P1010/P2020/P5020/P5040/T1024/T1040/
>>> T2080/T4240) and ARM(LS1021A/LS1043A/LS2080A).
>>>
>>> Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
>>> ---
>>> arch/powerpc/include/asm/config_mpc85xx.h | 8 ++++++++
>>> drivers/mmc/fsl_esdhc.c | 26
>> ++++++++++++++++++++++++++
>>> include/configs/ls1021aqds.h | 1 +
>>> include/configs/ls1021atwr.h | 1 +
>>> include/configs/ls1043a_common.h | 1 +
>>> include/configs/ls2080a_simu.h | 1 +
>>> include/configs/ls2080aqds.h | 1 +
>>> include/configs/ls2080ardb.h | 1 +
>>> include/fsl_esdhc.h | 1 +
>>> 9 files changed, 41 insertions(+)
>>
>> Yangbo,
>>
>> Why do you put the macro CONFIG_SYS_FSL_ERRATUM_ESDHC_A009620 in board
>> header file if the erratum applies to the SoC?
>>
>> York
>>
> [Lu Yangbo-B47093] Thanks a lot, York.
> Could you suggest any better place where I can put this macro?
> I didn't find such a good place :(
If use your patch by default, is there performance degression?
I don't know fsl_esdhc controller..so i just ask this. :)
>
> Thanks.
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
>
>
next prev parent reply other threads:[~2016-07-27 11:21 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-20 10:09 [U-Boot] [PATCH 1/4] mmc: fsl_esdhc: don't set XFERTYP_RSPTYP_48_BUSY for CMD with busy response Yangbo Lu
2016-05-20 10:09 ` [U-Boot] [PATCH 2/4] mmc: send STOP command when the READ/WIRTE commands fail Yangbo Lu
2016-06-10 15:31 ` York Sun
2016-05-20 10:10 ` [U-Boot] [PATCH 3/4] mmc: fsl_esdhc: add error recovery for data transfer with Auto CMD12 Yangbo Lu
2016-05-20 10:10 ` [U-Boot] [PATCH 4/4] mmc: add workaround for eSDHC erratum A009620 Yangbo Lu
2016-07-25 17:38 ` york sun
2016-07-27 7:10 ` Yangbo Lu
2016-07-27 11:21 ` Jaehoon Chung [this message]
2016-07-28 3:20 ` Yangbo Lu
2016-07-28 5:00 ` Jaehoon Chung
2016-07-28 6:15 ` Yangbo Lu
2016-07-27 14:48 ` york sun
2016-07-28 3:22 ` Yangbo Lu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57989920.4010904@samsung.com \
--to=jh80.chung@samsung.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox