From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Wan ZongShun <mcuos.com@gmail.com>
Cc: alsa-devel <alsa-devel@alsa-project.org>,
Ben Dooks <ben-linux@fluff.org>,
linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
Liam Girdwood <lrg@slimlogic.co.uk>
Subject: Re: [PATCH] NUC900/audio: add nuc900 audio driver support
Date: Mon, 17 May 2010 03:44:26 +0100 [thread overview]
Message-ID: <20100517024425.GA2485@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4BF01069.6060102@gmail.com>
On Sun, May 16, 2010 at 11:34:01PM +0800, Wan ZongShun wrote:
This all looks pretty good. A few comments below but they're all fairly
minor and should be easy to address.
> index b1749bc..81d4848 100644
> --- a/sound/soc/Kconfig
> +++ b/sound/soc/Kconfig
> @@ -36,6 +36,7 @@ source "sound/soc/s3c24xx/Kconfig"
> source "sound/soc/s6000/Kconfig"
> source "sound/soc/sh/Kconfig"
> source "sound/soc/txx9/Kconfig"
> +source "sound/soc/nuc900/Kconfig"
Please keep the Kconfig and Makefile sorted, this helps avoid merge
issues.
> +#define NUC900_AC97_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |\
> + SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 |\
> + SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000)
SNDRV_PCM_RATE_8000_48000.
> + if (!timeout)
> + dev_err(nuc900_audio->dev, "AC97 read register time out !\n");
> +
> + val = AUDIO_READ(nuc900_audio->mmio + ACTL_ACOS0) ;
If the read timed out shouldn't we be returning rather than continuing?
> + val = AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON);
> + val &= (~AC_C_RES);
> + AUDIO_WRITE(nuc900_audio->mmio + ACTL_ACCON, val);
> + udelay(1000);
> + if (!(AUDIO_READ(nuc900_audio->mmio + ACTL_ACIS0) & CODEC_READY))
> + dev_err(nuc900_audio->dev, "AC97 codec cold reset failed!\n");
What is this actually checking in the hardware? Not all CODECs enable
the AC97 link by default after a cold reset, the standard allows them to
power up in a low power state which will
On the other hand, given that there's no warm reset operation perhaps
this isn't a big deal.
> +static void nuc900_ac97_remove(struct platform_device *pdev,
> + struct snd_soc_dai *dai)
> +{
> + struct nuc900_audio *nuc900_audio = nuc900_ac97_data;
> +
> + /* Enable unit clock */
> + clk_disable(nuc900_audio->clk);
Bit rot in the comments here.
> +/* bit definition of REG_ACTL_CON register */
> +#define AUDCLK_EN 0x8000
> +#define PFIFO_EN 0x4000
> +#define RFIFO_EN 0x2000
These constants (and the rest) really should be namespaced - they're
likely to collide with other definitions in, for example, CODEC drivers
used by machines.
> +#define IIS_EN 0x0002
Looks like there's I2S support to come?
> +static irqreturn_t nuc900_dma_interrupt(int irq, void *dev_id)
> +{
> +
> + snd_pcm_period_elapsed(substream);
> +
> + return IRQ_HANDLED;
This is done unconditionally - are you sure there can't be any spurious
interrupts (eg, error interrupts). It shouldn't cause any harm, of
course.
WARNING: multiple messages have this Message-ID (diff)
From: broonie@opensource.wolfsonmicro.com (Mark Brown)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] NUC900/audio: add nuc900 audio driver support
Date: Mon, 17 May 2010 03:44:26 +0100 [thread overview]
Message-ID: <20100517024425.GA2485@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4BF01069.6060102@gmail.com>
On Sun, May 16, 2010 at 11:34:01PM +0800, Wan ZongShun wrote:
This all looks pretty good. A few comments below but they're all fairly
minor and should be easy to address.
> index b1749bc..81d4848 100644
> --- a/sound/soc/Kconfig
> +++ b/sound/soc/Kconfig
> @@ -36,6 +36,7 @@ source "sound/soc/s3c24xx/Kconfig"
> source "sound/soc/s6000/Kconfig"
> source "sound/soc/sh/Kconfig"
> source "sound/soc/txx9/Kconfig"
> +source "sound/soc/nuc900/Kconfig"
Please keep the Kconfig and Makefile sorted, this helps avoid merge
issues.
> +#define NUC900_AC97_RATES (SNDRV_PCM_RATE_8000 | SNDRV_PCM_RATE_11025 |\
> + SNDRV_PCM_RATE_16000 | SNDRV_PCM_RATE_22050 |\
> + SNDRV_PCM_RATE_44100 | SNDRV_PCM_RATE_48000)
SNDRV_PCM_RATE_8000_48000.
> + if (!timeout)
> + dev_err(nuc900_audio->dev, "AC97 read register time out !\n");
> +
> + val = AUDIO_READ(nuc900_audio->mmio + ACTL_ACOS0) ;
If the read timed out shouldn't we be returning rather than continuing?
> + val = AUDIO_READ(nuc900_audio->mmio + ACTL_ACCON);
> + val &= (~AC_C_RES);
> + AUDIO_WRITE(nuc900_audio->mmio + ACTL_ACCON, val);
> + udelay(1000);
> + if (!(AUDIO_READ(nuc900_audio->mmio + ACTL_ACIS0) & CODEC_READY))
> + dev_err(nuc900_audio->dev, "AC97 codec cold reset failed!\n");
What is this actually checking in the hardware? Not all CODECs enable
the AC97 link by default after a cold reset, the standard allows them to
power up in a low power state which will
On the other hand, given that there's no warm reset operation perhaps
this isn't a big deal.
> +static void nuc900_ac97_remove(struct platform_device *pdev,
> + struct snd_soc_dai *dai)
> +{
> + struct nuc900_audio *nuc900_audio = nuc900_ac97_data;
> +
> + /* Enable unit clock */
> + clk_disable(nuc900_audio->clk);
Bit rot in the comments here.
> +/* bit definition of REG_ACTL_CON register */
> +#define AUDCLK_EN 0x8000
> +#define PFIFO_EN 0x4000
> +#define RFIFO_EN 0x2000
These constants (and the rest) really should be namespaced - they're
likely to collide with other definitions in, for example, CODEC drivers
used by machines.
> +#define IIS_EN 0x0002
Looks like there's I2S support to come?
> +static irqreturn_t nuc900_dma_interrupt(int irq, void *dev_id)
> +{
> +
> + snd_pcm_period_elapsed(substream);
> +
> + return IRQ_HANDLED;
This is done unconditionally - are you sure there can't be any spurious
interrupts (eg, error interrupts). It shouldn't cause any harm, of
course.
next prev parent reply other threads:[~2010-05-17 2:44 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-16 15:34 [PATCH] NUC900/audio: add nuc900 audio driver support Wan ZongShun
2010-05-16 15:34 ` Wan ZongShun
2010-05-17 2:44 ` Mark Brown [this message]
2010-05-17 2:44 ` Mark Brown
2010-05-17 6:26 ` Wan ZongShun
2010-05-17 6:26 ` Wan ZongShun
2010-05-17 13:46 ` Mark Brown
2010-05-17 13:46 ` Mark Brown
2010-05-17 21:53 ` Wan ZongShun
2010-05-17 21:53 ` Wan ZongShun
2010-05-18 2:59 ` [PATCH v2] " Wan ZongShun
2010-05-18 2:59 ` Wan ZongShun
2010-05-18 5:36 ` Wan ZongShun
2010-05-18 5:36 ` Wan ZongShun
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=20100517024425.GA2485@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=alsa-devel@alsa-project.org \
--cc=ben-linux@fluff.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lrg@slimlogic.co.uk \
--cc=mcuos.com@gmail.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.