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