From mboxrd@z Thu Jan  1 00:00:00 1970
From: Marek Vasut <marex@denx.de>
Date: Fri, 14 Aug 2015 03:03:41 +0200
Subject: [U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from
	flash read
In-Reply-To: <55CD3A5C.1030300@st.com>
References: <1437013654-29387-1-git-send-email-vikas.manocha@st.com>
 <201508140244.09761.marex@denx.de> <55CD3A5C.1030300@st.com>
Message-ID: <201508140303.41206.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 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) ?

> 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 ?

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 ...

Best regards,
Marek Vasut