Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1467490

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

From Maxime Ripard <maxime.ripard@free-electrons.com>
Newsgroups linux.kernel
Subject Re: ASoC: sun4i-codec: playback stall and I/O error with DAPM paths all disabled
Date 2016-08-22 11:20 +0200
Message-ID <s8TyF-4oi-1@gated-at.bofh.it> (permalink)
References <s6mGR-3T5-17@gated-at.bofh.it> <s6oz0-537-9@gated-at.bofh.it> <s6Eu5-6Tr-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

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@kernel.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

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

ASoC: sun4i-codec: playback stall and I/O error with DAPM paths all disabled wens Tsai <wens213@gmail.com> - 2016-08-15 11:50 +0200
  Re: ASoC: sun4i-codec: playback stall and I/O error with DAPM paths  all disabled Mark Brown <broonie@kernel.org> - 2016-08-15 13:50 +0200
    Re: ASoC: sun4i-codec: playback stall and I/O error with DAPM paths  all disabled wens Tsai <wens213@gmail.com> - 2016-08-16 06:50 +0200
      Re: ASoC: sun4i-codec: playback stall and I/O error with DAPM paths  all disabled Maxime Ripard <maxime.ripard@free-electrons.com> - 2016-08-22 11:20 +0200
        Re: ASoC: sun4i-codec: playback stall and I/O error with DAPM paths  all disabled Mark Brown <broonie@kernel.org> - 2016-08-22 12:50 +0200

csiph-web