[U-Boot] [PATCH v2] spi: cadence_qspi_apb: Use 32 bit indirect write transaction when possible

[Vignesh R]

On Monday 28 November 2016 07:45 PM, See, Chin Liang wrote:
> On Jum, 2016-11-25 at 17:51 +0100, Marek Vasut wrote:
>> On 11/24/2016 06:35 AM, Vignesh R wrote:
>>>
>>> According to Section 11.15.4.9.2 Indirect Write Controller of K2G
>>> SoC
>>> TRM SPRUHY8D[1], the external master is only permitted to issue 32-
>>> bit
>>> data interface writes until the last word of an indirect transfer
>>> otherwise indirect writes is known to fails sometimes. So, make
>>> sure
>>> that QSPI indirect writes are 32 bit sized except for the last
>>> write. If
>>> the txbuf is unaligned then use bounce buffer to avoid data aborts.
>>>
>>> So, now that the driver uses bounce_buffer, enable
>>> CONFIG_BOUNCE_BUFFER
>>> for all boards that use Cadence QSPI driver.
>>>
>>> [1]www.ti.com/lit/ug/spruhy8d/spruhy8d.pdf
>>>
>>> Signed-off-by: Vignesh R <vigneshr at ti.com>
>>> ---
>> Reviewed-by: Marek Vasut <marex at denx.de>
>>
>> I'd like to have at least Dinh's/Chin's ack on this.
> 
> THanks Marek
> 
> Hmmm... From 11.15.4.1.1, the data slave port should able to accept
> only byte, half-word and word access. This should not create any data
> abort but probably bad performance. But it should insignificant as
> access time for the flash is longer than the data port access itself.
> 

Data slave port does accept byte, half-word and word access, there are
no data aborts. But indirect write controller seems to have
limitation(as documented in section 11.15.4.9.2) couping with non 32-bit
data writes on TI platform. For example with current driver if I try:

fatload mmc 0 0x82000000 zImage
sf erase 0x0 0x500000
sf write 0x82000000 0x0 0x35
sf read 0xA0000000 0x0 0x35


md.b 0xA0000000
a0000000: 00 00 a0 00 00 00 a0 00 00 00 a0 00 00 00 a0 00
a0000010: 00 00 a0 00 00 00 a0 00 00 00 a0 00 00 00 a0 00
a0000020: 03 00 00 00 18 28 6f 00 00 00 00 00 d8 5b 35 00
a0000030: 01 02 03 00 00 00 00 00 00 00 00 00 00 00 00 00
md.b 0x82000000
82000000: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1
82000010: 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1 00 00 a0 e1
82000020: 03 00 00 ea 18 28 6f 01 00 00 00 00 d8 5b 35 00
82000030: 01 02 03 04 00 90 0f e1 88 07 00 eb 01 70 a0 e1


As you can see, every fourth byte turn out to be 0x00. Therefore this
patch is required.


-- 
Regards
Vignesh