- 20 Jan, 2022 2 commits
-
-
Dave Airlie authored
Merge tag 'amd-drm-fixes-5.17-2022-01-19' of https://gitlab.freedesktop.org/agd5f/linux into drm-next amd-drm-fixes-5.17-2022-01-19: amdgpu: - SR-IOV fix - VCN harvest fix - Suspend/resume fixes - Tahiti fix - Enable GPU recovery on yellow carp radeon: - Fix error handling regression in radeon_driver_open_kms Signed-off-by:
Dave Airlie <airlied@redhat.com> From: Alex Deucher <alexander.deucher@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220120013547.5649-1-alexander.deucher@amd.com
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2022-01-20' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - Latest updates for the EHL display voltage swing table (José Roberto de Souza) - Additional step is required when programming the ADL-P display TC voltage swing (José Roberto de Souza) Signed-off-by:
-
- 18 Jan, 2022 3 commits
-
-
Christian König authored
The return value was never initialized so the cleanup code executed when it isn't even necessary. Just add proper error handling. Fixes: ab50cb9d ("drm/radeon/radeon_kms: Fix a NULL pointer dereference in radeon_driver_open_kms()") Signed-off-by:
Christian König <christian.koenig@amd.com> Tested-by:
Jan Stancek <jstancek@redhat.com> Tested-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Jingwen Chen authored
[Why] This fixes 892deb48 ("drm/amdgpu: Separate vf2pf work item init from virt data exchange"). we should read pf2vf data based at mman.fw_vram_usage_va after gmc sw_init. commit 892deb48 breaks this logic. [How] calling amdgpu_virt_exchange_data in amdgpu_virt_init_data_exchange to set the right base in the right sequence. v2: call amdgpu_virt_init_data_exchange after gmc sw_init to make data exchange workqueue run v3: clean up the code logic v4: add some comment and make the code more readable Fixes: 892deb48 ("drm/amdgpu: Separate vf2pf work item init from virt data exchange") Signed-off-by:
Jingwen Chen <Jingwen.Chen2@amd.com> Reviewed-by:
Horace Chen <horace.chen@amd.com> Signed-off-by:
-
Guchun Chen authored
This is a following patch to apply the workaround only on those boards with a bad harvest table in ip discovery. Signed-off-by:
Guchun Chen <guchun.chen@amd.com> Reviewed-by:
-
- 17 Jan, 2022 2 commits
-
-
José Roberto de Souza authored
TC voltage swing programming sequence was updated with a new step. BSpec: 54956 Cc: stable@vger.kernel.org Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20220113174826.50272-1-jose.souza@intel.com (cherry picked from commit 5ff59ddd) Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
-
José Roberto de Souza authored
EHL table was recently updated with some minor fixes. BSpec: 21257 Cc: stable@vger.kernel.org Cc: Clint Taylor <clinton.a.taylor@intel.com> Signed-off-by:
-
- 14 Jan, 2022 14 commits
-
-
Mario Limonciello authored
The WA from commit 2a50edbf ("drm/amd/display: Apply w/a for hard hang on HPD") and commit 1bd3bc74 ("drm/amd/display: Extend w/a for hard hang on HPD to dcn20") causes a regression in s0ix where the system will fail to resume properly on many laptops. Pull the workarounds out to avoid that s0ix regression in the common case. This HPD hang happens with an external device in special circumstances and a new W/A will need to be developed for this in the future. Cc: stable@vger.kernel.org Cc: Qingqing Zhuo <qingqing.zhuo@amd.com> Reported-by:
Scott Bruce <smbruce@gmail.com> Reported-by:
Chris Hixon <linux-kernel-bugs@hixontech.com> Reported-by: spasswolf@web.de Link: https://bugzilla.kernel.org/show_bug.cgi?id=215436 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1821 Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1852 Fixes: 2a50edbf ("drm/amd/display: Apply w/a for hard hang on HPD") Fixes: 1bd3bc74 ("drm/amd/display: Extend w/a for hard hang on HPD to dcn20") Reviewed-by:
Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by:
Mario Limonciello <mario.limonciello@amd.com> Signed-off-by:
-
Alex Deucher authored
Support for IP based discovery is in place now so this check is no longer required. Reviewed-by:
Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by:
-
Lukas Fink authored
eb4fd29a ("drm/amdgpu: bind to any 0x1002 PCI diplay class device") added generic bindings to amdgpu so that that it binds to all display class devices with VID 0x1002 and then rejects those in amdgpu_pci_probe. Unfortunately it reuses a driver_data value of 0 to detect those new bindings, which is already used to denote CHIP_TAHITI ASICs. The driver_data value given to those new bindings was changed in dd0761fd24ea1 ("drm/amdgpu: set CHIP_IP_DISCOVERY as the asic type by default") to CHIP_IP_DISCOVERY (=36), but it seems that the check in amdgpu_pci_probe was forgotten to be changed. Therefore, it still rejects Tahiti GPUs. Link: https://gitlab.freedesktop.org/drm/amd/-/issues/1860 Fixes: eb4fd29a ("drm/amdgpu: bind to any 0x1002 PCI diplay class device") Cc: stable@vger.kernel.org Signed-off-by:
Lukas Fink <lukas.fink1@gmail.com> Signed-off-by:
-
Alex Deucher authored
It can cause a hang. This is normally not enabled for GPU hangs on these asics, but was recently enabled for handling aborted suspends. This causes hangs on some platforms on suspend. Fixes: daf8de08 ("drm/amdgpu: always reset the asic in suspend (v2)") Cc: stable@vger.kernel.org Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1858Signed-off-by:
-
Alex Deucher authored
Rather than opting into GPU recovery support, default to on, and opt out if it's not working on a particular GPU. This avoids the need to add new asics to this list since this is a core feature. Reviewed-by:
Evan Quan <evan.quan@amd.com> Reviewed-by:
-
CHANDAN VURDIGERE NATARAJ authored
Add yellow carp to devices which support recovery Signed-off-by:
CHANDAN VURDIGERE NATARAJ <chandan.vurdigerenataraj@amd.com> Reviewed-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 17 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:
-
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:
-
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:
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:
-
Felix Kuehling authored
There are seven list_heads in struct svm_range: list, update_list, remove_list, insert_list, svm_bo_list, deferred_list, child_list. This patch and the next one remove two of them that are redundant. The insert_list head was only used for new ranges that are not on the svms->list yet. So we can use that list head for keeping track of new ranges before they get added, and use list_move_tail to move them to the svms->list when ready. Signed-off-by:
-
Lukas Bulwahn authored
Commit b5f57384 ("drm/amdkfd: Add sysfs bitfields and enums to uAPI") adds include/uapi/linux/kfd_sysfs.h with the "GPL-2.0 OR MIT WITH Linux-syscall-note" SPDX-License expression. The command ./scripts/spdxcheck.py warns: include/uapi/linux/kfd_sysfs.h: 1:48 Exception not valid for license MIT: Linux-syscall-note For a uapi header, the file under GPLv2 License must be combined with the Linux-syscall-note, but combining the MIT License with the Linux-syscall-note makes no sense, as the note provides an exception for GPL-licensed code, not for permissively licensed code. So, reorganize the SPDX expression to only combine the note with the GPL License condition. This makes spdxcheck happy again. Fixes: b5f57384 ("drm/amdkfd: Add sysfs bitfields and enums to uAPI") Signed-off-by:
Lukas Bulwahn <lukas.bulwahn@gmail.com> Reviewed-by: kstewart@linuxfoundation.org Reviewed-by:
-
Jiasheng Jiang authored
As the possible failure of the allocation, kmemdup() may return NULL pointer. Therefore, it should be better to check the 'props2' in order to prevent the dereference of NULL pointer. Fixes: 3a87177e ("drm/amdkfd: Add topology support for dGPUs") Signed-off-by:
Jiasheng Jiang <jiasheng@iscas.ac.cn> Reviewed-by:
-
José Expósito authored
The function performs a check on the "adev" input parameter, however, it is used before the check. Initialize the "dev" variable after the sanity check to avoid a possible NULL pointer dereference. Fixes: e27c41d5 ("drm/amd/display: Support for DMUB HPD interrupt handling") Addresses-Coverity-ID: 1493909 ("Null pointer dereference") Reviewed-by:
José Expósito <jose.exposito89@gmail.com> Signed-off-by:
-
Rajneesh Bhardwaj authored
This reverts commit fbcdbfde. Reviewed-by:
Rajneesh Bhardwaj <rajneesh.bhardwaj@amd.com> Signed-off-by:
-
Mario Limonciello authored
Otherwise future commands may fail as well leading to downstream problems that look like they stemmed from a timeout the first time but really didn't. Signed-off-by:
-
Greg Kroah-Hartman authored
There are currently 2 ways to create a set of sysfs files for a kobj_type, through the default_attrs field, and the default_groups field. Move the amdkfd sysfs code to use default_groups field which has been the preferred way since aa30f47c ("kobject: Add support for default attribute groups to kobj_type") so that we can soon get rid of the obsolete default_attrs field. Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
-
Greg Kroah-Hartman authored
There are currently 2 ways to create a set of sysfs files for a kobj_type, through the default_attrs field, and the default_groups field. Move the amdgpu sysfs code to use default_groups field which has been the preferred way since aa30f47c ("kobject: Add support for default attribute groups to kobj_type") so that we can soon get rid of the obsolete default_attrs field. Cc: Alex Deucher <alexander.deucher@amd.com> Cc: "Christian König" <christian.koenig@amd.com> Cc: "Pan, Xinhui" <Xinhui.Pan@amd.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: Hawking Zhang <Hawking.Zhang@amd.com> Cc: John Clements <john.clements@amd.com> Cc: Felix Kuehling <Felix.Kuehling@amd.com> Cc: Jonathan Kim <jonathan.kim@amd.com> Cc: Kevin Wang <kevin1.wang@amd.com> Cc: shaoyunl <shaoyun.liu@amd.com> Cc: Tao Zhou <tao.zhou1@amd.com> Cc: amd-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by:
-
Tom St Denis authored
The function amdgpu_mm_wreg_mmio_rlc() is used by debugfs to write to MMIO registers. It didn't support registers beyond the BAR mapped MMIO space. This adds pcie indirect write support. Signed-off-by:
Tom St Denis <tom.stdenis@amd.com> Acked-by:
-
Nirmoy Das authored
Get rid off pin/unpin of gart BO at resume/suspend and instead pin only once and try to recover gart content at resume time. This is much more stable in case there is OOM situation at 2nd call to amdgpu_device_evict_resources() while evicting GART table. v3: remove gart recovery from other places v2: pin gart at amdgpu_gart_table_vram_alloc() Reviewed-by:
Nirmoy Das <nirmoy.das@amd.com> Signed-off-by:
-
