From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Leo Yan <leoy@marvell.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Questions for dummy codec driver
Date: Mon, 26 Sep 2011 22:47:38 +0100 [thread overview]
Message-ID: <20110926214738.GA3517@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4E7A9276.803@marvell.com>
On Thu, Sep 22, 2011 at 09:42:14AM +0800, Leo Yan wrote:
> On our platform, there have some devices (like hdmi/bt) do not need
> config from the CODEC driver, they have their own s/w stack and
> interface to configure; for the audio driver, just need to set the
> I2S/PCM timing for them. So if there have a common dummy codec
> driver, then it can meet our requirement well. Otherwise, there will
> have some duplicate codes for these dummy codecs.
The general thought here has been that for dumb CODECs the boilerplate
is sufficiently small and simple to mean that the discoverability from
writing a skeletal driver outweighs the cost of having it kicking around
- while there is some boilerplate there it's easier for someone to grab
and use this code than it is to work out how exactly to translate the
datasheets into code each time they encounter the part. However, a
sufficiently well written generic driver would maintain that advantage
while reducing the duplication.
next prev parent reply other threads:[~2011-09-26 21:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-20 7:09 [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Axel Lin
2011-09-20 11:21 ` Liam Girdwood
2011-09-20 12:04 ` Mark Brown
2011-09-20 16:00 ` Timur Tabi
2011-09-21 2:23 ` Questions for dummy codec driver Leo Yan
2011-09-21 12:56 ` Mark Brown
2011-09-22 1:42 ` Leo Yan
2011-09-26 21:47 ` Mark Brown [this message]
2011-09-27 2:08 ` [PATCH] ASoC: fsl: Fix error handling if platform_device_add fails Tabi Timur-B04825
2011-09-27 2:21 ` Axel 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=20110926214738.GA3517@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=leoy@marvell.com \
--cc=linux-kernel@vger.kernel.org \
/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).