[PATCH v2 09/14] ASoC: audio-graph-card2: add Yaml Document

[Kuninori Morimoto]

Hi Mark

Thank you for your review

> > 	audio-graph-card2
> > 	 O: Normal connection
> > 	 O: DPCM
> > 	 O: Multi CPU/Codec
> > 	 O: Codec2Codec
> 
> OK, so if there's issues with multi CPU/CODEC due to the representation
> of inter-device links not being good enough we definitely need to fix
> that and I can see that being a binding change.  For the CODEC<->CODEC
> stuff I'd have thought we'd be able to get things working but if we're
> changing things anyway perhaps it's not worth it.  It'd probably be
> helpful to spell out the specific issues with the multi-device links.

Maybe I'm misunderstanding you, but the reason why we can't 100% merge
audio-graph-card and audio-graph-card2 is that existing audio-graph-card
was focusing only for "Normal" connection, and didn't mind expansion for
advanced connections.

DPCM connection was added for my local use case (= for both simple-card/audio-graph-card),
but it was forcibly expansion, has limitation, no flexibility, etc, etc...
I'm happy that someone is using it, but...
Adding more connection variation (which needs flexibility) (with keeping compatibility)
to existing audio-graph-card is impossible I thought.

The issue is audio-graph-card's flexibility/compatibility, not ALSA SoC.

> > 	step 1)
> > 	- add audio-graph-card2 which have (A) compatibility.
> > 	- indicate "audio-graph-card will be deprecated" on audio-graph-card
> 
> > 	step 2)
> > 	- Tegra switch to use audio-graph-card2
> > 	- confirm that all existing audio-graph-card user have no problem on
> > 	  audio-graph-card2 too.
> 
> > 	step 3)
> > 	- remove audio-graph-card
> 
> I guess one other option is to just keep the two audio graph bindings in
> parallel, having it as something like a simple links and rich links
> variant?  We're going to have to maintain compatibility I think and it'd
> make it clearer what's going on, it wouldn't just be a version number
> for the binding that's changed but rather something more descriptive.

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)
	...

> Perhaps the approach above with a descriptive name for the new binding
> and just keeping both around in parallel makes that all clearer/easier?

Yes

> > 	- audio-graph-card2 can keep (A) compatible, but some features
> > 	  are not recommended. Existing user will get such message.
> > 	  And because of this compatibility, audio-graph-card2 can't remove
> > 	  this "un-recommended" feature.
> 
> Right, some of this depends on how actively bad those features are - if
> they're more just not recommended than actively bad then perhaps it's
> not worth bothering to deprecate them.

In my quick check (not deep),
for keeping (A) (= Normal) compatibility on new card point of view,
one of not recommended I indicated is property naming (= "dai" vs "link").
But, I noticed that it is not a *super* big deal.

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.

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.

Thank you for your help !!

Best regards
---
Kuninori Morimoto