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

[vikas <vikas.manocha@st.com>]

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