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

[Mark Brown]

On Mon, Jul 26, 2021 at 11:19:20AM +0900, Kuninori Morimoto wrote:

> 	audio-graph-card
> (A)	 O: Normal connection
> (B)	 x: DPCM
> 	 -: Multi CPU/Codec
> 	 -: Codec2Codec
> 
> 	x: Tegra uses is as customize audio-graph-card

TBH I'm not sure this is a bad solution for DPCM - there's the whole
thing with representing DPCM in device tree being fun going on :/

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

> We need to keep simple-card, I think there is no discussion is needed here.

Yes.

> 
> About audio-graph-card vs audio-graph-card2,
> I think keeping (A) only on audio-graph-card2 is not super difficult
> (But some message will be indicated. see below).
> Supporting (B) on audio-graph-card2 is difficult.

> I'm not sure detail, but we can do like this ?

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

> My concerns are...

> 	- I'm not sure how DT is strict.
> 	  If we removed audio-graph-card, but user uses old Tegra DT on it...
> 	  We can't remove audio-graph-card forever if DT was super strict (?).

> 	- The naming of audio-graph-card vs audio-graph-card2 driver file.
> 	  because audio-graph-card will be removed later.

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

> 	- 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20210803/9af4eb89/attachment.sig>