linux-kernel - Re: ASoC: sun4i-codec: playback stall and I/O error with DAPM paths all disabled

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]

Date:	Tue, 16 Aug 2016 12:45:39 +0800
From:	wens Tsai <wens213@...il.com>
To:	Mark Brown <broonie@...nel.org>
Cc:	Maxime Ripard <maxime.ripard@...e-electrons.com>,
	Liam Girdwood <lgirdwood@...il.com>,
	Code Kipper <codekipper@...il.com>,
	Linux-ALSA <alsa-devel@...a-project.org>,
	linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: ASoC: sun4i-codec: playback stall and I/O error with DAPM paths
 all disabled

On Mon, Aug 15, 2016 at 7:42 PM, Mark Brown <broonie@...nel.org> wrote:
> On Mon, Aug 15, 2016 at 05:43:55PM +0800, wens Tsai wrote:
>
>> What is unexpected is any attempt to play anything under this state makes
>> the playback software (in my case mpg321) stall, and later report an I/O
>> error. My guess is that the DAC is still disabled by DAPM, so it doesn't
>> send any DRQs, and thus the DMA engine is not consuming any data from
>> userspace.
>
> This is normal for ASoC - like you say it'll be becasue the hardware
> isn't powered up.
>
>> I think we should just enable the digital bits of the DAC/ADC all the
>> time. Or maybe transfer and then discard data if the DAC is off. Not
>> sure if this is doable though. I expect playback software to work, and
>> not block, regardless of the hardware status.
>
> Powering things up all the time will have a major effect on battery life
> for systems that care about that.  The expectation is that systems with
> this sort of hardware won't normally be offering end users direct
> control of the routing, it'll be something that's handled during system
> integration.

Ok. So I guess one solution would be to move the mute controls out of
DAPM, and maybe change some other mux like paths into actual muxes, so
there's at least one usable path at all times.

IIRC there was a patch doing something like this. I'll look into it.

Regards
ChenYu