On Thu, Dec 07, 2023 at 06:56:55PM -0600, Pierre-Louis Bossart wrote:
+The Device Number specified in the Header follows the SoundWire +definitions, and broadcast and group addressing are +permitted. However, in reality it is very unlikely that the exact same +binary data needs to be provided to the two different Peripheral +devices. The Linux implementation only allows for transfers to a +single device at a time.
For the firmware download case it seems likely that this won't always be the case, but it's definitely a thing that could be done incrementally.
One example discussed this week on the mailing list is the Cirrus Logic case, where the firmware contains information on which speakers a given amplifier should be doing, and each firmware is named as AMP-n.
I can imagine a vendor structuring things so they've got separate firmware and coefficent/configuration images, the firmware images could be shared.
I have really not found any practical case where the same data needs to be sent to N devices, and I don't have a burning desire to tie the codec initialization together with all the asynchronous nature of enumeration/probe.
Like I say it does seem like something that could be done incrementally.
These don't seem like insurmountable obstacles - they feel more like a copy break kind of situation where we can infer things from the pattern of transactions, and there's always the possibility of adding some calls to give regmap more high level information about the overall state of the device. One of the expected usage patterns with cache only mode is to build up a final register state then let the cache code work out the optimal pattern to actually write that out.
I did expect some pushback on regmap :-)
The point is really that the main use for this download is a set of write-once memory areas which happen to be mapped as registers. There is no real need to declare or access each memory address individually.
Yeah, normally it's just write only stuff but I've seen things like controls being added in the DSP memory before - the
In addition in terms of error handling, the expectation is that the set of writes are handled in a pass/fail manner. There's no real way to know which of the individual writes failed.
That's the case for any block writes.
I might be missing something but those requests for redownload sound like things that would occur regardless of the mechanism used to perform the I/O?
What I meant is that the codec driver would e.g. need to fetch a different firmware table and download it. There's no real need to maintain a cache on the host side since the entire table will be downloaded.
I mean, if that's the usage pattern surely things would just be marked volatile anyway? A cache is entirely optional.
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.
At any rate the low-level behavior is to a) allocate and configure all the SoundWire resources b) allocate and configure all the DMA resources c) trigger DMA and enable SoundWire transfers d) wait for the DMA to complete
The codec API can be modified as needed, as long as there are provisions for these 4 steps.
That's not quite how the current API works, but it feels like it's close enough to the intent and there's literally one user of the actual API.
- (3) A Peripheral driver may want to wait until existing BRA
transfers complete or deal with BRA as a background task whenaudio transfers stop. In this case, there would be no timeout,and the operation may not happen if the platform is suspended.
Option 3 would be a jump for regmap.
Sorry, I don't get what a 'jump' means in this context.
Big change.