On Tuesday 16 March 2010 17:40:18 Arjan van de Ven wrote:
> On 3/16/2010 7:50, Thomas Renninger wrote:
> > Still, as this is totally broken:
> > - by design -> only one of a dozen cpufreq drivers is supported
>
> the one I care about is supported.
And that's the problem, before it's not removed, you do not care to
provide/suggest a proper solution that could fit others as well.
> The others... anyone can add
> support for their favorite driver.
Or everyone can write his own debug facility for every driver...
As said, there already is a debug facility. If you need timings,
improve the existing interface, suggest how it could get connected
to the tracing facility or why you see problems doing so.
> > please submit my patch and remove this again until a proper
> > implementation is provided.
> how about not. it works right now,
It does not. Robert's fix (if he had taken the frequency) is correct.
That means you could get totally wrong values
when you put some load on the machine and the scheduler moves around
processes. You'd better compared your results with cpufreq_stats...
> and is in active use right now.
It's obviously not powertop, there I get some statistics on an AMD
machine as well. So where does it get used?
> feel free to add support to other drivers if you care about those....
It's easy to fix up acpi-cpufreq itself and implement this into
powernow-k8. Not sure about possible cpufreq drivers which can switch
frequency on cores without executing the code on this core. I expect
trace(_power_frequency) is not made for such?
I assume everybody who did work on cpufreq interfaces would have given
you a not-ack'ed or at least had asked the questions I did above.
People know you well and x86 maintainers just pushed it, I also doubt
you intentionally did not CC the cpufreq list.
But now things are broken and should get reverted.
Grmpfl, I can have a look at it, but not the next couple of days...
Thomas
--
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
