summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm
AgeCommit message (Collapse)AuthorFilesLines
2023-10-10drm/amd: Fix logic error in sienna_cichlid_update_pcie_parameters()Mario Limonciello1-18/+23
commit 2a1fe39a5be785e962e387146aed34fa9a829f3f upstream. While aligning SMU11 with SMU13 implementation an assumption was made that `dpm_context->dpm_tables.pcie_table` was populated in dpm table initialization like in SMU13 but it isn't. So restore some of the original logic and instead just check for amdgpu_device_pcie_dynamic_switching_supported() to decide whether to hardcode values; erring on the side of performance. Cc: stable@vger.kernel.org # 6.1+ Reported-and-tested-by: Umio Yasuno <coelacanth_dream@protonmail.com> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/1447#note_2101382 Fixes: e701156ccc6c ("drm/amd: Align SMU11 SMU_MSG_OverridePcieParameters implementation with SMU13") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-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>
2023-10-10drm/amd: Fix detection of _PR3 on the PCIe root portMario Limonciello1-1/+1
commit 134b8c5d8674e7cde380f82e9aedfd46dcdd16f7 upstream. On some systems with Navi3x dGPU will attempt to use BACO for runtime PM but fails to resume properly. This is because on these systems the root port goes into D3cold which is incompatible with BACO. This happens because in this case dGPU is connected to a bridge between root port which causes BOCO detection logic to fail. Fix the intent of the logic by looking at root port, not the immediate upstream bridge for _PR3. Cc: stable@vger.kernel.org Suggested-by: Jun Ma <Jun.Ma2@amd.com> Tested-by: David Perry <David.Perry@amd.com> Fixes: b10c1c5b3a4e ("drm/amdgpu: add check for ACPI power resources") Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Reviewed-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>
2023-10-10drm/amd/display: Adjust the MST resume flowWayne Lin1-13/+80
commit ec5fa9fcdeca69edf7dab5ca3b2e0ceb1c08fe9a upstream. [Why] In drm_dp_mst_topology_mgr_resume() today, it will resume the mst branch to be ready handling mst mode and also consecutively do the mst topology probing. Which will cause the dirver have chance to fire hotplug event before restoring the old state. Then Userspace will react to the hotplug event based on a wrong state. [How] Adjust the mst resume flow as: 1. set dpcd to resume mst branch status 2. restore source old state 3. Do mst resume topology probing For drm_dp_mst_topology_mgr_resume(), it's better to adjust it to pull out topology probing work into a 2nd part procedure of the mst resume. Will have a follow up patch in drm. Reviewed-by: Chao-kai Wang <stylon.wang@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Acked-by: Stylon Wang <stylon.wang@amd.com> Signed-off-by: Wayne Lin <wayne.lin@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> [ Adjust for missing variable rename in f0127cb11299 ("drm/amdgpu/display/mst: adjust the naming of mst_port and port of aconnector") ] Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-06drm/meson: fix memory leak on ->hpd_notify callbackJani Nikula1-0/+2
commit 099f0af9d98231bb74956ce92508e87cbcb896be upstream. The EDID returned by drm_bridge_get_edid() needs to be freed. Fixes: 0af5e0b41110 ("drm/meson: encoder_hdmi: switch to bridge DRM_BRIDGE_ATTACH_NO_CONNECTOR") Cc: Neil Armstrong <narmstrong@baylibre.com> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Cc: Neil Armstrong <neil.armstrong@linaro.org> Cc: Kevin Hilman <khilman@baylibre.com> Cc: Jerome Brunet <jbrunet@baylibre.com> Cc: dri-devel@lists.freedesktop.org Cc: linux-amlogic@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: stable@vger.kernel.org # v5.17+ Signed-off-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230914131015.2472029-1-jani.nikula@intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-06drm/amdkfd: Use gpu_offset for user queue's wptrYuBiao Wang1-1/+1
commit cc39f9ccb82426e576734b493e1777ea01b144a8 upstream. Directly use tbo's start address will miss the domain start offset. Need to use gpu_offset instead. Signed-off-by: YuBiao Wang <YuBiao.Wang@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 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-06drm/i915/gt: Fix reservation address in ggtt_reserve_guc_topJavier Pello1-6/+17
commit b7599d241778d0b10cdf7a5c755aa7db9b83250c upstream. There is an assertion in ggtt_reserve_guc_top that the global GTT is of size at least GUC_GGTT_TOP, which is not the case on a 32-bit platform; see commit 562d55d991b39ce376c492df2f7890fd6a541ffc ("drm/i915/bdw: Only use 2g GGTT for 32b platforms"). If GEM_BUG_ON is enabled, this triggers a BUG(); if GEM_BUG_ON is disabled, the subsequent reservation fails and the driver fails to initialise the device: i915 0000:00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of GGTT for GuC i915 0000:00:02.0: Device initialization failed (-28) i915 0000:00:02.0: Please file a bug on drm/i915; see https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for details. i915: probe of 0000:00:02.0 failed with error -28 Make the reservation at the top of the available space, whatever that is, instead of assuming that the top will be GUC_GGTT_TOP. Fixes: 911800765ef6 ("drm/i915/uc: Reserve upper range of GGTT") Link: https://gitlab.freedesktop.org/drm/intel/-/issues/9080 Signed-off-by: Javier Pello <devel@otheo.eu> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Fernando Pacheco <fernando.pacheco@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: intel-gfx@lists.freedesktop.org Cc: stable@vger.kernel.org # v5.3+ Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230902171039.2229126186d697dbcf62d6d8@otheo.eu (cherry picked from commit 0f3fa942d91165c2702577e9274d2ee1c7212afc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-06drm/tests: Fix incorrect argument in drm_test_mm_insert_rangeJanusz Krzysztofik1-1/+1
commit 2ba157983974ae1b6aaef7d4953812020d6f1eb5 upstream. While drm_mm test was converted form igt selftest to kunit, unexpected value of "end" argument equal "start" was introduced to one of calls to a function that executes the drm_test_mm_insert_range for specific start/end pair of arguments. As a consequence, DRM_MM_BUG_ON(end <= start) is triggered. Fix it by restoring the original value. Fixes: fc8d29e298cf ("drm: selftest: convert drm_mm selftest to KUnit") Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com> Cc: "Maíra Canal" <mairacanal@riseup.net> Cc: Arthur Grillo <arthurgrillo@riseup.net> Cc: Javier Martinez Canillas <javierm@redhat.com> Cc: Daniel Latypov <dlatypov@google.com> Cc: stable@vger.kernel.org # v6.1+ Reviewed-by: Maíra Canal <mairacanal@riseup.net> Signed-off-by: Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230911130323.7037-2-janusz.krzysztofik@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-10-06drm/amdgpu: Handle null atom context in VBIOS info ioctlDavid Francis1-6/+11
[ Upstream commit 5e7e82254270c8cf8b107451c5de01cee2f135ae ] On some APU systems, there is no atom context and so the atom_context struct is null. Add a check to the VBIOS_INFO branch of amdgpu_info_ioctl to handle this case, returning all zeroes. Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: David Francis <David.Francis@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06drm/amdgpu/nbio4.3: set proper rmmio_remap.reg_offset for SR-IOVAlex Deucher1-0/+3
[ Upstream commit ab43213e7afd08ac68d4282060bacf309e70fd14 ] Needed for HDP flush to work correctly. Reviewed-by: Timmy Tsai <timmtsai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06drm/amdgpu/soc21: don't remap HDP registers for SR-IOVAlex Deucher1-1/+1
[ Upstream commit 1832403cd41ca6b19b24e9d64f79cb08d920ca44 ] This matches the behavior for soc15 and nv. Acked-by: Christian König <christian.koenig@amd.com> Reviewed-by: Timmy Tsai <timmtsai@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06drm/amd/display: Don't check registers, if using AUX BL controlSwapnil Patel1-1/+3
[ Upstream commit f5b2c10b57615828b531bb0ae56bd6325a41167e ] [Why] Currently the driver looks DCN registers to access if BL is on or not. This check is not valid if we are using AUX based brightness control. This causes driver to not send out "backlight off" command during power off sequence as it already thinks it is off. [How] Only check DCN registers if we aren't using AUX based brightness control. Reviewed-by: Wenjing Liu <wenjing.liu@amd.com> Acked-by: Stylon Wang <stylon.wang@amd.com> Signed-off-by: Swapnil Patel <swapnil.patel@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>
2023-10-06drm/bridge: ti-sn65dsi83: Do not generate HFP/HBP/HSA and EOT packetMarek Vasut1-1/+3
[ Upstream commit ca161b259cc84fe1f4a2ce4c73c3832cf6f713f1 ] Do not generate the HS front and back porch gaps, the HSA gap and EOT packet, as per "SN65DSI83 datasheet SLLSEC1I - SEPTEMBER 2012 - REVISED OCTOBER 2020", page 22, these packets are not required. This makes the TI SN65DSI83 bridge work with Samsung DSIM on i.MX8MN. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230403190242.224490-1-marex@denx.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06drm/amdkfd: Insert missing TLB flush on GFX10 and laterHarish Kasiviswanathan1-2/+1
[ Upstream commit edcfe22985d09ee8e2346c9217f5a52ab150099f ] Heavy-weight TLB flush is required after unmap on all GPUs for correctness and security. Signed-off-by: Harish Kasiviswanathan <Harish.Kasiviswanathan@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06drm/amdkfd: Flush TLB after unmapping for GFX v9.4.3Philip Yang1-3/+3
[ Upstream commit 75dda67c7213c3e0d17244a8c42547c27ee746f8 ] kfd_flush_tlb_after_unmap should return true for GFX v9.4.3, to do TLB heavyweight flush after unmapping from GPU to guarantee that the GPU will not access pages after they have been unmapped. This also helps improve the mapping to GPU performance. Without this, KFD accidently flush TLB after mapping to GPU because the vm update sequence number is increased by previous unmapping. Signed-off-by: Philip Yang <Philip.Yang@amd.com> Reviewed-by: Felix Kuehling <Felix.Kuehling@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: edcfe22985d0 ("drm/amdkfd: Insert missing TLB flush on GFX10 and later") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-10-06i915/pmu: Move execlist stats initialization to execlist specific setupUmesh Nerlige Ramappa2-1/+2
[ Upstream commit c524cd40e8a2a1a36f4898eaf2024beefeb815f3 ] engine->stats is a union of execlist and guc stat objects. When execlist specific fields are initialized, the initial state of guc stats is affected. This results in bad busyness values when using GuC mode. Move the execlist initialization from common code to execlist specific code. Fixes: 77cdd054dd2c ("drm/i915/pmu: Connect engine busyness stats from GuC to pmu") Signed-off-by: Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230912212247.1828681-1-umesh.nerlige.ramappa@intel.com (cherry picked from commit 4485bd519f5d6d620a29d0547ff3c982bdeeb468) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-23drm/amdgpu: fix amdgpu_cs_p1_user_fenceChristian König1-14/+4
commit 35588314e963938dfdcdb792c9170108399377d6 upstream. The offset is just 32bits here so this can potentially overflow if somebody specifies a large value. Instead reduce the size to calculate the last possible offset. The error handling path incorrectly drops the reference to the user fence BO resulting in potential reference count underflow. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-23drm/amd/display: fix the white screen issue when >= 64GB DRAMYifan Zhang1-5/+9
commit ef064187a9709393a981a56cce1e31880fd97107 upstream. Dropping bit 31:4 of page table base is wrong, it makes page table base points to wrong address if phys addr is beyond 64GB; dropping page_table_start/end bit 31:4 is unnecessary since dcn20_vmid_setup will do that. Also, while we are at it, cleanup the assignments using upper_32_bits()/lower_32_bits() and AMDGPU_GPU_PAGE_SHIFT. Cc: stable@vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2354 Fixes: 81d0bcf99009 ("drm/amdgpu: make display pinning more flexible (v2)") Acked-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Yifan Zhang <yifan1.zhang@amd.com> Co-developed-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-23Revert "drm/amd: Disable S/G for APUs when 64GB or more host memory"Hamza Mahfooz3-29/+3
commit 169ed4ece8373f02f10642eae5240e3d1ef5c038 upstream. This reverts commit 70e64c4d522b732e31c6475a3be2349de337d321. Since, we now have an actual fix for this issue, we can get rid of this workaround as it can cause pin failures if enough VRAM isn't carved out by the BIOS. Cc: stable@vger.kernel.org # 6.1+ Acked-by: Harry Wentland <harry.wentland@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-23drm: gm12u320: Fix the timeout usage for usb_bulk_msg()Jinjie Ruan1-5/+5
[ Upstream commit 7583028d359db3cd0072badcc576b4f9455fd27a ] The timeout arg of usb_bulk_msg() is ms already, which has been converted to jiffies by msecs_to_jiffies() in usb_start_wait_urb(). So fix the usage by removing the redundant msecs_to_jiffies() in the macros. And as Hans suggested, also remove msecs_to_jiffies() for the IDLE_TIMEOUT macro to make it consistent here and so change IDLE_TIMEOUT to msecs_to_jiffies(IDLE_TIMEOUT) where it is used. Fixes: e4f86e437164 ("drm: Add Grain Media GM12U320 driver v2") Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com> Suggested-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230904021421.1663892-1-ruanjinjie@huawei.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-23drm/mediatek: dp: Change logging to dev for mtk_dp_aux_transfer()AngeloGioacchino Del Regno1-3/+3
[ Upstream commit fd70e2019bfbcb0ed90c5e23839bf510ce6acf8f ] Change logging from drm_{err,info}() to dev_{err,info}() in functions mtk_dp_aux_transfer() and mtk_dp_aux_do_transfer(): this will be essential to avoid getting NULL pointer kernel panics if any kind of error happens during AUX transfers happening before the bridge is attached. This may potentially start happening in a later commit implementing aux-bus support, as AUX transfers will be triggered from the panel driver (for EDID) before the mtk-dp bridge gets attached, and it's done in preparation for the same. Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20230725073234.55892-4-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-23drm/exynos: fix a possible null-pointer dereference due to data race in ↵Tuo Li1-3/+2
exynos_drm_crtc_atomic_disable() [ Upstream commit 2e63972a2de14482d0eae1a03a73e379f1c3f44c ] The variable crtc->state->event is often protected by the lock crtc->dev->event_lock when is accessed. However, it is accessed as a condition of an if statement in exynos_drm_crtc_atomic_disable() without holding the lock: if (crtc->state->event && !crtc->state->active) However, if crtc->state->event is changed to NULL by another thread right after the conditions of the if statement is checked to be true, a null-pointer dereference can occur in drm_crtc_send_vblank_event(): e->pipe = pipe; To fix this possible null-pointer dereference caused by data race, the spin lock coverage is extended to protect the if statement as well as the function call to drm_crtc_send_vblank_event(). Reported-by: BassCheck <bass@buaa.edu.cn> Link: https://sites.google.com/view/basscheck/home Signed-off-by: Tuo Li <islituo@gmail.com> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Added relevant link. Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-23drm/amd/display: Blocking invalid 420 modes on HDMI TMDS for DCN314Leo Chen1-1/+3
[ Upstream commit 4c6107a653ccf361cb1b6ba35d558a1a5e6e57ac ] [Why & How] HDMI TMDS does not have ODM support. Filtering 420 modes that exceed the 4096 FMT limitation on DCN314 will resolve intermittent corruptions issues. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Leo Chen <sancchen@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>
2023-09-23drm/amd/display: Blocking invalid 420 modes on HDMI TMDS for DCN31Leo Chen1-1/+3
[ Upstream commit 026a71babf48efb6b9884a3a66fa31aec9e1ea54 ] [Why & How] HDMI TMDS does not have ODM support. Filtering 420 modes that exceed the 4096 FMT limitation on DCN31 will resolve intermittent corruptions issues. Reviewed-by: Nicholas Kazlauskas <nicholas.kazlauskas@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Leo Chen <sancchen@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>
2023-09-23drm/amd/display: Use DTBCLK as refclk instead of DPREFCLKAustin Zheng1-1/+2
[ Upstream commit 4a30cc2bd281fa176a68b5305cd3695d636152ad ] [Why] Flash of corruption observed when UCLK switching after transitioning from DTBCLK to DPREFCLK on subVP(DP) + subVP(HDMI) config Scenario where DPREFCLK is required instead of DTBCLK is not expected [How] Always set the DTBCLK source as DTBCLK0 Reviewed-by: Alvin Lee <alvin.lee2@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Austin Zheng <austin.zheng@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>
2023-09-23drm/amd/display: Fix underflow issue on 175hz timingLeo Ma1-1/+6
[ Upstream commit 735688eb905db529efea0c78466fccc1461c3fde ] [Why] Screen underflows happen on 175hz timing for 3 plane overlay case. [How] Based on dst y prefetch value clamp to equ or oto for bandwidth calculation. Reviewed-by: Dillon Varone <dillon.varone@amd.com> Acked-by: Alex Hung <alex.hung@amd.com> Signed-off-by: Leo Ma <hanghong.ma@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>
2023-09-23drm/edid: Add quirk for OSVR HDK 2.0Ralph Campbell1-0/+1
[ Upstream commit 98d4cb705bc00afd4a9a71cc1e84f7111682639a ] The OSVR virtual reality headset HDK 2.0 uses a different EDID vendor and device identifier than the HDK 1.1 - 1.4 headsets. Add the HDK 2.0 vendor and device identifier to the quirks table so that window managers do not try to display the desktop screen on the headset display. Closes: https://gitlab.freedesktop.org/drm/misc/-/issues/30 Signed-off-by: Ralph Campbell <rcampbell@nvidia.com> Tested-by: Ralph Campbell <rcampbell@nvidia.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230621061903.3422648-1-rcampbell@nvidia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-23drm/bridge: tc358762: Instruct DSI host to generate HSE packetsMarek Vasut1-1/+1
[ Upstream commit 362fa8f6e6a05089872809f4465bab9d011d05b3 ] This bridge seems to need the HSE packet, otherwise the image is shifted up and corrupted at the bottom. This makes the bridge work with Samsung DSIM on i.MX8MM and i.MX8MP. Signed-off-by: Marek Vasut <marex@denx.de> Reviewed-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230615201902.566182-3-marex@denx.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19drm/amd/display: Fix a bug when searching for insert_above_mpccWesley Chalmers1-2/+3
commit 3d028d5d60d516c536de1ddd3ebf3d55f3f8983b upstream. [WHY] Currently, when insert_plane is called with insert_above_mpcc parameter that is equal to tree->opp_list, the function returns NULL. [HOW] Instead, the function should insert the plane at the top of the tree. Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Tom Chung <chiahsuan.chung@amd.com> Signed-off-by: Wesley Chalmers <wesley.chalmers@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19drm/amdgpu: register a dirty framebuffer callback for fbconHamza Mahfooz1-1/+25
commit 0a611560f53bfd489e33f4a718c915f1a6123d03 upstream. fbcon requires that we implement &drm_framebuffer_funcs.dirty. Otherwise, the framebuffer might take a while to flush (which would manifest as noticeable lag). However, we can't enable this callback for non-fbcon cases since it may cause too many atomic commits to be made at once. So, implement amdgpu_dirtyfb() and only enable it for fbcon framebuffers (we can use the "struct drm_file file" parameter in the callback to check for this since it is only NULL when called by fbcon, at least in the mainline kernel) on devices that support atomic KMS. Cc: Aurabindo Pillai <aurabindo.pillai@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Cc: stable@vger.kernel.org # 6.1+ Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2519 Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19drm/amd/display: Remove wait while lockedGabe Teeger3-28/+42
commit 5a3ccb1400339268c5e3dc1fa044a7f6c7f59a02 upstream. [Why] We wait for mpc idle while in a locked state, leading to potential deadlock. [What] Move the wait_for_idle call to outside of HW lock. This and a call to wait_drr_doublebuffer_pending_clear are moved added to a new static helper function called wait_for_outstanding_hw_updates, to make the interface clearer. Cc: stable@vger.kernel.org Fixes: 8f0d304d21b3 ("drm/amd/display: Do not commit pipe when updating DRR") Reviewed-by: Jun Lei <jun.lei@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Gabe Teeger <gabe.teeger@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19drm/amd/display: always switch off ODM before committing more streamsWenjing Liu1-5/+5
commit 49a30c3d1a2258fc93cfe6eea8e4951dabadc824 upstream. ODM power optimization is only supported with single stream. When ODM power optimization is enabled, we might not have enough free pipes for enabling other stream. So when we are committing more than 1 stream we should first switch off ODM power optimization to make room for new stream and then allocating pipe resource for the new stream. Cc: stable@vger.kernel.org Fixes: 59de751e3845 ("drm/amd/display: add ODM case when looking for first split pipe") Reviewed-by: Dillon Varone <dillon.varone@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Wenjing Liu <wenjing.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19drm/amd/display: prevent potential division by zero errorsHamza Mahfooz1-3/+6
commit 07e388aab042774f284a2ad75a70a194517cdad4 upstream. There are two places in apply_below_the_range() where it's possible for a divide by zero error to occur. So, to fix this make sure the divisor is non-zero before attempting the computation in both cases. Cc: stable@vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2637 Fixes: a463b263032f ("drm/amd/display: Fix frames_to_insert math") Fixes: ded6119e825a ("drm/amd/display: Reinstate LFC optimization") Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19drm/amd/display: enable cursor degamma for DCN3+ DRM legacy gammaMelissa Wen1-0/+7
commit 57a943ebfcdb4a97fbb409640234bdb44bfa1953 upstream. For DRM legacy gamma, AMD display manager applies implicit sRGB degamma using a pre-defined sRGB transfer function. It works fine for DCN2 family where degamma ROM and custom curves go to the same color block. But, on DCN3+, degamma is split into two blocks: degamma ROM for pre-defined TFs and `gamma correction` for user/custom curves and degamma ROM settings doesn't apply to cursor plane. To get DRM legacy gamma working as expected, enable cursor degamma ROM for implict sRGB degamma on HW with this configuration. Cc: stable@vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2803 Fixes: 96b020e2163f ("drm/amd/display: check attr flag before set cursor degamma on DCN3+") Signed-off-by: Melissa Wen <mwen@igalia.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19drm/mxsfb: Disable overlay plane in mxsfb_plane_overlay_atomic_disable()Liu Ying1-0/+9
commit aa656d48e871a1b062e1bbf9474d8b831c35074c upstream. When disabling overlay plane in mxsfb_plane_overlay_atomic_update(), overlay plane's framebuffer pointer is NULL. So, dereferencing it would cause a kernel Oops(NULL pointer dereferencing). Fix the issue by disabling overlay plane in mxsfb_plane_overlay_atomic_disable() instead. Fixes: cb285a5348e7 ("drm: mxsfb: Replace mxsfb_get_fb_paddr() with drm_fb_cma_get_gem_addr()") Cc: stable@vger.kernel.org # 5.19+ Signed-off-by: Liu Ying <victor.liu@nxp.com> Reviewed-by: Marek Vasut <marex@denx.de> Signed-off-by: Marek Vasut <marex@denx.de> Link: https://patchwork.freedesktop.org/patch/msgid/20230612092359.784115-1-victor.liu@nxp.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19drm/i915/gvt: Drop unused helper intel_vgpu_reset_gtt()Sean Christopherson2-19/+0
[ Upstream commit a90c367e5af63880008e21dd199dac839e0e9e0f ] Drop intel_vgpu_reset_gtt() as it no longer has any callers. In addition to eliminating dead code, this eliminates the last possible scenario where __kvmgt_protect_table_find() can be reached without holding vgpu_lock. Requiring vgpu_lock to be held when calling __kvmgt_protect_table_find() will allow a protecting the gfn hash with vgpu_lock without too much fuss. No functional change intended. Fixes: ba25d977571e ("drm/i915/gvt: Do not destroy ppgtt_mm during vGPU D3->D0.") Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Tested-by: Yongwei Ma <yongwei.ma@intel.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Link: https://lore.kernel.org/r/20230729013535.1070024-11-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19drm/i915/gvt: Put the page reference obtained by KVM's gfn_to_pfn()Sean Christopherson1-1/+4
[ Upstream commit 708e49583d7da863898b25dafe4bcd799c414278 ] Put the struct page reference acquired by gfn_to_pfn(), KVM's API is that the caller is ultimately responsible for dropping any reference. Note, kvm_release_pfn_clean() ensures the pfn is actually a refcounted struct page before trying to put any references. Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support") Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Tested-by: Yongwei Ma <yongwei.ma@intel.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Link: https://lore.kernel.org/r/20230729013535.1070024-6-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct page"Sean Christopherson1-0/+4
[ Upstream commit f046923af79158361295ed4f0a588c80b9fdcc1d ] Check that the pfn found by gfn_to_pfn() is actually backed by "struct page" memory prior to retrieving and dereferencing the page. KVM supports backing guest memory with VM_PFNMAP, VM_IO, etc., and so there is no guarantee the pfn returned by gfn_to_pfn() has an associated "struct page". Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support") Reviewed-by: Yan Zhao <yan.y.zhao@intel.com> Tested-by: Yongwei Ma <yongwei.ma@intel.com> Reviewed-by: Zhi Wang <zhi.a.wang@intel.com> Link: https://lore.kernel.org/r/20230729013535.1070024-2-seanjc@google.com Signed-off-by: Sean Christopherson <seanjc@google.com> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19drm/i915: mark requests for GuC virtual engines to avoid use-after-freeAndrzej Hajda3-5/+6
[ Upstream commit 5eefc5307c983b59344a4cb89009819f580c84fa ] References to i915_requests may be trapped by userspace inside a sync_file or dmabuf (dma-resv) and held indefinitely across different proceses. To counter-act the memory leaks, we try to not to keep references from the request past their completion. On the other side on fence release we need to know if rq->engine is valid and points to hw engine (true for non-virtual requests). To make it possible extra bit has been added to rq->execution_mask, for marking virtual engines. Fixes: bcb9aa45d5a0 ("Revert "drm/i915: Hold reference to intel_context over life of i915_request"") Signed-off-by: Chris Wilson <chris.p.wilson@linux.intel.com> Signed-off-by: Andrzej Hajda <andrzej.hajda@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/20230821153035.3903006-1-andrzej.hajda@intel.com (cherry picked from commit 280410677af763f3871b93e794a199cfcf6fb580) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-19drm/ast: Fix DRAM init on AST2200Thomas Zimmermann1-1/+1
commit 4cfe75f0f14f044dae66ad0e6eea812d038465d9 upstream. Fix the test for the AST2200 in the DRAM initialization. The value in ast->chip has to be compared against an enum constant instead of a numerical value. This bug got introduced when the driver was first imported into the kernel. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Fixes: 312fec1405dd ("drm: Initial KMS driver for AST (ASpeed Technologies) 2000 series (v2)") Cc: Dave Airlie <airlied@redhat.com> Cc: dri-devel@lists.freedesktop.org Cc: <stable@vger.kernel.org> # v3.5+ Reviewed-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: Jocelyn Falempe <jfalempe@redhat.com> Tested-by: Jocelyn Falempe <jfalempe@redhat.com> # AST2600 Link: https://patchwork.freedesktop.org/patch/msgid/20230621130032.3568-2-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-19drm/virtio: Conditionally allocate virtio_gpu_fenceGurchetan Singh1-12/+18
commit 70d1ace56db6c79d39dbe9c0d5244452b67e2fde upstream. We don't want to create a fence for every command submission. It's only necessary when userspace provides a waitable token for submission. This could be: 1) bo_handles, to be used with VIRTGPU_WAIT 2) out_fence_fd, to be used with dma_fence apis 3) a ring_idx provided with VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK + DRM event API 4) syncobjs in the future The use case for just submitting a command to the host, and expecting no response. For example, gfxstream has GFXSTREAM_CONTEXT_PING that just wakes up the host side worker threads. There's also CROSS_DOMAIN_CMD_SEND which just sends data to the Wayland server. This prevents the need to signal the automatically created virtio_gpu_fence. In addition, VIRTGPU_EXECBUF_RING_IDX is checked when creating a DRM event object. VIRTGPU_CONTEXT_PARAM_POLL_RINGS_MASK is already defined in terms of per-context rings. It was theoretically possible to create a DRM event on the global timeline (ring_idx == 0), if the context enabled DRM event polling. However, that wouldn't work and userspace (Sommelier). Explicitly disallow it for clarity. Signed-off-by: Gurchetan Singh <gurchetansingh@chromium.org> Reviewed-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Tested-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> Signed-off-by: Dmitry Osipenko <dmitry.osipenko@collabora.com> # edited coding style Link: https://patchwork.freedesktop.org/patch/msgid/20230707213124.494-1-gurchetansingh@chromium.org Signed-off-by: Alyssa Ross <hi@alyssa.is> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-13Revert "drm/amd/display: Do not set drr on pipe commit"Michel Dänzer2-13/+0
commit 360930985ec9f394c82ba0b235403b4a366d1560 upstream. This reverts commit e101bf95ea87ccc03ac2f48dfc0757c6364ff3c7. Caused a regression: Samsung Odyssey Neo G9, running at 5120x1440@240/VRR, connected to Navi 21 via DisplayPort, blanks and the GPU hangs while starting the Steam game Assetto Corsa Competizione (via Proton 7.0). Example dmesg excerpt: amdgpu 0000:0c:00.0: [drm] ERROR [CRTC:82:crtc-0] flip_done timed out NMI watchdog: Watchdog detected hard LOCKUP on cpu 6 [...] RIP: 0010:amdgpu_device_rreg.part.0+0x2f/0xf0 [amdgpu] Code: 41 54 44 8d 24 b5 00 00 00 00 55 89 f5 53 48 89 fb 4c 3b a7 60 0b 00 00 73 6a 83 e2 02 74 29 4c 03 a3 68 0b 00 00 45 8b 24 24 <48> 8b 43 08 0f b7 70 3e 66 90 44 89 e0 5b 5d 41 5c 31 d2 31 c9 31 RSP: 0000:ffffb39a119dfb88 EFLAGS: 00000086 RAX: ffffffffc0eb96a0 RBX: ffff9e7963dc0000 RCX: 0000000000007fff RDX: 0000000000000000 RSI: 0000000000004ff6 RDI: ffff9e7963dc0000 RBP: 0000000000004ff6 R08: ffffb39a119dfc40 R09: 0000000000000010 R10: ffffb39a119dfc40 R11: ffffb39a119dfc44 R12: 00000000000e05ae R13: 0000000000000000 R14: ffff9e7963dc0010 R15: 0000000000000000 FS: 000000001012f6c0(0000) GS:ffff9e805eb80000(0000) knlGS:000000007fd40000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000461ca000 CR3: 00000002a8a20000 CR4: 0000000000350ee0 Call Trace: <TASK> dm_read_reg_func+0x37/0xc0 [amdgpu] generic_reg_get2+0x22/0x60 [amdgpu] optc1_get_crtc_scanoutpos+0x6a/0xc0 [amdgpu] dc_stream_get_scanoutpos+0x74/0x90 [amdgpu] dm_crtc_get_scanoutpos+0x82/0xf0 [amdgpu] amdgpu_display_get_crtc_scanoutpos+0x91/0x190 [amdgpu] ? dm_read_reg_func+0x37/0xc0 [amdgpu] amdgpu_get_vblank_counter_kms+0xb4/0x1a0 [amdgpu] dm_pflip_high_irq+0x213/0x2f0 [amdgpu] amdgpu_dm_irq_handler+0x8a/0x200 [amdgpu] amdgpu_irq_dispatch+0xd4/0x220 [amdgpu] amdgpu_ih_process+0x7f/0x110 [amdgpu] amdgpu_irq_handler+0x1f/0x70 [amdgpu] __handle_irq_event_percpu+0x46/0x1b0 handle_irq_event+0x34/0x80 handle_edge_irq+0x9f/0x240 __common_interrupt+0x66/0x110 common_interrupt+0x5c/0xd0 asm_common_interrupt+0x22/0x40 Reviewed-by: Aurabindo Pillai <aurabindo.pillai@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Michel Dänzer <mdaenzer@redhat.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-13drm/amd/display: Add smu write msg id fail retry processFudong Wang1-4/+16
commit 72105dcfa3d12b5af49311f857e3490baa225135 upstream. A benchmark stress test (12-40 machines x 48hours) found that DCN315 has cases where DC writes to an indirect register to set the smu clock msg id, but when we go to read the same indirect register the returned msg id doesn't match with what we just set it to. So, to fix this retry the write until the register's value matches with the requested value. Cc: stable@vger.kernel.org # 6.1+ Fixes: f94903996140 ("drm/amd/display: Add DCN315 CLK_MGR") Reviewed-by: Charlene Liu <charlene.liu@amd.com> Acked-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Fudong Wang <fudong.wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-13drm/amd/display: register edp_backlight_control() for DCN301Hamza Mahfooz1-0/+1
commit 1611917f39bee1abfc01501238db8ac19649042d upstream. As made mention of in commit 099303e9a9bd ("drm/amd/display: eDP intermittent black screen during PnP"), we need to turn off the display's backlight before powering off an eDP display. Not doing so will result in undefined behaviour according to the eDP spec. So, set DCN301's edp_backlight_control() function pointer to dce110_edp_backlight_control(). Cc: stable@vger.kernel.org Link: https://gitlab.freedesktop.org/drm/amd/-/issues/2765 Fixes: 9c75891feef0 ("drm/amd/display: rework recent update PHY state commit") Suggested-by: Swapnil Patel <swapnil.patel@amd.com> Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Hamza Mahfooz <hamza.mahfooz@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-09-13drm/radeon: Use RMW accessors for changing LNKCTLIlpo Järvinen2-53/+20
[ Upstream commit 7189576e8a829130192b33c5b64e8a475369c776 ] Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. And in the case of upstream bridge, the driver does not even own the device it's changing the registers for. Use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register value. Suggested-by: Lukas Wunner <lukas@wunner.de> Fixes: 8a7cd27679d0 ("drm/radeon/cik: add support for pcie gen1/2/3 switching") Fixes: b9d305dfb66c ("drm/radeon: implement pcie gen2/3 support for SI") Link: https://lore.kernel.org/r/20230717120503.15276-7-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13drm/amdgpu: Use RMW accessors for changing LNKCTLIlpo Järvinen2-52/+20
[ Upstream commit ce7d88110b9ed5f33fe79ea6d4ed049fb0e57bce ] Don't assume that only the driver would be accessing LNKCTL. ASPM policy changes can trigger write to LNKCTL outside of driver's control. And in the case of upstream bridge, the driver does not even own the device it's changing the registers for. Use RMW capability accessors which do proper locking to avoid losing concurrent updates to the register value. Suggested-by: Lukas Wunner <lukas@wunner.de> Fixes: a2e73f56fa62 ("drm/amdgpu: Add support for CIK parts") Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10") Link: https://lore.kernel.org/r/20230717120503.15276-6-ilpo.jarvinen@linux.intel.com Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13drm/mediatek: Fix potential memory leak if vmap() failSui Jingfeng1-1/+5
[ Upstream commit 379091e0f6d179d1a084c65de90fa44583b14a70 ] Also return -ENOMEM if such a failure happens, the implement should take responsibility for the error handling. Fixes: 3df64d7b0a4f ("drm/mediatek: Implement gem prime vmap/vunmap function") Reviewed-by: Matthias Brugger <matthias.bgg@gmail.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Signed-off-by: Sui Jingfeng <suijingfeng@loongson.cn> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20230706134000.130098-1-suijingfeng@loongson.cn/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13drm/mediatek: Remove freeing not dynamic allocated memoryJason-JH.Lin1-5/+2
[ Upstream commit 27b9e2ea3f2757da26bb8280e46f7fdbb1acb219 ] Fixing the coverity issue of: mtk_drm_cmdq_pkt_destroy frees address of mtk_crtc->cmdq_handle So remove the free function. Fixes: 7627122fd1c0 ("drm/mediatek: Add cmdq_handle in mtk_crtc") Signed-off-by: Jason-JH.Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20230714094908.13087-2-jason-jh.lin@mediatek.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13drm/mediatek: dp: Add missing error checks in mtk_dp_parse_capabilitiesAngeloGioacchino Del Regno1-5/+10
[ Upstream commit cfc146137a9f12e883ba64bc496b6da4d23f26d5 ] If reading the RX capabilities fails the training pattern will be set wrongly: add error checking for drm_dp_read_dpcd_caps() and return if anything went wrong with it. While at it, also add a less critical error check when writing to clear the ESI0 IRQ vector. Fixes: f70ac097a2cf ("drm/mediatek: Add MT8195 Embedded DisplayPort driver") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Tested-by: Chen-Yu Tsai <wenst@chromium.org> Reviewed-by: Alexandre Mergnat <amergnat@baylibre.com> Reviewed-by: CK Hu <ck.hu@mediatek.com> Link: https://patchwork.kernel.org/project/dri-devel/patch/20230725073234.55892-2-angelogioacchino.delregno@collabora.com/ Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13drm/msm/a2xx: Call adreno_gpu_init() earlierFabio Estevam1-4/+4
[ Upstream commit db07ce5da8b26bfeaf437a676ae49bd3bb1eace6 ] The adreno_is_a20x() and adreno_is_a225() functions rely on the GPU revision, but such information is retrieved inside adreno_gpu_init(), which is called afterwards. Fix this problem by caling adreno_gpu_init() earlier, so that the GPU information revision is available when adreno_is_a20x() and adreno_is_a225() run. Tested on a imx53-qsb board. Fixes: 21af872cd8c6 ("drm/msm/adreno: add a2xx") Signed-off-by: Fabio Estevam <festevam@denx.de> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/543456/ Signed-off-by: Rob Clark <robdclark@chromium.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-09-13drm/amd/pm: fix variable dereferenced issue in amdgpu_device_attr_create()Yang Wang1-3/+7
[ Upstream commit 25e6373a5b8efc623443f2699d2b929bf3067d76 ] - fix variable ('attr') dereferenced issue. - using condition check instead of BUG_ON(). Fixes: 4e01847c38f7 ("drm/amdgpu: optimize amdgpu device attribute code") Cc: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by: Yang Wang <kevinyang.wang@amd.com> Reviewed-by: Kenneth Feng <kenneth.feng@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-18 19:00:05 +0300