On Sat, May 23, 2020 at 11:34:10AM +0300, Serge Semin wrote: > On Fri, May 22, 2020 at 04:22:41PM +0100, Mark Brown wrote: > > Right, that definitely needs to be fixed then - 8MHz is indeed a totally > > normal clock rate for SPI so people will hit it. I guess if there's a > > noticable performance hit to defer to thread then we could implement > > both and look at how long the delay is going to be to decide which to > > use, that's annoyingly complicated though so if the overhead is small > > enough we could just not bother. > As I suggested before we can implement a solution without performance drop. > Just wait for the DMA completion locally in the dw_spi_dma_transfer() method and > return 0 instead of 1 from the transfer_one() callback. In that function we'll > wait while DMA finishes its business, after that we can check the Tx/Rx FIFO > emptiness and wait for the data to be completely transferred with delays or > sleeps or whatever. No extra context switches there at least, that's the main issue. > NOTE Currently the DW APB SSI driver doesn't set xfer->effective_speed_hz, though as > far as I can see that field exists there to be initialized by the SPI controller > driver, right? If so, strange it isn't done in any SPI drivers... Yes. Not that many people are concerned about the exact timing it turns out, the work that was being used for never fully made it upstream. > What do think about this? Sure. > patchset "spi: dw: Add generic DW DMA controller support" (it's being under > review in this email thread) ? Anyway, if the fixup is getting to be that > complicated, will it have to be backported to another stable kernels? No, if it's too invasive it shouldn't be (though the stable people might decide they want it anyway these days :/ ).
Attachment:
signature.asc
Description: PGP signature
