From: lrg@slimlogic.co.uk (Liam Girdwood)
To: linux-arm-kernel@lists.infradead.org
Subject: [alsa-devel] [RFC PATCH v2 1/3] ep93xx i2s audio driver
Date: Wed, 26 May 2010 12:07:21 +0100 [thread overview]
Message-ID: <1274872041.3240.158.camel@odin> (raw)
In-Reply-To: <1274850588-30460-2-git-send-email-ryan@bluewatersys.com>
On Wed, 2010-05-26 at 17:09 +1200, Ryan Mallon wrote:
> Add ep93xx i2s audio driver
>
> Signed-off-by: Ryan Mallon <ryan@bluewatersys.com>
> ---
> sound/soc/Kconfig | 1 +
> sound/soc/Makefile | 1 +
> sound/soc/ep93xx/Kconfig | 9 +
> sound/soc/ep93xx/Makefile | 8 +
> sound/soc/ep93xx/ep93xx-i2s.c | 489 +++++++++++++++++++++++++++++++++++++++++
> sound/soc/ep93xx/ep93xx-i2s.h | 25 ++
> sound/soc/ep93xx/ep93xx-pcm.c | 323 +++++++++++++++++++++++++++
> sound/soc/ep93xx/ep93xx-pcm.h | 22 ++
> 8 files changed, 878 insertions(+), 0 deletions(-)
> create mode 100644 sound/soc/ep93xx/Kconfig
> create mode 100644 sound/soc/ep93xx/Makefile
> create mode 100644 sound/soc/ep93xx/ep93xx-i2s.c
> create mode 100644 sound/soc/ep93xx/ep93xx-i2s.h
> create mode 100644 sound/soc/ep93xx/ep93xx-pcm.c
> create mode 100644 sound/soc/ep93xx/ep93xx-pcm.h
>
Overall looks OK, just some comments below.
> +static void ep93xx_i2s_enable(struct ep93xx_i2s_info *info)
> +{
> + int i;
> +
> + /* Enable clocks */
> + clk_enable(info->mclk);
> + clk_enable(info->sclk);
> + clk_enable(info->lrclk);
> +
> + /* Enable i2s */
> + ep93xx_i2s_write_reg(info, EP93XX_I2S_GLCTRL, 1);
> +
> + /* Enable fifos */
> + for (i = 0; i < 3; i++) {
> + ep93xx_i2s_write_reg(info, EP93XX_I2S_RX0EN + (i * 4), 1);
> + ep93xx_i2s_write_reg(info, EP93XX_I2S_TX0EN + (i * 4), 1);
Just curious, do we always need to enable both the RX and TX FIFOs ? Is
there unnecessary system overhead here when we have playback only or
capture only use cases ?
> +static void ep93xx_pcm_buffer_started(void *cookie,
> + struct ep93xx_dma_buffer *buf)
> +{
> +}
Do we need this ?
> +
> +static int ep93xx_pcm_prepare(struct snd_pcm_substream *substream)
> +{
> + return 0;
> +}
This can be removed
Thanks
Liam
--
Freelance Developer, SlimLogic Ltd
ASoC and Voltage Regulator Maintainer.
http://www.slimlogic.co.uk
next prev parent reply other threads:[~2010-05-26 11:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-26 5:09 [RFC PATCH v2 0/3] ep93xx i2s audio Ryan Mallon
2010-05-26 5:09 ` [RFC PATCH v2 1/3] ep93xx i2s audio driver Ryan Mallon
2010-05-26 11:07 ` Liam Girdwood [this message]
2010-05-26 11:16 ` [alsa-devel] " Peter Ujfalusi
2010-05-26 12:54 ` Chase Douglas
2010-05-26 13:08 ` Lothar Waßmann
2010-05-27 2:13 ` Mark Brown
2010-05-26 5:09 ` [RFC PATCH v2 2/3] ep93xx i2s core support Ryan Mallon
2010-05-26 5:09 ` [RFC PATCH v2 3/3] ep93xx i2s audio snapper cl15 support Ryan Mallon
2010-05-26 12:59 ` [RFC PATCH v2 0/3] ep93xx i2s audio Chase Douglas
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=1274872041.3240.158.camel@odin \
--to=lrg@slimlogic.co.uk \
--cc=linux-arm-kernel@lists.infradead.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).