On 29 April 2014 11:46, Srivatsa S. Bhat
<srivatsa.bhat@xxxxxxxxxxxxxxxxxx> wrote:
> Yes, I'm aware that this corner case doesn't work well with my debug
Don't know if its a corner case, it may be the most obvious case for
some :)
> patch. I tried to avoid this but couldn't think of any solution.
The problem is not that it wouldn't work for these systems, but we will
get WARN_ON() when they shouldn't have come :)
> (One big-hammer way to avoid this is to exclude this infrastructure
> for all ASYNC_NOTIFICATION drivers, but I didn't want to go with that
> approach, since it makes it look ugly). Do you have any better ideas
> to deal with this scenario?
Can't think of anything better than this:
+ WARN_ON(!(cpufreq_driver->flags & CPUFREQ_ASYNC_NOTIFICATION)
&& (current == policy->transition_task));
which you already mentioned.
> Also, do we really have cases in mind where a single thread does
> multiple frequency transitions in one go? That too in such quick
> successions? Echo's to sysfs, changing of governors from userspace etc
> all do one frequency transition at a time per-task...
Its not really about if we can think of a real use case or not. The point
is, governor is free to call transition calls one after the other (will always
happen from a single thread) and it isn't supposed to wait for drivers
to finish earlier transitions as ->target() has already returned.
--
viresh
--
To unsubscribe from this list: send the line "unsubscribe cpufreq" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
