Hi Mark, >> +One possible strategy to speed-up all initialization tasks would be to >> +start a BRA transfer for firmware download, then deal with all the >> +"regular" read/writes in parallel with the command channel, and last >> +to wait for the BRA transfers to complete. This would allow for a >> +degree of overlap instead of a purely sequential solution. As a >> +results, the BRA API must support async transfers and expose a >> +separate wait function. > > 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. I am now revisiting this entire patchset to try to enable firmware downloads with this SoundWire BPT/BRA protocol. I re-looked at regmap_raw_write_async()/regmap_async_complete() and they seem to map well with my initial write/wait_async proposal. 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. I don't see any locking that would prevent such a dual operation - with the caveat that it would be up to the codec driver to make sure they don't try to access the same register with the two modes of operation. 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. Thanks for your help on all this, -Pierre
