From: Wan ZongShun <mcuos.com@gmail.com>
To: Mark Brown <broonie@opensource.wolfsonmicro.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 14:26:12 +0800 [thread overview]
Message-ID: <4BF0E184.204@gmail.com> (raw)
In-Reply-To: <20100517024425.GA2485@opensource.wolfsonmicro.com>
Dear Mark,
Thanks a lot for your help, and I have other questions needed your help below.
> 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
The bit 'CODEC_READY' indicates the external AC97 audio CODEC is ready,
I just forget to implement the warm reset operation, if need, I will do
it. In addition, Can I add the checking CODEC_READY operation to warm reset
function?
> 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
I rechecked the latest datasheet, and I find above bits has been removed,
so I delete them here.
> 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?
>
Yes,nuc900 supports both IIS and AC97,but my board only enable AC97 support,
what's up here?
>> +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.
>
Wan .(Vincent)
WARNING: multiple messages have this Message-ID (diff)
From: mcuos.com@gmail.com (Wan ZongShun)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] NUC900/audio: add nuc900 audio driver support
Date: Mon, 17 May 2010 14:26:12 +0800 [thread overview]
Message-ID: <4BF0E184.204@gmail.com> (raw)
In-Reply-To: <20100517024425.GA2485@opensource.wolfsonmicro.com>
Dear Mark,
Thanks a lot for your help, and I have other questions needed your help below.
> 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
The bit 'CODEC_READY' indicates the external AC97 audio CODEC is ready,
I just forget to implement the warm reset operation, if need, I will do
it. In addition, Can I add the checking CODEC_READY operation to warm reset
function?
> 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
I rechecked the latest datasheet, and I find above bits has been removed,
so I delete them here.
> 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?
>
Yes,nuc900 supports both IIS and AC97,but my board only enable AC97 support,
what's up here?
>> +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.
>
Wan .(Vincent)
next prev parent reply other threads:[~2010-05-17 6:26 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
2010-05-17 2:44 ` Mark Brown
2010-05-17 6:26 ` Wan ZongShun [this message]
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=4BF0E184.204@gmail.com \
--to=mcuos.com@gmail.com \
--cc=alsa-devel@alsa-project.org \
--cc=ben-linux@fluff.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=lrg@slimlogic.co.uk \
/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.