On 2012-09-03 01:41, Daniel Vetter wrote:
On Sun, Sep 02, 2012 at 12:24:41AM -0700, Ben Widawsky wrote:
Userspace applications such as PowerTOP are interesting in being
able to
read the current GPU frequency. The patch itself sets up a generic
array
for gen6 attributes so we can easily add other items in the future
(and
it also happens to be just about the cleanest way to do this).
The patch is a nice addition to
commit 1ac02185dff3afac146d745ba220dc6672d1d162
Author: Daniel Vetter <[email protected]>
Date: Thu Aug 30 13:26:48 2012 +0200
drm/i915: add a tracepoint for gpu frequency changes
Reading the GPU frequncy can be done by reading a file like:
/sys/class/drm/card0/render_frequency_mhz
CC: Arjan van de Ven <[email protected]>
Signed-off-by: Ben Widawsky <[email protected]>
I've just noticed that your sloppy maintainer totally missed to pick
up
Jesse's gt power consumption interface:
http://lists.freedesktop.org/archives/intel-gfx/2012-June/018404.html
After looking at the sysfs interfaces a bit, I think it makes sense to
take my patch, and force Jesse to redo his on top of mine. You owe Jesse
one sparkling wine.
Hence a bikeshed for the sysfs filename:
- render_ prefix is not accurate, this is for all of gt. I hence vote
for
a gt_
I only went with render_ since we're just exposing Rps. I have no
attachment to the name otherwise (I initially had a patch which called
it rps, in fact). Alternatively we can make gt_, and then create
symlinks to it called render, video, whatever. Sounds like overkill, but
I feel the name gt will become passe at some point, and I really like
having a descriptive file name.
- I think calling it gt_cur_freq would make sense in case we'll
expose
_min/_max limits through sysfs, too.
"cur" is of course redundant, and to me implicit, unless we do indeed
add the other ones. I actually prefer it without cur, but I really don't
care enough to argue further.
- Also, calling it _cur_freq withouth MHz keeps in style with the
frequency knobs exposed by cpus ...
I prefer mhz, but I really don't care. Arjan doesn't either so long as
it's in the name. One thing which sucks about hz is if we ever break the
32b barrier, we have to deal with the same crap we do in residency.
Now I guess I should go back to my trace point patch and adjust it to
expose plain Hz, too ... Anyone got some bikeshed on this?
-Daniel
If you don't change the mhz->hz, can you please just suck in the
patches with whatever name suits you (unless of course, anything I said
above was interesting). If we all agree to change mhz->hz, I will
resubmit the patches.
---
drivers/gpu/drm/i915/i915_sysfs.c | 31
+++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index da733a3..0cb479d 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -203,6 +203,30 @@ static struct bin_attribute dpf_attrs = {
.mmap = NULL
};
+static ssize_t render_frequency_mhz_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct drm_minor *dminor = container_of(dev, struct drm_minor,
kdev);
+ struct drm_device *drm_dev = dminor->dev;
+ struct drm_i915_private *dev_priv = drm_dev->dev_private;
+ int ret;
+
+ ret = i915_mutex_lock_interruptible(drm_dev);
+ if (ret)
+ return ret;
+
+ ret = dev_priv->rps.cur_delay * 50;
+ mutex_unlock(&drm_dev->struct_mutex);
+
+ return snprintf(buf, PAGE_SIZE, "%d", ret);
+}
+
+static struct device_attribute gen6_attrs[] = {
+ __ATTR_RO(render_frequency_mhz),
+ __ATTR_NULL,
+};
+
+
void i915_setup_sysfs(struct drm_device *dev)
{
int ret;
@@ -220,10 +244,17 @@ void i915_setup_sysfs(struct drm_device *dev)
if (ret)
DRM_ERROR("l3 parity sysfs setup failed\n");
}
+
+ if (INTEL_INFO(dev)->gen >= 6) {
+ ret = device_create_file(&dev->primary->kdev, gen6_attrs);
+ if (ret)
+ DRM_ERROR("gen6 sysfs setup failed\n");
+ }
}
void i915_teardown_sysfs(struct drm_device *dev)
{
+ device_remove_file(&dev->primary->kdev, gen6_attrs);
device_remove_bin_file(&dev->primary->kdev, &dpf_attrs);
sysfs_unmerge_group(&dev->primary->kdev.kobj, &rc6_attr_group);
}
--
1.7.12
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ben Widawsky, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
