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)
next prev parent reply other threads:[~2010-05-17 6:26 UTC|newest]
Thread overview: 7+ 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-17 2:44 ` Mark Brown
2010-05-17 6:26 ` Wan ZongShun [this message]
2010-05-17 13:46 ` Mark Brown
2010-05-17 21:53 ` Wan ZongShun
2010-05-18 2:59 ` [PATCH v2] " 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 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).