summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2015-05-06drm/i915: cope with large i2c transfersDmitry Torokhov
commit 9535c4757b881e06fae72a857485ad57c422b8d2 upstream. The hardware, according to the specs, is limited to 256 byte transfers, and current driver has no protections in case users attempt to do larger transfers. The code will just stomp over status register and mayhem ensues. Let's split larger transfers into digestable chunks. Doing this allows Atmel MXT driver on Pixel 1 function properly (it hasn't since commit 9d8dc3e529a19e427fd379118acd132520935c5d "Input: atmel_mxt_ts - implement T44 message handling" which tries to consume multiple touchscreen/touchpad reports in a single transaction). Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-06drm/i915: vlv: fix save/restore of GFX_MAX_REQ_COUNT regImre Deak
commit b5f1c97f944482e98e6e39208af356630389d1ea upstream. Due this typo we don't save/restore the GFX_MAX_REQ_COUNT register across suspend/resume, so fix this. This was introduced in commit ddeea5b0c36f3665446518c609be91f9336ef674 Author: Imre Deak <imre.deak@intel.com> Date: Mon May 5 15:19:56 2014 +0300 drm/i915: vlv: add runtime PM support I noticed this only by reading the code. To my knowledge it shouldn't cause any real problems at the moment, since the power well backing this register remains on across a runtime s/r. This may change once system-wide s0ix functionality is enabled in the kernel. v2: - resend after a missing git add -u :/ Signed-off-by: Imre Deak <imre.deak@intel.com> Tested-By: PRC QA PRTS (Patch Regression Test System Contact: shuang.he@intel.com) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-06drm: adv7511: Fix nested sleep when reading EDIDLaurent Pinchart
commit a5241289c4139f0521b89e34a70f5f998463ae15 upstream. The EDID read code waits for the read completion interrupt to occur using wait_event_interruptible(). The condition passed to the macro reads I2C registers. This results in sleeping with the task state set to TASK_INTERRUPTIBLE, triggering a WARN_ON() introduced in commit 8eb23b9f35aae ("sched: Debug nested sleeps"). Fix this by reworking the EDID read code. Instead of checking whether the read is complete through I2C reads, handle the interrupt registers in the interrupt handler and update a new edid_read flag accordingly. As a side effect both the IRQ and polling code paths now process the interrupt sources through the same code path, simplifying the code. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-06drm: adv7511: Fix DDC error interrupt handlingLaurent Pinchart
commit 2e96206c4f952295e11c311fbb2a7aa2105024af upstream. The DDC error interrupt bit is located in REG_INT1, not REG_INT0. Update both the interrupt wait code and the interrupt sources reset code accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-06drm/i915: Dont enable CS_PARSER_ERROR interrupts at allDaniel Vetter
commit 37ef01ab5d24d1d520dc79f6a98099d451c2a901 upstream. We stopped handling them in commit aaecdf611a05cac26a94713bad25297e60225c29 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Nov 4 15:52:22 2014 +0100 drm/i915: Stop gathering error states for CS error interrupts but just clearing is apparently not enough: A sufficiently dead gpu left behind by firmware (*cough* coreboot *cough*) can keep the gpu in an endless loop of such interrupts, eventually leading to the nmi firing. And definitely to what looks like a machine hang. Since we don't even enable these interrupts on gen5+ let's do the same on earlier platforms. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93171 Tested-by: Mono <mono-for-kernel-org@donderklumpen.de> Tested-by: info@gluglug.org.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-05-06drm/radeon: fix doublescan modes (v2)Alex Deucher
commit fd99a0943ffaa0320ea4f69d09ed188f950c0432 upstream. Use the correct flags for atom. v2: handle DRM_MODE_FLAG_DBLCLK Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-19drm/i915: Push vblank enable/disable past encoder->enable/disableDaniel Vetter
commit f9b61ff6bce9a44555324b29e593fdffc9a115bc upstream. It is platform/output depenedent when exactly the pipe will start running. Sometimes we just need the (cpu) pipe enabled, in other cases the pch transcoder is enough and in yet other cases the (DP) port is sending the frame start signal. In a perfect world we'd put the drm_crtc_vblank_on call exactly where the pipe starts running, but due to cloning and similar things this will get messy. And the current approach of picking the most conservative place for all combinations also doesn't work since that results in legit vblank waits (in encoder->enable hooks, e.g. the 2 vblank waits for sdvo) failing. Completely going back to the old world before commit 51e31d49c89055299e34b8f44d13f70e19aaaad1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Sep 15 12:36:02 2014 +0200 drm/i915: Use generic vblank wait isn't great either since screaming when the vblank wait work because the pipe is off is kinda nice. Pick a compromise and move the drm_crtc_vblank_on right before the encoder->enable call. This is a lie on some outputs/platforms, but after the ->enable callback the pipe is guaranteed to run everywhere. So not that bad really. Suggested by Ville. v2: Same treatment for drm_crtc_vblank_off and encoder->disable: I've missed the ibx pipe B select w/a, which also has a vblank wait in the disable function (while the pipe is obviously still running). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-19radeon: Do not directly dereference pointers to BIOS area.David Miller
commit f2c9e560b406f2f6b14b345c7da33467dee9cdf2 upstream. Use readb() and memcpy_fromio() accessors instead. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-19drm/i915: Align initial plane backing objects correctlyDaniel Vetter
commit f37b5c2be8979993efee2da50b51126e3908eb8b upstream. Some bios really like to joke and start the planes at an offset ... hooray! Align start and end to fix this. v2: Fixup calculation of size, spotted by Chris Wilson. v3: Fix serious fumble I've just spotted. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86883 Cc: Johannes W <jargon@molb.org> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reported-and-tested-by: Johannes W <jargon@molb.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> [Jani: split WARN_ONs, rebase on v4.0-rc1] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-19drm/amdkfd: Initialize only amdkfd's assigned pipelinesOded Gabbay
commit 1365aa6266fad0669487240af3f098593796172c upstream. This patch fixes a bug in the initialization of the pipelines. The init_pipelines() function was called with a constant value of 0 in the first_pipe argument. This is an error because amdkfd doesn't handle pipe 0. The correct way is to pass the value that get_first_pipe() returns as the argument for first_pipe. This bug appeared in 3.19 (first version with amdkfd) and it causes around 15% drop in CPU performance of Kaveri (A10-7850). v2: Don't set get_first_pipe() as inline because it calls BUG_ON() Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Tested-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-19drm/i915/vlv: remove wait for previous GFX clk disable requestJesse Barnes
commit 5df0582bf036bb5f9a8ad8db5884fe13a55347d1 upstream. Looks like it was introduced in: commit 650ad970a39f8b6164fe8613edc150f585315289 Author: Imre Deak <imre.deak@intel.com> Date: Fri Apr 18 16:35:02 2014 +0300 drm/i915: vlv: factor out vlv_force_gfx_clock and check for pending force-of but I'm not sure why. It has caused problems for us in the past (see 85250ddff7a6 "drm/i915/chv: Remove Wait for a previous gfx force-off" and 8d4eee9cd7a1 "drm/i915: vlv: increase timeout when forcing on the GFX clock") and doesn't seem to be required, so let's just drop it. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-19drm/i915/vlv: save/restore the power context base regJesse Barnes
commit 9c25210fd30991e68f93e2ec0857de2d967b5766 upstream. Some BIOSes (e.g. the one on the Minnowboard) don't save/restore this reg. If it's unlocked, we can just restore the previous value, and if it's locked (in case the BIOS re-programmed it for us) the write will be ignored and we'll still have "did it move" sanity check in the PM code to warn us if something is still amiss. References: https://bugs.freedesktop.org/show_bug.cgi?id=89611 Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> Tested-by: Darren Hart <dvhart@linux.intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Deepak S <deepak.s@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-19drm/i915/chv: Remove Wait for a previous gfx force-offDeepak S
commit c9c52e24194a741f9fca96e7aa965f0fa36af504 upstream. On CHV, PUNIT team confirmed that 'VLV_GFX_CLK_STATUS_BIT' is not a sticky bit and it will always be set. So ignore Check for previous Gfx force off during suspend and allow the force clk as part S0ix Sequence Signed-off-by: Deepak S <deepak.s@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-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>
2015-04-19drm/radeon: fix wait in radeon_mn_invalidate_range_startChristian König
commit 22e2e86560c5fca6f9b9d078f221fcdab9947a5e upstream. We need to wait for all fences, not just the exclusive one. 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>
2015-04-19drm/radeon: add extra check in radeon_ttm_tt_unpin_userptrChristian König
commit 863653fed0f449fb738295255cc834b271cfa088 upstream. We somehow try to free the SG table twice. Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=89734 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>
2015-04-19drm/radeon/dpm: fix 120hz handling harderAlex Deucher
commit 3899ca844b82fb201fb764f56eec483acb59a29c upstream. Need to expand the check to handle short circuiting if the selected state is the same as current state. bug: https://bugs.freedesktop.org/show_bug.cgi?id=87796 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-04-19drm/i915: Reject the colorkey ioctls for primary and cursor planesVille Syrjälä
commit 840a1cf0cd533f30da792527ca5ff6a023d4a727 upstream. The legcy colorkey ioctls are only implemented for sprite planes, so reject the ioctl for primary/cursor planes. If we want to support colorkeying with these planes (assuming we have hw support of course) we should just move ahead with the colorkey property conversion. Testcase: kms_legacy_colorkey Cc: Tommi Rantala <tt.rantala@gmail.com> Reference: http://mid.gmane.org/CA+ydwtr+bCo7LJ44JFmUkVRx144UDFgOS+aJTfK6KHtvBDVuAw@mail.gmail.com Reported-and-tested-by: Tommi Rantala <tt.rantala@gmail.com> 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>
2015-04-19drm/edid: set ELD for firmware and debugfs override EDIDsJani Nikula
commit ad692b46dbf122ef90aadce3b389ef64c90e861d upstream. If the user supplies EDID through firmware or debugfs override, the driver callbacks are bypassed and the connector ELD does not get updated, and audio fails. Set ELD for firmware and debugfs EDIDs too. There should be no harm in gratuitously doing this for non HDMI/DP connectors, as it's still up to the driver to use the ELD, if any. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82349 Reference: https://bugs.freedesktop.org/show_bug.cgi?id=80691 Reported-by: Emil <emilsvennesson@gmail.com> Reported-by: Rob Engle <grenoble@gmail.com> Tested-by: Jolan Luff <jolan@gormsby.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>
2015-04-19drm: Fixup racy refcounting in plane_force_disableDaniel Vetter
commit 8218c3f4df3bb1c637c17552405039a6dd3c1ee1 upstream. Originally it was impossible to be dropping the last refcount in this function since there was always one around still from the idr. But in commit 83f45fc360c8e16a330474860ebda872d1384c8c Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Wed Aug 6 09:10:18 2014 +0200 drm: Don't grab an fb reference for the idr we've switched to weak references, broke that assumption but forgot to fix it up. Since we still force-disable planes it's only possible to hit this when racing multiple rmfb with fbdev restoring or similar evil things. As long as userspace is nice it's impossible to hit the BUG_ON. But the BUG_ON would most likely be hit from fbdev code, which usually invovles the console_lock besides all modeset locks. So very likely we'd never get the bug reports if this was hit in the wild, hence better be safe than sorry and backport. Spotted by Matt Roper while reviewing other patches. [airlied: pull this back into 4.0 - the oops happens there] Cc: Matt Roper <matthew.d.roper@intel.com> Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/i915: use in_interrupt() not in_irq() to check contextDave Gordon
commit 6c51d46f135b00c00373fcd029786ccef2b02b5b upstream. The kernel in_irq() function tests for hard-IRQ context only, so if a system is run with the kernel 'threadirqs' option selected, the test in intel_check_page_flip() generates lots of warnings, because then it gets called in soft-IRQ context. We can instead use in_interrupt() which allows for either type of interrupt, while still detecting and complaining about misuse of the page flip code if it is ever called from non-interrupt context. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89321 Signed-off-by: Dave Gordon <david.s.gordon@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Cc: Josh Boyer <jwboyer@fedoraproject.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/i915: gen4: work around hang during hibernationImre Deak
commit ab3be73fa7b43f4c3648ce29b5fd649ea54d3adb upstream. Bjørn reported that his machine hang during hibernation and eventually bisected the problem to the following commit: commit da2bc1b9db3351addd293e5b82757efe1f77ed1d Author: Imre Deak <imre.deak@intel.com> Date: Thu Oct 23 19:23:26 2014 +0300 drm/i915: add poweroff_late handler The problem seems to be that after the kernel puts the device into D3 the BIOS still tries to access it, or otherwise assumes that it's in D0. This is clearly bogus, since ACPI mandates that devices are put into D3 by the OSPM if they are not wake-up sources. In the future we want to unify more of the driver's runtime and system suspend paths, for example by skipping all the system suspend/hibernation hooks if the device is runtime suspended already. Accordingly for all other platforms the goal is still to properly power down the device during hibernation. v2: - Another GEN4 Lenovo laptop had the same issue, while platforms from other vendors (including mobile and desktop, GEN4 and non-GEN4) seem to work fine. Based on this apply the workaround on all GEN4 Lenovo platforms. - add code comment about failing platforms (Ville) Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/060633.html Reported-and-bisected-by: Bjørn Mork <bjorn@mork.no> Signed-off-by: Imre Deak <imre.deak@intel.com> Acked-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/i915: add dev_to_i915 helperImre Deak
commit 888d0d421663313739a8bf93459c6ba61fd4b121 upstream. This will be needed by later patches, so factor it out. No functional change. v2: - s/dev_to_i915_priv/dev_to_i915/ (Jani) - don't use the helper in i915_pm_suspend (Chris) - simplify the helper (Chris) v3: - remove redundant upcasting in the helper (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm: Don't assign fbs for universal cursor support to filesChris Wilson
commit 9a6f5130143c17b91e0a3cbf5cc2d8c1e5a80a63 upstream. The internal framebuffers we create to remap legacy cursor ioctls to plane operations for the universal plane support shouldn't be linke to the file like normal userspace framebuffers. This bug goes back to the original universal cursor plane support introduced in commit 161d0dc1dccb17ff7a38f462c7c0d4ef8bcc5662 Author: Matt Roper <matthew.d.roper@intel.com> Date: Tue Jun 10 08:28:10 2014 -0700 drm: Support legacy cursor ioctls via universal planes when possible (v4) The isn't too disastrous since fbs are small, we only create one when the cursor bo gets changed and ultimately they'll be reaped when the window server restarts. Conceptually we'd want to just pass NULL for file_priv when creating it, but the driver needs the file to lookup the underlying buffer object for cursor id. Instead let's move the file_priv linking out of add_framebuffer_internal() into the addfb ioctl implementation, which is the only place it is needed. And also rename the function for a more accurate since it only creates the fb, but doesn't add it anywhere. Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> (fix & commit msg) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> (provider of lipstick) Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Rob Clark <robdclark@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/vmwgfx: Fix a couple of lock dependency violationsThomas Hellstrom
commit 5151adb37a5918957f4c33a8d8e7629c0fb00563 upstream. Experimental lockdep annotation added to the TTM lock has unveiled a couple of lock dependency violations in the vmwgfx driver. In both cases it turns out that the device_private::reservation_sem is not needed so the offending code is moved out of that lock. Acked-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/vmwgfx: Reorder device takedown somewhatThomas Hellstrom
commit 3458390b9f0ba784481d23134798faee27b5f16f upstream. To take down the MOB and GMR memory types, the driver may have to issue fence objects and thus make sure that the fence manager is taken down after those memory types. Reorder device init accordingly. Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: drop ttm two ended allocationAlex Deucher
commit a239118a24b3bf9089751068e431dfb63dc4168b upstream. radeon_bo_create() calls radeon_ttm_placement_from_domain() before ttm_bo_init() is called. radeon_ttm_placement_from_domain() uses the ttm bo size to determine when to select top down allocation but since the ttm bo is not initialized yet the check is always false. It only took effect when buffers were validated later. It also seemed to regress suspend and resume on some systems possibly due to it not taking effect in radeon_bo_create(). radeon_bo_create() and radeon_ttm_placement_from_domain() need to be reworked substantially for this to be optimally effective. Re-enable it at that point. Noticed-by: Oded Gabbay <oded.gabbay@amd.com> 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>
2015-03-26drm/radeon: Changing number of compute pipe linesBen Goz
commit e405ca3a1bf166f741506c07c2a277b5d48af8f7 upstream. The current CP firmware can handle Usermode Queues only on MEC1. To reflect this firmware change, this commit reduces number of compute pipelines to 4 - 1, from 8 - 1 (the first pipeline is allocated for kgd). Signed-off-by: Ben Goz <ben.goz@amd.com> Signed-off-by: Oded Gabbay <oded.gabbay@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: fix wait to actually occur after the signaling callbackMaarten Lankhorst
commit b6610101718d4ab90d793c482625e98eb1262cad upstream. A normal wait adds to the front of the tail. By doing something similar to fence_default_wait the fence code can run without racing. This is a complete fix for "panic on suspend from KDE with radeon", and a partial fix for "Radeon: System pauses on TAHITI". On tahiti si_irq_set needs to be fixed too, to completely flush the writes before radeon_fence_activity is called in radeon_fence_enable_signaling. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=90861 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@ubuntu.com> Reported-by: Jon Arne Jørgensen <jonjon.arnearne@gmail.com> Reported-and-tested-by: Gustaw Smolarczyk <wielkiegie@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: drop setting UPLL to sleep modeChristian König
commit a17d4996e051e78d164989b894608cf37cd5110b upstream. Just keep it working, seems to fix some PLL problems. Bug: https://bugs.freedesktop.org/show_bug.cgi?id=73378 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>
2015-03-26drm/radeon: fix interlaced modes on DCE8Alex Deucher
commit 77ae5f4b48a0445426c9c1ef7c0f28b717e35d55 upstream. Need to double the viewport height. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: do a posting read in rs600_set_irqAlex Deucher
commit 54acf107e4e66d1f4a697e08a7f60dba9fcf07c3 upstream. To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: do a posting read in si_set_irqAlex Deucher
commit 0586915ec10d0ae60de5cd3381ad25a704760402 upstream. To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: do a posting read in cik_set_irqAlex Deucher
commit cffefd9bb31cd35ab745d3b49005d10616d25bdc upstream. To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: do a posting read in r600_set_irqAlex Deucher
commit 9d1393f23d5656cdd5f368efd60694d4aeed81d3 upstream. To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: do a posting read in r100_set_irqAlex Deucher
commit f957063fee6392bb9365370db6db74dc0b2dce0a upstream. To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: do a posting read in evergreen_set_irqAlex Deucher
commit c320bb5f6dc0cb88a811cbaf839303e0a3916a92 upstream. To make sure the writes go through the pci bridge. bug: https://bugzilla.kernel.org/show_bug.cgi?id=90741 Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-26drm/radeon: fix DRM_IOCTL_RADEON_CS oopsTommi Rantala
commit a28b2a47edcd0cb7c051b445f71a426000394606 upstream. Passing zeroed drm_radeon_cs struct to DRM_IOCTL_RADEON_CS produces the following oops. Fix by always calling INIT_LIST_HEAD() to avoid the crash in list_sort(). ---------------------------------- #include <stdint.h> #include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <drm/radeon_drm.h> static const struct drm_radeon_cs cs; int main(int argc, char **argv) { return ioctl(open(argv[1], O_RDWR), DRM_IOCTL_RADEON_CS, &cs); } ---------------------------------- [ttrantal@test2 ~]$ ./main /dev/dri/card0 [ 46.904650] BUG: unable to handle kernel NULL pointer dereference at (null) [ 46.905022] IP: [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] PGD 68f29067 PUD 688b5067 PMD 0 [ 46.905022] Oops: 0002 [#1] SMP [ 46.905022] CPU: 0 PID: 2413 Comm: main Not tainted 4.0.0-rc1+ #58 [ 46.905022] Hardware name: Hewlett-Packard HP Compaq dc5750 Small Form Factor/0A64h, BIOS 786E3 v02.10 01/25/2007 [ 46.905022] task: ffff880058e2bcc0 ti: ffff880058e64000 task.ti: ffff880058e64000 [ 46.905022] RIP: 0010:[<ffffffff814d6df2>] [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP: 0018:ffff880058e67998 EFLAGS: 00010246 [ 46.905022] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 46.905022] RDX: ffffffff81644410 RSI: ffff880058e67b40 RDI: ffff880058e67a58 [ 46.905022] RBP: ffff880058e67a88 R08: 0000000000000000 R09: 0000000000000000 [ 46.905022] R10: ffff880058e2bcc0 R11: ffffffff828e6ca0 R12: ffffffff81644410 [ 46.905022] R13: ffff8800694b8018 R14: 0000000000000000 R15: ffff880058e679b0 [ 46.905022] FS: 00007fdc65a65700(0000) GS:ffff88006d600000(0000) knlGS:0000000000000000 [ 46.905022] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 46.905022] CR2: 0000000000000000 CR3: 0000000058dd9000 CR4: 00000000000006f0 [ 46.905022] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 46.905022] DR3: 0000000000000000 DR6: 00000000ffff4ff0 DR7: 0000000000000400 [ 46.905022] Stack: [ 46.905022] ffff880058e67b40 ffff880058e2bcc0 ffff880058e67a78 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 46.905022] Call Trace: [ 46.905022] [<ffffffff81644a65>] radeon_cs_parser_fini+0x195/0x220 [ 46.905022] [<ffffffff81645069>] radeon_cs_ioctl+0xa9/0x960 [ 46.905022] [<ffffffff815e1f7c>] drm_ioctl+0x19c/0x640 [ 46.905022] [<ffffffff810f8fdd>] ? trace_hardirqs_on_caller+0xfd/0x1c0 [ 46.905022] [<ffffffff810f90ad>] ? trace_hardirqs_on+0xd/0x10 [ 46.905022] [<ffffffff8160c066>] radeon_drm_ioctl+0x46/0x80 [ 46.905022] [<ffffffff81211868>] do_vfs_ioctl+0x318/0x570 [ 46.905022] [<ffffffff81462ef6>] ? selinux_file_ioctl+0x56/0x110 [ 46.905022] [<ffffffff81211b41>] SyS_ioctl+0x81/0xa0 [ 46.905022] [<ffffffff81dc6312>] system_call_fastpath+0x12/0x17 [ 46.905022] Code: 48 89 b5 10 ff ff ff 0f 84 03 01 00 00 4c 8d bd 28 ff ff ff 31 c0 48 89 fb b9 15 00 00 00 49 89 d4 4c 89 ff f3 48 ab 48 8b 46 08 <48> c7 00 00 00 00 00 48 8b 0e 48 85 c9 0f 84 7d 00 00 00 c7 85 [ 46.905022] RIP [<ffffffff814d6df2>] list_sort+0x42/0x240 [ 46.905022] RSP <ffff880058e67998> [ 46.905022] CR2: 0000000000000000 [ 47.149253] ---[ end trace 09576b4e8b2c20b8 ]--- Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/i915: Check for driver readyness before handling an underrun interruptChris Wilson
commit 54fc7c1c961cb39edfe31f8a3f5ba6414e134b37 upstream. When we takeover from the BIOS and install our interrupt handler, the BIOS may have left us a few surprises in the form of spontaneous interrupts. (This is especially likely on hardware like 965gm where display fifo underruns are continuous and the GMCH cannot filter that interrupt souce.) As we enable our IRQ early so that we can use it during hardware probing, our interrupt handler must be prepared to handle a few sources prior to being fully configured. As such, we need to add a simple is-ready check prior to dereferencing our KMS state for reporting underruns. Reported-by: Rob Clark <rclark@redhat.com> Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1193972 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> [Jani: dropped the extra !] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/i915: avoid processing spurious/shared interrupts in low-power statesImre Deak
commit 2dd2a883aad7c852400027c2261bcab69d9e238e upstream. Atm, it's possible that the interrupt handler is called when the device is in D3 or some other low-power state. It can be due to another device that is still in D0 state and shares the interrupt line with i915, or on some platforms there could be spurious interrupts even without sharing the interrupt line. The latter case was reported by Klaus Ethgen using a Lenovo x61p machine (gen 4). He noticed this issue via a system suspend/resume hang and bisected it to the following commit: commit e11aa362308f5de467ce355a2a2471321b15a35c Author: Jesse Barnes <jbarnes@virtuousgeek.org> Date: Wed Jun 18 09:52:55 2014 -0700 drm/i915: use runtime irq suspend/resume in freeze/thaw This is a problem, since in low-power states IIR will always read 0xffffffff resulting in an endless IRQ servicing loop. Fix this by handling interrupts only when the driver explicitly enables them and so it's guaranteed that the interrupt registers return a valid value. Note that this issue existed even before the above commit, since during runtime suspend/resume we never unregistered the handler. v2: - clarify the purpose of smp_mb() vs. synchronize_irq() in the code comment (Chris) v3: - no need for an explicit smp_mb(), we can assume that synchronize_irq() and the mmio read/writes in the install hooks provide for this (Daniel) - remove code comment as the remaining synchronize_irq() is self explanatory (Daniel) v4: - drm_irq_uninstall() implies synchronize_irq(), so no need to call it explicitly (Daniel) Reference: https://lkml.org/lkml/2015/2/11/205 Reported-and-bisected-by: Klaus Ethgen <Klaus@Ethgen.ch> Signed-off-by: Imre Deak <imre.deak@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>
2015-03-18drm/i915: Dell Chromebook 11 has PWM backlightJani Nikula
commit cf6f0af9fbdd90b81af14fa6375387131cd8adf1 upstream. Add quirk for Dell Chromebook 11 backlight. Reported-and-tested-by: Owen Garland <garland.owen@gmail.com> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=93451 Acked-by: Damien Lespiau <damien.lespiau@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/i915: Check obj->vma_list under the struct_mutexChris Wilson
commit 6c31a614c43ae274546f736b2a33363e149c3dc2 upstream. When we walk the list of vma, or even for protecting against concurrent framebuffer creation, we must hold the struct_mutex or else a second thread can corrupt the list as we walk it. Fixes regression from commit d7f46fc4e7323887494db13f063a8e59861fefb0 Author: Ben Widawsky <benjamin.widawsky@intel.com> Date: Fri Dec 6 14:10:55 2013 -0800 drm/i915: Make pin count per VMA References: https://bugs.freedesktop.org/show_bug.cgi?id=89085 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> 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>
2015-03-18drm/i915/bdw: PCI IDs ending in 0xb are ULT.Rodrigo Vivi
commit 0dc6f20b9803f09726bbb682649d35cda8ef5b5d upstream. When reviewing patch that fixes VGA on BDW Halo Jani noticed that we also had other ULT IDs that weren't listed there. So this follow-up patch add these pci-ids as halo and fix comments on i915_pciids.h Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/radeon: fix 1 RB harvest config setup for TN/RLAlex Deucher
commit dbfb00c3e7e18439f2ebf67fe99bf7a50b5bae1e upstream. The logic was reversed from what the hw actually exposed. Fixes graphics corruption in certain harvest configurations. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/radeon: use drm_mode_vrefresh() rather than mode->vrefreshAlex Deucher
commit 3d2d98ee1af0cf6eebfbd6bff4c17d3601ac1284 upstream. Just in case it hasn't been calculated for the mode. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/radeon: enable native backlight control on old macsNathan-J. Hirschauer
commit 7a26f9ad1b5badfd0200ce2262ad696e2a6b7fbb upstream. Commit b7bc596ebbe0 ("drm/radeon: disable native backlight control on pre-r6xx asics (v2)") accidently broke backlight control on old mac laptops that use the on-GPU backlight controller. Signed-off-by: Nathan-J. Hirschauer <nathanhi@deepserve.info> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/i915: Clamp efficient frequency to valid rangeTom O'Rourke
commit 46efa4abe5712276494adbce102f46e3214632fd upstream. The efficient frequency (RPe) should stay in the range RPn <= RPe <= RP0. The pcode clamps the returned value internally on Broadwell but not on Haswell. Fix for missing range check in commit 93ee29203f506582cca2bcec5f05041526d9ab0a Author: Tom O'Rourke <Tom.O'Rourke@intel.com> Date: Wed Nov 19 14:21:52 2014 -0800 drm/i915: Use efficient frequency for HSW/BDW Reference: http://lists.freedesktop.org/archives/intel-gfx/2015-February/059802.html Reported-by: Michael Auchter <a@phire.org> Suggested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Tom O'Rourke <Tom.O'Rourke@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/i915: Correct the IOSF Dev_FN field for IOSF transfersShobhit Kumar
commit d180d2bbb66579e3bf449642b8ec2a76f4014fcd upstream. As per the specififcation, the SB_DevFn is the PCI_DEVFN of the target device and not the source. So PCI_DEVFN(2,0) is not correct. Further the port ID should be enough to identify devices unless they are MFD. The SB_DevFn was intended to remove ambiguity in case of these MFD devices. For non MFD devices the recommendation for the target device IP was to ignore these fields, but not all of them followed the recommendation. Some like CCK ignore these fields and hence PCI_DEVFN(2, 0) works and so does PCI_DEVFN(0, 0) as it works for DPIO. The issue came to light because of GPIONC which was not getting programmed correctly with PCI_DEVFN(2, 0). It turned out that this did not follow the recommendation and expected 0 in this field. In general the recommendation is to use SB_DevFn as PCI_DEVFN(0, 0) for all devices except target PCI devices. Signed-off-by: Shobhit Kumar <shobhit.kumar@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>
2015-03-18drm/i915: Prevent use-after-free in invalidate_range_start callbackMichał Winiarski
commit 460822b0b1a77db859b0320469799fa4dbe4d367 upstream. It's possible for invalidate_range_start mmu notifier callback to race against userptr object release. If the gem object was released prior to obtaining the spinlock in invalidate_range_start we're hitting null pointer dereference. Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close Testcase: igt/gem_userptr_blits/stress-mm-invalidate-close-overlap Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> [Jani: added code comment suggested by Chris] Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/i915: Drop vblank wait from intel_dp_link_downDaniel Vetter
commit 0ca09685546fed5fc8f0535204f0626f352140f4 upstream. Nothing in Bspec seems to indicate that we actually needs this, and it looks like can't work since by this point the pipe is off and so vblanks won't really happen any more. Note that Bspec mentions that it takes a vblank for this bit to change, but _only_ when enabling. Dropping this code quenches an annoying backtrace introduced by the more anal checking since commit 51e31d49c89055299e34b8f44d13f70e19aaaad1 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Mon Sep 15 12:36:02 2014 +0200 drm/i915: Use generic vblank wait Note: This fixes the fallout from the above commit, but does not address the shortcomings of the IBX transcoder select workaround implementation discussed during review [1]. [1] http://mid.gmane.org/87y4o7usxf.fsf@intel.com Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=86095 Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2015-03-18drm/i915: Insert a command barrier on BLT/BSD cache flushesChris Wilson
commit f0a1fb10e5f79f5aaf8d7e94b9fa6bf2fa9aeebf upstream. This looked like an odd regression from commit ec5cc0f9b019af95e4571a9fa162d94294c8d90b Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 12 10:28:55 2014 +0100 drm/i915: Restrict GPU boost to the RCS engine but in reality it undercovered a much older coherency bug. The issue that boosting the GPU frequency on the BCS ring was masking was that we could wake the CPU up after completion of a BCS batch and inspect memory prior to the write cache being fully evicted. In order to serialise the breadcrumb interrupt (and so ensure that the CPU's view of memory is coherent) we need to perform a post-sync operation in the MI_FLUSH_DW. v2: Fix all the MI_FLUSH_DW (bsd plus the duplication in execlists). Also fix the invalidate_domains mask in gen8_emit_flush() for ring != VCS. Testcase: gpuX-rcs-gpu-read-after-write Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-05-06 21:50:21 +0000