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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.