On Wed, Aug 04, 2021 at 09:49:39AM +0900, Kuninori Morimoto wrote:

> OK, it is nice idea for me, "descriptive" is difficult,
> but for example...

> 	- audio-link-card
> 	- multi-graph-card
> 	- link-graph-card
> 	- audio-mf-graph-card (mf = multi functional)

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?
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,
especially codec2codec since we might have for example both a DSP and a
codec2codec link in the same card.

> Other one is that new card is assuming that using auto format
> (= using .get_fmt on each driver), but we can use "format" property for it
> and possible to overwrite.
> So, I noticed that keeping Normal connection compatibility on new card
> is not super difficult, and "un-recommended" is very small (In my quick check).

> Ahh, new card is not supporting "platform" so far (it is supported on audio-graph-card),
> and maybe other options/property which I'm not using too.
> But it is not a big problem I think, we can add these later.

Yes, these both feel like things we can do on both cards.

> I want to tell here is that, we can add new card (by new name), and
> I think we can keep audio-graph-card's *normal* compatibility on it, (not DPCM).
> Of cource we can keep existing audio-graph-card, but easy to switch to new card (?).

> I'm not sure it is OK for DT maintainer.

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.