All of lore.kernel.org
 help / color / mirror / Atom feed
From: Liam Girdwood <lrg@slimlogic.co.uk>
To: Peter Ujfalusi <peter.ujfalusi@nokia.com>
Cc: "ext Olaya, Margarita" <magi.olaya@ti.com>,
	alsa-devel@alsa-project.org,
	ext Mark Brown <broonie@opensource.wolfsonmicro.com>
Subject: Re: [PATCH 2/2] ASoC: omap: Stop DMA re enabling in self linkage mode
Date: Tue, 07 Dec 2010 15:17:34 +0000	[thread overview]
Message-ID: <1291735054.3275.86.camel@odin> (raw)
In-Reply-To: <201012071638.36075.peter.ujfalusi@nokia.com>

On Tue, 2010-12-07 at 16:38 +0200, Peter Ujfalusi wrote:
> On Tuesday 07 December 2010 16:05:12 ext Mark Brown wrote:
> > On Tue, Dec 07, 2010 at 11:17:26AM +0200, Peter Ujfalusi wrote:
> > > I have not seen this happening on OMAP2/3, or at least I'm not aware of
> > > it. Is this problem OMAP4 only?
> > > Do you know if this happens on playback, capture or in both direction?
> > > Is it worth to do this workaround only on OMAP4?
> > 
> > Given that the patch should cause at most a single read from a register
> > when tearing down DMA if it's not required I'd guess it's safer to just
> > unconditionally enable the workaround on the off chance that it's just
> > reallly rare rather than not needed?
> 
> Sure, it is a single read to a register, but generally I'm a bit nervous, when 
> we have a while loop without timeout counter.
> In theory we could have infinite loop, if the HW has a bad day...
> This could be safe on all OMAP platforms, but I think it has been only tested on 
> OMAP4.
> If this could happen, than IMHO it has to be handled by the omap_stop_dma, since 
> other drivers could be hit by the same problem (there might be ERRATA for it 
> already for OMAP4).
> 

Afaik, this has also been tested on OMAP3. Not sure about OMAP2 and most
likely not tested on OMAP1.

Liam 

  parent reply	other threads:[~2010-12-07 15:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-06 22:34 [PATCH 2/2] ASoC: omap: Stop DMA re enabling in self linkage mode Olaya, Margarita
2010-12-06 22:47 ` Mark Brown
2010-12-07  9:17 ` Peter Ujfalusi
2010-12-07 14:05   ` Mark Brown
2010-12-07 14:38     ` Peter Ujfalusi
2010-12-07 14:43       ` Mark Brown
2010-12-07 15:17       ` Liam Girdwood [this message]
2010-12-07 16:00       ` Jarkko Nikula

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=1291735054.3275.86.camel@odin \
    --to=lrg@slimlogic.co.uk \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=magi.olaya@ti.com \
    --cc=peter.ujfalusi@nokia.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 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.