From mboxrd@z Thu Jan 1 00:00:00 1970 From: vikas Date: Thu, 13 Aug 2015 18:05:57 -0700 Subject: [U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from flash read In-Reply-To: <201508140303.41206.marex@denx.de> References: <1437013654-29387-1-git-send-email-vikas.manocha@st.com> <201508140244.09761.marex@denx.de> <55CD3A5C.1030300@st.com> <201508140303.41206.marex@denx.de> Message-ID: <55CD3EF5.5050405@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 06:03 PM, Marek Vasut wrote: > On Friday, August 14, 2015 at 02:46:20 AM, vikas wrote: >> Hi, > > Hi, > > [...] > >>>>>>> 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. >>> >>> That's a good question . Is there any way on the ST chip to avoid such >>> direct blocking read which can stall the CPU core indefinitelly? Can you >>> check with the chip designers ? >> >> I already checked & it does not exist in the hardware. Solution to that are >> timeout interrupts in indirect mode or use only direct mode. In case of >> direct mode, the u-boot driver can't be used. > > Why can't you use direct mode ? Wouldn't that solve your problem (with some > performance penalty probably) ? u-boot driver does not support direct mode. > >> But again, can we add some fix for stv0991 arch to avoid sram level. >> Without that we will not be able to use the driver at all for stv0991. >> >> In general, again it seems not a unique problem. Any idea how to apply >> fixes for such peripheral design bugs. > > What do you mean it's not unique please ? SOCs have one or the other design bugs often & there should be some way to apply fixes/workrounds. > > One option would be to pull out the SRAM level check into a separate function > and in that function check whether the controller is the one on ST chip (via > compatible string) and if it is, return fake "full" SRAM level. You'd then > fall back to the blocking read. I don't like the idea , but if there is no > other way ... It seems ok to me, I can send the patch for the same. Please let me know. Rgds, Vikas > > Best regards, > Marek Vasut > . >