aboutsummaryrefslogtreecommitdiffstats
path: root/drivers/gpu
Commit message (Collapse)AuthorAge
* Merge tag 'drm-intel-fixes-2013-12-18' of ↵Dave Airlie2013-12-22
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Besides the 2 fixes for tricky corner cases in gem from Chris I've promised already two patche from Paulo to fix pc8 warnings (both ported from -next, bug report from Dave Jones) and one patch from to fix vga enable/disable on snb+. That one is a really old bug, but apparently it can cause machine hangs if you try hard enough with vgacon/efifb handover. * tag 'drm-intel-fixes-2013-12-18' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: Use the correct GMCH_CTRL register for Sandybridge+ drm/i915: get a PC8 reference when enabling the power well drm/i915: change CRTC assertion on LCPLL disable drm/i915: Fix erroneous dereference of batch_obj inside reset_status drm/i915: Prevent double unref following alloc failure during execbuffer
| * drm/i915: Use the correct GMCH_CTRL register for Sandybridge+Chris Wilson2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The GMCH_CTRL register (or MGCC in the spec) is at a different address on Sandybridge, and the address to which we currently write to is undefined. These stray writes appear to upset (hard hang) my Ivybridge machine whilst it is in UEFI mode. Note that the register is still marked as locked RO on Sandybridge, so vgaarb is still dysfunctional. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: get a PC8 reference when enabling the power wellPaulo Zanoni2013-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In the current code, at haswell_modeset_global_resources, first we decide if we want to enable/disable the power well, then we decide if we want to enable/disable PC8. On the case where we're enabling PC8 this works fine, but on the case where we disable PC8 due to a non-eDP monitor being enabled, we first enable the power well and then disable PC8. Although wrong, this doesn't seem to be causing any problems now, and we don't even see anything in dmesg. But the patches for runtime D3 turn this problem into a real bug, so we need to fix it. This fixes the "modeset-non-lpsp" subtest from the "pm_pc8" test from intel-gpu-tools. v2: - Rebase (i915_disable_power_well). v3: - More reabase. v4: - Rebase on top of -fixes instead of -nightly. This is commit d62292c8f778772d1b6ec125d461c8c16fdc0417 in -next, but we need it in -fixes to address Dave's report. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@gmail.com> Reported-by: Dave Jones <davej@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: change CRTC assertion on LCPLL disablePaulo Zanoni2013-12-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, PC8 is enabled at modeset_global_resources, which is called after intel_modeset_update_state. Due to this, there's a small race condition on the case where we start enabling PC8, then do a modeset while PC8 is still being enabled. The racing condition triggers a WARN because intel_modeset_update_state will mark the CRTC as enabled, then the thread that's still enabling PC8 might look at the data structure and think that PC8 is being enabled while a pipe is enabled. Despite the WARN, this is not really a bug since we'll wait for the PC8-enabling thread to finish when we call modeset_global_resources. The spec says the CRTC cannot be enabled when we disable LCPLL, so we had a check for crtc->base.enabled. If we change to crtc->active we will still prevent disabling LCPLL while the CRTC is enabled, and we will also prevent the WARN above. This is a replacement for the previous patch named "drm/i915: get/put PC8 when we get/put a CRTC" Testcase: igt/pm_pc8/modeset-lpsp-stress-no-wait Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> (cherry picked from commit 798183c54799fbe1e5a5bfabb3a8c0505ffd2149 from -next due to Dave's report.) Reported-by: Dave Jones <davej@redhat.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Fix erroneous dereference of batch_obj inside reset_statusChris Wilson2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the rings may be processed and their requests deallocated in a different order to the natural retirement during a reset, /* Whilst this request exists, batch_obj will be on the * active_list, and so will hold the active reference. Only when this * request is retired will the the batch_obj be moved onto the * inactive_list and lose its active reference. Hence we do not need * to explicitly hold another reference here. */ is violated, and the batch_obj may be dereferenced after it had been freed on another ring. This can be simply avoided by processing the status update prior to deallocating any requests. Fixes regression (a possible OOPS following a GPU hang) from commit aa60c664e6df502578454621c3a9b1f087ff8d25 Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Wed Jun 12 15:13:20 2013 +0300 drm/i915: find guilty batch buffer on ring resets Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> [danvet: Add the code comment Chris supplied.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * drm/i915: Prevent double unref following alloc failure during execbufferChris Wilson2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whilst looking up the objects required for an execbuffer, an untimely allocation failure in creating the vma results in the object being unreferenced from two lists. The ownership during the lookup is meant to be moved from the list of objects being looked to the vma, and this double unreference upon error results in a use-after-free. Fixes regression from commit 27173f1f95db5e74ceb35fe9a2f2f348ea11bac9 Author: Ben Widawsky <ben@bwidawsk.net> Date: Wed Aug 14 11:38:36 2013 +0200 drm/i915: Convert execbuf code to use vmas Based on the fix by Ben Widawsky. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ben Widawsky <ben@bwidawsk.net> Cc: stable@vger.kernel.org [danvet: Bikeshed the crucial comment above the ownership transfer as discussed on irc.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | Merge branch 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2013-12-22
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes - fix for a long standing corruption bug on some Trinity/Richland parts. - Stability fix for cayman dpm - audio fixes for dce6+ * 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux: drm/radeon: fix asic gfx values for scrapper asics drm/radeon: check for 0 count in speaker allocation and SAD code drm/radeon/dpm: disable ss on Cayman drm/radeon/dce6: set correct number of audio pins
| * | drm/radeon: fix asic gfx values for scrapper asicsAlex Deucher2013-12-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes gfx corruption on certain TN/RL parts. bug: https://bugs.freedesktop.org/show_bug.cgi?id=60389 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| * | drm/radeon: check for 0 count in speaker allocation and SAD codeAlex Deucher2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If there is no speaker allocation block or SAD block, bail early. bug: https://bugs.freedesktop.org/show_bug.cgi?id=72283 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| * | drm/radeon/dpm: disable ss on CaymanAlex Deucher2013-12-17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Spread spectrum seems to cause hangs when dynamic clock switching is enabled. Disable it for now. This does not affect performance or the amount of power saved. Tracked down by Martin Andersson. bug: https://bugs.freedesktop.org/show_bug.cgi?id=69723 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
| * | drm/radeon/dce6: set correct number of audio pinsAlex Deucher2013-12-17
| | | | | | | | | | | | | | | | | | | | | DCE6.0, 8.x has 6 DCE6.1 has 4 Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/ttm: Fix swapin regressionThomas Hellstrom2013-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | Commit "drm/ttm: Don't move non-existing data" didn't take the swapped-out corner case into account. This patch corrects that. Fixes blank screen after attempted suspend / hibernate on vmwgfx. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | gpu: fix qxl missing crc32_leRandy Dunlap2013-12-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix build error: qxl uses crc32 functions so it needs to select CRC32. Also use angle quotes around a kernel header file name. drivers/built-in.o: In function `qxl_display_read_client_monitors_config': (.text+0x19d754): undefined reference to `crc32_le' Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm/edid: add quirk for BPC in Samsung NP700G7A-S01PL notebookRafał Miłecki2013-12-16
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug in EDID was exposed by: commit eccea7920cfb009c2fa40e9ecdce8c36f61cab66 Author: Alex Deucher <alexander.deucher@amd.com> Date: Mon Mar 26 15:12:54 2012 -0400 drm/radeon/kms: improve bpc handling (v2) Which resulted in kind of regression in 3.5. This fixes https://bugs.freedesktop.org/show_bug.cgi?id=70934 Signed-off-by: Rafał Miłecki <zajec5@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* | Merge branch 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux ↵Dave Airlie2013-12-16
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | into drm-next A single ttm vm fix. * 'ttm-fixes-3.13' of git://people.freedesktop.org/~thomash/linux: drm/ttm: Fix accesses through vmas with only partial coverage
| * | drm/ttm: Fix accesses through vmas with only partial coverageThomas Hellstrom2013-12-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | VMAs covering a bo but that didn't start at the same address space offset as the bo they were mapping were incorrectly generating SEGFAULT errors in the fault handler. Reported-by: Joseph Dolinak <kanilo2@yahoo.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Cc: stable@vger.kernel.org
* | | drm/nouveau: only runtime suspend by default in optimus configurationIlia Mirkin2013-12-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The intent was to only enable it by default for optimus, e.g. see the runtime_idle callback. The suspend callback may be called directly, e.g. as a result of nouveau_crtc_set_config. Reported-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Tested-by: Stefan Lippers-Hollmann <s.l-h@gmx.de> Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | drm: don't double-free on driver load errorIlia Mirkin2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All instances of drm_dev_register are followed by drm_dev_free on failure. Don't free dev->control/render/primary on failure, as they will be freed by drm_dev_free since commit 8f6599da8e (drm: delay minor destruction to drm_dev_free()). Instead unplug them. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Reported-and-tested-by: Bruno Prémont <bonbons@linux-vserver.org> Reviewed-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* | | Merge branch 'vmwgfx-fixes-3.13' of ↵Dave Airlie2013-12-12
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~thomash/linux into drm-fixes Part of a driver stack fix that fixes surface overcommiting on single execbuf calls. * 'vmwgfx-fixes-3.13' of git://people.freedesktop.org/~thomash/linux: drm/vmwgfx: Add max surface memory param
| * | | drm/vmwgfx: Add max surface memory paramJakob Bornecrantz2013-12-09
| |/ / | | | | | | | | | | | | | | | | | | | | | Userspace uses this to workaround overcommit issues by flushing the command stream early. Signed-off-by: Jakob Bornecrantz <jakob@vmware.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
* | | Revert "drm/radeon: Implement radeon_pci_shutdown"Alex Deucher2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This causes a race condition between drm_dev_unregister() and pci_driver.shutdown at shutdown or driver unload time. We need to revisit how to properly support kexec within the drm. This reverts commit 846ae41ae99d314bf2a02784152208a6ddf7eddc.
* | | drm/radeon: add missing display tiling setup for olandAlex Deucher2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | Fixes improperly set up display params for 2D tiling on oland. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | | drm/radeon: fix typo in cik_copy_dmaChristian König2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Otherwise we end up with a rather strange looking result. Signed-off-by: Christian König <christian.koenig@amd.com> Tested-by: Tom Stellard <thomas.stellard@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/radeon/cik: plug in missing blit callbackAlex Deucher2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I implemented support for this, but forget to hook up the callback so the driver can actually use it. On asics with a dedicated DMA engine, we use the DMA engine for buffer migration so this is just for testing purposes. Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/radeon/dpm: Fix hwmon crashMartin Andersson2013-12-12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit ec39f64bba3421c2060fcbd1aeb6eec81fe0a42d (drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups) converted one usage of dev_get_drvdata, but there were two more. bug: https://bugs.freedesktop.org/show_bug.cgi?id=72457 Signed-off-by: Martin Andersson <g02maran@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
* | | drm/radeon: Fix sideport problems on certain RS690 boardsAlex Deucher2013-12-12
| |/ |/| | | | | | | | | | | | | | | | | | | | | | | Some RS690 boards with 64MB of sideport memory show up as having 128MB sideport + 256MB of UMA. In this case, just skip the sideport memory and use UMA. This fixes rendering corruption and should improve performance. bug: https://bugs.freedesktop.org/show_bug.cgi?id=35457 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
* | Merge branch 'drm-tda998x-3.12-fixes' of ↵Dave Airlie2013-12-11
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://ftp.arm.linux.org.uk/~rmk/linux-cubox into drm-fixes These four patches fix a few issues discovered since the initial merge, which have been reviewed by Rob Clark and Thierry Reding. * 'drm-tda998x-3.12-fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-cubox: DRM: Armada: prime refcounting bug fix DRM: Armada: fix printing of phys_addr_t/dma_addr_t DRM: Armada: destroy framebuffer after helper DRM: Armada: implement lastclose() for fbhelper
| * | DRM: Armada: prime refcounting bug fixRussell King2013-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 011c2282c74d changed the way refcounting on imported dma_bufs works, and this hadn't been spotted while forward-porting Armada. Reflect the changes in that commit into the Armada driver. Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | DRM: Armada: fix printing of phys_addr_t/dma_addr_tRussell King2013-12-10
| | | | | | | | | | | | | | | | | | | | | | | | These can be 64-bit quantities, so fix them up appropriately. Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | DRM: Armada: destroy framebuffer after helperRussell King2013-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Destroy the framebuffer only after the helper, since the helper may still be referencing the framebufer at this point. Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
| * | DRM: Armada: implement lastclose() for fbhelperRussell King2013-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | Call drm_fb_helper_restore_fbdev_mode() upon last close so that in the event of the X server crashing, we have some kind of mode restored. Reviewed-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
* | | Merge tag 'drm-intel-fixes-2013-12-11' of ↵Dave Airlie2013-12-11
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://people.freedesktop.org/~danvet/drm-intel into drm-fixes Just a bunch of regression fixes plus a few patches for long-standing issues in gem corner-cases that we've hunted down in the past weeks. Since apparently people hit those in the wild (and we also have nice igts for them) I've opted for -fixes and cc: stable. There's 1-2 things oustanding on top of this where I'm still waiting on confirmation from testing, but nothing really scary. * tag 'drm-intel-fixes-2013-12-11' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915: don't update the dri1 breadcrumb with modesetting drm/i915: Repeat eviction search after idling the GPU drm/i915: Fix use-after-free in do_switch drm/i915: fix pm init ordering drm/i915: Hold mutex across i915_gem_release drm/i915: Skip clock checks on BDW drm/i915: Do not clobber config status after a forced restore of hw state drm/i915: Take modeset locks around intel_modeset_setup_hw_state()
| * | | drm/i915: don't update the dri1 breadcrumb with modesettingDaniel Vetter2013-12-11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The update is horribly racy since it doesn't protect at all against concurrent closing of the master fd. And it can't really since that requires us to grab a mutex. Instead of jumping through hoops and offloading this to a worker thread just block this bit of code for the modesetting driver. Note that the race is fairly easy to hit since we call the breadcrumb function for any interrupt. So the vblank interrupt (which usually keeps going for a bit) is enough. But even if we'd block this and only update the breadcrumb for user interrupts from the CS we could hit this race with kms/gem userspace: If a non-master is waiting somewhere (and hence has interrupts enabled) and the master closes its fd (probably due to crashing). v2: Add a code comment to explain why fixing this for real isn't really worth it. Also improve the commit message a bit. v3: Fix the spelling in the comment. Reported-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru> Cc: Eugene Shatokhin <eugene.shatokhin@rosalab.ru> Cc: stable@vger.kernel.org Acked-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Eugene Shatokhin <eugene.shatokhin@rosalab.ru> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Repeat eviction search after idling the GPUChris Wilson2013-12-10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With the advent of hw context support, we gained some objects that are pinned for the duration of their request. That is we can make aperture space available by idling the GPU and in the process performing a context switch back to the always-pinned default context. As such, we should not conclude that there is no space in the aperture for the current object until we have unpinned any such context objects. Note that we also have the problem of outstanding pageflips preventing eviction of their framebuffer objects to resolve. Testcase: igt/gem_ctx_exec/eviction Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=72507 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: lu hua <huax.lu@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Fix use-after-free in do_switchDaniel Vetter2013-12-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | So apparently under ridiculous amounts of memory pressure we can get into trouble in do_switch when we try to move the old hw context backing storage object onto the active lists. With list debugging enabled that usually results in us chasing a poisoned pointer - which means we've hit upon a vma that has been removed from all lrus with list_del (and then deallocated, so it's a real use-after free). Ian Lister has done some great callchain chasing and noticed that we can reenter do_switch: i915_gem_do_execbuffer() i915_switch_context() do_switch() from = ring->last_context; i915_gem_object_pin() i915_gem_object_bind_to_gtt() ret = drm_mm_insert_node_in_range_generic(); // If the above call fails then it will try i915_gem_evict_something() // If that fails it will call i915_gem_evict_everything() ... i915_gem_evict_everything() i915_gpu_idle() i915_switch_context(DEFAULT_CONTEXT) Like with everything else where the shrinker or eviction code can invalidate pointers we need to reload relevant state. Note that there's no need to recheck whether a context switch is still required because: - Doing a switch to the same context is harmless (besides wasting a bit of energy). - This can only happen with the default context. But since that one's pinned we'll never call down into evict_everything under normal circumstances. Note that there's a little driver bringup fun involved namely that we could recourse into do_switch for the initial switch. Atm we're fine since we assign the context pointer only after the call to do_switch at driver load or resume time. And in the gpu reset case we skip the entire setup sequence (which might be a bug on its own, but definitely not this one here). Cc'ing stable since apparently ChromeOS guys are seeing this in the wild (and not just on artificial stress tests), see the reference. Note that in upstream code doesn't calle evict_everything directly from evict_something, that's an extension in this product branch. But we can still hit upon this bug (and apparently we do, see the linked backtraces). I've noticed this while trying to construct a testcase for this bug and utterly failed to provoke it. It looks like we need to driver the system squarly into the lowmem wall and provoke the shrinker to evict the context object by doing the last-ditch evict_everything call. Aside: There's currently no means to get a badly-fragmenting hw context object away from a bad spot in the upstream code. We should fix this by at least adding some code to evict_something to handle hw contexts. References: https://code.google.com/p/chromium/issues/detail?id=248191 Reported-by: Ian Lister <ian.lister@intel.com> Cc: Ian Lister <ian.lister@intel.com> Cc: stable@vger.kernel.org Cc: Ben Widawsky <benjamin.widawsky@intel.com> Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: Bloomfield, Jon <jon.bloomfield@intel.com> Tested-by: Rafael Barbalho <rafael.barbalho@intel.com> Reviewed-by: Ian Lister <ian.lister@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: fix pm init orderingDaniel Vetter2013-12-06
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Shovel a bit more of the the code into the setup function, and call it earlier. Otherwise lockdep is unhappy since we cancel the delayed resume work before it's initialized. While at it also shovel the pc8 setup code into the same functions. I wanted to also ditch the header declaration of the hws pc8 functions, but for unfathomable reasons that stuff is in intel_display.c instead of intel_pm.c. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71980 Tested-by: Guo Jinxian <jinxianx.guo@intel.com> Reviewed-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Hold mutex across i915_gem_releaseChris Wilson2013-12-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Inorder to serialise the closing of the file descriptor and its subsequent release of client requests with i915_gem_free_request(), we need to hold the struct_mutex in i915_gem_release(). Failing to do so has the potential to trigger an OOPS, later with a use-after-free. Testcase: igt/gem_close_race Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=70874 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=71029 Reported-by: Eric Anholt <eric@anholt.net> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Skip clock checks on BDWVille Syrjälä2013-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We don't have clock state readout support for DDI, so skip the pipe config clock checks on all DDI 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>
| * | | drm/i915: Do not clobber config status after a forced restore of hw stateChris Wilson2013-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We call intel_modeset_setup_hw_state() along two paths, driver load/resume and after a lid event notification. During initialisation of the driver, it is imperative that we reset the config state. This correctly sets up the initial connector statuses and prepares the hardware for a thorough probing. However, during a lid event, we only want to undo the damage caused by the bios by resetting our last known mode. In this cirumstance, we do not want to clobber our desired state. In order to try and keep sanity between the config state and our own tracking, do the drm_mode_config_reset() first along the load/resume paths before reading out the hw state and apply any definite known corrections. v2: "As discussed on irc I don't think we should force the connector state to anything here: Imo connector->status should reflect what we believe to be the true output connection state, whereas connector->encoder reflects whether this connector is wired up to a pipe. And since we no longer reject modeset on disconnected connectors and never nuked the pipe if the connector gets disconnected there's no reason for that - such policy is userspace's job. This regression has been introduced in commit 2e9388923e83bc4e2726f170a984621f1d582e77 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Oct 11 20:08:24 2012 +0200 drm/i915/crt: explicitly set up HOTPLUG_BITS on resume" so sayeth Daniel. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org (v3.8 and later) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915: Take modeset locks around intel_modeset_setup_hw_state()Ville Syrjälä2013-12-03
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some lower level things get angry if we don't have modeset locks during intel_modeset_setup_hw_state(). Actually the resume and lid_notify codepaths alreday hold the locks, but the init codepath doesn't, so fix that. Note: This slipped through since we only disable pipes if the plane/pipe linking doesn't match. Which is only relevant on older gen3 mobile machines, if the BIOS fails to set up our preferred linking. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: stable@vger.kernel.org Tested-and-reported-by: Paul Bolle <pebolle@tiscali.nl> [danvet: Add note now that I could confirm my theory with the log files Paul Bolle provided.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | Merge branch 'bdw-fixes' of git://people.freedesktop.org/~danvet/drm-intel ↵Dave Airlie2013-12-11
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes As promised bdw fixes come separate for now. Just a few minior things. * 'bdw-fixes' of git://people.freedesktop.org/~danvet/drm-intel: drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwell drm/i915/bdw: Limit GTT to 2GB drm/i915/bdw: Add comment about gen8 HWS PGA drm/i915/bdw: Free correct number of ppgtt pages drm/i915/bdw: Do gen6 style reset for gen8 drm/i915/bdw: GEN8 backlight support drm/i915/bdw: Add BDW to ULT macro
| * | | drm/i915/bdw: PIPE_[BC] I[ME]R moved to powerwellBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pipe B and pipe C interrupt mask and enable registers are now part of the pipe, so disabling the pipe power wells will lost the contests of the registers. Art totally debugged this one! v2: Use the irq_lock to clarify code, and prevent future bugs (Daniel) Cc: Art Runyan <arthur.j.runyan@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> [danvet: Make sparse happy.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915/bdw: Limit GTT to 2GBBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because of the way in which we're allocating the pages for the Aliasing PPGTT, we cannot actually successfully alloc enough space for anything greater than 2GB. Instead of a quick hack to fix this, we should defer until we have the real solution in place (allocating much less contiguous space). This wasn't found sooner because we didn't not have any systems supporting more than a 2GB GTT. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915/bdw: Add comment about gen8 HWS PGABen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This confused me some many times that I think it is appropriate to add a small comment to instruct the reader of the code that it is indeed doing what it is supposed to do. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915/bdw: Free correct number of ppgtt pagesBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I am unclear how this got messed up in the shuffle, but it did. Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915/bdw: Do gen6 style reset for gen8Ben Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch existed before, but was lost over time. Note that reset is still somewhat problematic in my limited testing (ie. module_reload will not pass) but it can be disabled with a module parameter, and support should be considered preliminary anyway. Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915/bdw: GEN8 backlight supportBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to Haswell the CPU control register for backlight (BLC_PWM_CPU_CTL) toggled the PCH baclight pin for us. This made some sense as there was no pin on the CPU. With Haswell came the introduction of a CPU backlight pin, but the interface was still controlled by software with the same mechnism. Behind the scenes, hardware did all the dirty work for us. Broadwell no longer provides this for free. If we want to use the PCH backlight pin [1] then we have to set the override bit BLC_PWM_PCH_CTL1 and program BLC_PWM_PCH_CTL2 for the PWM values. This patch implements that. This patch is compile tested only, and given that I rarely if ever touch this code, careful review is welcome. [1] According to Art, we know of no devices that exist which use the CPU pin (and remember it has existed already on HSW). If such a device does exist, we'll have to handle it properly - this is left as TODO until then. v2: Drop the abstraction prep patch, as a bigger backlight overhaul is in the works, and do just the mimimal bdw enabling now. (by Jani) CC: Art Runyan <arthur.j.runyan@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
| * | | drm/i915/bdw: Add BDW to ULT macroBen Widawsky2013-11-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For what we care about ULT and ULX are interchangeable. We know of 3 types of pciids for these cases. I am not sure if at some point we will need to distinguish ULT and ULX. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Ben Widawsky <ben@bwidawsk.net> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
* | | | Merge branch 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie2013-12-04
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | into drm-fixes Some additional fixes for 3.13. Regression fixes for audio and hw_i2c, vram fix for some SI PX cards, race fix in the hwmon code, and a few other odds and ends. * 'drm-fixes-3.13' of git://people.freedesktop.org/~agd5f/linux: drm/radeon/atom: fix bus probes when hw_i2c is set (v2) drm/radeon: fix null pointer dereference in dce6+ audio code drm/radeon: fixup bad vram size on SI drm/radeon: fix VGT_GS_INSTANCE_CNT register drm/radeon: Fix a typo in Cayman and Evergreen registers drm/radeon/dpm: simplify state adjust logic for NI drm/radeon: add radeon_vm_bo_update trace point drm/radeon: add VMID allocation trace point drm/radeon/dpm: Convert to use devm_hwmon_register_with_groups drm/radeon: program DCE2 audio dto just like DCE3 drm/radeon: fix typo in fetching mpll params
| * | | | drm/radeon/atom: fix bus probes when hw_i2c is set (v2)Alex Deucher2013-12-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When probing the bus, we need to set the byte count to 0 rather than 1. v2: Don't count the first byte. bug: https://bugzilla.kernel.org/show_bug.cgi?id=66241 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org