From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14F1BC433E2 for ; Thu, 3 Sep 2020 07:40:35 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D173020684 for ; Thu, 3 Sep 2020 07:40:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="myWiETMl"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="t8qsS6P2" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728251AbgICHke (ORCPT ); Thu, 3 Sep 2020 03:40:34 -0400 Received: from wnew4-smtp.messagingengine.com ([64.147.123.18]:60797 "EHLO wnew4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726686AbgICHkb (ORCPT ); Thu, 3 Sep 2020 03:40:31 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id C890CB01; Thu, 3 Sep 2020 03:40:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 03 Sep 2020 03:40:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=3d+fTLgpTQcvjVM12OzE052YfvZ PoumZnCP7vT0BNTc=; b=myWiETMlIlUWHiTv8WnuXR+IYKbfeY5RfHZzjkLV+Xw vOJYm7vw+zvumPkFdHPXWFtkzhTYSTTd0kc6GrkplI4ro5xwGlVFKwTKqL6jra1X ksTvu1GJCw0OMAelGSu1027OYyKQ3kBURhut6zWOaxQfFjr8GlcY8lBvxPNqzMtK OUGZeAYHEmTpCkcZhosndWdeEoOKeOFu53O8EXVO+Tr4dFCir9889Qe1u5Uvg/c1 TI26DKLLToqDDNovI8WA/o22S9QZub5mhlrJF27B32oa6Gf8IKWigG8fYNu7ORL0 u1CsM+fhrutvTxQq7l52RBAsbBGUHfPKY1jS0tXI8Kw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=3d+fTL gpTQcvjVM12OzE052YfvZPoumZnCP7vT0BNTc=; b=t8qsS6P2vWW1REZJvCGNSX pl+k4eLlBP1UE8HWUavDheeb/zxkwmSlFYeSGsvk2ur7ajehHxmyBh6HsxfT0MTi nFwP/PWOXjXKxj/z0XBSr1lbAUNYXhVRRRa0q9QKX/Ay1bndTmlUSrTr3Mv6tqRg tANMq//E+NVwezpXe9BybmRJ8g/ws8isYuYOH0xt9sc8aKKf6ZP6mxjQ/p/dT7f3 JoVGPXZUtrGj6moTYiCmcOLj35IsjjIxhqgapxa9SOIZe8iL9Zi8yI/cWnZWxJk0 HF/RZCc3Nm9WIzf1B2PXx2YlfVkXHDBDjDD6wIj0mWJgHPfs0s7pQlec9/TFcfUA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegtddguddvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpeetledvveffgeeuheejtdegteekueetjeevgfeivefgieegkedtieelgeeh gfetheenucffohhmrghinhepsghoohhtlhhinhdrtghomhdprghlshgrqdhprhhojhgvtg htrdhorhhgnecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B68C328005D; Thu, 3 Sep 2020 03:40:24 -0400 (EDT) Date: Thu, 3 Sep 2020 09:40:23 +0200 From: Maxime Ripard To: Samuel Holland Cc: Jernej =?utf-8?Q?=C5=A0krabec?= , peron.clem@gmail.com, Chen-Yu Tsai , Mark Brown , Liam Girdwood , Rob Herring , Jaroslav Kysela , Takashi Iwai , Marcus Cooper , alsa-devel@alsa-project.org, devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com Subject: Re: [linux-sunxi] [PATCH 05/16] ASoc: sun4i-i2s: Add 20 and 24 bit support Message-ID: <20200903074023.jccqp45br3er4h3g@gilmour.lan> References: <20200704113902.336911-1-peron.clem@gmail.com> <20200704113902.336911-6-peron.clem@gmail.com> <1e320dfd-9388-54b2-dba9-7def0bf4bbad@sholland.org> <9148679.oVN3Z7rve9@kista> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hf5an3s4qg2ib7h7" Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --hf5an3s4qg2ib7h7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 02, 2020 at 09:22:33PM -0500, Samuel Holland wrote: > On 9/2/20 1:10 PM, Jernej =C5=A0krabec wrote: > > Hi Samuel! > >=20 > > Dne petek, 10. julij 2020 ob 07:44:51 CEST je Samuel Holland napisal(a): > >> On 7/4/20 6:38 AM, Cl=C3=A9ment P=C3=A9ron wrote: > >>> From: Marcus Cooper > >>> > >>> Extend the functionality of the driver to include support of 20 and > >>> 24 bits per sample. > >>> > >>> Signed-off-by: Marcus Cooper > >>> Signed-off-by: Cl=C3=A9ment P=C3=A9ron > >>> --- > >>> > >>> sound/soc/sunxi/sun4i-i2s.c | 11 +++++++++-- > >>> 1 file changed, 9 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > >>> index f78167e152ce..bc7f9343bc7a 100644 > >>> --- a/sound/soc/sunxi/sun4i-i2s.c > >>> +++ b/sound/soc/sunxi/sun4i-i2s.c > >>> @@ -577,6 +577,9 @@ static int sun4i_i2s_hw_params(struct > >>> snd_pcm_substream *substream,>=20 > >>> case 16: > >>> width =3D DMA_SLAVE_BUSWIDTH_2_BYTES; > >>> break; > >>> > >>> + case 32: > >>> + width =3D DMA_SLAVE_BUSWIDTH_4_BYTES; > >>> + break; > >> > >> This breaks the sun4i variants, because sun4i_i2s_get_wss returns 4 fo= r a 32 > >> bit width, but it needs to return 3. > >=20 > > I'm not sure what has WSS with physical width and DMA? >=20 > This is the change where creating a S24_LE stream no longer fails with -E= INVAL. > So this is the change where userspace stops downsampling 24-bit audio sou= rces. > So this is the change where playback of 24-bit audio sources breaks, beca= use WSS > is programmed wrong. >=20 > >> As a side note, I wonder why we use the physical width (the spacing be= tween > >> samples in RAM) to drive the slot width. S24_LE takes up 4 bytes per s= ample > >> in RAM, which we need for DMA. But I don't see why we would want to > >> transmit the padding over the wire. I would expect it to be transmitte= d the > >> same as S24_3LE (which has no padding). It did not matter before, beca= use > >> the only supported format had no padding. > >=20 > > Allwinner DMA engines support only 1, 2, 4 and sometimes 8 bytes for bu= s=20 > > width, so if sample is 24 bits in size, we have no other way but to tra= nsmit=20 > > padding too. >=20 > I understand why we do 4 byte DMA from RAM <=3D> I2S FIFO; that was not my > question. I'm referring to the actual wire format (FIFO <=3D> PCM_DIN/DOU= T). The > sample is already truncated from 32 bits to 24 bits in the FIFO -- that's= what > TXIM and RXOM in FIFO_CTRL control. >=20 > If a sample is 24 bits wide, why would we send 32 BCLKs for every LRCK? I= would > expect the slot width to match the sample resolution by default. But yet = we have > this code in the driver: >=20 > unsigned int word_size =3D params_width(params); > unsigned int slot_width =3D params_physical_width(params); >=20 > I think slot_width should be the same as word_size, and I suggest changin= g it > before adding 20/24-bit support. Generally speaking, the slot width doesn't necessarily match the physical width. With TDM for example you may very well have slots larger than their samples. That being said, S24 is explicitly a format where you send a sample of 24 bits in a 32-bit word (in the lowest three bytes, little endian) See: https://elixir.bootlin.com/linux/v5.9-rc3/source/sound/core/pcm_misc.c#L75 https://mailman.alsa-project.org/pipermail/alsa-devel/2013-April/061073.html 24 bits of data over three bytes like you suggest is S24_3LE Maxime --hf5an3s4qg2ib7h7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX1Cd5wAKCRDj7w1vZxhR xQAeAP9vjuO9Y3b+CKzmLOQ15SsDQDnKlVOEAQ0bmzds+Gn3dgEAvPzB50hkYbu/ m3XNc7Nyk17Y4tBWmLWyuoQ8IodG1QM= =gvkH -----END PGP SIGNATURE----- --hf5an3s4qg2ib7h7-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 91504C433E2 for ; Thu, 3 Sep 2020 07:41:38 +0000 (UTC) Received: from alsa0.perex.cz (alsa0.perex.cz [77.48.224.243]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id EEAC920775 for ; Thu, 3 Sep 2020 07:41:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=alsa-project.org header.i=@alsa-project.org header.b="WJH1M9kU"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="myWiETMl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="t8qsS6P2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EEAC920775 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=alsa-devel-bounces@alsa-project.org Received: from alsa1.perex.cz (alsa1.perex.cz [207.180.221.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa0.perex.cz (Postfix) with ESMTPS id 7130818BD; Thu, 3 Sep 2020 09:40:46 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa0.perex.cz 7130818BD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=alsa-project.org; s=default; t=1599118896; bh=abGRDPbucUsMZQ4A7O0ONgqImcFTk+wWfZTgc8w8R6w=; h=Date:From:To:Subject:References:In-Reply-To:Cc:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=WJH1M9kUotyDd2swGzVUmK52uHZ117Vf4Je5/zG3cf8t7bTsUkA6DBsU1IA5oV0sv mug/D6/iFZhK/8HUHN/Tc/G+Y4ilRTCtWkCUqS0pG3X2A3b3E+6dILV3+ps4Bto97+ p02JbHcImXUXZG8YC2ZnBVOEcgcanA1OeWqkV4r4= Received: from alsa1.perex.cz (localhost.localdomain [127.0.0.1]) by alsa1.perex.cz (Postfix) with ESMTP id F0227F8020D; Thu, 3 Sep 2020 09:40:45 +0200 (CEST) Received: by alsa1.perex.cz (Postfix, from userid 50401) id 2E6CCF80217; Thu, 3 Sep 2020 09:40:44 +0200 (CEST) Received: from wnew4-smtp.messagingengine.com (wnew4-smtp.messagingengine.com [64.147.123.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by alsa1.perex.cz (Postfix) with ESMTPS id B3C23F800F0 for ; Thu, 3 Sep 2020 09:40:33 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.11.0 alsa1.perex.cz B3C23F800F0 Authentication-Results: alsa1.perex.cz; dkim=pass (2048-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="myWiETMl"; dkim=pass (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="t8qsS6P2" Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id C890CB01; Thu, 3 Sep 2020 03:40:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 03 Sep 2020 03:40:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=3d+fTLgpTQcvjVM12OzE052YfvZ PoumZnCP7vT0BNTc=; b=myWiETMlIlUWHiTv8WnuXR+IYKbfeY5RfHZzjkLV+Xw vOJYm7vw+zvumPkFdHPXWFtkzhTYSTTd0kc6GrkplI4ro5xwGlVFKwTKqL6jra1X ksTvu1GJCw0OMAelGSu1027OYyKQ3kBURhut6zWOaxQfFjr8GlcY8lBvxPNqzMtK OUGZeAYHEmTpCkcZhosndWdeEoOKeOFu53O8EXVO+Tr4dFCir9889Qe1u5Uvg/c1 TI26DKLLToqDDNovI8WA/o22S9QZub5mhlrJF27B32oa6Gf8IKWigG8fYNu7ORL0 u1CsM+fhrutvTxQq7l52RBAsbBGUHfPKY1jS0tXI8Kw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=3d+fTL gpTQcvjVM12OzE052YfvZPoumZnCP7vT0BNTc=; b=t8qsS6P2vWW1REZJvCGNSX pl+k4eLlBP1UE8HWUavDheeb/zxkwmSlFYeSGsvk2ur7ajehHxmyBh6HsxfT0MTi nFwP/PWOXjXKxj/z0XBSr1lbAUNYXhVRRRa0q9QKX/Ay1bndTmlUSrTr3Mv6tqRg tANMq//E+NVwezpXe9BybmRJ8g/ws8isYuYOH0xt9sc8aKKf6ZP6mxjQ/p/dT7f3 JoVGPXZUtrGj6moTYiCmcOLj35IsjjIxhqgapxa9SOIZe8iL9Zi8yI/cWnZWxJk0 HF/RZCc3Nm9WIzf1B2PXx2YlfVkXHDBDjDD6wIj0mWJgHPfs0s7pQlec9/TFcfUA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegtddguddvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpeetledvveffgeeuheejtdegteekueetjeevgfeivefgieegkedtieelgeeh gfetheenucffohhmrghinhepsghoohhtlhhinhdrtghomhdprghlshgrqdhprhhojhgvtg htrdhorhhgnecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B68C328005D; Thu, 3 Sep 2020 03:40:24 -0400 (EDT) Date: Thu, 3 Sep 2020 09:40:23 +0200 From: Maxime Ripard To: Samuel Holland Subject: Re: [linux-sunxi] [PATCH 05/16] ASoc: sun4i-i2s: Add 20 and 24 bit support Message-ID: <20200903074023.jccqp45br3er4h3g@gilmour.lan> References: <20200704113902.336911-1-peron.clem@gmail.com> <20200704113902.336911-6-peron.clem@gmail.com> <1e320dfd-9388-54b2-dba9-7def0bf4bbad@sholland.org> <9148679.oVN3Z7rve9@kista> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hf5an3s4qg2ib7h7" Content-Disposition: inline In-Reply-To: Cc: devicetree@vger.kernel.org, Jernej =?utf-8?Q?=C5=A0krabec?= , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com, Takashi Iwai , Liam Girdwood , Rob Herring , Marcus Cooper , Chen-Yu Tsai , Mark Brown , peron.clem@gmail.com, linux-arm-kernel@lists.infradead.org X-BeenThere: alsa-devel@alsa-project.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Alsa-devel mailing list for ALSA developers - http://www.alsa-project.org" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: "Alsa-devel" --hf5an3s4qg2ib7h7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 02, 2020 at 09:22:33PM -0500, Samuel Holland wrote: > On 9/2/20 1:10 PM, Jernej =C5=A0krabec wrote: > > Hi Samuel! > >=20 > > Dne petek, 10. julij 2020 ob 07:44:51 CEST je Samuel Holland napisal(a): > >> On 7/4/20 6:38 AM, Cl=C3=A9ment P=C3=A9ron wrote: > >>> From: Marcus Cooper > >>> > >>> Extend the functionality of the driver to include support of 20 and > >>> 24 bits per sample. > >>> > >>> Signed-off-by: Marcus Cooper > >>> Signed-off-by: Cl=C3=A9ment P=C3=A9ron > >>> --- > >>> > >>> sound/soc/sunxi/sun4i-i2s.c | 11 +++++++++-- > >>> 1 file changed, 9 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > >>> index f78167e152ce..bc7f9343bc7a 100644 > >>> --- a/sound/soc/sunxi/sun4i-i2s.c > >>> +++ b/sound/soc/sunxi/sun4i-i2s.c > >>> @@ -577,6 +577,9 @@ static int sun4i_i2s_hw_params(struct > >>> snd_pcm_substream *substream,>=20 > >>> case 16: > >>> width =3D DMA_SLAVE_BUSWIDTH_2_BYTES; > >>> break; > >>> > >>> + case 32: > >>> + width =3D DMA_SLAVE_BUSWIDTH_4_BYTES; > >>> + break; > >> > >> This breaks the sun4i variants, because sun4i_i2s_get_wss returns 4 fo= r a 32 > >> bit width, but it needs to return 3. > >=20 > > I'm not sure what has WSS with physical width and DMA? >=20 > This is the change where creating a S24_LE stream no longer fails with -E= INVAL. > So this is the change where userspace stops downsampling 24-bit audio sou= rces. > So this is the change where playback of 24-bit audio sources breaks, beca= use WSS > is programmed wrong. >=20 > >> As a side note, I wonder why we use the physical width (the spacing be= tween > >> samples in RAM) to drive the slot width. S24_LE takes up 4 bytes per s= ample > >> in RAM, which we need for DMA. But I don't see why we would want to > >> transmit the padding over the wire. I would expect it to be transmitte= d the > >> same as S24_3LE (which has no padding). It did not matter before, beca= use > >> the only supported format had no padding. > >=20 > > Allwinner DMA engines support only 1, 2, 4 and sometimes 8 bytes for bu= s=20 > > width, so if sample is 24 bits in size, we have no other way but to tra= nsmit=20 > > padding too. >=20 > I understand why we do 4 byte DMA from RAM <=3D> I2S FIFO; that was not my > question. I'm referring to the actual wire format (FIFO <=3D> PCM_DIN/DOU= T). The > sample is already truncated from 32 bits to 24 bits in the FIFO -- that's= what > TXIM and RXOM in FIFO_CTRL control. >=20 > If a sample is 24 bits wide, why would we send 32 BCLKs for every LRCK? I= would > expect the slot width to match the sample resolution by default. But yet = we have > this code in the driver: >=20 > unsigned int word_size =3D params_width(params); > unsigned int slot_width =3D params_physical_width(params); >=20 > I think slot_width should be the same as word_size, and I suggest changin= g it > before adding 20/24-bit support. Generally speaking, the slot width doesn't necessarily match the physical width. With TDM for example you may very well have slots larger than their samples. That being said, S24 is explicitly a format where you send a sample of 24 bits in a 32-bit word (in the lowest three bytes, little endian) See: https://elixir.bootlin.com/linux/v5.9-rc3/source/sound/core/pcm_misc.c#L75 https://mailman.alsa-project.org/pipermail/alsa-devel/2013-April/061073.html 24 bits of data over three bytes like you suggest is S24_3LE Maxime --hf5an3s4qg2ib7h7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX1Cd5wAKCRDj7w1vZxhR xQAeAP9vjuO9Y3b+CKzmLOQ15SsDQDnKlVOEAQ0bmzds+Gn3dgEAvPzB50hkYbu/ m3XNc7Nyk17Y4tBWmLWyuoQ8IodG1QM= =gvkH -----END PGP SIGNATURE----- --hf5an3s4qg2ib7h7-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B92CC433E7 for ; Thu, 3 Sep 2020 07:42:19 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C538C2071B for ; Thu, 3 Sep 2020 07:42:18 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="WWXIFBA3"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=cerno.tech header.i=@cerno.tech header.b="myWiETMl"; dkim=fail reason="signature verification failed" (2048-bit key) header.d=messagingengine.com header.i=@messagingengine.com header.b="t8qsS6P2" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C538C2071B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=cerno.tech Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type:Cc: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=JXi2z1axEMTbBrgwiFcD78MsCpAlL6OT8Z13faTeYLc=; b=WWXIFBA3vz5bImGJVKtKsjNL7 hI2swakBocLoWRT1scVOwJSG825BUx2L9fqk38I0jw8ksXbJNmUHjDuNVo9905p4xvO7UCcNpcGw9 y2ECewOIym1ORHbc3J8A89Ub4pnIGIf3gygOf1x1hmwOk/cmmhuIUx24wOxOZjWfQAcDCqxp3pLSm v7gWtbXyZSpp2Ld3sPk/CiAamH+Whn1ZGtnYvJlhdyI8w1BZCYHT9wPGXmWRbDirMLtQohuQJn3Qv 7S+7Led7xWF8SlIO4HwKpOC6nl6fasQvijIQAScsaCKowTeCxTDEzI718/LkCdnLRBeSzEjPDVhS8 xdtjuiZmQ==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kDjrI-0001nC-VK; Thu, 03 Sep 2020 07:40:37 +0000 Received: from wnew4-smtp.messagingengine.com ([64.147.123.18]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kDjrF-0001mf-Sf for linux-arm-kernel@lists.infradead.org; Thu, 03 Sep 2020 07:40:34 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id C890CB01; Thu, 3 Sep 2020 03:40:28 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Thu, 03 Sep 2020 03:40:29 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cerno.tech; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm3; bh=3d+fTLgpTQcvjVM12OzE052YfvZ PoumZnCP7vT0BNTc=; b=myWiETMlIlUWHiTv8WnuXR+IYKbfeY5RfHZzjkLV+Xw vOJYm7vw+zvumPkFdHPXWFtkzhTYSTTd0kc6GrkplI4ro5xwGlVFKwTKqL6jra1X ksTvu1GJCw0OMAelGSu1027OYyKQ3kBURhut6zWOaxQfFjr8GlcY8lBvxPNqzMtK OUGZeAYHEmTpCkcZhosndWdeEoOKeOFu53O8EXVO+Tr4dFCir9889Qe1u5Uvg/c1 TI26DKLLToqDDNovI8WA/o22S9QZub5mhlrJF27B32oa6Gf8IKWigG8fYNu7ORL0 u1CsM+fhrutvTxQq7l52RBAsbBGUHfPKY1jS0tXI8Kw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=3d+fTL gpTQcvjVM12OzE052YfvZPoumZnCP7vT0BNTc=; b=t8qsS6P2vWW1REZJvCGNSX pl+k4eLlBP1UE8HWUavDheeb/zxkwmSlFYeSGsvk2ur7ajehHxmyBh6HsxfT0MTi nFwP/PWOXjXKxj/z0XBSr1lbAUNYXhVRRRa0q9QKX/Ay1bndTmlUSrTr3Mv6tqRg tANMq//E+NVwezpXe9BybmRJ8g/ws8isYuYOH0xt9sc8aKKf6ZP6mxjQ/p/dT7f3 JoVGPXZUtrGj6moTYiCmcOLj35IsjjIxhqgapxa9SOIZe8iL9Zi8yI/cWnZWxJk0 HF/RZCc3Nm9WIzf1B2PXx2YlfVkXHDBDjDD6wIj0mWJgHPfs0s7pQlec9/TFcfUA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudegtddguddvfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkfhggtggujgesghdtreertddtjeenucfhrhhomhepofgrgihi mhgvucftihhprghrugcuoehmrgigihhmvgestggvrhhnohdrthgvtghhqeenucggtffrrg htthgvrhhnpeetledvveffgeeuheejtdegteekueetjeevgfeivefgieegkedtieelgeeh gfetheenucffohhmrghinhepsghoohhtlhhinhdrtghomhdprghlshgrqdhprhhojhgvtg htrdhorhhgnecukfhppeeltddrkeelrdeikedrjeeinecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhgrgihimhgvsegtvghrnhhordhtvggthh X-ME-Proxy: Received: from localhost (lfbn-tou-1-1502-76.w90-89.abo.wanadoo.fr [90.89.68.76]) by mail.messagingengine.com (Postfix) with ESMTPA id 6B68C328005D; Thu, 3 Sep 2020 03:40:24 -0400 (EDT) Date: Thu, 3 Sep 2020 09:40:23 +0200 From: Maxime Ripard To: Samuel Holland Subject: Re: [linux-sunxi] [PATCH 05/16] ASoc: sun4i-i2s: Add 20 and 24 bit support Message-ID: <20200903074023.jccqp45br3er4h3g@gilmour.lan> References: <20200704113902.336911-1-peron.clem@gmail.com> <20200704113902.336911-6-peron.clem@gmail.com> <1e320dfd-9388-54b2-dba9-7def0bf4bbad@sholland.org> <9148679.oVN3Z7rve9@kista> MIME-Version: 1.0 In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200903_034034_097560_FF013549 X-CRM114-Status: GOOD ( 31.12 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Jernej =?utf-8?Q?=C5=A0krabec?= , alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com, Takashi Iwai , Liam Girdwood , Rob Herring , Jaroslav Kysela , Marcus Cooper , Chen-Yu Tsai , Mark Brown , peron.clem@gmail.com, linux-arm-kernel@lists.infradead.org Content-Type: multipart/mixed; boundary="===============9032265330701593349==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============9032265330701593349== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="hf5an3s4qg2ib7h7" Content-Disposition: inline --hf5an3s4qg2ib7h7 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 02, 2020 at 09:22:33PM -0500, Samuel Holland wrote: > On 9/2/20 1:10 PM, Jernej =C5=A0krabec wrote: > > Hi Samuel! > >=20 > > Dne petek, 10. julij 2020 ob 07:44:51 CEST je Samuel Holland napisal(a): > >> On 7/4/20 6:38 AM, Cl=C3=A9ment P=C3=A9ron wrote: > >>> From: Marcus Cooper > >>> > >>> Extend the functionality of the driver to include support of 20 and > >>> 24 bits per sample. > >>> > >>> Signed-off-by: Marcus Cooper > >>> Signed-off-by: Cl=C3=A9ment P=C3=A9ron > >>> --- > >>> > >>> sound/soc/sunxi/sun4i-i2s.c | 11 +++++++++-- > >>> 1 file changed, 9 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > >>> index f78167e152ce..bc7f9343bc7a 100644 > >>> --- a/sound/soc/sunxi/sun4i-i2s.c > >>> +++ b/sound/soc/sunxi/sun4i-i2s.c > >>> @@ -577,6 +577,9 @@ static int sun4i_i2s_hw_params(struct > >>> snd_pcm_substream *substream,>=20 > >>> case 16: > >>> width =3D DMA_SLAVE_BUSWIDTH_2_BYTES; > >>> break; > >>> > >>> + case 32: > >>> + width =3D DMA_SLAVE_BUSWIDTH_4_BYTES; > >>> + break; > >> > >> This breaks the sun4i variants, because sun4i_i2s_get_wss returns 4 fo= r a 32 > >> bit width, but it needs to return 3. > >=20 > > I'm not sure what has WSS with physical width and DMA? >=20 > This is the change where creating a S24_LE stream no longer fails with -E= INVAL. > So this is the change where userspace stops downsampling 24-bit audio sou= rces. > So this is the change where playback of 24-bit audio sources breaks, beca= use WSS > is programmed wrong. >=20 > >> As a side note, I wonder why we use the physical width (the spacing be= tween > >> samples in RAM) to drive the slot width. S24_LE takes up 4 bytes per s= ample > >> in RAM, which we need for DMA. But I don't see why we would want to > >> transmit the padding over the wire. I would expect it to be transmitte= d the > >> same as S24_3LE (which has no padding). It did not matter before, beca= use > >> the only supported format had no padding. > >=20 > > Allwinner DMA engines support only 1, 2, 4 and sometimes 8 bytes for bu= s=20 > > width, so if sample is 24 bits in size, we have no other way but to tra= nsmit=20 > > padding too. >=20 > I understand why we do 4 byte DMA from RAM <=3D> I2S FIFO; that was not my > question. I'm referring to the actual wire format (FIFO <=3D> PCM_DIN/DOU= T). The > sample is already truncated from 32 bits to 24 bits in the FIFO -- that's= what > TXIM and RXOM in FIFO_CTRL control. >=20 > If a sample is 24 bits wide, why would we send 32 BCLKs for every LRCK? I= would > expect the slot width to match the sample resolution by default. But yet = we have > this code in the driver: >=20 > unsigned int word_size =3D params_width(params); > unsigned int slot_width =3D params_physical_width(params); >=20 > I think slot_width should be the same as word_size, and I suggest changin= g it > before adding 20/24-bit support. Generally speaking, the slot width doesn't necessarily match the physical width. With TDM for example you may very well have slots larger than their samples. That being said, S24 is explicitly a format where you send a sample of 24 bits in a 32-bit word (in the lowest three bytes, little endian) See: https://elixir.bootlin.com/linux/v5.9-rc3/source/sound/core/pcm_misc.c#L75 https://mailman.alsa-project.org/pipermail/alsa-devel/2013-April/061073.html 24 bits of data over three bytes like you suggest is S24_3LE Maxime --hf5an3s4qg2ib7h7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCX1Cd5wAKCRDj7w1vZxhR xQAeAP9vjuO9Y3b+CKzmLOQ15SsDQDnKlVOEAQ0bmzds+Gn3dgEAvPzB50hkYbu/ m3XNc7Nyk17Y4tBWmLWyuoQ8IodG1QM= =gvkH -----END PGP SIGNATURE----- --hf5an3s4qg2ib7h7-- --===============9032265330701593349== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============9032265330701593349==--