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

[Chin Liang See]

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 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.

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

> 
>