linux-kernel - Re: [PATCH 5/9] ASoC: ssm2602: Add workaround for playback with external MCLK

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: <417f9340-3270-4579-8cff-701200a62591@sirena.org.uk>
Date:   Tue, 25 Apr 2023 17:42:03 +0100
From:   Mark Brown <broonie@...nel.org>
To:     Paweł Anikiel <pan@...ihalf.com>
Cc:     alsa-devel@...a-project.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, lgirdwood@...il.com, perex@...ex.cz,
        tiwai@...e.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, dinguyen@...nel.org,
        lars@...afoo.de, nuno.sa@...log.com, upstream@...ihalf.com
Subject: Re: [PATCH 5/9] ASoC: ssm2602: Add workaround for playback with
 external MCLK

On Tue, Apr 25, 2023 at 06:02:20PM +0200, Paweł Anikiel wrote:
> On Fri, Apr 14, 2023 at 7:35 PM Mark Brown <broonie@...nel.org> wrote:
> > On Fri, Apr 14, 2023 at 04:01:59PM +0200, Paweł Anikiel wrote:

> > > Apply a workaround for what seems to be a hardware quirk: when using
> > > an external MCLK signal, powering on Output and DAC for the first time
> > > produces output distortions unless they're powered together with whole
> > > chip power.

> > This doesn't seem coherent, these are multiple register writes so
> > clearly can't be done at the same moment as initial power on.  Clearly
> > there's some other constraint here.

> The "at the same time" part is done by writing multiple bits at once
> to SSM2602_PWR. But before that, SSM2602_ACTIVE has to be set, and
> then the chip is reset (SSM2602_RESET) to power everything down again.

So you need to power up the chip then do a register write sequence -
that's noticably different to what the description says.

> > > Here are some sequences run at the very start before a sw reset (and
> > > later using one of the NOT OK sequences from above):

> > >   ssmset 0x09 0x01 # core
> > >   ssmset 0x06 0x07 # chip, out, dac
> > >   OK

> > I can't tell what any of this is trying to say, especially given all the
> > magic numbers, and obviously no actual use of the driver should be
> > writing directly to the register map.

> These are shell commands run from userspace (with no ssm2602 driver
> present in the kernel). ssmset is a wrapper for the i2cset command:
> ssmset() {
>         i2cset -y 0 0x1a $(($1*2)) $2
> }
> I definitely should have made that more clear.

> Do you think these logs are worth adding? If so, I'll improve the
> explanation what these mean.

Probably?  Since I couldn't really follow what these were trying to tell
me it's a bit hard to say.  It looks like you worked this out yourself
rather than using an erratum so documenting where the workaround comes
from seems useful.

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)