summaryrefslogtreecommitdiff
path: root/drivers/gpu
diff options
context:
space:
mode:
authorBen Skeggs <bskeggs@redhat.com>2011-04-20 14:36:13 +1000
committerBen Skeggs <bskeggs@redhat.com>2011-05-16 10:50:57 +1000
commit96d1fcf8b5a3a9c66fddeaa9fb71e4e68ee2e08b (patch)
tree5725a2df3eacaee55f9da6ed6fccbba641105f4c /drivers/gpu
parentbfb61f43b37158d432a1897bc2a4bbbd41215fae (diff)
drm/nouveau/pm: translate ramcfg strap through ram restrict table
Hopefully this is how we're supposed to correctly handle when the RAMCFG strap is above the number of entries in timing-related tables. It's rather difficult to confirm without finding a configuration where the ram restrict table doesn't map 8-15 back onto 0-7 anyway. There's not a single vbios in the repo which is configured differently.. In any case, this is probably still better than potentially reading outside of the bounds of various tables.. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Diffstat (limited to 'drivers/gpu')
-rw-r--r--drivers/gpu/drm/nouveau/nouveau_perf.c6
1 files changed, 4 insertions, 2 deletions
diff --git a/drivers/gpu/drm/nouveau/nouveau_perf.c b/drivers/gpu/drm/nouveau/nouveau_perf.c
index 6e3f93334a97..922fb6b664ed 100644
--- a/drivers/gpu/drm/nouveau/nouveau_perf.c
+++ b/drivers/gpu/drm/nouveau/nouveau_perf.c
@@ -116,8 +116,10 @@ nouveau_perf_timing(struct drm_device *dev, struct bit_entry *P,
entries = tmap[4];
}
- ramcfg = nv_rd32(dev, NV_PEXTDEV_BOOT_0) & 0x0000003c;
- ramcfg >>= 2;
+ ramcfg = (nv_rd32(dev, NV_PEXTDEV_BOOT_0) & 0x0000003c) >> 2;
+ if (bios->ram_restrict_tbl_ptr)
+ ramcfg = bios->data[bios->ram_restrict_tbl_ptr + ramcfg];
+
if (ramcfg >= entries) {
NV_WARN(dev, "ramcfg strap out of bounds!\n");
return NULL;