On 10/11/18 11:28 AM, Charles Keepax wrote:
Here is a first pass at adding dapm sample rate domain support. Things are still pretty rough in quite a few places and I expect some major refactoring before they are ready to merge, but things are far enough along for people to look at the approach I am taking to the problem. And should provide enough for discussion at the mini-conference, although hopefully I will get some more done next week as well.
Interesting, too bad I couldn't be in Edinburgh this year.
The basic high level summary is two new concepts are added to ASoC, one being a sample rate domain and the other being a domain group. The domain groups represent widgets that are limited by hardware restrictions to always run at the same sample rate as each other. Sample rate domains represent a slot on a device for a sample rate. Both of these are currently limited to be within the scope of a single component. The core will track which groups are connected together, then as a group is powered up it will be allocated a domain based on the other groups it is connected to. Domain groups are implemented as a new type of DAPM widget and the domains themselves are a new thing which devices add through their component drivers. As we have previously discussed my intention would be that we also add bridges between domains although I haven't started work on that yet. The current code is limited to within a single component and I think that the bridges will allow better support for propagating rates between components as well as obviously for SRCs. Currently the SRCs on wm5110 are just being handled as points where the domain groups don't connect to another peer. This allows them to function but doesn't accurately convey things like the limitations which input rates support which output rates on the ISRC.
My feedback would be: why limit the domains to sample rate definition? we can also have additional criteria such as number of channels, channel maps and bit depth - maybe also audio/non-audio for compressed stuff. It'd be interesting to start with a non-scalar descriptor from day1. To some extent we'd also want something similar to .info definitions, with domains defined with masks to allow for flexibility in the conversions and easier bridge implementations. e.g. it'd be interesting to have a domain definition supporting more than one sampling frequency (8, 16, 48kHz) with the bridge doing the relevant conversion to adapt to the connected domain (fixed 48kHz DAI for example)
Thanks for starting the discussion! -Pierre
Thanks, Charles Charles Keepax (4): ASoC: dapm: Add support for hw_free on CODEC to CODEC links ASoC: dapm: Add support for a rate domain widget ASoC: domain: Add sample rate domain support ASoC: arizona: Add rate domain support include/sound/soc-dapm.h | 14 ++ include/sound/soc-domain.h | 98 +++++++++++ include/sound/soc.h | 8 + sound/soc/Makefile | 2 +- sound/soc/codecs/arizona.c | 255 ++++++++++++++++++++++------ sound/soc/codecs/arizona.h | 76 ++++++++- sound/soc/codecs/wm5110.c | 414 ++++++++++++++++++++++++++++++++++----------- sound/soc/soc-core.c | 8 + sound/soc/soc-dapm.c | 57 ++++++- sound/soc/soc-domain.c | 412 ++++++++++++++++++++++++++++++++++++++++++++ 10 files changed, 1183 insertions(+), 161 deletions(-) create mode 100644 include/sound/soc-domain.h create mode 100644 sound/soc/soc-domain.c
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
