linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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

  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).