From mboxrd@z Thu Jan 1 00:00:00 1970 From: vikas Date: Thu, 13 Aug 2015 17:26:02 -0700 Subject: [U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from flash read In-Reply-To: <201508140146.39891.marex@denx.de> References: <1437013654-29387-1-git-send-email-vikas.manocha@st.com> <201508140047.29254.marex@denx.de> <55CD25E3.8030008@st.com> <201508140146.39891.marex@denx.de> Message-ID: <55CD359A.8030003@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, On 08/13/2015 04:46 PM, Marek Vasut wrote: > On Friday, August 14, 2015 at 01:18:59 AM, vikas wrote: >> Hi Marek, > > Hi! > >> On 08/13/2015 03:47 PM, Marek Vasut wrote: >>> On Thursday, August 13, 2015 at 11:04:59 PM, vikas wrote: >>>> Hi Marek, >>> >>> Hi! >>> >>>> 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. >>> >>> Good. >>> >>>> Can we make it configurable (SRAM Level test or not) like from DT or >>>> #define ? >>> >>> How would you call such an option ? Something like CONFIG_SYS_YOLO (to >>> indicate that life is too short to use correct, but slower code) ? :-) >>> >>> I don't want to have two different codepaths in the codebase, one of >>> which is buggy. So no, I disagree we should add this option. I also >>> don't think it would be such a performance improvement, so I only see >>> downsides in such a code. >> >> I expected the same answer :-) & agree also. > > Heh, thanks :-) > >> ok, the issue is SRAM Fill Level register is not being updated on my SOC, >> seems like design issue. Any idea how can i add this fix (to avoid sram >> level polling) to my soc in u-boot mainline. > > Mask all interrupts in the controller, set watermark to N bytes (depending > on the length of your transfer) and poll the interrupt status register until > the watermark is reached ? Is this possible ? Watermark is for sram level and might not work as well. In general also for such soc/platform issues for any driver, any idea how to apply fixes. Rgds, Vikas > . >