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
