Bug 42579 - [SNB] Need to disable RC6 if already enabled and passed i915.i915_enabe_rc6=0
Summary: [SNB] Need to disable RC6 if already enabled and passed i915.i915_enabe_rc6=0
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Eugeni Dodonov
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-03 22:52 UTC by Ouping Zhang
Modified: 2017-07-24 23:03 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Ouping Zhang 2011-11-03 22:52:46 UTC
System Environment:
--------------------------
Kernel: (drm-intel-next)64a742fac3a22f57303d8f1b7e347350a1c48254

Bug detailed description:
-------------------------
Whatever enabled RC6 or not, cat at /sys/kernel/debug/dri/0/i915_drpc_info:
	Render standby enabled: yes 
	Current RS state: on
Render standby enabled always is "yes".
enabled RC6, cat /sys/module/i915/parameters/i915_enable_rc6, "1"; disable RC6, cat /sys/module/i915/parameters/i915_enable_rc6, "0".
Comment 1 Chris Wilson 2011-11-04 02:16:42 UTC
Or not. Jesse, at the time you said this was only a debugging feature and so disabling the BIOS setting at startup was not worth it.

Do you feel that is still the case given the number of rc6+vt-d bugs?
Comment 2 Jesse Barnes 2011-11-04 11:48:05 UTC
> Or not. Jesse, at the time you said this was only a debugging feature and so
> disabling the BIOS setting at startup was not worth it.
> 
> Do you feel that is still the case given the number of rc6+vt-d bugs?

Yeah, I'm ok with disabling it regardless of existing state if we pass
i915_enable_rc6=0.
Comment 3 Ben Widawsky 2011-11-04 20:07:41 UTC
Well if this is being run on Gen6+ then I'll bet this is just the same as the other bug which says we're never in rc6... It appears all the register values we use for drpc are gone after ILK. If this is the case, I think we need to combine the two bugs, and say the debugfs entry is broken, and just fix that.

We should also clearly define what drpc means, because the acronym eludes me, and many of the fields aren't even relevant on gen6+.

As for disabing rc6 during runtime, which it felt like what Chris was getting at, I feel we should avoid it unless someone has a better use case then: "I want to do it." If anything because we've had so many issues with rc6 before, I can't imagine quiescing the render states to do this change will do anything but make things more fragile.
Comment 4 Gordon Jin 2011-11-12 04:18:05 UTC
(In reply to comment #3)
> Well if this is being run on Gen6+ then I'll bet this is just the same as the
> other bug which says we're never in rc6... 

Yes, it's Gen6. The title says SNB.
Comment 5 Chris Wilson 2011-12-14 09:19:27 UTC
Eugeni needs the underlying function to work for his own pet project...
Comment 6 Eugeni Dodonov 2011-12-14 11:22:29 UTC
We need to disable rc6 for hardware observability counters to give us correct data. At the same time, we don't need those counters all the time, so the idea was to disable rc6, grab their data (e.g., run a gl app or something like that), and re-enable it back again.
Comment 7 Chris Wilson 2012-04-03 13:37:14 UTC
commit 83b7f9ac9126f0532ca34c14e4f0582c565c6b0d
Author: Eugeni Dodonov <eugeni.dodonov@intel.com>
Date:   Fri Mar 23 11:57:18 2012 -0300

    drm/i915: allow to select rc6 modes via kernel parameter
    
    This allows to select which rc6 modes are to be used via kernel parameter,
    via a bitmask parameter. E.g.:
    
    - to enable rc6, i915_enable_rc6=1
    - to enable rc6 and deep rc6, i915_enable_rc6=3
    - to enable rc6 and deepest rc6, use i915_enable_rc6=5
    - to enable rc6, deep and deepest rc6, use i915_enable_rc6=7
    
    Please keep in mind that the deepest RC6 state really should NOT be used
    by default, as it could potentially worsen the issues with deep RC6. So do
    enable it only when you know what you are doing. However, having it around
    could help solving possible future rc6-related issues and their debugging
    on user machines.


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.