Message ID | 1695780376-32301-1-git-send-email-cy_huang@richtek.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:cae8:0:b0:403:3b70:6f57 with SMTP id r8csp2415118vqu; Tue, 26 Sep 2023 23:07:03 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFhUAtY1Ree4ubFlnj/cZRtIcZQSrCf97KQetTJkAnM16Ln3Jvc4WKnEyOpO2l81HDbzDrw X-Received: by 2002:a17:902:d50c:b0:1c7:2661:91e8 with SMTP id b12-20020a170902d50c00b001c7266191e8mr543642plg.54.1695794823530; Tue, 26 Sep 2023 23:07:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1695794823; cv=none; d=google.com; s=arc-20160816; b=s8gSjoW1x4eubxngAAivbAl9gpuVmqm5VfdwnjlgoHZJUisKCMXHO487fs2P3yArwK +p+CWHrxzrMjFqsofsIk5vdFIJiSlSuc2tJFc4/xxA/O2OgCx7Wn5gWzOu0XOM+C6ETI R3tLpaCLomrhIap+rAQMQ4uTQlI1oBDsFtdekYbKug/JLbxyqFBHfDfTDkIYdQXKeSdw udINDCsRHsgN1vON2++XvxV3XINF4gNmJaeqN62V/XrVH/SfzUIukr/mYsVDv8vHBcB4 72AqgXOU7rPGD9zXeDWgIk4VuTWRqYNo7fWD/3OFt/qenNSTk0UQrpXOO68XSmClW/mi cYWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:subject:cc:to:from; bh=HfZYve466Sodl91t17fXmp8O60gtaik3ZdFLVw1t8Ec=; fh=YBycZUdArxaom4gbPo+SknHAvKMMnZmnmMopxOSpYT4=; b=ME7czqc6U0thGbOux2wzJdgbR09TdfDyOGx0aE5woZXdKxtFUYq5w4QyYoJxWKzWw/ MVzV2jWbtgqtGt9G3j+MPfl8B+CjWU8xpl2lN7nyCS536WzsjSkBoIHqGd2+8RtQhMeM 4ZfskvnfL8/VBqn3Sjzl7RT5hWLfO3hzyFze+sR4fGKV5GE5I8T7sFDXmXx+wq8KyKte i5oNjgeo0qLyTr8ACRXXVqbgKVIphDfJGJi4lXWTN/mUb1/xHZqdETqLoduGx0cbysH8 iI84wgFYXXAmgY7RzFUJJGH41Z/ciItGe0wC6Foz/z8UxxSzHLJ7bCIxL0Y03vYYAmHx HC+w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id ay6-20020a1709028b8600b001b025aba9f2si13777167plb.22.2023.09.26.23.07.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 26 Sep 2023 23:07:03 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id C8B018106879; Tue, 26 Sep 2023 22:45:40 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229768AbjI0FpZ (ORCPT <rfc822;pwkd43@gmail.com> + 25 others); Wed, 27 Sep 2023 01:45:25 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60118 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229732AbjI0Foy (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 27 Sep 2023 01:44:54 -0400 Received: from mg.richtek.com (mg.richtek.com [220.130.44.152]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id CE99A5FD7 for <linux-kernel@vger.kernel.org>; Tue, 26 Sep 2023 19:07:00 -0700 (PDT) X-MailGates: (SIP:2,PASS,NONE)(compute_score:DELIVER,40,3) Received: from 192.168.10.46 by mg.richtek.com with MailGates ESMTPS Server V6.0(1978105:0:AUTH_RELAY) (envelope-from <cy_huang@richtek.com>) (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256/256); Wed, 27 Sep 2023 10:06:17 +0800 (CST) Received: from ex4.rt.l (192.168.10.47) by ex3.rt.l (192.168.10.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.25; Wed, 27 Sep 2023 10:06:17 +0800 Received: from linuxcarl2.richtek.com (192.168.10.154) by ex4.rt.l (192.168.10.45) with Microsoft SMTP Server id 15.2.1118.25 via Frontend Transport; Wed, 27 Sep 2023 10:06:17 +0800 From: <cy_huang@richtek.com> To: Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com> CC: ChiYuan Huang <cy_huang@richtek.com>, Allen Lin <allen_lin@richtek.com>, <alsa-devel@alsa-project.org>, <linux-kernel@vger.kernel.org> Subject: [PATCH] ASoC: codecs: rtq9128: Add TDM data source selection Date: Wed, 27 Sep 2023 10:06:16 +0800 Message-ID: <1695780376-32301-1-git-send-email-cy_huang@richtek.com> X-Mailer: git-send-email 1.8.3.1 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Tue, 26 Sep 2023 22:45:40 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778169752994419395 X-GMAIL-MSGID: 1778169752994419395 |
Series |
ASoC: codecs: rtq9128: Add TDM data source selection
|
|
Commit Message
ChiYuan Huang
Sept. 27, 2023, 2:06 a.m. UTC
From: ChiYuan Huang <cy_huang@richtek.com> Since rtq9128 can support 4 channel I2S mode audio data, there are two dedicated data input pins for CH12 and CH34. But in TDM mode, input source was already drived on one data pin for multiple data slots. In this case, only one input source is needed for TDM mode. This patch is to add the data source pin selection for CH12 and CH34. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> --- sound/soc/codecs/rtq9128.c | 9 +++++++++ 1 file changed, 9 insertions(+) base-commit: c351835058419c1eb8791941a057c3f3e6068cb6
Comments
On Wed, Sep 27, 2023 at 10:06:16AM +0800, cy_huang@richtek.com wrote: > Since rtq9128 can support 4 channel I2S mode audio data, there are two > dedicated data input pins for CH12 and CH34. But in TDM mode, input > source was already drived on one data pin for multiple data slots. In > this case, only one input source is needed for TDM mode. > > This patch is to add the data source pin selection for CH12 and CH34. > + SOC_ENUM("CH12 TDM Data Select", rtq9128_ch12_tdm_data_select_enum), > + SOC_ENUM("CH34 TDM Data Select", rtq9128_ch34_tdm_data_select_enum), Is this something that's going to be changing dynamically at runtime or should this be a device property that's set either by firmware or when we're doing the TDM setup? This sounds like something I'd expect to be fixed by the board design.
On Wed, Sep 27, 2023 at 11:13:22AM +0200, Mark Brown wrote: > On Wed, Sep 27, 2023 at 10:06:16AM +0800, cy_huang@richtek.com wrote: > > > Since rtq9128 can support 4 channel I2S mode audio data, there are two > > dedicated data input pins for CH12 and CH34. But in TDM mode, input > > source was already drived on one data pin for multiple data slots. In > > this case, only one input source is needed for TDM mode. > > > > This patch is to add the data source pin selection for CH12 and CH34. > > > + SOC_ENUM("CH12 TDM Data Select", rtq9128_ch12_tdm_data_select_enum), > > + SOC_ENUM("CH34 TDM Data Select", rtq9128_ch34_tdm_data_select_enum), > > Is this something that's going to be changing dynamically at runtime or > should this be a device property that's set either by firmware or when > we're doing the TDM setup? This sounds like something I'd expect to be > fixed by the board design. I may think one case if ASoC platform support multiple data source outputs that share the same bck/lcrk on different data pin. If it can be dynamically adjusted for the scenarios, this will keep the flexibility for the differet platform design. Like as in most codecs, there could be mux design that can use to choose the dedicated data input. If we fixed in device property, the flexibility will be missing. It's our original thought to have the control for the data select mutiplexer.
On Wed, Sep 27, 2023 at 05:46:37PM +0800, ChiYuan Huang wrote: > On Wed, Sep 27, 2023 at 11:13:22AM +0200, Mark Brown wrote: > > Is this something that's going to be changing dynamically at runtime or > > should this be a device property that's set either by firmware or when > > we're doing the TDM setup? This sounds like something I'd expect to be > > fixed by the board design. > I may think one case if ASoC platform support multiple data source outputs > that share the same bck/lcrk on different data pin. If it can be dynamically > adjusted for the scenarios, this will keep the flexibility for the differet > platform design. Sure, but is that actually a practical design - or if someone is doing this shouldn't it be joined up with the TDM configuration since with just the control it'd only be possible to switch the pins but not change the TDM layout? I'm not sure that this control works as a standalone thing.
On Wed, Sep 27, 2023 at 11:59:31AM +0200, Mark Brown wrote: > On Wed, Sep 27, 2023 at 05:46:37PM +0800, ChiYuan Huang wrote: > > On Wed, Sep 27, 2023 at 11:13:22AM +0200, Mark Brown wrote: > > > > Is this something that's going to be changing dynamically at runtime or > > > should this be a device property that's set either by firmware or when > > > we're doing the TDM setup? This sounds like something I'd expect to be > > > fixed by the board design. > > > I may think one case if ASoC platform support multiple data source outputs > > that share the same bck/lcrk on different data pin. If it can be dynamically > > adjusted for the scenarios, this will keep the flexibility for the differet > > platform design. > > Sure, but is that actually a practical design - or if someone is doing > this shouldn't it be joined up with the TDM configuration since with > just the control it'd only be possible to switch the pins but not change > the TDM layout? I'm not sure that this control works as a standalone > thing. I think if two data source input for different scenarios, then the data source switch will become practical. For the standalone usage, keep a device property to decide this may be enough. But consider the future application, to keep this in general mixer control is still usable to meet the complex design.
On Wed, Sep 27, 2023 at 06:19:48PM +0800, ChiYuan Huang wrote: > On Wed, Sep 27, 2023 at 11:59:31AM +0200, Mark Brown wrote: > > Sure, but is that actually a practical design - or if someone is doing > > this shouldn't it be joined up with the TDM configuration since with > > just the control it'd only be possible to switch the pins but not change > > the TDM layout? I'm not sure that this control works as a standalone > > thing. > I think if two data source input for different scenarios, then the data source > switch will become practical. For the standalone usage, keep a device property > to decide this may be enough. But consider the future application, to keep this > in general mixer control is still usable to meet the complex design. My concern is that the control might not actually be usable without also changing the TDM mode so we might need the machine driver to add a control which flips the input and also changes the TDM mode - it feels likley that if there are two inputs they won't have identical formats.
On Wed, Sep 27, 2023 at 12:28:29PM +0200, Mark Brown wrote: > On Wed, Sep 27, 2023 at 06:19:48PM +0800, ChiYuan Huang wrote: > > On Wed, Sep 27, 2023 at 11:59:31AM +0200, Mark Brown wrote: > > > > Sure, but is that actually a practical design - or if someone is doing > > > this shouldn't it be joined up with the TDM configuration since with > > > just the control it'd only be possible to switch the pins but not change > > > the TDM layout? I'm not sure that this control works as a standalone > > > thing. > > > I think if two data source input for different scenarios, then the data source > > switch will become practical. For the standalone usage, keep a device property > > to decide this may be enough. But consider the future application, to keep this > > in general mixer control is still usable to meet the complex design. > > My concern is that the control might not actually be usable without also > changing the TDM mode so we might need the machine driver to add a > control which flips the input and also changes the TDM mode - it feels > likley that if there are two inputs they won't have identical formats. Yap, your concern may be correct. This change is really becuase our default register is badly defined. it choose TDM CH12 from 'DATA1' and CH34 from 'DATA2'. If it can choose both default to either one, this doesn't make it confused. Also, there's the another option is 'to tell user if TDM will be used, plase connect 'DATA1' and 'DATA2' together'. But our datasheet did not directly define this. I'll prepare another patch to define a device property, parsing at probe function and configure this input source source directly in 'set_tdm_slot' API when TDM is chosen to use. Thanks for all the comment.
diff --git a/sound/soc/codecs/rtq9128.c b/sound/soc/codecs/rtq9128.c index 926b79ed8078..3cf613c6900e 100644 --- a/sound/soc/codecs/rtq9128.c +++ b/sound/soc/codecs/rtq9128.c @@ -225,6 +225,7 @@ static const char * const phase_select_text[] = { "180 degree", "225 degree", "270 degree", "315 degree", }; static const char * const dvdduv_select_text[] = { "1P4V", "1P5V", "2P1V", "2P3V" }; +static const char * const tdm_data_select_text[] = { "DATA1", "DATA2" }; static const struct soc_enum rtq9128_ch1_si_enum = SOC_ENUM_SINGLE(RTQ9128_REG_SDI_SEL, 6, ARRAY_SIZE(source_select_text), source_select_text); @@ -246,6 +247,12 @@ static const struct soc_enum rtq9128_out3_phase_enum = static const struct soc_enum rtq9128_out4_phase_enum = SOC_ENUM_SINGLE(RTQ9128_REG_PLLTRI_GEN2, 0, ARRAY_SIZE(phase_select_text), phase_select_text); +static const struct soc_enum rtq9128_ch12_tdm_data_select_enum = + SOC_ENUM_SINGLE(RTQ9128_REG_SDO_SEL, 5, ARRAY_SIZE(tdm_data_select_text), + tdm_data_select_text); +static const struct soc_enum rtq9128_ch34_tdm_data_select_enum = + SOC_ENUM_SINGLE(RTQ9128_REG_SDO_SEL, 4, ARRAY_SIZE(tdm_data_select_text), + tdm_data_select_text); /* * In general usage, DVDD could be 1P8V, 3P0V or 3P3V. @@ -277,6 +284,8 @@ static const struct snd_kcontrol_new rtq9128_snd_ctrls[] = { SOC_ENUM("OUT3 Phase Select", rtq9128_out3_phase_enum), SOC_ENUM("OUT4 Phase Select", rtq9128_out4_phase_enum), SOC_ENUM("DVDD UV Threshold Select", rtq9128_dvdduv_select_enum), + SOC_ENUM("CH12 TDM Data Select", rtq9128_ch12_tdm_data_select_enum), + SOC_ENUM("CH34 TDM Data Select", rtq9128_ch34_tdm_data_select_enum), }; static int rtq9128_dac_power_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *kcontrol,