Hi Morimoto-san,
If we plan to go this way, I think we need to consider board specific configuration at init time and one at runtime. In that case there could be multiple compatibles that would get added to the driver and various other requirements can be managed with behavioral flags instead from DT?
This is still just idea though... But for example, if you want to 1) basically, DT is almost audio-graph 2) but want to have customized operation for some part
And if "audio-graph-card2" driver has graph_init() exported function, you can create your own drviver, and use customized audio-graph by using .hooks.
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?
This is just idea/sample, but I'm not sure this is enough or not, and/or if I can do what I want. But do you think it can solve your issue ?
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.
...
static audio_graph_hooks hooks = { .parse_of_hook_pre = xxx,=> .parse_of_hook_post = sameer_parse_of_post,
We may end up re-parsing the whole stuff under 'hook_post' (which appears redundant) because I am forcing DPCM and would like func_dpcm() to execute for all links. If I could set a flag under 'hooks' and if 'audio-graph-card' can use it to force DPCM, it would appear to be a better choice.
...
---- my-dt ----------
/* * DT setting is almost same as audio_graph * which is supporting normal and DPCM. * You can add own property which will be handled under .hook */ ************* PCM0 <------------> * * <----DAI0-----> * DSP * * * <----DAI1-----> ************* PCM1 <------------------------------------------> DAI2
I think, the main issue is you want to keep both normal/DPCM link detections, where as I am trying to force DPCM usage. That is mainly because I do have N components and would like to connect M(<=N) components with DPCM usage. My DT would be like this.
************* PCM0 <-------------> * * <------ DAI0 (component-0) ------> ... * * <------ DAI1 (component-1) ------> * Crossbar * ... PCMX <-------------> * * <------ DAIN (component-N) ------> * * *************
So at runtime my audio path could be, at t0: PCM0 -> DAI0 -> DAI1 at t1: PCM0 -> DAI1 -> DAIN
Audio path can have ideally any combination of DAIs (and components) in the path. DT may look like it is similar to having normal links, but conceptually any PCMx can be routed to any set of DAIs. DAIs can be resampler, mixer, multiplexer etc., in SoC. I hope this makes clear as to what I am looking for.
...
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.
ports { /* Front End side */ port@0 { dsp_f0: endpoint { remote-endpoint = <&pcm0>; }; }; /* Back End side */ port@4 { dsp_b0: endpoint { remote-endpoint = <&dai0>; }; }; port@5 { dsp_b1: endpoint { remote-endpoint = <&dai1>; }; }; }; }; back-end { ports { port@0 { dai0: endpoint { remote-endpoint = <&dsp_b0>; }; }; port@1 { dai1: endpoint { remote-endpoint = <&dsp_b1>; }; }; }; }; codec { port { dai2: endpoint { remote-endpoint = <&pcm1>; }; }; };Thank you for your help !!
Best regards
Kuninori Morimoto