Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp3579010pxb; Mon, 4 Oct 2021 05:28:34 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyuAs00J/7d639Fm6T7Vj1kV/HiFjnBa3AR8/upcgEdWqI2si/Z60dbirdHEMYXF2MINWvT X-Received: by 2002:a17:902:9007:b0:13d:e735:443e with SMTP id a7-20020a170902900700b0013de735443emr23248204plp.74.1633350513822; Mon, 04 Oct 2021 05:28:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1633350513; cv=none; d=google.com; s=arc-20160816; b=h8DmX52fkFIP2PlKxZvsMM/1QpAaQTKl32ps4Lpy+i4GZLbubgLFr17d9GuSAe4uEn sSOsaCg6MqlSLTl9UxaKPA/yIwDTDTY6j5mEqkPvgDIPL0wjueXMgoprxJFqcRIioBxZ F/422Ls71UK2YXV3kZlDQl6JL0YVxRXhFkg4w6RwRgoh1yHEmjB5Clbv2jIDC87ZaV/C VuYpvp7BWguVpe7+lqTSOKllwn4phJY4x5R+w+iclZten2IcoDBnLDvgJ74ZxR0J20ll mtuSxptr+LXasy3U+cjdEV/TdBxe/rUhqB2N8qn3vchpUruKizYmUi2C0nriGBxHYAO9 ljAA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=ej7aJ0FW65oKsNtQjiH6FThlyKBsKax9Z2ffsEWdqTo=; b=ErAPA3bIM8qZpydieMxiqqlYVB7oNBL2b/CRQ8Z2tOBB24GDFX+QbZlUXOUrCCbpuz EO1ubsmj0gONnxL4khZK0ITKFKWbOCQKBwus7h0Q7R9geAvPhwRw5q+HC59pAWsKNXkC za/Z64vVAfcbZP3owJk2wO0iqZJxpyzzkQOMhA+NpIlS6jVUxmr1ZJD222f1x7lfgDQX dNOOS+ci7bJHgCAKwPOiDc3AZ/N53P83cH58yrjOBmqOwWlpsCnABS8CM4XpX4XqQpep 88SM6XuslA5LNl4A17P7BB6R7s/QSG+h183d3fdexV4KPhKM1j22w7vA5lXwn/B8DVn6 LHhw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Z8To3342; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id l7si11513092pfd.19.2021.10.04.05.28.20; Mon, 04 Oct 2021 05:28:33 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=Z8To3342; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232483AbhJDMZW (ORCPT + 99 others); Mon, 4 Oct 2021 08:25:22 -0400 Received: from mail.kernel.org ([198.145.29.99]:50250 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230337AbhJDMZU (ORCPT ); Mon, 4 Oct 2021 08:25:20 -0400 Received: by mail.kernel.org (Postfix) with ESMTPSA id 89A736124C; Mon, 4 Oct 2021 12:23:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1633350211; bh=ej7aJ0FW65oKsNtQjiH6FThlyKBsKax9Z2ffsEWdqTo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z8To3342g6UJ4vhD+OEmlMItibW536UAqAdbB+SVo6NVWWujgoLiFCBu3+FhKRHrq E2vD0eLdJXx+jZgCn9e+gmN+3aTBM7jUb8N/iUZH52RqRZfCFPp6r+uSOKC5+VTbVO h26tTuiC6+iTaaAfa0LyDzG90xPS/Ic88ckVvr4uxZz+sV06mwDvW5bb8MRfw1pTIH 1kxRoZluNAVqZ5XIi2Bp4LGXjNgavrWtuvv6IigN6UgKStxSoqy6ifWvGNkyIGA+El 7GDGK6r3NyAq5yX8EjpqzPAp8CkFEM0hercTJK15B81dfXmr6dzgVTcMCmB0jyn6oM Yrdceo7T4tL6g== Date: Mon, 4 Oct 2021 13:23:29 +0100 From: Mark Brown To: Martin Blumenstingl Cc: Jerome Brunet , alsa-devel@alsa-project.org, linux-amlogic@lists.infradead.org, lgirdwood@gmail.com, perex@perex.cz, tiwai@suse.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH v1 0/1] ASoC: meson: aiu: HDMI codec control questions and issues Message-ID: References: <20211002234313.3209294-1-martin.blumenstingl@googlemail.com> <1j35pivzho.fsf@starbuckisacylon.baylibre.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/+Vq12Du1ArhJUSc" Content-Disposition: inline In-Reply-To: X-Cookie: If it heals good, say it. Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --/+Vq12Du1ArhJUSc Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Oct 03, 2021 at 09:17:39PM +0200, Martin Blumenstingl wrote: > old 32-bit u-boot sources from the Endless Mini do have some > documentation on AIU_I2S_SYNC [0]: > // 8'b0_000_1_1_10 > // A write to this register will cause the interface to repeat the current > // sample. Can be used to regain synchronization. > // A read from this register indicates that the next sample to be sent > // out of the interface should go into the _left_ channel of the dac. > There's also a note about AIU_I2S_MISC stating: > // Bit 4 if true, force each audio data to left or right according to > the bit attached with the audio data > // This bit should be used with Register AIU_i2s_sync(0x511) together > To be honest: to me this is not helpful since I don't understand > how/why the left channel is of importance. The left channel is important because for most (I think all?) audio formats the first channel sent after each frame sync is the left channel, if you're trying to resync it's useful to know when a left frame is going to be sent. >=20 > > At the time, It was completely new driver. Even if was not rock solid, > > it was still progress and I opted to upstream it with an imperfect 8ch > > support so people could help debug it. This was mentioned in the > > original submission. > > > > The other solution is to restrict to 2ch mode and remove > > AIU_RST_SOFT_I2S_FAST and AIU_I2S_SYNC pokes. There will be no noise > > anymore. > I think Christian (Hewitt) agrees on this point as he mentioned that > your earlier versions of the AIU code (before it got upstream) were > not affected by the "machine gun noise" issue. > Does the documentation from above give you any new ideas (assuming > that it's correct since it's the best we have)? Should I try playing > with AIU_RST_SOFT_I2S_FAST and AIU_I2S_SYNC to see if I can make a > difference? >=20 > [...] > > Here you describe a DAI link (think of it as wires) between the SPDIF > > encoder (output) and AIU_HDMI input PCM. This is not what the HW is and > > it is not possible. > > > > Let's start from the HDMI controller. > > The designware (on amlogic SoC) has 2 interface for audio input. > > 1) PCM/I2S: a classic interface 2 clocks and N data line > > 2) SPDIF: The Sony Philips 1 wire interface > The Transwitch HDMI TX controller supports these two inputs so even > though the IP is different the basic functionality (which we'll > discuss below) is the same. >=20 > > Whatever comes up on 1) has to be some sort of i2s signal. So SPDIF > > won't fly there. > I agree with this >=20 > > AIU_HDMI output is Hardwired to 1). It is just just a digital mux, > > implemented as an ASoC codec which allows to seleted one of 2 audio > > sources: > > A) the i2s output implemented as part of the AIU > > B) the PCM output, part the AUDIN (yes, an output in AUDIN) block. This > > is not implemented ATM. > This is some interesting information, I thought that PCM was used > because PCM audio can be transmitted over SPDIF. >=20 > For A) my understanding is different though: > - for AIU_HDMI_CLK_DATA_CTRL[5:4] (HDMI_DATA_SEL) your description > matches my understanding. For me it makes sense that SPDIF data cannot > be selected with this register since it's a one-wire protocol (and > doesn't have separate data/clock lines). Value 0x2 selects the I2S > data interface > - for AIU_HDMI_CLK_DATA_CTRL[1:0] (HDMI_DATA_CLK_SEL) however I have a > different understanding: 0x0 disables the clock signal to the HDMI TX > controller, 0x1 selects the PCM clock (which now I have learned is > related to the AUDIN block) and 0x2 selects the "AIU clock" (see > below) > - my understanding is that "AIU clock" comes from AIU_CLK_CTRL_MORE[6] > (HDMITX_SEL_AOCLKX2) where 0x0 selects "cts_i958 as AIU clk to > hdmi_tx_audio_master_clk" (SPDIF clock) and 0x1 selects > "cts_aoclkx2_int as AIU clk to hdmi_tx_audio_master_clk" (I2S clock) >=20 > So to me this means that there's three different muxes: > - data mux to choose between 0x0 (all zeros), 0x1 (PCM) and 0x2 (I2S) > - clock mux to choose between 0x0 (disabled), 0x1 (PCM) and 0x2 > (hdmi_tx_audio_master_clk) > - hdmi_tx_audio_master_clk clock mux to choose between 0x0 (cts_i958) > and 0x1 (cts_aoclkx2_int) >=20 > Based on that I think that it's not possible to have AIU output the > I2S and SPDIF signals at the same time to the HDMI TX controller and > then letting the HDMI TX controller choose which one to use. > Based on whichever signal (I2S or SPDIF) we want to use for HDMI we > need to configure AIU accordingly (data and clock). >=20 > [...] > > It is not meant to. The dai_link and the endpoint are i2s. > > Your HDMI controller should have 2 inputs and should have a way to > > select one or the other. The format at each of the (internal) input does > > not change > ah, that makes sense. > Let's say AIU has some internal muxing for the HDMI output then AIU > would have two outputs as well (let's call them HDMI_OUT_I2S and > HDMI_OUT_SPDIF). > Then I'd wire up each of these to their corresponding inputs on the > HDMI TX controller. >=20 >=20 > Best regards, > Martin --/+Vq12Du1ArhJUSc Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmFa8kAACgkQJNaLcl1U h9BMJwf/d07nv9RvNZHG5kWNU/JXFm14eDZ04SF4RdZ8I320a4C5dlJmNPw/jxwL XXW9FK3/+o/D7tqAdZhXu+Jo1gng9/SzqhyEntA4mXZSit/QhFkbAtAFCHZe0fPa X3/0ed3NpFqQ/kxXXrOKqT58xgd9YmzayJsOmphoqyg5CuwfjXQscOXEDpmmIqAV Sa2lMR72R8hQM6LawLuRCctfrGzz27DHwmQU+y0le8rTzwtVY8irYYVRkK+w8R2a grsSNGqLupzt5trqsX2vnfD4zaPkAiLlTVFrItxUSVKd/bGu4ibJDUb4l0Qlmwnu uAkefotjbjTiYRhE46CruMibys76yQ== =X6z2 -----END PGP SIGNATURE----- --/+Vq12Du1ArhJUSc--