On Tue, Dec 19, 2023 at 06:08:15PM +0100, Pierre-Louis Bossart wrote:
On 12/19/23 17:53, Mark Brown wrote:
On Tue, Dec 19, 2023 at 05:50:30PM +0100, Pierre-Louis Bossart wrote:
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.
The only actual async implementation is SPI which processes things in order of submission, the sync API wraps the async API.
Also is this just me spacing out or there is no regmap_raw_read_async()?
Right, there was never any need.
ok. I am starting to think that we could have a new type of regmap, say "regmap-sdw-bra", where the use of write_raw_async() would rely on the send/wait bus primitives, and write_raw() would fallback to the regular read/write commands. We'd need a mutual exclusion to prevent parallel async/sync access to the same regmap.
In other words, "memory" areas that are used for firmware downloads would be moved to a different regmap with async capabilities and no caching support.
I would be a little inclined to say leave adding a regmap for a follow up series, whether we add it to the existing regmap or add a new one, or whatever, it should all sit happily on top of the API being added in this series. Makes it a little more contained to focus on one area at a time, and leave this series as adding core support for BRA. But that said, if we really want to I don't feel mega strongly on this one.
Thanks, Charles