[alsa-devel] [PATCH 10/10] ASoC: dapm: Implement mixer input auto-disable

Mark Brown broonie at kernel.org
Fri Aug 2 11:53:16 CEST 2013

On Thu, Aug 01, 2013 at 09:24:11PM +0200, Lars-Peter Clausen wrote:
> On 08/01/2013 12:48 PM, Mark Brown wrote:

> >Equally well I'd expect the value to always be a functioning cache of
> >the real value so I think what I'm really saying here is that I don't
> >think we should really be checking if the control is powered at all.  We
> >do need the I/O path but the power isn't the reason for it, the fact
> >that we have the value stashed locally is.

> There might be some corner cases where the driver directly modifies
> the register value outside of put_volsw() which would break. But
> otherwise I agree.

Yeah, I'd argue that anything doing that is probably broken though.

> >Another thing that's bothering me here is that this only works for mono
> >controls but many of the uses are stereo mutes and/or volumes.  We'd
> >need to add back the support for those.

> But that's a general limitation for DAPM controls. Right now
> snd_soc_dapm_put_volsw() only supports mono controls. If we have a
> left and a right mixer we usually have one mono control for each
> side. But I of course it would be nice to have support for stereo
> controls here. I guess with the shared control infrastructure we
> actually have most of what we need in place. The only thing missing
> is a way to express which channel of the control controls which
> path. E.g. an extra field per path or per mixer widget selecting the
> index.

Yes, or we could just say as a first pass that as soon as any one of the
paths gets enabled the whole control gets enabled which should cover a
large propoprtion of use cases (headphones or stereo speakers of which
only one might be connected).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://mailman.alsa-project.org/pipermail/alsa-devel/attachments/20130802/bd301017/attachment.sig>

More information about the Alsa-devel mailing list