On Fri, Jun 16, 2017 at 03:06:38PM +0100, Liam Girdwood wrote: > On Fri, 2017-06-16 at 13:26 +0100, Liam Girdwood wrote: > > Ok, I can redo and use specific types, but there still is a problem of > > how do we configure a pipeline (a collection of widgets, where several > > pipelines can make a path from PCM to DAI). This configuration data is > > not hw/sw params type data, but more DSP scheduling type data. My > > original thought was the pipeline widget, as there is nothing else that > > cleanly fits into the ABI and that the pipeline scheduling data is DAPM > > widget/graph related anyway. > > Another alternative is extending the topology ABI and introduce a > > pipeline object that would be ignore by the core and just used by > > certain drivers and firmwares ? > I think I'm tending towards having a scheduler widget now (instead of a > pipeline widget) and that would be a valid part of the graph and also > discoverable via debugfs etc. Ah, I see what you're going for with that now I think. So something that looks in DAPM terms a bit like a supply widget (in that it's not really part of the path itself but provides things the path needs in order to function)? I think that makes sense to me now too.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
