linux-kernel - Re: [alsa-devel] [PATCH] ASoC: sgtl5000: only check VDDD-supply, not revision

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-next>] [day] [month] [year] [list]

Message-ID: <20160605231626.GA4076@archie.localdomain>
Date:	Mon, 6 Jun 2016 01:16:26 +0200
From:	Clemens Gruber <clemens.gruber@...ruber.com>
To:	Eric Nelson <eric@...int.com>, Fabio Estevam <festevam@...il.com>,
	Mark Brown <broonie@...nel.org>
Cc:	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [alsa-devel] [PATCH] ASoC: sgtl5000: only check VDDD-supply, not
 revision

Hi Eric, Fabio, Mark,

On Sat, Jun 04, 2016 at 07:15:25PM +0200, Clemens Gruber wrote:
> please don't merge the patch yet, I just observed a strange effect when
> resetting the board during playback / just after playback stops.
> At next boot time, sometimes the following error occurs:
> imx-sgtl5000 sound: ASoc: CODEC DAI sgtl5000 not registered
> imx-sgtl5000 sound: snd_soc_register_card failed (-517)

I looked into this today and discovered the following:

With my patch applied, if I reset the board just after playback, at the
next boot, the sgtl5000_fill_defaults function does not succeed: Writing
the default value 0x7060 to register 0x30 (CHIP_ANA_POWER) fails.

How did CHIP_ANA_POWER change with my patch: Before, only
LINREG_SIMPLE_POWERUP was cleared as is recommended in the datasheet
when using the internal LDO, now both LINREG_SIMPLE_POWERUP and
STARTUP_POWERUP are cleared, as is recommended when using external VDDD.

But why does the SGTL5000 nack that default write to CHIP_ANA_POWER
after a reboot, which interrupted the playback?

The following patch from Eric solved the problem; one write fails but it
continues setting the other registers and thus even if resetting a board
during playback, the sound still works after reboot:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088356.html
Another workaround might be to not even write a default value to
CHIP_ANA_POWER, as in this patch from Eric:
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-February/088355.html

What do you think we should do?

Regards,
Clemens