From mboxrd@z Thu Jan 1 00:00:00 1970 From: vikas Date: Thu, 13 Aug 2015 12:49:49 -0700 Subject: [U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from flash read In-Reply-To: <201508131933.12471.marex@denx.de> References: <1437013654-29387-1-git-send-email-vikas.manocha@st.com> <201508130409.49348.marex@denx.de> <55CCC55C.5020708@st.com> <201508131933.12471.marex@denx.de> Message-ID: <55CCF4DD.9010807@st.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Marek, On 08/13/2015 10:33 AM, Marek Vasut wrote: > 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) ok :-) > >> 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. Rgds, Vikas > > Best regards, > Marek Vasut > . >