alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Sameer Pujar <spujar@nvidia.com>
To: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Cc: sharadg@nvidia.com, Linux-ALSA <alsa-devel@alsa-project.org>,
	Mark Brown <broonie@kernel.org>,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	jonathanh@nvidia.com
Subject: Re: More Generic Audio Graph Sound Card idea
Date: Wed, 26 Aug 2020 12:16:13 +0530	[thread overview]
Message-ID: <f21353ca-5d47-afac-3451-f951eced36e2@nvidia.com> (raw)
In-Reply-To: <87mu2jw7zd.wl-kuninori.morimoto.gx@renesas.com>

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


  reply	other threads:[~2020-08-26  6:47 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-21  4:15 More Generic Audio Graph Sound Card idea Kuninori Morimoto
2020-08-21  5:26 ` Sameer Pujar
2020-08-21  7:14   ` Kuninori Morimoto
2020-08-21  8:28     ` Sameer Pujar
2020-08-21 13:02       ` Mark Brown
2020-09-25  1:43     ` Kuninori Morimoto
2020-09-25 19:22       ` Mark Brown
2020-09-25 20:04         ` Pierre-Louis Bossart
2020-09-25 20:10           ` Mark Brown
2020-09-25 20:50             ` Pierre-Louis Bossart
2020-08-21  7:11 ` Daniel Baluta
2020-08-21  7:25   ` Kuninori Morimoto
2020-08-21  7:33     ` Daniel Baluta
2020-08-21 11:47     ` Mark Brown
2020-08-21 12:18 ` Mark Brown
2020-08-24  0:25   ` Kuninori Morimoto
2020-08-24  6:25     ` Sameer Pujar
2020-08-25  0:59       ` Kuninori Morimoto
2020-08-25  3:11         ` Sameer Pujar
2020-08-25  5:13           ` Kuninori Morimoto
2020-08-25  5:42             ` Sameer Pujar
2020-08-25  6:35               ` Kuninori Morimoto
2020-08-26  6:46                 ` Sameer Pujar [this message]
2020-08-27  1:18                   ` Kuninori Morimoto
2020-08-27  1:36                   ` Kuninori Morimoto
2020-09-03 23:51     ` Kuninori Morimoto
2020-09-09 11:33       ` Sameer Pujar
2020-08-21 15:49 ` Pierre-Louis Bossart
2020-10-13  4:50 ` Kuninori Morimoto
2020-10-15 14:32   ` Mark Brown
2020-10-15 23:04     ` Kuninori Morimoto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f21353ca-5d47-afac-3451-f951eced36e2@nvidia.com \
    --to=spujar@nvidia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=jonathanh@nvidia.com \
    --cc=kuninori.morimoto.gx@renesas.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=sharadg@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).