summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)Author
2024-08-14drm/amd/display: Add delay to improve LTTPR UHBR interopMichael Strauss
[ Upstream commit 10839ee6a977ed1f7d0f4deb29f2d7e5d1f2a9dd ] [WHY] Avoid race condition which puts LTTPR into bad state during UHBR LT. [HOW] Delay 30ms between starting UHBR TPS1 PHY output and sending TPS1 via DPCD. Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Michael Strauss <michael.strauss@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>
2024-08-11drm/i915: Fix possible int overflow in skl_ddi_calculate_wrpll()Nikita Zhandarovich
commit 5b511572660190db1dc8ba412efd0be0d3781ab6 upstream. On the off chance that clock value ends up being too high (by means of skl_ddi_calculate_wrpll() having been called with big enough value of crtc_state->port_clock * 1000), one possible consequence may be that the result will not be able to fit into signed int. Fix this issue by moving conversion of clock parameter from kHz to Hz into the body of skl_ddi_calculate_wrpll(), as well as casting the same parameter to u64 type while calculating the value for AFE clock. This both mitigates the overflow problem and avoids possible erroneous integer promotion mishaps. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: 82d354370189 ("drm/i915/skl: Implementation of SKL DPLL programming") Cc: stable@vger.kernel.org Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240729174035.25727-1-n.zhandarovich@fintech.ru (cherry picked from commit 833cf12846aa19adf9b76bc79c40747726f3c0c1) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-11drm/virtio: Fix type of dma-fence context variableDmitry Osipenko
commit 445d336cd15860f1efb441e6d694f829fbf679eb upstream. Type of DMA fence context is u64. Fence-waiting code uses u32 for the context variable, fix it. Fixes: e4812ab8e6b1 ("drm/virtio: Refactor and optimize job submission code path") Cc: <stable@vger.kernel.org> # v6.4+ Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Reviewed-by: Rob Clark <robdclark@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240714205009.3408298-1-dmitry.osipenko@collabora.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-11drm/vmwgfx: Fix a deadlock in dma buf fence pollingZack Rusin
commit e58337100721f3cc0c7424a18730e4f39844934f upstream. Introduce a version of the fence ops that on release doesn't remove the fence from the pending list, and thus doesn't require a lock to fix poll->fence wait->fence unref deadlocks. vmwgfx overwrites the wait callback to iterate over the list of all fences and update their status, to do that it holds a lock to prevent the list modifcations from other threads. The fence destroy callback both deletes the fence and removes it from the list of pending fences, for which it holds a lock. dma buf polling cb unrefs a fence after it's been signaled: so the poll calls the wait, which signals the fences, which are being destroyed. The destruction tries to acquire the lock on the pending fences list which it can never get because it's held by the wait from which it was called. Old bug, but not a lot of userspace apps were using dma-buf polling interfaces. Fix those, in particular this fixes KDE stalls/deadlock. Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Fixes: 2298e804e96e ("drm/vmwgfx: rework to new fence interface, v2") Cc: Broadcom internal kernel review list <bcm-kernel-feedback-list@broadcom.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v6.2+ Reviewed-by: Maaz Mombasawala <maaz.mombasawala@broadcom.com> Reviewed-by: Martin Krastev <martin.krastev@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240722184313.181318-2-zack.rusin@broadcom.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-11drm/i915/hdcp: Fix HDCP2_STREAM_STATUS macroSuraj Kandpal
[ Upstream commit 555069117390a5d581863bc797fb546bb4417c31 ] Fix HDCP2_STREAM_STATUS macro, it called pipe instead of port never threw a compile error as no one used it. --v2 -Add Fixes [Jani] Fixes: d631b984cc90 ("drm/i915/hdcp: Add HDCP 2.2 stream register") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240730035505.3759899-1-suraj.kandpal@intel.com (cherry picked from commit 73d7cd542bbd0a7c6881ea0df5255f190a1e7236) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-11i915/perf: Remove code to update PWR_CLK_STATE for gen12Umesh Nerlige Ramappa
[ Upstream commit 4bc14b9cfaa2149d41baef2f2620e9f82d9847d7 ] PWR_CLK_STATE only needs to be modified up until gen11. For gen12 this code is not applicable. Remove code to update context image with PWR_CLK_STATE for gen12. Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Ashutosh Dixit <ashutosh.dixit@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240629005643.3050678-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit 7b5bdae7740eb6a3d09f9cd4e4b07362a15b86b3) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-11drm/vmwgfx: Trigger a modeset when the screen movesIan Forbes
[ Upstream commit 75c3e8a26a35d4f3eee299b3cc7e465f166f4e2d ] When multi-monitor is cycled the X,Y position of the Screen Target will likely change but the resolution will not. We need to trigger a modeset when this occurs in order to recreate the Screen Target with the correct X,Y position. Fixes a bug where multiple displays are shown in a single scrollable host window rather than in 2+ windows on separate host displays. Fixes: 426826933109 ("drm/vmwgfx: Filter modes which exceed graphics memory") Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240624205951.23343-1-ian.forbes@broadcom.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-11drm/vmwgfx: Fix overlay when using Screen TargetsIan Forbes
[ Upstream commit cb372a505a994cb39aa75acfb8b3bcf94787cf94 ] This code was never updated to support Screen Targets. Fixes a bug where Xv playback displays a green screen instead of actual video contents when 3D acceleration is disabled in the guest. Fixes: c8261a961ece ("vmwgfx: Major KMS refactoring / cleanup in preparation of screen targets") Reported-by: Doug Brown <doug@schmorgal.com> Closes: https://lore.kernel.org/all/bd9cb3c7-90e8-435d-bc28-0e38fee58977@schmorgal.com Signed-off-by: Ian Forbes <ian.forbes@broadcom.com> Tested-by: Doug Brown <doug@schmorgal.com> Signed-off-by: Zack Rusin <zack.rusin@broadcom.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240719163627.20888-1-ian.forbes@broadcom.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-11drm/nouveau: prime: fix refcount underflowDanilo Krummrich
[ Upstream commit a9bf3efc33f1fbf88787a277f7349459283c9b95 ] Calling nouveau_bo_ref() on a nouveau_bo without initializing it (and hence the backing ttm_bo) leads to a refcount underflow. Instead of calling nouveau_bo_ref() in the unwind path of drm_gem_object_init(), clean things up manually. Fixes: ab9ccb96a6e6 ("drm/nouveau: use prime helpers") Reviewed-by: Ben Skeggs <bskeggs@nvidia.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240718165959.3983-2-dakr@kernel.org (cherry picked from commit 1b93f3e89d03cfc576636e195466a0d728ad8de5) Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/panfrost: Mark simple_ondemand governor as softdepDragan Simic
commit 80f4e62730a91572b7fdc657f7bb747e107ae308 upstream. Panfrost DRM driver uses devfreq to perform DVFS, while using simple_ondemand devfreq governor by default. This causes driver initialization to fail on boot when simple_ondemand governor isn't built into the kernel statically, as a result of the missing module dependency and, consequently, the required governor module not being included in the initial ramdisk. Thus, let's mark simple_ondemand governor as a softdep for Panfrost, to have its kernel module included in the initial ramdisk. This is a rather longstanding issue that has forced distributions to build devfreq governors statically into their kernels, [1][2] or has forced users to introduce some unnecessary workarounds. [3] For future reference, not having support for the simple_ondemand governor in the initial ramdisk produces errors in the kernel log similar to these below, which were taken from a Pine64 RockPro64: panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init [panfrost]] *ERROR* Couldn't initialize GPU devfreq panfrost ff9a0000.gpu: Fatal error during GPU init panfrost: probe of ff9a0000.gpu failed with error -22 Having simple_ondemand marked as a softdep for Panfrost may not resolve this issue for all Linux distributions. In particular, it will remain unresolved for the distributions whose utilities for the initial ramdisk generation do not handle the available softdep information [4] properly yet. However, some Linux distributions already handle softdeps properly while generating their initial ramdisks, [5] and this is a prerequisite step in the right direction for the distributions that don't handle them properly yet. [1] https://gitlab.manjaro.org/manjaro-arm/packages/core/linux/-/blob/linux61/config?ref_type=heads#L8180 [2] https://salsa.debian.org/kernel-team/linux/-/merge_requests/1066 [3] https://forum.pine64.org/showthread.php?tid=15458 [4] https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/commit/?id=49d8e0b59052999de577ab732b719cfbeb89504d [5] https://github.com/archlinux/mkinitcpio/commit/97ac4d37aae084a050be512f6d8f4489054668ad Cc: Diederik de Haas <didi.debian@cknow.org> Cc: Furkan Kardame <f.kardame@manjaro.org> Cc: stable@vger.kernel.org Fixes: f3ba91228e8e ("drm/panfrost: Add initial panfrost driver") Signed-off-by: Dragan Simic <dsimic@manjaro.org> Reviewed-by: Steven Price <steven.price@arm.com> Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Steven Price <steven.price@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/4e1e00422a14db4e2a80870afb704405da16fd1b.1718655077.git.dsimic@manjaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/etnaviv: don't block scheduler when GPU is still activeLucas Stach
commit 704d3d60fec451f37706368d9d3e320322978986 upstream. Since 45ecaea73883 ("drm/sched: Partial revert of 'drm/sched: Keep s_fence->parent pointer'") still active jobs aren't put back in the pending list on drm_sched_start(), as they don't have a active parent fence anymore, so if the GPU is still working and the timeout is extended, all currently active jobs will be freed. To avoid prematurely freeing jobs that are still active on the GPU, don't block the scheduler until we are fully committed to actually reset the GPU. As the current job is already removed from the pending list and will not be put back when drm_sched_start() isn't called, we must make sure to put the job back on the pending list when extending the timeout. Cc: stable@vger.kernel.org #6.0 Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/i915/dp: Don't switch the LTTPR mode on an active linkImre Deak
commit 509580fad7323b6a5da27e8365cd488f3b57210e upstream. Switching to transparent mode leads to a loss of link synchronization, so prevent doing this on an active link. This happened at least on an Intel N100 system / DELL UD22 dock, the LTTPR residing either on the host or the dock. To fix the issue, keep the current mode on an active link, adjusting the LTTPR count accordingly (resetting it to 0 in transparent mode). v2: Adjust code comment during link training about reiniting the LTTPRs. (Ville) Fixes: 7b2a4ab8b0ef ("drm/i915: Switch to LTTPR transparent mode link training") Reported-and-tested-by: Gareth Yu <gareth.yu@intel.com> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/10902 Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240708190029.271247-3-imre.deak@intel.com (cherry picked from commit 211ad49cf8ccfdc798a719b4d1e000d0a8a9e588) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/i915/dp: Reset intel_dp->link_trained before retraining the linkImre Deak
commit d13e2a6e95e6b87f571c837c71a3d05691def9bb upstream. Regularly retraining a link during an atomic commit happens with the given pipe/link already disabled and hence intel_dp->link_trained being false. Ensure this also for retraining a DP SST link via direct calls to the link training functions (vs. an actual commit as for DP MST). So far nothing depended on this, however the next patch will depend on link_trained==false for changing the LTTPR mode to non-transparent. Cc: <stable@vger.kernel.org> # v5.15+ Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240708190029.271247-2-imre.deak@intel.com (cherry picked from commit a4d5ce61765c08ab364aa4b327f6739b646e6cfa) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/amd/amdgpu: Fix uninitialized variable warningsMa Ke
commit df65aabef3c0327c23b840ab5520150df4db6b5f upstream. Return 0 to avoid returning an uninitialized variable r. Cc: stable@vger.kernel.org Fixes: 230dd6bb6117 ("drm/amd/amdgpu: implement mode2 reset on smu_v13_0_10") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 6472de66c0aa18d50a4b5ca85f8272e88a737676) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/amdgpu: reset vm state machine after gpu reset(vram lost)ZhenGuo Yin
commit 5659b0c93a1ea02c662a030b322093203f299185 upstream. [Why] Page table of compute VM in the VRAM will lost after gpu reset. VRAM won't be restored since compute VM has no shadows. [How] Use higher 32-bit of vm->generation to record a vram_lost_counter. Reset the VM state machine when vm->genertaion is not equal to the new generation token. v2: Check vm->generation instead of calling drm_sched_entity_error in amdgpu_vm_validate. v3: Use new generation token instead of vram_lost_counter for check. Signed-off-by: ZhenGuo Yin <zhenguo.yin@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org (cherry picked from commit 47c0388b0589cb481c294dcb857d25a214c46eb3) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/dp_mst: Fix all mstb marked as not probed after suspend/resumeWayne Lin
commit d63d81094d208abb20fc444514b2d9ec2f4b7c4e upstream. [Why] After supend/resume, with topology unchanged, observe that link_address_sent of all mstb are marked as false even the topology probing is done without any error. It is caused by wrongly also include "ret == 0" case as a probing failure case. [How] Remove inappropriate checking conditions. Cc: Lyude Paul <lyude@redhat.com> Cc: Harry Wentland <hwentlan@amd.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Daniel Vetter <daniel@ffwll.ch> Cc: stable@vger.kernel.org Fixes: 37dfdc55ffeb ("drm/dp_mst: Cleanup drm_dp_send_link_address() a bit") Signed-off-by: Wayne Lin <Wayne.Lin@amd.com> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240626084825.878565-2-Wayne.Lin@amd.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/udl: Remove DRM_CONNECTOR_POLL_HPDThomas Zimmermann
commit 5aed213c7c6c4f5dcb1a3ef146f493f18fe703dc upstream. DisplayLink devices do not generate hotplug events. Remove the poll flag DRM_CONNECTOR_POLL_HPD, as it may not be specified together with DRM_CONNECTOR_POLL_CONNECT or DRM_CONNECTOR_POLL_DISCONNECT. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: afdfc4c6f55f ("drm/udl: Fixed problem with UDL adpater reconnection") Reviewed-by: Jani Nikula <jani.nikula@intel.com> Cc: Robert Tarasov <tutankhamen@chromium.org> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Dave Airlie <airlied@redhat.com> Cc: Sean Paul <sean@poorly.run> Cc: Thomas Zimmermann <tzimmermann@suse.de> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v4.15+ Link: https://patchwork.freedesktop.org/patch/msgid/20240510154841.11370-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/amdgpu/sdma5.2: Update wptr registers as well as doorbellAlex Deucher
commit a03ebf116303e5d13ba9a2b65726b106cb1e96f6 upstream. We seem to have a case where SDMA will sometimes miss a doorbell if GFX is entering the powergating state when the doorbell comes in. To workaround this, we can update the wptr via MMIO, however, this is only safe because we disallow gfxoff in begin_ring() for SDMA 5.2 and then allow it again in end_ring(). Enable this workaround while we are root causing the issue with the HW team. Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/3440 Tested-by: Friedrich Vock <friedrich.vock@gmx.de> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org (cherry picked from commit f2ac52634963fc38e4935e11077b6f7854e5d700) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/i915/gt: Do not consider preemption during execlists_dequeue for gen8Nitin Gote
commit 65564157ae64cec0f527583f96e32f484f730f92 upstream. We're seeing a GPU hang issue on a CHV platform, which was caused by commit bac24f59f454 ("drm/i915/execlists: Enable coarse preemption boundaries for Gen8"). The Gen8 platform only supports timeslicing and doesn't have a preemption mechanism, as its engines do not have a preemption timer. Commit 751f82b353a6 ("drm/i915/gt: Only disable preemption on Gen8 render engines") addressed this issue only for render engines. This patch extends that fix by ensuring that preemption is not considered for all engines on Gen8 platforms. v4: - Use the correct Fixes tag (Rodrigo Vivi) - Reworded commit log (Andi Shyti) v3: - Inside need_preempt(), condition of can_preempt() is not required as simplified can_preempt() is enough. (Chris Wilson) v2: Simplify can_preempt() function (Tvrtko Ursulin) Fixes: 751f82b353a6 ("drm/i915/gt: Only disable preemption on gen8 render engines") Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11396 Suggested-by: Andi Shyti <andi.shyti@intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Cc: Chris Wilson <chris.p.wilson@linux.intel.com> CC: <stable@vger.kernel.org> # v5.12+ Reviewed-by: Jonathan Cavitt <jonathan.cavitt@intel.com> Reviewed-by: Andi Shyti <andi.shyti@linux.intel.com> Signed-off-by: Andi Shyti <andi.shyti@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240711163208.1355736-1-nitin.r.gote@intel.com (cherry picked from commit 7df0be6e6280c6fca01d039864bb123e5e36604b) Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/amd/display: Check for NULL pointerSung Joon Kim
commit 4ab68e168ae1695f7c04fae98930740aaf7c50fa upstream. [why & how] Need to make sure plane_state is initialized before accessing its members. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Xi (Alex) Liu <xi.liu@amd.com> Signed-off-by: Sung Joon Kim <sungjoon.kim@amd.com> Signed-off-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 295d91cbc700651782a60572f83c24861607b648) Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modesMa Ke
commit 2df7aac81070987b0f052985856aa325a38debf6 upstream. In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a possible NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable@vger.kernel.org Fixes: 89c78134cc54 ("gma500: Add Poulsbo support") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240709092011.3204970-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modesMa Ke
commit cb520c3f366c77e8d69e4e2e2781a8ce48d98e79 upstream. In cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is assigned to mode, which will lead to a NULL pointer dereference on failure of drm_mode_duplicate(). Add a check to avoid npd. Cc: stable@vger.kernel.org Fixes: 6a227d5fd6c4 ("gma500: Add support for Cedarview") Signed-off-by: Ma Ke <make24@iscas.ac.cn> Signed-off-by: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240709113311.37168-1-make24@iscas.ac.cn Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2024-08-03drm/mediatek/dp: Fix spurious kfree()Michael Walle
[ Upstream commit 8ad49a92cff4bab13eb2f2725243f5f31eff3f3b ] drm_edid_to_sad() might return an error or just zero. If that is the case, we must not free the SADs because there was no allocation in the first place. Fixes: dab12fa8d2bd ("drm/mediatek/dp: fix memory leak on ->get_edid callback audio detection") Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.kernel.org/project/linux-mediatek/patch/20240604083337.1879188-1-mwalle@kernel.org/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/mediatek/dp: switch to ->edid_read callbackJani Nikula
[ Upstream commit 0c13bd9bf444b0dfb2e9ea0d26915f310cc8ad6a ] Prefer using the struct drm_edid based callback and functions. Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/3d783478e25e71f12f66c2caedb1f9205d4d8a44.1706038510.git.jani.nikula@intel.com Stable-dep-of: 8ad49a92cff4 ("drm/mediatek/dp: Fix spurious kfree()") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/mediatek: Remove less-than-zero comparison of an unsigned valueHsiao Chien Sung
[ Upstream commit 4ed9dd7fde22ed614384c03f8049723cbe7e6a58 ] Fix a Coverity error that less-than-zero comparison of an unsigned value is never true. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240614034937.23978-1-shawn.sung@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/qxl: Add check for drm_cvt_modeChen Ni
[ Upstream commit 7bd09a2db0f617377027a2bb0b9179e6959edff3 ] Add check for the return value of drm_cvt_mode() and return the error if it fails in order to avoid NULL pointer dereference. Fixes: 1b043677d4be ("drm/qxl: add qxl_add_mode helper function") Signed-off-by: Chen Ni <nichen@iscas.ac.cn> Reviewed-by: Heng Qi <hengqi@linux.alibaba.com> Signed-off-by: Maxime Ripard <mripard@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240621071031.1987974-1-nichen@iscas.ac.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/etnaviv: fix DMA direction handling for cached RW buffersLucas Stach
[ Upstream commit 58979ad6330a70450ed78837be3095107d022ea9 ] The dma sync operation needs to be done with DMA_BIDIRECTIONAL when the BO is prepared for both read and write operations. Fixes: a8c21a5451d8 ("drm/etnaviv: add initial etnaviv DRM driver") Signed-off-by: Lucas Stach <l.stach@pengutronix.de> Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de> Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/msm/dpu: drop validity checks for clear_pending_flush() ctl opAbhinav Kumar
[ Upstream commit 3d68e3dedd4b48f0358bdc187277e3315d8aa559 ] clear_pending_flush() ctl op is always assigned irrespective of the DPU hardware revision. Hence there is no needed to check whether the op has been assigned before calling it. Drop the checks across the driver for clear_pending_flush() and also update its documentation that it is always expected to be assigned. changes in v2: - instead of adding more validity checks just drop the one for clear_pending_flush - update the documentation for clear_pending_flush() ctl op - update the commit text reflecting these changes changes in v3: - simplify the documentation of clear_pending_flush Fixes: d7d0e73f7de3 ("drm/msm/dpu: introduce the dpu_encoder_phys_* for writeback") Reported-by: Dan Carpenter <dan.carpenter@linaro.org> Closes: https://lore.kernel.org/all/464fbd84-0d1c-43c3-a40b-31656ac06456@moroto.mountain/T/ Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/600241/ Link: https://lore.kernel.org/r/20240620201731.3694593-1-quic_abhinavk@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/msm/dsi: set VIDEO_COMPRESSION_MODE_CTRL_WCJonathan Marek
[ Upstream commit 9ecd0ddd223b68b4603e4766a1d51f6c6cda346e ] Video mode DSC won't work if this field is not set correctly. Set it to fix video mode DSC (for slice_per_pkt==1 cases at least). Fixes: 08802f515c3c ("drm/msm/dsi: Add support for DSC configuration") Signed-off-by: Jonathan Marek <jonathan@marek.ca> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Jun Nie <jun.nie@linaro.org> Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8550-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-QRD Tested-by: Neil Armstrong <neil.armstrong@linaro.org> # on SM8650-HDK Reviewed-by: Jessica Zhang <quic_jesszhan@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/596234/ Link: https://lore.kernel.org/r/20240530-msm-drm-dsc-dsi-video-upstream-4-v6-5-2ab1d334c657@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/mediatek: Add OVL compatible name for MT8195Hsiao Chien Sung
[ Upstream commit 6fb7a0985fd16868b5d72eb3e3de7524a6000e6e ] Add OVL compatible name for MT8195. Without this commit, DRM won't work after modifying the device tree. Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-7-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/mediatek: Turn off the layers with zero width or heightHsiao Chien Sung
[ Upstream commit 6b9946f4550d8dad8bc1af2db97286ca449af786 ] We found that IGT (Intel GPU Tool) will try to commit layers with zero width or height and lead to undefined behaviors in hardware. Disable the layers in such a situation. Fixes: 453c3364632a ("drm/mediatek: Add ovl_adaptor support for MT8195") Fixes: d886c0009bd0 ("drm/mediatek: Add ETHDR support for MT8195") Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-6-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/mediatek: Fix destination alpha error in OVLHsiao Chien Sung
[ Upstream commit 31c0fbf67c8c0bb38d7fb21d404ea3dbd619d99e ] The formula of Coverage alpha blending is: dst.a = dst.a * (0xff - src.a * SCA / 0xff) / 0xff + src.a * SCA / 0xff dst.a: destination alpha src.a: pixel alpha SCA : plane alpha When SCA = 0xff, the formula becomes: dst.a = dst.a * (0xff - src.a) + src.a This patch is to set the destination alpha (background) to 0xff: - When dst.a = 0 (before), dst.a = src.a - When dst.a = 0xff (after) , dst.a = 0xff * (0xff - src.a) + src.a According to the fomula above: - When src.a = 0 , dst.a = 0 - When src.a = 0xff, dst.a = 0xff This two cases are just still correct. But when src.a is between 0 and 0xff, the difference starts to appear Fixes: 616443ca577e ("drm/mediatek: Move cmdq_reg info from struct mtk_ddp_comp to sub driver private data") Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-5-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/mediatek: Fix XRGB setting error in MixerHsiao Chien Sung
[ Upstream commit 8e418bee401b7cfd0bc40d187afea2c6b08b44ec ] Although the alpha channel in XRGB formats can be ignored, ALPHA_CON must be configured accordingly when using XRGB formats or it will still affects CRC generation. Fixes: d886c0009bd0 ("drm/mediatek: Add ETHDR support for MT8195") Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-4-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/mediatek: Fix XRGB setting error in OVLHsiao Chien Sung
[ Upstream commit 765f284f1fe172573021056f7e337ee53f252969 ] CONST_BLD must be enabled for XRGB formats although the alpha channel can be ignored, or OVL will still read the value from memory. This error only affects CRC generation. Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-3-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/mediatek: Use 8-bit alpha in ETHDRHsiao Chien Sung
[ Upstream commit 231c020141cb150a59f5b28379cad82ff7bad899 ] 9-bit alpha (max=0x100) is designed for special HDR related calculation, which should be disabled by default. Change the alpha value from 0x100 to 0xff in 8-bit form. Fixes: d886c0009bd0 ("drm/mediatek: Add ETHDR support for MT8195") Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-2-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/mediatek: Add missing plane settings when async updateHsiao Chien Sung
[ Upstream commit 86b89dc669c400576dc23aa923bcf302f99e8e3a ] Fix an issue that plane coordinate was not saved when calling async update. Fixes: 920fffcc8912 ("drm/mediatek: update cursors by using async atomic update") Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.") Signed-off-by: Hsiao Chien Sung <shawn.sung@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20240620-igt-v3-1-a9d62d2e2c7e@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm: zynqmp_kms: Fix AUX bus not getting unregisteredSean Anderson
[ Upstream commit 0743dafefd3f2b92116213f2225ea355001b7948 ] drm_encoder_cleanup is responsible for calling drm_bridge_detach for each bridge attached to the encoder. zynqmp_dp_bridge_detach is in turn responsible for unregistering the AUX bus. However, we never ended up calling drm_encoder_cleanup in the remove or error paths, so the AUX bus would stick around after the rest of the driver had been removed. I don't really understand why drm_mode_config_cleanup doesn't call drm_encoder_cleanup for us. It will call destroy (which for simple_encoder is drm_encoder_cleanup) on encoders in the mode_config's encoder_list. Should drm_encoder_cleanup get called before or after drm_atomic_helper_shutdown? Fixes: 2dfd045c8435 ("drm: xlnx: zynqmp_dpsub: Register AUX bus at bridge attach time") Signed-off-by: Sean Anderson <sean.anderson@linux.dev> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503192922.2172314-2-sean.anderson@linux.dev Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm: zynqmp_dpsub: Fix an error handling path in zynqmp_dpsub_probe()Christophe JAILLET
[ Upstream commit 4ea3deda1341fef7b923ad9cfe5dd46b1b51bfa8 ] If zynqmp_dpsub_drm_init() fails, we must undo the previous drm_bridge_add() call. Fixes: be3f3042391d ("drm: zynqmp_dpsub: Always register bridge") Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by: Sean Anderson <sean.anderso@linux.dev> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Link: https://patchwork.freedesktop.org/patch/msgid/974d1b062d7c61ee6db00d16fa7c69aa1218ee02.1716198025.git.christophe.jaillet@wanadoo.fr Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/bridge: it6505: fix hibernate to resume no display issueKuro Chung
[ Upstream commit 484436ec5c2bffe8f346a09ae1cbc4cbf5e50005 ] When the system power resumes, the TTL input of IT6505 may experience some noise before the video signal stabilizes, necessitating a video reset. This patch is implemented to prevent a loop of video error interrupts, which can occur when a video reset in the video FIFO error interrupt triggers another such interrupt. The patch processes the SCDT and FIFO error interrupts simultaneously and ignores any video FIFO error interrupts caused by a video reset. Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Signed-off-by: Kuro Chung <kuro.chung@ite.com.tw> Signed-off-by: Hermes Wu <hermes.wu@ite.com.tw> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240522065528.1053439-1-kuro.chung@ite.com.tw Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/bridge: Fixed a DP link training bugxiazhengqiao
[ Upstream commit ca077ff8cac5af8a5a3c476983a6dd54aa3511b7 ] To have better compatibility for DP sink, there is a retry mechanism for the link training process to switch between different training process. The original driver code doesn't reset the retry counter when training state is pass. If the system triggers link training over 3 times, there will be a chance to causes the driver to use the wrong training method and return a training fail result. To Fix this, we reset the retry counter when training state is pass each time. Signed-off-by: Allen Chen <allen.chen@ite.corp-partner.google.com> Signed-off-by: xiazhengqiao <xiazhengqiao@huaqin.corp-partner.google.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20231221093057.7073-1-xiazhengqiao@huaqin.corp-partner.google.com Stable-dep-of: 484436ec5c2b ("drm/bridge: it6505: fix hibernate to resume no display issue") Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/panel: boe-tv101wum-nl6: Check for errors on the NOP in prepare()Douglas Anderson
[ Upstream commit 6320b9199dd99622668649c234d4e8a99e44a9c8 ] The mipi_dsi_dcs_nop() function returns an error but we weren't checking it in boe_panel_prepare(). Add a check. This is highly unlikely to matter in practice. If the NOP failed then likely later MIPI commands would fail too. Found by code inspection. Fixes: 812562b8d881 ("drm/panel: boe-tv101wum-nl6: Fine tune the panel power sequence") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240517143643.3.Ibffbaa5b4999ac0e55f43bf353144433b099d727@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.3.Ibffbaa5b4999ac0e55f43bf353144433b099d727@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/panel: boe-tv101wum-nl6: If prepare fails, disable GPIO before regulatorsDouglas Anderson
[ Upstream commit 587c48f622374e5d47b1d515c6006a4df4dee882 ] The enable GPIO should clearly be set low before turning off regulators. That matches both the inverse order that things were enabled and also the order in unprepare(). Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240517143643.2.Ieac346cd0f1606948ba39ceea06b55359fe972b6@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.2.Ieac346cd0f1606948ba39ceea06b55359fe972b6@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/panel: himax-hx8394: Handle errors from mipi_dsi_dcs_set_display_on() betterDouglas Anderson
[ Upstream commit cc2db2ef8d9eebc0df03808ac0dadbdb96733499 ] If mipi_dsi_dcs_set_display_on() returned an error then we'd store that in the "ret" variable and jump to error handling. We'd then attempt an orderly poweroff. Unfortunately we then blew away the value stored in "ret". That means that if the orderly poweroff actually worked then we're return 0 (no error) from hx8394_enable() even though the panel wasn't enabled. Fix this by not blowing away "ret". Found by code inspection. Fixes: 65dc9360f741 ("drm: panel: Add Himax HX8394 panel controller driver") Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20240517143643.1.I0a6836fffd8d7620f353becb3df2370d2898f803@changeid Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.1.I0a6836fffd8d7620f353becb3df2370d2898f803@changeid Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/amdgpu: Remove GC HW IP 9.3.0 from noretry=1Tim Van Patten
[ Upstream commit 1446226d32a45bb7c4f63195a59be8c08defe658 ] The following commit updated gmc->noretry from 0 to 1 for GC HW IP 9.3.0: commit 5f3854f1f4e2 ("drm/amdgpu: add more cases to noretry=1") This causes the device to hang when a page fault occurs, until the device is rebooted. Instead, revert back to gmc->noretry=0 so the device is still responsive. Fixes: 5f3854f1f4e2 ("drm/amdgpu: add more cases to noretry=1") Signed-off-by: Tim Van Patten <timvp@google.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/amdgpu: Check if NBIO funcs are NULL in amdgpu_device_baco_exitFriedrich Vock
[ Upstream commit 0cdb3f9740844b9d95ca413e3fcff11f81223ecf ] The special case for VM passthrough doesn't check adev->nbio.funcs before dereferencing it. If GPUs that don't have an NBIO block are passed through, this leads to a NULL pointer dereference on startup. Signed-off-by: Friedrich Vock <friedrich.vock@gmx.de> Fixes: 1bece222eabe ("drm/amdgpu: Clear doorbell interrupt status for Sienna Cichlid") Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@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>
2024-08-03drm/amdgpu: Fix memory range calculationLijo Lazar
[ Upstream commit ce798376ef6764de51d8f4684ae525b55df295fa ] Consider the 16M reserved region also before range calculation for GMC 9.4.3 SOCs. Fixes: a433f1f59484 ("drm/amdgpu: Initialize memory ranges for GC 9.4.3") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Le Ma <le.ma@amd.com> Reviewed-by: Hawking Zhang <Hawking.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/amd/pm: Fix aldebaran pcie speed reportingLijo Lazar
[ Upstream commit b6420021e17e262c57bb289d0556ee181b014f9c ] Fix the field definitions for LC_CURRENT_DATA_RATE. Fixes: c05d1c401572 ("drm/amd/swsmu: add aldebaran smu13 ip support (v3)") Signed-off-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Asad Kamal <asad.kamal@amd.com> Reviewed-by: Yang Wang <kevinyang.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/amdkfd: Fix CU Masking for GFX 9.4.3Mukul Joshi
[ Upstream commit 85cf43c554e438e2e12b0fe109688c9533e4d93f ] We are incorrectly passing the first XCC's MQD when updating CU masks for other XCCs in the partition. Fix this by passing the MQD for the XCC currently being updated with CU mask to update_cu_mask function. Fixes: fc6efed2c728 ("drm/amdkfd: Update CU masking for GFX 9.4.3") Signed-off-by: Mukul Joshi <mukul.joshi@amd.com> Reviewed-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/arm/komeda: Fix komeda probe failing if there are no links in the ↵Faiz Abbas
secondary pipeline [ Upstream commit 9054c46d479b55768adae31031a1afa1b7d62228 ] Since commit 4cfe5cc02e3f ("drm/arm/komeda: Remove component framework and add a simple encoder"), the devm_drm_of_get_bridge() call happens regardless of whether any remote nodes are available on the pipeline. Fix this by moving the bridge attach to its own function and calling it conditional on there being an output link. Fixes: 4cfe5cc02e3f ("drm/arm/komeda: Remove component framework and add a simple encoder") Signed-off-by: Faiz Abbas <faiz.abbas@arm.com> [Corrected Commit-id of the fixed patch to match mainline] Signed-off-by: Liviu Dudau <liviu.dudau@arm.com> Acked-by: Liviu Dudau <liviu.dudau@arm.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240219100915.192475-2-faiz.abbas@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2024-08-03drm/rockchip: vop2: Fix the port mux of VP2Andy Yan
[ Upstream commit 2bdb481bf7a93c22b9fea8daefa2834aab23a70f ] The port mux of VP2 should be RK3568_OVL_PORT_SET__PORT2_MUX. Fixes: 604be85547ce ("drm/rockchip: Add VOP2 driver") Signed-off-by: Andy Yan <andy.yan@rock-chips.com> Acked-by: Sascha Hauer <s.hauer@pengutronix.de> Tested-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240422101905.32703-2-andyshrk@163.com Signed-off-by: Sasha Levin <sashal@kernel.org>