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 _______________________________________________ Uclinux-dist-devel mailing list Uclinux-dist-devel@blackfin.uclinux.org https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel
