All of lore.kernel.org
 help / color / mirror / Atom feed
From: Troy Kisky <troy.kisky@boundarydevices.com>
To: "Nori, Sekhar" <nsekhar@ti.com>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"davinci-linux-open-source@linux.davincidsp.com"
	<davinci-linux-open-source@linux.davincidsp.com>,
	"broonie@sirena.org.uk" <broonie@sirena.org.uk>
Subject: Re: [PATCH 4/4] ASoC: DaVinci: pcm, fix underrun by using sram
Date: Wed, 14 Jul 2010 10:46:59 -0700	[thread overview]
Message-ID: <4C3DF813.4050908@boundarydevices.com> (raw)
In-Reply-To: <B85A65D85D7EB246BE421B3FB0FBB59301E7B42662@dbde02.ent.ti.com>

Nori, Sekhar wrote:
> On Wed, Jul 14, 2010 at 00:31:00, troy.kisky@boundarydevices.com wrote:
>> On Tue 13/07/10 6:00 AM , "Nori, Sekhar" nsekhar@ti.com sent:
>>
>
>>       The reason is so that the IRAM data can be fetched and used
>> while
>>
>>       EVENTQ_1 fetches the next buffer of data from sdram into IRAM.
> 
> Thanks for the explanation. That sounds reasonable.
> 
> Just curious as to whether you actually faced an issue
> when using the same event queue for both transfers?
> 
> I just tested this on DM365 with both transfers on EDMAQ_0
> with 16K each of capture and playback IRAM at 48KHz
> sampling rate and did not find any issue.
> 
> Anyway it makes sense to make provision for platform to choose
> different queues for both transfers so will implement my patch
> that way.
> 
> Thanks,
> Sekhar
> 

IIRC, the DM365 has a fifo, the 6443/6446 doesn't. So, the 365 doesn't
need to use IRAM and shouldn't use it. Test using the same controller
on a board without a fifo.

Troy

  reply	other threads:[~2010-07-14 17:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-13 19:01 [PATCH 4/4] ASoC: DaVinci: pcm, fix underrun by using sram troy.kisky
     [not found] ` <51883.1279047660-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2010-07-14 13:05   ` Nori, Sekhar
2010-07-14 17:46     ` Troy Kisky [this message]
  -- strict thread matches above, loose matches on Subject: below --
2009-11-16 23:52 [PATCH 1/4] ASoC: DaVinci: remove requirement that dma_params is 1st in structure Troy Kisky
2009-11-16 23:52 ` [PATCH 2/4] ASoC: DaVinci: i2s, reduce underruns by combining into 1 element Troy Kisky
2009-11-16 23:52   ` [PATCH 3/4] ASoC: DaVinci: pcm, rename variables in prep for ping/pong Troy Kisky
2009-11-16 23:52     ` [PATCH 4/4] ASoC: DaVinci: pcm, fix underrun by using sram Troy Kisky
     [not found]       ` <1258415554-31069-4-git-send-email-troy.kisky-Q5RJGjKts06CY9SHAMCTRUEOCMrvLtNR@public.gmane.org>
2010-07-13 11:00         ` Nori, Sekhar

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=4C3DF813.4050908@boundarydevices.com \
    --to=troy.kisky@boundarydevices.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@sirena.org.uk \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=nsekhar@ti.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.