ext Mark Brown wrote: > On Fri, Oct 09, 2009 at 08:24:49PM +0200, ext-Eero.Nurkkala@xxxxxxxxx wrote: > >> I guess there's (or may be) an exception though. I think I've seen some >> strangeness with the close_delayed_work() -> and simultaneous mixer tweaking: > > As I said when you posted previously that's a problem anyway and > close_delayed_work() needs to be fixed. You had a half-posted patch, > did you manage to test it properly (even in normal operation)? I'd been > expecting a proper posting of it to appear at some point. Yes I did test it immediatelly. No apparent problems with that. However, now I use kernel 2.6.28 - and I'm about to update it next week. I wish to take the time with that patch, rather than taking the blame =) Lockdep doesn't seem to find dependencies with the mutex - until the code faces it. (I wish not to make other codecs unusable, locked up).. >> So there can and does run two dapm_power_widgets() when stars >> point to the right direction. That's when delayed work is at >> damp_power_widgets, and then preempted to >> the userspace thread. May that isn't related to this TPA though, but >> I think I'll silently review the code so that the "stars are forced to >> point to the right direction". > > This is completely unrelated to driver code, the core's data is much > more of a problem than the register cache which will generally fix > itself the next time DAPM does anything. Yeah, agreed. _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
