- 28 May, 2024 40 commits
-
-
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:
Linus Walleij <linus.walleij@linaro.org> Acked-by:
Maxime Ripard <mripard@kernel.org> Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240503143327.RFT.v2.9.Iaddb8e0cab570e2f8066a4baf1d49239a820b799@changeid
-
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:
Sui Jingfeng <sui.jingfeng@linux.dev> Reviewed-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:
-
Maxime Ripard authored
The i915 driver has a property to force the RGB range of an HDMI output. The vc4 driver then implemented the same property with the same semantics. KWin has support for it, and a PR for mutter is also there to support it. Both drivers implementing the same property with the same semantics, plus the userspace having support for it, is proof enough that it's pretty much a de-facto standard now and we can provide helpers for it. Let's plumb it into the newly created HDMI connector. Reviewed-by:
Pekka Paalanen <pekka.paalanen@collabora.com> Reviewed-by:
Sebastian Wick <sebastian.wick@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240527-kms-hdmi-connector-state-v15-18-c5af16c3aae2@kernel.orgSigned-off-by:
-
Maxime Ripard authored
The Broadcast RGB property has been documented as three separate entries so far, each with a different set of values. The first one is pretty much the generic one: it's used by i915 and vc4, and is the one used by all the compositors. The second one is used by the gma500 driver, and is a subset of the first one: it can have the values "Full" or "Limited 16:235", but lack the "Automatic" value. The third one however isn't used by any driver and documents the values "off", "auto" and "on". It's unclear where the last one comes from. It was first documented in commit 6c6a3996 ("Documentation: drm: describing drm properties exposed by various drivers") which adds a number of properties used by drivers, but without mentioning which driver was using what property. Grepping at the 6c6a3996 commit however, it looks like no driver is actually using it, and a quick look at the entire kernel history doesn't show any match either. At the time though, gma500 had an "audio" property used right next to Broadcast RGB that did have the "off", "auto" and "on" values in the same order. As such, it was probably a copy/paste or scripting error back then, and there's never been such property used in the kernel. Either way, it certainly hasn't been used in a decade or two so we can just get rid of it. Suggested-by:
-
Maxime Ripard authored
The previous patch added the bpc and format an HDMI connector needs to be set up with for a given connector state. Let's add a few tests to make sure it works as expected. Reviewed-by:
-
Maxime Ripard authored
Now that we have all the infrastructure needed, we can add some code that will, for a given connector state and mode, compute the best output format and bpc. The algorithm is equivalent to the one already found in i915 and vc4. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Maxime Ripard authored
The previous patch adds a new hook for HDMI connectors to filter out configurations based on the TMDS character rate. Let's add some tests to make sure it works as expected. Reviewed-by:
-
Maxime Ripard authored
Most of the HDMI controllers have an upper TMDS character rate limit they can't exceed. On "embedded"-grade display controllers, it will typically be lower than what high-grade monitors can provide these days, so drivers will filter the TMDS character rate based on the controller capabilities. To make that easier to handle for drivers, let's provide an optional hook to be implemented by drivers so they can tell the HDMI controller helpers if a given TMDS character rate is reachable for them or not. This will then be useful to figure out the best format and bpc count for a given mode. Reviewed-by:
-
Maxime Ripard authored
The previous patch stores in the connector state the expected TMDS character rate matching the configuration of the HDMI connector. Let's add a few tests to make sure it works as expected. Reviewed-by:
-
Maxime Ripard authored
Most HDMI drivers have some code to calculate the TMDS character rate, usually to adjust an internal clock to match what the mode requires. Since the TMDS character rates mostly depends on the resolution, whether we need to repeat pixels or not, the bpc count and the format, we can now derive it from the HDMI connector state that stores all those infos and remove the duplication from drivers. Reviewed-by:
-
Maxime Ripard authored
The previous patch added an helper to compute the TMDS character rate on an HDMI connector. Let's add a few tests to make sure it works as expected. Reviewed-by:
-
Maxime Ripard authored
A lot of HDMI drivers have some variation of the formula to calculate the TMDS character rate from a mode, but few of them actually take all parameters into account. Let's create a helper to provide that rate taking all parameters into account. Reviewed-by:
-
Maxime Ripard authored
Now that we track the HDMI output format as part of the connector state, let's add a few tests to make sure it works as expected. Reviewed-by:
-
Maxime Ripard authored
Just like BPC, we'll add support for automatic selection of the output format for HDMI connectors. Let's add the needed defaults and fields for now. Reviewed-by:
-
Maxime Ripard authored
Now that we're tracking the output bpc count in the connector state, let's add a few tests to make sure it works as expected. Reviewed-by:
-
Maxime Ripard authored
We'll need to use drm_mode_obj_find_prop_id() for kunit tests to make sure a given property has been properly created. Let's export it for tests only. Reviewed-by:
-
Maxime Ripard authored
We'll add automatic selection of the output BPC in a following patch, but let's add it to the HDMI connector state already. Reviewed-by:
-
Maxime Ripard authored
The next features we will need to share across drivers will need to store some parameters for drivers to use, such as the selected output format. Let's create a new connector sub-state dedicated to HDMI controllers, that will eventually store everything we need. Reviewed-by:
-
Maxime Ripard authored
We just introduced a new initialization function for our connectors, so let's build a kunit test suite for it as well. Reviewed-by:
-
