Received: by 10.223.176.5 with SMTP id f5csp2606520wra; Mon, 29 Jan 2018 00:41:53 -0800 (PST) X-Google-Smtp-Source: AH8x225IbziCO8ffJAiISzfnk6Tv/4w97meelg9OJnhFpMXVkHAngj784qX6hA9yJcPTFBNaIr3Y X-Received: by 10.99.65.134 with SMTP id o128mr12381154pga.323.1517215313539; Mon, 29 Jan 2018 00:41:53 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517215313; cv=none; d=google.com; s=arc-20160816; b=rwBf36g96ZA7FrEhzzRrKtbxn1HBw+afNzTVJi4UcXT8Y5sheOsu4bQhh8HGSyZl1B e8r1b+lGWrBbuXZl+b30EmSPZPILNMVNpy8TIu/IQaTKThe0S8yHYRvzuPVNOKkJcoGn oEjDHpMeLYDO14WizkVUxDKS3xy1rdTwBjb8405FJ3KuU6G+AT/duTIZ7/YXPTRi/B8H cbOJdFqZYa+q6GobIpDkgLtDsgJAOSyh0ugItXm9ecQC2o43OYoCznlopNl7kVcD8Kx1 RIw4r2E3b/UBdV++nOpATOZLkKyvVxja1iDptYDxIWcni84MIrNhWttwfFaB8U4JsADl p9PQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=jiKdddFNuxBmpC7vfEPm2IXjUccsngc91D9BseimH5E=; b=y+1lPm042xXXFhWD38jKAhrTMb+SgNPU6421Vdvbl1RBb/1eG4NO2QGkf9ldYzEQaf cwvGv4HcmFl4TQf3YXuSnSPNp9Axb8XxNxI6fqXv0riiYJW8Tw8d4TQi4LqLRzbwca1Z 4zMX58ZJfUCGRW2ejRtA0i/qv/K3+UYTA9bydKK2H24UdPx/wTxkyENlT16IidgIdRFe t2y+eOzYr116SfLoUyTkTXfBa1oyFQ24czrx0KU+4pzoHhf+uZccnZQUzA00tgUrsXb3 a2qzcT4ZwDe6is8jIUg8YekOwJBRQwp5/7O8eoCgOmrhfMQAt33lqouilK3EAKcZ8qzl RD/Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f5-v6si1019928plj.274.2018.01.29.00.41.16; Mon, 29 Jan 2018 00:41:53 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751496AbeA2Ikv (ORCPT + 99 others); Mon, 29 Jan 2018 03:40:51 -0500 Received: from mail.free-electrons.com ([62.4.15.54]:56325 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751127AbeA2Iku (ORCPT ); Mon, 29 Jan 2018 03:40:50 -0500 Received: by mail.free-electrons.com (Postfix, from userid 110) id 5CEF421989; Mon, 29 Jan 2018 09:40:49 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.free-electrons.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from localhost (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.free-electrons.com (Postfix) with ESMTPSA id 2A7E921988; Mon, 29 Jan 2018 09:40:39 +0100 (CET) Date: Mon, 29 Jan 2018 09:40:39 +0100 From: Maxime Ripard To: Chen-Yu Tsai Cc: Code Kipper , linux-arm-kernel , linux-sunxi , Liam Girdwood , Mark Brown , linux-kernel , Linux-ALSA , "Andrea Venturi (pers)" Subject: Re: [linux-sunxi] [PATCH 1/3] ASoC: sun4i-i2s: Add set_tdm_slot functionality Message-ID: <20180129084039.bysenf2y72hqbajq@flea.lan> References: <20180124141101.12867-1-codekipper@gmail.com> <20180124141101.12867-2-codekipper@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="55uq6xzd4dh6xbnq" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --55uq6xzd4dh6xbnq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 29, 2018 at 03:38:40PM +0800, Chen-Yu Tsai wrote: > On Mon, Jan 29, 2018 at 3:34 PM, Code Kipper wrote: > > On 29 January 2018 at 02:50, Chen-Yu Tsai wrote: > >> On Wed, Jan 24, 2018 at 10:10 PM, wrote: > >>> From: Marcus Cooper > >>> > >>> Some codecs require a different amount of a bit clocks per frame than > >>> what is calculated by the sample width. Use the tdm slot bindings to > >>> provide this mechanism. > >>> > >>> Signed-off-by: Marcus Cooper > >>> --- > >>> sound/soc/sunxi/sun4i-i2s.c | 23 +++++++++++++++++++++-- > >>> 1 file changed, 21 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > >>> index dca1143c1150..d7a9141514cf 100644 > >>> --- a/sound/soc/sunxi/sun4i-i2s.c > >>> +++ b/sound/soc/sunxi/sun4i-i2s.c > >>> @@ -96,6 +96,7 @@ > >>> #define SUN8I_I2S_CTRL_BCLK_OUT BIT(18) > >>> #define SUN8I_I2S_CTRL_LRCK_OUT BIT(17) > >>> > >>> +#define SUN8I_I2S_FMT0_LRCK_MAX_PERIOD (GENMASK(17, 8) >> 8) > >>> #define SUN8I_I2S_FMT0_LRCK_PERIOD_MASK GENMASK(17, 8) > >>> #define SUN8I_I2S_FMT0_LRCK_PERIOD(period) ((period - 1) << 8) > >>> > >>> @@ -193,6 +194,9 @@ struct sun4i_i2s { > >>> struct regmap_field *field_rxchansel; > >>> > >>> const struct sun4i_i2s_quirks *variant; > >>> + > >>> + unsigned int tdm_slots; > >>> + unsigned int slot_width; > >>> }; > >>> > >>> struct sun4i_i2s_clk_div { > >>> @@ -344,7 +348,7 @@ static int sun4i_i2s_set_clk_rate(struct snd_soc_= dai *dai, > >>> if (i2s->variant->has_fmt_set_lrck_period) > >>> regmap_update_bits(i2s->regmap, SUN4I_I2S_FMT0_REG, > >>> SUN8I_I2S_FMT0_LRCK_PERIOD_MASK, > >>> - SUN8I_I2S_FMT0_LRCK_PERIOD(32)); > >>> + SUN8I_I2S_FMT0_LRCK_PERIOD(word_si= ze)); > >>> > >>> return 0; > >>> } > >>> @@ -418,7 +422,8 @@ static int sun4i_i2s_hw_params(struct snd_pcm_sub= stream *substream, > >>> sr + i2s->variant->fmt_offset); > >>> > >>> return sun4i_i2s_set_clk_rate(dai, params_rate(params), > >>> - params_width(params)); > >>> + i2s->tdm_slots ? > >>> + i2s->slot_width : params_width(= params)); > >>> } > >>> > >>> static int sun4i_i2s_set_fmt(struct snd_soc_dai *dai, unsigned int f= mt) > >>> @@ -691,6 +696,19 @@ static int sun4i_i2s_set_sysclk(struct snd_soc_d= ai *dai, int clk_id, > >>> return 0; > >>> } > >>> > >>> +static int sun4i_i2s_set_dai_tdm_slot(struct snd_soc_dai *dai, > >>> + unsigned int tx_mask, unsigned int rx_mask, > >>> + int slots, int width) > >>> +{ > >>> + struct sun4i_i2s *i2s =3D snd_soc_dai_get_drvdata(dai); > >>> + > >>> + i2s->tdm_slots =3D slots; > >>> + > >>> + i2s->slot_width =3D width; > >>> + > >>> + return 0; > >>> +} > >>> + > >> > >> IIRC some of the DAI controllers actually support TDM. Would this > >> change conflict with that in the future? > > > > Hi Wens, > > I'm not sure..I was looking for a clean example of being able to > > override the number of bclks in the lrclk width and some other > > devices(Rpi) were doing it this way. I open to suggestions, >=20 > I'm not familiar with the issue either. If Mark doesn't have any > objections, we could merge it for now, and fix it later if there > are any complications. >=20 > BTW, you didn't provide a device tree example (if any) for how > to use this. Could it be that it's just not i2s but some other format? Maxime --=20 Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com --55uq6xzd4dh6xbnq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEE0VqZU19dR2zEVaqr0rTAlCFNr3QFAlpu3gYACgkQ0rTAlCFN r3R7kxAAjG9SzIPMrmN5HTS5inlMgzH2qjvCg5P+7FkA0XhFkX3b4W6rWlwjdU02 kgl9U6sG/VCcnFbJpjFztKxPWa3xa1XTOY6hnB6WYSVTO/QtgJ12jPjXzJUNsbsm ocsTRGpMPFr1kipReUtELW+wAmk2Q2kTkk4dQ4/4noSTDzbGCKD0K4hHURWKMP2y eCbL9nkKZuukLRtd5xr2PEGhAfmLseOvt6r7U9bQNmYxOysxqqfbf5pgw/sS0zrV jOjGk8doVAhi69MJOvYYOiDRC2Z1lUxPU1pLY6G3rgPTwfDGEfXOx2PiZF2ZToyy Evh6NDHryst/9FWTauJGDQNnKJnGXJbKIt8SH0j3eAiEPhT+ctCm8XAFwpG2GgGN 2p3ESmho7bUScerLnhA/HVHpuRQ2Bzr6J0KdiLWY4QHqz81vyHyp/1SEghETI5IS 4bchmGne8/7kmIA2Gsih8zCFuhgvvPBjCPg1CV/IxT1Xc/YYjtRnD/zGNLrkviXn HSBoEpJ1Rx0+nMK1sDHuNdXe9s8sE6wm90Nl+fDfPFAwet8lRuCqDHdwmHJ+qr8n 5PXQXChN1cxxIjcSrR/IMnsxzf8F5aDQe9tcqa9BQaIt+vHrnxse1acc2sjOIzTS Lx7O6FUc6YcLH/rAmYNw6Ly5HROXt5EfBv98ybIH8Gs5h8L1T2w= =85hs -----END PGP SIGNATURE----- --55uq6xzd4dh6xbnq--