[U-Boot] [v2 2/6] spi: cadence_qspi: remove sram polling from flash read

[Marek Vasut <marex@denx.de>]

On Friday, August 14, 2015 at 03:05:57 AM, vikas wrote:
> Hi,

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.

What about implementing support for 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.

They do, but unless we precisely know what the problem is, we're kept in
the dark. If it's really the case that your SRAM level is not begin updated,
then you might want to add DT prop, something like "cdns,broken-sram-level",
pull out the sram level checking code and if this prop is set, simple report
that the SRAM level is "full".

But I wonder, is your SRAM level counter not updating or is your FIFO just 
overflowing (ie. SRAM level indicator is rolling over) ? What are the real
symptoms ?

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

Thinking about it a bit further, adding a DT prop for this might be a better
idea than the compatible string.

Best regards,