Re: [PATCH] spi: spi-imx: Revert "spi: spi-imx: add PIO polling support"

[Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>]

Hi Fabio, hi David,

On 11.11.22 13:59, David Jander wrote:
> 
> Dear Fabio,
> 
> On Fri, 11 Nov 2022 08:33:03 -0300
> Fabio Estevam <festevam@xxxxxxxxx> wrote:
> 
>> Hi David,
>>
>> On Fri, Nov 11, 2022 at 6:50 AM David Jander <david@xxxxxxxxxxx> wrote:
>>
>>> The effect of this patch is that it will cause short SPI transfers to have a
>>> lot less latency than without this patch, so could it be that we are looking
>>> at a timing related bug in the MTD driver, or some other timing issue?

This was also my first suspicion when I originally discovered a similar
(or probably the same) issue on 5.19 with wrong data being read from the
SPI NOR. Reducing the clock to 40 MHz fixed the read in my case.

>>> Your SPI clock is 80MHz, but the datasheet of the MACRONIX MX25R1635F
>>> specifies a maximum clock of 33MHz. Is your NOR flash chip capable of this
>>> clock-rate?  
>>
>> Thanks for your suggestions.
>>
>> I have tried passing spi-max-frequency = <33000000>, and I don't see
>> the failure anymore.
>>
>> Looking at the MX25R1635F datasheet the maximum SPI frequency is:
>>
>> 80MHz: when L/H bit is 1 - High Performance mode.
>> 33MHz: when L/H bit is 0 - Ultra Low Power mode.
>>
>> "L/H switch bit The Low Power / High Performance bit is a volatile bit.
>> User can change the value of L/H switch bit to keep Ultra Low Power
>> mode or High Performance mode.
>> Please check Ordering Information for the L/H Switch default support"
> 
> Oh, my bad, sorry. I didn't read far enough into the DS. I just wanted to point
> out that AFAIK, if you use a clock higher than 33MHz, you probably also need
> "m25p,fast-read" in the DT:

I already tried changing the pin configuration for the SPI pins (slew
rate, drive strength), setting spi-[rx/tx]-delay-us and enabling
m25p,fast-read. Unfortunately nothing of this worked.

According to our hardware department we are using the MX25R1635FZUIH0
which has "High Performance Mode" enabled by default and should be
capable of using a 80 MHz clock.

As far as I know Fabio also discovered that disabling SDMA also fixes
the problem.

I guess I will try to repeat some tests on latest master and see if
there is anything that makes things work again without reducing the
clock. If anyone has some more ideas of how to fix this properly, please
let me know. If nothing else helps we could also reduce the SPI clock.

Thanks
Frieder