kernel/linux.git/drivers/gpu/drm, branch v5.15.7

Revert "drm/i915: Implement Wa_1508744258"

2021-12-08T08:04:53+00:00

[ Upstream commit 72641d8d60401a5f1e1a0431ceaf928680d34418 ] This workarounds are causing hangs, because I missed the fact that it needs to be enabled for all cases and disabled when doing a resolve pass. So KMD only needs to whitelist it and UMD will be the one setting it on per case. This reverts commit 28ec02c9cbebf3feeaf21a59df9dfbc02bda3362. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4145 Signed-off-by: José Roberto de Souza Fixes: 28ec02c9cbeb ("drm/i915: Implement Wa_1508744258") Reviewed-by: Matt Atwood Link: https://patchwork.freedesktop.org/patch/msgid/20211119140931.32791-1-jose.souza@intel.com (cherry picked from commit f3799ff16fcfacd44aee55db162830df461b631f) Signed-off-by: Rodrigo Vivi Signed-off-by: Sasha Levin

drm/msm: Restore error return on invalid fence

2021-12-08T08:04:52+00:00

[ Upstream commit 067ecab9eef620d41040715669e5fcdc2f8ff963 ] When converting to use an idr to map userspace fence seqno values back to a dma_fence, we lost the error return when userspace passes seqno that is larger than the last submitted fence. Restore this check. Reported-by: Akhil P Oommen Fixes: a61acbbe9cf8 ("drm/msm: Track "seqno" fences by idr") Signed-off-by: Rob Clark Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20211111192457.747899-3-robdclark@gmail.com Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/msm: Fix wait_fence submitqueue leak

2021-12-08T08:04:52+00:00

[ Upstream commit ea0006d390a28012f8187717aea61498b2b341e5 ] We weren't dropping the submitqueue reference in all paths. In particular, when the fence has already been signalled. Split out a helper to simplify handling this in the various different return paths. Fixes: a61acbbe9cf8 ("drm/msm: Track "seqno" fences by idr") Signed-off-by: Rob Clark Link: https://lore.kernel.org/r/20211111192457.747899-2-robdclark@gmail.com Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/msm: Fix mmap to include VM_IO and VM_DONTDUMP

2021-12-08T08:04:52+00:00

[ Upstream commit 3466d9e217b337bf473ee629c608e53f9f3ab786 ] In commit 510410bfc034 ("drm/msm: Implement mmap as GEM object function") we switched to a new/cleaner method of doing things. That's good, but we missed a little bit. Before that commit, we used to _first_ run through the drm_gem_mmap_obj() case where `obj->funcs->mmap()` was NULL. That meant that we ran: vma->vm_flags |= VM_IO | VM_PFNMAP | VM_DONTEXPAND | VM_DONTDUMP; vma->vm_page_prot = pgprot_writecombine(vm_get_page_prot(vma->vm_flags)); vma->vm_page_prot = pgprot_decrypted(vma->vm_page_prot); ...and _then_ we modified those mappings with our own. Now that `obj->funcs->mmap()` is no longer NULL we don't run the default code. It looks like the fact that the vm_flags got VM_IO / VM_DONTDUMP was important because we're now getting crashes on Chromebooks that use ARC++ while logging out. Specifically a crash that looks like this (this is on a 5.10 kernel w/ relevant backports but also seen on a 5.15 kernel): Unable to handle kernel paging request at virtual address ffffffc008000000 Mem abort info: ESR = 0x96000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 swapper pgtable: 4k pages, 39-bit VAs, pgdp=000000008293d000 [ffffffc008000000] pgd=00000001002b3003, p4d=00000001002b3003, pud=00000001002b3003, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP [...] CPU: 7 PID: 15734 Comm: crash_dump64 Tainted: G W 5.10.67 #1 [...] Hardware name: Qualcomm Technologies, Inc. sc7280 IDP SKU2 platform (DT) pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--) pc : __arch_copy_to_user+0xc0/0x30c lr : copyout+0xac/0x14c [...] Call trace: __arch_copy_to_user+0xc0/0x30c copy_page_to_iter+0x1a0/0x294 process_vm_rw_core+0x240/0x408 process_vm_rw+0x110/0x16c __arm64_sys_process_vm_readv+0x30/0x3c el0_svc_common+0xf8/0x250 do_el0_svc+0x30/0x80 el0_svc+0x10/0x1c el0_sync_handler+0x78/0x108 el0_sync+0x184/0x1c0 Code: f8408423 f80008c3 910020c6 36100082 (b8404423) Let's add the two flags back in. While we're at it, the fact that we aren't running the default means that we _don't_ need to clear out VM_PFNMAP, so remove that and save an instruction. NOTE: it was confirmed that VM_IO was the important flag to fix the problem I was seeing, but adding back VM_DONTDUMP seems like a sane thing to do so I'm doing that too. Fixes: 510410bfc034 ("drm/msm: Implement mmap as GEM object function") Reported-by: Stephen Boyd Signed-off-by: Douglas Anderson Reviewed-by: Stephen Boyd Tested-by: Stephen Boyd Link: https://lore.kernel.org/r/20211110113334.1.I1687e716adb2df746da58b508db3f25423c40b27@changeid Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/msm/devfreq: Fix OPP refcnt leak

2021-12-08T08:04:52+00:00

[ Upstream commit 59ba1b2b4825342676300f66d785764be3fcb093 ] Reported-by: Douglas Anderson Fixes: 9bc95570175a ("drm/msm: Devfreq tuning") Signed-off-by: Rob Clark Reviewed-by: Douglas Anderson Tested-By: Steev Klimaszewski Reviewed-by: Akhil P Oommen Link: https://lore.kernel.org/r/20211105202021.181092-1-robdclark@gmail.com Signed-off-by: Rob Clark Signed-off-by: Sasha Levin

drm/vc4: kms: Fix previous HVS commit wait

2021-12-08T08:04:50+00:00

commit 6052a3110be208e547a4a8aeb184446199a16e8a upstream. Our current code is supposed to serialise the commits by waiting for all the drm_crtc_commits associated to the previous HVS state. However, assuming we have two CRTCs running and being configured and we configure each one alternately, we end up in a situation where we're not waiting at all. Indeed, starting with a state (state 0) where both CRTCs are running, and doing a commit (state 1) on the first CRTC (CRTC 0), we'll associate its commit to its assigned FIFO in vc4_hvs_state. If we get a new commit (state 2), this time affecting the second CRTC (CRTC 1), the DRM core will allow both commits to execute in parallel (assuming they don't have any share resources). Our code in vc4_atomic_commit_tail is supposed to make sure we only get one commit at a time and serialised by order of submission. It does so by using for_each_old_crtc_in_state, making sure that the CRTC has a FIFO assigned, is used, and has a commit pending. If it does, then we'll wait for the commit before going forward. During the transition from state 0 to state 1, as our old CRTC state we get the CRTC 0 state 0, its commit, we wait for it, everything works fine. During the transition from state 1 to state 2 though, the use of for_each_old_crtc_in_state is wrong. Indeed, while the code assumes it's returning the state of the CRTC in the old state (so CRTC 0 state 1), it actually returns the old state of the CRTC affected by the current commit, so CRTC 0 state 0 since it wasn't part of state 1. Due to this, if we alternate between the configuration of CRTC 0 and CRTC 1, we never actually wait for anything since we should be waiting on the other every time, but it never is affected by the previous commit. Change the logic to, at every commit, look at every FIFO in the previous HVS state, and if it's in use and has a commit associated to it, wait for that commit. Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Tested-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20211117094527.146275-7-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman

drm/vc4: kms: Don't duplicate pending commit

2021-12-08T08:04:50+00:00

commit d354699e2292c60f25496d3c31ce4e7b1563b899 upstream. Our HVS global state, when duplicated, will also copy the pointer to the drm_crtc_commit (and increase the reference count) for each FIFO if the pointer is not NULL. However, our atomic_setup function will overwrite that pointer without putting the reference back leading to a memory leak. Since the commit is only relevant during the atomic commit process, it doesn't make sense to duplicate the reference to the commit anyway. Let's remove it. Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Tested-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20211117094527.146275-6-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman

drm/vc4: kms: Clear the HVS FIFO commit pointer once done

2021-12-08T08:04:50+00:00

commit d134c5ff71c7f2320fc7997f2fbbdedf0c76889a upstream. Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a wait on the previous commit done on a given HVS FIFO. However, we never cleared that pointer once done. Since drm_crtc_commit_put can free the drm_crtc_commit structure directly if we were the last user, this means that it can lead to a use-after free if we were to duplicate the state, and that stale pointer would even be copied to the new state. Set the pointer to NULL once we're done with the wait so that we don't carry over a pointer to a free'd structure. Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Tested-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20211117094527.146275-5-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman

drm/vc4: kms: Add missing drm_crtc_commit_put

2021-12-08T08:04:50+00:00

commit 049cfff8d53a30cae3349ff71a4c01b7d9981bc2 upstream. Commit 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") introduced a global state for the HVS, with each FIFO storing the current CRTC commit so that we can properly synchronize commits. However, the refcounting was off and we thus ended up leaking the drm_crtc_commit structure every commit. Add a drm_crtc_commit_put to prevent the leakage. Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Tested-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20211117094527.146275-4-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman

drm/vc4: kms: Fix return code check

2021-12-08T08:04:50+00:00

commit f927767978d201d4ac023fcd797adbb963a6565d upstream. The HVS global state functions return an error pointer, but in most cases we check if it's NULL, possibly resulting in an invalid pointer dereference. Fixes: 9ec03d7f1ed3 ("drm/vc4: kms: Wait on previous FIFO users before a commit") Signed-off-by: Maxime Ripard Reviewed-by: Dave Stevenson Tested-by: Jian-Hong Pan Link: https://lore.kernel.org/r/20211117094527.146275-3-maxime@cerno.tech Signed-off-by: Greg Kroah-Hartman