summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2021-01-12drm/i915: clear the gpu reloc batchMatthew Auld
commit 641382e9b44fba81a0778e1914ee35b8471121f9 upstream. The reloc batch is short lived but can exist in the user visible ppGTT, and since it's backed by an internal object, which lacks page clearing, we should take care to clear it upfront. Signed-off-by: Matthew Auld <matthew.auld@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201224151358.401345-2-matthew.auld@intel.com Cc: stable@vger.kernel.org (cherry picked from commit 26ebc511e799f621357982ccc37a7987a56a00f4) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-01-09Revert "drm/amd/display: Fix memory leaks in S3 resume"Alex Deucher
This reverts commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362. This leads to blank screens on some boards after replugging a display. Revert until we understand the root cause and can fix both the leak and the blank screen after replug. Cc: Stylon Wang <stylon.wang@amd.com> Cc: Harry Wentland <harry.wentland@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Cc: Andre Tomt <andre@tomt.net> Cc: Oleksandr Natalenko <oleksandr@natalenko.name> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30drm/i915: Fix mismatch between misplaced vma check and vma insertChris Wilson
commit 0e53656ad8abc99e0a80c3de611e593ebbf55829 upstream. When inserting a VMA, we restrict the placement to the low 4G unless the caller opts into using the full range. This was done to allow usersapce the opportunity to transition slowly from a 32b address space, and to avoid breaking inherent 32b assumptions of some commands. However, for insert we limited ourselves to 4G-4K, but on verification we allowed the full 4G. This causes some attempts to bind a new buffer to sporadically fail with -ENOSPC, but at other times be bound successfully. commit 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page") suggests that there is a genuine problem with stateless addressing that cannot utilize the last page in 4G and so we purposefully excluded it. This means that the quick pin pass may cause us to utilize a buggy placement. Reported-by: CQ Tang <cq.tang@intel.com> Testcase: igt/gem_exec_params/larger-than-life-batch Fixes: 48ea1e32c39d ("drm/i915/gen9: Set PIN_ZONE_4G end to 4GB - 1 page") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: CQ Tang <cq.tang@intel.com> Reviewed-by: CQ Tang <cq.tang@intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v4.5+ Link: https://patchwork.freedesktop.org/patch/msgid/20201216092951.7124-1-chris@chris-wilson.co.uk (cherry picked from commit 5f22cc0b134ab702d7f64b714e26018f7288ffee) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30drm/dp_aux_dev: check aux_dev before use in drm_dp_aux_dev_get_by_minor()Zwane Mwaikambo
commit 73b62cdb93b68d7e2c1d373c6a411bc00c53e702 upstream. I observed this when unplugging a DP monitor whilst a computer is asleep and then waking it up. This left DP chardev nodes still being present on the filesystem and accessing these device nodes caused an oops because drm_dp_aux_dev_get_by_minor() assumes a device exists if it is opened. This can also be reproduced by creating a device node with mknod(1) and issuing an open(2) [166164.933198] BUG: kernel NULL pointer dereference, address: 0000000000000018 [166164.933202] #PF: supervisor read access in kernel mode [166164.933204] #PF: error_code(0x0000) - not-present page [166164.933205] PGD 0 P4D 0 [166164.933208] Oops: 0000 [#1] PREEMPT SMP NOPTI [166164.933211] CPU: 4 PID: 99071 Comm: fwupd Tainted: G W 5.8.0-rc6+ #1 [166164.933213] Hardware name: LENOVO 20RD002VUS/20RD002VUS, BIOS R16ET25W (1.11 ) 04/21/2020 [166164.933232] RIP: 0010:drm_dp_aux_dev_get_by_minor+0x29/0x70 [drm_kms_helper] [166164.933234] Code: 00 0f 1f 44 00 00 55 48 89 e5 41 54 41 89 fc 48 c7 c7 60 01 a4 c0 e8 26 ab 30 d7 44 89 e6 48 c7 c7 80 01 a4 c0 e8 47 94 d6 d6 <8b> 50 18 49 89 c4 48 8d 78 18 85 d2 74 33 8d 4a 01 89 d0 f0 0f b1 [166164.933236] RSP: 0018:ffffb7d7c41cbbf0 EFLAGS: 00010246 [166164.933237] RAX: 0000000000000000 RBX: ffff8a90001fe900 RCX: 0000000000000000 [166164.933238] RDX: 0000000000000000 RSI: 0000000000000003 RDI: ffffffffc0a40180 [166164.933239] RBP: ffffb7d7c41cbbf8 R08: 0000000000000000 R09: ffff8a93e157d6d0 [166164.933240] R10: 0000000000000000 R11: ffffffffc0a40188 R12: 0000000000000003 [166164.933241] R13: ffff8a9402200e80 R14: ffff8a90001fe900 R15: 0000000000000000 [166164.933244] FS: 00007f7fb041eb00(0000) GS:ffff8a9411500000(0000) knlGS:0000000000000000 [166164.933245] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [166164.933246] CR2: 0000000000000018 CR3: 00000000352c2003 CR4: 00000000003606e0 [166164.933247] Call Trace: [166164.933264] auxdev_open+0x1b/0x40 [drm_kms_helper] [166164.933278] chrdev_open+0xa7/0x1c0 [166164.933282] ? cdev_put.part.0+0x20/0x20 [166164.933287] do_dentry_open+0x161/0x3c0 [166164.933291] vfs_open+0x2d/0x30 [166164.933297] path_openat+0xb27/0x10e0 [166164.933306] ? atime_needs_update+0x73/0xd0 [166164.933309] do_filp_open+0x91/0x100 [166164.933313] ? __alloc_fd+0xb2/0x150 [166164.933316] do_sys_openat2+0x210/0x2d0 [166164.933318] do_sys_open+0x46/0x80 [166164.933320] __x64_sys_openat+0x20/0x30 [166164.933328] do_syscall_64+0x52/0xc0 [166164.933336] entry_SYSCALL_64_after_hwframe+0x44/0xa9 (gdb) disassemble drm_dp_aux_dev_get_by_minor+0x29 Dump of assembler code for function drm_dp_aux_dev_get_by_minor: 0x0000000000017b10 <+0>: callq 0x17b15 <drm_dp_aux_dev_get_by_minor+5> 0x0000000000017b15 <+5>: push %rbp 0x0000000000017b16 <+6>: mov %rsp,%rbp 0x0000000000017b19 <+9>: push %r12 0x0000000000017b1b <+11>: mov %edi,%r12d 0x0000000000017b1e <+14>: mov $0x0,%rdi 0x0000000000017b25 <+21>: callq 0x17b2a <drm_dp_aux_dev_get_by_minor+26> 0x0000000000017b2a <+26>: mov %r12d,%esi 0x0000000000017b2d <+29>: mov $0x0,%rdi 0x0000000000017b34 <+36>: callq 0x17b39 <drm_dp_aux_dev_get_by_minor+41> 0x0000000000017b39 <+41>: mov 0x18(%rax),%edx <========= 0x0000000000017b3c <+44>: mov %rax,%r12 0x0000000000017b3f <+47>: lea 0x18(%rax),%rdi 0x0000000000017b43 <+51>: test %edx,%edx 0x0000000000017b45 <+53>: je 0x17b7a <drm_dp_aux_dev_get_by_minor+106> 0x0000000000017b47 <+55>: lea 0x1(%rdx),%ecx 0x0000000000017b4a <+58>: mov %edx,%eax 0x0000000000017b4c <+60>: lock cmpxchg %ecx,(%rdi) 0x0000000000017b50 <+64>: jne 0x17b76 <drm_dp_aux_dev_get_by_minor+102> 0x0000000000017b52 <+66>: test %edx,%edx 0x0000000000017b54 <+68>: js 0x17b6d <drm_dp_aux_dev_get_by_minor+93> 0x0000000000017b56 <+70>: test %ecx,%ecx 0x0000000000017b58 <+72>: js 0x17b6d <drm_dp_aux_dev_get_by_minor+93> 0x0000000000017b5a <+74>: mov $0x0,%rdi 0x0000000000017b61 <+81>: callq 0x17b66 <drm_dp_aux_dev_get_by_minor+86> 0x0000000000017b66 <+86>: mov %r12,%rax 0x0000000000017b69 <+89>: pop %r12 0x0000000000017b6b <+91>: pop %rbp 0x0000000000017b6c <+92>: retq 0x0000000000017b6d <+93>: xor %esi,%esi 0x0000000000017b6f <+95>: callq 0x17b74 <drm_dp_aux_dev_get_by_minor+100> 0x0000000000017b74 <+100>: jmp 0x17b5a <drm_dp_aux_dev_get_by_minor+74> 0x0000000000017b76 <+102>: mov %eax,%edx 0x0000000000017b78 <+104>: jmp 0x17b43 <drm_dp_aux_dev_get_by_minor+51> 0x0000000000017b7a <+106>: xor %r12d,%r12d 0x0000000000017b7d <+109>: jmp 0x17b5a <drm_dp_aux_dev_get_by_minor+74> End of assembler dump. (gdb) list *drm_dp_aux_dev_get_by_minor+0x29 0x17b39 is in drm_dp_aux_dev_get_by_minor (drivers/gpu/drm/drm_dp_aux_dev.c:65). 60 static struct drm_dp_aux_dev *drm_dp_aux_dev_get_by_minor(unsigned index) 61 { 62 struct drm_dp_aux_dev *aux_dev = NULL; 63 64 mutex_lock(&aux_idr_mutex); 65 aux_dev = idr_find(&aux_idr, index); 66 if (!kref_get_unless_zero(&aux_dev->refcount)) 67 aux_dev = NULL; 68 mutex_unlock(&aux_idr_mutex); 69 (gdb) p/x &((struct drm_dp_aux_dev *)(0x0))->refcount $8 = 0x18 Looking at the caller, checks on the minor are pushed down to drm_dp_aux_dev_get_by_minor() static int auxdev_open(struct inode *inode, struct file *file) { unsigned int minor = iminor(inode); struct drm_dp_aux_dev *aux_dev; aux_dev = drm_dp_aux_dev_get_by_minor(minor); <==== if (!aux_dev) return -ENODEV; file->private_data = aux_dev; return 0; } Fixes: e94cb37b34eb ("drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.") Cc: <stable@vger.kernel.org> # v4.6+ Signed-off-by: Zwane Mwaikambo <zwane@yosper.io> Reviewed-by: Lyude Paul <lyude@redhat.com> [added Cc to stable] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/alpine.DEB.2.21.2010122231070.38717@montezuma.home Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30drm/amd/display: Fix memory leaks in S3 resumeStylon Wang
commit a135a1b4c4db1f3b8cbed9676a40ede39feb3362 upstream. EDID parsing in S3 resume pushes new display modes to probed_modes list but doesn't consolidate to actual mode list. This creates a race condition when amdgpu_dm_connector_ddc_get_modes() re-initializes the list head without walking the list and results in memory leak. Bug: https://bugzilla.kernel.org/show_bug.cgi?id=209987 Acked-by: Harry Wentland <harry.wentland@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Stylon Wang <stylon.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30drm/amdkfd: Fix leak in dmabuf importFelix Kuehling
[ Upstream commit c897934da15f182ce99536007f8ef61c4748c07e ] Release dmabuf reference before returning from kfd_ioctl_import_dmabuf. amdgpu_amdkfd_gpuvm_import_dmabuf takes a reference to the underlying GEM BO and doesn't keep the reference to the dmabuf wrapper. Signed-off-by: Felix Kuehling <Felix.Kuehling@amd.com> Reviewed-by: Kent Russell <kent.russell@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/amd/display: Prevent bandwidth overflowChris Park
[ Upstream commit 80089dd8410f356d5104496d5ab71a66a4f4646b ] [Why] At very high pixel clock, bandwidth calculation exceeds 32 bit size and overflow value. This causes the resulting selection of link rate to be inaccurate. [How] Change order of operation and use fixed point to deal with integer accuracy. Also address bug found when forcing link rate. Signed-off-by: Chris Park <Chris.Park@amd.com> Reviewed-by: Wenjing Liu <Wenjing.Liu@amd.com> Acked-by: Eryk Brol <eryk.brol@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-30drm/mediatek: avoid dereferencing a null hdmi_phy on an error messageColin Ian King
[ Upstream commit b097efba9580d1f7cbc80cda84e768983e3de541 ] Currently there is a null pointer check for hdmi_phy that implies it may be null, however a dev_err messages dereferences this potential null pointer. Avoid a null pointer dereference by only emitting the dev_err message if hdmi_phy is non-null. It is a moot point if the error message needs to be printed at all, but since this is a relatively new piece of code it may be useful to keep the message in for the moment in case there are unforseen errors that need to be reported. Fixes: be28b6507c46 ("drm/mediatek: separate hdmi phy to different file") Signed-off-by: Colin Ian King <colin.king@canonical.com> Addresses-Coverity: ("Dereference after null check") Link: https://lore.kernel.org/r/20201207150937.170435-1-colin.king@canonical.com [vkoul: fix indent of return call] Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/omap: dmm_tiler: fix return error code in omap_dmm_probe()Yang Yingliang
[ Upstream commit 723ae803218da993143387bf966042eccefac077 ] Return -ENOMEM when allocating refill memory failed. Fixes: 71e8831f6407 ("drm/omap: DMM/TILER support for OMAP4+ platform") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20201117061045.3452287-1-yangyingliang@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/msm/dsi_pll_10nm: restore VCO rate during restore_stateDmitry Baryshkov
[ Upstream commit a4ccc37693a271330a46208afbeaed939d54fdbb ] PHY disable/enable resets PLL registers to default values. Thus in addition to restoring several registers we also need to restore VCO rate settings. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Fixes: c6659785dfb3 ("drm/msm/dsi/pll: call vco set rate explicitly") Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/amdgpu: fix build_coefficients() argumentArnd Bergmann
[ Upstream commit dbb60031dd0c2b85f10ce4c12ae604c28d3aaca4 ] gcc -Wextra warns about a function taking an enum argument being called with a bool: drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c: In function 'apply_degamma_for_user_regamma': drivers/gpu/drm/amd/amdgpu/../display/modules/color/color_gamma.c:1617:29: warning: implicit conversion from 'enum <anonymous>' to 'enum dc_transfer_func_predefined' [-Wenum-conversion] 1617 | build_coefficients(&coeff, true); It appears that a patch was added using the old calling conventions after the type was changed, and the value should actually be 0 (TRANSFER_FUNCTION_SRGB) here instead of 1 (true). Fixes: 55a01d4023ce ("drm/amd/display: Add user_regamma to color module") Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/amdgpu: fix incorrect enum typeArnd Bergmann
[ Upstream commit a110f3750bf8b93764f13bd1402c7cba03d15d61 ] core_link_write_dpcd() returns enum dc_status, not ddc_result: display/dc/core/dc_link_dp.c: In function 'dp_set_panel_mode': display/dc/core/dc_link_dp.c:4237:11: warning: implicit conversion from 'enum dc_status' to 'enum ddc_result' [-Wenum-conversion] Avoid the warning by using the correct enum in the caller. Fixes: 0b226322434c ("drm/amd/display: Synchronous DisplayPort Link Training") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/tve200: Fix handling of platform_get_irq() errorKrzysztof Kozlowski
[ Upstream commit 77bb5aaf2bb8180e7d1bb70b4df306f511707a7d ] platform_get_irq() returns -ERRNO on error. In such case comparison to 0 would pass the check. Fixes: 179c02fe90a4 ("drm/tve200: Add new driver for TVE200") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200827071107.27429-2-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/mcde: Fix handling of platform_get_irq() errorKrzysztof Kozlowski
[ Upstream commit e2dae672a9d5e11856fe30ede63467c65f999a81 ] platform_get_irq() returns -ERRNO on error. In such case comparison to 0 would pass the check. Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE") Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20200827071107.27429-1-krzk@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/aspeed: Fix Kconfig warning & subsequent build errorsRandy Dunlap
[ Upstream commit bf296b35489b46780b73b74ad984d06750ed5479 ] Kernel test robot reported build errors (undefined references) that didn't make much sense. After reproducing them, there is also a Kconfig warning that is the root cause of the build errors, so fix that Kconfig problem. Fixes this Kconfig warning: WARNING: unmet direct dependencies detected for CMA Depends on [n]: MMU [=n] Selected by [m]: - DRM_ASPEED_GFX [=m] && HAS_IOMEM [=y] && DRM [=m] && OF [=y] && (COMPILE_TEST [=y] || ARCH_ASPEED) && HAVE_DMA_CONTIGUOUS [=y] and these dependent build errors: (.text+0x10c8c): undefined reference to `start_isolate_page_range' microblaze-linux-ld: (.text+0x10f14): undefined reference to `test_pages_isolated' microblaze-linux-ld: (.text+0x10fd0): undefined reference to `undo_isolate_page_range' Fixes: 76356a966e33 ("drm: aspeed: Clean up Kconfig options") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Reviewed-by: Joel Stanley <joel@jms.id.au> Cc: Joel Stanley <joel@jms.id.au> Cc: Andrew Jeffery <andrew@aj.id.au> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michal Simek <monstr@monstr.eu> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Mike Rapoport <rppt@linux.ibm.com> Cc: linux-mm@kvack.org Cc: linux-aspeed@lists.ozlabs.org Cc: linux-arm-kernel@lists.infradead.org Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by: Joel Stanley <joel@jms.id.au> Link: https://patchwork.freedesktop.org/patch/msgid/20201011230131.4922-1-rdunlap@infradead.org Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/gma500: fix double free of gma_connectorTom Rix
[ Upstream commit 4e19d51ca5b28a1d435a844c7b2a8e1b1b6fa237 ] clang static analysis reports this problem: cdv_intel_dp.c:2101:2: warning: Attempt to free released memory kfree(gma_connector); ^~~~~~~~~~~~~~~~~~~~ In cdv_intel_dp_init() when the call to cdv_intel_edp_panel_vdd_off() fails, the handler calls cdv_intel_dp_destroy(connector) which does the first free of gma_connector. So adjust the goto label and skip the second free. Fixes: d112a8163f83 ("gma500/cdv: Add eDP support") Signed-off-by: Tom Rix <trix@redhat.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201003193928.18869-1-trix@redhat.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/amd/display: Init clock value by current vbios CLKsBrandon Syu
[ Upstream commit 7e0b367db85ef7b91399006253759a024eab7653 ] [Why] While booting into OS, driver updates DPP/DISP CLKs. But init clock value is zero which is invalid. [How] Get current clocks value to update init clocks. To avoid underflow. Signed-off-by: Brandon Syu <Brandon.Syu@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/tegra: sor: Disable clocks on error in tegra_sor_init()Qinglang Miao
[ Upstream commit bf3a3cdcad40e5928a22ea0fd200d17fd6d6308d ] Fix the missing clk_disable_unprepare() before return from tegra_sor_init() in the error handling case. Signed-off-by: Qinglang Miao <miaoqinglang@huawei.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-30drm/tegra: replace idr_init() by idr_init_base()Deepak R Varma
[ Upstream commit 41f71629b4c432f8dd47d70ace813be5f79d4d75 ] idr_init() uses base 0 which is an invalid identifier for this driver. The new function idr_init_base allows IDR to set the ID lookup from base 1. This avoids all lookups that otherwise starts from 0 since 0 is always unused. References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient") Signed-off-by: Deepak R Varma <mh12gx2825@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-12-16drm/i915/display/dp: Compute the correct slice count for VDSC on DPManasi Navare
commit f6cbe49be65ed800863ac5ba695555057363f9c2 upstream. This patch fixes the slice count computation algorithm for calculating the slice count based on Peak pixel rate and the max slice width allowed on the DSC engines. We need to ensure slice count > min slice count req as per DP spec based on peak pixel rate and that it is greater than min slice count based on the max slice width advertised by DPCD. So use max of these two. In the prev patch we were using min of these 2 causing it to violate the max slice width limitation causing a blank screen on 8K@60. Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice Count for DSC") Cc: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201204205804.25225-1-manasi.d.navare@intel.com (cherry picked from commit d371d6ea92ad2a47f42bbcaa786ee5f6069c9c14) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-12-11drm/i915/gt: Program mocs:63 for cache eviction on gen9Chris Wilson
commit 777a7717d60ccdc9b84f35074f848d3f746fc3bf upstream. Ville noticed that the last mocs entry is used unconditionally by the HW when it performs cache evictions, and noted that while the value is not meant to be writable by the driver, we should program it to a reasonable value nevertheless. As it turns out, we can change the value of mocs:63 and the value we were programming into it would cause hard hangs in conjunction with atomic operations. v2: Add details from bspec about how it is used by HW Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2707 Fixes: 3bbaba0ceaa2 ("drm/i915: Added Programming of the MOCS") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jason Ekstrand <jason@jlekstrand.net> Cc: <stable@vger.kernel.org> # v4.3+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201126140841.1982-1-chris@chris-wilson.co.uk (cherry picked from commit 977933b5da7c16f39295c4c1d4259a58ece65dbe) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-24drm/i915: Handle max_bpc==16Ville Syrjälä
commit d2e3fce9ddafe689c6f7cb355f23560637e30b9d upstream. EDID can declare the maximum supported bpc up to 16, and apparently there are displays that do so. Currently we assume 12 bpc is tha max. Fix the assumption and toss in a MISSING_CASE() for any other value we don't expect to see. This fixes modesets with a display with EDID max bpc > 12. Previously any modeset would just silently fail on platforms that didn't otherwise limit this via the max_bpc property. In particular we don't add the max_bpc property to HDMI ports on gmch platforms, and thus we would see the raw max_bpc coming from the EDID. I suppose we could already adjust this to also allow 16bpc, but seeing as no current platform supports that there is little point. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2632 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201110210447.27454-1-ville.syrjala@linux.intel.com Reviewed-by: José Roberto de Souza <jose.souza@intel.com> (cherry picked from commit 2ca5a7b85b0c2b97ef08afbd7799b022e29f192e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-24drm/amd/display: Add missing pflip irq for dcn2.0Alex Deucher
commit 728321e53045d2668bf2b8627a8d61bc2c480d3b upstream. If we have more than 4 displays we will run into dummy irq calls or flip timout issues. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-24drm/sun4i: dw-hdmi: fix error return code in sun8i_dw_hdmi_bind()Xiongfeng Wang
[ Upstream commit 6654b57866b98230a270953dd34f67de17ab1708 ] Fix to return a negative error code from the error handling case instead of 0 in function sun8i_dw_hdmi_bind(). Fixes: b7c7436a5ff0 ("drm/sun4i: Implement A83T HDMI driver") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Xiongfeng Wang <wangxiongfeng2@huawei.com> Reviewed-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/1605488969-5211-1-git-send-email-wangxiongfeng2@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-18drm/i915: Correctly set SFC capability for video enginesVenkata Sandeep Dhanalakota
commit 5ce6861d36ed5207aff9e5eead4c7cc38a986586 upstream. SFC capability of video engines is not set correctly because i915 is testing for incorrect bits. Fixes: c5d3e39caa45 ("drm/i915: Engine discovery query") Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: <stable@vger.kernel.org> # v5.3+ Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20201106011842.36203-1-daniele.ceraolospurio@intel.com (cherry picked from commit ad18fa0f5f052046cad96fee762b5c64f42dd86a) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-18drm/gma500: Fix out-of-bounds access to struct drm_device.vblank[]Thomas Zimmermann
commit 06ad8d339524bf94b89859047822c31df6ace239 upstream. The gma500 driver expects 3 pipelines in several it's IRQ functions. Accessing struct drm_device.vblank[], this fails with devices that only have 2 pipelines. An example KASAN report is shown below. [ 62.267688] ================================================================== [ 62.268856] BUG: KASAN: slab-out-of-bounds in psb_irq_postinstall+0x250/0x3c0 [gma500_gfx] [ 62.269450] Read of size 1 at addr ffff8880012bc6d0 by task systemd-udevd/285 [ 62.269949] [ 62.270192] CPU: 0 PID: 285 Comm: systemd-udevd Tainted: G E 5.10.0-rc1-1-default+ #572 [ 62.270807] Hardware name: /DN2800MT, BIOS MTCDT10N.86A.0164.2012.1213.1024 12/13/2012 [ 62.271366] Call Trace: [ 62.271705] dump_stack+0xae/0xe5 [ 62.272180] print_address_description.constprop.0+0x17/0xf0 [ 62.272987] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx] [ 62.273474] __kasan_report.cold+0x20/0x38 [ 62.273989] ? psb_irq_postinstall+0x250/0x3c0 [gma500_gfx] [ 62.274460] kasan_report+0x3a/0x50 [ 62.274891] psb_irq_postinstall+0x250/0x3c0 [gma500_gfx] [ 62.275380] drm_irq_install+0x131/0x1f0 <...> [ 62.300751] Allocated by task 285: [ 62.301223] kasan_save_stack+0x1b/0x40 [ 62.301731] __kasan_kmalloc.constprop.0+0xbf/0xd0 [ 62.302293] drmm_kmalloc+0x55/0x100 [ 62.302773] drm_vblank_init+0x77/0x210 Resolve the issue by only handling vblank entries up to the number of CRTCs. I'm adding a Fixes tag for reference, although the bug has been present since the driver's initial commit. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers") Cc: Alan Cox <alan@linux.intel.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: dri-devel@lists.freedesktop.org Cc: stable@vger.kernel.org#v3.3+ Link: https://patchwork.freedesktop.org/patch/msgid/20201105190256.3893-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-18amd/amdgpu: Disable VCN DPG mode for PicassoVeerabadhran Gopalakrishnan
[ Upstream commit c6d2b0fbb893d5c7dda405aa0e7bcbecf1c75f98 ] Concurrent operation of VCN and JPEG decoder in DPG mode is causing ring timeout due to power state. Signed-off-by: Veerabadhran Gopalakrishnan <veerabadhran.gopalakrishnan@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-18drm/amd/pm: do not use ixFEATURE_STATUS for checking smc runningEvan Quan
[ Upstream commit 786436b453001dafe81025389f96bf9dac1e9690 ] This reverts commit f87812284172a9809820d10143b573d833cd3f75 ("drm/amdgpu: Fix bug where DPM is not enabled after hibernate and resume"). It was intended to fix Hawaii S4(hibernation) issue but break S3. As ixFEATURE_STATUS is filled with garbage data on resume which can be only cleared by reloading smc firmware(but that will involve many changes). So, we will revert this S4 fix and seek a new way. Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-by: Sandeep Raghuraman <sandy.8925@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-18drm/amd/pm: perform SMC reset on suspend/hibernationEvan Quan
[ Upstream commit 277b080f98803cb73a83fb234f0be83a10e63958 ] So that the succeeding resume can be performed based on a clean state. Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-by: Sandeep Raghuraman <sandy.8925@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-18drm/amdgpu: perform srbm soft reset always on SDMA resumeEvan Quan
[ Upstream commit 253475c455eb5f8da34faa1af92709e7bb414624 ] This can address the random SDMA hang after pci config reset seen on Hawaii. Signed-off-by: Evan Quan <evan.quan@amd.com> Tested-by: Sandeep Raghuraman <sandy.8925@gmail.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-18drm/i915/gem: Flush coherency domains on first set-domain-ioctlChris Wilson
[ Upstream commit 59dd13ad310793757e34afa489dd6fc8544fc3da ] Avoid skipping what appears to be a no-op set-domain-ioctl if the cache coherency state is inconsistent with our target domain. This also has the utility of using the population of the pages to validate the backing store. The danger in skipping the first set-domain is leaving the cache inconsistent and submitting stale data, or worse leaving the clean data in the cache and not flushing it to the GPU. The impact should be small as it requires a no-op set-domain as the very first ioctl in a particular sequence not found in typical userspace. Reported-by: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Fixes: 754a25442705 ("drm/i915: Skip object locking around a no-op set-domain ioctl") Testcase: igt/gem_mmap_offset/blt-coherency Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Cc: Zbigniew Kempczyński <zbigniew.kempczynski@intel.com> Cc: <stable@vger.kernel.org> # v5.2+ Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201019203825.10966-1-chris@chris-wilson.co.uk (cherry picked from commit 44c2200afcd59f441b43f27829b4003397cc495d) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/panfrost: Fix a deadlock between the shrinker and madvise pathBoris Brezillon
commit 7d2d6d01293e6d9b42a6cb410be4158571f7fe9d upstream. panfrost_ioctl_madvise() and panfrost_gem_purge() acquire the mappings and shmem locks in different orders, thus leading to a potential the mappings lock first. Fixes: bdefca2d8dc0 ("drm/panfrost: Add the panfrost_gem_mapping concept") Cc: <stable@vger.kernel.org> Cc: Christian Hewitt <christianshewitt@gmail.com> Reported-by: Christian Hewitt <christianshewitt@gmail.com> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201101174016.839110-1-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10drm/nouveau/gem: fix "refcount_t: underflow; use-after-free"Karol Herbst
[ Upstream commit 925681454d7b557d404b5d28ef4469fac1b2e105 ] we can't use nouveau_bo_ref here as no ttm object was allocated and nouveau_bo_ref mainly deals with that. Simply deallocate the object. Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/nouveau/nouveau: fix the start/end range for migrationRalph Campbell
[ Upstream commit cfa736f5a6f31ca8a05459b5720aac030247ad1b ] The user level OpenCL code shouldn't have to align start and end addresses to a page boundary. That is better handled in the nouveau driver. The npages field is also redundant since it can be computed from the start and end addresses. Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/vc4: drv: Add error handding for bindHoegeun Kwon
[ Upstream commit 9ce0af3e9573fb84c4c807183d13ea2a68271e4b ] There is a problem that if vc4_drm bind fails, a memory leak occurs on the drm_property_create side. Add error handding for drm_mode_config. Signed-off-by: Hoegeun Kwon <hoegeun.kwon@samsung.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20201027041442.30352-2-hoegeun.kwon@samsung.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/amdgpu: add DID for navi10 blockchain SKUTianci.Yin
[ Upstream commit 8942881144a7365143f196f5eafed24783a424a3 ] Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Guchun Chen <guchun.chen@amd.com> Signed-off-by: Tianci.Yin <tianci.yin@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/sun4i: frontend: Fix the scaler phase on A33Maxime Ripard
[ Upstream commit e3190b5e9462067714d267c40d8c8c1d0463dda3 ] The A33 has a different phase parameter in the Allwinner BSP on the channel1 than the one currently applied. Fix this. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-3-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/sun4i: frontend: Reuse the ch0 phase for RGB formatsMaxime Ripard
[ Upstream commit 2db9ef9d9e6ea89a9feb5338f58d1f8f83875577 ] When using the scaler on the A10-like frontend with single-planar formats, the current code will setup the channel 0 filter (used for the R or Y component) with a different phase parameter than the channel 1 filter (used for the G/B or U/V components). This creates a bleed out that keeps repeating on of the last line of the RGB plane across the rest of the display. The Allwinner BSP either applies the same phase parameter over both channels or use a separate one, the condition being whether the input format is YUV420 or not. Since YUV420 is both subsampled and multi-planar, and since YUYV is subsampled but single-planar, we can rule out the subsampling and assume that the condition is actually whether the format is single or multi-planar. And it looks like applying the same phase parameter over both channels for single-planar formats fixes our issue, while we keep the multi-planar formats working properly. Reported-by: Taras Galchenko <tpgalchenko@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-2-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/sun4i: frontend: Rework a bit the phase dataMaxime Ripard
[ Upstream commit 84c971b356379c621df595bd00c3114579dfa59f ] The scaler filter phase setup in the allwinner kernel has two different cases for setting up the scaler filter, the first one using different phase parameters for the two channels, and the second one reusing the first channel parameters on the second channel. The allwinner kernel has a third option where the horizontal phase of the second channel will be set to a different value than the vertical one (and seems like it's the same value than one used on the first channel). However, that code path seems to never be taken, so we can ignore it for now, and it's essentially what we're doing so far as well. Since we will have always the same values across each components of the filter setup for a given channel, we can simplify a bit our frontend structure by only storing the phase value we want to apply to a given channel. Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Jernej Skrabec <jernej.skrabec@siol.net> Link: https://patchwork.freedesktop.org/patch/msgid/20201015093642.261440-1-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2020-11-10drm/i915: Drop runtime-pm assert from vgpu io accessorsChris Wilson
commit 5c6c13cd1102caf92d006a3cf4591c0229019daf upstream. The "mmio" writes into vgpu registers are simple memory traps from the guest into the host. We do not need to assert in the guest that the device is awake for the io as we do not write to the device itself. However, over time we have refactored all the mmio accessors with the result that the vgpu reuses the gen2 accessors and so inherits the assert for runtime-pm of the native device. The assert though has actually been there since commit 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps"). References: 3be0bf5acca6 ("drm/i915: Create vGPU specific MMIO operations to reduce traps") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Yan Zhao <yan.y.zhao@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200811092532.13753-1-chris@chris-wilson.co.uk (cherry picked from commit 0e65ce24a33c1d37da4bf43c34e080334ec6cb60) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10drm/i915/gt: Delay execlist processing for tglChris Wilson
commit 9b99e5ba3e5d68039bd6b657e4bbe520a3521f4c upstream. When running gem_exec_nop, it floods the system with many requests (with the goal of userspace submitting faster than the HW can process a single empty batch). This causes the driver to continually resubmit new requests onto the end of an active context, a flood of lite-restore preemptions. If we time this just right, Tigerlake hangs. Inserting a small delay between the processing of CS events and submitting the next context, prevents the hang. Naturally it does not occur with debugging enabled. The suspicion then is that this is related to the issues with the CS event buffer, and inserting an mmio read of the CS pointer status appears to be very successful in preventing the hang. Other registers, or uncached reads, or plain mb, do not prevent the hang, suggesting that register is key -- but that the hang can be prevented by a simple udelay, suggests it is just a timing issue like that encountered by commit 233c1ae3c83f ("drm/i915/gt: Wait for CSB entries on Tigerlake"). Also note that the hang is not prevented by applying CTX_DESC_FORCE_RESTORE, or by inserting a delay on the GPU between requests. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Bruce Chang <yu.bruce.chang@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: stable@vger.kernel.org Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201015195023.32346-1-chris@chris-wilson.co.uk (cherry picked from commit 6ca7217dffaf1abba91558e67a2efb655ac91405) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-10drm/i915: Break up error capture compression loops with cond_resched()Chris Wilson
commit 7d5553147613b50149238ac1385c60e5c7cacb34 upstream. As the error capture will compress user buffers as directed to by the user, it can take an arbitrary amount of time and space. Break up the compression loops with a call to cond_resched(), that will allow other processes to schedule (avoiding the soft lockups) and also serve as a warning should we try to make this loop atomic in the future. Testcase: igt/gem_exec_capture/many-* Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: stable@vger.kernel.org Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200916090059.3189-2-chris@chris-wilson.co.uk (cherry picked from commit 293f43c80c0027ff9299036c24218ac705ce584e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05drm/amd/pm: increase mclk switch threshold to 200 usEvan Quan
commit 83da6eea3af669ee0b1f1bc05ffd6150af984994 upstream. To avoid underflow seen on Polaris10 with some 3440x1440 144Hz displays. As the threshold of 190 us cuts too close to minVBlankTime of 192 us. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05drm/ttm: fix eviction valuable range check.Dave Airlie
commit fea456d82c19d201c21313864105876deabe148b upstream. This was adding size to start, but pfn and start are in pages, so it should be using num_pages. Not sure this fixes anything in the real world, just noticed it during refactoring. Signed-off-by: Dave Airlie <airlied@redhat.com> Reviewed-by: Christian König <christian.koenig@amd.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20201019222257.1684769-2-airlied@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05drm/amd/display: Fix kernel panic by dal_gpio_open() errorTakashi Iwai
commit 920bb38c518408fa2600eaefa0af9e82cf48f166 upstream. Currently both error code paths handled in dal_gpio_open_ex() issues ASSERT_CRITICAL(), and this leads to a kernel panic unnecessarily if CONFIG_KGDB is enabled. Since basically both are non-critical errors and can be recovered, drop those assert calls and use a safer one, BREAK_TO_DEBUGGER(), for allowing the debugging, instead. BugLink: https://bugzilla.opensuse.org/show_bug.cgi?id=1177973 Cc: <stable@vger.kernel.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05drm/amd/display: Don't invoke kgdb_breakpoint() unconditionallyTakashi Iwai
commit 8b7dc1fe1a5c1093551f6cd7dfbb941bd9081c2e upstream. ASSERT_CRITICAL() invokes kgdb_breakpoint() whenever either CONFIG_KGDB or CONFIG_HAVE_KGDB is set. This, however, may lead to a kernel panic when no kdb stuff is attached, since the kgdb_breakpoint() call issues INT3. It's nothing but a surprise for normal end-users. For avoiding the pitfall, make the kgdb_breakpoint() call only when CONFIG_DEBUG_KERNEL_DC is set. https://bugzilla.opensuse.org/show_bug.cgi?id=1177973 Cc: <stable@vger.kernel.org> Acked-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05drm/amdgpu: increase the reserved VM size to 2MBChristian König
commit 55bb919be4e4973cd037a04f527ecc6686800437 upstream. Ideally this should be a multiple of the VM block size. 2MB should at least fit for Vega/Navi. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Madhav Chauhan <madhav.chauhan@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05drm/amd/display: Avoid MST manager resource leak.Andrey Grodzovsky
commit 5dff80bdce9e385af5716ed083f9e33e814484ab upstream. On connector destruction call drm_dp_mst_topology_mgr_destroy to release resources allocated in drm_dp_mst_topology_mgr_init. Do it only if MST manager was initilized before otherwsie a crash is seen on driver unload/device unplug. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05drm/amdkfd: Use same SQ prefetch setting as amdgpuJay Cornwall
commit d56b1980d7efe9ef08469e856fc0703d0cef65e4 upstream. 0 causes instruction fetch stall at cache line boundary under some conditions on Navi10. A non-zero prefetch is the preferred default in any case. Fixes soft hang in Luxmark. Signed-off-by: Jay Cornwall <jay.cornwall@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-11-05drm/amdgpu: correct the gpu reset handling for job != NULL caseEvan Quan
commit 207ac684792560acdb9e06f9d707ebf63c84b0e0 upstream. Current code wrongly treat all cases as job == NULL. Signed-off-by: Evan Quan <evan.quan@amd.com> Reviewed-and-tested-by: Jane Jian <Jane.Jian@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.25.1) at 2026-06-05 20:46:21 +0000