| Message ID | 20181011162831.26351-1-ckeepax@opensource.cirrus.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | Initial prototype of DAPM sample rate domains | expand |
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 >
On Mon, Oct 22, 2018 at 09:27:13AM -0500, Pierre-Louis Bossart wrote: > > On 10/11/18 11:28 AM, Charles Keepax wrote: > 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! I don't think there really is anything about the way I am approaching the code that will limit this to just sample rates, it's more that is the part I need at the moment so is what I am implementing. I have basically a "domain" structure, that gets assigned as the groups power up, this is in no way specific to rates. We can just extend that struct to have other properties and add new ops on the domains as people discover additional features they require. Currently at that point in the code you will see a TODO which says to consider using a hw_params struct instead of just an int for the rate. I think based on your comments and others at the conference I will definitely be switching to that in the next spin. Although implementing the additional callbacks etc. is not something I can find sensible use-cases for on our devices, so someone else might need to pick up that part. Thanks, Charles