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: Tue, 25 Aug 2020 08:41:03 +0530	[thread overview]
Message-ID: <e6e04e2c-2695-b7ba-3eb2-79158f317e4a@nvidia.com> (raw)
In-Reply-To: <87364by23u.wl-kuninori.morimoto.gx@renesas.com>

Hi Morimoto-san,

CC Jon, Sharad

On 8/25/2020 6:29 AM, Kuninori Morimoto wrote:
> External email: Use caution opening links or attachments
>
>
> Hi Sameer
>
>> The series [0] introduces small deltas to resolve issues I am
>> facing. As you see, most of the implementation is unchanged for the
>> graph-card driver. Hence I am not sure if we need a new driver now.
> Yes, maybe it is not needed *for now*, but will be issue in the future,
> because I can't have normal-link and DPCM-link in the same time, right ?

Yes I am forcing usage of DPCM for all links. May be the compatible 
"-cc-" should reflect this. The reason for doing so is, wanted to use 
DPCM interface with the component model as previously discussed with 
Mark in [1]. The existing detection mechanism did not work because, in 
my case, the HW links are one-to-one and the DT is described that way in 
[0].

>
>> at all it gets complicated in future, the "-cc-" compatible can be
>> moved to new driver? Please note that the new "-cc-" compatibility is
>> added to address following and some of these are discussed in [1].
>> - DPCM usage with component model (where there can be N number of
>> components available and M (<= N) of them can be connected together to
>> form an audio path). For example the path would be like,
>> FE -> BE_1 -> BE_2 -> ... -> BE_M.
>> - I am extending dpcm_path_get() for this reason and DAI ops get
>> called for all connected components.
>>
>> [0] https://lkml.org/lkml/2020/8/5/42
>> [1] https://lkml.org/lkml/2020/4/30/519
> The difference between "-cc" and "card2" is DPCM link detection.
> "-cc-"  will assume all are DPCM link,
> "card2" will detect both normal-link and DPCM-link via DT.
>
> But, I guess new driver 1st version is focus to
> detecting normal-link and DPCM-link only.

Do you plan to propose something like enum for card2 and has scope for 
extension, where link type can be normal/DPCM/codec-to-codec/etc., ?
Since there are so many board variants and may have some specific 
requirements, I am wondering being able to detect link type from DT 
should be the only motivation for a new driver.

>
> This means it is not enough for your case,
> because I can't full reproduce your board/situation.
> Maybe you need some extra patch on "card2"
> which "-cc-" added to soc-xxx.c

I am afraid that even the new driver won't work as it is for my case 
unless a similar compatible and flag exposed for it. So I am not sure 
how different it would be from [0].


Thanks,
Sameer.

  reply	other threads:[~2020-08-25  3:12 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 [this message]
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
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=e6e04e2c-2695-b7ba-3eb2-79158f317e4a@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).