Hi Sameer
What you are suggesting is 'audio-graph-card2' is a new restructured version of 'audio-graph-card' with some additional customization available for specific users. Do you think updating existing 'audio-graph-card' itself, with necessary hooks, would be too complicated to handle?
It depends on how new driver was implemented. If we need to keep current card, I will keep it as-is and do nothing anymore, and has customize option at card2. If we update current card, customize option will be added to it.
From a brief overview, it may solve my issue in customizing few stuff. But I am not too sure if we want to go that way, because eventually we end up in writing a separate machine driver for Tegra (though there can be common stuff used from the generic graph card). The original idea was to use 'audio-graph-card' and people facing similar issues could use "-cc-" compatible.
The biggest issue on current audio-graph-card is that DPCM feature is limited, and because of it, the link detection is very tricky. Your "-cc-" assumes all links are DPCM, but it is more limitation. We want to have more flexible/generic detection.
dsp { compatible = "audio-graph-card2-dsp";Sorry I did not understand this. Do you intend to parse 'dsp' separately with some version of audio graph card? In my case 'dsp' is just a 'crossbar' and is registered as a component exposing all routes. However I have described links in the DT in a similar way where my 'crossbar' is exposing FEs and BEs like below.
This compatible is used just for indicating audio-graph DSP. "audio-graph-card" will parse it if it was connected. If you confuse it, just ignore for now.
Thank you for your help !!
Best regards --- Kuninori Morimoto