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

Marek Vasut marex at denx.de
Thu Aug 13 04:09:49 CEST 2015


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.

> 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 at st.com>
> ---
[...]
Best regards,
Marek Vasut


More information about the U-Boot mailing list