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