- 28 May, 2024 40 commits
-
-
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:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.46.I6a51b36831a5c7b2b82bccf8c550cf0d076aa541@changeid
-
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:
-
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: Jitao Shi <jitao.shi@mediatek.com> Cc: Cong Yang <yangcong5@huaqin.corp-partner.google.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: Konrad Dybcio <konrad.dybcio@linaro.org> Acked-by:
Luca Weiss <luca.weiss@fairphone.com> Signed-off-by:
-
Ville Syrjälä authored
Allow sti to be built with COMPILE_TEST=y for greater coverage. Builds fine on x86/x86_64 at least. Cc: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240408170426.9285-8-ville.syrjala@linux.intel.comAcked-by:
Alain Volmat <alain.volmat@foss.st.com>
-
Ville Syrjälä authored
Include linux/io.h for devm_ioremap(). When built on x86_64 w/ COMPILE_TEST=y: ../drivers/gpu/drm/sti/sti_dvo.c:531:21: error: implicit declaration of function ‘devm_ioremap’ [-Werror=implicit-function-declaration] 531 | dvo->regs = devm_ioremap(dev, res->start, | ^~~~~~~~~~~~ ../drivers/gpu/drm/sti/sti_dvo.c:531:19: error: assignment to ‘void *’ from ‘int’ makes pointer from integer without a cast [-Werror=int-conversion] 531 | dvo->regs = devm_ioremap(dev, res->start, | ^ Cc: Alain Volmat <alain.volmat@foss.st.com> Signed-off-by: -
MarileneGarcia authored
It fixes the following warnings when the kernel documentation is generated: ./include/drm/display/drm_dp_helper.h:126: warning: Function parameter or struct member 'mode' not described in 'drm_dp_as_sdp' ./include/drm/display/drm_dp_helper.h:126: warning: Excess struct member 'operation_mode' description in 'drm_dp_as_sdp' Signed-off-by:
MarileneGarcia <marilene.agarcia@gmail.com> Fixes: 0bbb8f59 ("drm/dp: Add Adaptive Sync SDP logging") Reviewed-by:
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Closes: https://lore.kernel.org/r/20240405141640.09b0bdbf@canb.auug.org.auReviewed-by:
-
Alex Bee authored
The DesignWare MIPI DSI controller found RK3128 SoCs supports up to 4 DSI data lanes. Similar to PX30/RK356x/RV1126 it uses an external D-PHY. Signed-off-by:
Alex Bee <knaerzche@gmail.com> Signed-off-by:
-
Alex Bee authored
Document the MIPI DSI controller for Rockchip RK3128. The integration is similar to PX30 so it's bindings-constraints can be re-used. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Signed-off-by:
-
Maxime Ripard authored
The new HDMI connector infrastructure allows to remove some boilerplate, especially to generate infoframes. Let's switch to it. Reviewed-by:
Jernej Skrabec <jernej.skrabec@gmail.com> Acked-by:
Andy Yan <andyshrk@163.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-29-c5af16c3aae2@kernel.orgSigned-off-by:
-
Maxime Ripard authored
The new HDMI connector infrastructure allows to remove some boilerplate, especially to generate infoframes. Let's switch to it. Reviewed-by:
-
Maxime Ripard authored
Now that we have a plane create helper for kunit mocked drivers, let's convert to it in vc4. Reviewed-by:
Maíra Canal <mcanal@igalia.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-27-c5af16c3aae2@kernel.orgSigned-off-by:
-
Maxime Ripard authored
The vc4_dummy_plane structure was introduced as a mean to add mock-specific fields. However, we never really used it and it's still strictly equivalent to vc4_plane (which is in the same situation vs drm_plane), so we can simply remove the vc4_dummy_plane structure and make the mock code cleaner. Reviewed-by:
-
Maxime Ripard authored
The new HDMI connector infrastructure allows us to remove a lot of boilerplate, so let's switch to it. Acked-by:
-
Maxime Ripard authored
There has been some discussions recently about the infoframes sent by drivers and if they were properly generated. In parallel, there's been some interest in creating an infoframe-decode tool similar to edid-decode. Both would be much easier if we were to expose the infoframes programmed in the hardware. It won't be perfect since we have no guarantee that it's actually what goes through the wire, but it's the best we can do. Reviewed-by:
-
Maxime Ripard authored
The previous patch added the generation of the infoframes matching an HDMI connector state. Let's add a few tests to make sure it works as expected. Reviewed-by:
-
Maxime Ripard authored
Infoframes in KMS is usually handled by a bunch of low-level helpers that require quite some boilerplate for drivers. This leads to discrepancies with how drivers generate them, and which are actually sent. Now that we have everything needed to generate them in the HDMI connector state, we can generate them in our common logic so that drivers can simply reuse what we precomputed. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Maxime Ripard authored
The previous commit added the infrastructure to the connector state to track what RGB Quantization should be used in a given state for an HDMI connector. Let's add some kunit tests to make sure it works as expected. Reviewed-by:
Dave Stevenson <dave.stevenson@raspberrypi.com> Reviewed-by:
-
Maxime Ripard authored
HDMI controller drivers will need to figure out the RGB range they need to configure based on a mode and property values. Let's expose that in the HDMI connector state so drivers can just use that value. Reviewed-by:
-
Maxime Ripard authored
This had a bunch of kunit tests to make sure our code to handle the Broadcast RGB property behaves properly. This requires bringing a bit of infrastructure to create mock HDMI connectors, with custom EDIDs. Reviewed-by:
-
