[U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from flash read
vikas
vikas.manocha at st.com
Thu Aug 13 23:04:59 CEST 2015
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
> .
>
More information about the U-Boot
mailing list