From mboxrd@z Thu Jan 1 00:00:00 1970 From: vikasm Date: Thu, 13 Aug 2015 09:27:08 -0700 Subject: [U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from flash read In-Reply-To: <201508130409.49348.marex@denx.de> References: <1437013654-29387-1-git-send-email-vikas.manocha@st.com> <1437013654-29387-3-git-send-email-vikas.manocha@st.com> <201508130409.49348.marex@denx.de> Message-ID: <55CCC55C.5020708@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/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. Rgds, Vikas > >> 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 >> --- > [...] > Best regards, > Marek Vasut > . >