[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <81d106c0-e1c8-a79a-8caf-1f3be0d61f0c@nvidia.com>
Date: Tue, 30 Jun 2020 18:23:49 +0530
From: Sameer Pujar <spujar@...dia.com>
To: Mark Brown <broonie@...nel.org>
CC: <spujar@...dia.com>,
Kuninori Morimoto <kuninori.morimoto.gx@...esas.com>,
<perex@...ex.cz>, <tiwai@...e.com>, <robh+dt@...nel.org>,
<lgirdwood@...il.com>, <thierry.reding@...il.com>,
<jonathanh@...dia.com>, <digetx@...il.com>,
<alsa-devel@...a-project.org>, <linux-tegra@...r.kernel.org>,
<linux-kernel@...r.kernel.org>, <sharadg@...dia.com>,
<mkumard@...dia.com>, <viswanathl@...dia.com>,
<rlokhande@...dia.com>, <dramesh@...dia.com>,
<atalambedu@...dia.com>, <nwartikar@...dia.com>,
<swarren@...dia.com>, <nicoleotsuka@...il.com>
Subject: Re: Re: [PATCH v4 12/23] ASoC: simple-card: Support DPCM DAI link
with multiple Codecs
On 6/30/2020 4:31 PM, Mark Brown wrote:
> On Tue, Jun 30, 2020 at 01:22:29PM +0530, Sameer Pujar wrote:
>
>> Yes there are complex use cases, but if we look at the amount of changes
>> required in simple-card driver that is not too much. Existing binding for
>> simple-card driver would still work fine for our cases. Yes there are some
>> deviations and we don't want to break existing users, that is why a *new*
>> compatible was introduced and specific items can be pushed under it.
>> Majority of the simple-card driver is getting re-used here. We just need to
>> make sure it does not affect anyone else.
> Why simple-card and not audio-graph-card?
Frankly speaking I have not used audio-graph-card before. I had a brief
look at the related binding. It seems it can use similar DT properties
that simple-card uses, although the binding style appears to be
different. However I am not sure if it offers better solutions to the
problems I am facing. For example, the ability to connect or form a
chain of components to realize more complicated use cases with DPCM,
some of which were discussed in [0]. Can you please help me understand
why it could be preferred?
[0] https://lkml.org/lkml/2020/4/30/519
>>> Using fe/be instead of cpu/codec is easy to understand.
>> I guess you are referring to DT binding part. The parsing code specifically
>> looks for "codec" sub node and thus present conventions had to be used.
> Remember that this stuff gets fixed into the ABI so we'd have to live
> with this for ever.
Powered by blists - more mailing lists