[U-Boot] [PATCH] driver: fsl_qspi: disable AHB buffer prefetch

york sun york.sun at nxp.com
Thu Jul 7 16:54:56 CEST 2016


On 07/07/2016 12:52 AM, Yunhui Cui wrote:
>
>> On 07/07/2016 1:01 AM, york sun wrote:
>> On 07/03/2016 08:27 PM, Yunhui Cui wrote:
>>> From: Yunhui Cui <yunhui.cui at nxp.com>
>>>
>>> A-009282: QuadSPI: QuadSPI data pre-fetch can result in incorrect data
>>> Affects: QuadSPI
>>> Description: With AHB buffer prefetch enabled, the QuadSPI may return
>>> incorrect data on the AHB interface. The buffer pre-fetch is enabled
>>> if the fetch size as configured either in the LUT or in the BUFxCR
>>> register is greater than 8 bytes.
>>> Impact: Only 64 bit read allowed.
>>> Workaround: Keep the read data size to 64 bits (8 Bytes), which
>>> disables the prefetch on the AHB buffer, and prevents this issue from
>>> occurring.
>>>
>>> Signed-off-by: Yunhui Cui <yunhui.cui at nxp.com>
>>> ---
>>>    drivers/spi/fsl_qspi.c | 2 +-
>>>    1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/spi/fsl_qspi.c b/drivers/spi/fsl_qspi.c index
>>> 75cbab2..e0a002d 100644
>>> --- a/drivers/spi/fsl_qspi.c
>>> +++ b/drivers/spi/fsl_qspi.c
>>> @@ -444,7 +444,7 @@ static void qspi_init_ahb_read(struct fsl_qspi_priv
>> *priv)
>>>    	qspi_write32(priv->flags, &regs->buf1cr,
>> QSPI_BUFXCR_INVALID_MSTRID);
>>>    	qspi_write32(priv->flags, &regs->buf2cr,
>> QSPI_BUFXCR_INVALID_MSTRID);
>>>    	qspi_write32(priv->flags, &regs->buf3cr, QSPI_BUF3CR_ALLMST_MASK |
>>> -		     (0x80 << QSPI_BUF3CR_ADATSZ_SHIFT));
>>> +		     (0x1 << QSPI_BUF3CR_ADATSZ_SHIFT));
>>>
>>>    	/* We only use the buffer3 */
>>>    	qspi_write32(priv->flags, &regs->buf0ind, 0);
>>>
>>
>> Yunhui,
>>
>> We handle erratum workaround using macros in case the workaround has
>> impact on other SoCs.
>
> [Yunhui] For now, all SoCs with Qspi module need this errata.

I still think it is better to gate the workaround with #ifdef in case we 
need to disable it for future SoCs. It will also be easier to locate the 
workaround code.

>
>> We also put the erratum information either in a
>> README file, or inline comment. It will be easier to read the code later.
>
> [Yunhui] ok, I will add inline comment in next version.
>
>> You don't have to put the whole erratum description in the commit message,
>> as long as it explains what this patch does and refer the erratum number
>> somewhere in the message so we can search the git log.
>>
>> York
>
> [Yunhui] ok, I will update the commit message in next version.
>

Thanks.

York




More information about the U-Boot mailing list