linux-kernel - Re: [PATCH] ASoC: mediatek: mt8188-mt6359: Remove hardcoded dmic codec

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f60f4242-9e4e-4846-b1f0-949daf68f6f5@notapiano>
Date: Mon, 6 Jan 2025 14:33:10 -0300
From: Nícolas F. R. A. Prado <nfraprado@...labora.com>
To: Chen-Yu Tsai <wenst@...omium.org>
Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>, Jaroslav Kysela <perex@...ex.cz>,
	Takashi Iwai <tiwai@...e.com>,
	Matthias Brugger <matthias.bgg@...il.com>,
	Trevor Wu <trevor.wu@...iatek.com>, kernel@...labora.com,
	linux-sound@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org,
	linux-mediatek@...ts.infradead.org, Fei Shao <fshao@...omium.org>
Subject: Re: [PATCH] ASoC: mediatek: mt8188-mt6359: Remove hardcoded dmic
 codec

On Thu, Dec 26, 2024 at 04:30:17PM +0800, Chen-Yu Tsai wrote:
> Hi,
> 
> On Wed, Dec 4, 2024 at 3:22 AM Nícolas F. R. A. Prado
> <nfraprado@...labora.com> wrote:
> >
> > Remove hardcoded dmic codec from the UL_SRC dai link to avoid requiring
> > a dmic codec to be present for the driver to probe, as not every
> > MT8188-based platform might need a dmic codec. The codec can be assigned
> > to the dai link through the dai-link property in Devicetree on the
> > platforms where it is needed.
> 
> A followup question about this. The DMICs on the Chromebooks are attached
> to the PMIC codec's input side, which then converts the signals to standard
> I2S and passes them out to the SoC through its AIF1. So the original code
> was somewhat incorrect, though it works.
> 
> How should we describe such a connection, given that the MediaTek sound
> bindings aren't a full graph?

What you're describing is that the hardware topology looks like this:

--------------------      --------------------
|    SoC           |      |   MT6359 PMIC    |
|        UL_SRC BE | <--- | AIF1   AIN0_DMIC | <-- DMic
--------------------      --------------------

But that the dailink definition in the machine driver had the DMic codec
connected directly to the UL_SRC BE instead, alongside the connection to the
PMIC, unlike the topology above.

My understanding is that the dmic codec was added simply to allow the usage of
the wakeup-delays. From [1] it appears that DAI connections between two codecs
are possible, though rare. So the PMIC -> DMic connection description might be
possible in that way, although I'm not sure it brings any benefits besides
closer resembling the hardware topology.

[1] https://www.kernel.org/doc/html/latest/sound/soc/codec-to-codec.html

> 
> > No Devicetree currently relies on it so it is safe to remove without
> > worrying about backward compatibility.
> 
> Removing it didn't seem to cause any issues for the Chromebooks that
> do actually have DMICs. I suspect the only difference would be that
> the wakeup-delays no longer apply correctly.

That's my guess too.

Thanks,
Nícolas