linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Grant Likely <grant.likely@secretlab.ca>
To: linuxppc-dev@ozlabs.org, alsa-devel@alsa-project.org,
	liam.girdwood@wolfsonmicro.com, jonsmirl@gmail.com,
	timur@freescale.com
Subject: Re: [PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver
Date: Tue, 22 Jul 2008 17:23:17 -0400	[thread overview]
Message-ID: <20080722212316.GC12412@secretlab.ca> (raw)
In-Reply-To: <20080722100951.GB2572@rakim.wolfsonmicro.main>

On Tue, Jul 22, 2008 at 11:09:52AM +0100, Mark Brown wrote:
> On Tue, Jul 22, 2008 at 12:53:58AM -0600, Grant Likely wrote:
> 
> > Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
> 
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
> 
> There's a few issues that were raised on the previous review cycle that
> still need to be addressed but they should be fixable in incremental
> patches (and easier to review that way):
> 
> > +static int psc_i2s_trigger(struct snd_pcm_substream *substream, int cmd)
> 
> > +		spin_lock_irqsave(&psc_i2s->lock, flags);
> > +		/* first make sure it is low */
> > +		while ((in_8(&regs->ipcr_acr.ipcr) & 0x80) != 0)
> > +			;
> > +		/* then wait for the transition to high */
> > +		while ((in_8(&regs->ipcr_acr.ipcr) & 0x80) == 0)
> > +			;
> 
> These loops should really have some sort of time limit on them,
> otherwise they'll lock hard if the expected events don't happen.  Given
> that in slave mode they're synchronising with an externally generated
> clock this is something that might happen in practice and should produce
> better diagnostics.

Yes, I hope to rework these two lines entirely.  I'm not happy with the
current implementation either.

> > +	default:
> > +		dev_dbg(psc_i2s->dev, "invalid command\n");
> > +		return -EINVAL;
> > +	}
> 
> I'd really expect to see the other possible triggers handled, even if
> the appropriate action is to silently ignore them, rather than having
> them generate an error message.

Okay, I'll do that.

g.

  reply	other threads:[~2008-07-22 21:23 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-22  6:53 [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers Grant Likely
2008-07-22  6:53 ` [PATCH v3 2/3] ALSA SoC: Add mpc5200-psc I2S driver Grant Likely
2008-07-22 10:09   ` Mark Brown
2008-07-22 21:23     ` Grant Likely [this message]
2008-07-22 18:28   ` Jon Smirl
2008-07-22  6:54 ` [PATCH v3 3/3] ALSA SoC: Add Texas Instruments TLV320AIC26 codec driver Grant Likely
2008-07-22 10:34   ` Mark Brown
2008-07-22  9:27 ` [PATCH v3 1/3] ALSA SoC: Add OpenFirmware helper for matching bus and codec drivers Mark Brown
2008-07-22 16:38 ` Jon Smirl
2008-07-22 17:51   ` [alsa-devel] " Mark Brown
2008-07-22 21:21   ` Grant Likely

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=20080722212316.GC12412@secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --cc=alsa-devel@alsa-project.org \
    --cc=jonsmirl@gmail.com \
    --cc=liam.girdwood@wolfsonmicro.com \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=timur@freescale.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).