[alsa-devel] [PATCH] ASoC: tlv320aic3x: Correct S24_3LE support

Mark Brown broonie at kernel.org
Mon Jun 23 17:18:22 CEST 2014


On Mon, Jun 23, 2014 at 04:01:13PM +0300, Peter Ujfalusi wrote:

> AIC3X_FORMATS is correct:
> #define AIC3X_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S20_3LE | \
> 			SNDRV_PCM_FMTBIT_S24_3LE | SNDRV_PCM_FMTBIT_S32_LE)

> While in hw_params the switch was not handling the S24_3LE but it was defined
> as S24_LE. So the code was not correct: It advertised that it supportsd
> S24_3LE and was not handling it, but it was handling S24_LE which would not
> happen with this codec driver since the format is not supported - as it was
> defined by the AIC3X_FORMATS.

> This is a fix for the current driver.

Yes, but the fix should be to support both.

> > I really need to get round to doing
> > the rest of the conversions to use params_width() which should ensure
> > this.

> Not sure how this would work at the end to be honest for all platforms and codecs.
> How should the bitclock need to be configured for S24_3LE, S24_LE and S32_LE
> msbits=24? They are at the end have 24bits audio data but in memory they are
> stored in different ways.

The number of bits on the wire should be the number specified in the
format.

> Aic3x for example need to be configured to 24bit mode (24 clocks/channel if it
> is master) so it is going to 'pull' that amount from the CPU side. This can
> not be used with OMAP's sDMA/McBSP but davinci's eDMA/McASP can support it. I
> can even get daVinci to 'extract' the valid 24 bits from the 32bit sample
> coming via eDMA (mask/rotate/reverse operation).

Sure, so it only supports exactly 24 bit sample formats in master mode.
That's what's expected by default.

> So I still think that this is a bit more complicated than it looks

I'm not seeing anything particularly hard here.  The main thing is that
we ought to do something for dealing with extra BCLKs (eg, a device that
can tolerate extra BCLKs can have the other end generating more data
quite happily).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20140623/10ee8f91/attachment.sig>


More information about the Alsa-devel mailing list