dmaengine: dw-axi-dmac: Add channel abort support

[pelwell]

dmaengine: dw-axi-dmac: Add channel abort support

Disabling a channel will stall and timeout if it is currently
transferring to or from a slow peripheral with handshaking (which they
all have). When that happens, use the channels "abort" feature to
unblock the channel.

See: #7642

[popcornmix]

From claude - is resending an issue?

• rp1_pio_sm_tx_user(): before this change, an interrupted wait did break with ret == 0, so the ioctl reported success even though data was dropped. Returning an error fixes that. But -ERESTARTSYS means that with SA_RESTART the ioctl is restarted from the beginning. Any chunks already submitted in the earlier loop iterations would then be sent a second time. -EINTR avoids the silent duplication, at least once head_idx has moved. The same applies to the non-cyclic rx loop: chunks already copied to the user are lost, and the restart reads fresh data. The cyclic rx path already has this behaviour, so it may be acceptable, but it's worth a thought.

[pelwell]

Updated to ignore non-fatal signals if some data has already been transferred.

[popcornmix]

There is a change in behaviour that may or may not be intended:

• After commit, only a fatal signal can end the wait. An app that installs a SIGINT handler can't use Ctrl-C to break out of a stalled transfer (e.g. an SM waiting on an external clock or pin that never arrives). Only SIGKILL will get it out.

[pelwell]

I'm enjoying this game of Claude vs Claude (and Phil vs Claude), but I think it should now cope with the case that the PIOLib client has installed a SIGINT handler (as long as it specifies SA_RESTART).

[pelwell]

Updated with a third patch to clear out stale RX data during the close procedure.

All three commits are FYI, @hverkuil.

[popcornmix]

Feel free to merge if you've had enough of claude, but he has more grumbles:

• The flush can DMA to a stale or zero address. config_xfer accepts buf_size == 0 && buf_count == 0, which is the zero-copy mode the kernel API uses (!dma->buf_count in rp1_pio_sm_xfer_data()). In that mode no bounce buffers are allocated. rp1_pio_sm_dma_flush_rx() then uses dma->bufs[0].dma_addr anyway. That is either 0 or the address left over from an earlier configuration of that SM, whose memory has since been freed (rp1_pio_sm_dma_free() doesn't clear it). Up to 64 bytes are written there. This can be triggered from user space via SM_CONFIG_XFER with 0/0, followed by close. Either skip the flush when !dma->buf_count, or flush into a small buffer of its own.
• Every RX close now takes about 50 ms of CPU. The SM is disabled, so the flush transfer never completes. dmaengine_terminate_sync() then always spins in readl_poll_timeout_atomic() for the full 50 ms before falling back to the new abort. It works, but with several RX SMs it adds up. It may be worth going straight to abort here, or shortening the first poll.
• The commit message doesn't match the code. The message says "a single DMA RX of the configured burst size", but the code transfers RP1_PIO_FIFO_DEPTH * 4 + burst_bytes. The message also says the mechanism "is not fully understood", while the comment states it as fact. The two should agree.
• Reconfiguring an SM doesn't flush. A second config_xfer on the same SM/direction frees the old channel without a flush, so the same stale data could appear there. It's less likely, since the SM may still be running, but worth a thought.

[pelwell]

Answering the points above as if they were numbered:

1. Agreed - the latest version allocates a small DMA buffer on the fly in all cases.
2. That's not what I see. On the Pi, closing a process that has only an idle
   RX channel configured takes 2–3 ms of wall time, 1 ms of
   which is the flush's fsleep(). A process with no DMA takes
   about 1 ms. So stopping an RX channel that is waiting for a
   request with nothing in flight doesn't hit the 50 ms poll.
   The ~50 ms exit times seen earlier come from the TX channel:
   since commit 1347b00, the SM is disabled while TX data is still
   queued, and that channel needs the abort. That cost predates
   the flush. Shortening the poll for TX may still be worth
   doing, but it's a separate question.
3. Agreed - rewritten.
4. Not flushing on a reconfigure is deliberate. On
   reconfiguration the SM may still be running, and a request
   held at that point normally has real data behind it. The new
   channel's first burst then delivers that data correctly,
   whereas a flush there would throw it away. Stale data only
   appears if the FIFO has been emptied by the CPU in the
   meantime. That's the same within-process case already listed
   as not covered. The driver doesn't track whether the SM is
   stopped, so it can't tell when a flush would be safe.

[popcornmix]

Feel free to merge. There was one final comment that isn't caused by this PR, but I'll mention in case you care:

• The one remaining point is older than this PR and doesn't block it: the bounce buffers are allocated with dma->chan->device->dev but freed in rp1_pio_sm_dma_free() with the PIO's dev. The new flush uses the same device for both, which is correct.

[pelwell]

Fair - see #7664.