All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Peter Ujfalusi <peter.ujfalusi@ti.com>
Cc: alsa-devel@alsa-project.org, patches@opensource.wolfsonmicro.com,
	Liam Girdwood <lrg@ti.com>
Subject: Re: [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI
Date: Tue, 17 Jan 2012 14:56:47 +0000	[thread overview]
Message-ID: <20120117145646.GG2944@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4F15833B.2000808@ti.com>

On Tue, Jan 17, 2012 at 03:18:35PM +0100, Peter Ujfalusi wrote:

> It is mostly true. DAC33 can be configured to operate internally 16bit
> or 24msbit/32bit for example.

Well, if it's doing something more complicated that doesn't fit in the
framework then it shouldn't be doing that.

> It does not give any useful information for application that the codec
> will upsample the 16bit data internally to 24 bits. It does not really
> matter for them since all 16bit data will be used by the codec.

Oh, I dunno - I'm sure someone could think of a use for it.

> > On the CPU side specifying significant bits would normally only be
> > appropriate on PDM interfaces as they have most of a DAC or ADC in them
> > to move between the sampled and PDM formats.  I'd be surprised to see
> > anything else setting these flags, most of the hardware is just passing
> > the data straight through.

> True, the CPU side mostly passes the data as it is, it does not care
> about msbits. For McPDM it is different since the internal FIFO in 24bit
> long word lines, so if application would use all 32bit we it will loose

Right, like I say that's because it's got most of a DAC in it.

> 8bit lsb. This can make difference for PA when applying the digital gain
> in SW.

Well, it saves it a bit of effort but that's about it.

  reply	other threads:[~2012-01-17 14:56 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-16 18:41 [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI Mark Brown
2012-01-16 18:41 ` [PATCH 2/2] ASoC: 24 bits are significant on the WM8996 audio interfaces Mark Brown
2012-01-16 22:26 ` [PATCH 1/2] ASoC: Allow drivers to specify how many bits are significant on a DAI Girdwood, Liam
2012-01-16 22:42   ` Mark Brown
2012-01-17  8:56     ` Peter Ujfalusi
2012-01-17  8:55 ` Peter Ujfalusi
2012-01-17 11:38   ` Mark Brown
2012-01-17 13:06     ` Peter Ujfalusi
2012-01-17 13:19       ` Mark Brown
2012-01-17 14:18         ` Peter Ujfalusi
2012-01-17 14:56           ` Mark Brown [this message]
2012-01-17 16:08             ` Peter Ujfalusi
2012-01-17 16:44               ` Mark Brown
2012-01-17 17:55                 ` Peter Ujfalusi
2012-01-17 18:17                   ` Mark Brown
2012-01-17 18:51                     ` Peter Ujfalusi
2012-01-17 18:59                       ` Mark Brown

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=20120117145646.GG2944@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=lrg@ti.com \
    --cc=patches@opensource.wolfsonmicro.com \
    --cc=peter.ujfalusi@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.