summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2016-03-04drm/radeon: call hpd_irq_event on resumeAlex Deucher1-0/+1
commit dbb17a21c131eca94eb31136eee9a7fe5aff00d9 upstream. Need to call this on resume if displays changes during suspend in order to properly be notified of changes. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/radeon: Fix off-by-one errors in radeon_vm_bo_set_addrFelix Kuehling1-6/+6
commit 42ef344c0994cc453477afdc7a8eadc578ed0257 upstream. eoffset is sometimes treated as the last address inside the address range, and sometimes as the first address outside the range. This was resulting in errors when a test filled up the entire address space. Make it consistent to always be the last address within the range. Also fixed related errors when checking the VA limit and in radeon_vm_fence_pts. Signed-off-by: Felix.Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/dp/mst: deallocate payload on port destructionMykola Lysenko1-8/+83
commit 91a25e463130c8e19bdb42f2d827836c7937992e upstream. This is needed to properly deallocate port payload after downstream branch get unplugged. In order to do this unplugged MST topology should be preserved, to find first alive port on path to unplugged MST topology, and send payload deallocation request to branch device of found port. For this mstb and port kref's are used in reversed order to track when port and branch memory could be freed. Added additional functions to find appropriate mstb as described above. Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com> Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/dp/mst: Reverse order of MST enable and clearing VC payload table.Andrey Grodzovsky1-6/+6
commit c175cd16df272119534058f28cbd5eeac6ff2d24 upstream. On DELL U3014 if you clear the table before enabling MST it sometimes hangs the receiver. Signed-off-by: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/dp/mst: move GUID storage from mgr, port to only mst branchHersen Wu1-36/+28
commit 5e93b8208d3c419b515fb75e2601931c027e12ab upstream. Previous implementation does not handle case below: boot up one MST branch to DP connector of ASIC. After boot up, hot plug 2nd MST branch to DP output of 1st MST, GUID is not created for 2nd MST branch. When downstream port of 2nd MST branch send upstream request, it fails because 2nd MST branch GUID is not available. New Implementation: only create GUID for MST branch and save it within Branch. Signed-off-by: Hersen Wu <hersenxs.wu@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/dp/mst: Calculate MST PBN with 31.32 fixed pointHarry Wentland1-28/+39
commit a9ebb3e46c7ef6112c0da466ef0954673ad36832 upstream. Our PBN value overflows the 20 bits integer part of the 20.12 fixed point. We need to use 31.32 fixed point to avoid this. This happens with display clocks larger than 293122 (at 24 bpp), which we see with the Sharp (and similar) 4k tiled displays. Signed-off-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/dp/mst: fix in RAD element accessMykola Lysenko1-2/+2
commit 7a11a334aa6af4c65c6a0d81b60c97fc18673532 upstream. This is needed to receive correct port number from RAD, so MSTB could be found Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/dp/mst: fix in MSTB RAD initializationMykola Lysenko1-6/+6
commit 75af4c8c4c0f60d7ad135419805798f144e9baf9 upstream. This fix is needed to support more then two branch displays, so RAD address consist at least of 2 elements Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/dp/mst: always send reply for UP requestMykola Lysenko1-19/+11
commit 1f16ee7fa13649f4e55aa48ad31c3eb0722a62d3 upstream. We should always send reply for UP request in order to make downstream device clean-up resources appropriately. Issue was that reply for UP request was sent only once. Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/dp/mst: process broadcast messages correctlyMykola Lysenko1-11/+84
commit bd9343208704fcc70a5b919f228a7d26ae472727 upstream. In case broadcast message received in UP request, RAD cannot be used to identify message originator. Message should be parsed, originator should be found by GUID from parsed message. Also reply with broadcast in case broadcast message received (for now it is always broadcast) Acked-by: Dave Airlie <airlied@gmail.com> Signed-off-by: Mykola Lysenko <Mykola.Lysenko@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/nouveau: platform: Fix deferred probeThierry Reding2-12/+30
commit 870571a5698b2e9d0f4d2e5c6245967b582aab45 upstream. The error cleanup paths aren't quite correct and will crash upon deferred probe. Reviewed-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/nouveau/disp/dp: ensure sink is powered up before attempting link trainingBen Skeggs2-0/+16
commit 95664e66fad964c3dd7945d6edfb1d0931844664 upstream. This can happen under some annoying circumstances, and is a quick fix until more substantial changes can be made. Fixed eDP mode changes on (at least) the Lenovo P50. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/nouveau/display: Enable vblank irqs after display engine is on again.Mario Kleiner1-4/+4
commit ff683df7bf34f90766a50c7e7454e219aef2710e upstream. In the display resume path, move the calls to drm_vblank_on() after the point when the display engine is running again. Since changes were made to drm_update_vblank_count() in Linux 4.4+ to emulate hw vblank counters via vblank timestamping, the function drm_vblank_on() now needs working high precision vblank timestamping and therefore working scanout position queries at time of call. These don't work before the display engine gets restarted, causing miscalculation of vblank counter increments and thereby large forward jumps in vblank count at display resume. These jumps can cause client hangs on resume, or desktop hangs in the case of composited desktops. Fix this Linux 4.4 regression by reordering calls accordingly. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: ville.syrjala@linux.intel.com Cc: daniel.vetter@ffwll.ch Cc: dri-devel@lists.freedesktop.org Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/nouveau/kms: take mode_config mutex in connector hotplug pathBen Skeggs1-0/+3
commit 0a882cadbc63fd2da3994af7115b4ada2fcbd638 upstream. fdo#93634 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu/pm: adjust display configuration after powerstateAlex Deucher1-2/+3
commit 8e7cedc6f7fe762ffe6e348502be34b11fa79298 upstream. set_power_state defaults to no displays, so we need to update the display configuration after setting up the powerstate on the first call. In most cases this is not an issue since ends up getting called multiple times at any given modeset and the proper order is achieved in the display changed handling at the top of the function. Reviewed-by: Christian König <christian.koenig@amd.com> Acked-by: Jordan Lazare <Jordan.Lazare@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: Don't hang in amdgpu_flip_work_func on disabled crtc.Mario Kleiner1-3/+15
commit e1d09dc0ccc6c91e3916476f636edb76da1f65bb upstream. This fixes a regression introduced in Linux 4.4. This is a port of the same fix for radeon-kms in the patch "drm/radeon: Don't hang in radeon_flip_work_func on disabled crtc. (v2)" Limit the amount of time amdgpu_flip_work_func can delay programming a page flip, by both limiting the maximum amount of time per wait cycle and the maximum number of wait cycles. Continue the flip if the limit is exceeded, even if that may result in a visual or timing glitch. This is to prevent a hang of page flips, as reported in fdo bug #93746: Disconnecting a DisplayPort display in parallel to a kms pageflip getting queued can cause the following hang of page flips and thereby an unusable desktop: 1. kms pageflip ioctl() queues pageflip -> queues execution of amdgpu_flip_work_func. 2. Hotunplug of display causes the driver to DPMS OFF the unplugged display. Display engine shuts down, scanout no longer moves, but stays at its resting position at start line of vblank. 3. amdgpu_flip_work_func executes while crtc is off, and due to the non-moving scanout position, the new flip delay code introduced into Linux 4.4 by commit 8e36f9d33c13 ("drm/amdgpu: Fixup hw vblank counter/ts..") enters an infinite wait loop. 4. After reconnecting the display, the pageflip continues to hang in 3. and the display doesn't update its view of the desktop. This patch fixes the Linux 4.4 regression from fdo bug #93746 <https://bugs.freedesktop.org/show_bug.cgi?id=93746> Reported-by: Bernd Steinhauser <linux@bernd-steinhauser.de> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Michel Dänzer <michel.daenzer@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-03-04drm/amdgpu: use post-decrement in error handlingRasmus Villemoes1-1/+1
commit 09ccbb74b6718ad4d1290de3f5669212c0ac7d4b upstream. We need to use post-decrement to get the pci_map_page undone also for i==0, and to avoid some very unpleasant behaviour if pci_map_page failed already at i==0. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: fix issue with overlapping userptrsChristian König3-1/+23
commit cc1de6e800c253172334f8774c419dc64401cd2e upstream. Otherwise we could try to evict overlapping userptr BOs in get_user_pages(), leading to a possible circular locking dependency. Signed-off-by: Christian König <christian.koenig@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: hold reference to fences in amdgpu_sa_bo_new (v2)Nicolai Hähnle1-1/+4
commit a8d81b36267366603771431747438d18f32ae2d5 upstream. An arbitrary amount of time can pass between spin_unlock and fence_wait_any_timeout, so we need to ensure that nobody frees the fences from under us. A stress test (rapidly starting and killing hundreds of glxgears instances) ran into a deadlock in fence_wait_any_timeout after about an hour, and this race condition appears to be a plausible cause. v2: agd: rebase on upstream Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-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>
2016-03-04drm/amdgpu: remove unnecessary forward declarationNicolai Hähnle1-2/+0
commit b19763d0d867eb863953500a5c87f2fd663863b8 upstream. Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com> Reviewed-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>
2016-03-04drm/amdgpu: fix s4 resumeFlora Cui1-4/+9
commit ca19852884c8937eed89560f924f5a34cfcc22af upstream. No need to re-init asic if it's already been initialized. Skip IB tests since kernel processes are frozen in thaw. Signed-off-by: Flora Cui <Flora.Cui@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: remove exp hardware support from icelandAlex Deucher1-5/+5
commit dba280b20bfd1c2bed8a07ce3f75a6da8ba7d247 upstream. It's working now. bug: https://bugs.freedesktop.org/show_bug.cgi?id=92270 Reviewed-by: Ken Wang <Qingqing.Wang@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>
2016-03-04drm/amdgpu: don't load MEC2 on topazAlex Deucher2-11/+5
commit 97dde76a30c2e67fa5fb9cb6a4072c0178c9df26 upstream. Not validated. Reviewed-by: Ken Wang <Qingqing.Wang@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>
2016-03-04drm/amdgpu: drop topaz support from gmc8 moduleAlex Deucher1-27/+1
commit 8878d8548ac7fae43cd6d82579f966eb8825e282 upstream. topaz is actually gmc7. Reviewed-by: Ken Wang <Qingqing.Wang@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>
2016-03-04drm/amdgpu: pull topaz gmc bits into gmc_v7Alex Deucher1-2/+33
commit 72b459c8f716ef03a8a0c78078547ce64d8d29a2 upstream. Add the topaz golden settings into the gmc7 module. Reviewed-by: Ken Wang <Qingqing.Wang@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>
2016-03-04drm/amdgpu: The VI specific EXE bit should only apply to GMC v8.0 aboveKen Wang1-1/+1
commit 8f3c162961fc2d92ec73a66496aab69eb2e19c36 upstream. Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Ken Wang <Qingqing.Wang@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: iceland use CI based MC IPKen Wang2-4/+13
commit 429c45deae6e57f1bb91bfb05b671063fb0cef60 upstream. Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Ken Wang <Qingqing.Wang@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: move gmc7 support out of CIK dependencyAlex Deucher1-1/+2
commit e42d85261680edfc350a6c2a86b7fbb44a85014b upstream. It's used by iceland which is VI. Reviewed-by: Ken Wang <Qingqing.Wang@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>
2016-03-04drm/amdgpu: no need to load MC firmware on fijiAlex Deucher1-4/+2
commit ad32152eb26043d165eed9406cb9e2f7011f6b10 upstream. Vbios does this for us on asic_init. Reviewed-by: Ken Wang >Qingqing.Wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: fix amdgpu_bo_pin_restricted VRAM placing v2Christian König1-1/+2
commit 78d0e182b6c1f5336f6e8cbb197f403276dabc7f upstream. We could pin BOs into invisible VRAM otherwise. v2: make logic more readable as suggested by Michel Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Reviewed-by: Rex Zhu <Rex.Zhu@amd.com> (v1) Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: fix tonga smu resumeAlex Deucher1-15/+2
commit e160e4db833c7e8587ec3c88efaed0d84f1bcf42 upstream. Need to make sure smu buffers are pinned on resume. This matches what Fiji does. Reviewed-by: Junwei Zhang <Jerry.Zhang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Ken Wang <Qingqing.Wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: fix lost sync_to if scheduler is enabled.Chunming Zhou1-2/+3
commit 888c9e33e4c5a503285921046c621f7c73199d2f upstream. when scheduler is enabled, the semaphore isn't used at all. Signed-off-by: Chunming Zhou <David1.Zhou@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: call hpd_irq_event on resumeAlex Deucher1-0/+1
commit 54fb2a5cd0baf8e97d743de411e2f832d1afa68d upstream. Need to call this on resume if displays changes during suspend in order to properly be notified of changes. Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/amdgpu: Fix off-by-one errors in amdgpu_vm_bo_mapFelix Kuehling1-5/+5
commit 005ae95e6ec119c64e2d16eb65a94c49e1dcf9f0 upstream. eaddr is sometimes treated as the last address inside the address range, and sometimes as the first address outside the range. This was resulting in errors when a test filled up the entire address space. Make it consistent to always be the last address within the range. Signed-off-by: Felix.Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/vmwgfx: respect 'nomodeset'Rob Clark1-0/+7
commit 96c5d076f0a5e2023ecdb44d8261f87641ee71e0 upstream. Signed-off-by: Rob Clark <robdclark@gmail.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>. Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/vmwgfx: Fix a width / pitch mismatch on framebuffer updatesThomas Hellstrom1-1/+5
commit a50e2bf5a0f674d62b69f51f6935a30e82bd015c upstream. When the framebuffer is a vmwgfx dma buffer and a proxy surface is created, the vmw_kms_update_proxy() function requires that the proxy surface width and the framebuffer pitch are compatible, otherwise display corruption occurs as seen in gnome-shell/native with software 3D. Since the framebuffer pitch is determined by user-space, allocate a proxy surface the width of which is based on the framebuffer pitch rather than on the framebuffer width. Reported-by: Raphael Hertzog <buxy@kali.org> Tested-by: Mati Aharoni <muts@kali.org> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Brian Paul <brianp@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/vmwgfx: Fix an incorrect lock checkThomas Hellstrom1-1/+1
commit fb89ac5102ae2875d685c847e6b5dbc141622d43 upstream. With CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y the vmwgfx kernel module would unconditionally throw a bug when checking for a held spinlock in the command buffer code. Fix this by using a lockdep check. Reported-and-tested-by: Tetsuo Handa <penguin-kernel@i-love-sakura.ne.jp> Signed-off-by: Thomas Hellstrom <thellstrom@vmware.com> Reviewed-by: Sinclair Yeh <syeh@vmware.com> Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/i915: shut up gen8+ SDE irq dmesg noiseDaniel Vetter1-3/+7
commit 97e5ed1111dcc5300a0f59a55248cd243937a8ab upstream. We get tons of cases where the master interrupt handler apparently set a bit, with the SDEIIR disagreeing. No idea what's going on there, but it's consistent on gen8+, no one seems to care about it and it's making CI results flaky. Shut it up. No idea what's going on here, but we've had fun with PCH interrupts before: commit 44498aea293b37af1d463acd9658cdce1ecdf427 Author: Paulo Zanoni <paulo.r.zanoni@intel.com> Date: Fri Feb 22 17:05:28 2013 -0300 drm/i915: also disable south interrupts when handling them Note that there's a regression report in Bugzilla, and other regression reports on the mailing lists keep croping up. But no ill effects have ever been reported. But for paranoia still keep the message at a debug level as a breadcrumb, just in case. This message was introduced in commit 38cc46d73ed99dd7002f1406002e52d7975d16cc Author: Oscar Mateo <oscar.mateo@intel.com> Date: Mon Jun 16 16:10:59 2014 +0100 drm/i915/bdw: Ack interrupts before handling them (GEN8) v2: Improve commit message a bit. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1445590572-23631-2-git-send-email-daniel.vetter@ffwll.ch Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92084 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80896 Acked-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-03-04drm/gma500: Use correct unref in the gem bo create functionDaniel Vetter1-1/+1
commit d3e376f52d095103ca51dbda4d6ff8aaf488f98f upstream. This is called without dev->struct_mutex held, we need to use the _unlocked variant. Never caught in the wild since you'd need an evil userspace which races a gem_close ioctl call with the in-progress open. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Acked-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1448271183-20523-17-git-send-email-daniel.vetter@ffwll.ch Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2016-01-07Merge branch 'linux-4.4' of git://github.com/skeggsb/linux into drm-fixesDave Airlie1-0/+1
single nv40 oops fix. * 'linux-4.4' of git://github.com/skeggsb/linux: drm/nouveau/gr/nv40: fix oops in interrupt handler
2016-01-05drm/nouveau/gr/nv40: fix oops in interrupt handlerBen Skeggs1-0/+1
fdo#93557 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
2016-01-03Merge tag 'drm-intel-fixes-2016-01-02' of ↵Linus Torvalds2-5/+9
git://anongit.freedesktop.org/drm-intel Pull i915 drm fixes from Jani Nikula: "Two display fixes still for v4.4. The new year's resolution is to start using signed tags per Linus' request. This one is still unsigned; I want to fix this up in our maintainer scripts instead of doing it one-off" * tag 'drm-intel-fixes-2016-01-02' of git://anongit.freedesktop.org/drm-intel: drm/i915: increase the tries for HDMI hotplug live status checking drm/i915: Unbreak check_digital_port_conflicts()
2015-12-30drm/i915: increase the tries for HDMI hotplug live status checkingGary Wang1-1/+1
The total delay of HDMI hotplug detecting with 30ms is sometimes not enoughtfor HDMI live status up with specific HDMI monitors in BSW platform. After doing experiments for following monitors, it needs 80ms at least for those worst cases. Lenovo L246 1xwA (4 failed, necessary hot-plug delay: 58/40/60/40ms) Philips HH2AP (9 failed, necessary hot-plug delay: 80/50/50/60/46/40/58/58/39ms) BENQ ET-0035-N (6 failed, necessary hot-plug delay: 60/50/50/80/80/40ms) DELL U2713HM (2 failed, necessary hot-plug delay: 58/59ms) HP HP-LP2475w (5 failed, necessary hot-plug delay: 70/50/40/60/40ms) It looks like 70-80 ms is BSW platform needs in some bad cases of the monitors at this end (8 times delay at most). Keep less than 100ms for HDCP pulse HPD low (with at least 100ms) to respond a plug out. Reviewed-by: Cooper Chiou <cooper.chiou@intel.com> Tested-by: Gary Wang <gary.c.wang@intel.com> Cc: Gavin Hindman <gavin.hindman@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Shobhit Kumar <shobhit.kumar@intel.com> Signed-off-by: Gary Wang <gary.c.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450858295-12804-1-git-send-email-gary.c.wang@intel.com Tested-by: Shobhit Kumar <shobhit.kumar@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: 237ed86c693d ("drm/i915: Check live status before reading edid") Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit f8d03ea0053b23de42c828d559016eabe0b91523) [Jani: undo the file mode change of the original commit] Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-12-23Merge tag 'drm-intel-fixes-2015-12-23' of ↵Linus Torvalds7-61/+154
git://anongit.freedesktop.org/drm-intel Pull i915 drm fixes from Jani Nikula: "Here's a batch of i915 fixes all around. It may be slightly bigger than one would hope for at this stage, but they've all been through testing in our -next before being picked up for v4.4. Also, I missed Dave's fixes pull earlier today just because I wanted an extra testing round on this. So I'm fairly confident. Wishing you all the things it is customary to wish this time of the year" * tag 'drm-intel-fixes-2015-12-23' of git://anongit.freedesktop.org/drm-intel: drm/i915: Correct max delay for HDMI hotplug live status checking drm/i915: mdelay(10) considered harmful drm/i915: Kill intel_crtc->cursor_bo drm/i915: Workaround CHV pipe C cursor fail drm/i915: Only spin whilst waiting on the current request drm/i915: Limit the busy wait on requests to 5us not 10ms! drm/i915: Break busywaiting for requests on pending signals drm/i915: Disable primary plane if we fail to reconstruct BIOS fb (v2) drm/i915: Set the map-and-fenceable flag for preallocated objects drm/i915: Drop the broken cursor base==0 special casing
2015-12-23drm/i915: Unbreak check_digital_port_conflicts()Ville Syrjälä1-4/+8
Atomic changes broke check_digital_port_conflicts(). It needs to look at the global situation instead of just trying to find a conflict within the current atomic state. This bug made my HSW explode spectacularly after I had split the DDI encoders into separate DP and HDMI encoders. With the fix, things seem much more solid. I hope holding the connection_mutex is enough protection that we can actually walk the connectors even if they're not part of the current atomic state... v2: Regenerate the patch so that it actually applies (Jani) Cc: stable@vger.kernel.org Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com> Fixes: 5448a00d3f06 ("drm/i915: Don't use staged config in check_digital_port_conflicts()") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449764551-12466-1-git-send-email-ville.syrjala@linux.intel.com (cherry picked from commit 0bff4858653312a10c83709e0009c3adb87e6f1e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-12-22drm/i915: Correct max delay for HDMI hotplug live status checkingGary Wang1-3/+4
The total delay of HDMI hotplug detecting with 30ms have already been split into a resolution of 3 retries of 10ms each, for the worst cases. But it still suffered from only waiting 10ms at most in intel_hdmi_detect(). This patch corrects it by reading hotplug status with 4 times at most for 30ms delay. v2: - straight up to loop execution for more clear in code readability - mdelay will replace with msleep by Daniel's new patch drm/i915: mdelay(10) considered harmful - suggest to re-evaluate try times for being compatible to old HDMI monitor Reviewed-by: Cooper Chiou <cooper.chiou@intel.com> Tested-by: Gary Wang <gary.c.wang@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Gavin Hindman <gavin.hindman@intel.com> Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: Shashank Sharma <shashank.sharma@intel.com> Signed-off-by: Gary Wang <gary.c.wang@intel.com> [danvet: fixup conflict with s/mdelay/msleep/ patch.] Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 61fb3980dd396880ffba48523b1e27579868b82b) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-12-22drm/i915: mdelay(10) considered harmfulDaniel Vetter1-1/+1
I missed this myself when reviewing commit 237ed86c693d8a8e4db476976aeb30df4deac74b Author: Sonika Jindal <sonika.jindal@intel.com> Date: Tue Sep 15 09:44:20 2015 +0530 drm/i915: Check live status before reading edid Long sleeps like this really shouldn't waste cpu cycles spinning. Cc: Sonika Jindal <sonika.jindal@intel.com> Cc: "Wang, Gary C" <gary.c.wang@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1449859455-32609-1-git-send-email-daniel.vetter@ffwll.ch Reviewed-by: Sonika Jindal <sonika.jindal@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit 71a199bacb398ee54eeac001699257dda083a455) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-12-22drm/i915: Kill intel_crtc->cursor_boVille Syrjälä2-6/+0
The vma may have been rebound between the last time the cursor was enabled and now, so skipping the cursor gtt offset deduction is not safe unless we would also reset cursor_bo to NULL when disabling the cursor. Just thow cursor_bo to the bin instead since it's lost all other uses thanks to universal plane support. Chris pointed out that cursor updates are currently too slow via universal planes that micro optimizations like these wouldn't even help. v2: Add a note about futility of micro optimizations (Chris) Cc: drm-intel-fixes@lists.freedesktop.org References: http://lists.freedesktop.org/archives/intel-gfx/2015-December/082976.html Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Takashi Iwai <tiwai@suse.de> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450107302-17171-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (cherry picked from commit 1264859d648c4bdc9f0a098efbff90cbf462a075) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-12-22drm/i915: Workaround CHV pipe C cursor failVille Syrjälä1-0/+17
Turns out CHV pipe C was glued on somewhat poorly, and there's something wrong with the cursor. If the cursor straddles the left screen edge, and is then moved away from the edge or disabled, the pipe will often underrun. If enough underruns are triggered quickly enough the pipe will fall over and die (it just scans out a solid color and reports a constant underrun). We need to turn the disp2d power well off and on again to recover the pipe. None of that is very nice for the user, so let's just refuse to place the cursor in the compromised position. The ddx appears to fall back to swcursor when the ioctl returns an error, so theoretically there's no loss of functionality for the user (discounting swcursor bugs). I suppose most cursors images actually have the hotspot not exactly at 0,0 so under typical conditions the fallback will in fact kick in as soon as the cursor touches the left edge of the screen. Any atomic compositor should anyway be prepared to fall back to GPU composition when things don't work out, so there should be no problem with those. Other things that I tried to solve this include flipping all display related clock gating knobs I could find, increasing the minimum gtt alignment all the way up to 512k. I also tried to see if there are more specific screen coordinates that hit the bug, but the findings were somewhat inconclusive. Sometimes the failures happen almost across the whole left edge, sometimes more at the very top and around the bottom half. I wasn't able to find any real pattern to these variations, so it seems our only choice is to just refuse to straddle the left screen edge at all. Cc: stable@vger.kernel.org Cc: Jason Plum <max@warheads.net> Testcase: igt/kms_chv_cursor_fail Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92826 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1450459479-16286-1-git-send-email-ville.syrjala@linux.intel.com Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> (cherry picked from commit b29ec92c4f5e6d45d8bae8194e664427a01c6687) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2015-12-22drm/i915: Only spin whilst waiting on the current requestChris Wilson2-9/+26
Limit busywaiting only to the request currently being processed by the GPU. If the request is not currently being processed by the GPU, there is a very low likelihood of it being completed within the 2 microsecond spin timeout and so we will just be wasting CPU cycles. v2: Check for logical inversion when rebasing - we were incorrectly checking for this request being active, and instead busywaiting for when the GPU was not yet processing the request of interest. v3: Try another colour for the seqno names. v4: Another colour for the function names. v5: Remove the forced coherency when checking for the active request. On reflection and plenty of recent experimentation, the issue is not a cache coherency problem - but an irq/seqno ordering problem (timing issue). Here, we do not need the w/a to force ordering of the read with an interrupt. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: "Rogozhkin, Dmitry V" <dmitry.v.rogozhkin@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Eero Tamminen <eero.t.tamminen@intel.com> Cc: "Rantala, Valtteri" <valtteri.rantala@intel.com> Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1449833608-22125-4-git-send-email-chris@chris-wilson.co.uk (cherry picked from commit 821485dc2ad665f136c57ee589bf7a8210160fe2) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-09-25 14:00:33 +0300