On Thu, Aug 05, 2021 at 08:47:46AM +0900, Kuninori Morimoto wrote: > > The -mf- there reads unfortunately differently in English so we > > definitely don't want to go with that one I think. I do agree that it's > > hard to come up with a name, possibly rich-link-graph-card or something? > Thanks. It is a little bit long name, so, > rich-graph-card, or rich-link-card is nice for me. Yeah, let's go with that for now. > > > Actually, looking at the bindings documents I'm not 100% clear what the > > differences in the binding (as opposed to the code that parses it) are - > > this may just be the examples being too cut down to show them. I'm not > > 100% clear why we have the three different compatibles in there, that > > feels like something that should just be in the graph description, > Ohhhh, yes, indeed. I didn't notice about that ! > If my understanding was correct, it can be something like ... > card { > compatible = "rich-graph-card"; > ... > links = ... > > mix { > ... > } > multi { > ... > } > codec2codec { > ... > } > } > > Hmm, nice idea. Can we merge some of these types - for example what happens if we get a CODEC to CODEC link with TDM (eg, a DSP with a link to two mono speakers). I think we should at least be able to merge TDM with anything else, I guess we could have all three if we had a DPCM SoC with two CODECs on a single link though that feels a bit pathological. > > especially codec2codec since we might have for example both a DSP and a > > codec2codec link in the same card. > It is possible in my understanding, but am I misunderstanding ? > ... is it naming issue ? > In my understanding, both "DSP" and "MIXer" are using "DPCM" connection, > but driver/sample is calling it as "DSP". > I think "MIXer" and "Codec2Codec" in same card is possible. > I'm not sure about "DSP" case... I think you're understanding it right - I'm using DSP to mean a SoC needing DPCM because of the DSP here, sorry that wasn't the clearest way to describe things.
Attachment:
signature.asc
Description: PGP signature