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.