- 26 Jan, 2022 6 commits
-
-
Daniele Ceraolo Spurio authored
Starting from DG2, some of the programming previously done by i915 and the GuC has been moved to the GSC and the relevant registers are no longer writable by either CPU or GuC. This is also referred to as GuC deprivilege. On the i915 side, this affects the WOPCM registers: these are no longer programmed by the driver and we do instead expect to find them already set. This can lead to verification failures because in i915 we cheat a bit with the WOPCM size defines, to keep the code common across platforms, by sometimes using a smaller WOPCM size that the actual HW support (which isn't a problem because the extra size is not needed if the FW fits in the smaller chunk), while the pre-programmed values can use the actual size. Given tha the new programming entity is trusted, relax the amount of the checks done on the pre-programmed values by not limiting the max programmed size. In the extremely unlikely scenario that the registers have been misprogrammed, we will still fail later at DMA time. v2: drop special case for DG2 G10 A0 (Alan) Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Stuart Summers <stuart.summers@intel.com> Cc: John Harrison <john.c.harrison@intel.com> Cc: Alan Previn <alan.previn.teres.alexis@intel.com> Reviewed-by:
Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120212947.3440448-1-daniele.ceraolospurio@intel.com
-
Anusha Srivatsa authored
Add stepping-substepping info in accordance to BSpec changes. Though it looks weird, the revision ID for the newer stepping is indeed backwards and is in accordance to the spec. v2: Rearrange the platforms in logical order (Matt) Bspec: 53655 Cc: Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
-
Thomas Hellström authored
In some cases we use leftover kfree() instead of i915_vma_resource_free(). Fix this. Fixes: 2f6b90da ("drm/i915: Use vma resources for async unbinding") Reported-by:
Robert Beckett <bob.beckett@collabora.com> Cc: Matthew Auld <matthew.auld@intel.com> Signed-off-by:
Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220119174734.213552-1-thomas.hellstrom@linux.intel.com
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version, in order to avoid any potential type mistakes or integer overflows that, in the worst scenario, could lead to heap overflows. Also, address the following sparse warnings: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:792:23: warning: using sizeof on a flexible structure Link: https://github.com/KSPP/linux/issues/174Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by:
-
Umesh Nerlige Ramappa authored
All timestamps returned by GuC for GuC PMU busyness are captured from GUC PM TIMESTAMP. Since this timestamp does not tick when GuC goes idle, kmd uses RING_TIMESTAMP to measure busyness of an engine with an active context. In further stress testing, the MMIO read of the RING_TIMESTAMP is seen to cause a rare hang. Resolve the issue by using gt specific timestamp from PM which is in sync with the GuC PM timestamp. Fixes: 77cdd054 ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Signed-off-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220111015523.225562-1-umesh.nerlige.ramappa@intel.com
-
Matthew Brost authored
Using more guc_ids in the stealing guc id test has no real benefit. Tearing down lots of contexts all at the same time takes a bit of time due to the H2G / G2H ping-pong with the GuC. On some slower platforms this can cause timeous when flushing the test as the GT isn't idle when this ping-pong is happening. Reduce the number of guc ids to speed up the flushing of the test. Link: https://gitlab.freedesktop.org/drm/intel/-/issues/4821Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
- 25 Jan, 2022 1 commit
-
-
Matthew Brost authored
Realized that the GuC multi-lrc fini breadcrumb emit code is very delicate as the math this code does relies on functions it calls to emit a certain number of DWs. Add a few GEM_BUG_ONs to assert the math is correct. v2: - Rebase + resend for CI (Checkpatch) - Fix blank line warning Signed-off-by:
-
- 24 Jan, 2022 2 commits
-
-
Matt Roper authored
A few more MOD registers need to be programmed on DG2. Signed-off-by:
Swathi Dhanavanthri <swathi.dhanavanthri@intel.com>
-
Andi Shyti authored
Replace "linux/slab.h" with "linux/sched/mm.h" header inclusion as the first is not required, while the second, if not included, prodouces the following error: drivers/gpu/drm/i915/i915_vma_resource.c: In function ‘i915_vma_resource_bind_dep_await’: drivers/gpu/drm/i915/i915_vma_resource.c:381:9: error: implicit declaration of function ‘might_alloc’; did you mean ‘might_lock’? [-Werror=implicit-function-declaration] 381 | might_alloc(gfp); | ^~~~~~~~~~~ | might_lock Fixes: 2f6b90da ("drm/i915: Use vma resources for async unbinding") Signed-off-by:Andi Shyti <andi.shyti@linux.intel.com> Cc: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220124094418.2661-1-andi.shyti@linux.intel.com
-
- 22 Jan, 2022 1 commit
-
-
Matthew Brost authored
Don't use the interruptable version of the timeline mutex lock in the error path of eb_pin_timeline as the cleanup must always happen. v2: (John Harrison) - Don't check for interrupt during mutex lock v3: (Tvrtko) - A comment explaining why lock helper isn't used Fixes: 544460c3 ("drm/i915: Multi-BB execbuf") Signed-off-by:
-
- 21 Jan, 2022 3 commits
-
-
Matthew Brost authored
Now that the error capture is fully decoupled from fence signalling (request retirement to free memory, which in turn depends on resets) we can safely flush the G2H handler during a GT reset. This eliminates corner cases where GuC generated G2H (e.g. engine resets) race with a GT reset. v2: (John Harrison) - Fix typo in commit message (s/is/in) Signed-off-by:
-
Matthew Brost authored
The G2H handler needs to be flushed during a GT reset but a G2H indicating engine reset failure can trigger a GT reset. Add a worker to trigger the GT rest when an engine reset failure is received to break this circular dependency. v2: (John Harrison) - Store engine reset mask - Fix typo in commit message v3: (John Harrison) - Fix another typo in commit message - s/reset_*/reset_fail_*/ Signed-off-by:
-
Matthew Brost authored
Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than GFP_KERNEL to fully decouple the error capture from fence signalling. v2: (John Harrison) - Fix typo in commit message (s/do/to) Fixes: 8b91cdd4 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code") Signed-off-by:
-
- 19 Jan, 2022 2 commits
-
-
Matthew Brost authored
In the i915 there are several hacks in place to make request cancellation work with an old version of the GuC which delivered the G2H indicating schedule disable is done before G2H indicating a context reset. Version 69 fixes this, so we can remove these hacks. v2: (Checkpatch) - s/cancelation/cancellation Reviewed-by:
-
Matthew Brost authored
Add a cancel request selftest that results in an engine reset to cancel the request as it is non-preemptable. Also insert a NOP request after the cancelled request and confirm that it completes successfully. v2: (Tvrtko) - Skip test if preemption timeout compiled out - Skip test if engine reset isn't supported - Update debug prints to be more descriptive v3: - Add comment explaining test v4: (John Harrison) - Fix typos in comment explaining test - goto out_rq is NOP creation fails Signed-off-by:
-
- 18 Jan, 2022 7 commits
-
-
Maarten Lankhorst authored
Add a flag PIN_VALIDATE, to indicate we don't need to pin and only protected by the object lock. This removes the need to unpin, which is done by just releasing the lock. eb_reserve is slightly reworked for readability, but the same steps are still done: - First pass pins with NONBLOCK. - Second pass unbinds all objects first, then pins. - Third pass is only called when not all objects are softpinned, and unbinds all objects, then calls i915_gem_evict_vm(), then pins. Changes since v1: - Split out eb_reserve() into separate functions for readability. Changes since v2: - Make batch buffer mappable on platforms where only GGTT is available, to prevent moving the batch buffer during relocations. Changes since v3: - Preserve current behavior for batch buffer, instead be cautious when calling i915_gem_object_ggtt_pin_ww, and re-use the current batch vma if it's inside ggtt and map-and-fenceable. - Remove impossible condition check from eb_reserve. (Matt) Changes since v5: - Do not even temporarily pin, just call i915_gem_evict_vm() and mark all vma's as unpinned. Signed-off-by:
-
Maarten Lankhorst authored
Now that we require the object lock for all ops, some code handling race conditions can be removed. This is required to not take short-term pins inside execbuf. Signed-off-by:
Niranjana Vishwanathapura <niranjana.vishwanathapura@intel.com> Reviewed-by:
-
Maarten Lankhorst authored
We want to remove more members of i915_vma, which requires the locking to be held more often. Start requiring gem object lock for i915_vma_unbind, as it's one of the callers that may unpin pages. Some special care is needed when evicting, because the last reference to the object may be held by the VMA, so after __i915_vma_unbind, vma may be garbage, and we need to cache vma->obj before unlocking. Changes since v1: - Make trylock failing a WARN. (Matt) - Remove double i915_vma_wait_for_bind() (Matt) - Move atomic_set to right before mutex_unlock(), to make it more clear they belong together. (Matt) Signed-off-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220114132320.109030-5-maarten.lankhorst@linux.intel.com
-
Maarten Lankhorst authored
Because we will start to require the obj->resv lock for unbinding, ensure these vma eviction utility functions also take the lock. This requires some function signature changes, to ensure that the ww context is passed around, but is mostly straightforward. Previously this was split up into several patches, but reworking should allow for easier bisection. Changes since v1: - Handle evicting dead objects better. Signed-off-by:
-
Maarten Lankhorst authored
i915_gem_evict_vm will need to be able to evict objects that are locked by the current ctx. By testing if the current context already locked the object, we can do this correctly. This allows us to evict the entire vm even if we already hold some objects' locks. Previously, this was spread over several commits, but it makes more sense to commit the changes to i915_gem_evict_vm separately from the changes to i915_gem_evict_something() and i915_gem_evict_for_node(). Changes since v1: - Handle evicting dead objects better. Changes since v2: - Use for_i915_gem_ww in igt_evict_vm. (Thomas) Signed-off-by:
-
Maarten Lankhorst authored
Now that we cannot unbind kill the currently locked object directly because we're removing short term pinning, we may have to unbind the object from gtt manually, using a i915_gem_evict_vm() call. Changes since v1: - Remove -ENOSPC warning, can still happen with concurrent mmaps where we can't unbind the other mmap because of the lock held. This fixes the gem_mmap_gtt@cpuset tests. Signed-off-by:
-
Tvrtko Ursulin authored
Maarten needs backmerge to account for header file renames/changes which landed via drm-intel-next and are interfering with his pinning work. Signed-off-by:
-
- 14 Jan, 2022 9 commits
-
-
Colin Ian King authored
Don't populate the read-only array flex_regs on the stack but instead it static const. Also makes the object code a little smaller. Signed-off-by:
Colin Ian King <colin.i.king@gmail.com> Signed-off-by:
-
Daniel Vetter authored
Merge tag 'amd-drm-next-5.17-2022-01-12' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-next-5.17-2022-01-12: amdgpu: - SR-IOV fixes - Suspend/resume fixes - Display fixes - DMCUB fixes - DP alt mode fixes - RAS fixes - UBSAN fix - Navy Flounder VCN fix - ttm resource manager cleanup - default_groups change for kobj_type - vkms fix - Aldebaran fixes amdkfd: - SDMA ECC interrupt fix - License clarification - Pointer check fix - DQM fixes for hawaii - default_groups change for kobj_type - Typo fixes Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220113030537.5758-1-alexander.deucher@amd.com
-
Daniel Vetter authored
Merge tag 'drm-misc-next-fixes-2022-01-14' of git://anongit.freedesktop.org/drm/drm-misc into drm-next * atomic helpers: Fix error messages * mipi-dbi: Fix buffer mapping Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDaniel Vetter authored
Two DT bindings fixes for meson, a device refcounting fix for sun4i, a probe fix for vga16fb, a locking fix for the CMA dma-buf heap and a compilation fix for ttm. Signed-off-by:
-
Thomas Zimmermann authored
Set the source-buffer address after mapping the buffer into the kernel's address space. Makes MIPI DBI helpers work again. Signed-off-by:
Thomas Zimmermann <tzimmermann@suse.de> Fixes: c47160d8 ("drm/mipi-dbi: Remove dependency on GEM CMA helper library") Reviewed-by:
Noralf Trønnes <noralf@tronnes.org> Reported-by:
-
Claudio Suarez authored
The patch d1af5cd86997 ("drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_a*.c") fails when the drm_device cannot be found in the parameter plane_state->crtc. Fix it using plane_state->plane. Reported-by:kernel test robot <oliver.sang@intel.com> Fixes: 6e22dc35 ("drm: get rid of DRM_DEBUG_* log calls in drm core, files drm_a*.c") Signed-off-by:
Claudio Suarez <cssk@net-c.es> [danvet: fix Fixes: line] Signed-off-by:
-
Daniel Vetter authored
Merge tag 'drm-misc-next-fixes-2022-01-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next * Fix use of CRTC state's active vs enable in atomic helper Signed-off-by:
-
Daniel Vetter authored
Merge tag 'drm-intel-next-fixes-2022-01-13' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Hold runtime PM wakelock during PXP unbind (Juston Li) - Three fixes for the TTM backend fault handling (Matthew Auld) - Make sure to unmap when purging in the TTM backend (Matthew Auld) Signed-off-by:
-
Johannes Berg authored
Even if it's probably not really useful, it can get selected by e.g. randconfig builds, and then failing to compile is an annoyance. Unfortunately, it's hard to fix in Kconfig, since DRM_TTM is selected by many things that don't really depend on any specific architecture, and just depend on PCI (which is indeed now available in ARCH=um via simulation/emulation). Fix this in the code instead by just ifdef'ing the relevant two lines that depend on "real X86". Reported-by:
Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com> Signed-off-by:
-
- 13 Jan, 2022 1 commit
-
-
Weizhao Ouyang authored
Fix cma_heap_buffer mutex locking critical section to protect vmap_cnt and vaddr. Fixes: a5d2d29e ("dma-buf: heaps: Move heap-helper logic into the cma_heap implementation") Signed-off-by:
Weizhao Ouyang <o451686892@gmail.com> Acked-by:
John Stultz <john.stultz@linaro.org> Signed-off-by:
Sumit Semwal <sumit.semwal@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20220104073545.124244-1-o451686892@gmail.com
-
- 12 Jan, 2022 1 commit
-
-
Javier Martinez Canillas authored
The vga16fb framebuffer driver only supports Enhanced Graphics Adapter (EGA) and Video Graphics Array (VGA) 16 color graphic cards. But it doesn't check if the adapter is one of those or if a VGA16 mode is used. This means that the driver will be probed even if a VESA BIOS Extensions (VBE) or Graphics Output Protocol (GOP) interface is used. This issue has been present for a long time but it was only exposed by commit d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") since the platform device registration to match the {vesa,efi}fb drivers is done later as a consequence of that change. All non-x86 architectures though treat orig_video_isVGA as a boolean so only do the supported video mode check for x86 and not for other arches. Link: https://bugzilla.kernel.org/show_bug.cgi?id=215001 Fixes: d391c582 ("drivers/firmware: move x86 Generic System Framebuffers support") Reported-by:
Kris Karas <bugs-a21@moonlit-rail.com> Cc: <stable@vger.kernel.org> # 5.15.x Signed-off-by:
Javier Martinez Canillas <javierm@redhat.com> Tested-by:
Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20220110095625.278836-3-javierm@redhat.com
-
- 11 Jan, 2022 7 commits
-
-
Kent Russell authored
Three misspelled ASICs in comments here, so fix the spelling Signed-off-by:
Kent Russell <kent.russell@amd.com> Reviewed-by:
Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
Felix Kuehling authored
start_nocpsch would never set dqm->sched_running on Hawaii due to an early return statement. This would trigger asserts in other functions and end up in inconsistent states. Bug: https://github.com/RadeonOpenCompute/ROCm/issues/1624Signed-off-by:
-
Harry Wentland authored
For some reason this file isn't using the appropriate register headers for DCN headers, which means that on DCN2 we're getting the VIEWPORT_DIMENSION offset wrong. This means that we're not correctly carving out the framebuffer memory correctly for a framebuffer allocated by EFI and therefore see corruption when loading amdgpu before the display driver takes over control of the framebuffer scanout. Fix this by checking the DCE_HWIP and picking the correct offset accordingly. Long-term we should expose this info from DC as GMC shouldn't need to know about DCN registers. Cc: stable@vger.kernel.org Signed-off-by:
Harry Wentland <harry.wentland@amd.com> Reviewed-by:
Huang Rui <ray.huang@amd.com> Acked-by:
Christian König <christian.koenig@amd.com> Reviewed-by:
-
Tao Zhou authored
PMFW only returns 0 on master die and sends NACK back on other dies for the message. v2: only send GmiPwrDnControl msg on master die instead of all dies. v3: remove the pointer check for get_socket_id and get_die_id as they should be present on Aldebaran. Signed-off-by:
Tao Zhou <tao.zhou1@amd.com> Reviewed-by:
Lijo Lazar <lijo.lazar@amd.com> Signed-off-by:
-
Guchun Chen authored
This is observed in SRIOV case with virtual KMS as display. _raw_spin_lock_irqsave+0x37/0x40 drm_handle_vblank+0x69/0x350 [drm] ? try_to_wake_up+0x432/0x5c0 ? amdgpu_vkms_prepare_fb+0x1c0/0x1c0 [amdgpu] drm_crtc_handle_vblank+0x17/0x20 [drm] amdgpu_vkms_vblank_simulate+0x4d/0x80 [amdgpu] __hrtimer_run_queues+0xfb/0x230 hrtimer_interrupt+0x109/0x220 __sysvec_apic_timer_interrupt+0x64/0xe0 asm_call_irq_on_stack+0x12/0x20 Fixes: 84ec374b ("drm/amdgpu: create amdgpu_vkms (v4)") Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Acked-by:
Kelly Zytaruk <kelly.zytaruk@amd.com> Signed-off-by:
-
Prike Liang authored
In some APU project we needn't always assign flags to identify each other, so we may not need return an error. Signed-off-by:
Prike Liang <Prike.Liang@amd.com> Reviewed-by:
-
Felix Kuehling authored
The remove_list head was only used for keeping track of existing ranges that are to be removed from the svms->list. The update_list was used for new or existing ranges that need updated attributes. These two cases are mutually exclusive (i.e. the same range will never be on both lists). Therefore we can use the update_list head to track the remove_list and save another 16 bytes in the svm_range struct. Signed-off-by:
Philip Yang <Philip.Yang@amd.com> Signed-off-by:
-
