alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Arnaud Patard <apatard@mandriva.com>
Cc: alsa-devel@alsa-project.org, nico@fluxnic.net, saeed@marvell.com,
	tbm@cyrius.com
Subject: Re: [patch 5/6] kirkwood: Add i2s support
Date: Wed, 12 May 2010 15:59:44 +0100	[thread overview]
Message-ID: <20100512145944.GD8082@rakim.wolfsonmicro.main> (raw)
In-Reply-To: <m339xxuqvy.fsf@anduin.mandriva.com>

On Wed, May 12, 2010 at 04:38:25PM +0200, Arnaud Patard wrote:
> Mark Brown <broonie@opensource.wolfsonmicro.com> writes:
> > On Tue, May 11, 2010 at 06:23:47PM +0200, apatard@mandriva.com wrote:

> >> +		if (status & ~(KIRKWOOD_INT_CAUSE_PLAY_BYTES | \
> >> +				KIRKWOOD_INT_CAUSE_REC_BYTES))
> >> +			return IRQ_NONE;

> > Surely it'd make sense to log the unexpected interrupts for diagnostics?
> > You should never get here if there are no interrupts you've enabled.
> > Unless the interrupt is shared, but that'd be a bit surprising for a
> > SoC.

> it's not shared iirc but there are different possible interrupt
> cause. There used to be a message but I think it has been removed by
> error. Should I had it back or remove the check ? (I prefer adding it
> back but your point of view does matter).

Add it back and also log it, but also fix the IRQ_NONE thing - it's
defintiely going to be wrong if this is the second spin through the loop
for example.

> > It also looks like it'd be more sensible to either drop the do/while
> > loop entirely (the IRQ core should handle the interrupt still being
> > asserted and it doesn't look like any of the handling should take so
> > long that interrupts reassert while it's running anyway) or move the
> > handling of error interrupts and the first read into the loop so you
> > don't have two slightly different paths.

> The loop is there to handle playback and record interrupts at the same

Why is this required?  You check both interrupts in sequence anyway.

> time. As regards the error interrupts, I preferred to put outside the
> loop to differentiate "normal" interrupts from "error" interrupts.

Actually looking again they are in a separate status register too so I
suppose that's not quite so bad.  It is a bit odd that they all come in
on the same status line and can't be muxed out from a single register
but hardware designers are like that sometimes.

> >> +		mask = readl(priv->io + KIRKWOOD_INT_MASK);
> >> +		status = readl(priv->io + KIRKWOOD_INT_CAUSE) & mask;

> > This masking didn't happen prior to the first entry into the loop.

> Can you explain a little bit more ? at the beginning of the function,
> there are the 2 same lines.

I was looking at the read of cause there, I hadn't noticed the separate
status register.

> >> +static int kirkwood_dma_mmap(struct snd_pcm_substream *substream,
> >> +		struct vm_area_struct *vma)
> >> +{
> >> +	struct snd_pcm_runtime *runtime = substream->runtime;
> >> +
> >> +	return dma_mmap_coherent(substream->pcm->card->dev, vma,
> >> +					runtime->dma_area,
> >> +					runtime->dma_addr,
> >> +					runtime->dma_bytes);
> >> +}

> > Hrm, this looks like there should be a utility function to do it, it's
> > not terribly driver specific.

> hmm... I need to double check. I got some troubles with this kind of
> stuff on my ST LS2E/F mips platforms, so I wrote something known to be
> working.

The point is that it looks like either there should already be an
implementation of this function you can use or this should be put
somewhere were other folks are able to use it.

> >> +	mv_audio_init(priv->io);

> > Seems a bit odd ot have the separate init function in the middle of a
> > bunch of other register writes.

> I want to have interrupts disable before calling it. I don't want bad
> suprises.

My point is that you may as well just have the mv_audio_init() function
in line in the code here, jumping out into another function seems a bit
odd when all it is is more register writes.

  reply	other threads:[~2010-05-12 14:59 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-11 16:23 [patch 0/6] kirkwood openrd client audio support apatard
2010-05-11 16:23 ` [patch 1/6] kirkwood: add audio functions apatard
2010-05-12  8:56   ` Liam Girdwood
2010-05-11 16:23 ` [patch 2/6] openrd-client: initialise audio apatard
2010-05-12  7:09   ` saeed bishara
2010-05-11 16:23 ` [patch 3/6] asoc: Add SOC_DOUBLE_R_SX_TLV control apatard
2010-05-12  8:59   ` Mark Brown
2010-05-13  9:30   ` Mark Brown
2010-05-11 16:23 ` [patch 4/6] cs42l51: add asoc driver apatard
2010-05-11 19:36   ` Timur Tabi
2010-05-12  9:56   ` Mark Brown
2010-05-12 13:46     ` Arnaud Patard
2010-05-12 14:08       ` Mark Brown
2010-05-11 16:23 ` [patch 5/6] kirkwood: Add i2s support apatard
2010-05-12 10:24   ` Mark Brown
2010-05-12 10:43     ` Saeed Bishara
2010-05-12 10:48     ` saeed bishara
2010-05-12 10:54       ` Mark Brown
2010-05-12 14:38     ` Arnaud Patard
2010-05-12 14:59       ` Mark Brown [this message]
2010-05-11 16:23 ` [patch 6/6] kirkwood: Add audio support to openrd client platforms apatard
2010-05-12 10:26   ` Mark Brown
2010-05-12  6:47 ` [patch 0/6] kirkwood openrd client audio support saeed bishara
  -- strict thread matches above, loose matches on Subject: below --
2010-05-27 12:57 [patch 0/6] kirkwood openrd client audio support - v4 apatard
2010-05-27 12:57 ` [patch 5/6] kirkwood: Add i2s support apatard

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=20100512145944.GD8082@rakim.wolfsonmicro.main \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=apatard@mandriva.com \
    --cc=nico@fluxnic.net \
    --cc=saeed@marvell.com \
    --cc=tbm@cyrius.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 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).