- 24 12月, 2014 1 次提交
-
-
由 Dave Airlie 提交于
This reverts commit 355a7018. This had some bad side effects under normal operation, and should have been dropped earlier. Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 16 12月, 2014 1 次提交
-
-
由 Imre Deak 提交于
Atm, we don't disable RPS interrupts and related work items before resetting the GPU. This may interfere with the following GPU initialization and cause RPS interrupts to show up in PM_IIR too early before calling gen6_enable_rps_interrupts() (triggering a WARN there). Solve this by disabling RPS interrupts and flushing any related work items before resetting the GPU. v2: - split out the common parts of the gt suspend and the new gt reset functions (Paulo) v3: - remove the check for UMS, it's a NOP nowadays (Daniel) Reported-by: NHe, Shuang <shuang.he@intel.com> Testcase: igt/gem_reset_stats/ban-render Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86644Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 08 12月, 2014 1 次提交
-
-
由 Dave Airlie 提交于
Otherwise the MST resume paths can hit DPMS paths which hit state checker paths, which hit WARN_ON, because the state checker is inconsistent with the hw. This fixes a bunch of WARN_ON's on resume after undocking. Signed-off-by: NDave Airlie <airlied@redhat.com> Reviewed-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Cc: stable@vger.kernel.org Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 03 12月, 2014 4 次提交
-
-
由 Ville Syrjälä 提交于
On gen4 and earlier the GPU reset also resets the display, so we should protect against concurrent modeset operations. Grab all the modeset locks around the entire GPU reset dance, remebering first ti dislogde any pending page flip to make sure we don't deadlock. Any pageflip coming in between these two steps should fail anyway due to reset_in_progress, so this should be safe. This fixes a lot of failed asserts in the modeset code when there's a modeset racing with the reset. Naturally the asserts aren't happy when the expected state has disappeared. v2: Drop UMS checks, complete pending flips after the reset (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
g33 seems to sit somewhere between the 915/945/965 style and the g4x style. The bits look like g4x, but we still need to do a full reset including display. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
915/945 have the same reset registers as 965, so share the code. Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Ville Syrjälä 提交于
On pre-ctg GPU reset also resets the display hardware. Force a mode restore after the GPU reset, and also re-init clock gating. v2: Use intel_modeset_init_hw() instead of intel_init_clock_gating() in case more relevant stuff gets added there at some point Restore interrupts after the reset as well Tested-by: NKenneth Graunke <kenneth@whitecape.org> Signed-off-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 21 11月, 2014 1 次提交
-
-
由 Thomas Hellstrom 提交于
It happens on occasion that developers of generic user-space applications abuse the dumb buffer API to get hold of drm buffers that they can both mmap() and use for GPU acceleration, using the assumptions that dumb buffers and buffers available for GPU are a) The same type and can be aribtrarily type-casted. b) fully coherent. This patch makes the most widely used drivers warn nicely when that happens, the next step will be to fail. v2: Move drmP.h changes to drm_gem.h. Fix Radeon dumb mmap breakage. Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com> Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Acked-by: NAlex Deucher <alexander.deucher@amd.com> Signed-off-by: NDave Airlie <airlied@redhat.com>
-
- 20 11月, 2014 2 次提交
-
-
由 Daniel Vetter 提交于
Again just complicates gem init functions and makes a general mess out of everything. Good riddance! v2: In my enthusiasm to start removing dri1/ums crud I went overboard a bit and killed parts of hangcheck. Resurrect it. Acked-by: NChris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Chris Wilson 提交于
With the deprecation of UMS, and by association DRI1, we have a tough choice when updating the ring access routines. We either rewrite the DRI1 routines blindly without testing (so likely to be broken) or take the liberty of declaring them no longer supported and remove them entirely. This takes the latter approach. v2: Also remove the DRI1 sarea updates Signed-off-by: NChris Wilson <chris@chris-wilson.co.uk> [danvet: Fix rebase conflicts.] Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 19 11月, 2014 1 次提交
-
-
由 Imre Deak 提交于
After the previous patch RPS disabling doesn't depend any more on the first level interrupts being disabled, so we can move it everywhere earlier. Doing so let's us think about the uninitialization steps afterwards independently of any asynchronous RPS events that can happen atm. It also makes the system/runtime suspend time RPS disabling more uniform. Finally this gets rid of the WARN in intel_suspend_gt_powersave(), which we can hit if a final RPS work runs after we disabled the first level interrupts. Testcase: igt/pm_rpm Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 14 11月, 2014 1 次提交
-
-
由 Jani Nikula 提交于
The block was added for spin_lock_irqsave flags, but since the locking was converted to spin_lock_irq variant, the block is no longer needed. Signed-off-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 08 11月, 2014 1 次提交
-
-
由 Paulo Zanoni 提交于
With this patch, the RPS sequence for runtime suspend/resume is exactly like the sequence for S3 suspend/resume: - flush_delayed_work(&dev_priv->rps.delayed_resume_work) - intel_runtime_pm_disable_interrupts() - intel_suspend_gt_powersave() (suspended) - intel_runtime_pm_enable_interrupts() - intel_enable_gt_powersave() With this, we get rid of WARNs that are currently intermittently triggered by the system-suspend-execbuf subtest of runtime PM. Notice that these WARNs could also be triggered in other ways that involved doing lots of RPM suspend/resume cycles just after a system S3 resume. Testcase: igt/pm_rpm/system-suspend-execbuf Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reference: https://bugs.freedesktop.org/show_bug.cgi?id=82939Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 07 11月, 2014 1 次提交
-
-
由 Imre Deak 提交于
During S4 freeze we don't call intel_suspend_complete(), which would save the gunit HW state, but during S4 thaw/restore events we call intel_resume_prepare() which restores it, thus ending up in a corrupted HW state. Fix this by calling intel_suspend_complete() from the corresponding freeze_late event handler. The issue was introduced in commit 016970be Author: Sagar Kamble <sagar.a.kamble@intel.com> Date: Wed Aug 13 23:07:06 2014 +0530 CC: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: NJani Nikula <jani.nikula@intel.com>
-
- 05 11月, 2014 2 次提交
-
-
由 Paulo Zanoni 提交于
We want to run intel_uncore_early_sanitize() before we touch any registers, because on BDW, when we resume, the FPGA_DBG_RM_NOCLAIM bit is set, so we need to clear it - through intel_uncore_early_sanitize() - before we do anything else. With the current code, we don't clear the bit before our first register access, so we print a WARN complaining about an unclaimed register error. v1: Was called "drm/i915: run intel_uncore_early_sanitize earlier on resume" v2: Was called "drm/i915: run intel_uncore_early_sanitize earlier on resume on non-VLV" v3: This one, on top of the intel_resume_prepare() rework. v4: Rebase. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Paulo Zanoni 提交于
Because, really, the abstraction is not working for us. It is nice for VLV, but doesn't add anything useful on SNB/HSW/BDW. We want to change this code due to a recently-discovered bug, but we can't seem to find a nice solution that repects the current abstraction. So let's kill intel_resume_prepare() and its friends, and add an equivalent implementation to both its callers. Also, look at the diffstat! v2: - Rebase. Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 10月, 2014 18 次提交
-
-
由 Imre Deak 提交于
This will hopefully make it easier to navigate the code without the need to consult the full PM documentation. v2: - add a comment that the freeze handler is also called after rebooting - add a comment that the thaw handler is also called to recover from errors (Ville) - add the PM event names (PMSG_THAW etc.) for reference (Ville) - add comments that s0ix can be handled both via system and runtime suspend (Ville) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
By now we handle switcheroo and legacy suspend/resume the same way, so no need to keep separate functions for them. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
The suspend_late handler saves some registers and powers off the device, so it doesn't have a big overhead. Calling it at S4 poweroff_late time makes the power off handling identical to the S3 suspend and S4 freeze handling, so do this for consistency. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
By now the S4 freeze/thaw and S3 suspend/resume events are handled the same way, so we can rename the freeze/thaw internal helpers to suspend/resume accordingly to make clearer what the helpers do. Also rename i915_resume_early to i915_drm_resume_early aligning it with the rest of the helper names. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
The S3 and S4 events are now handled the same way internally, there is no need to keep separate wrapper functions around them. Simply reuse the suspend/resume versions everywhere. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
We already disable everything during S4 freeze, except the PCI device itself. There is no reason why we couldn't disable that too and doing so allows us to unify these handlers in the next patch with the corresponding S3 suspend/resume handlers. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
To avoid processing hotplug events we disable connector polling for the duration of S3 suspend. We also disable it for S4 freeze, and keep it disabled after S4 thaw. This won't prevent though hotplug processing, since we re-enable interrupts anyway. There is also no need to prevent it at that time, since we reinitialize everything during thaw, so the device is in a consistent state. So to simplify things enable polling during thaw, which will allow us to handle S4 thaw the same way as S3 resume in an upcoming patch. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
Checking for GT faults is not specific in any way to S4 thaw, so do it also during S3 resume, S4 restore and driver load time. This allows us to unify the Sx handlers in an upcoming patch. v2: - move the check to intel_uncore_early_sanitize(), so we check at driver load time too (Chris) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
The logic to skip restoring GTT mappings was added to speed up suspend/resume, but not on old GENs where not restoring them caused problems. The check for old GENs is based on the existence of OpRegion, but this doesn't work since opregion is initialized only after the check. So we end up always restoring the mappings. On my BYT - which has OpRegion - skipping restoring the mappings during suspend doesn't work, I get a GPU hang after resume. Also the logic of when to allow the optimization during S4 is reversed: we should allow it during S4 thaw but not during S4 restore, but atm we have it the other way around in the code. Since correctness wins over optimal code and since the optimization wasn't used anyway I decided not to try to fix it at this point, but just remove it. This allows us to unify the S3 and S4 handlers in the following patches. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
If the device is suspended already through the switcheroo interface we shouldn't suspend it again or resume it after suspend. We have the corresponding check for S3 suspend already, add it for all the other S3 and S4 handlers. Also move the check from i915_resume_early() to i915_resume_legacy(), so that it's done in the high level handler for all PM events. v2: - fix the resume path too, we don't need to special case there DRM_SWITCH_POWER_OFF with the device being enabled (in which case we'd have to disable the device), since that never happens (Ville) Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
During switcheroo/legacy suspend we don't call the suspend_late handler but when resuming afterwards we call resume_early. This happened to work so far, since suspend_late only disabled the PCI device. This changed in commit 016970be Author: Sagar Kamble <sagar.a.kamble@intel.com> Date: Wed Aug 13 23:07:06 2014 +0530 drm/i915: Sharing platform specific sequence between runtime and system susp after which we also saved/restored the VLV Gunit HW state in suspend_late/resume_early. So now since we don't save the state during suspend a following resume will restore a corrupted state. Fix this by calling the suspend_late handler during both switcheroo and legacy suspend. CC: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NSagar Kamble <sagar.a.kamble@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
i915_suspend() is called from the DRM legacy S3 suspend/S4 freeze paths and the switcheroo suspend path. For switcheroo we only ever need to perform a full suspend (PM_EVENT_SUSPEND) and for the DRM legacy path we can handle the S4 freeze (PM_EVENT_FREEZE) the same way as S3 suspend. The only difference atm between suspend and freeze is that during freeze we don't disable the PCI device, but there is no reason why we can't do so. So unify the two cases to reduce complexity. Note that for the DRM legacy case the thaw event is not handled, so we disable the display before creating the hibernation image and it won't get re-enabled until reboot. We could fix this leaving the display enabled for the image creation/writing (if we care enough about UMS), but this can be done as a follow-up. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
This is needed by an upcoming patch fixing the switcheroo/legacy suspend paths. No functional change. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
During S4 freeze we don't call intel_suspend_complete(), which would save the gunit HW state, but during S4 thaw/restore events we call intel_resume_prepare() which restores it, thus ending up in a corrupted HW state. Fix this by calling intel_suspend_complete() from the corresponding freeze_late event handler. The issue was introduced in commit 016970be Author: Sagar Kamble <sagar.a.kamble@intel.com> Date: Wed Aug 13 23:07:06 2014 +0530 CC: Sagar Kamble <sagar.a.kamble@intel.com> Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Imre Deak 提交于
The legacy DRM suspend logic (effective in UMS) doesn't handle any S4 thaw events so we don't need to care about it either. Only S3 suspend and S4 freeze events are handled. Leave an assert behind to be sure. Signed-off-by: NImre Deak <imre.deak@intel.com> Reviewed-by: NVille Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Damien Lespiau 提交于
IS_ULT() wasn't taking into account SKL so we had a warn with SPT-LP. We don't realy need those checks here, and as we don't need to introduce IS_SKL_ULT/ULX() at the moment, let's just drop them. 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 提交于
No need to add the BDW pci ULT/ULX checks inside a if (IS_HASWELL(dev)) code path. 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>
-
- 03 10月, 2014 1 次提交
-
-
由 Daniel Vetter 提交于
It's the new world order! Not going full monty on these here and rolling this out throughout the subsequent call chains since this is just for the kerneldoc. Later on we can go more crazy, especially once we've embedded drm_device correctly. v2: Also frob the runtime_pm functions ... Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 01 10月, 2014 2 次提交
-
-
由 Daniel Vetter 提交于
This seems to have been accidentally lost in commit be62acb4 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 30 16:19:28 2013 +0300 drm/i915: ban badly behaving contexts Without this real gpu hangs only log output at info level, which gets filtered away by piglit's testrunner. v2: Tune down to notice level. Note that we need to add drm/i915 so that at least the automatic igt dmesg filtering still picks it up. v3: git add and lack of coffee don't mix well. v4: Message is in between hw and sw reset, so switch verb to continuous form. v5: Use i915_stop_rings_allow_warn for consistency. For Chris' case of injecting lots of hangs I guess we need to revamp this all anyway when merging. For now this should plug the regression for piglit testing mesa. v6: Make it compile (Mika). Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Kenneth Graunke <kenneth@whitecape.org> Reported-by: NKenneth Graunke <kenneth@whitecape.org> Reviewed-by: NChris Wilson <chris@chris-wilson.co.uk> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
-
由 Daniel Vetter 提交于
Another layer of indirection for just an lpt-only w/a is a bit excessive. Reduce it. This was added in commit 7d708ee4 Author: Imre Deak <imre.deak@intel.com> Date: Wed Apr 17 14:04:50 2013 +0300 drm/i915: HSW: allow PCH clock gating for suspend Cc: Imre Deak <imre.deak@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com> Reviewed-by: NImre Deak <imre.deak@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
- 24 9月, 2014 3 次提交
-
-
由 Satheeshakrishna M 提交于
This patch implements detection of SPT and SPT-LP PCH devices. v2: Added HAS_PCH_SPT macro Reviewed-by: NRodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: NSatheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Daisy Sun 提交于
Enable FBC feature on Skylake Issue: VIZ-3788 Reviewed-by: NThomas Wood <thomas.wood@intel.com> Signed-off-by: NDaisy Sun <daisy.sun@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-
由 Satheeshakrishna M 提交于
Adding new macro IS_SKYLAKE for skylake specific implementation. Reviewed-by: NThomas Wood <thomas.wood@intel.com> Signed-off-by: NSatheeshakrishna M <satheeshakrishna.m@intel.com> Signed-off-by: NDamien Lespiau <damien.lespiau@intel.com> Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
-