Description, Verify VIZ-1651 feature(gfx turbo for VLV), find the value gt_RP0_freq_mhz/gt_RP1_freq_mhz/gt_RPn_freq_mhz is equal to 0. Min_freq is 167 $cat /sys/class/drm/card0/gt_min_freq_mhz Max_freq is 755 $cat /sys/class/drm/card0/gt_max_freq_mhz Test Environment, Platform: Baytrail-M 00:00.0 Host bridge [0600]: Intel Corporation ValleyView SSA-CUnit [8086:0f00] (rev 06) 00:02.0 VGA compatible controller [0300]: Intel Corporation ValleyView Gen7 [8086:0f31] (rev 06) Driver version: OSD: Fedora Release 19.x86_64 Kernel_version: kernel-3.11.0rc2_drmintelfixes_61c254_20130731_+-6401.x86_64.rpm Libdrm: (master)libdrm-2.4.46-2-gfea5408098c3c3057958e85ea9d7146f0b08749e Mesa: (9.2)9b8ad643629fad1724e01c8fbb3289e43d42e1c1 Xserver: (server-1.13-branch)xorg-server-1.13.4 Xf86_video_intel: (master)2.21.13-35-g493763301e995d02cb838d14348da46dd26444af Cairo: (master)3cd6c5966aca1d202744fe44083800bc2a4a831d Libva: (master)d2dbc3f69c69e5933e7b3da429c0fb0cae5b98b0 Libva_intel_driver: (master)8bf807539c1790d6eee531373131672d38c82b31 OpenCL: (master) Kernel: (drm-intel-fixes) 61c2542b3b8e70fc1b82880c3ef7e2f930875b97 BIOS version: BBAYCRB_X64_R_SPI_0040_40_SEC_1040
Your description is very, very confused. Please do copy and paste the exact sequence of commands you use, and then describe exactly what you expected. Always attach a dmesg.
Jesse is the Batrail owner.
Chris, this bug is reported for GFX turbo feature on JIRA, owner is Jesse who provided us test methodology, he must know about it. (In reply to comment #1) > Your description is very, very confused. Please do copy and paste the exact > sequence of commands you use, and then describe exactly what you expected. > > Always attach a dmesg.
The bug report is still imprecise.
(In reply to comment #4) > The bug report is still imprecise. Let me clarify the reproduced steps, 1. Run a workload(Like as Openarena v0.8.8) 2. Navigate to /sys/class/drm/card0 to check P-state frequency 3. Observe some files indicated P-state frequency(gt_cur_freq_mhz is the current frequency, min/max are the min/max freqs, RP0 is the max P-state, RP1 is the "nominal" P-state, and RPn is the lowest frequency) Actual: The value of RP0/RP1/RPn frequency returned from these files is equal to 0. Expected: It should be max/nominal/max freq.
(In reply to comment #5) > (In reply to comment #4) > > The bug report is still imprecise. > > Let me clarify the reproduced steps, > 1. Run a workload(Like as Openarena v0.8.8) > 2. Navigate to /sys/class/drm/card0 to check P-state frequency > 3. Observe some files indicated P-state frequency(gt_cur_freq_mhz is the > current frequency, min/max are the min/max freqs, RP0 is the max P-state, > RP1 is the "nominal" P-state, and RPn is the lowest frequency) > > Actual: The value of RP0/RP1/RPn frequency returned from these files is > equal to 0. > Expected: It should be max/nominal/max freq. The purpose is to check whether P-state frequency will increase or not while running a workload.
Hm, vlv rps support was merged for 3.11 ... I have no idea why this doesn't work. Jesse?
rps support is there. Just gt_rp_mhz_show() was not adjusted for VLV.
Created attachment 83707 [details] [review] Expose RPe for vlv in sysfs
(In reply to comment #9) > Created attachment 83707 [details] [review] [review] > Expose RPe for vlv in sysfs Chris, I can't find this posted on the ml. But you can stick my r-b on it when you do.
Was waiting for the bug owner to notice ;-)
Assigning to Kobe. Please confirm.
(In reply to comment #9) > Created attachment 83707 [details] [review] [review] > Expose RPe for vlv in sysfs Chris, I can't find gt_RP0_freq_mhz/gt_RP1_freq_mhz/gt_RPn_freq_mhz under /sys/class/drm/card0 [root@x-byt02 card0]# ls card0-DP-1 card0-HDMI-A-2 dev error gt_max_freq_mhz power uevent card0-HDMI-A-1 card0-VGA-1 device gt_cur_freq_mhz gt_min_freq_mhz subsystem vlv_rpe_freq_mhz
Baytrail doesn't use RP0, RP1, or RPn. Hence the patch does not expose the sysfs files.
(In reply to comment #14) > Baytrail doesn't use RP0, RP1, or RPn. Hence the patch does not expose the > sysfs files. All right, if so, this bug can be closed.
The patch isn't merged yet, so we need to keep the bug report open until the fix has landed.
commit 97e4eed7dc532e20208b0bdf7ad1136569da2f35 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 26 16:18:54 2013 +0100 drm/i915: Adjust available RPS information through sysfs for vlv Valleyview has its own render power state implementation with different capability knobs - it has no RP0,RP1,RPn but rather RPe. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=67734 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: kobe.qin@intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Closing old verified+fixed.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.