More Generic Audio Graph Sound Card idea

[Sameer Pujar]

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 at 0 { dsp_f0: endpoint { remote-endpoint = <&pcm0>; }; };
>
>                                  /* Back End side */
>                                  port at 4 { dsp_b0: endpoint { remote-endpoint = <&dai0>; }; };
>                                  port at 5 { dsp_b1: endpoint { remote-endpoint = <&dai1>; }; };
>                          };
>                  };
>
>                  back-end {
>                          ports {
>                                  port at 0 { dai0: endpoint { remote-endpoint = <&dsp_b0>; }; };
>                                  port at 1 { dai1: endpoint { remote-endpoint = <&dsp_b1>; }; };
>                          };
>                  };
>
>                  codec {
>                          port { dai2: endpoint { remote-endpoint = <&pcm1>; }; };
>                  };
>
>
> Thank you for your help !!
>
> Best regards
> ---
> Kuninori Morimoto