All of lore.kernel.org
 help / color / mirror / Atom feed
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)

  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.