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

[Frieder Schrempf <frieder.schrempf@xxxxxxxxxx>]

On 15.11.22 11:51, Frieder Schrempf wrote:
> 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?

Further debugging reveals, that for polling_limit_us=30 the calculated
byte_limit (8104) is well beyond the maximum size of the data transfers
from the SPI NOR (4096 bytes). So I don't see any DMA transfers being
triggered which makes it even more strange why disabling DMA resolves
the issue.