summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2021-10-20drm/edid: In connector_bad_edid() cap num_of_ext by num_blocks readDouglas Anderson1-3/+12
commit 97794170b696856483f74b47bfb6049780d2d3a0 upstream. In commit e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test") the function connector_bad_edid() started assuming that the memory for the EDID passed to it was big enough to hold `edid[0x7e] + 1` blocks of data (1 extra for the base block). It completely ignored the fact that the function was passed `num_blocks` which indicated how much memory had been allocated for the EDID. Let's fix this by adding a bounds check. This is important for handling the case where there's an error in the first block of the EDID. In that case we will call connector_bad_edid() without having re-allocated memory based on `edid[0x7e]`. Fixes: e11f5bd8228f ("drm: Add support for DP 1.4 Compliance edid corruption test") Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20211005192905.v2.1.Ib059f9c23c2611cb5a9d760e7d0a700c1295928d@changeid Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20drm/panel: olimex-lcd-olinuxino: select CRC32Vegard Nossum1-0/+1
commit a14bc107edd0c108bda2245e50daa22f91c95d20 upstream. Fix the following build/link error by adding a dependency on the CRC32 routines: ld: drivers/gpu/drm/panel/panel-olimex-lcd-olinuxino.o: in function `lcd_olinuxino_probe': panel-olimex-lcd-olinuxino.c:(.text+0x303): undefined reference to `crc32_le' Fixes: 17fd7a9d324fd ("drm/panel: Add support for Olimex LCD-OLinuXino panel") Cc: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Sam Ravnborg <sam@ravnborg.org> Link: https://patchwork.freedesktop.org/patch/msgid/20211012115242.10325-1-vegard.nossum@oracle.com Signed-off-by: Dave Airlie <airlied@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-20drm/msm: Avoid potential overflow in timeout_to_jiffies()Marek Vasut1-2/+2
commit 171316a68d9a8e0d9e28b7cf4c15afc4c6244a4e upstream. The return type of ktime_divns() is s64. The timeout_to_jiffies() currently assigns the result of this ktime_divns() to unsigned long, which on 32 bit systems may overflow. Furthermore, the result of this function is sometimes also passed to functions which expect signed long, dma_fence_wait_timeout() is one such example. Fix this by adjusting the type of remaining_jiffies to s64, so we do not suffer overflow there, and return a value limited to range of 0..INT_MAX, which is safe for all usecases of this timeout. The above overflow can be triggered if userspace passes in too large timeout value, larger than INT_MAX / HZ seconds. The kernel detects it and complains about "schedule_timeout: wrong timeout value %lx" and generates a warning backtrace. Note that this fixes commit 6cedb8b377bb ("drm/msm: avoid using 'timespec'"), because the previously used timespec_to_jiffies() function returned unsigned long instead of s64: static inline unsigned long timespec_to_jiffies(const struct timespec *value) Fixes: 6cedb8b377bb ("drm/msm: avoid using 'timespec'") Signed-off-by: Marek Vasut <marex@denx.de> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Rob Clark <robdclark@chromium.org> Cc: stable@vger.kernel.org # 5.6+ Acked-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20210917005913.157379-1-marex@denx.de Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-17drm/amdgpu: fix gart.bo pin_count leakLeslie Shi2-2/+4
[ Upstream commit 66805763a97f8f7bdf742fc0851d85c02ed9411f ] gmc_v{9,10}_0_gart_disable() isn't called matched with correspoding gart_enbale function in SRIOV case. This will lead to gart.bo pin_count leak on driver unload. Cc: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Leslie Shi <Yuliang.Shi@amd.com> Signed-off-by: Guchun Chen <guchun.chen@amd.com> Reviewed-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-10-13drm/nouveau/debugfs: fix file release memory leakYang Yingliang1-0/+1
[ Upstream commit f5a8703a9c418c6fc54eb772712dfe7641e3991c ] When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked. Fixes: 6e9fc177399f ("drm/nouveau/debugfs: add copy of sysfs pstate interface ported to debugfs") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210911075023.3969054-2-yangyingliang@huawei.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13drm/nouveau/kms/nv50-: fix file release memory leakYang Yingliang1-0/+1
[ Upstream commit 0b3d4945cc7e7ea1acd52cb06dfa83bfe265b6d5 ] When using single_open() for opening, single_release() should be called, otherwise the 'op' allocated in single_open() will be leaked. Fixes: 12885ecbfe62 ("drm/nouveau/kms/nvd9-: Add CRC support") Reported-by: Hulk Robot <hulkci@huawei.com> Signed-off-by: Yang Yingliang <yangyingliang@huawei.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210911075023.3969054-1-yangyingliang@huawei.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13drm/nouveau: avoid a use-after-free when BO init failsJeremy Cline1-3/+1
[ Upstream commit bcf34aa5082ee2343574bc3f4d1c126030913e54 ] nouveau_bo_init() is backed by ttm_bo_init() and ferries its return code back to the caller. On failures, ttm_bo_init() invokes the provided destructor which should de-initialize and free the memory. Thus, when nouveau_bo_init() returns an error the gem object has already been released and the memory freed by nouveau_bo_del_ttm(). Fixes: 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM object") Cc: Thierry Reding <treding@nvidia.com> Signed-off-by: Jeremy Cline <jcline@redhat.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201203000220.18238-1-jcline@redhat.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13drm/sun4i: dw-hdmi: Fix HDMI PHY clock setupJernej Skrabec3-47/+61
[ Upstream commit c64c8e04a12ed3e2238761e26cda78e72550dc98 ] Recent rework, which made HDMI PHY driver a platform device, inadvertely reversed clock setup order. HW is very touchy about it. Proper way is to handle controllers resets and clocks first and HDMI PHYs second. Currently, without this fix, first mode set completely fails (nothing on HDMI monitor) on H3 era PHYs. On H6, it still somehow work. Move HDMI PHY reset & clocks handling to sun8i_hdmi_phy_init() which will assure that code is executed after controllers reset & clocks are handled. Additionally, add sun8i_hdmi_phy_deinit() which will deinit them at controllers driver unload. Tested on A64, H3, H6 and R40. Fixes: 9bf3797796f5 ("drm/sun4i: dw-hdmi: Make HDMI PHY into a platform device") Signed-off-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20210915175836.3158839-1-jernej.skrabec@gmail.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-13drm/nouveau/kms/tu102-: delay enabling cursor until after assign_windowsBen Skeggs1-1/+1
commit f732e2e34aa08493fdd762f3daa4e5f16bbf1e45 upstream. Prevent NVD core channel error code 67 occuring and hanging display, managed to reproduce on GA102 while testing suspend/resume scenarios. Required extension of earlier commit to fix interactions with EFI. Fixes: e78b1b545c6c ("drm/nouveau/kms/nv50: workaround EFI GOP window channel format differences") Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: Lyude Paul <lyude@redhat.com> Cc: Karol Herbst <kherbst@redhat.com> Cc: <stable@vger.kernel.org> # v5.12+ Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210906005628.11499-2-skeggsb@gmail.com Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-10-06drm/i915/request: fix early tracepointsMatthew Auld1-9/+2
[ Upstream commit c83ff0186401169eb27ce5057d820b7a863455c3 ] Currently we blow up in trace_dma_fence_init, when calling into get_driver_name or get_timeline_name, since both the engine and context might be NULL(or contain some garbage address) in the case of newly allocated slab objects via the request ctor. Note that we also use SLAB_TYPESAFE_BY_RCU here, which allows requests to be immediately freed, but delay freeing the underlying page by an RCU grace period. With this scheme requests can be re-allocated, at the same time as they are also being read by some lockless RCU lookup mechanism. In the ctor case, which is only called for new slab objects(i.e allocate new page and call the ctor for each object) it's safe to reset the context/engine prior to calling into dma_fence_init, since we can be certain that no one is doing an RCU lookup which might depend on peeking at the engine/context, like in active_engine(), since the object can't yet be externally visible. In the recycled case(which might also be externally visible) the request refcount always transitions from 0->1 after we set the context/engine etc, which should ensure it's valid to dereference the engine for example, when doing an RCU list-walk, so long as we can also increment the refcount first. If the refcount is already zero, then the request is considered complete/released. If it's non-zero, then the request might be in the process of being re-allocated, or potentially still in flight, however after successfully incrementing the refcount, it's possible to carefully inspect the request state, to determine if the request is still what we were looking for. Note that all externally visible requests returned to the cache must have zero refcount. One possible fix then is to move dma_fence_init out from the request ctor. Originally this was how it was done, but it was moved in: commit 855e39e65cfc33a73724f1cc644ffc5754864a20 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Mon Feb 3 09:41:48 2020 +0000 drm/i915: Initialise basic fence before acquiring seqno where it looks like intel_timeline_get_seqno() relied on some of the rq->fence state, but that is no longer the case since: commit 12ca695d2c1ed26b2dcbb528b42813bd0f216cfc Author: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Date: Tue Mar 23 16:49:50 2021 +0100 drm/i915: Do not share hwsp across contexts any more, v8. intel_timeline_get_seqno() could also be cleaned up slightly by dropping the request argument. Moving dma_fence_init back out of the ctor, should ensure we have enough of the request initialised in case of trace_dma_fence_init. Functionally this should be the same, and is effectively what we were already open coding before, except now we also assign the fence->lock and fence->ops, but since these are invariant for recycled requests(which might be externally visible), and will therefore already hold the same value, it shouldn't matter. An alternative fix, since we don't yet have a fully initialised request when in the ctor, is just setting the context/engine as NULL, but this does require adding some extra handling in get_driver_name etc. v2(Daniel): - Try to make the commit message less confusing Fixes: 855e39e65cfc ("drm/i915: Initialise basic fence before acquiring seqno") Signed-off-by: Matthew Auld <matthew.auld@intel.com> Cc: Michael Mason <michael.w.mason@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20210921134202.3803151-1-matthew.auld@intel.com (cherry picked from commit be988eaee1cb208c4445db46bc3ceaf75f586f0b) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-10-06drm/amdgpu: correct initial cp_hqd_quantum for gfx9Hawking Zhang1-1/+1
commit 9f52c25f59b504a29dda42d83ac1e24d2af535d4 upstream. didn't read the value of mmCP_HQD_QUANTUM from correct register offset Signed-off-by: Hawking Zhang <Hawking.Zhang@amd.com> Reviewed-by: Le Ma <Le.Ma@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-10-06drm/amd/display: Pass PCI deviceid into DCCharlene Liu1-0/+1
commit d942856865c733ff60450de9691af796ad71d7bc upstream. [why] pci deviceid not passed to dal dc, without proper break, dcn2.x falls into dcn3.x code path [how] pass in pci deviceid, and break once dal_version initialized. Reviewed-by: Zhan Liu <Zhan.Liu@amd.com> Acked-by: Anson Jacob <Anson.Jacob@amd.com> Signed-off-by: Charlene Liu <Charlene.Liu@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-09-30amd/display: downgrade validation failure log levelSimon Ser1-1/+2
[ Upstream commit 7bbee36d71502ab9a341505da89a017c7ae2e6b2 ] In amdgpu_dm_atomic_check, dc_validate_global_state is called. On failure this logs a warning to the kernel journal. However warnings shouldn't be used for atomic test-only commit failures: user-space might be perfoming a lot of atomic test-only commits to find the best hardware configuration. Downgrade the log to a regular DRM atomic message. While at it, use the new device-aware logging infrastructure. This fixes error messages in the kernel when running gamescope [1]. [1]: https://github.com/Plagman/gamescope/issues/245 Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Simon Ser <contact@emersion.fr> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-30treewide: Change list_sort to use const pointersSami Tolvanen5-6/+9
[ Upstream commit 4f0f586bf0c898233d8f316f471a21db2abd522d ] list_sort() internally casts the comparison function passed to it to a different type with constant struct list_head pointers, and uses this pointer to call the functions, which trips indirect call Control-Flow Integrity (CFI) checking. Instead of removing the consts, this change defines the list_cmp_func_t type and changes the comparison function types of all list_sort() callers to use const pointers, thus avoiding type mismatches. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Kees Cook <keescook@chromium.org> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210408182843.1754385-10-samitolvanen@google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-30drm/amd/pm: Update intermediate power state for SILijo Lazar1-0/+2
commit ab39d3cef526ba09c4c6923b4cd7e6ec1c5d4faa upstream. Update the current state as boot state during dpm initialization. During the subsequent initialization, set_power_state gets called to transition to the final power state. set_power_state refers to values from the current state and without current state populated, it could result in NULL pointer dereference. For ex: on platforms where PCI speed change is supported through ACPI ATCS method, the link speed of current state needs to be queried before deciding on changing to final power state's link speed. The logic to query ATCS-support was broken on certain platforms. The issue became visible when broken ATCS-support logic got fixed with commit f9b7f3703ff9 ("drm/amdgpu/acpi: make ATPX/ATCS structures global (v2)"). Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1698 Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@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>
2021-09-26drm/nouveau/nvkm: Replace -ENOSYS with -ENODEVGuenter Roeck1-1/+1
commit e8f71f89236ef82d449991bfbc237e3cb6ea584f upstream. nvkm test builds fail with the following error. drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c: In function 'nvkm_control_mthd_pstate_info': drivers/gpu/drm/nouveau/nvkm/engine/device/ctrl.c:60:35: error: overflow in conversion from 'int' to '__s8' {aka 'signed char'} changes value from '-251' to '5' The code builds on most architectures, but fails on parisc where ENOSYS is defined as 251. Replace the error code with -ENODEV (-19). The actual error code does not really matter and is not passed to userspace - it just has to be negative. Fixes: 7238eca4cf18 ("drm/nouveau: expose pstate selection per-power source in sysfs") Signed-off-by: Guenter Roeck <linux@roeck-us.net> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: David Airlie <airlied@linux.ie> Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-26drm/amdgpu: Disable PCIE_DPM on Intel RKL PlatformKoba Ko1-1/+16
[ Upstream commit b3dc549986eb7b38eba4a144e979dc93f386751f ] Due to high latency in PCIE clock switching on RKL platforms, switching the PCIE clock dynamically at runtime can lead to HDMI/DP audio problems. On newer asics this is handled in the SMU firmware. For SMU7-based asics, disable PCIE clock switching to avoid the issue. AMD provide a parameter to disable PICE_DPM. modprobe amdgpu ppfeaturemask=0xfff7bffb It's better to contorl PCIE_DPM in amd gpu driver, switch PCI_DPM by determining intel RKL platform for SMU7-based asics. Fixes: 1a31474cdb48 ("drm/amd/pm: workaround for audio noise issue") Ref: https://lists.freedesktop.org/archives/amd-gfx/2021-August/067413.html Signed-off-by: Koba Ko <koba.ko@canonical.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-22drm/rockchip: cdn-dp-core: Make cdn_dp_core_resume __maybe_unusedArnd Bergmann1-1/+1
commit 040b8907ccf1c78d020aca29800036565d761d73 upstream. With the new static annotation, the compiler warns when the functions are actually unused: drivers/gpu/drm/rockchip/cdn-dp-core.c:1123:12: error: 'cdn_dp_resume' defined but not used [-Werror=unused-function] 1123 | static int cdn_dp_resume(struct device *dev) | ^~~~~~~~~~~~~ Mark them __maybe_unused to suppress that warning as well. [ Not so 'new' static annotations any more, and I removed the part of the patch that added __maybe_unused to cdn_dp_suspend(), because it's used by the shutdown/remove code. So only the resume function ends up possibly unused if CONFIG_PM isn't set - Linus ] Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make cdn_dp_core_suspend/resume static") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Reviewed-by: Enric Balletbo i Serra <enric.balletbo@collabora.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/etnaviv: add missing MMU context put when reaping MMU mappingLucas Stach1-0/+1
commit f2faea8b64125852fa9acc6771c07fc0311a039b upstream. When we forcefully evict a mapping from the the address space and thus the MMU context, the MMU context is leaked, as the mapping no longer points to it, so it doesn't get freed when the GEM object is destroyed. Add the mssing context put to fix the leak. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Michael Walle <michael@walle.cc> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/etnaviv: reference MMU context when setting up hardware stateLucas Stach3-12/+24
commit d6408538f091fb22d47f792d4efa58143d56c3fb upstream. Move the refcount manipulation of the MMU context to the point where the hardware state is programmed. At that point it is also known if a previous MMU state is still there, or the state needs to be reprogrammed with a potentially different context. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Michael Walle <michael@walle.cc> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/etnaviv: fix MMU context leak on GPU resetLucas Stach1-0/+2
commit f978a5302f5566480c58ffae64a16d34456801bd upstream. After a reset the GPU is no longer using the MMU context and may be restarted with a different context. While the mmu_state proeprly was cleared, the context wasn't unreferenced, leading to a memory leak. Cc: stable@vger.kernel.org # 5.4 Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Michael Walle <michael@walle.cc> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/etnaviv: exec and MMU state is lost when resetting the GPULucas Stach1-3/+2
commit 725cbc7884c37f3b4f1777bc1aea6432cded8ca5 upstream. When the GPU is reset both the current exec state, as well as all MMU state is lost. Move the driver side state tracking into the reset function to keep hardware and software state from diverging. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Michael Walle <michael@walle.cc> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/etnaviv: keep MMU context across runtime suspend/resumeLucas Stach1-3/+3
commit 8f3eea9d01d7b0f95b0fe04187c0059019ada85b upstream. The MMU state may be kept across a runtime suspend/resume cycle, as we avoid a full hardware reset to keep the latency of the runtime PM small. Don't pretend that the MMU state is lost in driver state. The MMU context is pushed out when new HW jobs with a different context are coming in. The only exception to this is when the GPU is unbound, in which case we need to make sure to also free the last active context. Cc: stable@vger.kernel.org # 5.4 Reported-by: Michael Walle <michael@walle.cc> Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Michael Walle <michael@walle.cc> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/etnaviv: stop abusing mmu_context as FE running markerLucas Stach2-2/+9
commit 23e0f5a57d0ecec86e1fc82194acd94aede21a46 upstream. While the DMA frontend can only be active when the MMU context is set, the reverse isn't necessarily true, as the frontend can be stopped while the MMU state is kept. Stop treating mmu_context being set as a indication that the frontend is running and instead add a explicit property. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Michael Walle <michael@walle.cc> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/etnaviv: put submit prev MMU context when it existsLucas Stach1-0/+2
commit cda7532916f7bc860b36a1806cb8352e6f63dacb upstream. The prev context is the MMU context at the time of the job queueing in hardware. As a job might be queued multiple times due to recovery after a GPU hang, we need to make sure to put the stale prev MMU context from a prior queuing, to avoid the reference and thus the MMU context leaking. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Michael Walle <michael@walle.cc> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/etnaviv: return context from etnaviv_iommu_context_getLucas Stach5-11/+8
commit 78edefc05e41352099ffb8f06f8d9b2d091e29cd upstream. Being able to have the refcount manipulation in an assignment makes it much easier to parse the code. Cc: stable@vger.kernel.org # 5.4 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Tested-by: Michael Walle <michael@walle.cc> Tested-by: Marek Vasut <marex@denx.de> Reviewed-by: Christian Gmeiner <christian.gmeiner@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/amd/amdgpu: Increase HWIP_MAX_INSTANCE to 10Ernst Sjöstrand1-1/+1
commit 67a44e659888569a133a8f858c8230e9d7aad1d5 upstream. Seems like newer cards can have even more instances now. Found by UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:318:29 index 8 is out of range for type 'uint32_t *[8]' Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1697 Cc: stable@vger.kernel.org Signed-off-by: Ernst Sjöstrand <ernstp@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-22drm/bridge: lt9611: Fix handling of 4k panelsRobert Foss1-1/+7
commit d1a97648ae028a44536927c87837c45ada7141c9 upstream. 4k requires two dsi pipes, so don't report MODE_OK when only a single pipe is configured. But rather report MODE_PANEL to signal that requirements of the panel are not being met. Reported-by: Peter Collingbourne <pcc@google.com> Suggested-by: Peter Collingbourne <pcc@google.com> Signed-off-by: Robert Foss <robert.foss@linaro.org> Tested-by: John Stultz <john.stultz@linaro.org> Tested-by: Anibal Limon <anibal.limon@linaro.org> Tested-by: Peter Collingbourne <pcc@google.com> Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org> Acked-by: Vinod Koul <vkoul@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20201217140933.1133969-1-robert.foss@linaro.org Cc: Peter Collingbourne <pcc@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/panfrost: Clamp lock region to Bifrost minimumAlyssa Rosenzweig2-1/+3
commit bd7ffbc3ca12629aeb66fb9e28cf42b7f37e3e3b upstream. When locking a region, we currently clamp to a PAGE_SIZE as the minimum lock region. While this is valid for Midgard, it is invalid for Bifrost, where the minimum locking size is 8x larger than the 4k page size. Add a hardware definition for the minimum lock region size (corresponding to KBASE_LOCK_REGION_MIN_SIZE_LOG2 in kbase) and respect it. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Tested-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-4-alyssa.rosenzweig@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/panfrost: Use u64 for size in lock_regionAlyssa Rosenzweig1-6/+6
commit a77b58825d7221d4a45c47881c35a47ba003aa73 upstream. Mali virtual addresses are 48-bit. Use a u64 instead of size_t to ensure we can express the "lock everything" condition as ~0ULL without overflow. This code was silently broken on any platform where a size_t is less than 48-bits; in particular, it was broken on 32-bit armv7 platforms which remain in use with panfrost. (Mainly RK3288) Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Suggested-by: Rob Herring <robh@kernel.org> Tested-by: Chris Morgan <macromorgan@hotmail.com> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: <stable@vger.kernel.org> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-3-alyssa.rosenzweig@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/panfrost: Simplify lock_region calculationAlyssa Rosenzweig1-14/+5
commit b5fab345654c603c07525100d744498f28786929 upstream. In lock_region, simplify the calculation of the region_width parameter. This field is the size, but encoded as ceil(log2(size)) - 1. ceil(log2(size)) may be computed directly as fls(size - 1). However, we want to use the 64-bit versions as the amount to lock can exceed 32-bits. This avoids undefined (and completely wrong) behaviour when locking all memory (size ~0). In this case, the old code would "round up" ~0 to the nearest page, overflowing to 0. Since fls(0) == 0, this would calculate a region width of 10 + 0 = 10. But then the code would shift by (region_width - 11) = -1. As shifting by a negative number is undefined, UBSAN flags the bug. Of course, even if it were defined the behaviour is wrong, instead of locking all memory almost none would get locked. The new form of the calculation corrects this special case and avoids the undefined behaviour. Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com> Reported-and-tested-by: Chris Morgan <macromorgan@hotmail.com> Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Cc: <stable@vger.kernel.org> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Rob Herring <robh@kernel.org> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210824173028.7528-2-alyssa.rosenzweig@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/amd/display: Update bounding box states (v2)Jerry (Fangzhi) Zuo1-10/+31
commit a7a9d11e12fcc32160d55e8612e72e5ab51b15dc upstream. [Why] Drop hardcoded dispclk, dppclk, phyclk [How] Read the corresponding values from clock table entries already populated. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1403 Cc: stable@vger.kernel.org Signed-off-by: Jerry (Fangzhi) Zuo <Jerry.Zuo@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/amd/display: Update number of DCN3 clock statesAurabindo Pillai1-0/+1
commit 0bbf06d888734041e813b916d7821acd4f72005a upstream. [Why & How] The DCN3 SoC parameter num_states was calculated but not saved into the object. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1403 Cc: stable@vger.kernel.org Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/amdgpu: Fix BUG_ON assertAndrey Grodzovsky1-1/+1
commit ea7acd7c5967542353430947f3faf699e70602e5 upstream. With added CPU domain to placement you can have now 3 placemnts at once. CC: stable@kernel.org Signed-off-by: Andrey Grodzovsky <andrey.grodzovsky@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210622162339.761651-5-andrey.grodzovsky@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/panfrost: Make sure MMU context lifetime is not bound to panfrost_privBoris Brezillon6-111/+136
commit 7fdc48cc63a30fa3480d18bdd8c5fff2b9b15212 upstream. Jobs can be in-flight when the file descriptor is closed (either because the process did not terminate properly, or because it didn't wait for all GPU jobs to be finished), and apparently panfrost_job_close() does not cancel already running jobs. Let's refcount the MMU context object so it's lifetime is no longer bound to the FD lifetime and running jobs can finish properly without generating spurious page faults. Reported-by: Icecream95 <ixn@keemail.me> Fixes: 7282f7645d06 ("drm/panfrost: Implement per FD address spaces") Cc: <stable@vger.kernel.org> Signed-off-by: Boris Brezillon <boris.brezillon@collabora.com> Reviewed-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210621133907.1683899-2-boris.brezillon@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/dp_mst: Fix return code on sideband message failureRajkumar Subbiah1-4/+6
commit 92bd92c44d0d9be5dcbcda315b4be4b909ed9740 upstream. Commit 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") added some debug code for sideband message tracing. But it seems to have unintentionally changed the behavior on sideband message failure. It catches and returns failure only if DRM_UT_DP is enabled. Otherwise it ignores the error code and returns success. So on an MST unplug, the caller is unaware that the clear payload message failed and ends up waiting for 4 seconds for the response. Fixes the issue by returning the proper error code. Changes in V2: -- Revise commit text as review comment -- add Fixes text Changes in V3: -- remove "unlikely" optimization Fixes: 2f015ec6eab6 ("drm/dp_mst: Add sideband down request tracing + selftests") Cc: <stable@vger.kernel.org> # v5.5+ Signed-off-by: Rajkumar Subbiah <rsubbia@codeaurora.org> Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/1625585434-9562-1-git-send-email-khsieh@codeaurora.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/msi/mdp4: populate priv->kms in mdp4_kms_initDavid Heidelberg1-1/+3
commit cb0927ab80d224c9074f53d1a55b087d12ec5a85 upstream. Without this fix boot throws NULL ptr exception at msm_dsi_manager_setup_encoder on devices like Nexus 7 2013 (MDP4 v4.4). Fixes: 03436e3ec69c ("drm/msm/dsi: Move setup_encoder to modeset_init") Cc: <stable@vger.kernel.org> Signed-off-by: David Heidelberg <david@ixit.cz> Link: https://lore.kernel.org/r/20210811170631.39296-1-david@ixit.cz Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/mgag200: Select clock in PLL update functionsThomas Zimmermann3-12/+33
commit 147696720eca12ae48d020726208b9a61cdd80bc upstream. Put the clock-selection code into each of the PLL-update functions to make them select the correct pixel clock. Instead of copying the code, introduce a new helper WREG_MISC_MASKED, which does masked writes into <MISC>. Use it from each individual PLL update function. The pixel clock for video output was not actually set before programming the clock's values. It worked because the device had the correct clock pre-set. v2: * don't duplicate <MISC> update code (Sam) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: db05f8d3dc87 ("drm/mgag200: Split MISC register update into PLL selection, SYNC and I/O") Acked-by: Sam Ravnborg <sam@ravnborg.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Emil Velikov <emil.velikov@collabora.com> Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v5.9+ Link: https://patchwork.freedesktop.org/patch/msgid/20210714142240.21979-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-09-18drm/amdkfd: Account for SH/SE count when setting up cu masks.Sean Keely2-21/+64
[ Upstream commit 1ec06c2dee679e9f089e78ed20cb74ee90155f61 ] On systems with multiple SH per SE compute_static_thread_mgmt_se# is split into independent masks, one for each SH, in the upper and lower 16 bits. We need to detect this and apply cu masking to each SH. The cu mask bits are assigned first to each SE, then to alternate SHs, then finally to higher CU id. This ensures that the maximum number of SPIs are engaged as early as possible while balancing CU assignment to each SH. v2: Use max SH/SE rather than max SH in cu_per_sh. v3: Fix comment blocks, ensure se_mask is initially zero filled, and correctly assign se.sh.cu positions to unset bits in cu_mask. Signed-off-by: Sean Keely <Sean.Keely@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18drm/exynos: Always initialize mapping in exynos_drm_register_dma()Nathan Chancellor1-0/+2
[ Upstream commit c626f3864bbbb28bbe06476b0b497c1330aa4463 ] In certain randconfigs, clang warns: drivers/gpu/drm/exynos/exynos_drm_dma.c:121:19: warning: variable 'mapping' is uninitialized when used here [-Wuninitialized] priv->mapping = mapping; ^~~~~~~ drivers/gpu/drm/exynos/exynos_drm_dma.c:111:16: note: initialize the variable 'mapping' to silence this warning void *mapping; ^ = NULL 1 warning generated. This occurs when CONFIG_EXYNOS_IOMMU is enabled and both CONFIG_ARM_DMA_USE_IOMMU and CONFIG_IOMMU_DMA are disabled, which makes the code look like void *mapping; if (0) mapping = arm_iommu_create_mapping() else if (0) mapping = iommu_get_domain_for_dev() ... priv->mapping = mapping; Add an else branch that initializes mapping to the -ENODEV error pointer so that there is no more warning and the driver does not change during runtime. Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18drm/display: fix possible null-pointer dereference in dcn10_set_clock()Tuo Li1-6/+5
[ Upstream commit 554594567b1fa3da74f88ec7b2dc83d000c58e98 ] The variable dc->clk_mgr is checked in: if (dc->clk_mgr && dc->clk_mgr->funcs->get_clock) This indicates dc->clk_mgr can be NULL. However, it is dereferenced in: if (!dc->clk_mgr->funcs->get_clock) To fix this null-pointer dereference, check dc->clk_mgr and the function pointer dc->clk_mgr->funcs->get_clock earlier, and return if one of them is NULL. Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Tuo Li <islituo@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18gpu: drm: amd: amdgpu: amdgpu_i2c: fix possible uninitialized-variable ↵Tuo Li1-1/+1
access in amdgpu_i2c_router_select_ddc_port() [ Upstream commit a211260c34cfadc6068fece8c9e99e0fe1e2a2b6 ] The variable val is declared without initialization, and its address is passed to amdgpu_i2c_get_byte(). In this function, the value of val is accessed in: DRM_DEBUG("i2c 0x%02x 0x%02x read failed\n", addr, *val); Also, when amdgpu_i2c_get_byte() returns, val may remain uninitialized, but it is accessed in: val &= ~amdgpu_connector->router.ddc_mux_control_pin; To fix this possible uninitialized-variable access, initialize val to 0 in amdgpu_i2c_router_select_ddc_port(). Reported-by: TOTE Robot <oslab@tsinghua.edu.cn> Signed-off-by: Tuo Li <islituo@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18drm/msm/dp: return correct edid checksum after corrupted edid checksum readKuogee Hsieh1-2/+7
[ Upstream commit 7948fe12d47a946fb8025a0534c900e3dd4b5839 ] Response with correct edid checksum saved at connector after corrupted edid checksum read. This fixes Link Layer CTS cases 4.2.2.3, 4.2.2.6. Signed-off-by: Kuogee Hsieh <khsieh@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Link: https://lore.kernel.org/r/1628196295-7382-6-git-send-email-khsieh@codeaurora.org Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18drm/vmwgfx: fix potential UAF in vmwgfx_surface.cDesmond Cheong Zhi Xi1-2/+2
[ Upstream commit 2bc5da528dd570c5ecabc107e6fbdbc55974276f ] drm_file.master should be protected by either drm_device.master_mutex or drm_file.master_lookup_lock when being dereferenced. However, drm_master_get is called on unprotected file_priv->master pointers in vmw_surface_define_ioctl and vmw_gb_surface_define_internal. This is fixed by replacing drm_master_get with drm_file_get_master. Signed-off-by: Desmond Cheong Zhi Xi <desmondcheongzx@gmail.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Zack Rusin <zackr@vmware.com> Signed-off-by: Zack Rusin <zackr@vmware.com> Link: https://patchwork.freedesktop.org/patch/msgid/20210724111824.59266-4-desmondcheongzx@gmail.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2021-09-18drm/amd/display: fix incorrect CM/TF programming sequence in dwbRoy Chan1-26/+64
[ Upstream commit 781e1e23131cce56fb557e6ec2260480a6bd08cc ] [How] the programming sequeune