Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp513240ybl; Wed, 14 Aug 2019 01:28:30 -0700 (PDT) X-Google-Smtp-Source: APXvYqzNIDV0G6e+EWoOOpTdNTlrCsGzKV/7HA+S5HtqcbfNeGyeNH3VWOVndRoa3BBYhLlvs4YL X-Received: by 2002:a17:902:2ae7:: with SMTP id j94mr41509237plb.270.1565771310247; Wed, 14 Aug 2019 01:28:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565771310; cv=none; d=google.com; s=arc-20160816; b=eO7Yxy62/5Kom/5cykyPgAtmwdH0LLWdxFSw/1spWqgkMqQFZ4KmNfwh04CPgRpj3a UAICRXH5iQgnIMTVtB0vHDvUAs8CV7ldPj15WBjEjMZ40f7W7LUB7Sai2fPVuWGSxWLR xH2w0lkTzi9ej09NwpKRFcYYg1GJcO9vA2qi7CdO+T3dOoyaFlg0htYKdRK/HC222t32 F5fV9GZc0JRF1VPZeTMZB9uVPaPFhaFi8W58ppKKR/ezAeZQHBz3J+vaJwTBD74eFj+/ WCWpHLfdwlmMVkFQObXlBbVFJ8rOPJnSX5krdJ4KD0jC4cZjz6ggjkW94IxZpYOOQrWD uQzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=3gE5kEXYFGYp1NL5CVXFOoRMz6qJmDaHUxtSZp9tvPo=; b=Ne6pAo+9ih4+bruJwnjUppKAbINaKH5oXrW9e/+br49xAf2G6dZcgOJaB9vKLnyY78 y802pJXs1ktnUjz0QLcgq3N2OqI+SWRZimqC5J5AlnbYNKjdNHdIKvq44oKOIRGq5sB0 speSjwmvlE6oVzpHS5wHqFPmgHP19oprNH29sBCCOY8DfgZhUBSocA9ms8anRzgXNmQ1 Y/61aXuD2wy2MZSOphL+O0GY/Ot9g2EBber8MRidlJabQKo5qPWo2BAWMq6yJ0CvqFEt qtzIMZlp9hlCabT1CCRK+k2sThaSBkuZU+42swllvjNmFL7X8/tB1iuuRUOXd82o8Wx0 XzBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XFpfp1W3; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j4si17410148pfi.34.2019.08.14.01.28.14; Wed, 14 Aug 2019 01:28:30 -0700 (PDT) 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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XFpfp1W3; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726803AbfHNI1c (ORCPT + 99 others); Wed, 14 Aug 2019 04:27:32 -0400 Received: from mail-wm1-f68.google.com ([209.85.128.68]:39091 "EHLO mail-wm1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725280AbfHNI1c (ORCPT ); Wed, 14 Aug 2019 04:27:32 -0400 Received: by mail-wm1-f68.google.com with SMTP id i63so3654366wmg.4 for ; Wed, 14 Aug 2019 01:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=3gE5kEXYFGYp1NL5CVXFOoRMz6qJmDaHUxtSZp9tvPo=; b=XFpfp1W3puWa/3htoMflxHKUuAj7OYdt2KBmq8Qvkhz1yRx5mUcc9kKoRC7hcl+kw2 Swg5Ybcs6f153Zr3/5NCmVnCmeMvhgvJBZj9+M6S0jK95Ci5q6VSCqHBe8hwkKvHTwOk ZEWIOWEN/+ENTAwjEPMmLLYvJv5tcpaVFqzMunbAImN5LndqSbQfw82Q91TqeOsYqPMo GaSraPnht5Tk6e8yoWUPi1sOVbSw6DeNqgnQMe/sPZlqY60bbE8qf37lciaeNuPZM7ju 3AmLP+MxhPVpsrhnLA7eqrrNanxkqQeEMYJn6e/8Fh/QujCfmNy8deCvfNV/JzRR1AHv 8SRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=3gE5kEXYFGYp1NL5CVXFOoRMz6qJmDaHUxtSZp9tvPo=; b=d6OBhNKlHOHgybKDrnBvcaVTlr0o8+5oGC33evr32aoIZhkcNCkYKfaa3lXRbG4WK5 THfSJcCDtfnRqYP0BAibYaU5hZmBrZaQ7W2cuzw6eI2xnGjeh5kKn9nNf8XXX5nNo3gN viuW0Lfzd9UDm6G18w4g4g5Orbqv2miQDrfa2WqUmcOxyQxAEPAPmL8pQyAKItuGIggw oS+hIo3gy6sFvms122e6uYxQpuASSUgfX/9fCfwSVkZZ6ZkixvOL64lObUhcR3jbJ070 oDKMHFBphyh9wqLJgsGFQUqZ9vDIB5SMSxjTHbvhoWe11Kp7yaQMp17H6Rpn+ZLQmdNx W6qQ== X-Gm-Message-State: APjAAAV5qeRolMcIcOUuiijf+y7Gvf+q6YV4Ki71Aoe39b6pjYPQlofl jjDUjpQOEyQzW6RsxkLqEcs= X-Received: by 2002:a1c:ed09:: with SMTP id l9mr7274205wmh.58.1565771249331; Wed, 14 Aug 2019 01:27:29 -0700 (PDT) Received: from jernej-laptop.localnet (89-212-178-211.dynamic.t-2.net. [89.212.178.211]) by smtp.gmail.com with ESMTPSA id c15sm65833981wrb.80.2019.08.14.01.27.27 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Wed, 14 Aug 2019 01:27:27 -0700 (PDT) From: Jernej =?utf-8?B?xaBrcmFiZWM=?= To: linux-sunxi@googlegroups.com, codekipper@gmail.com Cc: maxime.ripard@free-electrons.com, wens@csie.org, linux-arm-kernel@lists.infradead.org, lgirdwood@gmail.com, broonie@kernel.org, linux-kernel@vger.kernel.org, alsa-devel@alsa-project.org, be17068@iperbole.bo.it Subject: Re: [linux-sunxi] [PATCH v5 12/15] ASoC: sun4i-i2s: Add multi-lane functionality Date: Wed, 14 Aug 2019 10:27:26 +0200 Message-ID: <3526410.lk6A0UfGIS@jernej-laptop> In-Reply-To: <20190814060854.26345-13-codekipper@gmail.com> References: <20190814060854.26345-1-codekipper@gmail.com> <20190814060854.26345-13-codekipper@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi! Dne sreda, 14. avgust 2019 ob 08:08:51 CEST je codekipper@gmail.com napisal(a): > From: Marcus Cooper > > The i2s block supports multi-lane i2s output however this functionality > is only possible in earlier SoCs where the pins are exposed and for > the i2s block used for HDMI audio on the later SoCs. > > To enable this functionality, an optional property has been added to > the bindings. > > Signed-off-by: Marcus Cooper > --- > sound/soc/sunxi/sun4i-i2s.c | 28 +++++++++++++++++++++++++--- > 1 file changed, 25 insertions(+), 3 deletions(-) > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > index a8d98696fe7c..a020c3b372a8 100644 > --- a/sound/soc/sunxi/sun4i-i2s.c > +++ b/sound/soc/sunxi/sun4i-i2s.c > @@ -23,7 +23,7 @@ > > #define SUN4I_I2S_CTRL_REG 0x00 > #define SUN4I_I2S_CTRL_SDO_EN_MASK GENMASK(11, 8) > -#define SUN4I_I2S_CTRL_SDO_EN(sdo) BIT(8 + (sdo)) > +#define SUN4I_I2S_CTRL_SDO_EN(lines) (((1 << lines) - 1) << 8) > #define SUN4I_I2S_CTRL_MODE_MASK BIT(5) > #define SUN4I_I2S_CTRL_MODE_SLAVE (1 << 5) > #define SUN4I_I2S_CTRL_MODE_MASTER (0 << 5) > @@ -614,6 +614,7 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream > *substream, struct sun4i_i2s *i2s = snd_soc_dai_get_drvdata(dai); > int sr, wss, channels; > u32 width; > + int lines; > > channels = params_channels(params); > if (channels != 2) { > @@ -622,6 +623,13 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream > *substream, return -EINVAL; > } > > + lines = (channels + 1) / 2; > + > + /* Enable the required output lines */ > + regmap_update_bits(i2s->regmap, SUN4I_I2S_CTRL_REG, > + SUN4I_I2S_CTRL_SDO_EN_MASK, > + SUN4I_I2S_CTRL_SDO_EN(lines)); As Maxime said before, this doesn't work for TDM. Maybe we can skip this for now, until we agree on method how to describe channel allocation? > + > if (i2s->variant->has_chcfg) { > regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK, > @@ -1389,9 +1397,10 @@ static int sun4i_i2s_init_regmap_fields(struct device > *dev, static int sun4i_i2s_probe(struct platform_device *pdev) > { > struct sun4i_i2s *i2s; > + struct snd_soc_dai_driver *soc_dai; > struct resource *res; > void __iomem *regs; > - int irq, ret; > + int irq, ret, val; > > i2s = devm_kzalloc(&pdev->dev, sizeof(*i2s), GFP_KERNEL); > if (!i2s) > @@ -1456,6 +1465,19 @@ static int sun4i_i2s_probe(struct platform_device > *pdev) i2s->capture_dma_data.addr = res->start + SUN4I_I2S_FIFO_RX_REG; > i2s->capture_dma_data.maxburst = 8; > > + soc_dai = devm_kmemdup(&pdev->dev, &sun4i_i2s_dai, > + sizeof(*soc_dai), GFP_KERNEL); > + if (!soc_dai) { > + ret = -ENOMEM; > + goto err_pm_disable; > + } > + > + if (!of_property_read_u32(pdev->dev.of_node, > + "allwinner,playback-channels", &val)) { > + if (val >= 2 && val <= 8) > + soc_dai->playback.channels_max = val; > + } > + Rather than inventing new DT properties, I would rather have multiple snd_soc_dai_driver structures, depending on capabilities of that particular I2S block. That way we avoid some boilerplate code as can be seen here and it's IMO more transparent. In this case, I would make another snd_soc_dai_driver struct for H3, which has channel_max property set to 8 and from patch 14, additional supported formats. Best regards, Jernej > pm_runtime_enable(&pdev->dev); > if (!pm_runtime_enabled(&pdev->dev)) { > ret = sun4i_i2s_runtime_resume(&pdev->dev); > @@ -1465,7 +1487,7 @@ static int sun4i_i2s_probe(struct platform_device > *pdev) > > ret = devm_snd_soc_register_component(&pdev->dev, > &sun4i_i2s_component, > - &sun4i_i2s_dai, 1); > + soc_dai, 1); > if (ret) { > dev_err(&pdev->dev, "Could not register DAI\n"); > goto err_suspend;