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. > 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.
Attachment:
signature.asc
Description: PGP signature
