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=-12.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,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 9ED0EC282CE for ; Tue, 4 Jun 2019 09:47:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6D3F82499B for ; Tue, 4 Jun 2019 09:47:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727107AbfFDJrt (ORCPT ); Tue, 4 Jun 2019 05:47:49 -0400 Received: from web2.default.djames.uk0.bigv.io ([213.138.101.246]:45110 "EHLO web2.default.djames.uk0.bigv.io" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726982AbfFDJrt (ORCPT ); Tue, 4 Jun 2019 05:47:49 -0400 X-Greylist: delayed 2689 seconds by postgrey-1.27 at vger.kernel.org; Tue, 04 Jun 2019 05:47:47 EDT Received: from mail-it1-f173.google.com ([209.85.166.173]) by web2.default.djames.uk0.bigv.io with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hY5LM-00007b-49 for linux-kernel@vger.kernel.org; Tue, 04 Jun 2019 10:02:56 +0100 Received: by mail-it1-f173.google.com with SMTP id r135so34257ith.1 for ; Tue, 04 Jun 2019 02:02:56 -0700 (PDT) X-Gm-Message-State: APjAAAWXMNQUzcAnnJ7AsAqOVCBcAeNhqk032uH6tZuiX4yzZrEExTNe cL5LcUToStFdEaZnPCEf8YI96l3TWuZiYA5wS/s= X-Google-Smtp-Source: APXvYqy5fOqmW1LpJnYMNhUIlz6rmDEGpblhX6WaThh9eDcSVUboO20xGeWQwLkQRBSt8dunKGmdzQEmWj26Bi7ROz8= X-Received: by 2002:a02:a493:: with SMTP id d19mr16646745jam.22.1559638974496; Tue, 04 Jun 2019 02:02:54 -0700 (PDT) MIME-Version: 1.0 References: <20190603174735.21002-1-codekipper@gmail.com> <20190603174735.21002-7-codekipper@gmail.com> <20190604075840.kquy3zcuckuzmvzr@flea> In-Reply-To: From: Christopher Obbard Date: Tue, 4 Jun 2019 10:02:59 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [linux-sunxi] Re: [PATCH v4 6/9] ASoC: sun4i-i2s: Add multi-lane functionality To: Code Kipper Cc: Maxime Ripard , Chen-Yu Tsai , linux-sunxi , linux-arm-kernel , Liam Girdwood , Mark Brown , linux-kernel , Linux-ALSA , "Andrea Venturi (pers)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 4 Jun 2019 at 09:43, Code Kipper wrote: > > On Tue, 4 Jun 2019 at 09:58, Maxime Ripard wrote: > > > > On Mon, Jun 03, 2019 at 07:47:32PM +0200, codekipper@gmail.com wrote: > > > 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 > > > > I'd like to have Mark's input on this, but I'm really worried about > > the interaction with the proper TDM support. > > > > Our fundamental issue is that the controller can have up to 8 > > channels, but either on 4 lines (instead of 1), or 8 channels on 1 > > (like proper TDM) (or any combination between the two, but that should > > be pretty rare). > > I understand...maybe the TDM needs to be extended to support this to consider > channel mapping and multiple transfer lines. I was thinking about the later when > someone was requesting support on IIRC a while ago, I thought masking might > of been a solution. These can wait as the only consumer at the moment is > LibreELEC and we can patch it there. Hi Marcus, FWIW, the TI McASP driver has support for TDM & (i think?) multiple transfer lines which are called serializers. Maybe this can help with inspiration? see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/ti/davinci-mcasp.c sample DTS: &mcasp0 { #sound-dai-cells = <0>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&mcasp0_pins>; op-mode = <0>; tdm-slots = <8>; serial-dir = < 2 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 >; tx-num-evt = <1>; rx-num-evt = <1>; }; Cheers! > Do you have any ideas Master? > CK > > > > You're trying to do the first one, and I'm trying to do the second one. > > > > There's a number of assumptions later on that will break the TDM case, > > see below for examples > > > > > --- > > > sound/soc/sunxi/sun4i-i2s.c | 44 ++++++++++++++++++++++++++++++++----- > > > 1 file changed, 39 insertions(+), 5 deletions(-) > > > > > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > > > index bca73b3c0d74..75217fb52bfa 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) > > > @@ -355,14 +355,23 @@ 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) { > > > + if ((channels > dai->driver->playback.channels_max) || > > > + (channels < dai->driver->playback.channels_min)) { > > > dev_err(dai->dev, "Unsupported number of channels: %d\n", > > > channels); > > > 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)); > > > + > > > > This has the assumption that each line will have 2 channels, which is wrong. > > > > > if (i2s->variant->is_h3_i2s_based) { > > > regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > > > SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK, > > > @@ -373,8 +382,19 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream, > > > } > > > > > > /* Map the channels for playback and capture */ > > > - regmap_field_write(i2s->field_txchanmap, 0x76543210); > > > regmap_field_write(i2s->field_rxchanmap, 0x00003210); > > > + regmap_field_write(i2s->field_txchanmap, 0x10); > > > + if (i2s->variant->is_h3_i2s_based) { > > > + if (channels > 2) > > > + regmap_write(i2s->regmap, > > > + SUN8I_I2S_TX_CHAN_MAP_REG+4, 0x32); > > > + if (channels > 4) > > > + regmap_write(i2s->regmap, > > > + SUN8I_I2S_TX_CHAN_MAP_REG+8, 0x54); > > > + if (channels > 6) > > > + regmap_write(i2s->regmap, > > > + SUN8I_I2S_TX_CHAN_MAP_REG+12, 0x76); > > > + } > > > > And this creates a mapping matching that. > > > > > /* Configure the channels */ > > > regmap_field_write(i2s->field_txchansel, > > > @@ -1057,9 +1077,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) > > > @@ -1126,6 +1147,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; > > > + } > > > + > > > > I'm not quite sure how this works. > > > > of_property_read_u32 will return 0, so you will enter in the > > condition. But what happens if the property is missing? > > > > Maxime > > > > -- > > Maxime Ripard, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com > > -- > You received this message because you are subscribed to the Google Groups "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com. > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAEKpxB%3DRdYF9eEvAJ%2BR7sT6OtdtBWjhMM1am%2BEhaN%3D9ZO9Gd2A%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Obbard Subject: Re: Re: [PATCH v4 6/9] ASoC: sun4i-i2s: Add multi-lane functionality Date: Tue, 4 Jun 2019 10:02:59 +0100 Message-ID: References: <20190603174735.21002-1-codekipper@gmail.com> <20190603174735.21002-7-codekipper@gmail.com> <20190604075840.kquy3zcuckuzmvzr@flea> Reply-To: chris-ljUBoSVpJTpWk0Htik3J/w@public.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Sender: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org In-Reply-To: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , To: Code Kipper Cc: Maxime Ripard , Chen-Yu Tsai , linux-sunxi , linux-arm-kernel , Liam Girdwood , Mark Brown , linux-kernel , Linux-ALSA , "Andrea Venturi (pers)" List-Id: alsa-devel@alsa-project.org On Tue, 4 Jun 2019 at 09:43, Code Kipper wrote: > > On Tue, 4 Jun 2019 at 09:58, Maxime Ripard wrote: > > > > On Mon, Jun 03, 2019 at 07:47:32PM +0200, codekipper-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote: > > > 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 > > > > I'd like to have Mark's input on this, but I'm really worried about > > the interaction with the proper TDM support. > > > > Our fundamental issue is that the controller can have up to 8 > > channels, but either on 4 lines (instead of 1), or 8 channels on 1 > > (like proper TDM) (or any combination between the two, but that should > > be pretty rare). > > I understand...maybe the TDM needs to be extended to support this to consider > channel mapping and multiple transfer lines. I was thinking about the later when > someone was requesting support on IIRC a while ago, I thought masking might > of been a solution. These can wait as the only consumer at the moment is > LibreELEC and we can patch it there. Hi Marcus, FWIW, the TI McASP driver has support for TDM & (i think?) multiple transfer lines which are called serializers. Maybe this can help with inspiration? see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/ti/davinci-mcasp.c sample DTS: &mcasp0 { #sound-dai-cells = <0>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&mcasp0_pins>; op-mode = <0>; tdm-slots = <8>; serial-dir = < 2 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 >; tx-num-evt = <1>; rx-num-evt = <1>; }; Cheers! > Do you have any ideas Master? > CK > > > > You're trying to do the first one, and I'm trying to do the second one. > > > > There's a number of assumptions later on that will break the TDM case, > > see below for examples > > > > > --- > > > sound/soc/sunxi/sun4i-i2s.c | 44 ++++++++++++++++++++++++++++++++----- > > > 1 file changed, 39 insertions(+), 5 deletions(-) > > > > > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > > > index bca73b3c0d74..75217fb52bfa 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) > > > @@ -355,14 +355,23 @@ 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) { > > > + if ((channels > dai->driver->playback.channels_max) || > > > + (channels < dai->driver->playback.channels_min)) { > > > dev_err(dai->dev, "Unsupported number of channels: %d\n", > > > channels); > > > 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)); > > > + > > > > This has the assumption that each line will have 2 channels, which is wrong. > > > > > if (i2s->variant->is_h3_i2s_based) { > > > regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > > > SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK, > > > @@ -373,8 +382,19 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream, > > > } > > > > > > /* Map the channels for playback and capture */ > > > - regmap_field_write(i2s->field_txchanmap, 0x76543210); > > > regmap_field_write(i2s->field_rxchanmap, 0x00003210); > > > + regmap_field_write(i2s->field_txchanmap, 0x10); > > > + if (i2s->variant->is_h3_i2s_based) { > > > + if (channels > 2) > > > + regmap_write(i2s->regmap, > > > + SUN8I_I2S_TX_CHAN_MAP_REG+4, 0x32); > > > + if (channels > 4) > > > + regmap_write(i2s->regmap, > > > + SUN8I_I2S_TX_CHAN_MAP_REG+8, 0x54); > > > + if (channels > 6) > > > + regmap_write(i2s->regmap, > > > + SUN8I_I2S_TX_CHAN_MAP_REG+12, 0x76); > > > + } > > > > And this creates a mapping matching that. > > > > > /* Configure the channels */ > > > regmap_field_write(i2s->field_txchansel, > > > @@ -1057,9 +1077,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) > > > @@ -1126,6 +1147,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; > > > + } > > > + > > > > I'm not quite sure how this works. > > > > of_property_read_u32 will return 0, so you will enter in the > > condition. But what happens if the property is missing? > > > > Maxime > > > > -- > > Maxime Ripard, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com > > -- > You received this message because you are subscribed to the Google Groups "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAEKpxB%3DRdYF9eEvAJ%2BR7sT6OtdtBWjhMM1am%2BEhaN%3D9ZO9Gd2A%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. 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=-12.0 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,T_DKIMWL_WL_HIGH, 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 6ED35C282CE for ; Tue, 4 Jun 2019 09:03:11 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 4437F249E3 for ; Tue, 4 Jun 2019 09:03:11 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nI9/asSY" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4437F249E3 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=64studio.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-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=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=3rqnBnvefdFa5zy3eWk+novo67hG7e69JDWDET0pmyE=; b=nI9/asSY2Mrdcq Ka/ymtatoR2vonlD/lC8LhCZYPFt+dVIPiv0xnX8PJrp0rp5Ryj4GT+zipzq6JXBC966TsMdPQXNv YhxsuUnFZPMn6GZK0SitiM86iJKIyaEbvSPjYxsaWWfMdNz3zoraz72NKyRFptFnTt9ZaPHc3MqyS ZVfEKwlgKJqI3rKwbuIzFNhVyPv2D0soNrX9Gxo6lo343SxIWUxfuwbma/mFKALUoIJvR4YXuCEuk 0yVmSxAHamn/j9wRqWUEWfEoXkcI5Idawbna2TktEPWJmEmWAU+vDHSpIHwiSd9rtvve/bQzVBZ92 WfZQTJL/HrB91lvWfeKg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.90_1 #2 (Red Hat Linux)) id 1hY5LX-0001nU-GB; Tue, 04 Jun 2019 09:03:07 +0000 Received: from web2.default.djames.uk0.bigv.io ([2001:41c8:51:1f6::246]) by bombadil.infradead.org with esmtps (Exim 4.90_1 #2 (Red Hat Linux)) id 1hY5LT-0001lk-RY for linux-arm-kernel@lists.infradead.org; Tue, 04 Jun 2019 09:03:06 +0000 Received: from mail-it1-f174.google.com ([209.85.166.174]) by web2.default.djames.uk0.bigv.io with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hY5LM-00007h-6H for linux-arm-kernel@lists.infradead.org; Tue, 04 Jun 2019 10:02:56 +0100 Received: by mail-it1-f174.google.com with SMTP id j204so25792669ite.4 for ; Tue, 04 Jun 2019 02:02:56 -0700 (PDT) X-Gm-Message-State: APjAAAVtPvYQ4416aGpUGF8evBD0WHlYxXF4nQyixjwWry731r+fvj/J 4TFa6K12Csl8t72rPLFtpR0tok1HWtymQVB/1X8= X-Google-Smtp-Source: APXvYqy5fOqmW1LpJnYMNhUIlz6rmDEGpblhX6WaThh9eDcSVUboO20xGeWQwLkQRBSt8dunKGmdzQEmWj26Bi7ROz8= X-Received: by 2002:a02:a493:: with SMTP id d19mr16646745jam.22.1559638974496; Tue, 04 Jun 2019 02:02:54 -0700 (PDT) MIME-Version: 1.0 References: <20190603174735.21002-1-codekipper@gmail.com> <20190603174735.21002-7-codekipper@gmail.com> <20190604075840.kquy3zcuckuzmvzr@flea> In-Reply-To: From: Christopher Obbard Date: Tue, 4 Jun 2019 10:02:59 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [linux-sunxi] Re: [PATCH v4 6/9] ASoC: sun4i-i2s: Add multi-lane functionality To: Code Kipper X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190604_020304_051200_0F51489C X-CRM114-Status: GOOD ( 40.44 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Linux-ALSA , Maxime Ripard , linux-kernel , linux-sunxi , Liam Girdwood , "Andrea Venturi \(pers\)" , Chen-Yu Tsai , Mark Brown , linux-arm-kernel Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Tue, 4 Jun 2019 at 09:43, Code Kipper wrote: > > On Tue, 4 Jun 2019 at 09:58, Maxime Ripard wrote: > > > > On Mon, Jun 03, 2019 at 07:47:32PM +0200, codekipper@gmail.com wrote: > > > 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 > > > > I'd like to have Mark's input on this, but I'm really worried about > > the interaction with the proper TDM support. > > > > Our fundamental issue is that the controller can have up to 8 > > channels, but either on 4 lines (instead of 1), or 8 channels on 1 > > (like proper TDM) (or any combination between the two, but that should > > be pretty rare). > > I understand...maybe the TDM needs to be extended to support this to consider > channel mapping and multiple transfer lines. I was thinking about the later when > someone was requesting support on IIRC a while ago, I thought masking might > of been a solution. These can wait as the only consumer at the moment is > LibreELEC and we can patch it there. Hi Marcus, FWIW, the TI McASP driver has support for TDM & (i think?) multiple transfer lines which are called serializers. Maybe this can help with inspiration? see https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/sound/soc/ti/davinci-mcasp.c sample DTS: &mcasp0 { #sound-dai-cells = <0>; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&mcasp0_pins>; op-mode = <0>; tdm-slots = <8>; serial-dir = < 2 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 >; tx-num-evt = <1>; rx-num-evt = <1>; }; Cheers! > Do you have any ideas Master? > CK > > > > You're trying to do the first one, and I'm trying to do the second one. > > > > There's a number of assumptions later on that will break the TDM case, > > see below for examples > > > > > --- > > > sound/soc/sunxi/sun4i-i2s.c | 44 ++++++++++++++++++++++++++++++++----- > > > 1 file changed, 39 insertions(+), 5 deletions(-) > > > > > > diff --git a/sound/soc/sunxi/sun4i-i2s.c b/sound/soc/sunxi/sun4i-i2s.c > > > index bca73b3c0d74..75217fb52bfa 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) > > > @@ -355,14 +355,23 @@ 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) { > > > + if ((channels > dai->driver->playback.channels_max) || > > > + (channels < dai->driver->playback.channels_min)) { > > > dev_err(dai->dev, "Unsupported number of channels: %d\n", > > > channels); > > > 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)); > > > + > > > > This has the assumption that each line will have 2 channels, which is wrong. > > > > > if (i2s->variant->is_h3_i2s_based) { > > > regmap_update_bits(i2s->regmap, SUN8I_I2S_CHAN_CFG_REG, > > > SUN8I_I2S_CHAN_CFG_TX_SLOT_NUM_MASK, > > > @@ -373,8 +382,19 @@ static int sun4i_i2s_hw_params(struct snd_pcm_substream *substream, > > > } > > > > > > /* Map the channels for playback and capture */ > > > - regmap_field_write(i2s->field_txchanmap, 0x76543210); > > > regmap_field_write(i2s->field_rxchanmap, 0x00003210); > > > + regmap_field_write(i2s->field_txchanmap, 0x10); > > > + if (i2s->variant->is_h3_i2s_based) { > > > + if (channels > 2) > > > + regmap_write(i2s->regmap, > > > + SUN8I_I2S_TX_CHAN_MAP_REG+4, 0x32); > > > + if (channels > 4) > > > + regmap_write(i2s->regmap, > > > + SUN8I_I2S_TX_CHAN_MAP_REG+8, 0x54); > > > + if (channels > 6) > > > + regmap_write(i2s->regmap, > > > + SUN8I_I2S_TX_CHAN_MAP_REG+12, 0x76); > > > + } > > > > And this creates a mapping matching that. > > > > > /* Configure the channels */ > > > regmap_field_write(i2s->field_txchansel, > > > @@ -1057,9 +1077,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) > > > @@ -1126,6 +1147,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; > > > + } > > > + > > > > I'm not quite sure how this works. > > > > of_property_read_u32 will return 0, so you will enter in the > > condition. But what happens if the property is missing? > > > > Maxime > > > > -- > > Maxime Ripard, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com > > -- > You received this message because you are subscribed to the Google Groups "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com. > To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAEKpxB%3DRdYF9eEvAJ%2BR7sT6OtdtBWjhMM1am%2BEhaN%3D9ZO9Gd2A%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel