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
