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]

Message-ID: <20160822091815.GE7104@lukather>
Date:   Mon, 22 Aug 2016 11:18:15 +0200
From:   Maxime Ripard <maxime.ripard@...e-electrons.com>
To:     wens Tsai <wens213@...il.com>
Cc:     Mark Brown <broonie@...nel.org>,
        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 Tue, Aug 16, 2016 at 12:45:39PM +0800, wens Tsai wrote:
> 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.

I'm not sure that's even a requirement. IIRC, but Mark might correct
me, you just need to expose whatever the reset state is.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

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