summaryrefslogtreecommitdiff
path: root/drivers/gpu
AgeCommit message (Collapse)AuthorFilesLines
2023-07-19drm/bridge: Introduce pre_enable_prev_first to alter bridge init orderDave Stevenson1-24/+121
[ Upstream commit 4fb912e5e19075874379cfcf074d90bd51ebf8ea ] DSI sink devices typically want the DSI host powered up and configured before they are powered up. pre_enable is the place this would normally happen, but they are called in reverse order from panel/connector towards the encoder, which is the "wrong" order. Add a new flag pre_enable_prev_first that any bridge can set to swap the order of pre_enable (and post_disable) for that and the immediately previous bridge. Should the immediately previous bridge also set the pre_enable_prev_first flag, the previous bridge to that will be called before either of those which requested pre_enable_prev_first. eg: - Panel - Bridge 1 - Bridge 2 pre_enable_prev_first - Bridge 3 - Bridge 4 pre_enable_prev_first - Bridge 5 pre_enable_prev_first - Bridge 6 - Encoder Would result in pre_enable's being called as Panel, Bridge 1, Bridge 3, Bridge 2, Bridge 6, Bridge 5, Bridge 4, Encoder. Signed-off-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Tested-by: Frieder Schrempf <frieder.schrempf@kontron.de> Reviewed-by: Frieder Schrempf <frieder.schrempf@kontron.de> Link: https://lore.kernel.org/r/20221205173328.1395350-5-dave.stevenson@raspberrypi.com Signed-off-by: Maxime Ripard <maxime@cerno.tech> Stable-dep-of: dd9e329af723 ("drm/bridge: ti-sn65dsi83: Fix enable/disable flow to meet spec") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: anx7625: Prevent endless probe loopNícolas F. R. A. Prado1-40/+88
[ Upstream commit 1464e48d69ab7a50a377c9d39f5e5eb3cee2722e ] During probe, the driver registers i2c dummy devices and populates the aux bus, which registers a device for the panel. After doing that, the driver can still defer probe if needed. This ordering of operations is troublesome however, because the deferred probe work will retry probing all pending devices every time a new device is registered. Therefore, if modules need to be loaded in order to satisfy the dependencies for this driver to complete probe, the kernel will stall, since it'll keep trying to probe the anx7625 driver, but never succeed, given that modules would only be loaded after the deferred probe work completes. Two changes are required to avoid this issue: * Move of_find_mipi_dsi_host_by_node(), which can defer probe, to before anx7625_register_i2c_dummy_clients() and devm_of_dp_aux_populate_ep_devices(), which register devices. * Make use of the done_probing callback when populating the aux bus, so that the bridge registration is only done after the panel is probed. This is required because the panel might need to defer probe, but the aux bus population needs the i2c dummy devices working, so this call couldn't just be moved to an earlier point in probe. One caveat is that if the panel is described outside the aux bus, the probe loop issue can still happen, but we don't have a way to avoid it in that case since there's no callback available. With this patch applied, it's possible to boot on mt8192-asurada-spherion with CONFIG_DRM_ANALOGIX_ANX7625=y CONFIG_MTK_MMSYS=m CONFIG_BACKLIGHT_PWM=y and also with CONFIG_DRM_ANALOGIX_ANX7625=y CONFIG_MTK_MMSYS=y CONFIG_BACKLIGHT_PWM=m Fixes: adca62ec370c ("drm/bridge: anx7625: Support reading edid through aux channel") Fixes: 269332997a16 ("drm/bridge: anx7625: Return -EPROBE_DEFER if the dsi host was not found") Reported-by: "kernelci.org bot" <bot@kernelci.org> Signed-off-by: Nícolas F. R. A. Prado <nfraprado@collabora.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230518193902.891121-1-nfraprado@collabora.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: anx7625: Convert to i2c's .probe_new()Uwe Kleine-König1-3/+2
[ Upstream commit 71450f8c824f5571d4af9e6e021b733085c8e690 ] The probe function doesn't make use of the i2c_device_id * parameter so it can be trivially converted. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Link: https://lore.kernel.org/r/20221118224540.619276-18-uwe@kleine-koenig.org Signed-off-by: Robert Foss <robert.foss@linaro.org> Stable-dep-of: 1464e48d69ab ("drm/bridge: anx7625: Prevent endless probe loop") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/msm/dpu: Set DPU_DATA_HCTL_EN for in INTF_SC7180_MASKKonrad Dybcio1-2/+5
[ Upstream commit a7129231edf329a00e92dbd2d741f6da728a4a06 ] DPU5 and newer targets enable this unconditionally. Move it from the SC7280 mask to the SC7180 one. Fixes: 7e6ee55320f0 ("drm/msm/disp/dpu1: enable DATA_HCTL_EN for sc7280 target") Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Patchwork: https://patchwork.freedesktop.org/patch/538159/ Link: https://lore.kernel.org/r/20230508-topic-hctl_en-v2-1-e7bea9f1f5dd@linaro.org [DB: removed BIT(DPU_INTF_DATA_COMPRESS), which is not yet merged] Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/msm/disp/dpu: get timing engine status from intf status registerVinod Polimera3-7/+16
[ Upstream commit e3969eadc8ee78a5bdca65b8ed0a421a359e4090 ] Recommended way of reading the interface timing gen status is via status register. Timing gen status register will give a reliable status of the interface especially during ON/OFF transitions. This support was added from DPU version 5.0.0. Signed-off-by: Vinod Polimera <quic_vpolimer@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Patchwork: https://patchwork.freedesktop.org/patch/524724/ Link: https://lore.kernel.org/r/1677774797-31063-6-git-send-email-quic_vpolimer@quicinc.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Stable-dep-of: a7129231edf3 ("drm/msm/dpu: Set DPU_DATA_HCTL_EN for in INTF_SC7180_MASK") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/msm/dsi: don't allow enabling 14nm VCO with unprogrammed rateDmitry Baryshkov1-0/+3
[ Upstream commit 1e0a97f84d73ea1182740f62069690c7f3271abb ] If the dispcc uses CLK_OPS_PARENT_ENABLE (e.g. on QCM2290), CCF can try enabling VCO before the rate has been programmed. This can cause clock lockups and/or other boot issues. Program the VCO to the minimal PLL rate if the read rate is 0 Hz. Cc: Konrad Dybcio <konrad.dybcio@linaro.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reported-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Reported-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Fixes: f079f6d999cb ("drm/msm/dsi: Add PHY/PLL for 8x96") Patchwork: https://patchwork.freedesktop.org/patch/534813/ Link: https://lore.kernel.org/r/20230501011257.3460103-1-dmitry.baryshkov@linaro.org Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358767: Switch to devm MIPI-DSI helpersAlexander Stein1-2/+2
[ Upstream commit f47d6140b7a4c858d82d263e7577ff6fb5279a9c ] DSI device registering and attaching needs to be undone upon deregistration. This fixes module unload/load. Fixes: bbfd3190b656 ("drm/bridge: tc358767: Add DSI-to-DPI mode support") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230517122107.1766673-1-alexander.stein@ew.tq-group.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/vkms: Fix RGB565 pixel conversionMaíra Canal1-6/+6
[ Upstream commit ab87f558dcfb2562c3497e89600dec798a446665 ] Currently, the pixel conversion isn't rounding the fixed-point values before assigning it to the RGB coefficients, which is causing the IGT pixel-format tests to fail. So, use the drm_fixp2int_round() fixed-point helper to round the values when assigning it to the RGB coefficients. Tested with igt@kms_plane@pixel-format and igt@kms_plane@pixel-format-source-clamping. [v2]: * Use drm_fixp2int_round() to fix the pixel conversion instead of casting the values to s32 (Melissa Wen). Fixes: 89b03aeaef16 ("drm/vkms: fix 32bit compilation error by replacing macros") Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Arthur Grillo <arthurgrillo@riseup.net> Signed-off-by: Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230512104044.65034-2-mcanal@igalia.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/vkms: isolate pixel conversion functionalityMaíra Canal5-81/+56
[ Upstream commit 322d716a3e8a74fb75cd0f657647be4df253fd2f ] Currently, the pixel conversion functions repeat the same loop to iterate the rows. Instead of repeating the same code for each pixel format, create a function to wrap the loop and isolate the pixel conversion functionality. Suggested-by: Arthur Grillo <arthurgrillo@riseup.net> Signed-off-by: Maíra Canal <mcanal@igalia.com> Reviewed-by: Arthur Grillo <arthurgrillo@riseup.net> Signed-off-by: Maíra Canal <mairacanal@riseup.net> Link: https://patchwork.freedesktop.org/patch/msgid/20230418130525.128733-2-mcanal@igalia.com Stable-dep-of: ab87f558dcfb ("drm/vkms: Fix RGB565 pixel conversion") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/panel: sharp-ls043t1le01: adjust mode settingsDmitry Baryshkov1-5/+6
[ Upstream commit dee23b2c9e3ff46d59c5d45e1436eceb878e7c9a ] Using current settings causes panel flickering on APQ8074 dragonboard. Adjust panel settings to follow the vendor-provided mode. This also enables MIPI_DSI_MODE_VIDEO_SYNC_PULSE, which is also specified by the vendor dtsi for the mentioned dragonboard. Fixes: ee0172383190 ("drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230507172639.2320934-1-dmitry.baryshkov@linaro.org Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm: sun4i_tcon: use devm_clk_get_enabled in `sun4i_tcon_init_clocks`XuDong Liu1-15/+4
[ Upstream commit 123ee07ba5b7123e0ce0e0f9d64938026c16a2ce ] Smatch reports: drivers/gpu/drm/sun4i/sun4i_tcon.c:805 sun4i_tcon_init_clocks() warn: 'tcon->clk' from clk_prepare_enable() not released on lines: 792,801. In the function sun4i_tcon_init_clocks(), tcon->clk and tcon->sclk0 are not disabled in the error handling, which affects the release of these variable. Although sun4i_tcon_bind(), which calls sun4i_tcon_init_clocks(), use sun4i_tcon_free_clocks to disable the variables mentioned, but the error handling branch of sun4i_tcon_init_clocks() ignores the required disable process. To fix this issue, use the devm_clk_get_enabled to automatically balance enable and disabled calls. As original implementation use sun4i_tcon_free_clocks() to disable clk explicitly, we delete the related calls and error handling that are no longer needed. Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Fixes: b14e945bda8a ("drm/sun4i: tcon: Prepare and enable TCON channel 0 clock at init") Fixes: 8e9240472522 ("drm/sun4i: support TCONs without channel 1") Fixes: 34d698f6e349 ("drm/sun4i: Add has_channel_0 TCON quirk") Signed-off-by: XuDong Liu <m202071377@hust.edu.cn> Reviewed-by: Dongliang Mu <dzm91@hust.edu.cn> Signed-off-by: Maxime Ripard <maxime@cerno.tech> Link: https://patchwork.freedesktop.org/patch/msgid/20230430112347.4689-1-m202071377@hust.edu.cn Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/vram-helper: fix function names in vram helper docLuc Ma1-3/+3
[ Upstream commit b8e392245105b50706f18418054821e71e637288 ] Refer to drmm_vram_helper_init() instead of the non-existent drmm_vram_helper_alloc_mm(). Fixes: a5f23a72355d ("drm/vram-helper: Managed vram helpers") Signed-off-by: Luc Ma <luc@sietium.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/64583db2.630a0220.eb75d.8f51@mx.google.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358768: fix THS_TRAILCNT computationFrancesco Dolcini1-3/+4
[ Upstream commit bac7842cd179572e8e0fc2d7b5254e40c6e9e057 ] Correct computation of THS_TRAILCNT register. This register must be set to a value that ensure that THS_TRAIL > 60 ns + 4 x UI and THS_TRAIL > 8 x UI and THS_TRAIL < TEOT with TEOT = 105 ns + (12 x UI) with the actual value of THS_TRAIL being (1 + THS_TRAILCNT) x ByteClk cycle + ((1 to 2) + 2) xHSBYTECLK cycle + - (PHY output delay) with PHY output delay being about (8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-9-francesco@dolcini.it Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358768: fix TXTAGOCNT computationFrancesco Dolcini1-1/+1
[ Upstream commit 3666aad8185af8d0ce164fd3c4974235417d6d0b ] Correct computation of TXTAGOCNT register. This register must be set to a value that ensure that the TTA-GO period = (4 x TLPX) with the actual value of TTA-GO being 4 x (TXTAGOCNT + 1) x (HSByteClk cycle) Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-8-francesco@dolcini.it Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358768: fix THS_ZEROCNT computationFrancesco Dolcini1-3/+4
[ Upstream commit 77a089328da791118af9692543a5eedc79eb5fd4 ] Correct computation of THS_ZEROCNT register. This register must be set to a value that ensure that THS_PREPARE + THS_ZERO > 145ns + 10*UI with the actual value of (THS_PREPARE + THS_ZERO) being ((1 to 2) + 1 + (TCLK_ZEROCNT + 1) + (3 to 4)) x ByteClk cycle + + HSByteClk x (2 + (1 to 2)) + (PHY delay) with PHY delay being about (8 + (5 to 6)) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-7-francesco@dolcini.it Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358768: fix TCLK_TRAILCNT computationFrancesco Dolcini1-3/+5
[ Upstream commit ee18698e212b1659dd0850d7e2ae0f22e16ed3d3 ] Correct computation of TCLK_TRAILCNT register. The driver does not implement non-continuous clock mode, so the actual value doesn't make a practical difference yet. However this change also ensures that the value does not write to reserved registers bits in case of under/overflow. This register must be set to a value that ensures that TCLK-TRAIL > 60ns and TEOT <= (105 ns + 12 x UI) with the actual value of TCLK-TRAIL being (TCLK_TRAILCNT + (1 to 2)) xHSByteClkCycle + (2 + (1 to 2)) * HSBYTECLKCycle - (PHY output delay) with PHY output delay being about (2 to 3) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-2-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-3-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-4-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-5-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-2-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-3-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-4-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-5-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-2-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-3-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-4-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-5-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-2-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-3-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-4-francesco@dolcini.it Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-5-francesco@dolcini.it Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358768: Add atomic_get_input_bus_fmts() implementationFrancesco Dolcini1-0/+44
[ Upstream commit cec5ccef85bd0128cf895612de54a9d21d2015d0 ] Add atomic_get_input_bus_fmts() implementation, tc358768 has a parallel RGB input interface with the actual bus format depending on the amount of parallel input data lines. Without this change when the tc358768 is used with less than 24bit the color mapping is completely wrong. Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230330095941.428122-7-francesco@dolcini.it Stable-dep-of: ee18698e212b ("drm/bridge: tc358768: fix TCLK_TRAILCNT computation") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358768: fix TCLK_ZEROCNT computationFrancesco Dolcini1-4/+4
[ Upstream commit f9cf811374f42fca31ac34aaf59ee2ae72b89879 ] Correct computation of TCLK_ZEROCNT register. This register must be set to a value that ensure that (TCLK-PREPARECNT + TCLK-ZERO) > 300ns with the actual value of (TCLK-PREPARECNT + TCLK-ZERO) being (1 to 2) + (TCLK_ZEROCNT + 1)) x HSByteClkCycle + (PHY output delay) with PHY output delay being about (2 to 3) x MIPIBitClk cycle in the BitClk conversion. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-5-francesco@dolcini.it Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358768: fix PLL target frequencyFrancesco Dolcini1-3/+5
[ Upstream commit ffd2e4bbea626d565b9817312b0fcfb382fecb88 ] Correctly compute the PLL target frequency, the current formula works correctly only when the input bus width is 24bit, actually to properly compute the PLL target frequency what is relevant is the bits-per-pixel on the DSI link. No regression expected since the DSI format is currently hard-coded as MIPI_DSI_FMT_RGB888. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-4-francesco@dolcini.it Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358768: fix PLL parameters computationFrancesco Dolcini1-1/+5
[ Upstream commit 6a4020b4c63911977aaf8047f904a300d15de739 ] According to Toshiba documentation the PLL input clock after the divider should be not less than 4MHz, fix the PLL parameters computation accordingly. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-3-francesco@dolcini.it Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: tc358768: always enable HS video modeFrancesco Dolcini1-2/+1
[ Upstream commit 75a8aeac2573ab258c53676eba9b3796ea691988 ] Always enable HS video mode setting the TXMD bit, without this change no video output is present with DSI sinks that are setting MIPI_DSI_MODE_LPM flag (tested with LT8912B DSI-HDMI bridge). Previously the driver was enabling HS mode only when the DSI sink was not explicitly setting the MIPI_DSI_MODE_LPM, however this is not correct. The MIPI_DSI_MODE_LPM is supposed to indicate that the sink is willing to receive data in low power mode, however clearing the TC358768_DSI_CONTROL_TXMD bit will make the TC358768 send video in LP mode that is not the intended behavior. Fixes: ff1ca6397b1d ("drm/bridge: Add tc358768 driver") Signed-off-by: Francesco Dolcini <francesco.dolcini@toradex.com> Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230427142934.55435-2-francesco@dolcini.it Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: ti-sn65dsi83: Fix enable error pathAlexander Stein1-0/+1
[ Upstream commit 8a91b29f1f50ce7742cdbe5cf11d17f128511f3f ] If PLL locking failed, the regulator needs to be disabled again. Fixes: 5664e3c907e2 ("drm/bridge: ti-sn65dsi83: Add vcc supply regulator support") Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Robert Foss <rfoss@kernel.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230504065316.2640739-1-alexander.stein@ew.tq-group.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/bridge: it6505: Move a variable assignment behind a null pointer check ↵Markus Elfring1-1/+2
in receive_timing_debugfs_show() [ Upstream commit 0be05a75de2916421e88e0d64b001984f54df0bd ] The address of a data structure member was determined before a corresponding null pointer check in the implementation of the function “receive_timing_debugfs_show”. Thus avoid the risk for undefined behaviour by moving the assignment for the variable “vid” behind the null pointer check. This issue was detected by using the Coccinelle software. Fixes: b5c84a9edcd4 ("drm/bridge: add it6505 driver") Signed-off-by: Markus Elfring <elfring@users.sourceforge.net> Link: https://patchwork.freedesktop.org/patch/msgid/fa69384f-1485-142b-c4ee-3df54ac68a89@web.de Reviewed-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Robert Foss <rfoss@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/amd/display: Explicitly specify update type per plane info changeNicholas Kazlauskas1-3/+0
[ Upstream commit 710cc1e7cd461446a9325c9bd1e9a54daa462952 ] [Why] The bit for flip addr is being set causing the determination for FAST vs MEDIUM to always return MEDIUM when plane info is provided as a surface update. This causes extreme stuttering for the typical atomic update path on Linux. [How] Don't use update_flags->raw for determining FAST vs MEDIUM. It's too fragile to changes like this. Explicitly specify the update type per update flag instead. It's not as clever as checking the bits itself but at least it's correct. Fixes: aa5fdb1ab5b6 ("drm/amd/display: Explicitly specify update type per plane info change") Reviewed-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Nicholas Kazlauskas <nicholas.kazlauskas@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-07-19radeon: avoid double free in ci_dpm_init()Nikita Zhandarovich1-8/+20
[ Upstream commit 20c3dffdccbd494e0dd631d1660aeecbff6775f2 ] Several calls to ci_dpm_fini() will attempt to free resources that either have been freed before or haven't been allocated yet. This may lead to undefined or dangerous behaviour. For instance, if r600_parse_extended_power_table() fails, it might call r600_free_extended_power_table() as will ci_dpm_fini() later during error handling. Fix this by only freeing pointers to objects previously allocated. Found by Linux Verification Center (linuxtesting.org) with static analysis tool SVACE. Fixes: cc8dbbb4f62a ("drm/radeon: add dpm support for CI dGPUs (v2)") Co-developed-by: Natalia Petrova <n.petrova@fintech.ru> Signed-off-by: Nikita Zhandarovich <n.zhandarovich@fintech.ru> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-07-19drm/amd/display: Add logging for display MALL refresh settingWesley Chalmers1-0/+3
[ Upstream commit cd8f067a46d34dee3188da184912ae3d64d98444 ] [WHY] Add log entry for when display refresh from MALL settings are sent to SMU. Fixes: 1664641ea946 ("drm/amd/display: Add logger for SMU msg") Signed-off-by: Wesley Chalmers <Wesley.Chalmers@amd.com> Acked-by: Aurabindo Pillai <aurabindo.pillai@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-07-19drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2Jeff Layton1-1/+1
commit 54d217406afe250d7a768783baaa79a035f21d38 upstream. I've been experiencing some intermittent crashes down in the display driver code. The symptoms are ususally a line like this in dmesg: amdgpu 0000:30:00.0: [drm] Failed to create MST payload for port 000000006d3a3885: -5 ...followed by an Oops due to a NULL pointer dereference. Switch to using mgr->dev instead of state->dev since "state" can be NULL in some cases. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855 Suggested-by: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Jeff Layton <jlayton@kernel.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/20230419112447.18471-1-jlayton@kernel.org Cc: "Limonciello, Mario" <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-05drm/amd/display: Ensure vmin and vmax adjust for DCERodrigo Siqueira1-2/+3
commit 2820433be2a33beb44b13b367e155cf221f29610 upstream. [Why & How] In the commit 32953485c558 ("drm/amd/display: Do not update DRR while BW optimizations pending"), a modification was added to avoid adjusting DRR if optimized bandwidth is set. This change was only intended for DCN, but one part of the patch changed the code path for DCE devices and caused regressions to the kms_vrr test. To address this problem, this commit adds a modification in which dc_stream_adjust_vmin_vmax will be fully executed in DCE devices. Fixes: 32953485c558 ("drm/amd/display: Do not update DRR while BW optimizations pending") Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@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-07-05drm/amdgpu: Validate VM ioctl flags.Bas Nieuwenhuizen1-0/+4
commit a2b308044dcaca8d3e580959a4f867a1d5c37fac upstream. None have been defined yet, so reject anybody setting any. Mesa sets it to 0 anyway. Signed-off-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-05drm/amd/display: Do not update DRR while BW optimizations pendingAric Cyr1-19/+29
commit 32953485c558cecf08f33fbfa251e80e44cef981 upstream. [why] While bandwidth optimizations are pending, it's possible a pstate change will occur. During this time, VSYNC handler should not also try to update DRR parameters causing pstate hang [how] Do not adjust DRR if optimize bandwidth is set. Reviewed-by: Aric Cyr <aric.cyr@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Aric Cyr <aric.cyr@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-07-05drm/amd/display: Remove optimization for VRR updatesAlvin Lee1-3/+0
commit 3442f4e0e55555d14b099c17382453fdfd2508d5 upstream. Optimization caused unexpected regression, so remove for now. Tested-by: Mark Broadworth <mark.broadworth@amd.com> Reviewed-by: Aric Cyr <Aric.Cyr@amd.com> Acked-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Signed-off-by: Alvin Lee <Alvin.Lee2@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-28drm/radeon: fix race condition UAF in radeon_gem_set_domain_ioctlMin Li1-3/+1
[ Upstream commit 982b173a6c6d9472730c3116051977e05d17c8c5 ] Userspace can race to free the gobj(robj converted from), robj should not be accessed again after drm_gem_object_put, otherwith it will result in use-after-free. Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Min Li <lm0963hack@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-28drm/exynos: fix race condition UAF in exynos_g2d_exec_ioctlMin Li1-1/+1
[ Upstream commit 48bfd02569f5db49cc033f259e66d57aa6efc9a3 ] If it is async, runqueue_node is freed in g2d_runqueue_worker on another worker thread. So in extreme cases, if g2d_runqueue_worker runs first, and then executes the following if statement, there will be use-after-free. Signed-off-by: Min Li <lm0963hack@gmail.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Inki Dae <inki.dae@samsung.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-28drm/exynos: vidi: fix a wrong error returnInki Dae1-2/+0
[ Upstream commit 4a059559809fd1ddbf16f847c4d2237309c08edf ] Fix a wrong error return by dropping an error return. When vidi driver is remvoed, if ctx->raw_edid isn't same as fake_edid_info then only what we have to is to free ctx->raw_edid so that driver removing can work correctly - it's not an error case. Signed-off-by: Inki Dae <inki.dae@samsung.com> Reviewed-by: Andi Shyti <andi.shyti@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-28drm/amd/display: fix the system hang while disable PSRTom Chung1-4/+6
[ Upstream commit ea2062dd1f0384ae1b136d333ee4ced15bedae38 ] [Why] When the PSR enabled. If you try to adjust the timing parameters, it may cause system hang. Because the timing mismatch with the DMCUB settings. [How] Disable the PSR before adjusting timing parameters. 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: Tom Chung <chiahsuan.chung@amd.com> Reviewed-by: Wayne Lin <Wayne.Lin@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-06-28drm/amd/display: Add wrapper to call planes and stream updateRodrigo Siqueira1-10/+41
[ Upstream commit 81f743a08f3b214638aa389e252ae5e6c3592e7c ] [Why & How] This commit is part of a sequence of changes that replaces the commit sequence used in the DC with a new one. As a result of this transition, we moved some specific parts from the commit sequence and brought them to amdgpu_dm. This commit adds a wrapper inside DM that enable our drivers to do any necessary preparation or change before we offload the plane/stream update to DC. Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: ea2062dd1f03 ("drm/amd/display: fix the system hang while disable PSR") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-28drm/amd/display: Use dc_update_planes_and_streamRodrigo Siqueira1-15/+15
[ Upstream commit f7511289821ffccc07579406d6ab520aa11049f5 ] [Why & How] The old dc_commit_updates_for_stream lacks manipulation for many corner cases where the DC feature requires special attention; as a result, it starts to show its limitation (e.g., the SubVP feature is not supported by it, among other cases). To modernize and unify our internal API, this commit replaces the old dc_commit_updates_for_stream with dc_update_planes_and_stream, which has more features. Reviewed-by: Harry Wentland <Harry.Wentland@amd.com> Acked-by: Qingqing Zhuo <qingqing.zhuo@amd.com> Signed-off-by: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com> Tested-by: Daniel Wheeler <daniel.wheeler@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Stable-dep-of: ea2062dd1f03 ("drm/amd/display: fix the system hang while disable PSR") Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21drm/amdgpu: Don't set struct drm_driver.output_poll_changedThomas Zimmermann2-3/+0
commit 0e3172bac3f43759719384403fe2d1e4c61f87e0 upstream. Don't set struct drm_driver.output_poll_changed. It's used to restore the fbdev console. But as amdgpu uses generic fbdev emulation, the console is being restored by the DRM client helpers already. See the functions drm_kms_helper_hotplug_event() and drm_kms_helper_connector_hotplug_event() in drm_probe_helper.c. v2: * fix commit description (Christian) Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Javier Martinez Canillas <javierm@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20221103151446.2638-5-tzimmermann@suse.de Cc: "Gagniuc, Alexandru" <alexandru.gagniuc@hp.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-21drm/nouveau: add nv_encoder pointer check for NULLNatalia Petrova1-1/+2
[ Upstream commit 55b94bb8c42464bad3d2217f6874aa1a85664eac ] Pointer nv_encoder could be dereferenced at nouveau_connector.c in case it's equal to NULL by jumping to goto label. This patch adds a NULL-check to avoid it. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 3195c5f9784a ("drm/nouveau: set encoder for lvds") Signed-off-by: Natalia Petrova <n.petrova@fintech.ru> Reviewed-by: Lyude Paul <lyude@redhat.com> [Fixed patch title] Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512103320.82234-1-n.petrova@fintech.ru Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21drm/nouveau/dp: check for NULL nv_connector->native_modeNatalia Petrova1-2/+2
[ Upstream commit 20a2ce87fbaf81e4c3dcb631d738e423959eb320 ] Add checking for NULL before calling nouveau_connector_detect_depth() in nouveau_connector_get_modes() function because nv_connector->native_mode could be dereferenced there since connector pointer passed to nouveau_connector_detect_depth() and the same value of nv_connector->native_mode is used there. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: d4c2c99bdc83 ("drm/nouveau/dp: remove broken display depth function, use the improved one") Signed-off-by: Natalia Petrova <n.petrova@fintech.ru> Reviewed-by: Lyude Paul <lyude@redhat.com> Signed-off-by: Lyude Paul <lyude@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230512111526.82408-1-n.petrova@fintech.ru Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21drm/bridge: ti-sn65dsi86: Avoid possible buffer overflowSu Hui1-0/+4
[ Upstream commit 95011f267c44a4d1f9ca1769e8a29ab2c559e004 ] Smatch error:buffer overflow 'ti_sn_bridge_refclk_lut' 5 <= 5. Fixes: cea86c5bb442 ("drm/bridge: ti-sn65dsi86: Implement the pwm_chip") Signed-off-by: Su Hui <suhui@nfschina.com> Reviewed-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20230608012443.839372-1-suhui@nfschina.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21drm/nouveau: don't detect DSM for non-NVIDIA deviceRatchanan Srirattanamet1-0/+3
[ Upstream commit 11d24327c2d7ad7f24fcc44fb00e1fa91ebf6525 ] The call site of nouveau_dsm_pci_probe() uses single set of output variables for all invocations. So, we must not write anything to them unless it's an NVIDIA device. Otherwise, if we are called with another device after the NVIDIA device, we'll clober the result of the NVIDIA device. For example, if the other device doesn't have _PR3 resources, the detection later would miss the presence of power resource support, and the rest of the code will keep using Optimus DSM, breaking power management for that machine. Also, because we're detecting NVIDIA's DSM, it doesn't make sense to run this detection on a non-NVIDIA device anyway. Thus, check at the beginning of the detection code if this is an NVIDIA card, and just return if it isn't. This, together with commit d22915d22ded ("drm/nouveau/devinit/tu102-: wait for GFW_BOOT_PROGRESS == COMPLETED") developed independently and landed earlier, fixes runtime power management of the NVIDIA card in Lenovo Legion 5-15ARH05. Without this patch, the GPU resumption code will "timeout", sometimes hanging userspace. As a bonus, we'll also stop preventing _PR3 usage from the bridge for unrelated devices, which is always nice, I guess. Fixes: ccfc2d5cdb02 ("drm/nouveau: Use generic helper to check _PR3 presence") Signed-off-by: Ratchanan Srirattanamet <peathot@hotmail.com> Closes: https://gitlab.freedesktop.org/drm/nouveau/-/issues/79 Reviewed-by: Karol Herbst <kherbst@redhat.com> Signed-off-by: Karol Herbst <kherbst@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/DM6PR19MB2780805D4BE1E3F9B3AC96D0BC409@DM6PR19MB2780.namprd19.prod.outlook.com Signed-off-by: Sasha Levin <sashal@kernel.org>
2023-06-21drm/amdgpu: add missing radeon secondary PCI IDAlex Deucher1-0/+1
commit e61f67749b351c19455ce3085af2ae9af80023bc upstream. 0x5b70 is a missing RV370 secondary id. Add it so we don't try and probe it with amdgpu. Cc: michel@daenzer.net Reviewed-by: Michel Dänzer <mdaenzer@redhat.com> Tested-by: Michel Dänzer <mdaenzer@redhat.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-06-21drm/amd/pm: workaround for compute workload type on some skusKenneth Feng1-2/+31
commit 7ca302d488f80cf4529620acc1c545f9022d8bb8 upstream. On smu 13.0.0, the compute workload type cannot be set on all the skus due to some other problems. This workaround is to make sure compute workload type can also run on some specific skus. v2: keep the variable consistent Signed-off-by: Kenneth Feng <kenneth.feng@amd.com> Acked-by: Lijo Lazar <lijo.lazar@amd.com> Reviewed-by: Feifei Xu <Feifei.Xu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-21drm/amd: Tighten permissions on VBIOS flashing attributesMario Limonciello1-2/+2
commit 7ab1a4913d0051cf5196ef7987b5fa42c25e13b6 upstream. Non-root users shouldn't be able to try to trigger a VBIOS flash or query the flashing status. This should be reserved for users with the appropriate permissions. Cc: stable@vger.kernel.org Fixes: 8424f2ccb3c0 ("drm/amdgpu/psp: Add vbflash sysfs interface support") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-21drm/amd: Make sure image is written to trigger VBIOS image update flowMario Limonciello1-0/+3
commit 3eb1a3a04056ba3df3205e169b8acc9da0c65a94 upstream. The VBIOS image update flow requires userspace to: 1) Write the image to `psp_vbflash` 2) Read `psp_vbflash` 3) Poll `psp_vbflash_status` to check for completion If userspace reads `psp_vbflash` before writing an image, it's possible that it causes problems that can put the dGPU into an invalid state. Explicitly check that an image has been written before letting a read succeed. Cc: stable@vger.kernel.org Fixes: 8424f2ccb3c0 ("drm/amdgpu/psp: Add vbflash sysfs interface support") Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-21drm/amd/display: edp do not add non-edid timingsHersen Wu1-1/+7
commit e749dd10e5f292061ad63d2b030194bf7d7d452c upstream. [Why] most edp support only timings from edid. applying non-edid timings, especially those timings out of edp bandwidth, may damage edp. [How] do not add non-edid timings for edp. 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: Hersen Wu <hersenxs.wu@amd.com> Reviewed-by: Roman Li <roman.li@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-06-21drm/amdgpu: vcn_4_0 set instance 0 init sched score to 1Sonny Jiang1-1/+5
commit 9db5ec1ceb5303398ec4f899d691073d531257c3 upstream. Only vcn0 can process AV1 codecx. In order to use both vcn0 and vcn1 in h264/265 transcode to AV1 cases, set vcn0 sched score to 1 at initialization time. Signed-off-by: Sonny Jiang <sonjiang@amd.com> Reviewed-by: Leo Liu <leo.liu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org # 6.1.x Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-21nouveau: fix client work fence deletion raceDave Airlie1-4/+10
commit c8a5d5ea3ba6a18958f8d76430e4cd68eea33943 upstream. This seems to have existed for ever but is now more apparant after commit 9bff18d13473 ("drm/ttm: use per BO cleanup workers") My analysis: two threads are running, one in the irq signalling the fence, in dma_fence_signal_timestamp_locked, it has done the DMA_FENCE_FLAG_SIGNALLED_BIT setting, but hasn't yet reached the callbacks. The second thread in nouveau_cli_work_ready, where it sees the fence is signalled, so then puts the fence, cleanups the object and frees the work item, which contains the callback. Thread one goes again and tries to call the callback and causes the use-after-free. Proposed fix: lock the fence signalled check in nouveau_cli_work_ready, so either the callbacks are done or the memory is freed. Reviewed-by: Karol Herbst <kherbst@redhat.com> Fixes: 11e451e74050 ("drm/nouveau: remove fence wait code from deferred client work handler") Cc: stable@vger.kernel.org Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://lore.kernel.org/dri-devel/20230615024008.1600281-1-airlied@gmail.com/ Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2023-06-21drm:amd:amdgpu: Fix missing buffer object unlock in failure pathSukrut Bellary2-2/+6
[ Upstream commit 60ecaaf54886b0642d5c4744f7fbf1ff0d6b3e42 ] smatch warning - 1) drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c:3615 gfx_v9_0_kiq_resume() warn: inconsistent returns 'ring->mqd_obj->tbo.base.resv'. 2) drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c:6901 gfx_v10_0_kiq_resume() warn: inconsistent returns 'ring->mqd_obj->tbo.base.resv'. Signed-off-by: Sukrut Bellary <sukrut.bellary@linux.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>