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

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

Hi Marek,

On 08/13/2015 01:35 PM, Marek Vasut wrote:
> On Thursday, August 13, 2015 at 09:49:49 PM, vikas wrote:
> 
> Hi!
> 
>>>> 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.
>>>
>>> How do you implement a "simple timeout" if the CPU core is stuck and does
>>> not execute instructions ? If you mean interrupt, then forget it, U-Boot
>>> does not do interrupts ;-)
>>
>> Oh yes, you are right.
> 
> So shall we keep the SRAM piece ?

Although in this case the better solution would be to have watermark interrupt/status check based on sram
fill level, let us keep the existing piece of SRAM.

Can we make it configurable (SRAM Level test or not) like from DT or #define ? 

Rgds,
Vikas

> 
> Best regards,
> Marek Vasut
> .
>