On 4/29/2020 8:13 PM, Mark Brown wrote:
On Wed, Apr 29, 2020 at 04:20:53PM +0800, Dilip Kota wrote:
On 4/28/2020 7:10 PM, Daniel Schwierzeck wrote:
actually there is no real bottom half. Reading or writing the FIFOs is
fast and is therefore be done in hard IRQ context. But as the comment
Doing FIFO r/w in threaded irqs shouldn't cause any impact on maximum
transfer rate i think.
Have you actually tested this? Generally adding extra latency is going
to lead to some opportunity for the hardware to idle and the longer the
hardware is idle the lower the throughput.
Also the ISR should be quick enough, doing FIFO r/w in ISR adds up more
latency to ISR.
Handling the FIFOs r/w in threaded irq will be a better way.
Consider what happens on a heavily loaded system - the threaded
interrupt will have to be scheduled along with other tasks.
for lantiq_ssc_bussy_work() state, the driver needs some busy-waiting
after the last interrupt. I don't think it's worth to replace this with
threaded interrupts which add more runtime overhead and likely decrease
the maximum transfer speed.
Workqueue has a higher chances of causing SPI transfers timedout.
because...?
I just tried to get the history of removing workqueue in SPI driver, on
GRX500 (earlier chipset of LGM) the SPI transfers got timedout with
workqueues during regression testing. Once changed to threaded IRQs
transfers are working successfully.
Regards,
Dilip
