Alsa-Devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Liam Girdwood <liam.r.girdwood@linux.intel.com>
Cc: Peter Ujfalusi <peter.ujfalusi@ti.com>,
	Takashi Iwai <tiwai@suse.de>,
	"alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"Koul, Vinod" <vinod.koul@intel.com>
Subject: Re: [RFC 0/4] ASoC DSP topology
Date: Tue, 21 Apr 2015 17:39:42 +0100	[thread overview]
Message-ID: <20150421163942.GM22845@sirena.org.uk> (raw)
In-Reply-To: <1429629831.2797.9.camel@loki>


[-- Attachment #1.1: Type: text/plain, Size: 1309 bytes --]

On Tue, Apr 21, 2015 at 04:23:51PM +0100, Liam Girdwood wrote:
> On Tue, 2015-04-21 at 15:30 +0300, Peter Ujfalusi wrote:

> > We have discussed this with Liam in the past: in my view the DSP topology (or
> > Dynamic FW) should be represented in the machine level and it would be the
> > best if the same image could carry card level widgets routes and links. If you
> > have big enough change in the FW and it's provided widgets/PCMs you would need
> > separate machine driver or at least a way to have different set of machine
> > level routes, widgets, links, etc for different DSP topology file.

> The component level allows us to target the physical component devices
> that may have runtime definable topologies. This would include codecs
> too, since some vendors are making codecs with built in FW (maybe TI
> too ?). The machine level more represents the board HW topology and this
> should be derived from ACPI or DT.

I tend to agree.  We should let each vendor provide their own topology
information - if they need to do something with this (which does seem
unlikely) system integrators should be on an equal footing with silicon
vendors here, and we shouldn't be encouraging systems where we need
per-board firmware definitions for the silicon components just because
the board has differences.

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]



  reply	other threads:[~2015-04-21 16:39 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-04-16 20:48 [RFC 0/4] ASoC DSP topology Liam Girdwood
2015-04-20 21:40 ` Mark Brown
2015-04-21  6:58 ` Peter Ujfalusi
2015-04-21  9:28   ` Mark Brown
2015-04-21 10:03     ` Liam Girdwood
2015-04-21 12:30     ` Peter Ujfalusi
2015-04-21 15:23       ` Liam Girdwood
2015-04-21 16:39         ` Mark Brown [this message]
2015-04-22  4:10           ` Vinod Koul

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=20150421163942.GM22845@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=peter.ujfalusi@ti.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