[U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from flash read

[vikasm <vikas.manocha@st.com>]

Hi Marek,

On 08/12/2015 07:09 PM, Marek Vasut wrote:
> On Thursday, July 16, 2015 at 04:27:30 AM, Vikas Manocha wrote:
>> There is no need to check for sram fill level. If sram is empty, cpu will
>> go in the wait state till the time data is available from flash.
> 
> 
> Consider the following scenario:
> - CPU core reads some memory area, but there are no data available just yet
>   => CPU core goes into wait state
> - The data never arrive
> 
> Will the CPU be stuck forever ? If we checked the fill level first instead,
> we would never enter such stuck-state.

This indirect mode of reading/writing would be entered when the read/write addresses
are in the programmed valid range of addresses.

Even in case of "data never arrive" scenario, a simple timeout seems better then currently
implemented read sram level with timeout.

Rgds,
Vikas

> 
>> Also Relying on SRAM fill level only for deciding when the data should be
>> fetched from the local SRAM is not most efficient approach, particularly
>> if we are working on high data rates.
>>
>> It should be noticed that after one SRAM word is collected, the information
>> is forwarded into system domain and then synchronized into register domain
>> (apb). If we are using slow APB and AHB clks, SRAM fill level might not be
>> up-to-dated because of latency cycles needed for synchronization. For
>> example in case we are getting SRAM fill level equal to 10 locations but
>> in reality there were 2 another words completed and actual level is 12 but
>> information may not be synchronized yet because of the synchronization
>> latency on APB domain.
>>
>> Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
>> ---
> [...]
> Best regards,
> Marek Vasut
> .
>