[alsa-devel] [PATCH 2/8] ASoC: Add support for virtual switch controls

[Lars-Peter Clausen]

On 01/11/2013 01:45 PM, Mark Brown wrote:
> On Fri, Jan 11, 2013 at 01:38:55PM +0100, Lars-Peter Clausen wrote:
>> On 01/11/2013 01:19 PM, Mark Brown wrote:
> 
>>> going to affect everything else in the path).  I'd expect to see
>>> something like this implemented by having a control that has a specified
>>> value forced in the register while the control is enabled (kind of the
>>> opposite of a supply).  This is a fairly common need for older parts
>>> though it's unusual to see it on a new device.
> 
>> I think I want the opposite of what you just described. I want to be able to
>> overwrite the control setting based on the power state.
> 
> Right, just a thinko though - you see the point though.
> 
>> In ASoC I modeled this by letting DAPM take care of mute controls. E.g. the
>> mute control gets disabled if there is an active path from the DAC through
>> the mixer to one of the outputs and gets disabled otherwise. This makes sure
>> that when the DAC is powered down (when there is no active path from the DAC
>> to any of the outputs) each mute control is also enabled. The virtual
>> switches now allow disable a path from the DAC to the mixer, which in turn
>> will cause DAPM to enable the mute control. This is similar to how the
>> virtual enums already work.
> 
> Virtual enums do actually end up routing, that's not what a mute control
> usually does.  You can do the above in the manner I suggested, just have
> the register forced to a particular value when the DAC is disabled.

Well, that's what the code does. The alternative is to implement more or
less in the driver. Have custom put/get callbacks for the controls, which
write to a shadow register, only if the DAC is enabled the shadow value gets
written to the real register. And listen to the DAC powerdown/powerup
events, when it is powered down enable all hw mutes, when it is enabled
restore the shadow register value. The virtual control more or less
implements it in a generic manner so it does not have to be implemented by
each driver which needs this on its own.

- Lars