summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-03-07drm/i915: sanitize PUNIT register macro definitionsImre Deak
In the upcoming patches we'll need to access the rest of the fields in the punit power gating register, so prepare for that. v2: - add doc reference for the power well subsystem IDs (Jesse) - remove IDs for non-existant DPIO_RX[23] subsystems (Jesse) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: vlv: keep first level vblank IRQs maskedImre Deak
This is a left-over from commit b7e634cc8dcd320123199a18bae0937b40dc28b8 Author: Imre Deak <imre.deak@intel.com> Date: Tue Feb 4 21:35:45 2014 +0200 drm/i915: vlv: don't unmask IIR[DISPLAY_PIPE_A/B_VBLANK] interrupt where we stopped unmasking the vblank IRQs, but left them enabled in the IER register. Disable them in IER too. v2: - remove comment becoming stale after this change (Ville) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: check pipe power domain when reading its hw stateImre Deak
We can read out the pipe HW state only if the required power domain is on. If not we consider the pipe to be off. v2: - no change v3: - push down the power domain checks into the specific crtc get_pipe_config handlers (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Appease checkpatch.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: check port power domain when reading the encoder hw stateImre Deak
Since the encoder is tied to its port, we need to make sure the power domain for that port is on before reading out the encoder HW state. Note that this also covers also all connector get_hw_state handlers, since all those just call the corresponding encoder get_hw_state handler, which checks - after this change - for all power domains the connector needs. v2: - no change v3: - push down the power domain checks into the specific encoder get_hw_state handlers (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: get port power domain in connector detect handlersImre Deak
The connector detect and get_mode handlers need to access the port specific HW blocks to read the EDID etc. Get/put the port power domains around these handlers. v2: - get port power domain for HDMI too (Ville) - get port power domain for the DP,HDMI audio detect handlers (Jesse) - Leave the intel_runtime_pm_get/put in the DP detect function in place. Instead of just removing them, these should be moved to the appropriate power_well enable/disable handlers. We can do this after Paulo's 'Merge PC8 with runtime PM, v2' patchset. v3: - rebased on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: add port power domainsImre Deak
Parts that poke port specific HW blocks like the encoder HW state readout or connector hotplug detect code need a way to check whether required power domains are on or enable/disable these. For this purpose add a set of power domains that refer to the port HW blocks. Get the proper port power domains during modeset. For now when requesting the power domain for a DDI port get it for a 4 lane configuration. This can be optimized later to request only the 2 lane power domain, when proper support is added on the VLV PHY side for this. Atm, the PHY setup code assumes a 4 lane config in all cases. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: add noop power well handlers instead of NULL checking themImre Deak
Reading code free of special cases wins over the small overhead of calling a noop handler. Suggested by Jesse. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: split power well 'set' handler to separate enable/disable/sync_hwImre Deak
Split the 'set' power well handler into an 'enable', 'disable' and 'sync_hw' handler. This maps more conveniently to higher level operations, for example it allows us to push the hsw package c8 handling into the corresponding hsw/bdw enable/disable handlers and the hsw BIOS hand-over setting into the hsw/bdw sync_hw handler. No functional change. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> [danvet: Appease checkpatch's whitespace complaints.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: add init power domain to always-on power wellsImre Deak
Whenever we request a power domain it has to guarantee that all HW resources are enabled that are needed to access a HW register associated with that power domain. In case a register is on an always-on power well this won't result in turning on a power well, but it may require enabling some other HW resource. One such resource is the HSW/BDW device D0 state that is required for all register accesses and thus for all power wells/power domains. So far the init power domain (guaranteeing access to all HW registers) was part of the default i9xx always-on power well, but not the HSW/BDW always-on power wells. Add the domain to the latter power wells too. Atm, all the always-on power wells have noop handlers, so this doesn't change the functionality. v2: - clarify semantics of always-on power wells (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: move power domain macros to intel_pm.cImre Deak
These macros are used only locally, so move them to the .c file. No functional change. v2: - add init power domain to always-on power wells in the following - separate - patch (Paulo) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: Disable full ppgtt by defaultDaniel Vetter
There are too many oustanding issues: - Fence handling in the current code is broken. There's a patch series from me, but it's blocked on and extended review (which includes writing the testcases). - IOMMU mapping handling is broken, we need to properly refcount it - currently it gets destroyed when the first vma is unbound, so way too early. - There's a pending reset issue on snb. Since Mika's reset work and full ppgtt have been pulled in in separate branches and ended up intermittingly breaking each another it's unclear who's the exact culprit here. - We still have persistent evidince of crazy recursion bugs through vma_unbind and ppgtt_relase, e.g. https://bugs.freedesktop.org/show_bug.cgi?id=73383 This issue (and a few others meanwhile resolved) have blocked our performance measuring/tuning group since 3 months. - Secure batch dispatching is broken. This is blocking Brad Volkin's command checker work since 3 months. All these issues are confirmed to only happen when full ppgtt is enabled, falling back to aliasing ppgtt resolves them. But even aliasing ppgtt itself still has a regression: - We currently unconditionally bind objects into the aliasing ppgtt, which means all priviledged objects like ringbuffers are visible to unpriviledged access again. On top of that this also breaks the command checker for aliasing ppgtt, since it can't hide the validated batch any more. Furthermore topic/full-ppgtt has never been reviewed: - Lifetime rules around vma unbinding/release are unclear, resulting into this awesome hack called ppgtt_release. Which seems to take the blame for most of the recursion fallout. - Context/ring init works different on gpu reset than anywhere else. Such differeneces have in the past always lead to really hard to track down bugs. - Aliasing ppgtt is treated in a bunch of places as a real address space, but it isn't - the real address space is always the global gtt in that case. This results in a bit a mess between contexts and ppgtt object, further complication the context/ppgtt/vma lifetime rules. - We don't have any docs describing the overall concepts introduced with full ppgtt. A short, concise overview describing vmas and some of the strange bits around them (like the unbound vmas used by execbuf, or the new binding rules) really is needed. Note that a lot of the post topic/full-ppgtt merge fallout has already been addressed, this entire list here of 10 issues really only contains the still outstanding issues. Finally the 3.15 merge window is approaching and I think we need to use the remaining time to ensure that our fallback option of using aliasing ppgtt is in solid shape. Hence I think it's time to throw the switch. While at it demote the helper from static inline status because really. Cc: Ben Widawsky <ben@bwidawsk.net> Cc: Dave Airlie <airlied@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: move modeset_update_power_wells earlierImre Deak
These functions will be needed by the valleyview specific power well update functionality added in an upcoming patch, so move them earlier. No functional change. v2: - no change v3: - rebase on latest -nightly Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v2) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-07drm/i915: fold in __intel_power_well_get/put functionsImre Deak
These functions are used only by a single call site and are simple enough to just fold them in. Note that in later patches the parts folded in here are further simplified as we'll remove hsw_{disable,enable}_package_c8 and the NULL check of the power well enable/disable handlers. All this means that at the end intel_display_power_get/put() becomes more understandable as we don't need to jump between two functions when reading the code. No functional change. v2: - clarify the rational for the change (Chris) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Unify CHICKEN_PIPESL_1 register definitionsVille Syrjälä
We have two names for the same register CHICKEN_PIPESL_1 and HSW_PIPE_SLICE_CHICKEN_1. Unify it to just one. Also rename the FBCQ disable bit to resemble the name we've given to a similar bit on earlier platforms. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Use RMW to update chicken bits in gen7_enable_fbc()Ville Syrjälä
gen7_enable_fbc() may write to some registers which we've already touched, so use RMW so that we don't undo any previous updates. Also note that we implemnt WaFbcAsynchFlipDisableFbcQueue:bdw. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Don't clobber CHICKEN_PIPESL_1 on BDWVille Syrjälä
Misplaced parens cause us to totally clobber the CHICKEN_PIPESL_1 registers with 0xffffffff. Move the parens to the correct place to avoid this. In particular this caused bit 30 of said registers to be set, which caused the sprite CSC to produce incorrect results. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72220 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: reverse dp link param selection, prefer fast over wide againDaniel Vetter
... it's this time of the year again. Originally we've frobbed this to fix up some regressions, but maybe our DP code improved sufficiently now that we can dare to do again what the spec recommends. This reverts commit 2514bc510d0c3aadcc5204056bb440fa36845147 Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Thu Jun 21 15:13:50 2012 -0700 drm/i915: prefer wide & slow to fast & narrow in DP configs I'm pretty sure I'll regret this patch, but otoh I expect we won't make progress here without poking the devil occasionally. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=73694 Cc: peter@colberg.org Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Itai BEN YAACOV <candeb@free.fr> Tested-by: David En <d.engraf@arcor.de> Reported-and-Tested-by: Marcus Bergner <marcusbergner@gmail.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: No need to put forcewake after a resetMika Kuoppala
As we now have intel_uncore_forcewake_reset() no need to do explicit put after reset. v2: rebase Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Fix i915_switch_context() argument name in kerneldocDamien Lespiau
While reading some code, out of boredom, stumbled on a tiny tiny fix. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Remove unused to_gem_object() macroDamien Lespiau
That macro was only ever used to convert ring->private into a gem object (hence the forceful cast). ring->private doesn't even exist anymore as it was transmogrified by Chris in: commit 0d1aacac36530fce058d7a0db3da7befd5765417 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Aug 26 20:58:11 2013 +0100 drm/i915: Embed the ring->private within the struct intel_ring_buffer Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Make i915_gem_retire_requests_ring() staticDamien Lespiau
Its last usage outside of i915_gem.c was removed in: commit 1f70999f9052f5a1b0ce1a55aff3808f2ec9fe42 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Jan 27 22:43:07 2014 +0000 drm/i915: Prevent recursion by retiring requests when the ring is full Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Don't just say it, actually force edp vddPatrik Jakobsson
This patch fixes the blank screen bug introduced in 3.14-rc1 on the MacBook Air 6,2. The comments state that we need to force edp vdd so lets put it back. The regression was introduced by the following commit: commit dff392dbd258381a6c3164f38420593f2d291e3b Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Dec 6 17:32:41 2013 -0200 drm/i915: don't touch the VDD when disabling the panel v2: Wrap intel_disable_dp() with _vdd_on and _vdd_off Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74628 Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Make num_sprites a per-pipe valueDamien Lespiau
In the future, we need to be able to specify per-pipe number of planes/sprites. Let's start today! Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Add a for_each_sprite() macroDamien Lespiau
This macro is similar to for_each_pipe() we already have. Convert the two call sites we have at the same time. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Replace a few for_each_pipe(i) by for_each_pipe(pipe)Damien Lespiau
Consistency throughout the code base is good and remove some room for mistakes (as explained in the "drm/i915: Use a pipe variable to cycle through the pipes" commit) So, let's replace the for_each_pipe(i) occurences by for_each_pipe(pipe) when it's reasonable and practical to do so (eg. when there isn't another pipe variable already). Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Don't declare unnecessary shadowing variableDamien Lespiau
'i' is already defined in the function scope and used elsewhere. Let's use it instead. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Use a pipe variable to cycle through the pipesDamien Lespiau
I recently fumbled a patch because I wrote twice num_sprites[i], and it was the right thing to do in only 50% of the cases. This patch ensures I need to write num_sprites[pipe], ie it should be self-documented that it's per-pipe number of sprites without having to look at what is 'i' this time around. It's all a lame excuse, but it does make it harder to redo the same mistake. Signed-off-by: Damien Lespiau <damien.lespiau@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: We implement WaDisableAsyncFlipPerfMode:bdwVille Syrjälä
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Implement WaDisableSDEUnitClockGating:bdwVille Syrjälä
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Disable semaphore wait event idle message on BDWVille Syrjälä
According to BSpec we need to always set this magic bit in ring buffer mode. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Use DIV_ROUND_UP() when calculating number of required FDI lanesVille Syrjälä
If we need precisely N lanes to satisfy the FDI bandwidth requirement, the code would still claim that we need N+1 lanes. Use DIV_ROUND_UP() to get a more accurate answer. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Fix DDI port_clock for VGA outputVille Syrjälä
On DDI there's no PLL as such to generate the pixel clock for VGA. Instead we derive the pixel clock from the FDI link frequency. So to make .compute_config match what .get_config does, we need to set the port_clock based on the FDI link frequency. Note that we don't even check the port_clock when selecting the PLL for VGA output. We just assume SPLL at 1.35GHz is what we want, and that does match with the asumption of FDI frequency of 2.7Ghz we have in intel_fdi_link_freq(). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=74955 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Don't access fifodbg registers on gen8Mika Kuoppala
as they don't exists. v2: rename gen6_*_mt_* to gen7_*_mt_* as they never get called with gen6 (Chris) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v1) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Do forcewake reset on gen8Mika Kuoppala
When we get control from BIOS there might be mt forcewake bits already set. This causes us to do double mt get without proper clear/ack sequence. Fix this by clearing mt forcewake register on init, like we do with older gens. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: don't flood the logs about bdw semaphoresJani Nikula
BDW is no longer flagged as preliminary hw, but without i915.preliminary_hw_support module param set the logs are filled with WARNs about it. Just make semaphores off the BDW per-chip default for now. CC: Ben Widawsky <ben@bwidawsk.net> Reported-by: Sebastien Dufour <sebastien.dufour@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Add thread stall DOP clock gating workaround on Broadwell.Kenneth Graunke
Ben and I believe this will be necessary on production hardware. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> [danvet: Shuffle lines to group all ROW_CHICKEN writes and add a cautious comment that this might not be needed on production hw.] Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Add a partial instruction shootdown workaround on Broadwell.Kenneth Graunke
I believe this will be necessary on production hardware. Signed-off-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Fix whitespace fail spotted by checkpatch. Also add missing :bdw w/a tag that Ville spotted.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Add suspend count to error stateMika Kuoppala
For example if we get bug reports with similar error states and suspend count is always 1, that might lead the Sherlocks to right general direction. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Add reset count to error stateMika Kuoppala
By default we keep only the error state from first hang. However some sneaky user might have cleared the first error state and we assume mistakenly that it is from first hang. As sometimes this matters, it is better to explicitly store the reset count. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Add reason for capture in error stateMika Kuoppala
We capture error state not only when the GPU hangs but also on other situations as in interrupt errors and in situations where we can kick things forward without GPU reset. There will be log entry on most of these cases. But as error state capture might be only thing we have, if dmesg was not captured. Or as in GEN4 case, interrupt error can trigger error state capture without log entry, the exact reason why capture was made is hard to decipher. v2: Split out the the error code stuff to separate patch (Ben) References: https://bugs.freedesktop.org/show_bug.cgi?id=74193 Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Add error code into error stateMika Kuoppala
commit 011cf577b2531dfbd2254bd9ec147ad71471abaf Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Tue Feb 4 12:18:55 2014 +0000 drm/i915: Generate a hang error code added error code debug into dmesg. Store this also with error state to make matching dmesg logs and error states easier. As we need to have full ring state for error code generation, do full capture always, print hang message into log and then decide if we need to keep the error state. Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Record pid/comm of hanging taskChris Wilson
After finding the guilty batch and request, we can use it to find the process that submitted the batch and then add the culprit into the error state. This is a slightly different approach from Ben's in that instead of adding the extra information into the struct i915_hw_context, we use the information already captured in struct drm_file which is then referenced from the request. v2: Also capture the workaround buffer for gen2, so that we can compare its contents against the intended batch for the active request. v3: Rebase (Mika) v4: Check for null context (Chris) checkpatch warnings fixed Link: http://lists.freedesktop.org/archives/intel-gfx/2013-August/032280.html Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v2) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v4) Acked-by: Ben Widawsky <ben@bwidawsk.net> Cc: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Rely on accurate request tracking for finding hung batchesChris Wilson
In the past, it was possible to have multiple batches per request due to a stray signal or ENOMEM. As a result we had to scan each active object (filtered by those having the COMMAND domain) for the one that contained the ACTHD pointer. This was then made more complicated by the introduction of ppgtt, whereby ACTHD then pointed into the address space of the context and so also needed to be taken into account. This is a fairly robust approach (though the implementation is a little fragile and depends upon the per-generation setup, registers and parameters). However, due to the requirements for hangstats, we needed a robust method for associating batches with a particular request and having that we can rely upon it for finding the associated batch object for error capture. If the batch buffer tracking is not robust enough, that should become apparent quite quickly through an erroneous error capture. That should also help to make sure that the runtime reporting to userspace is robust. It also means that we then report the oldest incomplete batch on each ring, which can be useful for determining the state of userspace at the time of a hang. v2: Use i915_gem_find_active_request (Mika) v3: remove check for ring->get_seqno, split long lines (Ben) v4: check that context is available (Chris) checkpatch warnings fixed Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (v1) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> (v3) Cc: Ben Widawsky <benjamin.widawsky@intel.com> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> (v3) Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Reset vma->mm_list after unbindingChris Wilson
In place of true activity counting, we walk the list of vma associated with an object managing each on the vm's active/inactive list everytime we call move-to-inactive. This depends upon the vma->mm_list being cleared after unbinding, or else we run into difficulty when tracking the object in multiple vm's - we see a use-after free and corruption of the mm_list. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Reviewed-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Streamline VLV forcewake handlingVille Syrjälä
It occured to me that when we're trying to wake up both render and media wells on VLV, we might end up calling the low level force_wake_get/put two times even though one call would be enough. Make that happen by figuring out which wells really need to be woken up based on the forcewake counts. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:Deepak S <deepak.s@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Drop the forcewake count inc/dec around register read on VLVVille Syrjälä
VLV is the only platform where we increment/decrement the forcewake count around register access. Drop the inc/dec on VLV to make the forcewake code a bit more unified. The inc/dec are not necessary since we hold the uncore lock around the whole operation. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Fix VLV forcewake after resetVille Syrjälä
Use the render/media specific forcewake counts to properly restore the forcewake status after a GPU reset on VLV. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Deepak S <deepak.s@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: Perform pageflip using mmio if the GPU is terminally wedgedChris Wilson
After a hang and failed reset, we cannot use the GPU to execute the page flip instructions. Instead we can force a synchronous mmio flip. (Later, we can reduce the synchronicity of the mmio flip by moving some of the delays off to a worker, like the current page flip code; see vblank tasks.) References: https://bugs.freedesktop.org/show_bug.cgi?id=72631 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: assert we're not runtime suspended when accessing registersPaulo Zanoni
I could swear this was already happening in the current code... Also, put the reads and writes in a generic place, so we don't forget it again when we add runtime PM support to new platforms. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-03-05drm/i915: assert force wake is disabled when we runtime suspendPaulo Zanoni
Just to be sure... Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
generated by cgit (git 2.34.1) at 2025-07-15 08:16:10 +0000