On Sel, 2016-11-29 at 10:55 +0530, Vignesh R wrote:
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@ti.com
Reviewed-by: Marek Vasut marex@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.
Thanks Vignesh
Interesting to know that the newer version of controller has this constrain. Let me pull out my board to ensure this patch doesn't break the SOCFPGA
Thanks Chin Liang