On Sun, Dec 02, 2018 at 09:55:52AM +0100, kernel@xxxxxxxxxxxxxxxx wrote: > > On 30.11.2018, at 15:55, kernel@xxxxxxxxxxxxxxxx wrote: > > With this patch applied the spi-worker is not even woken one! > Further testing with mixed spi_sync and spi_async shows that spi_async > is no longer working properly. > This seems to be related to shutdown code getting triggered in the > next loop of _spi_pump_message, which is not called with this patch > in place. > More investigation and probably a more inversive patch is needed > to solve this problem for real. Yes... I remember thinking when I put the unconditional kick in there that there were holes that would need to be plugged before we could skip the thread but I don't think got as far as specifically identifying them. You're right that it's inefficient and we should be able to get rid of it a lot of the time. Ideally we'd be able to run the entire message pump in interrupt context as the prior message completes when the device is busy but sadly some hardware (including the main hardware I was using when I did that work) has limitations which prevent this. > While reading the code it seems as if controller teardown and > here ctlr->unprepare_transfer_hardware and pm_runtime_* are > possibly called way more often than necessary - i.e. whenever > the queue is empty. > Maybe deferring this a few jiffies is all that is needed > and would be an improvement as well… Yes, that's also a good idea - I did wonder about experimenting with a delay there like we do with DAPM and with the autosuspend delay in runtime PM but IIRC my test system took negligable time to idle the hardware so it wasn't helping my use case.
Attachment:
signature.asc
Description: PGP signature
