Am Dienstag, den 23.03.2010, 09:58 -0700 schrieb Arjan van de Ven: > On 3/23/2010 9:57, Thomas Renninger wrote: > > On Tuesday 23 March 2010 17:28:36 Robert Schöne wrote: > >> Am Montag, den 22.03.2010, 06:57 -0700 schrieb Arjan van de Ven: > >>> On 3/22/2010 0:04, Robert Schöne wrote: > >>>> Am Sonntag, den 21.03.2010, 17:42 -0700 schrieb Arjan van de Ven: > >>>>> On 3/20/2010 14:37, Thomas Renninger wrote: > >>>>> > >>>>>> It also seem to be (hopefully) a minor feature for timechart, so this should > >>>>>> not hurt that much (yet). > >>>>> > >>>>> It's actually a major feature for timechart, and one of the key things I and a bunch of others > >>>>> inside Intel use timechart for. > >>>>> > >>>> It's a major feature for us too. > >>>> I suppose, the cpufreq_notify_transition calls are correct (meaning > >>>> being called for all related cpus) for every driver. So there's still > >>>> the option to include it in the POST_CHANGE section of this function. > >>>> Could this be okay for the both of you? > >>> > >>> post change would work... that gets frequency afaik.. > >> Are you ok with this too, Thomas? > > You mean hooking it into cpufreq_stat_notifier_trans() in > > drivers/cpufreq/cpufreq_stats.c? > > no > > > hooking into the post frequency change callback that gets done.. > which is guaranteed to be on the right cpu afaics. > I don't see where this would be guaranteed. So I'd be fine with a) adding it to cpufreq.c/cpufreq_notify_transition/cpufreq_notify_transition b) adding an item to the cpufreq_transition_notifier_list c) adding it to cpufreq_stats.c/cpufreq_stat_notifier_trans which would imply the usage of smp_call_function_single(...) -- 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
