[alsa-devel] [PATCH 1/2] ALSA: pcm: add SNDRV_PCM_FORMAT_{S, U}20_4

[Maciej S. Szmigiero]

On 23.11.2017 09:08, Takashi Iwai wrote:
> On Wed, 22 Nov 2017 20:17:34 +0100,
>  Maciej S. Szmigiero  wrote:
>>
>> This format is similar to existing SNDRV_PCM_FORMAT_{S,U}20_3 that keep
>> 20-bit PCM samples in 3 bytes, however i.MX6 platform SSI FIFO does not
>> allow 3-byte accesses (including DMA) so a 4-byte format is needed for it.
>>
>> Signed-off-by: Maciej S. Szmigiero <mail at maciej.szmigiero.name>
>> ---
>>  include/sound/pcm.h         |  8 ++++++++
>>  include/sound/soc-dai.h     |  2 ++
>>  include/uapi/sound/asound.h | 10 +++++++++-
>>  sound/core/pcm_misc.c       | 16 ++++++++++++++++
>>  4 files changed, 35 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/sound/pcm.h b/include/sound/pcm.h
>> index 24febf9e177c..7ad2d3f0934f 100644
>> --- a/include/sound/pcm.h
>> +++ b/include/sound/pcm.h
>> @@ -191,6 +191,10 @@ struct snd_pcm_ops {
>>  #define SNDRV_PCM_FMTBIT_DSD_U32_LE	_SNDRV_PCM_FMTBIT(DSD_U32_LE)
>>  #define SNDRV_PCM_FMTBIT_DSD_U16_BE	_SNDRV_PCM_FMTBIT(DSD_U16_BE)
>>  #define SNDRV_PCM_FMTBIT_DSD_U32_BE	_SNDRV_PCM_FMTBIT(DSD_U32_BE)
>> +#define SNDRV_PCM_FMTBIT_S20_4LE	_SNDRV_PCM_FMTBIT(S20_4LE)
>> +#define SNDRV_PCM_FMTBIT_U20_4LE	_SNDRV_PCM_FMTBIT(U20_4LE)
>> +#define SNDRV_PCM_FMTBIT_S20_4BE	_SNDRV_PCM_FMTBIT(S20_4BE)
>> +#define SNDRV_PCM_FMTBIT_U20_4BE	_SNDRV_PCM_FMTBIT(U20_4BE)
> 
> The conventional names aren't with "4" suffix,
> e.g. SNDRV_PCM_FMTBIT_S20_LE.

Will rename it in a respin.
> Also, there are still empty slots under 32, e.g. start from 25.
> The formats over 31 were used for 3 bytes or other unusual formats
> (although nowadays it makes little sense), and the slots < 32 would
> fit for 4 bytes linear format.

Will renumber these formats to start from 25 in a respin.

> It's still an open question whether we should increase the protocol
> number when we add a new PCM format definition.  I guess it's not, as
> the ABI behavior itself doesn't change, but I might have overlooked
> some possible breakage.

This isn't an incompatible, application-breaking, ABI change (it is
rather kind of an additional "ABI"), so I think an ALSA protocol number
should not be increased for it.

> thanks,
> 
> Takashi
> 

Thanks,
Maciej