- 03 Jun, 2024 3 commits
-
-
Ryan Walklin authored
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display from an unknown OEM used in a number of handheld gaming devices made by Anbernic. Limited information is available online however the panel timing values (below) have been obtained from the vendor BSP. The panel appears to integrate a NV3052C LCD driver (or clone). Available devices address it in SPI/RGB mode, with the timing signals generated from the device SoC (Allwinner H700) and passed through. Add a panel definition and display mode to the existing NV3502C driver. It was assumed during bringup that the initialisation sequence was the same as the existing Fascontek FS035VG158 panel, proved working during experimentation, however subsequent dumping of the init sequence with a logic analyser confirms one small change to VCOM_ADJ3 from 0x4a to 0x44, therefore a separate set of registers is also added. Timings: | Active | FP | Sync | BP | Total -----------|--------|------|------|------|------- Horizontal | 640 | 64 | 20 | 46 | 770 Vertical | 480 | 21 | 4 | 15 | 520 Signed-off-by:Ryan Walklin <ryan@testtoast.com> Co-developed-by:
Hironori KIKUCHI <kikuchan98@gmail.com> Signed-off-by:
John Watts <contact@jookia.org> Reviewed-by:
Neil Armstrong <neil.armstrong@linaro.org> Acked-by:
Jessica Zhang <quic_jesszhan@quicinc.com> Link: https://lore.kernel.org/r/20240530211415.44201-4-ryan@testtoast.comSigned-off-by:
-
Ryan Walklin authored
The WL-355608-A8 is a 3.5" 640x480@60Hz RGB LCD display used in a number of handheld gaming devices made by Anbernic. By consensus a vendor prefix is not provided as the panel OEM is unknown. Add a device tree binding for the panel. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Link: https://lore.kernel.org/r/20240530211415.44201-3-ryan@testtoast.comSigned-off-by:
-
Sam Ravnborg authored
Drop myself as reviewer of panel patches, to reflect the reality. Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Neil Armstrong <neil.armstrong@linaro.org> Acked-by:
-
- 31 May, 2024 1 commit
-
-
Christian König authored
When dma_resv_reserve_fences() is called with num_fences=0 it usually means that a driver or other component messed up its calculation how many fences are needed. Warn in that situation. When no fence are needed the function shouldn't be called in the first place. Signed-off-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240529084322.2284-1-christian.koenig@amd.comReviewed-by:
Matthew Auld <matthew.auld@intel.com>
-
- 30 May, 2024 9 commits
-
-
Dmitry Baryshkov authored
In order to validate drm/msm register definition files against schema, reuse the nodebugfs build step. The validation entry is guarded by the EXPERT Kconfig option and we don't want to enable that option for all the builds. Reviewed-by:
Abhinav Kumar <quic_abhinavk@quicinc.com> Acked-by:
Helen Koike <helen.koike@collabora.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240503-fd-fix-lxml-v2-2-f80a60ce21a1@linaro.orgSigned-off-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
-
Manikandan Muralidharan authored
Add the LCD controller layer definition and descriptor structure for sam9x75 for the following layers: - Base Layer - Overlay1 Layer - Overlay2 Layer - High End Overlay Signed-off-by:
Manikandan Muralidharan <manikandan.m@microchip.com> Acked-by:
-
Manikandan Muralidharan authored
Add support for the following DPI mode if the encoder type is DSI as per the XLCDC IP datasheet: - 16BPPCFG1 - 16BPPCFG2 - 16BPPCFG3 - 18BPPCFG1 - 18BPPCFG2 - 24BPP Signed-off-by:
Durai Manickam KR <durai.manickamkr@microchip.com> Acked-by:
-
Manikandan Muralidharan authored
Update the vertical and horizontal scaler registers of XLCDC IP with Bilinear and Bicubic co-efficients taps for Chroma and Luma componenets of the Pixel. Signed-off-by:
-
Manikandan Muralidharan authored
Add support for Display Pixel Interface (DPI) Compatible Mode support in atmel-hlcdc driver for XLCDC IP along with legacy pixel mapping. DPI mode BIT is configured in LCDC_CFG5 register. Signed-off-by:
-
Manikandan Muralidharan authored
Add XLCDC specific driver ops and is_xlcdc flag to separate the functionality and to access the controller registers. HEO scaling, window resampling, Alpha blending, YUV-to-RGB conversion in XLCDC is derived and handled using additional configuration bits and registers. Writing one to the Enable fields of each layer in LCD_ATTRE is required to reflect the values set in Configuration, FBA, Enable registers of each layer. Signed-off-by:
Hari Prasath Gujulan Elango <Hari.PrasathGE@microchip.com> Signed-off-by:
-
Manikandan Muralidharan authored
Replace regmap_read with regmap_read_poll_timeout to neatly handle retries Signed-off-by:
Dharma Balasubiramani <dharma.b@microchip.com> Reviewed-by:
-
Durai Manickam KR authored
The register address of the XLCDC IP used in SAM9X7 SoC family are different from the previous HLCDC. Defining those address space with valid macros. Signed-off-by:
Lee Jones <lee@kernel.org> Acked-by:
-
Manikandan Muralidharan authored
Add LCD IP specific ops in driver data to differentiate HLCDC and XLCDC code within the atmel-hlcdc driver files. XLCDC in SAM9X7 has different sets of registers and additional configuration bits when compared to previous HLCDC IP. Read/write operation on the controller register and functionality is now separated using the LCD IP specific ops. Signed-off-by:
-
- 29 May, 2024 2 commits
-
-
Maxime Ripard authored
During the life of the series that introduced the DRM_DISPLAY_HDMI_STATE_HELPER option, we reworked the Kconfig option dependency setup to rely on depends on with commit f6d2dc03 ("drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on") which got reverted later on because it was creating too many issues by commit d7c128cb ("Revert "drm: Switch DRM_DISPLAY_HDMI_HELPER to depends on""). However, since the series was out of tree at that time, DRM_DISPLAY_HDMI_STATE_HELPER wasn't properly updated to take the revert into account and is now creating build issues. Let's switch the depends on to a select to fix this. Reported-by:
kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202405290332.Sqtt0ix0-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405290438.TOYhXMIn-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405290803.c3178DYT-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405291109.PQdqc46g-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405291221.a0NStxHE-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202405291636.8GgBtK8u-lkp@intel.com/ Fixes: 54cb39e2 ("drm/connector: hdmi: Create an HDMI sub-state") Reviewed-by:
Javier Martinez Canillas <javierm@redhat.com> Reviewed-by:
Maxime Ripard <mripard@kernel.org>
-
Maxime Ripard authored
Commit ea64761a ("drm/sun4i: hdmi: Switch to HDMI connector") introduced a dependency that got renamed in a previous version, but wasn't properly updated in that driver. Fix the name of the function. Reported-by:
-
- 28 May, 2024 25 commits
-
-
Pin-yen Lin authored
Same as commit 7c8690d8 ("drm/panel-edp: Add some panels with conservative timings"), the 3 panels added in this patch are used by Mediatek MT8173 Chromebooks and they used to work with the downstream v4.19 kernel without any specified delay. These panel IDs were found from in-field reports, but their datahseets are not available. For BOE 0x0623 and SHP 0x153a, their product names are retrieved from the EDIDs. The EDID of AUO 0x1999 does not contain such information, so list as "Unknown" in this patch. Update these entries with less-conservative timings from other panels of the same vendor. Signed-off-by:
Pin-yen Lin <treapking@chromium.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Signed-off-by:
-
Pin-yen Lin authored
Add support for the following models: AUO B140HTN02.0 BOE NT116WHM-N21 V4.1 BOE NT116WHM-N21 Signed-off-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by TI OMAP boards. The TI OMAP driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. The acx565akm seems to do some unique stuff with the "enabled" state. Specifically: 1. It seems to detect the enabled state based on how the bootloader left the panel. 2. It uses the enabled state to prevent certain sysfs files from accessing a disabled panel. We'll leave the "enabled" state tracking for this. However, we can at least get rid of the double-check when trying to disable. Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Sebastian Reichel <sebastian.reichel@collabora.com> Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. The compatible strings used by this driver seem to show up across boards using a variety of DRM drivers. It appears that the relevant drivers have been converted, but at least one compatible string doesn't seem to be found in any mainline dts files so we can't be 100% sure. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Guido Günther <agx@sigxcpu.org> Cc: Ondřej Jirman <megi@xff.cz> Cc: Chris Morgan <macromorgan@hotmail.com> Cc: Frank Oltmanns <frank@oltmanns.dev> Acked-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. One thing to note for st7703 is that it has a special "allpixelson" debugfs file. When this file is written the driver hacks a disable/unprepare and then a prepare/enable to try to reset the panel. Potentially that might have been relying on the old booleans we removed. It'll still "work" because of the checks in the core but it deserves a comment. This debugfs file didn't appear to be particularly safe to use even before this patch since it would cause a disabled/unprepared panel to become prepared/enabled. Cc: Guido Günther <agx@sigxcpu.org> Cc: Ondřej Jirman <megi@xff.cz> Cc: Chris Morgan <macromorgan@hotmail.com> Cc: Frank Oltmanns <frank@oltmanns.dev> Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Rockchip boards. The Rockchip driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.orgAcked-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, it's very difficult to know exactly which DRM modeset drivers are using panel-simple due to the sheer number of panels it handles. For now, we'll leave the calls and just add a comment to keep people from copying this code. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.orgAcked-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Acked-by:
Sui Jingfeng <sui.jingfeng@linux.dev> Signed-off-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Qualcomm boards. The Qualcomm driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.orgAcked-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Qualcomm boards. The Qualcomm driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Benni Steini <bennisteinir@gmail.com> Cc: Marijn Suijten <marijn.suijten@somainline.org> Acked-by:
Joel Selvaraj <jo@jsfamily.in> Signed-off-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Benni Steini <bennisteinir@gmail.com> Cc: Marijn Suijten <marijn.suijten@somainline.org> Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.orgAcked-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, grepping mainline for this panel's compatible string shows no hits, so we can't be 100% sure if the DRM modeset driver used with this panel has been fixed. If it is found that the DRM modeset driver hasn't been fixed then this patch could be temporarily reverted until it is. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.orgAcked-by:
Quentin Schulz <quentin.schulz@cherry.de> Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # RK3399 Puma with Haikou Video Demo Tested-by: Quentin Schulz <quentin.schulz@cherry.de> # PX30 Ringneck with Haikou Video Demo Signed-off-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Rockchip boards. The Rockchip driver appear to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Brian Norris <briannorris@chromium.org> Cc: Chris Zhong <zyw@rock-chips.com> Cc: Nickey Yang <nickey.yang@rock-chips.com> Acked-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Brian Norris <briannorris@chromium.org> Cc: Chris Zhong <zyw@rock-chips.com> Cc: Nickey Yang <nickey.yang@rock-chips.com> Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Rockchip boards. The Rockchip driver appears to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Chris Zhong <zyw@rock-chips.com> Cc: Lin Huang <hl@rock-chips.com> Cc: Brian Norris <briannorris@chromium.org> Acked-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Cc: Chris Zhong <zyw@rock-chips.com> Cc: Lin Huang <hl@rock-chips.com> Cc: Brian Norris <briannorris@chromium.org> Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. Unfortunately, it's very difficult to know exactly which DRM modeset drivers are using panel-edp due to the sheer number of panels it handles. For now, we'll leave the calls and just add a comment to keep people from copying this code. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.orgAcked-by:
-
Douglas Anderson authored
As talked about in commit d2aacaf0 ("drm/panel: Check for already prepared/enabled in drm_panel"), we want to remove needless code from panel drivers that was storing and double-checking the prepared/enabled state. Even if someone was relying on the double-check before, that double-check is now in the core and not needed in individual drivers. Acked-by:
-
Douglas Anderson authored
It's the responsibility of a correctly written DRM modeset driver to call drm_atomic_helper_shutdown() at shutdown time and that should be disabling / unpreparing the panel if needed. Panel drivers shouldn't be calling these functions themselves. A recent effort was made to fix as many DRM modeset drivers as possible [1] [2] [3] and most drivers are fixed now. A grep through mainline for compatible strings used by this driver indicates that it is used by Mediatek and Qualcomm boards. Both of those drivers appear to be correctly calling drm_atomic_helper_shutdown() so we can remove the calls. [1] https://lore.kernel.org/r/20230901234015.566018-1-dianders@chromium.org [2] https://lore.kernel.org/r/20230901234202.566951-1-dianders@chromium.org [3] https://lore.kernel.org/r/20230921192749.1542462-1-dianders@chromium.org Cc: Jitao Shi <jitao.shi@mediatek.com> Cc: Cong Yang <yangcong5@huaqin.corp-partner.google.com> Acked-by:
-
