ext Mark Brown wrote:
On Fri, Oct 09, 2009 at 08:24:49PM +0200, ext-Eero.Nurkkala@nokia.com 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.