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

[Vignesh R]

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

Yes, I will submit a separate patch for that shortly.

-- 
Regards
Vignesh