summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2021-04-10drm/msm/adreno: a5xx_power: Don't apply A540 lm_setup to other GPUsKonrad Dybcio1-1/+1
[ Upstream commit 4a9d36b0610aa7034340e976652e5b43320dd7c5 ] While passing the A530-specific lm_setup func to A530 and A540 to !A530 was fine back when only these two were supported, it certainly is not a good idea to send A540 specifics to smaller GPUs like A508 and friends. Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-04-07drm/amdgpu: check alignment on CPU page for bo mapXℹ Ruoyao1-4/+4
commit e3512fb67093fabdf27af303066627b921ee9bd8 upstream. The page table of AMDGPU requires an alignment to CPU page so we should check ioctl parameters for it. Return -EINVAL if some parameter is unaligned to CPU page, instead of corrupt the page table sliently. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Xi Ruoyao <xry111@mengyan1223.wang> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-07drm/amdgpu: fix offset calculation in amdgpu_vm_bo_clear_mappings()Nirmoy Das1-1/+1
commit 5e61b84f9d3ddfba73091f9fbc940caae1c9eb22 upstream. Offset calculation wasn't correct as start addresses are in pfn not in bytes. CC: stable@vger.kernel.org Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-30drm/msm: fix shutdown hook in case GPU components failed to bindDmitry Baryshkov1-0/+4
[ Upstream commit 623f279c77811475ac8fd5635cc4e4451aa71291 ] If GPU components have failed to bind, shutdown callback would fail with the following backtrace. Add safeguard check to stop that oops from happening and allow the board to reboot. [ 66.617046] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 66.626066] Mem abort info: [ 66.628939] ESR = 0x96000006 [ 66.632088] EC = 0x25: DABT (current EL), IL = 32 bits [ 66.637542] SET = 0, FnV = 0 [ 66.640688] EA = 0, S1PTW = 0 [ 66.643924] Data abort info: [ 66.646889] ISV = 0, ISS = 0x00000006 [ 66.650832] CM = 0, WnR = 0 [ 66.653890] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107f81000 [ 66.660505] [0000000000000000] pgd=0000000100bb2003, p4d=0000000100bb2003, pud=0000000100897003, pmd=0000000000000000 [ 66.671398] Internal error: Oops: 96000006 [#1] PREEMPT SMP [ 66.677115] Modules linked in: [ 66.680261] CPU: 6 PID: 352 Comm: reboot Not tainted 5.11.0-rc2-00309-g79e3faa756b2 #38 [ 66.688473] Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) [ 66.695347] pstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--) [ 66.701507] pc : msm_atomic_commit_tail+0x78/0x4e0 [ 66.706437] lr : commit_tail+0xa4/0x184 [ 66.710381] sp : ffff8000108f3af0 [ 66.713791] x29: ffff8000108f3af0 x28: ffff418c44337000 [ 66.719242] x27: 0000000000000000 x26: ffff418c40a24490 [ 66.724693] x25: ffffd3a842a4f1a0 x24: 0000000000000008 [ 66.730146] x23: ffffd3a84313f030 x22: ffff418c444ce000 [ 66.735598] x21: ffff418c408a4980 x20: 0000000000000000 [ 66.741049] x19: 0000000000000000 x18: ffff800010710fbc [ 66.746500] x17: 000000000000000c x16: 0000000000000001 [ 66.751954] x15: 0000000000010008 x14: 0000000000000068 [ 66.757405] x13: 0000000000000001 x12: 0000000000000000 [ 66.762855] x11: 0000000000000001 x10: 00000000000009b0 [ 66.768306] x9 : ffffd3a843192000 x8 : ffff418c44337000 [ 66.773757] x7 : 0000000000000000 x6 : 00000000a401b34e [ 66.779210] x5 : 00ffffffffffffff x4 : 0000000000000000 [ 66.784660] x3 : 0000000000000000 x2 : ffff418c444ce000 [ 66.790111] x1 : ffffd3a841dce530 x0 : ffff418c444cf000 [ 66.795563] Call trace: [ 66.798075] msm_atomic_commit_tail+0x78/0x4e0 [ 66.802633] commit_tail+0xa4/0x184 [ 66.806217] drm_atomic_helper_commit+0x160/0x390 [ 66.811051] drm_atomic_commit+0x4c/0x60 [ 66.815082] drm_atomic_helper_disable_all+0x1f4/0x210 [ 66.820355] drm_atomic_helper_shutdown+0x80/0x130 [ 66.825276] msm_pdev_shutdown+0x14/0x20 [ 66.829303] platform_shutdown+0x28/0x40 [ 66.833330] device_shutdown+0x158/0x330 [ 66.837357] kernel_restart+0x40/0xa0 [ 66.841122] __do_sys_reboot+0x228/0x250 [ 66.845148] __arm64_sys_reboot+0x28/0x34 [ 66.849264] el0_svc_common.constprop.0+0x74/0x190 [ 66.854187] do_el0_svc+0x24/0x90 [ 66.857595] el0_svc+0x14/0x20 [ 66.860739] el0_sync_handler+0x1a4/0x1b0 [ 66.864858] el0_sync+0x174/0x180 [ 66.868269] Code: 1ac020a0 2a000273 eb02007f 54ffff01 (f9400285) [ 66.874525] ---[ end trace 20dedb2a3229fec8 ]--- Fixes: 9d5cbf5fe46e ("drm/msm: add shutdown support for display platform_driver") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Fabio Estevam <festevam@gmail.com> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-30drm/radeon: fix AGP dependencyChristian König1-0/+1
[ Upstream commit cba2afb65cb05c3d197d17323fee4e3c9edef9cd ] When AGP is compiled as module radeon must be compiled as module as well. Signed-off-by: Christian König <christian.koenig@amd.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>
2021-03-30drm/amdgpu: fb BO should be ttm_bo_type_deviceNirmoy Das1-1/+1
[ Upstream commit 521f04f9e3ffc73ef96c776035f8a0a31b4cdd81 ] FB BO should not be ttm_bo_type_kernel type and amdgpufb_create_pinned_object() pins the FB BO anyway. Signed-off-by: Nirmoy Das <nirmoy.das@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-30drm/amd/display: Revert dram_clock_change_latency for DCN2.1Sung Lee1-1/+1
[ Upstream commit b0075d114c33580f5c9fa9cee8e13d06db41471b ] [WHY & HOW] Using values provided by DF for latency may cause hangs in multi display configurations. Revert change to previous value. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Sung Lee <sung.lee@amd.com> Reviewed-by: Haonan Wang <Haonan.Wang2@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>
2021-03-20drm/i915/gvt: Fix vfio_edid issue for BXT/APLColin Xu2-23/+62
commit 4ceb06e7c336f4a8d3f3b6ac9a4fea2e9c97dc07 upstream BXT/APL has different isr/irr/hpd regs compared with other GEN9. If not setting these regs bits correctly according to the emulated monitor (currently a DP on PORT_B), although gvt still triggers a virtual HPD event, the guest driver won't detect a valid HPD pulse thus no full display detection will be executed to read the updated EDID. With this patch, the vfio_edid is enabled again on BXT/APL, which is previously disabled. Fixes: 642403e3599e ("drm/i915/gvt: Temporarily disable vfio_edid for BXT/APL") Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201201060329.142375-1-colin.xu@intel.com Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> (cherry picked from commit 4ceb06e7c336f4a8d3f3b6ac9a4fea2e9c97dc07) Signed-off-by: Colin Xu <colin.xu@intel.com> Cc: <stable@vger.kernel.org> # 5.4.y Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20drm/i915/gvt: Fix port number for BDW on EDID region setupColin Xu1-2/+3
From: Zhenyu Wang <zhenyuw@linux.intel.com> commit 28284943ac94014767ecc2f7b3c5747c4a5617a0 upstream Current BDW virtual display port is initialized as PORT_B, so need to use same port for VFIO EDID region, otherwise invalid EDID blob pointer is assigned which caused kernel null pointer reference. We might evaluate actual display hotplug for BDW to make this function work as expected, anyway this is always required to be fixed first. Reported-by: Alejandro Sior <aho@sior.be> Cc: Alejandro Sior <aho@sior.be> Fixes: 0178f4ce3c3b ("drm/i915/gvt: Enable vfio edid for all GVT supported platform") Reviewed-by: Hang Yuan <hang.yuan@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200914030302.2775505-1-zhenyuw@linux.intel.com (cherry picked from commit 28284943ac94014767ecc2f7b3c5747c4a5617a0) Signed-off-by: Colin Xu <colin.xu@intel.com> Cc: <stable@vger.kernel.org> # 5.4.y Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20drm/i915/gvt: Fix virtual display setup for BXT/APLColin Xu2-0/+178
commit a5a8ef937cfa79167f4b2a5602092b8d14fd6b9a upstream Program display related vregs to proper value at initialization, setup virtual monitor and hotplug. vGPU virtual display vregs inherit the value from pregs. The virtual DP monitor is always setup on PORT_B for BXT/APL. However the host may connect monitor on other PORT or without any monitor connected. Without properly setup PIPE/DDI/PLL related vregs, guest driver may not setup the virutal display as expected, and the guest desktop may not be created. Since only one virtual display is supported, enable PIPE_A only. And enable transcoder/DDI/PLL based on which port is setup for BXT/APL. V2: Revise commit message. V3: set_edid should on PORT_B for BXT. Inject hpd event for BXT. V4: Temporarily disable vfio edid on BXT/APL until issue fixed. V5: Rebase to use new HPD define GEN8_DE_PORT_HOTPLUG for BXT. Put vfio edid disabling on BXT/APL to a separate patch. Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201109073922.757759-1-colin.xu@intel.com (cherry picked from commit a5a8ef937cfa79167f4b2a5602092b8d14fd6b9a) Signed-off-by: Colin Xu <colin.xu@intel.com> Cc: <stable@vger.kernel.org> # 5.4.y Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20drm/i915/gvt: Fix mmio handler break on BXT/APL.Colin Xu1-1/+7
commit 92010a97098c4c9fd777408cc98064d26b32695b upstream - Remove dup mmio handler for BXT/APL. Otherwise mmio handler will fail to init. - Add engine GPR with F_CMD_ACCESS since BXT/APL will load them via LRI. Otherwise, guest will enter failsafe mode. V2: Use RCS/BCS GPR macros instead of offset. Revise commit message. V3: Use GEN8_RING_CS_GPR macros on ring base. Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201016052913.209248-1-colin.xu@intel.com (cherry picked from commit 92010a97098c4c9fd777408cc98064d26b32695b) Signed-off-by: Colin Xu <colin.xu@intel.com> Cc: <stable@vger.kernel.org> # 5.4.y Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-20drm/i915/gvt: Set SNOOP for PAT3 on BXT/APL to workaround GPU BB hangColin Xu1-1/+31
commit 8fe105679765700378eb328495fcfe1566cdbbd0 upstream If guest fills non-priv bb on ApolloLake/Broxton as Mesa i965 does in: 717e7539124d (i965: Use a WC map and memcpy for the batch instead of pw-) Due to the missing flush of bb filled by VM vCPU, host GPU hangs on executing these MI_BATCH_BUFFER. Temporarily workaround this by setting SNOOP bit for PAT3 used by PPGTT PML4 PTE: PAT(0) PCD(1) PWT(1). The performance is still expected to be low, will need further improvement. Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Colin Xu <colin.xu@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20201012045231.226748-1-colin.xu@intel.com (cherry picked from commit 8fe105679765700378eb328495fcfe1566cdbbd0) Signed-off-by: Colin Xu <colin.xu@intel.com> Cc: <stable@vger.kernel.org> # 5.4.y Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17qxl: Fix uninitialised struct field head.surface_idColin Ian King1-0/+1
commit 738acd49eb018feb873e0fac8f9517493f6ce2c7 upstream. The surface_id struct field in head is not being initialized and static analysis warns that this is being passed through to dev->monitors_config->heads[i] on an assignment. Clear up this warning by initializing it to zero. Addresses-Coverity: ("Uninitialized scalar variable") Fixes: a6d3c4d79822 ("qxl: hook monitors_config updates into crtc, not encoder.") Signed-off-by: Colin Ian King <colin.king@canonical.com> Link: http://patchwork.freedesktop.org/patch/msgid/20210304094928.2280722-1-colin.king@canonical.com Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17drm: meson_drv add shutdown functionArtem Lapkin1-0/+11
commit fa0c16caf3d73ab4d2e5d6fa2ef2394dbec91791 upstream. Problem: random stucks on reboot stage about 1/20 stuck/reboots // debug kernel log [ 4.496660] reboot: kernel restart prepare CMD:(null) [ 4.498114] meson_ee_pwrc c883c000.system-controller:power-controller: shutdown begin [ 4.503949] meson_ee_pwrc c883c000.system-controller:power-controller: shutdown domain 0:VPU... ...STUCK... Solution: add shutdown function to meson_drm driver // debug kernel log [ 5.231896] reboot: kernel restart prepare CMD:(null) [ 5.246135] [drm:meson_drv_shutdown] ... [ 5.259271] meson_ee_pwrc c883c000.system-controller:power-controller: shutdown begin [ 5.274688] meson_ee_pwrc c883c000.system-controller:power-controller: shutdown domain 0:VPU... [ 5.338331] reboot: Restarting system [ 5.358293] psci: PSCI_0_2_FN_SYSTEM_RESET reboot_mode:0 cmd:(null) bl31 reboot reason: 0xd bl31 reboot reason: 0x0 system cmd 1. ...REBOOT... Tested: on VIM1 VIM2 VIM3 VIM3L khadas sbcs - 1000+ successful reboots and Odroid boards, WeTek Play2 (GXBB) Fixes: bbbe775ec5b5 ("drm: Add support for Amlogic Meson Graphic Controller") Signed-off-by: Artem Lapkin <art@khadas.com> Tested-by: Christian Hewitt <christianshewitt@gmail.com> Acked-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Neil Armstrong <narmstrong@baylibre.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210302042202.3728113-1-art@khadas.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17drm/shmem-helper: Don't remove the offset in vm_area_struct pgoffNeil Roberts1-5/+6
commit 11d5a4745e00e73745774671dbf2fb07bd6e2363 upstream. When mmapping the shmem, it would previously adjust the pgoff in the vm_area_struct to remove the fake offset that is added to be able to identify the buffer. This patch removes the adjustment and makes the fault handler use the vm_fault address to calculate the page offset instead. Although using this address is apparently discouraged, several DRM drivers seem to be doing it anyway. The problem with removing the pgoff is that it prevents drm_vma_node_unmap from working because that searches the mapping tree by address. That doesn't work because all of the mappings are at offset 0. drm_vma_node_unmap is being used by the shmem helpers when purging the buffer. This fixes a bug in Panfrost which is using drm_gem_shmem_purge. Without this the mapping for the purged buffer can still be accessed which might mean it would access random pages from other buffers v2: Don't check whether the unsigned page_offset is less than 0. Cc: stable@vger.kernel.org Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Signed-off-by: Neil Roberts <nroberts@igalia.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210223155125.199577-3-nroberts@igalia.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17drm/shmem-helper: Check for purged buffers in fault handlerNeil Roberts1-4/+14
commit d611b4a0907cece060699f2fd347c492451cd2aa upstream. When a buffer is madvised as not needed and then purged, any attempts to access the buffer from user-space should cause a bus fault. This patch adds a check for that. Cc: stable@vger.kernel.org Fixes: 17acb9f35ed7 ("drm/shmem: Add madvise state and purge helpers") Signed-off-by: Neil Roberts <nroberts@igalia.com> Reviewed-by: Steven Price <steven.price@arm.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210223155125.199577-2-nroberts@igalia.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-17drm/compat: Clear bounce structuresDaniel Vetter1-0/+11
commit de066e116306baf3a6a62691ac63cfc0b1dabddb upstream. Some of them have gaps, or fields we don't clear. Native ioctl code does full copies plus zero-extends on size mismatch, so nothing can leak. But compat is more hand-rolled so need to be careful. None of these matter for performance, so just memset. Also I didn't fix up the CONFIG_DRM_LEGACY or CONFIG_DRM_AGP ioctl, those are security holes anyway. Acked-by: Maxime Ripard <mripard@kernel.org> Reported-by: syzbot+620cf21140fc7e772a5d@syzkaller.appspotmail.com # vblank ioctl Cc: syzbot+620cf21140fc7e772a5d@syzkaller.appspotmail.com Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210222100643.400935-1-daniel.vetter@ffwll.ch (cherry picked from commit e926c474ebee404441c838d18224cd6f246a71b7) Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-11drm/msm/a5xx: Remove overwriting A5XX_PC_DBG_ECO_CNTL registerAngeloGioacchino Del Regno1-2/+0
[ Upstream commit 8f03c30cb814213e36032084a01f49a9e604a3e3 ] The PC_DBG_ECO_CNTL register on the Adreno A5xx family gets programmed to some different values on a per-model basis. At least, this is what we intend to do here; Unfortunately, though, this register is being overwritten with a static magic number, right after applying the GPU-specific configuration (including the GPU-specific quirks) and that is effectively nullifying the efforts. Let's remove the redundant and wrong write to the PC_DBG_ECO_CNTL register in order to retain the wanted configuration for the target GPU. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Reviewed-by: Jordan Crouse <jcrouse@codeaurora.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-09drm/amdgpu: fix parameter error of RREG32_PCIE() in amdgpu_regs_pcieKevin Wang1-2/+2
commit 1aa46901ee51c1c5779b3b239ea0374a50c6d9ff upstream. the register offset isn't needed division by 4 to pass RREG32_PCIE() Signed-off-by: Kevin Wang <kevin1.wang@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@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>
2021-03-07drm/amd/display: Guard against NULL pointer deref when get_i2c_info failsNicholas Kazlauskas1-0/+5
[ Upstream commit 44a09e3d95bd2b7b0c224100f78f335859c4e193 ] [Why] If the BIOS table is invalid or corrupt then get_i2c_info can fail and we dereference a NULL pointer. [How] Check that ddc_pin is not NULL before using it and log an error if it is because this is unexpected. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Reviewed-by: Eric Yang <eric.yang2@amd.com> Acked-by: Anson Jacob <anson.jacob@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-07drm/amdgpu: Add check to prevent IH overflowDefang Bo3-39/+71
[ Upstream commit e4180c4253f3f2da09047f5139959227f5cf1173 ] Similar to commit <b82175750131>("drm/amdgpu: fix IH overflow on Vega10 v2"). When an ring buffer overflow happens the appropriate bit is set in the WPTR register which is also written back to memory. But clearing the bit in the WPTR doesn't trigger another memory writeback. So what can happen is that we end up processing the buffer overflow over and over again because the bit is never cleared. Resulting in a random system lockup because of an infinite loop in an interrupt handler. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Defang Bo <bodefang@126.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-07drm/hisilicon: Fix use-after-freeTian Tao1-1/+0
[ Upstream commit c855af2f9c5c60760fd1bed7889a81bc37d2591d ] Fix the problem of dev being released twice. ------------[ cut here ]------------ refcount_t: underflow; use-after-free. WARNING: CPU: 75 PID: 15700 at lib/refcount.c:28 refcount_warn_saturate+0xd4/0x150 CPU: 75 PID: 15700 Comm: rmmod Tainted: G E 5.10.0-rc3+ #3 Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 0.88 07/24/2019 pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--) pc : refcount_warn_saturate+0xd4/0x150 lr : refcount_warn_saturate+0xd4/0x150 sp : ffff2028150cbc00 x29: ffff2028150cbc00 x28: ffff2028150121c0 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000003 x23: 0000000000000000 x22: ffff2028150cbc90 x21: ffff2020038a30a8 x20: ffff2028150cbc90 x19: ffff0020cd938020 x18: 0000000000000010 x17: 0000000000000000 x16: 0000000000000000 x15: ffffffffffffffff x14: ffff2028950cb88f x13: ffff2028150cb89d x12: 0000000000000000 x11: 0000000005f5e0ff x10: ffff2028150cb800 x9 : 00000000ffffffd0 x8 : 75203b776f6c6672 x7 : ffff800011a6f7c8 x6 : 0000000000000001 x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000 x2 : ffff202ffe2f9dc0 x1 : ffffa02fecf40000 x0 : 0000000000000026 Call trace: refcount_warn_saturate+0xd4/0x150 devm_drm_dev_init_release+0x50/0x70 devm_action_release+0x20/0x30 release_nodes+0x13c/0x218 devres_release_all+0x80/0x170 device_release_driver_internal+0x128/0x1f0 driver_detach+0x6c/0xe0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x60 pci_unregister_driver+0x24/0xd8 hibmc_pci_driver_exit+0x14/0xe858 [hibmc_drm] __arm64_sys_delete_module+0x1fc/0x2d0 el0_svc_common.constprop.3+0xa8/0x188 do_el0_svc+0x80/0xa0 el0_sync_handler+0x8c/0xb0 el0_sync+0x15c/0x180 CPU: 75 PID: 15700 Comm: rmmod Tainted: G E 5.10.0-rc3+ #3 Hardware name: Huawei TaiShan 200 (Model 2280)/BC82AMDDA, BIOS 0.88 07/24/2019 Call trace: dump_backtrace+0x0/0x208 show_stack+0x2c/0x40 dump_stack+0xd8/0x10c __warn+0xac/0x128 report_bug+0xcc/0x180 bug_handler+0x24/0x78 call_break_hook+0x80/0xa0 brk_handler+0x28/0x68 do_debug_exception+0x9c/0x148 el1_sync_handler+0x7c/0x128 el1_sync+0x80/0x100 refcount_warn_saturate+0xd4/0x150 devm_drm_dev_init_release+0x50/0x70 devm_action_release+0x20/0x30 release_nodes+0x13c/0x218 devres_release_all+0x80/0x170 device_release_driver_internal+0x128/0x1f0 driver_detach+0x6c/0xe0 bus_remove_driver+0x74/0x100 driver_unregister+0x34/0x60 pci_unregister_driver+0x24/0xd8 hibmc_pci_driver_exit+0x14/0xe858 [hibmc_drm] __arm64_sys_delete_module+0x1fc/0x2d0 el0_svc_common.constprop.3+0xa8/0x188 do_el0_svc+0x80/0xa0 el0_sync_handler+0x8c/0xb0 el0_sync+0x15c/0x180 ---[ end trace 00718630d6e5ff18 ]--- Signed-off-by: Tian Tao <tiantao6@hisilicon.com> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/1607941973-32287-1-git-send-email-tiantao6@hisilicon.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-07drm/virtio: use kvmalloc for large allocationsSergey Senozhatsky1-2/+3
commit ea86f3defd55f141a44146e66cbf8ffb683d60da upstream. We observed that some of virtio_gpu_object_shmem_init() allocations can be rather costly - order 6 - which can be difficult to fulfill under memory pressure conditions. Switch to kvmalloc_array() in virtio_gpu_object_shmem_init() and let the kernel vmalloc the entries array. Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/20201105014744.1662226-1-senozhatsky@chromium.org Signed-off-by: Gerd Hoffmann <kraxel@redhat.com> Signed-off-by: Doug Horn <doughorn@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04drm/i915: Reject 446-480MHz HDMI clock on GLKVille Syrjälä1-1/+5
commit 7a6c6243b44a439bda4bf099032be35ebcf53406 upstream. The BXT/GLK DPLL can't generate certain frequencies. We already reject the 233-240MHz range on both. But on GLK the DPLL max frequency was bumped from 300MHz to 594MHz, so now we get to also worry about the 446-480MHz range (double the original problem range). Reject any frequency within the higher problematic range as well. Cc: stable@vger.kernel.org Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3000 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210203093044.30532-1-ville.syrjala@linux.intel.com Reviewed-by: Mika Kahola <mika.kahola@intel.com> (cherry picked from commit 41751b3e5c1ac656a86f8d45a8891115281b729e) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04drm/sched: Cancel and flush all outstanding jobs before finish.Andrey Grodzovsky1-0/+3
commit e582951baabba3e278c97169d0acc1e09b24a72e upstream. To avoid any possible use after free. Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/414814/ CC: stable@vger.kernel.org Signed-off-by: Christian König <christian.koenig@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04drm/nouveau/kms: handle mDP connectorsKarol Herbst2-0/+2
commit d1f5a3fc85566e9ddce9361ef180f070367e6eab upstream. In some cases we have the handle those explicitly as the fallback connector type detection fails and marks those as eDP connectors. Attempting to use such a connector with mutter leads to a crash of mutter as it ends up with two eDP displays. Information is taken from the official DCB documentation. Cc: stable@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: Ben Skeggs <bskeggs@redhat.com> Reported-by: Mark Pearson <markpearson@lenovo.com> Tested-by: Mark Pearson <markpearson@lenovo.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-03-04drm/amdgpu: Set reference clock to 100Mhz on Renoir (v2)Alex Deucher1-0/+2
commit 6e80fb8ab04f6c4f377e2fd422bdd1855beb7371 upstream. Fixes the rlc reference clock used for GPU timestamps. Value is 100Mhz. Confirmed with hardware team. v2: reword commit message. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1480 Acked-by: Christian König <christian.koenig@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>
2021-03-04drm/amd/display: Add vupdate_no_lock interrupts for DCN2.1Rodrigo Siqueira1-0/+22
commit 688f97ed3f5e339c0c2c09d9ee7ff23d5807b0a7 upstream. When run igt@kms_vrr in a device that uses DCN2.1 architecture, we noticed multiple failures. Furthermore, when we tested a VRR demo, we noticed a system hang where the mouse pointer still works, but the entire system freezes; in this case, we don't see any dmesg warning or failure messages kernel. This happens due to a lack of vupdate_no_lock interrupt, making the userspace wait eternally to get the event back. For fixing this issue, we need to add the vupdate_no_lock interrupt in the interrupt list. Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Bindu Ramamurthy <bindu.r@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>
2021-03-04drm/msm/mdp5: Fix wait-for-commit for cmd panelsIskren Chernev1-1/+1
[ Upstream commit 68e4f01fddb4ead80e8c7084db489307f22c9cbb ] Before the offending commit in msm_atomic_commit_tail wait_flush was called once per frame, after the commit was submitted. After it wait_flush is also called at the beginning to ensure previous potentially async commits are done. For cmd panels the source of wait_flush is a ping-pong irq notifying a completion. The completion needs to be notified with complete_all so multiple waiting parties (new async committers) can proceed. Signed-off-by: Iskren Chernev <iskren.chernev@gmail.com> Suggested-by: Rob Clark <robdclark@gmail.com> Fixes: 2d99ced787e3d ("drm/msm: async commit support") Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04drm/msm/dsi: Correct io_start for MSM8994 (20nm PHY)Konrad Dybcio1-1/+1
[ Upstream commit 33a7808ce1aea6e2edc1af25db25928137940c02 ] The previous registers were *almost* correct, but instead of PHYs, they were pointing at DSI PLLs, resulting in the PHY id autodetection failing miserably. Fixes: dcefc117cc19 ("drm/msm/dsi: Add support for msm8x94") Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04drm/amdgpu: Prevent shift wrapping in amdgpu_read_mask()Dan Carpenter1-3/+3
[ Upstream commit c915ef890d5dc79f483e1ca3b3a5b5f1a170690c ] If the user passes a "level" value which is higher than 31 then that leads to shift wrapping. The undefined behavior will lead to a syzkaller stack dump. Fixes: 5632708f4452 ("drm/amd/powerplay: add dpm force multiple levels on cz/tonga/fiji/polaris (v2)") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04drm/nouveau: bail out of nouveau_channel_new if channel init failsFrantisek Hrbata1-0/+1
[ Upstream commit eaba3b28401f50e22d64351caa8afe8d29509f27 ] Unprivileged user can crash kernel by using DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC ioctl. This was reported by trinity[1] fuzzer. [ 71.073906] nouveau 0000:01:00.0: crashme[1329]: channel failed to initialise, -17 [ 71.081730] BUG: kernel NULL pointer dereference, address: 00000000000000a0 [ 71.088928] #PF: supervisor read access in kernel mode [ 71.094059] #PF: error_code(0x0000) - not-present page [ 71.099189] PGD 119590067 P4D 119590067 PUD 1054f5067 PMD 0 [ 71.104842] Oops: 0000 [#1] SMP NOPTI [ 71.108498] CPU: 2 PID: 1329 Comm: crashme Not tainted 5.8.0-rc6+ #2 [ 71.114993] Hardware name: AMD Pike/Pike, BIOS RPK1506A 09/03/2014 [ 71.121213] RIP: 0010:nouveau_abi16_ioctl_channel_alloc+0x108/0x380 [nouveau] [ 71.128339] Code: 48 89 9d f0 00 00 00 41 8b 4c 24 04 41 8b 14 24 45 31 c0 4c 8d 4b 10 48 89 ee 4c 89 f7 e8 10 11 00 00 85 c0 75 78 48 8b 43 10 <8b> 90 a0 00 00 00 41 89 54 24 08 80 7d 3d 05 0f 86 bb 01 00 00 41 [ 71.147074] RSP: 0018:ffffb4a1809cfd38 EFLAGS: 00010246 [ 71.152526] RAX: 0000000000000000 RBX: ffff98cedbaa1d20 RCX: 00000000000003bf [ 71.159651] RDX: 00000000000003be RSI: 0000000000000000 RDI: 0000000000030160 [ 71.166774] RBP: ffff98cee776de00 R08: ffffdc0144198a08 R09: ffff98ceeefd4000 [ 71.173901] R10: ffff98cee7e81780 R11: 0000000000000001 R12: ffffb4a1809cfe08 [ 71.181214] R13: ffff98cee776d000 R14: ffff98cec519e000 R15: ffff98cee776def0 [ 71.188339] FS: 00007fd926250500(0000) GS:ffff98ceeac80000(0000) knlGS:0000000000000000 [ 71.196418] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 71.202155] CR2: 00000000000000a0 CR3: 0000000106622000 CR4: 00000000000406e0 [ 71.209297] Call Trace: [ 71.211777] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] [ 71.218053] drm_ioctl_kernel+0xac/0xf0 [drm] [ 71.222421] drm_ioctl+0x211/0x3c0 [drm] [ 71.226379] ? nouveau_abi16_ioctl_getparam+0x1f0/0x1f0 [nouveau] [ 71.232500] nouveau_drm_ioctl+0x57/0xb0 [nouveau] [ 71.237285] ksys_ioctl+0x86/0xc0 [ 71.240595] __x64_sys_ioctl+0x16/0x20 [ 71.244340] do_syscall_64+0x4c/0x90 [ 71.248110] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 71.253162] RIP: 0033:0x7fd925d4b88b [ 71.256731] Code: Bad RIP value. [ 71.259955] RSP: 002b:00007ffc743592d8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010 [ 71.267514] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd925d4b88b [ 71.274637] RDX: 0000000000601080 RSI: 00000000c0586442 RDI: 0000000000000003 [ 71.281986] RBP: 00007ffc74359340 R08: 00007fd926016ce0 R09: 00007fd926016ce0 [ 71.289111] R10: 0000000000000003 R11: 0000000000000206 R12: 0000000000400620 [ 71.296235] R13: 00007ffc74359420 R14: 0000000000000000 R15: 0000000000000000 [ 71.303361] Modules linked in: rfkill sunrpc snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core edac_mce_amd snd_hwdep kvm_amd snd_seq ccp snd_seq_device snd_pcm kvm snd_timer snd irqbypass soundcore sp5100_tco pcspkr crct10dif_pclmul crc32_pclmul ghash_clmulni_intel wmi_bmof joydev i2c_piix4 fam15h_power k10temp acpi_cpufreq ip_tables xfs libcrc32c sd_mod t10_pi sg nouveau video mxm_wmi i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm broadcom bcm_phy_lib ata_generic ahci drm e1000 crc32c_intel libahci serio_raw tg3 libata firewire_ohci firewire_core wmi crc_itu_t dm_mirror dm_region_hash dm_log dm_mod [ 71.365269] CR2: 00000000000000a0 simplified reproducer ---------------------------------8<---------------------------------------- /* * gcc -o crashme crashme.c * ./crashme /dev/dri/renderD128 */ struct drm_nouveau_channel_alloc { uint32_t fb_ctxdma_handle; uint32_t tt_ctxdma_handle; int channel; uint32_t pushbuf_domains; /* Notifier memory */ uint32_t notifier_handle; /* DRM-enforced subchannel assignments */ struct { uint32_t handle; uint32_t grclass; } subchan[8]; uint32_t nr_subchan; }; static struct drm_nouveau_channel_alloc channel; int main(int argc, char *argv[]) { int fd; int rv; if (argc != 2) die("usage: %s <dev>", 0, argv[0]); if ((fd = open(argv[1], O_RDONLY)) == -1) die("open %s", errno, argv[1]); if (ioctl(fd, DRM_IOCTL_NOUVEAU_CHANNEL_ALLOC, &channel) == -1 && errno == EACCES) die("ioctl %s", errno, argv[1]); close(fd); printf("PASS\n"); return 0; } ---------------------------------8<---------------------------------------- [1] https://github.com/kernelslacker/trinity Fixes: eeaf06ac1a55 ("drm/nouveau/svm: initial support for shared virtual memory") Signed-off-by: Frantisek Hrbata <frantisek@hrbata.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04drm/amd/display: Fix HDMI deep color output for DCE 6-11.Mario Kleiner3-0/+76
[ Upstream commit efa18405baa55a864c61d2f3cc6fe4d363818eb3 ] This fixes corrupted display output in HDMI deep color 10/12 bpc mode at least as observed on AMD Mullins, DCE-8.3. It will hopefully also provide fixes for other DCE's up to DCE-11, assuming those will need similar fixes, but i could not test that for HDMI due to lack of suitable hw, so viewer discretion is advised. dce110_stream_encoder_hdmi_set_stream_attribute() is used for HDMI setup on all DCE's and is missing color_depth assignment. dce110_program_pix_clk() is used for pixel clock setup on HDMI for DCE 6-11, and is missing color_depth assignment. Additionally some of the underlying Atombios specific encoder and pixelclock setup functions are missing code which is in the classic amdgpu kms modesetting path and the in the radeon kms driver for DCE6/DCE8. encoder_control_digx_v3() - Was missing setup code wrt. amdgpu and radeon kms classic drivers. Added here, but untested due to lack of suitable test hw. encoder_control_digx_v4() - Added missing setup code. Successfully tested on AMD mullins / DCE-8.3 with HDMI deep color output at 10 bpc and 12 bpc. Note that encoder_control_digx_v5() has proper setup code in place and is used, e.g., by DCE-11.2, but this code wasn't used for deep color setup due to the missing cntl.color_depth setup in the calling function for HDMI. set_pixel_clock_v5() - Missing setup code wrt. classic amdgpu/radeon kms. Added here, but untested due to lack of hw. set_pixel_clock_v6() - Missing setup code added. Successfully tested on AMD mullins DCE-8.3. This fixes corrupted display output at HDMI deep color output with 10 bpc or 12 bpc. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04drm/amd/display: Fix 10/12 bpc setup in DCE output bit depth reduction.Mario Kleiner1-4/+4
[ Upstream commit 1916866dfa4aaceba1a70db83fde569387649d93 ] In set_clamp(), the comments and definitions for the COLOR_DEPTH_101010 and COLOR_DEPTH_121212 cases directly contradict the code comment which explains how this should work, whereas the COLOR_DEPTH_888 case is consistent with the code comments. Comment says the bitmask should be chosen to align to the top-most 10 or 12 MSB's on a 14 bit bus, but the implementation contradicts that: 10 bit case sets a mask for 12 bpc clamping, whereas 12 bit case sets a mask for 14 bpc clamping. Note that during my limited testing on DCE-8.3 (HDMI deep color) and DCE-11.2 (DP deep color), this didn't have any obvious ill effects, neither did fixing it change anything obvious for the better, so this fix may be inconsequential on DCE, and just reduce the confusion of innocent bystanders when reading the code and trying to investigate problems with 10 bpc+ output. Fixes: 4562236b3bc0 ("drm/amd/dc: Add dc display driver (v2)") Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04drm/sun4i: tcon: fix inverted DCLK polarityGiulio Benetti2-19/+3
[ Upstream commit 67f4aeb2b41a0629abde3794d463547f60b0cbdd ] During commit 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") DRM_BUS_FLAG_* macros have been changed to avoid ambiguity but just because of this ambiguity previous DRM_BUS_FLAG_PIXDATA_(POS/NEG)EDGE were used meaning _SAMPLE_ not _DRIVE_. This leads to DLCK inversion and need to fix but instead of swapping phase values, let's adopt an easier approach Maxime suggested: It turned out that bit 26 of SUN4I_TCON0_IO_POL_REG is dedicated to invert DCLK polarity and this makes things really easier than before. So let's handle DCLK polarity by adding SUN4I_TCON0_IO_POL_DCLK_DRIVE_NEGEDGE as bit 26 and activating according to bus_flags the same way it is done for all the other signals polarity. Fixes: 88bc4178568b ("drm: Use new DRM_BUS_FLAG_*_(DRIVE|SAMPLE)_(POS|NEG)EDGE flags") Suggested-by: Maxime Ripard <maxime@cerno.tech> Signed-off-by: Giulio Benetti <giulio.benetti@micronovasrl.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210114081732.9386-1-giulio.benetti@benettiengineering.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04drm/amdgpu: Fix macro name _AMDGPU_TRACE_H_ in preprocessor if conditionChenyang Li1-1/+1
[ Upstream commit 956e20eb0fbb206e5e795539db5469db099715c8 ] Add an underscore in amdgpu_trace.h line 24 "_AMDGPU_TRACE_H". Fixes: d38ceaf99ed0 ("drm/amdgpu: add core driver (v4)") Reviewed-by: Guchun Chen <guchun.chen@amd.com> Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de> Signed-off-by: Chenyang Li <lichenyang@loongson.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04drm/fb-helper: Add missed unlocks in setcmap_legacy()Chuhong Yuan1-5/+10
[ Upstream commit 0a260e731d6c4c17547ac275a2cde888a9eb4a3d ] setcmap_legacy() does not call drm_modeset_unlock_all() in some exits, add the missed unlocks with goto to fix it. Fixes: 964c60063bff ("drm/fb-helper: separate the fb_setcmap helper into atomic and legacy paths") Signed-off-by: Chuhong Yuan <hslester96@gmail.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201203144248.418281-1-hslester96@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04gma500: clean up error handling in initDan Carpenter1-9/+13
[ Upstream commit 15ccc39b3aab667c6fa131206f01f31bfbccdf6a ] The main problem with this error handling was that it didn't clean up if i2c_add_numbered_adapter() failed. This code is pretty old, and doesn't match with today's checkpatch.pl standards so I took the opportunity to tidy it up a bit. I changed the NULL comparison, and removed the WARNING message if kzalloc() fails and updated the label names. Fixes: 1b082ccf5901 ("gma500: Add Oaktrail support") Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/X8ikkAqZfnDO2lu6@mwanda Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-03-04drm/gma500: Fix error return code in psb_driver_load()Jialin Zhang1-0/+2
[ Upstream commit 6926872ae24452d4f2176a3ba2dee659497de2c4 ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 5c49fd3aa0ab ("gma500: Add the core DRM files and headers") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Jialin Zhang <zhangjialin11@huawei.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20201130020216.1906141-1-zhangjialin11@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-17drm/sun4i: dw-hdmi: Fix max. frequency for H6Jernej Skrabec1-4/+2
[ Upstream commit 1926a0508d8947cf081280d85ff035300dc71da7 ] It turns out that reasoning for lowering max. supported frequency is wrong. Scrambling works just fine. Several now fixed bugs prevented proper functioning, even with rates lower than 340 MHz. Issues were just more pronounced with higher frequencies. Fix that by allowing max. supported frequency in HW and fix the comment. Fixes: cd9063757a22 ("drm/sun4i: DW HDMI: Lower max. supported rate for H6") Reviewed-by: Chen-Yu Tsai <wens@csie.org> Tested-by: Andre Heider <a.heider@gmail.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-6-jernej.skrabec@siol.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-17drm/sun4i: Fix H6 HDMI PHY configurationJernej Skrabec1-17/+9
[ Upstream commit 6a155216c48f2f65c8dcb02c4c27549c170d24a9 ] As it turns out, vendor HDMI PHY driver for H6 has a pretty big table of predefined values for various pixel clocks. However, most of them are not useful/tested because they come from reference driver code. Vendor PHY driver is concerned with only few of those, namely 27 MHz, 74.25 MHz, 148.5 MHz, 297 MHz and 594 MHz. These are all frequencies for standard CEA modes. Fix sun50i_h6_cur_ctr and sun50i_h6_phy_config with the values only for aforementioned frequencies. Table sun50i_h6_mpll_cfg doesn't need to be changed because values are actually frequency dependent and not so much SoC dependent. See i.MX6 documentation for explanation of those values for similar PHY. Fixes: c71c9b2fee17 ("drm/sun4i: Add support for Synopsys HDMI PHY") Tested-by: Andre Heider <a.heider@gmail.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-5-jernej.skrabec@siol.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-17drm/sun4i: tcon: set sync polarity for tcon1 channelJernej Skrabec2-0/+31
[ Upstream commit 50791f5d7b6a14b388f46c8885f71d1b98216d1d ] Channel 1 has polarity bits for vsync and hsync signals but driver never sets them. It turns out that with pre-HDMI2 controllers seemingly there is no issue if polarity is not set. However, with HDMI2 controllers (H6) there often comes to de-synchronization due to phase shift. This causes flickering screen. It's safe to assume that similar issues might happen also with pre-HDMI2 controllers. Solve issue with setting vsync and hsync polarity. Note that display stacks with tcon top have polarity bits actually in tcon0 polarity register. Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Reviewed-by: Chen-Yu Tsai <wens@csie.org> Tested-by: Andre Heider <a.heider@gmail.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210209175900.7092-3-jernej.skrabec@siol.net Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-17drm/vc4: hvs: Fix buffer overflow with the dlist handlingMaxime Ripard1-4/+14
[ Upstream commit facd93f4285c405f9a91b05166147cb39e860666 ] Commit 0a038c1c29a7 ("drm/vc4: Move LBM creation out of vc4_plane_mode_set()") changed the LBM allocation logic from first allocating the LBM memory for the plane to running mode_set, adding a gap in the LBM, and then running the dlist allocation filling that gap. The gap was introduced by incrementing the dlist array index, but was never checking whether or not we were over the array length, leading eventually to memory corruptions if we ever crossed this limit. vc4_dlist_write had that logic though, and was reallocating a larger dlist array when reaching the end of the buffer. Let's share the logic between both functions. Cc: Boris Brezillon <boris.brezillon@collabora.com> Cc: Eric Anholt <eric@anholt.net> Fixes: 0a038c1c29a7 ("drm/vc4: Move LBM creation out of vc4_plane_mode_set()") Signed-off-by: Maxime Ripard <maxime@cerno.tech> Acked-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210129160647.128373-1-maxime@cerno.tech Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-17drm/amd/display: Decrement refcount of dc_sink before reassignmentVictor Lu1-1/+3
[ Upstream commit 8e92bb0fa75bca9a57e4aba2e36f67d8016a3053 ] [why] An old dc_sink state is causing a memory leak because it is missing a dc_sink_release before a new dc_sink is assigned back to aconnector->dc_sink. [how] Decrement the dc_sink refcount before reassigning it to a new dc_sink. Signed-off-by: Victor Lu <victorchengchi.lu@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-17drm/amd/display: Free atomic state after drm_atomic_commitVictor Lu1-8/+6
[ Upstream commit 2abaa323d744011982b20b8f3886184d56d23946 ] [why] drm_atomic_commit was changed so that the caller must free their drm_atomic_state reference on successes. [how] Add drm_atomic_commit_put after drm_atomic_commit call in dm_force_atomic_commit. Signed-off-by: Victor Lu <victorchengchi.lu@amd.com> Reviewed-by: Roman Li <Roman.Li@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-17drm/amd/display: Fix dc_sink kref count in emulated_link_detectVictor Lu1-2/+2
[ Upstream commit 3ddc818d9bb877c64f5c649beab97af86c403702 ] [why] prev_sink is not used anywhere else in the function and the reference to it from dc_link is replaced with a new dc_sink. [how] Change dc_sink_retain(prev_sink) to dc_sink_release(prev_sink). Signed-off-by: Victor Lu <victorchengchi.lu@amd.com> Reviewed-by: Nicholas Kazlauskas <Nicholas.Kazlauskas@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-17drm/amd/display: Add more Clock Sources to DCN2.1Sung Lee1-0/+10
[ Upstream commit 1622711beebe887e4f0f8237fea1f09bb48e9a51 ] [WHY] When enabling HDMI on ComboPHY, there are not enough clock sources to complete display detection. [HOW] Initialize more clock sources. Signed-off-by: Sung Lee <sung.lee@amd.com> Reviewed-by: Tony Cheng <Tony.Cheng@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-10drm/amd/display: Revert "Fix EDID parsing after resume from suspend"Stylon Wang1-2/+0
commit 1a10e5244778169a5a53a527d7830cf0438132a1 upstream. This reverts commit b24bdc37d03a0478189e20a50286092840f414fa. It caused memory leak after S3 on 4K HDMI displays. Signed-off-by: Stylon Wang <stylon.wang@amd.com> Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@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>
2021-02-07drm/amd/display: Change function decide_dp_link_settings to avoid infinite ↵Bing Guo1-0/+3
looping [ Upstream commit 4716a7c50c5c66d6ddc42401e1e0ba13b492e105 ] Why: Function decide_dp_link_settings() loops infinitely when required bandwidth can't be supported. How: Check the required bandwidth against verified_link_cap before trying to find a link setting for it. Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Bing Guo <bing.guo@amd.com> Reviewed-by: Jun Lei <Jun.Lei@amd.com> Acked-by: Anson Jacob <anson.jacob@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-02-07drm/amd/display: Update dram_clock_change_latency for DCN2.1Jake Wang1-1/+1
[ Upstream commit 901c1ec05ef277ce9d43cb806a225b28b3efe89a ] [WHY] dram clock change latencies get updated using ddr4 latency table, but does that update does not happen before validation. This value should not be the default and should be number received from df for better mode support. This may cause a PState hang on high refresh panels with short vblanks such as on 1080p 360hz or 300hz panels. [HOW] Update latency from 23.84 to 11.72. Signed-off-by: Sung Lee <sung.lee@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>
generated by cgit v1.2.3 (git 2.39.0) at 2025-10-02 18:19:26 +0300