Hi Mark
Thank you for your feedback
> 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.
> Well, I think the big issue from a DT point of view is needing to add a
> new generic card at all - there's much less problem with keeping the old
> ones around than there is with keeping on adding new generic cards.
I guess/hope the DT issue will be disappear if new card can keep
existing binding...
> 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.
> 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...
Thank you for your help !!
Best regards
---
Kuninori Morimoto
