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

[Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>]

On 14.11.22 12:29, Mark Brown wrote:
> On Mon, Nov 14, 2022 at 09:30:26AM +0100, Frieder Schrempf wrote:
> 
>> 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.
> 
> It sounds like the commit can stay and that everyone is happy
> that the issue is that the the commit made things run faster and
> exposed some other misconfiguration for these systems?

Honestly I'm not really sure how to proceed.

My first impression was to keep the PIO polling support with its
benefits if there's just this single issue with the SPI NOR on our board
and assuming that the performance improvements uncovered a bug somewhere
else. But at the moment I'm not quite sure this is really the case.

I did another test on v6.1-rc5 and disabling either PIO polling
(spi-imx.polling_limit_us=0) or DMA (spi-imx.use_dma=0), or both of them
makes reading the SPI NOR work again.

Looking at spi_imx_transfer_one() this means that doing PIO polling
transfers for short messages combined with normal PIO transfers for
longer messages works. The same for DMA transfers only (short and long
messages).

The problematic case seems to be having PIO polling transfers for short
messages and DMA transfers for long messages probably interleaved in
some way. And this sounds more like a problem that is not really
specific to our SPI NOR use case and as I said so far I didn't find a
way to fix it other than reducing the SPI clock significantly.

David, Marc, do you have any idea if this could be a general problem
with the PIO polling implementation?