Re: [PATCH v3 5/5] spi: dw: use threaded interrupt and optimize the threaded ISR
From: Joseph Steel
Date: Fri Sep 11 2026 - 10:32:02 EST
Hi
On Wed, Sep 09, 2026 at 10:36:52PM +0800, Jisheng Zhang wrote:
> To avoid blocking for an excessive amount of time, eventually impacting
> on system responsiveness, hard interrupt handlers should finish
> executing in as little time as possible.
>
> Use threaded interrupt and move the SPI transfer handling to an
> interrupt thread for host mode and non enhanced spi for two reasons:
>
> "while the performance improvement will apply for both target mode
> has no control over the clocking of data by the host so is much more
> vulnerable to dropping data in a threaded interrupt if the system is
> loaded. In host mode this isn't an issue since we'll simply stop
> clocking data while waiting for the scheduler to get round to the
> interrupt thread."
This isn't correct. FYI the IRQ-based Tx/Rx has been implemented in
the driver for a reason. The reason is - "damn automatic chip-select
toggling if there is no data to transmit in Tx FIFO." That is if a
platform uses the native controller chip-selects and the driver can't
feed the Tx FIFO fast enough so one wouldn't get empty for the entire
SPI-message handling, then the native CS will be automatically
de-asserted on the Tx FIFO emptying event which will effectively break
the message transfer.
So if you still wish the threaded IRQ handling, then it must be
utilized only for the non-native CS (like GPIO) or if the platform has
a custom native chip-select override.
-Joseph
>