- 08 Jun, 2020 4 commits
-
-
Chris Wilson authored
If the execbuf is interrupted after building the cmdparser pipeline, and before we commit to submitting the request to HW, we would attempt to clean up the cmdparser early. While we held active references to the vma being parsed and constructed, we did not hold an active reference for the buffer pool itself. The result was that an interrupted execbuf could still have run the cmdparser pipeline, but since the buffer pool was idle, its target vma could have been recycled. Note this problem only occurs if the cmdparser is running async due to pipelined waits on busy fences, and the execbuf is interrupted. Fixes: 686c7c35 ("drm/i915/gem: Asynchronous cmdparser") Fixes: 16e87459 ("drm/i915/gt: Move the batch buffer pool from the engine to the gt") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200604103751.18816-1-chris@chris-wilson.co.uk (cherry picked from commit 57a78ca4) Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2020-06-04' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Includes gvt-next-fixes-2020-05-28 - Use after free fix for display global state. - Whitelisting context-local timestamp on Gen9 and two scheduler fixes with deps (Cc: stable) - Removal of write flag from sysfs files where ineffective Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200604150454.GA59322@jlahtine-desk.ger.corp.intel.com
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-fixes-5.8-2020-06-04 amdgpu: - Prevent hwmon accesses while GPU is in reset - CTF interrupt fix - Backlight fix for renoir - Fix for display sync groups - Display bandwidth validation workaround Signed-off-by:
-
git://github.com/skeggsb/linuxDave Airlie authored
- HDMI/DP audio HDA fixes - display hang fix for Volta/Turing - GK20A regression fix. Signed-off-by:
-
- 04 Jun, 2020 7 commits
-
-
Ben Skeggs authored
The most innocuous result of not having done this is that we end up sending unnecessary methods when we next enable the window. However, interactions with the code handling skipping disables when an update immediately follows, and window ownership assignment, can lead to upsetting the display hardware on Volta and newer. Signed-off-by:Ben Skeggs <bskeggs@redhat.com>
-
Thierry Reding authored
Tegra firmware doesn't actually use any version numbers and passing -1 causes the existing firmware binaries not to be found. Use version 0 to find the correct files. Fixes: ef16dc27 ("drm/nouveau/gr/gf100-: select implementation based on available FW") Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Ben Skeggs authored
Some HDA pin widgets may be disabled by BIOS, and unavailable from a SOR. Our SOR allocation policy uses this information to allocate an appropriate SOR when HDA is supported by a display. Thank you to NVIDIA for providing the information to determine this. Signed-off-by: -
Ben Skeggs authored
GP100 needs different HDA detection. Signed-off-by: -
Ben Skeggs authored
Since GM200, SORs are no longer tied to a specific connector, and we allocate them instead, with the assumption that all SORs are equally capable. However, there's a 1<->1 mapping between SOR and HDA pin widget, and it turns out that it's possible for some widgets to be disabled... In order to avoid picking a SOR without a valid pin widget, some new rules need to be added. Signed-off-by: -
Ben Skeggs authored
No logical changes here, this is just moving the code to make the changes in the next commit more obvious. Signed-off-by: -
Ben Skeggs authored
Will be used by a subsequent commit to influence SOR allocation policy. Signed-off-by:
-
- 03 Jun, 2020 2 commits
-
-
Nicholas Kazlauskas authored
[Why] Whenever we switch between tiled formats without also switching pixel formats or doing anything else that recreates the DC plane state we can run into underflow or hangs since we're not updating the DML parameters before committing to the hardware. [How] If the update type is FULL then call validate_bandwidth again to update the DML parmeters before committing the state. This is basically just a workaround and protective measure against update types being added DC where we could run into this issue in the future. We can only fully validate the state in advance before applying it to the hardware if we recreate all the plane and stream states since we can't modify what's currently in use. The next step is to update DM to ensure that we're creating the plane and stream states for whatever could potentially be a full update in DC to pre-emptively recreate the state for DC global validation. The workaround can stay until this has been fixed in DM. Signed-off-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by:
Hersen Wu <hersenxs.wu@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Alex Deucher authored
We may end up with no planes set yet, depending on the ordering, but we should have the proper blanking state which is either handled by either DPG or TG depending on the hardware generation. Check both to determine the proper blanked state. Bug: https://gitlab.freedesktop.org/drm/amd/issues/781 Fixes: 5fc0cbfa ("drm/amd/display: determine if a pipe is synced by plane state") Cc: nicholas.kazlauskas@amd.com Reviewed-by:
-
- 02 Jun, 2020 5 commits
-
-
https://github.com/intel/gvt-linuxJoonas Lahtinen authored
Merge tag 'gvt-next-fixes-2020-05-28' of https://github.com/intel/gvt-linux into drm-intel-next-fixes gvt-next-fixes-2020-05-28 - Fix one clang warning on debug only function (Nathan) - Use ARRAY_SIZE for coccicheck warn (Aishwarya) Signed-off-by:
-
Jani Nikula authored
fake_lmem_start does not need to be mutable via module param sysfs. It's only used during driver probe. Fixes: 16292243 ("drm/i915/lmem: add the fake lmem region") Cc: Matthew Auld <matthew.auld@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200601215510.18379-2-jani.nikula@intel.com (cherry picked from commit f322e851) Signed-off-by:
-
Jani Nikula authored
The parameter only makes sense as a module parameter only. Fixes: c43c5a88 ("drm/i915/params: add i915 parameters to debugfs") Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Reviewed-by:
Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com> Signed-off-by:
-
Chris Wilson authored
Allow batch buffers to read their own _local_ cumulative HW runtime of their logical context. Fixes: 0f2f3975 ("drm/i915: Add gen9 BCS cmdparsing") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200601161942.30854-1-chris@chris-wilson.co.uk (cherry picked from commit f9496520) Signed-off-by:
-
Ville Syrjälä authored
While the current locking/serialization of the global state suffices for protecting the obj->state access and the actual hardware reprogramming, we do have a problem with accessing the old/new states during nonblocking commits. The state computation and swap will be protected by the crtc locks, but the commit_tails can finish out of order, thus also causing the atomic states to be cleaned up out of order. This would mean the commit that started first but finished last has had its new state freed as the no-longer-needed old state by the other commit. To fix this let's just refcount the states. obj->state amounts to one reference, and the intel_atomic_state holds extra references to both its new and old global obj states. Fixes: 0ef1905e ("drm/i915: Introduce better global state handling") Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200527200245.13184-1-ville.syrjala@linux.intel.comReviewed-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> (cherry picked from commit f8c86ffa) Signed-off-by:
-
- 01 Jun, 2020 5 commits
-
-
Chris Wilson authored
With the advent of preempt-to-busy, a request may still be on the GPU as we unwind. And in the case of a unpreemptible [due to HW] request, that request will remain indefinitely on the GPU even though we have returned it back to our submission queue, and cleared the active bit. We only run the execution callbacks on transferring the request from our submission queue to the execution queue, but if this is a bonded request that the HW is waiting for, we will not submit it (as we wait for a fresh execution) even though it is still being executed. As we know that there are always preemption points between requests, we know that only the currently executing request may be still active even though we have cleared the flag. However, we do not precisely know which request is in ELSP[0] due to a delay in processing events, and furthermore we only store the last request in a context in our state tracker. Fixes: 22b7a426 ("drm/i915/execlists: Preempt-to-busy") Testcase: igt/gem_exec_balancer/bonded-dual Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200529143926.3245-1-chris@chris-wilson.co.uk (cherry picked from commit b55230e5) Signed-off-by:
-
Chris Wilson authored
When we push a virtual request onto the HW, we update the rq->engine to point to the physical engine. A request that is then submitted by the user that waits upon the virtual engine, but along the physical engine in use, will then see that it is due to be submitted to the same engine and take a shortcut (and be queued without waiting for the completion fence). However, the virtual request may be preempted (either by higher priority users, or by timeslicing) and removed from the physical engine to be migrated over to one of its siblings. The dependent normal request however is oblivious to the removal of the virtual request and remains queued to execute on HW, believing that once it reaches the head of its queue all of its predecessors will have completed executing! v2: Beware restriction of signal->execution_mask prior to submission. Fixes: 6d06779e ("drm/i915: Load balancing across a virtual engine") Testcase: igt/gem_exec_balancer/sliced Signed-off-by:
-
Chris Wilson authored
Reorder the code so that we can reuse the await_execution from a special case in await_request in the next patch. Signed-off-by:
-
Ben Skeggs authored
The audio driver can call into nouveau right while we're in the middle of re-fetching the EDID, and decide it no longer needs to be awake. Stop depending on EDID in the audio component get_eld() callback, and instead cache whether audio support is present from the prior modeset. Signed-off-by: -
Ben Skeggs authored
This is a SOR register, and not indexed by the bound head. Fixes display not coming up on high-bandwidth HDMI displays under a number of configurations. Signed-off-by:
-
- 29 May, 2020 3 commits
-
-
Harry Wentland authored
This reverts commit 96cb7cf1. This change was used for DCN2 bringup and is no longer desired. In fact it breaks backlight on DCN2 systems. Cc: Alexander Monakov <amonakov@ispras.ru> Cc: Hersen Wu <hersenxs.wu@amd.com> Cc: Anthony Koo <Anthony.Koo@amd.com> Cc: Michael Chiu <Michael.Chiu@amd.com> Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Acked-by:
Alexander Monakov <amonakov@ispras.ru> Signed-off-by:
-
Evan Quan authored
There will be no further interrupt without proper ack for current one. V2: fix typo to really set ACK bit only Signed-off-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
Alex Deucher authored
Return an error for sysfs and debugfs power interfaces during gpu reset and suspend. Prevents access to the hw while it may be in an unusable state. v2: squash in fix to drop suspend check Acked-by:
Nirmoy Das <nirmoy.das@amd.com> Signed-off-by:
-
- 28 May, 2020 2 commits
-
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
amd-drm-next-5.8-2020-05-27: amdgpu: - SRIOV fixes - RAS fixes - VCN 2.5 DPG (Dynamic PowerGating) fixes - FP16 updates for display - CTF cleanups - Display fixes - Fix pcie bw sysfs handling - Enable resizeable BAR support for gmc 10.x - GFXOFF fixes for Raven - PM sysfs handling fixes amdkfd: - Fix a race condition - Warning fixes Signed-off-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2020-05-27' of git://anongit.freedesktop.org/drm/drm-misc into drm-next Short summary of fixes pull (less than what git shortlog provides): There's a fix for panel brighness on Lenovo X13 Yoga devices and a fix for -Wformat warnings on architectures where atomic-64 counters are not of type unsigned long long. Signed-off-by:
-
- 27 May, 2020 2 commits
-
-
Aric Cyr authored
[Why] If VUPDATE_END is before VUPDATE_START the delay calculated can become very large, causing a soft hang. [How] Take the absolute value of the difference between START and END. Signed-off-by:
Aric Cyr <aric.cyr@amd.com> Reviewed-by:
Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by:
-
Simon Ser authored
get_cursor_position already handles the case where the cursor has negative off-screen coordinates by not setting dc_cursor_position.enabled. Signed-off-by:
Simon Ser <contact@emersion.fr> Fixes: 626bf90f ("drm/amd/display: add basic atomic check for cursor plane") Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
-
- 26 May, 2020 2 commits
-
-
Kevin Wang authored
the origin design will use varible of "attr->states" to save node supported states on current gpu device, but for multi gpu device, when probe second gpu device, the driver will check attribute node states from previous gpu device wthether to create attribute node. it will cause other gpu device create attribute node faild. 1. add member attr_list into amdgpu_device to link supported device attribute node. 2. add new structure "struct amdgpu_device_attr_entry{}" to track device attribute state. 3. drop member "states" from amdgpu_device_attr. v2: 1. move "attr_list" into amdgpu_pm and rename to "pm_attr_list". 2. refine create & remove device node functions parameter. fix: drm/amdgpu: optimize amdgpu device attribute code Signed-off-by:Kevin Wang <kevin1.wang@amd.com> Reviewed-by:
-
Dave Airlie authored
nouveau was calling the fbdev API which has issues with modules and built-ins. Call the correct API. Reported-by:
Randy Dunlap <rdunlap@infradead.org> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Fixes: 2dd4d163 ("drm/nouveau: remove open-coded version of remove_conflicting_pci_framebuffers()") Link: https://lore.kernel.org/lkml/21b52c28-3ace-cd13-d8ce-f38f2c6b2a96@infradead.org/T/#uSigned-off-by:
-
- 25 May, 2020 5 commits
-
-
Chris Wilson authored
Our __sgt_iter assumes that the scattergather list has at least one element. But during construction we may fail in allocating the first page, and so mark the first element as the terminator. This is unexpected! [22555.524752] RIP: 0010:shmem_get_pages+0x506/0x710 [i915] [22555.524759] Code: 49 8b 2c 24 31 c0 66 89 44 24 40 48 85 ed 0f 84 62 01 00 00 4c 8b 75 00 8b 5d 08 44 8b 7d 0c 48 8b 0d 7e 34 07 e2 49 83 e6 fc <49> 8b 16 41 01 df 48 89 cf 48 89 d0 48 c1 e8 2d 48 85 c9 0f 84 c8 [22555.524765] RSP: 0018:ffffc9000053f9d0 EFLAGS: 00010246 [22555.524770] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8881ffffa000 [22555.524774] RDX: fffffffffffffff4 RSI: ffffffffffffffff RDI: ffffffff821efe00 [22555.524778] RBP: ffff8881b099ab00 R08: 0000000000000000 R09: 00000000fffffff4 [22555.524782] R10: 0000000000000002 R11: 00000000ffec0a02 R12: ffff8881cd3c8d60 [22555.524786] R13: 00000000fffffff4 R14: 0000000000000000 R15: 0000000000000000 [22555.524790] FS: 00007f4fbeb9b9c0(0000) GS:ffff8881f8580000(0000) knlGS:0000000000000000 [22555.524795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22555.524799] CR2: 0000000000000000 CR3: 00000001ec7f0004 CR4: 00000000001606e0 [22555.524803] Call Trace: [22555.524919] __i915_gem_object_get_pages+0x4f/0x60 [i915] Fixes: 85d1225e ("drm/i915: Introduce & use new lightweight SGL iterators") Signed-off-by:
Maciej Patelczyk <maciej.patelczyk@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200522132706.5133-1-chris@chris-wilson.co.uk (cherry picked from commit 957ad9a0) Signed-off-by:
-
Chris Wilson authored
In order to be valid to dereference during the i915_fence_release, after retiring the fence and releasing its refererences, we assume that rq->engine can only be a real engine (that stay intact until the device is shutdown after all fences have been flushed). However, due to a quirk of preempt-to-busy, we may retire a request that still belongs to a virtual engine and so eventually free it with rq->engine being invalid. To avoid dereferencing that invalid engine, we look at the execution_mask which if it indicates it may be executed on more than one engine, we know it originated on a virtual engine and may still be on one. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/1906 Fixes: 43acd651 ("drm/i915: Keep a per-engine request pool") Signed-off-by:
-
Chris Wilson authored
Since the removal of the no-semaphore boosting, we rely on timeslicing to reorder passed inter-dependency hogs across the engines. However, we require preemption to support timeslicing into user payloads, and not all machine support preemption so we do not universally enable timeslicing, even when it would correctly preempt our own inter-engine semaphores. Since timeslicing and semaphore priority deboosting is now disabled on Broadwell/Braswell, we have to follow suite and not use semaphores. Testcase: igt/gem_exec_schedule/semaphore-codependency # bdw/bsw Fixes: 18e4af04 ("drm/i915: Drop no-semaphore boosting") Signed-off-by:
-
Chris Wilson authored
This assertion was removed in commit b412c63f ("drm/i915/gt: Report context-is-closed prior to pinning"), but accidentally restored by a cherry-pick into drm-next and now has percolated back to drm-intel-next-queued. Fixes: 2e46a2a0 ("drm/i915: Use explicit flag to mark unreachable intel_context") Fixes: 2b703bbd ("Merge drm/drm-next into drm-intel-next-queued") References: b412c63f ("drm/i915/gt: Report context-is-closed prior to pinning") Signed-off-by:
-
Chris Wilson authored
We recorded the execlists->queue_priority_hint update for the inflight request without kicking the tasklet. The next submitted request then failed to be scheduled as it had a lower priority than the hint, leaving the HW running with only the inflight request. Fixes: 6cebcf74 ("drm/i915: Tweak scheduler's kick_submission()") Signed-off-by:
-
- 22 May, 2020 3 commits
-
-
Lyude Paul authored
On some architectures like ppc64le and aarch64, compiling with -Wformat=1 will throw the following warnings: In file included from drivers/gpu/drm/drm_vblank.c:33: drivers/gpu/drm/drm_vblank.c: In function 'drm_update_vblank_count': drivers/gpu/drm/drm_vblank.c:273:16: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 4 has type 'long int' [-Wformat=] DRM_DEBUG_VBL("updating vblank count on crtc %u:" ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ./include/drm/drm_print.h:407:22: note: in definition of macro 'DRM_DEBUG_VBL' drm_dbg(DRM_UT_VBL, fmt, ##__VA_ARGS__) ^~~ drivers/gpu/drm/drm_vblank.c:274:22: note: format string is defined here " current=%llu, diff=%u, hw=%u hw_last=%u\n", ~~~^ %lu So, fix that with a typecast. Co-developed-by:Lyude Paul <lyude@redhat.com> Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20200521204647.2578479-1-lyude@redhat.com
-
Felix Kuehling authored
This fixes an intermittent bug where a root PD clear operation still in progress could overwrite a PDE update done by the CPU, resulting in a VM fault. Fixes: 108b4d92 ("drm/amd/amdgpu: Update VM function pointer") Reported-by:
Jay Cornwall <Jay.Cornwall@amd.com> Tested-by:
Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by:
Christian König <christian.koenig@amd.com> Signed-off-by:
-
Bhawanpreet Lakha authored
[Why] Previously we used the s3 codepath for gpu reset. This can lead to issues in certain case where we end of waiting for fences which will never come (because parts of the hw are off due to gpu reset) and we end up waiting forever causing a deadlock. [How] Handle GPU reset separately from normal s3 case. We essentially need to redo everything we do in s3, but avoid any drm calls. For GPU reset case suspend: -Acquire DC lock -Cache current dc_state -Commit 0 stream/planes to dc (this puts dc into a state where it can be powered off) -Disable interrupts resume -Edit cached state to force full update -Commit cached state from suspend -Build stream and plane updates from the cached state -Commit stream/plane updates -Enable interrupts -Release DC lock v2: -Formatting -Release dc_state Signed-off-by:
Bhawanpreet Lakha <Bhawanpreet.Lakha@amd.com> Acked-by:
-
