All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren@nvidia.com>
To: "Liam Girdwood (lrg@ti.com)" <lrg@ti.com>,
	"Mark Brown (broonie@opensource.wolfsonmicro.com)"
	<broonie@opensource.wolfsonmicro.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>
Subject: ASoC DSP and related status
Date: Fri, 26 Aug 2011 12:44:26 -0700	[thread overview]
Message-ID: <74CDBE0F657A3D45AFBB94109FB122FF04B24A41A8@HQMAIL01.nvidia.com> (raw)

Liam, Mark,

I was recently talking to our internal audio team, extolling the virtues
of writing upstreamable drivers for Tegra's audio HW.

One of the big unknowns here is how to represent the Tegra DAS and AHUB
modules[1] in a standard fashion, and allowing configuration via kcontrols
that influence DAPM routing, rather than open-coding and/or hard-coding
such policy in the ASoC machine driver.

So, my questions are:

* What's the status of the ASoC DSP work. I see that some of the base
infra-structure has been merged into ASoC's for-next branch, but I think
that's just a small portion of the work. Do you have any kind of estimate
for when the whole thing will be merged? I don't see recent updates to
e.g. Liams' topic/dsp or topic/dsp-upstream branches.

* Back in March in another DSP-related thread, Mark mentioned that the
DSP rework was mainly about configuring stuff within a device, but that
Mark was working on some code to support autonomous inter-device links.
I assume that Tegra's DAS/AHUB would rely on the DSP work, not the stuff
Mark mentioned?

See the last few paragraphs of:
http://mailman.alsa-project.org/pipermail/alsa-devel/2011-March/037776.html

Related, Mark also mentioned something about representing the DAS/AHUB
as codecs. I'm not sure if that was meant as a stop-gap solution before
the DSP work was in place, or if that's part of supporting DAAS/AHUB
within the DSP infra-structure.

Thanks for any kind of information! Any information here will simply help
us plan for when we might be able to switch from open-coding some of the
more advanced Tegra audio support to more standardized solutions.


[1] Here's a very quick overview of the relevant Tegra audio HW:

DAS:

Part of Tegra20. Tegra20 has Digital Audio controllers (DACs) i.e. I2S
controllers. It also has Digital Audio Ports (DAPs). The Digital Audio
Switch (DAS ) sits between. Each DAP selects its audio output from a
particular DAC's or DAP's output. Each DAC selects its audio input from
a particular DAP. DAP<-> DAP is supported, with one being the master the
other the slave. Note that I2S configuration (channels, sample size, I2S
vs. DSP etc) is configured in the DAC not the DAP.

AHUB:

Part of Tegra30. Tegra30 has an interconnect called the Audio HUB (AHUB).
Various devices attach to this: FIFOs to send/receive audio to CPU memory
using DMA, DAMs that receive n(2?) channels from the AHUB and mix/SRC them
sending the result back to the AHUB, and finally various IO controllers
such as I2S and SPDIF. The AHUB is I believe a full cross-bar. In this
case, the I2S formatting is configured solely within the I2S controllers,
not on the other side of the AHUB as is the case with the Tegra20 DAS.
FIFOs also independently determine the number of channels/bit they send/
receive. There is some limited support for channel count and bitsize
conversion at each attachment point to the AHUB. I2S<->I2S loopback may
be supported in HW, at least in some cases.

-- 
nvpublic

             reply	other threads:[~2011-08-26 19:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-26 19:44 Stephen Warren [this message]
2011-08-27  9:36 ` ASoC DSP and related status Mark Brown
2011-08-31 23:14   ` Stephen Warren
2011-09-01 12:58     ` Mark Brown
2011-08-29 18:09 ` Liam Girdwood
2011-08-29 18:12   ` Liam Girdwood

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=74CDBE0F657A3D45AFBB94109FB122FF04B24A41A8@HQMAIL01.nvidia.com \
    --to=swarren@nvidia.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=lrg@ti.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.