[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20130726110554.GB9858@sirena.org.uk>
Date: Fri, 26 Jul 2013 12:05:54 +0100
From: Mark Brown <broonie@...nel.org>
To: Russell King - ARM Linux <linux@....linux.org.uk>
Cc: Jean-Francois Moine <moinejf@...e.fr>,
Liam Girdwood <lgirdwood@...il.com>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
Rob Herring <rob.herring@...xeda.com>,
alsa-devel@...a-project.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: [PATCH 4/4] ASoc: kirkwood: add DT support
On Fri, Jul 26, 2013 at 12:05:33AM +0100, Russell King - ARM Linux wrote:
> On Thu, Jul 25, 2013 at 08:19:05PM +0100, Mark Brown wrote:
> > On Thu, Jul 25, 2013 at 11:14:59AM +0200, Jean-Francois Moine wrote:
> > > + if (np) {
> > > + priv->burst = 128; /* might be 32 or 128 */
> > > + } else if (data) {
> > When you posted this before I queried how and why the value might vary -
> > I see the code is the same and I don't recall a reply.
> This is the DMA burst size, and can be either 32 or 128 bytes according
> to the docs. Everyone seems to pass this as 128 bytes in their platform
> data to date, which I guess is why its ended up being hard coded as 128.
OK.
> However, whether it needs to be configurable or not is debatable - obviously
> the hardware allows it, but that doesn't mean it has to be exposed. If
> ALSA has some kind of way of specifying a "low latency" mode where 128
> byte vs 32 byte fetches would make a significant difference, then it may
> be something to look at.
This sort of configuration would normally be keyed off the period size
and so vary at runtime depending on what the application does when it
opens a stream. Sounds like something someone can worry about if they
have the requirement.
Download attachment "signature.asc" of type "application/pgp-signature" (837 bytes)
Powered by blists - more mailing lists