- 20 10月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
Single-threaded forcewake was only used on some early pre-production ivybridge machines, all the latest ones should use mt forcewake. And we already assume this in other places of the code (e.g. DERRMR support in the ddx, or the latest intel_gt_reset patch to reset any lingering forcewake references left behind by the bios), so don't bother here, too. Reviewed-by: NMika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 18 10月, 2012 2 次提交
-
-
由 Chris Wilson 提交于
Some BIOSes may forcibly suspend RC6 during their operation which trigger a warning as we find the hardware in a perplexing state upon first use. So far that appears to be the worst symptom as fortuituously we use the same values as the BIOS for programming the FORCEWAKE register. Reported-by: NOleksij Rempel <bug-track@fisher-privat.net> Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
No functional change, but reserves 0x2 for use by userspace. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 16 10月, 2012 2 次提交
-
-
由 Ben Widawsky 提交于
BIOS should be setting the minimum voltage for rc6 to be 450mV. Old or buggy BIOSen may not be doing this, so we correct it for them. Ideally customers should update the BIOS as only it would know the optimal values for the platform, so we leave that fact as a DRM_ERROR for the user to see. Unfortunately this isn't fixing any of the issues it was targeted to fix, but it is documented that we must do it. CC: Jesse Barnes <jbarnes@virtuousgeek.org> CC: Matt Turner <mattst88@gmail.com> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> [danvet: bikeshedded loglevel of the "your bios is broken message" to debug.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
There is a special mechanism for communicating with the PCU already being used for the ring frequency stuff. As we'll be needing this for other commands, extract it now to make future code less error prone and the current code more reusable. I'm not entirely sure if this code matches 1:1 with the previous code behaviorally. Functionally however, it should be the same. CC: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> [danvet: Fixup compile fail reported by Wu Fengguang.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 11 10月, 2012 1 次提交
-
-
由 Paulo Zanoni 提交于
Introduced in commit 87f8020e: drm/i915: implement WaDisableEarlyCull for VLV and IVB Notice that the original patch sent to the mailing list did not include the Haswell chunk, it was added later. The bit set by the commit does not exist on Haswell machines (at least that's what the documentation says). Also, the commit gives me a GPU hang every time we're loading the driver. So let's revert the Haswell chunk, making the patch do only what its title actually says. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 10月, 2012 3 次提交
-
-
由 Damien Lespiau 提交于
This workaround is only valid for IVB and VLV and the write triggers an error on HSW. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanonI@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
For the next person that checks these kind of things, without having to dig up the register definition. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
There's is another register (a read only, so no harm done) at 0x42020 on Haswell GPUs. Let's just remove the write from the copy&paste that introduced haswell_init_clock_gating(). A note for the interested reader, it does seem we have a duplication of the 0x42020 register definition, hence the removal of 2 writes. That duplication could be the object of a later patch. Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Tested-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 10月, 2012 2 次提交
-
-
由 Jesse Barnes 提交于
Workaround for a culling optimization. Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> [danvet: Also apply to haswell, spotted by Damien.] Reviewed-by: N"Lespiau, Damien" <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Jesse Barnes 提交于
References: https://bugs.freedesktop.org/show_bug.cgi?id=50250Signed-off-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 9月, 2012 2 次提交
-
-
由 Ben Widawsky 提交于
With the new "standardized" sysfs interfaces we need to be a bit more careful about setting the RPS values. Because the sysfs code and the rps workqueue can run at the same time, if the sysfs setter wins the race to the mutex, the workqueue can come in and set a value which is out of range (ie. we're no longer protecting by RPINTLIM). I was not able to actually make this error occur in testing. Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
In order to keep our cached values in sync with the hardware, we need a posting read here. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 11 9月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
Currently we've only frobbed this bit at irq_init time, but did not restore it at resume time. Move it to the gen3 clock gating function to fix this. Notice while reading through code. Cc: stable@vger.kernel.org (for 3.5 only) Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 03 9月, 2012 7 次提交
-
-
由 Ben Widawsky 提交于
The same designer from the previous patch has told us to never read FORCEWAKE. We only do this for the POSTING_READ(), so simply change that to something within the same cacheline (for no reason in particular other than it sounds nice). In the _mt case we can leverage the gtfifodbg check for the POSTING_READ. This partially reverts commit 6af2d180 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 26 16:24:50 2012 +0200 drm/i915: fix forcewake related hangs on snb v2: commit message, comments about posting read from (Daniel) Note: vlv forcewake doesn't need any changes for this special treatment since FORCEWAKE_VLV is in a totally different register range, and the readback FORCEWAKE_ACK_VLV readback that follows is in the same range. Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Acked-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: Added note.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
A designer familiar with the hardware has stated that the forcewake timeout can theoretically be as high as a little over 1ms. Therefore we modify our code to use 2ms (appropriate fudge and because we don't want to round down). Hopefully this can't prevent spurious timeouts. Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Acked-by: NChris Wilson <chris@chris-wilson.oc.uk> [danvet: again fix conflict with vlv patch.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ben Widawsky 提交于
It's used all over the place, and we want to be able to play around with the value, apparently. Note that it doesn't touch other timeouts of the same value (like gtfifo, and thread C0 wait). Signed-off-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NChris Wilson <chris@chris-wilson.oc.uk> [danvet: fixup conflict with vlv forcewake patches.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
<ickle> danvet: in the force wake, both DRM_ERRORs have the same string. <ickle> useful for .txt shrinkage, horrible for debugging Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
For some odd reasons, the vlv forcewake code is rather different from all other platforms, with no clear justification. Adjust things: - Don't check whether the gt is awake already (and bail out early), we need to grab a forcewake anyway. Otherwise the chip might go to sleep too early. And this would also screw up our forcewake accounting. - Like all other platforms, check whether the gt has cleared the forcewake bit in the _ACK register before setting it again. - Use _MASKED_BIT_ENABLE/DISABLE macros - Only use bit0 of the forcewake reg, not all 16 bits. - check the gtfifodb reg like on all other platforms in _put. - Drop the POSTING_READs for consistency. v2: Failure to git add ... again. v3: Fixup the spelling fail a bit. Tested-by: N"Purushothaman, Vijay A" <vijay.a.purushothaman@intel.com> Tested-by: N"Widawsky, Benjamin" <benjamin.widawsky@intel.com> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
We've had and still have too many issues where the gpu turbo doesn't quite to what it's supposed to do (or what we want it to do). Adding a tracepoint to track when the desired gpu frequency changes should help a lot in characterizing and understanding problematic workloads. Also, this should be fairly interesting for power tuning (and especially noticing when the gpu is stuck in high frequencies, as has happened in the past) and hence for integration into powertop and similar tools. Cc: Arjan van de Ven <arjan@linux.intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Acked-by: NPaul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
Like with the equivalent change for gen6+ rps state, this helps in clarifying the code (and in fixing a few places that have fallen through the cracks in the locking review). Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 8月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
It blows up. And hopefully this is the root-cause of the mysterious rc6 related hang on ilk. For reference, the commit that enabled rc6 on ilk again is: commit 456470eb Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 8 23:35:40 2012 +0200 drm/i915: enable rc6 on ilk again Reported-by: NDave Airlie <airlied@gmail.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 8月, 2012 1 次提交
-
-
由 Chris Wilson 提交于
Avoid stalling and waiting for the GPU by checking to see if there is sufficient inactive space in the aperture for us to bind the buffer prior to writing through the GTT. If there is inadequate space we will have to stall waiting for the GPU, and incur overheads moving objects about. Instead, only incur the clflush overhead on the target object by writing through shmem. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 21 8月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
James Bottomley reported [1] a massive power regression, due to the enabling of semaphores by default in 3.5. A workaround for him is to again disable semaphores. And indeed, his system has a very hard time to enter rc6 with semaphores enabled. Ben Widawsky run around with a kill-a-watt a lot and noticed: - There are indeed a few rare systems that seem to have a hard time entering rc6 when desktop-idle. - One machine, The Indestructible Toshiba regressed in this behaviour between 3.5 and 3.6 in a merge commit! So rc6 behaviour with the current setting seems to be highly timing dependent and not robust at all. - The behaviour James reported wrt semaphores seems to be a freak timing thing that only happens on his specific machine, confirming that enabling semaphores shouldn't reduce rc6 residency. Now furthermore the Google ChromeOS guys reported [2] a while ago that at least on some machines a simply a blinking cursor can keep the gpu turbo at the highest frequency. This is because the current rps limits used on snb/ivb are highly asymmetric. On the theory that gpu turbo and rc6 tuning values are related, we've tried whether the much saner looking (since much less asymmetric) rps tuning values used for hsw would also help entering rc6 more robustly. And it seems to mostly work, and we don't really have the resources to through-roughly tune things in any better way: The values from the ChromeOS ppl seem to fare a bit worse for James' machine, so I guess we better stick with something vpg (the gpu hw/windows group) provided, hoping that they've done their jobs. Reference[1]: http://lists.freedesktop.org/archives/dri-devel/2012-July/025675.html Reference[2]: http://lists.freedesktop.org/archives/intel-gfx/2012-July/018692.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53393Tested-by: NBen Widawsky <ben@bwidawsk.net> Cc: stable@vger.kernel.org Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 10 8月, 2012 6 次提交
-
-
由 Daniel Vetter 提交于
I have the faint hope that the total absence of any locking for the rps code wasn't too good an idea and could very well have caused some rc6 related regressions. Unfortunately we've never managed to reproduce these issues on any of our own machines, so the only way to go about this is to enable it and see what happens. While at it, kill some stale comments and improve the logging. Acked-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
We change the drps/ips sw/hw state from different callers: Our own irq handler, the external intel-ips module and from process context. Most of these callers don't take any lock at all. Protect everything by making the mchdev_lock irqsave and grabbing it in all relevant callsites. Note that we have to convert a few sleeps in the drps enable/disable code to delays, but alas, I'm not volunteering to restructure the code around a few work items. For paranoia add a spin_locked assert to ironlake_set_drps, too. v2: Move one access inside the lock protection. Caught by the dev_priv->ips mass-rename ... v3: Resolve rebase conflict. Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
It's only ever a pointer to the global mchdev_lock, and we don't use it at all. Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
This way it's easier so see what belongs together, and what is used by the ilk ips code. Also add some comments that explain the locking. Note that (cur|min|max)_delay need to be duplicated, because they're also used by the ips code. v2: Missed one place that the dev_priv->ips change caught ... Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
- Take the dev->struct_mutex around access the corresponding state (and adjusting the rps hw state). - Add an assert to gen6_set_rps to ensure we don't forget about this in the future. - Don't set up the min/max_freq files if it doesn't apply to the hw. And do the same for the gen6+ cache sharing file while at it. v2: Move the gen6+ checks into the read/write callbacks. Thanks to the awesome drm midlayer we can't check that when registering the debugfs files, because the driver is not yet fully set up, specifically the ->load callback hasn't run yet. Oh how I despise this disaster ... v3: Also add a WARN_ON(mutex_is_locked) in set_rps to check the locking. v4: Use mutex_lock_interruptible, suggested by Chris Wilson. Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (for v2) Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
The update_gfx_val function called from mark_busy wasn't taking the mchdev_lock, as it should have. Also sprinkle a few spinlock asserts over the code to document things better. Things are still rather confusing, especially since a few variables in dev_priv are used by both the gen6+ rps code and the ilk ips code. But protected by totally different locks. Follow-on patches will clean that up. v2: Don't add a deadlock ... hence split up update_gfx_val into a wrapper that grabs the lock and an internal __ variant for callsites within intel_pm.c that already have taken the lock. v3: Mark the internal helper as static, noticed by Ben Widawsky. v4: Damien Lespiau had questions about the safety of the ips setup sequence, explain in a comment why it works. Reviewed-by: NDamien Lespiau <damien.lespiau@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 09 8月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
In commit commit 20b46e59 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Jul 26 11:16:14 2012 +0200 drm/i915: Only set the down rps limit when at the loweset frequency The computation for the new desired frequency was extracted, but since the desired frequency was passed-by value, the adjustments didn't propgate back. Fix this. Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 27 7月, 2012 1 次提交
-
-
由 Daniel Vetter 提交于
... by adding seemingly redudant posting reads. This little dragon lair exploded the first time around when we've refactored the code a bit to use the common wait_for_atomic_us in "drm/i915: Group the GT routines together in both code and vtable", which caused QA to file fdo bug #51738. Chris Wilson entertained a few approaches to fixing #51738: Replacing the udelay(1) with the previously-used udelay(10) (or any other "sufficiently larger" delay), adding a posting read, or ditching the delay completely and using cpu_relax. We went with the cpu_relax and "915: Workaround hang with BSD and forcewake on SandyBridge". Which blew up in fdo bug #52424, but adding the posting read while still using cpu_relax seems to also fix that, it looks like the posting read is the important ingriedient to fix these rc6 related hangs on snb. Popular theories as to why this is like it is include: - A herd of pink elephants got royally angered somehow. - The gpu has internally different functional units and judging by the register offsets, the forcewake request register and the forcewake ack registers are _not_ in the same functional unit (or at least aren't reached through the same routes). Hence the posting read syncs up with the wrong block and gets the entire gpu confused. - ... As a minimal ducttape fix for 3.6, let's just put these posting reads into place again. We can try fancier approaches (like adding back the cpu_relax instead of the udelay) in -next. This (re-)fixes a regression introduced in commit 990bbdad Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jul 2 11:51:02 2012 -0300 drm/i915: Group the GT routines together in both code and vtable Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: NChris Wilson <chris@chris-wilson.co.uk> Tested-by: NDu Yan <yanx.du@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=52424 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=51738uSigned-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 26 7月, 2012 3 次提交
-
-
由 Daniel Vetter 提交于
We believe to have squashed all issues around the gen6+ rps interrupt generation and why the gpu sometimes got stuck. With that cleared up, there's no user left for the sanitize_pm infrastructure, so let's just rip it out. Note that 'intel_reg_write 0xa014 0x13070000' is the w/a if we find ourselves stuck again. Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
The power docs say that when the gt leaves rc6, it is in the lowest frequency and only about 25 usec later will switch to the frequency selected in GEN6_RPNSWREQ. If the downclock limit expires in that window and the down limit is set to the lowest possible frequency, the hw will not send the down interrupt. Which leads to a too high gpu clock and wasted power. Chris Wilson already worked on this with commit 7b9e0ae6 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Sat Apr 28 08:56:39 2012 +0100 drm/i915: Always update RPS interrupts thresholds along with frequency but got the logic inverted: The current code set the down limit as long as we haven't reached it. Instead of only once with reached the lowest frequency. Note that we can't always set the downclock limit to 0, because otherwise the hw will keep on bugging us with downclock request irqs once the lowest level is reached. For similar reasons also always set the upclock limit, otherwise the hw might poke us again with interrupts. v2: Chris Wilson noticed that the limit reg is also computed in sanitize_pm. To avoid duplication, extract the code into a common function. Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
As suggested by Daniel, rip out the independent timers for device and crtc busyness and integrate the manual powermanagement of the display engine into the GEM core and its request tracking. The benefits are that the code is a lot smaller, fewer moving parts and should fit more neatly into the overall activity tracking of the driver. v2: Complete overhaul and removal of the racy timers and workers. Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 20 7月, 2012 2 次提交
-
-
由 Eugeni Dodonov 提交于
This initializes power wells within the modeset_init_hw routine. Testing has shown that this works for both driver load time and for suspend-resume code paths. Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Chris Wilson 提交于
There is little point waking up every 10ms to service an interrupt which we then promptly ignore. So only program the the PMIER to enable interrupts for those events which we do handle, not all of them! Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Eugeni Dodonov <eugeni.dodonov@intel.com> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Reviewed-by: NJesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 05 7月, 2012 3 次提交
-
-
由 Eugeni Dodonov 提交于
This pollutes dmesg output even if we do not have FBC for the device, so move the DRM_DEBUG_KMS statement lower. v2: just kill the message as suggested by Daniel. Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daniel Vetter 提交于
While creating the new enable/disable_gt_powersave functions in commit 8090c6b9 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Sun Jun 24 16:42:32 2012 +0200 drm/i915: wrap up gt powersave enabling functions I've botched up the handling of ironlake_disable_rc6. Fix this up by calling it at the right place. Note though that ironlake_disable_rc6 does a bit more than just disabling rc6 - it also tears down all the allocated context objects. Hence we need to move intel_teardown_rc6 out and directly call it from intel_modeset_cleanup. Also properly mark ironlake_enable_rc6 as static and kill the un-used declaration in i915_drv.h. Note: In review a question popped out why disable_rc6 also tears down the backing object and why we should move that out - it's simply for consistency with gen6+ rps code, which does it that way. Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: NEugeni Dodonov <eugeni.dodonov@intel.com> Reviewed-by: NBen Widawsky <ben@bwidawsk.net> Signed-Off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Eugeni Dodonov 提交于
This commit moves force wake support routines into intel_pm modules, and exports the gen6_gt_check_fifodbg routine (used in I915_READ). Signed-off-by: NEugeni Dodonov <eugeni.dodonov@intel.com> Acked-by: NBen Widawsky <ben@bwidawsk.net> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-