On 11/29/2016 01:08 PM, Vignesh R wrote:
On Tuesday 29 November 2016 04:23 PM, Marek Vasut wrote:
On 11/29/2016 05:58 AM, Vignesh R wrote:
On Monday 28 November 2016 06:11 PM, Marek Vasut wrote:
On 11/28/2016 10:37 AM, Vignesh R wrote:
On Friday 25 November 2016 10:21 PM, 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.
btw don't you need BB for READ as well ?
I don't see any issue with READ due to non word size accesses ATM,
Like user does sf read ... 0x1003 0x100 , you'll likely have a problem, no?
No issues with that either. The above limitation seems to be only wrt sf write (indirect write).
Because indirect read already uses readsb to handle the alignment , right ?
Alignment is not the problem here, even indirect write uses writesb to handle alignment. But the problem is, driver uses readsb/writesb (which perform byte wise accesses) for reading/writing, if txbuf/rxbuf is unaligned or data length is not a multiple of word size. As per the TI K2G SoC TRM, external master is not permitted to do non 32 bit indirect read/write accesses except for last read/write. So, if the driver writes say 25 bytes, one byte at a time using writesb, then some bytes are do not get written to flash correctly (instead 0x0 is written).
Well ok, then we have a problem on READ as well.
What my patch is doing is to use bounce buffer so that txbuf is always aligned and writesl can be used instead of writesb. And also make sure that writesb is only to right last trailing bytes in case data length is not a multiple of word size.
Right.
But wrt indirect read, I don't see any such data corruption or other issues if driver reads, say 25 bytes, one byte at a time using readsb (though the TRM advises against this)
Correct, so fix the READ path too to be extra sure.