From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Nitin PAI <nitinmpai@gmail.com>
Cc: alsa-devel@alsa-project.org, swarren@nvidia.com, lrg@ti.com
Subject: Re: ASOC - Codecs : Renaming of spdif_tranceiver.c
Date: Wed, 7 Mar 2012 14:24:47 +0000 [thread overview]
Message-ID: <20120307142447.GM3107@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <CAJDSjBhYdsxh+=LEfatCLrydSDm_KLCVqfptBkOBStNpZJgS4A@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1748 bytes --]
On Wed, Mar 07, 2012 at 07:45:24PM +0530, Nitin PAI wrote:
Don't top post, and please don't do things like reordering content.
> The usecase for the DSP was specifically for automotive where there is no
> power requirements and the audio functionality is always on.
> The programming of the codecs usually from the userspace. However ALSA is
> used for ease of using the alsalib for its various functions (applications
> standpoint).
Even with automotive there's *some* power limits and obviously the power
control also includes things like syncing startup of the algorithms with
the data path
> >>The CPU side drivers have no dependency on the CODEC drivers, these are
> >>integrated by the machine. The SoC vendor can easily ship drivers which
> >>will work with any CODEC which works well on Linux.
> The problem with just writing the machine driver and shipping it is,
> without any codec driver the cards wont be enumerated.
> Having a thin codec driver to enumerate the cards and ship it will help.
> (from debug and development standpoint).
Well, yes. Unless someone writes a card driver the CPU driver won't do
anything useful but then without the card driver you've no idea how the
system is actually wired up and the chances of it doing anything useful
are close to zero. There's no getting out of the machine driver.
> >>Another option is to just embed all the data
> >>structures in a single driver which binds to them all and selects the
> >>right data structure based on the probe information, that might be
> >>useful.
> Are you suggesting to have this in the machine driver? I didnt understand
> this, please clarify.
No, obviously CODEC drivers should be handling by CODECs...
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2012-03-07 14:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-07 6:45 ASOC - Codecs : Renaming of spdif_tranceiver.c Nitin PAI
2012-03-07 12:18 ` Nitin PAI
2012-03-07 13:43 ` Mark Brown
2012-03-07 14:15 ` Nitin PAI
2012-03-07 14:24 ` Mark Brown [this message]
2012-03-07 15:18 ` Nitin PAI
2012-03-07 15:39 ` Mark Brown
2012-03-07 16:28 ` Nitin PAI
2012-03-07 16:34 ` Mark Brown
2012-03-07 16:53 ` Nitin PAI
2012-03-07 17:04 ` Nitin PAI
2012-03-07 17:11 ` Mark Brown
2012-03-07 17:58 ` Nitin PAI
2012-03-07 19:19 ` Mark Brown
2012-03-07 17:09 ` Mark Brown
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=20120307142447.GM3107@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=lrg@ti.com \
--cc=nitinmpai@gmail.com \
--cc=swarren@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).