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.
Attachment:
signature.asc
Description: PGP signature
