Message ID | 20230621115328.156457-1-fido_max@inbox.ru |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp4303785vqr; Wed, 21 Jun 2023 04:57:22 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ4HcVDyBhrXU7qc4PpPPgWxmwSOCnl3Q0ZtM0JcXIbvd2IO86d3t/ayJu98Ka9sjx25b9pY X-Received: by 2002:a17:90a:4e08:b0:25b:da7f:9a53 with SMTP id n8-20020a17090a4e0800b0025bda7f9a53mr11181974pjh.26.1687348642303; Wed, 21 Jun 2023 04:57:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1687348642; cv=none; d=google.com; s=arc-20160816; b=Dft7+cUaEP4LzrX2ch+Hu5TWwiy40rHDcSrpYSQgZylcUQwG0s8Xz+nWvJkzEkKKCk 0bFNDopuo1i88pYevsfPrAuUVIw/gzj9uLBQHYl07N0o6mUI9tQKmrKMUlScrUzS7poW J7BdYLlUuYTeORGq/w4Gq64J1v/SsmtbSgR51Ldc4EM4XZmgVsipa2cgTG9fjOw/gyJ2 kU3cBMg2yDSjgbWrWwnZB3r4n8j3bSflUVoTEPOPPRnTovWxw1W9CBt2Rt/kl6Tao7Ai RLuGYefbAz73pi1ee6F9Dc5UW66lW9/1VbRuhY/Giv6cWJui0jlmCackyWJzoBeVi048 d7DQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature:dkim-signature; bh=Dt0Pfw4hhB64UidxR15sPo8nXNsoSpkcj1h2rZuo8hk=; b=GiE0nuLayZIae1mhE2YI3un5wF5rFbThfJMLBTitN/lv4sTIvZUdRWhH9P8PBPj10Y RQyMGTxNkaksCFfs8RqGDZgMSLgR8JHBIczi7F3T31qAFvi3v5Pf3Pk+rLSqw4++nE+b FbzpS/0mLEwdNI9X/NZJMjTJ7nUOyoJGt8Wp5UiZAXG36zglU4kAkyThvoVkKiRcTe3v 0ny8Id4qMyCMrdVtmKZZsG5cJY9iuezKN3TDBQcGl/Y+v16ostNWHeeUvLgdaVJXfK0p HJQxNkR0uDgZwHvqcwtjzyss/XycGQGH27pIDDmPZcate/Kh7e0nAvzfCYQOT8Ut6e6D tD+w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@inbox.ru header.s=mail4 header.b=ErmyDf9e; dkim=pass header.i=@inbox.ru header.s=mail4 header.b=EhqWlY9U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=inbox.ru Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g12-20020a17090a4b0c00b00255d819b632si3961946pjh.43.2023.06.21.04.56.43; Wed, 21 Jun 2023 04:57:22 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@inbox.ru header.s=mail4 header.b=ErmyDf9e; dkim=pass header.i=@inbox.ru header.s=mail4 header.b=EhqWlY9U; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=inbox.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230506AbjFULyA (ORCPT <rfc822;maxin.john@gmail.com> + 99 others); Wed, 21 Jun 2023 07:54:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59978 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230471AbjFULx6 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 21 Jun 2023 07:53:58 -0400 Received: from fallback1.i.mail.ru (fallback1.i.mail.ru [79.137.243.67]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2057C170A for <linux-kernel@vger.kernel.org>; Wed, 21 Jun 2023 04:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail4; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:Cc:To:From:From:Subject:Content-Type:Content-Transfer-Encoding:To:Cc; bh=Dt0Pfw4hhB64UidxR15sPo8nXNsoSpkcj1h2rZuo8hk=; t=1687348436;x=1687438436; b=ErmyDf9eSzTcVcbMKX2BxI7Eg4KGVatBaGgTdUySgH+tR3ZnXuoHTQ52yq39PT5kmLUO4X5Rqu3uu+l4EydxOgiIKwh16CS3uD/MNIfb7fYgZ6p0bRtVMVSfXiGF+fCf/5jDPpKuqUWRkm0sHUFHB+1Zp5shO3gj6nUQi2Y4hzyqkF8ZYm1vv7cj7DHohY3ESPiVrAjCrHEegpNE93NcKG8o9Am/jH3C1/QWYpXI+zdIa9D4lwV5l+RyMyWYb7c1hAZ2LrjKQw01rTgglMn7+e4KjY3CfsBleaXwwIy7mtUNHZB0XN2GleZdgtV+zuttRtNqTMRFzxhPJ6KE+0mnpQ==; Received: from [10.161.55.49] (port=42924 helo=smtpng1.i.mail.ru) by fallback1.i.mail.ru with esmtp (envelope-from <fido_max@inbox.ru>) id 1qBwPK-00FkSl-0R for linux-kernel@vger.kernel.org; Wed, 21 Jun 2023 14:53:54 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=inbox.ru; s=mail4; h=Content-Transfer-Encoding:MIME-Version:Message-Id:Date:Subject:Cc:To:From:From:Subject:Content-Type:Content-Transfer-Encoding:To:Cc; bh=Dt0Pfw4hhB64UidxR15sPo8nXNsoSpkcj1h2rZuo8hk=; t=1687348434;x=1687438434; b=EhqWlY9UNZPMaYAxaQuA3mpXBqDCSotzyYyYC4ZLQPKnBs9ZH3x4r3Ct60kYm22CfSTx6rjGH97IuGShbwcpoaOWmwBDMzr0Ouj6JoTRj49zl3D5ye1RAEYY/B0xok1iEKzozmbCG1UhYUkMnF6d6whJyj/7QevgCNcu0eGAkkYF8gRkRzHTiqZpkt7cuKrz26wYR7/sMv6/4NYU6yx5tEbg2dnl0/Szc4sbpmlaf33qy5VCYn1K3Ao0DSCbGNzR4ciY77CQVwmTxFrRxLRCoOmjpaEkiUo4xd2Y46iiAHEX5Snb/suCCyyhtALVeAAzHnqXmi7Edo9ZyQEHlPwiHQ==; Received: by smtpng1.m.smailru.net with esmtpa (envelope-from <fido_max@inbox.ru>) id 1qBwP5-0000gW-SZ; Wed, 21 Jun 2023 14:53:40 +0300 From: Maxim Kochetkov <fido_max@inbox.ru> To: alsa-devel@alsa-project.org Cc: Maxim Kochetkov <fido_max@inbox.ru>, Liam Girdwood <lgirdwood@gmail.com>, Mark Brown <broonie@kernel.org>, Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>, Benjamin Mugnier <benjamin.mugnier@foss.st.com>, Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, =?utf-8?q?Uwe_Kleine-K?= =?utf-8?q?=C3=B6nig?= <u.kleine-koenig@pengutronix.de>, Claudiu Beznea <claudiu.beznea@microchip.com>, Charles Keepax <ckeepax@opensource.cirrus.com>, linux-kernel@vger.kernel.org Subject: [PATCH 1/1] ASoC: codecs: max98090: Allow dsp_a mode Date: Wed, 21 Jun 2023 14:53:27 +0300 Message-Id: <20230621115328.156457-1-fido_max@inbox.ru> X-Mailer: git-send-email 2.40.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailru-Src: smtp X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD95D99986233CC4DDC4468B86CD3C8787546E8D189E2EBE9EA182A05F53808504070B069C72436E1D2D5A4E71BD025E4125047B1DA41A3FADE443584DC68319CB8 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7A140E7B1D51EB231EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006374D0D183F14C070BA8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D83712544A9697989658D127D5918B20866F9789CCF6C18C3F8528715B7D10C86859CC434672EE6371117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC3A703B70628EAD7BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F4460429728776938767073520C24E1E72F37C03A0CB629EEF1311BF91D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B67393CE827C55B5F775ECD9A6C639B01B4E70A05D1297E1BBCB5012B2E24CD356 X-C1DE0DAB: 0D63561A33F958A53ED0F0D15519928FD04AAF18DCFED2499590945C3EDE3FF3F87CCE6106E1FC07E67D4AC08A07B9B0A6C7FFFE744CA7FB9C5DF10A05D560A950611B66E3DA6D700B0A020F03D25A0997E3FB2386030E77 X-C8649E89: 1C3962B70DF3F0ADE00A9FD3E00BEEDF77DD89D51EBB7742D3581295AF09D3DF87807E0823442EA2ED31085941D9CD0AF7F820E7B07EA4CF874C60ACDD5FE242F57F3AD3431D0F7AB6867A931EA55A5E929DFB5A80A42D569B332213384B5353C17492877F82D9B86CE4D2ACC560A8F38AAD56CD3798406E04DA52CF61C1B8024C41F94D744909CEE921556F0E976A29E6EC0772259F8F8F8815B87D7EC76CB9 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojw7uTMtz3/lzKbCaM7tQQkw== X-Mailru-Sender: 689FA8AB762F73930F533AC2B33E986B42AF639ED9E053B675404323CF2E7D5998CC072019C18A892CA7F8C7C9492E1F2F5E575105D0B01ADBE2EF17B331888EEAB4BC95F72C04283CDA0F3B3F5B9367 X-Mras: Ok X-7564579A: 646B95376F6C166E X-77F55803: 6242723A09DB00B4E9028C5D3AAACA54E8DC16345F01FC93132BCC4B5F627A4CB647ED114AB003ACB18A032C91B96DF475D01A0B191F359A97BF0508C385DA8C9D94EE637B74D14D X-7FA49CB5: 0D63561A33F958A594549CC4FF3B142D6E5D536DC6E77C76452CA37571F42238CACD7DF95DA8FC8BD5E8D9A59859A8B67EB76A845F84D5F3 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5xhPKz0ZEsZ5k6NOOPWz5QAiZSCXKGQRq3/7KxbCLSB2ESzQkaOXqCBFZPLWFrEGlV1shfWe2EVcxl5toh0c/aCGOghz/frdRhzMe95NxDFdGZgddNfoakPLJDztWF3qfQ== X-Mailru-MI: C000000000000800 X-Mras: Ok X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,T_SCC_BODY_TEXT_LINE, URIBL_BLOCKED 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-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1769313289813643377?= X-GMAIL-MSGID: =?utf-8?q?1769313289813643377?= |
Series |
[1/1] ASoC: codecs: max98090: Allow dsp_a mode
|
|
Commit Message
Maxim Kochetkov
June 21, 2023, 11:53 a.m. UTC
TDM mode for max98090 is dsp_a compatible. So allow it.
Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru>
---
sound/soc/codecs/max98090.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Wed, Jun 21, 2023 at 02:53:27PM +0300, Maxim Kochetkov wrote: > TDM mode for max98090 is dsp_a compatible. So allow it. > case SND_SOC_DAIFMT_DSP_A: > - /* Not supported mode */ > + break; This is configuring DSP A identically to left justified mode, it looks like the format configuration needs at least some interlock with the TDM configuration.
On 21.06.2023 15:26, Mark Brown wrote: > On Wed, Jun 21, 2023 at 02:53:27PM +0300, Maxim Kochetkov wrote: > >> TDM mode for max98090 is dsp_a compatible. So allow it. > >> case SND_SOC_DAIFMT_DSP_A: >> - /* Not supported mode */ >> + break; > > This is configuring DSP A identically to left justified mode, it looks > like the format configuration needs at least some interlock with the TDM > configuration. According to datasheet MAX98090 supports only DSP_A (L data MSB after FRM LRC) TDM mode. Allowing this mode will let us proper configure CPU audio node via DT. Actual TDM mode activation is performed in max98090_set_tdm_slot() via M98090_REG_TDM_FORMAT/M98090_REG_TDM_CONTROL registers.
On Wed, Jun 21, 2023 at 04:02:34PM +0300, Maxim Kochetkov wrote: > On 21.06.2023 15:26, Mark Brown wrote: > > This is configuring DSP A identically to left justified mode, it looks > > like the format configuration needs at least some interlock with the TDM > > configuration. > According to datasheet MAX98090 supports only DSP_A (L data MSB after FRM > LRC) TDM mode. Allowing this mode will let us proper configure CPU audio > node via DT. Actual TDM mode activation is performed in > max98090_set_tdm_slot() via M98090_REG_TDM_FORMAT/M98090_REG_TDM_CONTROL > registers. I'm saying there should be some interlock between these two settings, if nothing else setting DSP A mode should force TDM mode with automatically configured slot sizes.
On 21.06.2023 16:18, Mark Brown wrote: > On Wed, Jun 21, 2023 at 04:02:34PM +0300, Maxim Kochetkov wrote: >> On 21.06.2023 15:26, Mark Brown wrote: > >>> This is configuring DSP A identically to left justified mode, it looks >>> like the format configuration needs at least some interlock with the TDM >>> configuration. > >> According to datasheet MAX98090 supports only DSP_A (L data MSB after FRM >> LRC) TDM mode. Allowing this mode will let us proper configure CPU audio >> node via DT. Actual TDM mode activation is performed in >> max98090_set_tdm_slot() via M98090_REG_TDM_FORMAT/M98090_REG_TDM_CONTROL >> registers. > > I'm saying there should be some interlock between these two settings, if > nothing else setting DSP A mode should force TDM mode with automatically > configured slot sizes. At this time there is no any interlock for TDM mode in MAX98090 driver. We can specify dai-tdm-slot-* properties in DT and .set_tdm_slot() will be called to setup TDM mode. And SND_SOC_DAIFMT cannot affect it. I checked other codecs drivers: most of them performs TDM setup this way. So why do we need such interlock right now?
On Wed, Jun 21, 2023 at 04:55:18PM +0300, Maxim Kochetkov wrote: > On 21.06.2023 16:18, Mark Brown wrote: > > I'm saying there should be some interlock between these two settings, if > > nothing else setting DSP A mode should force TDM mode with automatically > > configured slot sizes. > At this time there is no any interlock for TDM mode in MAX98090 driver. We Yes, that's the problem I am identifying. The driver allows TDM mode to be configured independently of the DAI format but the two are related. > can specify dai-tdm-slot-* properties in DT and .set_tdm_slot() will be > called to setup TDM mode. And SND_SOC_DAIFMT cannot affect it. I checked > other codecs drivers: most of them performs TDM setup this way. So why do we > need such interlock right now? A lot of devices support TDM modes with other DAI formats, or allow the mode that is required for TDM to be configured even without doing TDM setup. Some always configure TDM like I'm suggesting, with the explicit TDM configuration just being an override. Some are just buggy and nobody noticed. The issue is that the driver will claim to have configured DSP A mode but actually done something else unless the user also configures TDM.
On 21.06.2023 17:01, Mark Brown wrote: > On Wed, Jun 21, 2023 at 04:55:18PM +0300, Maxim Kochetkov wrote: >> On 21.06.2023 16:18, Mark Brown wrote: > >>> I'm saying there should be some interlock between these two settings, if >>> nothing else setting DSP A mode should force TDM mode with automatically >>> configured slot sizes. > >> At this time there is no any interlock for TDM mode in MAX98090 driver. We > > Yes, that's the problem I am identifying. The driver allows TDM mode to > be configured independently of the DAI format but the two are related. But DSP_A mode is just bit/frame format. It is just compatible with TDM. > >> can specify dai-tdm-slot-* properties in DT and .set_tdm_slot() will be >> called to setup TDM mode. And SND_SOC_DAIFMT cannot affect it. I checked >> other codecs drivers: most of them performs TDM setup this way. So why do we >> need such interlock right now? > > A lot of devices support TDM modes with other DAI formats, or allow the > mode that is required for TDM to be configured even without doing TDM > setup. Some always configure TDM like I'm suggesting, with the explicit > TDM configuration just being an override. Some are just buggy and > nobody noticed. The issue is that the driver will claim to have > configured DSP A mode but actually done something else unless the user > also configures TDM. Yep. But we have to specify TDM parameters (slot masks, slot width, etc) any way. Because there is no default TDM configuration like I2S and so. And pure DSP_A/B mode just have no sense. Anyway. What do you suggest? Should I perform some refactoring for the driver? Should I move M98090_REG_TDM_FORMAT/M98090_REG_TDM_CONTROL registers setup to the max98090_dai_set_fmt()?
On Wed, Jun 21, 2023 at 05:28:41PM +0300, Maxim Kochetkov wrote: > Yep. But we have to specify TDM parameters (slot masks, slot width, etc) any > way. Because there is no default TDM configuration like I2S and so. And pure > DSP_A/B mode just have no sense. No, they make perfect sense and are widely supported - the sample size is chosen based on the hwparams instead of being forced by configuring TDM mode. > Anyway. What do you suggest? Should I perform some refactoring for the > driver? Should I move M98090_REG_TDM_FORMAT/M98090_REG_TDM_CONTROL registers > setup to the max98090_dai_set_fmt()? To repeat: > > > I'm saying there should be some interlock between these two settings, if > > > nothing else setting DSP A mode should force TDM mode with automatically > > > configured slot sizes.
On 21.06.2023 17:35, Mark Brown wrote: > To repeat: > >>>> I'm saying there should be some interlock between these two settings, if >>>> nothing else setting DSP A mode should force TDM mode with automatically >>>> configured slot sizes. Ok. How about that: --- sound/soc/codecs/max98090.c | 52 ++++++++++++++++++++----------------- sound/soc/codecs/max98090.h | 2 ++ 2 files changed, 30 insertions(+), 24 deletions(-) diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index 142083b13ac3..c30305269514 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -1582,7 +1582,7 @@ static int max98090_dai_set_fmt(struct snd_soc_dai *codec_dai, struct snd_soc_component *component = codec_dai->component; struct max98090_priv *max98090 = snd_soc_component_get_drvdata(component); struct max98090_cdata *cdata; - u8 regval; + u8 regval, tdm_regval; max98090->dai_fmt = fmt; cdata = &max98090->dai[0]; @@ -1591,6 +1591,7 @@ static int max98090_dai_set_fmt(struct snd_soc_dai *codec_dai, cdata->fmt = fmt; regval = 0; + tdm_regval = 0; switch (fmt & SND_SOC_DAIFMT_CLOCK_PROVIDER_MASK) { case SND_SOC_DAIFMT_CBC_CFC: /* Set to consumer mode PLL - MAS mode off */ @@ -1636,7 +1637,8 @@ static int max98090_dai_set_fmt(struct snd_soc_dai *codec_dai, regval |= M98090_RJ_MASK; break; case SND_SOC_DAIFMT_DSP_A: - /* Not supported mode */ + tdm_regval |= M98090_TDM_MASK; + break; default: dev_err(component->dev, "DAI format unsupported"); return -EINVAL; @@ -1665,11 +1667,20 @@ static int max98090_dai_set_fmt(struct snd_soc_dai *codec_dai, * seen for the case of TDM mode. The remaining cases have * normal logic. */ - if (max98090->tdm_slots > 1) + if (tdm_regval) regval ^= M98090_BCI_MASK; snd_soc_component_write(component, M98090_REG_INTERFACE_FORMAT, regval); + + regval = 0; + if (tdm_regval) + regval = max98090->tdm_lslot << M98090_TDM_SLOTL_SHIFT | + max98090->tdm_rslot << M98090_TDM_SLOTR_SHIFT | + 0 << M98090_TDM_SLOTDLY_SHIFT; + + snd_soc_component_write(component, M98090_REG_TDM_FORMAT, regval); + snd_soc_component_write(component, M98090_REG_TDM_CONTROL, tdm_regval); } return 0; @@ -1680,33 +1691,23 @@ static int max98090_set_tdm_slot(struct snd_soc_dai *codec_dai, { struct snd_soc_component *component = codec_dai->component; struct max98090_priv *max98090 = snd_soc_component_get_drvdata(component); - struct max98090_cdata *cdata; - cdata = &max98090->dai[0]; if (slots < 0 || slots > 4) return -EINVAL; - max98090->tdm_slots = slots; - max98090->tdm_width = slot_width; + if (slot_width != 16) + return -EINVAL; - if (max98090->tdm_slots > 1) { - /* SLOTL SLOTR SLOTDLY */ - snd_soc_component_write(component, M98090_REG_TDM_FORMAT, - 0 << M98090_TDM_SLOTL_SHIFT | - 1 << M98090_TDM_SLOTR_SHIFT | - 0 << M98090_TDM_SLOTDLY_SHIFT); - - /* FSW TDM */ - snd_soc_component_update_bits(component, M98090_REG_TDM_CONTROL, - M98090_TDM_MASK, - M98090_TDM_MASK); - } + if (rx_mask != tx_mask) + return -EINVAL; - /* - * Normally advisable to set TDM first, but this permits either order - */ - cdata->fmt = 0; - max98090_dai_set_fmt(codec_dai, max98090->dai_fmt); + if (!rx_mask) + return -EINVAL; + + max98090->tdm_slots = slots; + max98090->tdm_width = slot_width; + max98090->tdm_lslot = ffs(rx_mask) - 1; + max98090->tdm_rslot = fls(rx_mask) - 1; return 0; } @@ -2411,6 +2412,9 @@ static int max98090_probe(struct snd_soc_component *component) max98090->pa1en = 0; max98090->pa2en = 0; + max98090->tdm_lslot = 0; + max98090->tdm_rslot = 1; + ret = snd_soc_component_read(component, M98090_REG_REVISION_ID); if (ret < 0) { dev_err(component->dev, "Failed to read device revision: %d\n", diff --git a/sound/soc/codecs/max98090.h b/sound/soc/codecs/max98090.h index a197114b0dad..2d2971acd150 100644 --- a/sound/soc/codecs/max98090.h +++ b/sound/soc/codecs/max98090.h @@ -1534,6 +1534,8 @@ struct max98090_priv { unsigned int dai_fmt; int tdm_slots; int tdm_width; + int tdm_lslot; + int tdm_rslot; u8 lin_state; unsigned int pa1en; unsigned int pa2en;
On Wed, Jun 21, 2023 at 10:57:18PM +0300, Maxim Kochetkov wrote: > On 21.06.2023 17:35, Mark Brown wrote: > > > > > I'm saying there should be some interlock between these two settings, if > > > > > nothing else setting DSP A mode should force TDM mode with automatically > > > > > configured slot sizes. > Ok. How about that: > --- > sound/soc/codecs/max98090.c | 52 ++++++++++++++++++++----------------- > sound/soc/codecs/max98090.h | 2 ++ > 2 files changed, 30 insertions(+), 24 deletions(-) That looks plausible, yes. I do note that the driver ignores tdm_width (and the entire TDM configuration) when configuring BCLK, I guess it only works in clock consumer mode for TDM? If that's the case there should really be some validation, and there should probably be a check for slot width being 16 since that looks like the only thing supported. Those were already broken though.
On 21.06.2023 23:46, Mark Brown wrote: >> Ok. How about that: >> --- >> sound/soc/codecs/max98090.c | 52 ++++++++++++++++++++----------------- >> sound/soc/codecs/max98090.h | 2 ++ >> 2 files changed, 30 insertions(+), 24 deletions(-) > > That looks plausible, yes. > > I do note that the driver ignores tdm_width (and the entire TDM > configuration) when configuring BCLK, I guess it only works in clock > consumer mode for TDM? If that's the case there should really be some > validation, and there should probably be a check for slot width being 16 > since that looks like the only thing supported. Those were already > broken though. Yep, tdm_width is not used in the driver and I can drop it. We already have slot_width validation in set_tdm_slot(), so only 16 is allowed. I didn't check/use clock provider mode. But it looks fine for me. set_fmt() just sets frame width here: 32 - by default, 48/64 - 3/4 slots if configured. We also check slots count in set_tdm_slots(). It will work for I2S/TDM.
diff --git a/sound/soc/codecs/max98090.c b/sound/soc/codecs/max98090.c index 7bc463910d4f..403926254c84 100644 --- a/sound/soc/codecs/max98090.c +++ b/sound/soc/codecs/max98090.c @@ -1635,7 +1635,7 @@ static int max98090_dai_set_fmt(struct snd_soc_dai *codec_dai, regval |= M98090_RJ_MASK; break; case SND_SOC_DAIFMT_DSP_A: - /* Not supported mode */ + break; default: dev_err(component->dev, "DAI format unsupported"); return -EINVAL;