From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752798AbdKWM0c (ORCPT ); Thu, 23 Nov 2017 07:26:32 -0500 Received: from vps-vb.mhejs.net ([37.28.154.113]:53826 "EHLO vps-vb.mhejs.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752769AbdKWM0b (ORCPT ); Thu, 23 Nov 2017 07:26:31 -0500 Subject: Re: [PATCH 1/2] ALSA: pcm: add SNDRV_PCM_FORMAT_{S,U}20_4 To: Takashi Iwai Cc: Nicolin Chen , Xiubo Li , Jaroslav Kysela , Timur Tabi , alsa-devel@alsa-project.org, Liam Girdwood , Mark Brown , linuxppc-dev@lists.ozlabs.org, Fabio Estevam , linux-kernel References: <53d527c0-89f6-d501-09e9-1effea8a5bac@maciej.szmigiero.name> From: "Maciej S. Szmigiero" Message-ID: <38602575-acc5-2106-38ef-3a71076de398@maciej.szmigiero.name> Date: Thu, 23 Nov 2017 13:26:25 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 >> --- >> 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