aboutsummaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/panel
AgeCommit message (Collapse)AuthorFilesLines
2024-05-30drm/panel: sitronix-st7789v: fix display size for jt240mhqs_hwt_ek_e3 panelGerald Loacker1-2/+2
This is a portrait mode display. Change the dimensions accordingly. Fixes: 0fbbe96bfa08 ("drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support") Signed-off-by: Gerald Loacker <[email protected]> Acked-by: Jessica Zhang <[email protected]> Link: https://lore.kernel.org/r/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-3-e4821802443d@wolfvision.net Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-3-e4821802443d@wolfvision.net
2024-05-30drm/panel: sitronix-st7789v: tweak timing for jt240mhqs_hwt_ek_e3 panelGerald Loacker1-3/+3
Use the default timing parameters to get a refresh rate of about 60 Hz for a clock of 6 MHz. Fixes: 0fbbe96bfa08 ("drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support") Signed-off-by: Gerald Loacker <[email protected]> Acked-by: Jessica Zhang <[email protected]> Link: https://lore.kernel.org/r/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-2-e4821802443d@wolfvision.net Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-2-e4821802443d@wolfvision.net
2024-05-30drm/panel: sitronix-st7789v: fix timing for jt240mhqs_hwt_ek_e3 panelGerald Loacker1-3/+3
Flickering was observed when using partial mode. Moving the vsync to the same position as used by the default sitronix-st7789v timing resolves this issue. Fixes: 0fbbe96bfa08 ("drm/panel: sitronix-st7789v: add jasonic jt240mhqs-hwt-ek-e3 support") Acked-by: Jessica Zhang <[email protected]> Signed-off-by: Gerald Loacker <[email protected]> Link: https://lore.kernel.org/r/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-1-e4821802443d@wolfvision.net Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240409-bugfix-jt240mhqs_hwt_ek_e3-timing-v2-1-e4821802443d@wolfvision.net
2024-05-29drm/panel/lg-sw43408: mark sw43408_backlight_ops as staticDmitry Baryshkov1-1/+1
Fix sparse warning regarding symbol 'sw43408_backlight_ops' not being declared. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Reviewed-by: Neil Armstrong <[email protected]> Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver") Reviewed-by: Marijn Suijten <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-05-29drm/panel/lg-sw43408: select CONFIG_DRM_DISPLAY_DP_HELPERDmitry Baryshkov1-0/+2
This panel driver uses DSC PPS functions and as such depends on the DRM_DISPLAY_DP_HELPER. Select this symbol to make required functions available to the driver. Reported-by: kernel test robot <[email protected]> Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/ Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver") Reviewed-by: Neil Armstrong <[email protected]> Reviewed-by: Marijn Suijten <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Signed-off-by: Dmitry Baryshkov <[email protected]>
2024-05-28drm/panel-edp: Add more panels with conservative timingsPin-yen Lin1-0/+3
Same as commit 7c8690d8fc80 ("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 <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-28drm/panel-edp: Add support for several panelsPin-yen Lin1-0/+3
Add support for the following models: AUO B140HTN02.0 BOE NT116WHM-N21 V4.1 BOE NT116WHM-N21 Signed-off-by: Pin-yen Lin <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-28drm/panel: sony-acx565akm: Don't call disable at removeDouglas Anderson1-3/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Laurent Pinchart <[email protected]> Cc: Sebastian Reichel <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.47.I2513fd6824929a17c1ccd18a797b98a1a1063559@changeid
2024-05-28drm/panel: sony-acx565akm: Don't double-check enabled state in disableDouglas Anderson1-3/+0
As talked about in commit d2aacaf07395 ("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 <[email protected]> Cc: Sebastian Reichel <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.46.I6a51b36831a5c7b2b82bccf8c550cf0d076aa541@changeid
2024-05-28drm/panel: sitronix-st7703: Don't call disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Guido Günther <[email protected]> Cc: Ondřej Jirman <[email protected]> Cc: Chris Morgan <[email protected]> Cc: Frank Oltmanns <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.43.I08ba0d4e2d534c06ab0ede9c148bb14cc7c1a9d7@changeid
2024-05-28drm/panel: sitronix-st7703: Stop tracking preparedDouglas Anderson1-11/+7
As talked about in commit d2aacaf07395 ("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 <[email protected]> Cc: Ondřej Jirman <[email protected]> Cc: Chris Morgan <[email protected]> Cc: Frank Oltmanns <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.42.Ifc436b262d72f1a33ddef10adfd7578d4acb60d8@changeid
2024-05-28drm/panel: xinpeng-xpp055c272: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.31.Ib97e67a9877070698afbec4f8ede091b2bf89a1f@changeid
2024-05-28drm/panel: xinpeng-xpp055c272: Stop tracking preparedDouglas Anderson1-11/+0
As talked about in commit d2aacaf07395 ("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: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.30.I2145be78ce28327f4588c2c21370f22fd79d28b8@changeid
2024-05-28drm/panel: simple: Add a comment about unprepare+disable at shutdown/removeDouglas Anderson1-10/+23
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.27.I639183ac987e139092491a94e22d46a5d857580c@changeid
2024-05-28drm/panel: simple: Stop tracking prepared/enabledDouglas Anderson1-27/+0
As talked about in commit d2aacaf07395 ("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: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Acked-by: Sui Jingfeng <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.26.I865be97dd393d6ae3c3a3cd1358c95fdbca0fe83@changeid
2024-05-28drm/panel: samsung-atna33xc20: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-12/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.25.Iaeacccf98e6cb729b8fc3a782725769cd66812ad@changeid
2024-05-28drm/panel: samsung-atna33xc20: Stop tracking prepared/enabledDouglas Anderson1-24/+0
As talked about in commit d2aacaf07395 ("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: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.24.Ibb4f923363a27167c480a432e52884b117221974@changeid
2024-05-28drm/panel: novatek-nt36672a: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Sumit Semwal <[email protected]> Cc: Benni Steini <[email protected]> Cc: Marijn Suijten <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Tested-by: Joel Selvaraj <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.19.I67819ba5513d4ef85f254a68b22a3402b4cdf30f@changeid
2024-05-28drm/panel: novatek-nt36672a: Stop tracking preparedDouglas Anderson1-12/+0
As talked about in commit d2aacaf07395 ("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 <[email protected]> Cc: Benni Steini <[email protected]> Cc: Marijn Suijten <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Tested-by: Joel Selvaraj <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.18.I13a06b9e6f5920659b1e5d12543b3cd9066383b8@changeid
2024-05-28drm/panel: ltk500hd1829: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.17.If3edcf846f754b425959980039372a9fd1599ecc@changeid
2024-05-28drm/panel: ltk500hd1829: Stop tracking preparedDouglas Anderson1-11/+0
As talked about in commit d2aacaf07395 ("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: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.16.I4f574b87fe24765ddd4424437159b37a6481aa1a@changeid
2024-05-28drm/panel: ltk050h3146w: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Tested-by: Quentin Schulz <[email protected]> # RK3399 Puma with Haikou Video Demo Tested-by: Quentin Schulz <[email protected]> # PX30 Ringneck with Haikou Video Demo Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.15.Ibeb2e5692e34b136afe4cf55532f0696ab3f5eed@changeid
2024-05-28drm/panel: ltk050h3146w: Stop tracking preparedDouglas Anderson1-11/+0
As talked about in commit d2aacaf07395 ("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: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Tested-by: Heiko Stuebner <[email protected]> Reviewed-by: Quentin Schulz <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.14.I264417152e65b4a2e374666010666fa1c2d973fc@changeid
2024-05-28drm/panel: kingdisplay-kd097d04: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-17/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Brian Norris <[email protected]> Cc: Chris Zhong <[email protected]> Cc: Nickey Yang <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.13.I6c7c84b1560dd374f6e7e8dc50f419a870d31d31@changeid
2024-05-28drm/panel: kingdisplay-kd097d04: Stop tracking prepared/enabledDouglas Anderson1-31/+0
As talked about in commit d2aacaf07395 ("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 <[email protected]> Cc: Chris Zhong <[email protected]> Cc: Nickey Yang <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.12.I711d07c4f4738df199697fd534c452cdfa46a21f@changeid
2024-05-28drm/panel: innolux-p079zca: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-16/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Chris Zhong <[email protected]> Cc: Lin Huang <[email protected]> Cc: Brian Norris <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.9.Iaddb8e0cab570e2f8066a4baf1d49239a820b799@changeid
2024-05-28drm/panel: innolux-p079zca: Stop tracking prepared/enabledDouglas Anderson1-39/+0
As talked about in commit d2aacaf07395 ("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 <[email protected]> Cc: Lin Huang <[email protected]> Cc: Brian Norris <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Reviewed-by: Heiko Stuebner <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.8.I99c73621fe3fba067a5e7ee6a1f6293c23371e1e@changeid
2024-05-28drm/panel: edp: Add a comment about unprepare+disable at shutdown/removeDouglas Anderson1-10/+23
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.7.Icff7f7005d997773d585e36aba9ed41a9865201f@changeid
2024-05-28drm/panel: edp: Stop tracking prepared/enabledDouglas Anderson1-27/+0
As talked about in commit d2aacaf07395 ("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: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.6.I4d1bf08781593c08127e506422687ab19fd3c824@changeid
2024-05-28drm/panel: boe-tv101wum-nl6: Don't call unprepare+disable at shutdown/removeDouglas Anderson1-11/+0
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/[email protected] [2] https://lore.kernel.org/r/[email protected] [3] https://lore.kernel.org/r/[email protected] Cc: Jitao Shi <[email protected]> Cc: Cong Yang <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.5.I5bd120aa0b7d17a1149ea43cc4852492834058c0@changeid
2024-05-28drm/panel: boe-tv101wum-nl6: Stop tracking preparedDouglas Anderson1-12/+0
As talked about in commit d2aacaf07395 ("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: Jitao Shi <[email protected]> Cc: Cong Yang <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.4.Ib501f2eceb62016e09cfb17bca29bde0f605a567@changeid
2024-05-28drm/panel: raydium-rm692e5: Stop tracking preparedDouglas Anderson1-10/+0
As talked about in commit d2aacaf07395 ("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: Konrad Dybcio <[email protected]> Acked-by: Linus Walleij <[email protected]> Acked-by: Maxime Ripard <[email protected]> Tested-by: Luca Weiss <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.1.I784238de4810658212a5786b219f128460562a37@changeid
2024-05-27Merge drm/drm-next into drm-misc-nextMaxime Ripard2-23/+24
Let's start the new release cycle. Signed-off-by: Maxime Ripard <[email protected]>
2024-05-22drm/panel-edp: Add CMN N116BCJ-EAKHaikun Zhou1-0/+1
Add support for the CMN N116BCJ-EAK, place the raw EDID here for subsequent reference. 00 ff ff ff ff ff ff 00 0d ae 60 11 00 00 00 00 04 22 01 04 95 1a 0e 78 02 67 75 98 59 53 90 27 1c 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 da 1d 56 e2 50 00 20 30 30 20 a6 00 00 90 10 00 00 18 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 00 00 fe 00 43 4d 4e 0a 20 20 20 20 20 20 20 20 20 00 00 00 fe 00 4e 31 31 36 42 43 4a 2d 45 41 4b 0a 20 00 98 Signed-off-by: Haikun Zhou <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Douglas Anderson <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240522113924.1261683-1-zhouhaikun5@huaqin.corp-partner.google.com
2024-05-21drm/panel: himax-hx83102: use wrapped MIPI DCS functionsDouglas Anderson1-64/+28
Take advantage of some of the new wrapped routines introduced by commit f79d6d28d8fe ("drm/mipi-dsi: wrap more functions for streamline handling") to simplify the himax-hx83102 driver a bit more. This gets rid of some extra error prints (since the _multi functions all print errors for you) and simplifies the code a bit. One thing here that isn't just refactoring is that in a few places we now check with errors with "if (err)" instead of "if (err < 0)". All errors are expected to be negative so this is not expected to have any impact. The _multi code internally considers anything non-zero to be an error so this just makes things consistent. It can also be noted that hx83102_prepare() has a mix of things that can take advantage of _multi calls and things that can't. The cleanest seemed to be to use the multi_ctx still but consistently use the "accum_err" variable for error returns, though that's definitely a style decision with pros and cons. Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240517143643.8.If761d37b5d511867ac8207fe8220ae48d444a04f@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.8.If761d37b5d511867ac8207fe8220ae48d444a04f@changeid
2024-05-21drm/panel: himax-hx83102: Check for errors on the NOP in prepare()Douglas Anderson1-1/+5
The mipi_dsi_dcs_nop() function returns an error but we weren't checking it in hx83102_prepare(). Add a check. This is highly unlikely to matter in practice. If the NOP failed then likely later MIPI commands would fail too. Found by code inspection. Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out as separate driver") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240517143643.7.I3fae28745bf2cacd8dac04d7a06daea50e233f46@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.7.I3fae28745bf2cacd8dac04d7a06daea50e233f46@changeid
2024-05-21drm/panel: himax-hx83102: If prepare fails, disable GPIO before regulatorsDouglas Anderson1-1/+1
The enable GPIO should clearly be set low before turning off regulators. That matches both the inverse order that things were enabled and also the order in unprepare(). Fixes: 0ef94554dc40 ("drm/panel: himax-hx83102: Break out as separate driver") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240517143643.6.Id0659a80147cf51e0ebb8fe7fee18db86851960d@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.6.Id0659a80147cf51e0ebb8fe7fee18db86851960d@changeid
2024-05-21drm/panel: ilitek-ili9882t: Check for errors on the NOP in prepare()Douglas Anderson1-1/+5
The mipi_dsi_dcs_nop() function returns an error but we weren't checking it in ili9882t_prepare(). Add a check. This is highly unlikely to matter in practice. If the NOP failed then likely later MIPI commands would fail too. Found by code inspection. Fixes: e2450d32e5fb ("drm/panel: ili9882t: Break out as separate driver") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240517143643.5.I323476ba9fa8cc7a5adee4c1ec95202785cc5686@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.5.I323476ba9fa8cc7a5adee4c1ec95202785cc5686@changeid
2024-05-21drm/panel: ilitek-ili9882t: If prepare fails, disable GPIO before regulatorsDouglas Anderson1-1/+1
The enable GPIO should clearly be set low before turning off regulators. That matches both the inverse order that things were enabled and also the order in unprepare(). Fixes: e2450d32e5fb ("drm/panel: ili9882t: Break out as separate driver") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240517143643.4.Ieb0179065847972a0f13e9a8574a80a5f65f3338@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.4.Ieb0179065847972a0f13e9a8574a80a5f65f3338@changeid
2024-05-21drm/panel: boe-tv101wum-nl6: Check for errors on the NOP in prepare()Douglas Anderson1-1/+5
The mipi_dsi_dcs_nop() function returns an error but we weren't checking it in boe_panel_prepare(). Add a check. This is highly unlikely to matter in practice. If the NOP failed then likely later MIPI commands would fail too. Found by code inspection. Fixes: 812562b8d881 ("drm/panel: boe-tv101wum-nl6: Fine tune the panel power sequence") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: AngeloGioacchino Del Regno <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240517143643.3.Ibffbaa5b4999ac0e55f43bf353144433b099d727@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.3.Ibffbaa5b4999ac0e55f43bf353144433b099d727@changeid
2024-05-21drm/panel: boe-tv101wum-nl6: If prepare fails, disable GPIO before regulatorsDouglas Anderson1-1/+1
The enable GPIO should clearly be set low before turning off regulators. That matches both the inverse order that things were enabled and also the order in unprepare(). Fixes: a869b9db7adf ("drm/panel: support for boe tv101wum-nl6 wuxga dsi video mode panel") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240517143643.2.Ieac346cd0f1606948ba39ceea06b55359fe972b6@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.2.Ieac346cd0f1606948ba39ceea06b55359fe972b6@changeid
2024-05-21drm/panel: himax-hx8394: Handle errors from mipi_dsi_dcs_set_display_on() betterDouglas Anderson1-2/+1
If mipi_dsi_dcs_set_display_on() returned an error then we'd store that in the "ret" variable and jump to error handling. We'd then attempt an orderly poweroff. Unfortunately we then blew away the value stored in "ret". That means that if the orderly poweroff actually worked then we're return 0 (no error) from hx8394_enable() even though the panel wasn't enabled. Fix this by not blowing away "ret". Found by code inspection. Fixes: 65dc9360f741 ("drm: panel: Add Himax HX8394 panel controller driver") Signed-off-by: Douglas Anderson <[email protected]> Reviewed-by: Dmitry Baryshkov <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240517143643.1.I0a6836fffd8d7620f353becb3df2370d2898f803@changeid Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240517143643.1.I0a6836fffd8d7620f353becb3df2370d2898f803@changeid
2024-05-17drm/panel: lg-sw43408: use new streamlined MIPI DSI APIDmitry Baryshkov1-58/+37
Use newer mipi_dsi_*_multi() functions in order to simplify and cleanup panel's prepare() and unprepare() functions. Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-17drm/panel: novatek-nt36672e: use wrapped MIPI DCS functionsDmitry Baryshkov1-313/+284
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to simplify driver's init/exit code. This also includes passing context to the init_sequence() function instead of passing the DSI device. Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-17drm/panel: innolux-p079zca: use mipi_dsi_dcs_nop_multi()Dmitry Baryshkov1-8/+1
Remove conditional code and use mipi_dsi_dcs_nop_multi() wrapper to simplify driver code. Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-17drm/panel: ilitek-ili9882t: use wrapped MIPI DCS functionsDmitry Baryshkov1-37/+11
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to simplify driver's init/exit code. Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-17drm/panel: boe-tv101wum-nl6: use wrapped MIPI DCS functionsDmitry Baryshkov1-62/+19
Remove conditional code and always use mipi_dsi_dcs_*multi() wrappers to simplify driver's init/exit code. Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-17drm/panel: lg-sw43408: add missing error handlingDmitry Baryshkov1-6/+27
Add missing error handling for the mipi_dsi_ functions that actually return error code instead of silently ignoring it. Fixes: 069a6c0e94f9 ("drm: panel: Add LG sw43408 panel driver") Reviewed-by: Douglas Anderson <[email protected]> Signed-off-by: Dmitry Baryshkov <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
2024-05-17drm/panel: himax-hx83102: Support for IVO t109nw41 MIPI-DSI panelCong Yang1-0/+132
The IVO t109nw41 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller which fits in nicely with the existing panel-himax-hx83102 driver. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240516072039.1287065-7-yangcong5@huaqin.corp-partner.google.com Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240516072039.1287065-7-yangcong5@huaqin.corp-partner.google.com
2024-05-17drm/panel: himax-hx83102: Support for BOE nv110wum-l60 MIPI-DSI panelCong Yang1-0/+133
The BOE nv110wum-l60 is a 11.0" WUXGA TFT LCD panel, use hx83102 controller which fits in nicely with the existing panel-himax-hx83102 driver. Hence, we add a new compatible with panel specific config. Signed-off-by: Cong Yang <[email protected]> Reviewed-by: Douglas Anderson <[email protected]> Reviewed-by: Linus Walleij <[email protected]> Link: https://lore.kernel.org/r/20240516072039.1287065-5-yangcong5@huaqin.corp-partner.google.com Signed-off-by: Neil Armstrong <[email protected]> Link: https://patchwork.freedesktop.org/patch/msgid/20240516072039.1287065-5-yangcong5@huaqin.corp-partner.google.com
Powered by cgit, Gruvboxed by Blaster4385.