On 8/20/24 13:53, Mark Brown wrote: > On Tue, Aug 20, 2024 at 09:48:05AM +0200, Pierre-Louis Bossart wrote: > >>> This feels a lot like it could map onto the regmap async interface, it >>> would need a bit of a rework (mainly that currently they provide >>> ordering guarantees with respect to both each other and sync I/O) but >>> those could be removed with some care) but it's got the "here's a list >>> of I/O, here's another call to ensure it's all actually happened" thing. >>> It sounds very much like how I was thinking of the async API when I was >>> writing it and the initial users. > >>> It's this bit that really got me thinking it could fit well into regmap. > >> Do I get this right that these async capabilities could be used to >> enable this faster SoundWire protocol, but the regular regmap_write() >> could still happen in parallel with these async transfers? This could be >> useful if e.g. there's a jack detection while downloading firmware for >> another function. > > As far as the regmap core is concerned, yes - with SPI we do wind up > with ordering but that's because the SPI sync API is a thin wrapper > around the SPI async API rather than anything regmap does. ok. I am struggling a bit to adjust the plumbing that was obviously defined for SPI. The regmap async_write() doesn't have any wait, but there's a notifier that needs to be called by *something* that waits. I think the SPI layer has a set of kthreads but in our case we could just rely on a a workqueue after 1ms or something and do the wait then for the DMAs to complete and finally call the notifier to wake-up the regmap stuff. >> The only thing that would need to be extended is that we'd need >> additional callbacks to check if the protocol is supported on a given >> hardware/firmware platform, and if there's no audio stream. In these >> cases the async writes would be demoted to regular writes. Otherwise the >> bus would be locked to make sure no reconfiguration takes place while >> the firmware download happens, and unlocked when the transfer ends. > > Those callbacks seem reasonable. We already do the demotion to sync for > buses that don't have async, it'd just need to be made dynamic. sounds good.
