From: Mark Brown <broonie@kernel.org>
To: mengdong.lin@linux.intel.com
Cc: alsa-devel@alsa-project.org, tiwai@suse.de,
hardik.t.shah@intel.com, guneshwor.o.singh@intel.com,
liam.r.girdwood@linux.intel.com, vinod.koul@intel.com,
rakesh.a.ughreja@intel.com, mengdong.lin@intel.com
Subject: Re: [PATCH v2 01/11] ASoC: topology: Able to create BE DAIs
Date: Fri, 16 Sep 2016 15:56:52 +0100 [thread overview]
Message-ID: <20160916145651.GD27974@sirena.org.uk> (raw)
In-Reply-To: <084b7ba7ba3f0d4a97641b43fab26aee2dc20c5d.1473420558.git.mengdong.lin@linux.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 1480 bytes --]
On Fri, Sep 09, 2016 at 07:43:11PM +0800, mengdong.lin@linux.intel.com wrote:
> From: Mengdong Lin <mengdong.lin@linux.intel.com>
> Topology will check with ASoC if a BE DAI already exists by checking
> its name. If the BE DAI doesn't exist, topology will create a new one
> and the dai_load ops will be called for device specific init.
I still remain fundamentally unconvinced that this is a good or scalable
idea and that it makes sense to have it be part of the standard topology
ABI. We are not going to download a DSP firmware that creates a new
physical link in the system so having the topology be the thing creating
those physical links seems wrong.
> create the HDA DAIs. Ideally, the driver should query BIOS to get the
> physical pin output types and connections to peripherals for a specific
> platform, but unfortunately BIOS sometimes does not have accurate info,
> so there is still hard code of BE DAI & DAI links in driver. To share a
Having the connections to the DSP specified in the toplogy is of course
sensible but fundamentally this is always going to be choosing from a
list of physical DAIs that we already know about and potential
connections for those that are also already known. If the driver wants
to do something in response to a DAI being hooked up into the topology
(which seems to be the actual goal here) that would be sensible but
attempting to create physical hardware in a topology does not seem like
a good idea as a generic feature.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2016-09-16 14:57 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-09 11:41 [PATCH v2 00/11] ASoC: topology: Remaining kernel patches mengdong.lin
2016-09-09 11:43 ` [PATCH v2 01/11] ASoC: topology: Able to create BE DAIs mengdong.lin
2016-09-16 14:56 ` Mark Brown [this message]
2016-09-19 17:09 ` Shah, Hardik T
2016-09-21 5:44 ` Mengdong Lin
2016-09-21 7:09 ` Liam Girdwood
2016-09-24 18:56 ` Mark Brown
2016-09-09 11:45 ` [PATCH v2 02/11] ASoC: topology: ABI - Add flags to PCM mengdong.lin
2016-09-09 11:45 ` [PATCH v2 03/11] ASoC: topology: ABI - Add private data " mengdong.lin
2016-09-09 11:45 ` [PATCH v2 04/11] ASoC: topology: Add FE DAIs only if not already added mengdong.lin
2016-09-09 11:46 ` [PATCH v2 05/11] ASoC: topology: ABI - Add name & component info to BE/CC links mengdong.lin
2016-09-09 11:46 ` [PATCH v2 06/11] ASoC: topology: ABI - Define DAI physical PCM data formats mengdong.lin
2016-09-09 11:46 ` [PATCH v2 07/11] ASoC: topology: ABI - Add HW configurations to BE/CC links mengdong.lin
2016-09-09 11:46 ` [PATCH v2 08/11] ASoC: topology: ABI - Add flags and private data " mengdong.lin
2016-09-09 11:46 ` [PATCH v2 09/11] ASoC: Define API to find a dai link by id mengdong.lin
2016-09-09 11:46 ` [PATCH v2 10/11] ASoC: Probe link components after finding new links mengdong.lin
2016-09-09 11:46 ` [PATCH v2 11/11] ASoC: topology: Able to create BE DAI links mengdong.lin
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=20160916145651.GD27974@sirena.org.uk \
--to=broonie@kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=guneshwor.o.singh@intel.com \
--cc=hardik.t.shah@intel.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=mengdong.lin@intel.com \
--cc=mengdong.lin@linux.intel.com \
--cc=rakesh.a.ughreja@intel.com \
--cc=tiwai@suse.de \
--cc=vinod.koul@intel.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).