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.