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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YVo4uuKJy2QIQ77n@geday>
Date:   Sun, 3 Oct 2021 20:11:54 -0300
From:   Geraldo Nascimento <geraldogabriel@...il.com>
To:     Jerome Brunet <jbrunet@...libre.com>
Cc:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        alsa-devel@...a-project.org, linux-amlogic@...ts.infradead.org,
        lgirdwood@...il.com, linux-kernel@...r.kernel.org, tiwai@...e.com,
        broonie@...nel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [RFC PATCH v1 0/1] ASoC: meson: aiu: HDMI codec control
 questions and issues

On Sun, Oct 03, 2021 at 05:57:34PM +0200, Jerome Brunet wrote:
> 
> On Sun 03 Oct 2021 at 01:43, Martin Blumenstingl <martin.blumenstingl@...glemail.com> wrote:
> 
> > Hello Jerome et al.,
> >
> > on Amlogic Meson SoCs which use the AIU audio controller we have the
> > so-called "machine gun noise" (MGN) issue, reproducible for example in
> > Kodi. So far nobody was able to identify the cause of this issue. My
> > idea was to at least narrow down the issue so we can categorize it. For
> > that I wanted to get the SPDIF output from AIU to the HDMI controller
> > working.
> 
> Ok, I'll clarify (again) about this issue.
> 
> This issue is on AIU only (not the AXG series), on the i2s encoder
> regardless of the output (HDMI, internal and external codec)
> 
> This encoder support either 2ch or 8ch mode, nothing else.
> As long as only 2ch was supported, there was no problem.
> In order to switch between 2ch and 8ch mode.  AIU_RST_SOFT_I2S_FAST and
> AIU_I2S_SYNC shall be "poked" (check iu-fifo-i2s.c and
> aiu-encoder-i2c.c). Without this, the switch is not done.
> 
> What these do, how and when it should be done is unclear. I tried
> several combination. At the time I found something stable-ish but it was
> not perfect.
> 
> 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.
> 

Hi, Jerome,

Thanks for the extensive clarification. I have compiled 5.15-rc3
commenting out the pokes for 8ch as you have suggested, both for
AIU_RST_SOFT_I2S_FAST and AIU_I2S_SYNC in both aiu-fifo-i2s.c
and aiu-encoder-i2c.c.

It works, the bug is gone just like you said it would be.

My suggestion is that, for the time being, until someone can solve
this properly, you restrict enablement of 8ch configuration under
an EXPERIMENTAL kernel option, with a big fat warning in the help
description, saying it will break 2ch.

Last but no least, thanks for helping Martin out.

Thank you,
Geraldo Nascimento

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ