On Mon, Mar 22, 2010 at 04:46:08PM +0200, Peter Ujfalusi wrote: > On Monday 22 March 2010 16:15:44 ext Mark Brown wrote: > > I don't see any fundamental problem here - mostly this just maps on to > > "if the widget is powered on write this value, otherwise write the > > value configured by the control.". > Hmm, I suppose it could be possible to pass the name of the DAPM widget, a > bitmask to a control... > Than in the handler in the core we could walk through the DAPM widgets, and find > the one, check the status, and if it is on, we allow the write, otherwise we > could use the mask to write only the things, that it is needed. Something like that, yes - the walk could happen at startup time to avoid having to do it repeatedly. > But, in TWL case I'd like to filter out also the writes which is done by the > DAPM widgets (which is visible from the user space, the mixers). > As it is now, if user changes the mixer, which is associated with DAPM widget > (and it is different than the PGA, they are DAPM_MIXER), than that write goes > directly to the register, and this write takes the cached value, makes the > changes and than writes it to register. This also enables the gain (which > enables the amp, which takes power). Remember, the register cache is below the controls and transparent to them - if the controls haven't written a value to the chip then it will not appear in the register cache so other controls will not be affected. > > Well, I was rather hoping I could convince you to make this more > > generic. But if that's not possible then yes, please do make the commit > > message clearer. > I need to study other codes as well, before I could start doing something more > generic, which I totally agree would be beneficial for others as well. > But for now, I would like to update the commit message, and come back later, and > revisit the possibility of similar, and more generic ways of doing this. I guess. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
