From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Thu, 13 Aug 2015 19:33:12 +0200
Subject: [U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from
	flash read
In-Reply-To: <55CCC55C.5020708@st.com>
References: <1437013654-29387-1-git-send-email-vikas.manocha@st.com>
 <201508130409.49348.marex@denx.de> <55CCC55C.5020708@st.com>
Message-ID: <201508131933.12471.marex@denx.de>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On Thursday, August 13, 2015 at 06:27:08 PM, vikasm wrote:
> Hi Marek,

Hi vikasm,

(you might want to fix your name in your mailer)

> 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 ;-)

Best regards,
Marek Vasut