On 06/09/2014 11:24 PM, Mark Brown wrote:
On Fri, Jun 06, 2014 at 04:05:31PM +0300, Peter Ujfalusi wrote:
Correct the hw_params callback to configure the codec correctly in case of S24_3LE format. S24_LE is not defined as supported format for the codec.
These should both be supported by the time things get down to the wire - the memory layout shouldn't matter.
The codec itself has support for 16, 20, 24 and 32 bits data. The 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.
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. 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).
So I still think that this is a bit more complicated than it looks