[Intel-gfx] [PATCH] drm/i915: add a tracepoint for gpu frequency changes

[Ben Widawsky]

On 2012-09-01 19:44, Arjan van de Ven wrote:
> On 9/1/2012 6:36 PM, Ben Widawsky wrote:
>
>> It depends on what you're trying to measure. I think this patch is 
>> quite useful but I think I'll make you defend your patch now since 
>> you're the maintainer and you took
>> your own patch and you're shooting down my idea. So please tell me 
>> what PowerTOP should do with this patch other than notice we're stuck 
>> (and furthermore, even if we're
>> stuck, what should it tell us to do)?
>
> what I would like to do, as the powertop guy.... is to show frequency
> stats similar to how we do that
> for CPUs. E.g. as close as to actual as we can get.
> few questions:
> 1) Can I read the momentary frequency somewhere?
> (it's great to get change events, but I also need a start frequency,
> otherwise I have a gap in
> knowledge from start of measurement to first change event)

I forget offhand if we ever added this. Daniel did ask me to do it a 
long time ago and I never got around to it. OTOH his trace event does 
tell you what frequency it's changed to, and the up/down steps should be 
incremental. In other words, from a single trace event you should know 
the current frequency and the previous frequency. Besides, eventually 
we'll just add this to systemd and load it before i915, right :p?

> 2) Can I read a "hardware average" somewhere, similar to what we can
> do for cpus ?

I'm not aware of an easy way to do this. The way the programming of 
these up and down events sort of does that though. There are various 
heuristics we have to configure via registers to get the HW to generate 
the interrupts at all. In other words if you decode the way the 
interrupts are generated and record a few events, you may get something 
that almost resembles an average. Honestly, it gets quite complicated as 
you might imagine and as such many of these values are opaque to us 
(magic numbers handed down through the ages). We could try to engage 
with mother Intel to find out from the designers how we could go about 
doing this in a more suitable way.

-- 
Ben Widawsky, Intel Open Source Technology Center