>>> 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 really don't know anything about this async interface, if you have >> pointers on existing examples I am all ears....I am not aware of any >> Intel platform or codec used on an Intel platform making use of this API. > > grep for regmap_.*async - cs_dsp.c is the upstream example in a driver, > or there's the rbtree cache sync code which uses a back door to go into > an async mode. Basically just variants of all the normal regmap I/O > calls with a _complete() call you can use to wait for everything to > happen. The implementation is a bit heavyweight since it was written to > work with fairly slow buses. I spent a fair amount of time this afternoon trying to understand the regmap_async parts, and I am not following where in the code there is an ordering requirement/enforcement between async and sync usages. I do see this comment in the code * @async_write: Write operation which completes asynchronously, optional and must serialise with respect to non-async I/O. But that 'must' is a requirement on the codec side, isn't it? When using regmap_raw_write_async(), the lock is released immediately. I don't see anything at the regmap level that would prevent a codec driver from using regmap_raw_write() immediately. That's probably a violation of the API to do so, but it's the same problem I was referring earlier in the conversation where 'regular' read/writes cannot happen in parallel with BTP/BRA transactions. Also is this just me spacing out or there is no regmap_raw_read_async()?
