summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2014-10-06drm/radeon/px: fix module unloadAlex Deucher1-2/+9
commit 2e97140dd58cab8772bf77d73eabda213e45202d upstream. Use the new vga_switcheroo_fini_domain_pm_ops function to unregister the pm ops. Based on a patch from: Pali Rohár <pali.rohar@gmail.com> bug: https://bugzilla.kernel.org/show_bug.cgi?id=84431 Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/nouveau/runpm: fix module unloadAlex Deucher1-0/+9
commit 53beaa01e0fe8e4202f43485a03b32fcf5dfea74 upstream. Use the new vga_switcheroo_fini_domain_pm_ops function to unregister the pm ops. Based on a patch from: Pali Rohár <pali.rohar@gmail.com> bug: https://bugzilla.kernel.org/show_bug.cgi?id=84431 Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06vgaswitcheroo: add vga_switcheroo_fini_domain_pm_opsAlex Deucher1-0/+6
commit 766a53d059d1500c9755c8af017bd411bd8f1b20 upstream. Drivers should call this on unload to unregister pmops. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=84431 Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06PCI: Add pci_ignore_hotplug() to ignore hotplug events for a deviceBjorn Helgaas2-0/+2
commit b440bde74f043c8ec31081cb59c9a53ade954701 upstream. Powering off a hot-pluggable device, e.g., with pci_set_power_state(D3cold), normally generates a hot-remove event that unbinds the driver. Some drivers expect to remain bound to a device even while they power it off and back on again. This can be dangerous, because if the device is removed or replaced while it is powered off, the driver doesn't know that anything changed. But some drivers accept that risk. Add pci_ignore_hotplug() for use by drivers that know their device cannot be removed. Using pci_ignore_hotplug() tells the PCI core that hot-plug events for the device should be ignored. The radeon and nouveau drivers use this to switch between a low-power, integrated GPU and a higher-power, higher-performance discrete GPU. They power off the unused GPU, but they want to remain bound to it. This is a reimplementation of f244d8b623da ("ACPIPHP / radeon / nouveau: Fix VGA switcheroo problem related to hotplug") but extends it to work with both acpiphp and pciehp. This fixes a problem where systems with dual GPUs using the radeon drivers become unusable, freezing every few seconds (see bugzillas below). The resume of the radeon device may also fail, e.g., This fixes problems on dual GPU systems where the radeon driver becomes unusable because of problems while suspending the device, as in bug 79701: [drm] radeon: finishing device. radeon 0000:01:00.0: Userspace still has active objects ! radeon 0000:01:00.0: ffff8800cb4ec288 ffff8800cb4ec000 16384 4294967297 force free ... WARNING: CPU: 0 PID: 67 at /home/apw/COD/linux/drivers/gpu/drm/radeon/radeon_gart.c:234 radeon_gart_unbind+0xd2/0xe0 [radeon]() trying to unbind memory from uninitialized GART ! or while resuming it, as in bug 77261: radeon 0000:01:00.0: ring 0 stalled for more than 10158msec radeon 0000:01:00.0: GPU lockup ... radeon 0000:01:00.0: GPU pci config reset pciehp 0000:00:01.0:pcie04: Card not present on Slot(1-1) radeon 0000:01:00.0: GPU reset succeeded, trying to resume *ERROR* radeon: dpm resume failed radeon 0000:01:00.0: Wait for MC idle timedout ! Link: https://bugzilla.kernel.org/show_bug.cgi?id=77261 Link: https://bugzilla.kernel.org/show_bug.cgi?id=79701 Reported-by: Shawn Starr <shawn.starr@rogers.com> Reported-by: Jose P. <lbdkmjdf@sharklasers.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Acked-by: Rajat Jain <rajatxjain@gmail.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Acked-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon/cik: use a separate counter for CP init timeoutAlex Deucher1-2/+2
commit 370ce45b5986118fa496dddbcd7039e1aa1a418f upstream. Otherwise we may fail to init the second compute ring. Noticed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon/dpm: fix resume on mullinsAlex Deucher1-7/+21
commit 39da038479a81a35a7f8af3ab2c90effd5c8eff1 upstream. Need to properly disable nb dpm on dpm disable. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: don't reset dma on r6xx-evergreen initAlex Deucher1-9/+0
commit c1789a2e66a4209fe5035eca11fdd729b2ffdd82 upstream. Otherwise we may lose the DMA golden settings which can lead to hangs, etc. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: don't reset sdma on CIK initAlex Deucher1-7/+0
commit 799028d5d85384cce140323be633c8d5f079193f upstream. Otherwise we may lose the DMA golden settings which can lead to hangs, etc. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: don't reset dma on NI/SI initAlex Deucher1-6/+0
commit 31a25e2caf9367365fcb0e57fd8fa5a42e9b73e4 upstream. Otherwise we may lose the DMA golden settings which can lead to hangs, etc. bug: https://www.libreoffice.org/bugzilla/show_bug.cgi?id=83500 Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: add connector quirk for fujitsu boardAlex Deucher1-0/+7
commit 1952f24d0fa6292d65f886887af87ba8ac79b3ba upstream. Vbios connector table lists non-existent VGA port. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=83184 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon/dpm: set the thermal type properly for special configsAlex Deucher1-7/+19
commit ff4377924f7e587c61bcbc704eafecf6c7bd2e00 upstream. On systems with special thermal configurations make sure we make note of the thermal setup. This is required for proper firmware configuration on these systems. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: fix semaphore value initChristian König1-1/+1
commit f229407da79315c18a2f25f485e1a1b9fdda1e92 upstream. Semaphore values have 64 bits, not 32. This fixes a very subtle bug that disables synchronization when the upper 32bits wasn't zero. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-By: Grigori Goronzy <greg@chown.ath.cx> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: handle broken disabled rb mask gracefully (6xx/7xx) (v2)Alex Deucher2-33/+16
commit 0a5f6e9d60e71e4b6dbeabd97bc887d6b2b0f0c8 upstream. This is a port of cedb655a3a7764c3fd946077944383c9e0e68dd4 to older asics. Fixes a possible divide by 0 if the harvest register is invalid. v2: drop some additional harvest munging. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: fix active_cu mask on SI and CIK after re-init (v3)Alex Deucher2-0/+2
commit 52da51f0f9ea9d213adfc99223630707b26d1d38 upstream. Need to initialize the mask to 0 on init, otherwise it keeps increasing. bug: https://bugzilla.kernel.org/show_bug.cgi?id=82581 v2: also fix cu count v3: split count fix into separate patch Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: fix active cu count for SI and CIKAlex Deucher2-10/+6
commit 6101b3ae94b4f266456308824e9ca4eab1235d1a upstream. This fixes the CU count reported to userspace for OpenCL. bug: https://bugzilla.kernel.org/show_bug.cgi?id=82581 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: fix pm handling in radeon_gpu_resetAlex Deucher1-2/+16
commit c940b4476f4fb649f6493b6a0ae837474ded8915 upstream. pm_suspend is handled in the radeon_suspend callbacks. pm_resume has special handling depending on whether dpm or legacy pm is enabled. Change radeon_gpu_reset to mirror the behavior in the suspend and resume pathes. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: properly document reloc priority maskChristian König1-1/+2
commit 701e1e789142042144c8cc10b8f6d1554e960144 upstream. Instead of hard coding the value properly document that this is an userspace interface. No intended functional change. Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon/dpm: select the appropriate vce power state for KV/KB/MLAlex Deucher1-3/+3
commit c83dec3bb6c38629398b65c231c80978b3e00e14 upstream. Compare the clock in the limits table to the requested evclk rather than just taking the first value. Improves vce performance in certain cases. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: Add missing lines to ci_set_thermal_temperature_rangeOleg Chernovskiy1-0/+3
commit 6bce8d9772c1c606921a9c99e566eb14202f6669 upstream. Properly set the thermal min and max temp on CI. Otherwise, we end up setting the thermal ranges to 0 on resume and end up in the lowest power state. Signed-off-by: Oleg Chernovskiy <algonkvel@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: Add ability to get and change dpm state when radeon PX card is ↵Pali Rohár1-10/+6
turned off commit b07a657e3a05b81c8a30d60e3f3746ca5a48ee62 upstream. This fixing commit 4f2f203976964e267dc477de6648bdb3acd2b74b bug: https://bugzilla.kernel.org/show_bug.cgi?id=76321 Signed-off-by: Pali Rohár <pali.rohar@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/vmwgfx: Fix a potential infinite spin waiting for fifo idleThomas Hellstrom1-1/+2
commit f01ea0c3d9db536c64d47922716d8b3b8f21d850 upstream. The code waiting for fifo idle was incorrect and could possibly spin forever under certain circumstances. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reported-by: Mark Sheldon <markshel@vmware.com> Reviewed-by: Jakob Bornecrantz <jakob@vmware.com> Reivewed-by: Mark Sheldon <markshel@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/ast: AST2000 cannot be detected correctlyY.C. Chen1-1/+1
commit 83502a5d34386f7c6973bc70e1c423f55f5a2e3a upstream. Type error and cause AST2000 cannot be detected correctly Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com> Reviewed-by: Egbert Eich <eich@suse.de> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/ast: open key before detect chipsY.C. Chen1-0/+1
commit 8f372e250ae5f4a5faf87ca1a629d0ae59db65b6 upstream. Some config settings like 3rd TX chips will not get correctly if the extended reg is protected Signed-off-by: Y.C. Chen <yc_chen@aspeedtech.com> Reviewed-by: Egbert Eich <eich@suse.de> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Don't leak command parser tables on suspend/resumeBrad Volkin1-5/+7
commit 22cb99af39b5d4aae075a5bc9da615ba245227cd upstream. Ring init and cleanup are not balanced because we re-init the rings on resume without having cleaned them up on suspend. This leads to the driver leaking the parser's hash tables with a kmemleak signature such as this: unreferenced object 0xffff880405960980 (size 32): comm "systemd-udevd", pid 516, jiffies 4294896961 (age 10202.044s) hex dump (first 32 bytes): d0 85 46 c0 ff ff ff ff 00 00 00 00 00 00 00 00 ..F............. 98 60 28 04 04 88 ff ff 00 00 00 00 00 00 00 00 .`(............. backtrace: [<ffffffff81816f9e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811fa678>] kmem_cache_alloc_trace+0x168/0x2f0 [<ffffffffc03e20a5>] i915_cmd_parser_init_ring+0x2a5/0x3e0 [i915] [<ffffffffc04088a2>] intel_init_ring_buffer+0x202/0x470 [i915] [<ffffffffc040c998>] intel_init_vebox_ring_buffer+0x1e8/0x2b0 [i915] [<ffffffffc03eff59>] i915_gem_init_hw+0x2f9/0x3a0 [i915] [<ffffffffc03f0057>] i915_gem_init+0x57/0x1d0 [i915] [<ffffffffc045e26a>] i915_driver_load+0xc0a/0x10e0 [i915] [<ffffffffc02e0d5d>] drm_dev_register+0xad/0x100 [drm] [<ffffffffc02e3b9f>] drm_get_pci_dev+0x8f/0x200 [drm] [<ffffffffc03c934b>] i915_pci_probe+0x3b/0x60 [i915] [<ffffffff81436725>] local_pci_probe+0x45/0xa0 [<ffffffff81437a69>] pci_device_probe+0xd9/0x130 [<ffffffff81524f4d>] driver_probe_device+0x12d/0x3e0 [<ffffffff815252d3>] __driver_attach+0x93/0xa0 [<ffffffff81522e1b>] bus_for_each_dev+0x6b/0xb0 This patch extends the current convention of checking whether a resource is already allocated before allocating it during ring init. Longer term it might make sense to only init the rings once. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83794 Tested-by: Kari Suvanto <kari.tj.suvanto@gmail.com> Signed-off-by: Brad Volkin <bradley.d.volkin@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915/hdmi: fix hdmi audio state readoutJani Nikula1-1/+1
commit c84db77010877da6c5da119868ed54c43d59e726 upstream. Check the correct bit for audio. Seems like a copy-paste error from the start: commit 9ed109a7b445e3f073d8ea72f888ec80c0532465 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Apr 24 23:54:52 2014 +0200 drm/i915: Track has_audio in the pipe config Reported-by: Martin Andersen <martin.x.andersen@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82756 Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Wait for vblank before enabling the TV encoderVille Syrjälä1-0/+4
commit 7a98948f3b536ca9a077e84966ddc0e9f53726df upstream. The vblank waits in intel_tv_detect_type() are timing out for some reason. This is a regression caused removing seemingly useless vblank waits from the modeset seqeuence in: commit 56ef52cad5e37fca89638e4bad598a994ecc3d9f Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Thu May 8 19:23:15 2014 +0300 drm/i915: Kill vblank waits after pipe enable on gmch platforms So it turns out they weren't all entirely useless. Apparently the pipe has to go through one full frame before we enable the TV port. Add a vblank wait to intel_enable_tv() to make sure that happens. Another approach was attempted by placing the vblank wait just after enabling the port. The theory behind that attempt was that we need to let the port stay enabled for one full frame before disabling it again during load detection. But that didn't work, and we definitely must have the vblank wait before enabling the port. Cc: Alan Bartlett <ajb@elrepo.org> Tested-by: Alan Bartlett <ajb@elrepo.org> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=79311 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Fix EIO/wedged handling in gem fault handlerDaniel Vetter1-4/+7
commit 2232f0315c6688f5ff6b2067ea88d97542034873 upstream. In commit 1f83fee08d625f8d0130f9fe5ef7b17c2e022f3c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Nov 15 17:17:22 2012 +0100 drm/i915: clear up wedged transitions I've accidentally inverted the EIO/wedged handling in the fault handler: We want to return the EIO as a SIGBUS only if it's not because of the gpu having died, to prevent userspace from unduly dying. In my defence the comment right above is completely misleading, so fix both. v2: Drop the WARN_ON, it's not actually a bug to e.g. receive an -EIO when swap-in fails. v3: Don't remove too much ... oops. Reported-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Fix lock dropping in intel_tv_detect()Ville Syrjälä1-3/+7
commit bbfb44e8b688e778964275ab0862f67463ba4f84 upstream. When intel_tv_detect() fails to do load detection it would forget to drop the locks and clean up the acquire context. Fix it up. This is a regression from: commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Mon Aug 11 13:15:35 2014 +0300 drm/i915: Fix locking for intel_enable_pipe_a() v2: Make the code more readable (Chris) v3: Drop WARN_ON(type < 0) (Chris) Cc: Tibor Billes <tbilles@gmx.com> Reported-by: Tibor Billes <tbilles@gmx.com> Tested-by: Tibor Billes <tbilles@gmx.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Remove bogus __init annotation from DMI callbacksMathias Krause3-3/+3
commit bbe1c2740d3a25aa1dbe5d842d2ff09cddcdde0a upstream. The __init annotations for the DMI callback functions are wrong as this code can be called even after the module has been initialized, e.g. like this: # echo 1 > /sys/bus/pci/devices/0000:00:02.0/remove # modprobe i915 # echo 1 > /sys/bus/pci/rescan The first command will remove the PCI device from the kernel's device list so the second command won't see it right away. But as it registers a PCI driver it'll see it on the third command. If the system happens to match one of the DMI table entries we'll try to call a function in long released memory and generate an Oops, at best. Fix this by removing the bogus annotation. Modpost should have caught that one but it ignores section reference mismatches from the .rodata section. :/ Fixes: 25e341cfc33d ("drm/i915: quirk away broken OpRegion VBT") Fixes: 8ca4013d702d ("CHROMIUM: i915: Add DMI override to skip CRT...") Fixes: 425d244c8670 ("drm/i915: ignore LVDS on intel graphics systems...") Signed-off-by: Mathias Krause <minipli@googlemail.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Duncan Laurie <dlaurie@chromium.org> Cc: Jarod Wilson <jarod@redhat.com> Cc: Rusty Russell <rusty@rustcorp.com.au> # Can modpost be fixed? Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Ignore VBT backlight presence check on Acer C720 (4005U)Scot Doyle1-0/+3
commit dfb3d47b2369ad752ab9f7438bbf9949524b46ae upstream. commit c675949ec58ca50d5a3ae3c757892f1560f6e896 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT prevents backlight setup on the Acer C720 (Core i3 4005U CPU), which has a misconfigured VBT. Apply quirk to ignore the VBT backlight presence check during backlight setup. Signed-off-by: Scot Doyle <lkml14@scotdoyle.com> Tested-by: Tyler Cleveland <siralucardt@openmailbox.org> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: fix plane/cursor handling when runtime suspendedPaulo Zanoni1-0/+24
commit d6dd6843ff4a57c662dbc378b9f99a9c034b0956 upstream. If we're runtime suspended and try to use the plane interfaces, we will get a lot of WARNs saying we did the wrong thing. We need to get runtime PM references to pin the objects, and to change the fences. The pin functions are the ideal places for this, but intel_crtc_cursor_set_obj() doesn't call them, so we also have to add get/put calls inside it. There is no problem if we runtime suspend right after these functions are finished, because the registers written are forwarded to system memory. Note: for a complete fix of the cursor-dpms test case, we also need the patch named "drm/i915: Don't try to enable cursor from setplane when crtc is disabled". v2: - Narrow the put/get calls on intel_crtc_cursor_set_obj() (Daniel) v3: - Make get/put also surround the fence and unpin calls (Daniel and Ville). - Merge all the plane changes into a single patch since they're the same fix. - Add the comment requested by Daniel. v4: - Remove spurious whitespace (Ville). v5: - Remove intel_crtc_update_cursor() chunk since Ville did an equivalent fix in another patch (Ville). v6: - Remove unpin chunk: it will be on a separate patch (Ville, Chris, Daniel). v7: - Same thing, new color. Testcase: igt/pm_rpm/cursor Testcase: igt/pm_rpm/cursor-dpms Testcase: igt/pm_rpm/legacy-planes Testcase: igt/pm_rpm/legacy-planes-dpms Testcase: igt/pm_rpm/universal-planes Testcase: igt/pm_rpm/universal-planes-dpms Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81645 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82603 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: don't try to retrain a DP link on an inactive CRTCImre Deak1-0/+3
commit 1a125d8a2c22b11741fc47d4ffcf7a5ffa044dd3 upstream. Atm we may retrain the DP link even if the CRTC is inactive through HPD work->intel_dp_check_link_status(). This in turn can lock up the PHY (at least on BYT), since the DP port is disabled. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81948 Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Fix locking for intel_enable_pipe_a()Ville Syrjälä4-21/+17
commit 208bf9fdcd3575aa4a5d48b3e0295f7cdaf6fc44 upstream. intel_enable_pipe_a() gets called with all the modeset locks already held (by drm_modeset_lock_all()), so trying to grab the same locks using another drm_modeset_acquire_ctx is going to fail miserably. Move most of the drm_modeset_acquire_ctx handling (init/drop/fini) out from intel_{get,release}_load_detect_pipe() into the callers (intel_{crt,tv}_detect()). Only the actual locking and backoff handling is left in intel_get_load_detect_pipe(). And in intel_enable_pipe_a() we just share the mode_config.acquire_ctx from drm_modeset_lock_all() which is already holding all the relevant locks. It's perfectly legal to lock the same ww_mutex multiple times using the same ww_acquire_ctx. drm_modeset_lock() will convert the returned -EALREADY into 0, so the caller doesn't need to do antyhing special. Fixes a hang on resume on my 830. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Skip load detect when intel_crtc->new_enable==trueVille Syrjälä1-4/+8
commit a459249c73eaec1daf4e4657ea3564cc3550e66c upstream. During suspend we turn off the crtcs, but leave the staged config in place so that we can restore the display(s) to their previous state on resume. During resume when we attempt to apply the force pipe A quirk we use the load detect mechanism. That doesn't check whether there was an already staged configuration for the crtc since that's not even possible during normal runtime load detection. But during resume it is possible, and if we just blindly go and overwrite the staged crtc configuration for the load detection we can no longer restore the display to the correct state. Even worse, we don't even clear all the staged connector->encoder->crtc links so we may end up using a cloned setup for the load detection, and after we're done we just clear the links related to the VGA output leaving the links for the other outputs in place. This will eventually result in calling intel_set_mode() with mode==NULL but with valid connector->encoder->crtc links which will result in dereferencing the NULL mode since the code thinks it will have to a modeset. To avoid these problems don't use any crtc with new_enabled==true for load detection. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Disable RCS flips on IvybridgeChris Wilson1-0/+2
commit 2a92d5bca1999b69c78f3c3e97b5484985b094b9 upstream. We currently see random GPU hangs when using RCS flips with multiple pipes on Ivybridge. Now that we have mmio flips, we can fairly cheaply fallback to using CPU driven flips instead. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=77104 Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: read HEAD register back in init_ring_common() to enforce orderingJiri Kosina1-0/+3
commit ece4a17d237a79f63fbfaf3f724a12b6d500555c upstream. Withtout this, ring initialization fails reliabily during resume with [drm:init_ring_common] *ERROR* render ring initialization failed ctl 0001f001 head ffffff8804 tail 00000000 start 000e4000 This is not a complete fix, but it is verified to make the ring initialization failures during resume much less likely. We were not able to root-cause this bug (likely HW-specific to Gen4 chips) yet. This is therefore used as a ducttape before problem is fully understood and proper fix created, so that people don't suffer from completely unusable systems in the meantime. The discussion and debugging is happening at https://bugs.freedesktop.org/show_bug.cgi?id=76554 Signed-off-by: Jiri Kosina <jkosina@suse.cz> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/i915: Fix crash when failing to parse MIPI VBTRafael Barbalho1-1/+1
commit ed3b6679936801fa2dab47e7a6ef74e383400ed9 upstream. This particular nasty presented itself while trying to register the intelfb device (intel_fbdev.c). During the process of registering the device the driver will disable the crtc via i9xx_crtc_disable. These will also disable the panel using the generic mipi panel functions in dsi_mod_vbt_generic.c. The stale MIPI generic data sequence pointers would cause a crash within those functions. However, all of this is happening while console_lock is held from do_register_framebuffer inside fbcon.c. Which means that you got kernel log and just the device appearing to reboot/hang for no apparent reason. The fault started from the FB_EVENT_FB_REGISTERED event using the fb_notifier_call_chain call in fbcon.c. This regression has been introduced in commit d3b542fcfc72d7724585e3fd2c5e75351bc3df47 Author: Shobhit Kumar <shobhit.kumar@intel.com> Date: Mon Apr 14 11:00:34 2014 +0530 drm/i915: Add parsing support for new MIPI blocks in VBT Cc: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Rafael Barbalho <rafael.barbalho@intel.com> Reviewed-by: Shobhit Kumar <shobhit.kumar@intel.com> [danvet: Add regression citation.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: tweak ACCEL_WORKING2 query for hawaiiAlex Deucher1-1/+8
commit 3c64bd26f7e9bd589ebe0d1ebec69ef2f784c12d upstream. Return 2 so we can be sure the kernel has the necessary changes for acceleration to work. Note: This patch depends on these two commits: - drm/radeon: fix cut and paste issue for hawaii. - drm/radeon: use packet2 for nop on hawaii with old firmware Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Andreas Boll <andreas.boll.dev@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon/atom: add new voltage fetch function for hawaiiAlex Deucher2-0/+38
commit e9f274b2a1bd4ecc569b823b1e7942e9bf92593e upstream. Some hawaii boards use a different method for fetching the voltage information from the vbios. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: set VM base addr using the PFP v2Christian König2-3/+4
commit f1d2a26b506e9dc7bbe94fae40da0a0d8dcfacd0 upstream. Seems to make VM flushes more stable on SI and CIK. v2: only use the PFP on the GFX ring on CIK Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: load the lm63 driver for an lm64 thermal chip.Alex Deucher1-2/+2
commit 5dc355325b648dc9b4cf3bea4d968de46fd59215 upstream. Looks like the lm63 driver supports the lm64 as well. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: re-enable dpm by default on BTCAlex Deucher1-3/+3
commit c08abf11900e19b14dd3a0cc3d105bd74519cd18 upstream. This patch depends on: e07929810f0a19ddd756558290c7d72827cbfcd9 (drm/radeon/dpm: fix typo in vddci setup for eg/btc) bugs: https://bugs.freedesktop.org/show_bug.cgi?id=73053 https://bugzilla.kernel.org/show_bug.cgi?id=68571 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon: re-enable dpm by default on caymanAlex Deucher1-1/+1
commit 8f500af4efe347d1a8ac674d115220e8caa84559 upstream. This patch depends on: b0880e87c1fd038b84498944f52e52c3e86ebe59 (drm/radeon/dpm: fix vddci setup typo on cayman) bug: https://bugs.freedesktop.org/show_bug.cgi?id=69723 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/radeon/dpm: handle voltage info fetching on hawaiiAlex Deucher1-1/+12
commit 6b57f20cb5b708415fbab63847f8f8429b051af8 upstream. Some hawaii cards use a different method to fetch the voltage info from the vbios. bug: https://bugs.freedesktop.org/show_bug.cgi?id=74250 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/ttm: Pass GFP flags in order to avoid deadlock.Tetsuo Handa2-19/+19
commit a91576d7916f6cce76d30303e60e1ac47cf4a76d upstream. Commit 7dc19d5a "drivers: convert shrinkers to new count/scan API" added deadlock warnings that ttm_page_pool_free() and ttm_dma_page_pool_free() are currently doing GFP_KERNEL allocation. But these functions did not get updated to receive gfp_t argument. This patch explicitly passes sc->gfp_mask or GFP_KERNEL to these functions, and removes the deadlock warning. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/ttm: Fix possible stack overflow by recursive shrinker calls.Tetsuo Handa1-3/+7
commit 71336e011d1d2312bcbcaa8fcec7365024f3a95d upstream. While ttm_dma_pool_shrink_scan() tries to take mutex before doing GFP_KERNEL allocation, ttm_pool_shrink_scan() does not do it. This can result in stack overflow if kmalloc() in ttm_page_pool_free() triggered recursion due to memory pressure. shrink_slab() => ttm_pool_shrink_scan() => ttm_page_pool_free() => kmalloc(GFP_KERNEL) => shrink_slab() => ttm_pool_shrink_scan() => ttm_page_pool_free() => kmalloc(GFP_KERNEL) Change ttm_pool_shrink_scan() to do like ttm_dma_pool_shrink_scan() does. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/ttm: Use mutex_trylock() to avoid deadlock inside shrinker functions.Tetsuo Handa1-2/+4
commit 22e71691fd54c637800d10816bbeba9cf132d218 upstream. I can observe that RHEL7 environment stalls with 100% CPU usage when a certain type of memory pressure is given. While the shrinker functions are called by shrink_slab() before the OOM killer is triggered, the stall lasts for many minutes. One of reasons of this stall is that ttm_dma_pool_shrink_count()/ttm_dma_pool_shrink_scan() are called and are blocked at mutex_lock(&_manager->lock). GFP_KERNEL allocation with _manager->lock held causes someone (including kswapd) to deadlock when these functions are called due to memory pressure. This patch changes "mutex_lock();" to "if (!mutex_trylock()) return ...;" in order to avoid deadlock. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/ttm: Choose a pool to shrink correctly in ttm_dma_pool_shrink_scan().Tetsuo Handa1-3/+3
commit 46c2df68f03a236b30808bba361f10900c88d95e upstream. We can use "unsigned int" instead of "atomic_t" by updating start_pool variable under _manager->lock. This patch will make it possible to avoid skipping when choosing a pool to shrink in round-robin style, after next patch changes mutex_lock(_manager->lock) to !mutex_trylock(_manager->lork). Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/ttm: Fix possible division by 0 in ttm_dma_pool_shrink_scan().Tetsuo Handa1-0/+3
commit 11e504cc705e8ccb06ac93a276e11b5e8fee4d40 upstream. list_empty(&_manager->pools) being false before taking _manager->lock does not guarantee that _manager->npools != 0 after taking _manager->lock because _manager->npools is updated under _manager->lock. Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2014-10-06drm/ttm: fix handling of TTM_PL_FLAG_TOPDOWN v2Christian König4-4/+9
commit e3f202798aaa808e7a38faa8c3a9f0aa93b85cc0 upstream. bo->mem.placement is not initialized when ttm_bo_man_get_node is called, so the flag had no effect at all. v2: change nouveau and vmwgfx as well Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-05-09 17:59:32 +0300