- 28 May, 2024 32 commits
-
-
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:
Douglas Anderson <dianders@chromium.org> Signed-off-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:
Heiko Stuebner <heiko@sntech.de> Link: https://patchwork.freedesktop.org/patch/msgid/20240509140653.168591-6-knaerzche@gmail.com
-
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 <mripard@kernel.org>
-
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:
-
Maxime Ripard authored
A lot of the various HDMI drivers duplicate some logic that depends on the HDMI spec itself and not really a particular hardware implementation. Output BPC or format selection, infoframe generation are good examples of such areas. This creates a lot of boilerplate, with a lot of variations, which makes it hard for userspace to rely on, and makes it difficult to get it right for drivers. In the next patches, we'll add a lot of infrastructure around the drm_connector and drm_connector_state structures, which will allow to abstract away the duplicated logic. This infrastructure comes with a few requirements though, and thus we need a new initialization function. Hopefully, this will make drivers simpler to handle, and their behaviour more consistent. Reviewed-by:
-
- 27 May, 2024 8 commits
-
-
Jani Nikula authored
Prefer the struct drm_edid based functions for reading the EDID and updating the connector. Reviewed-by:
Jani Nikula <jani.nikula@intel.com>
-
Jani Nikula authored
Prefer the struct drm_edid based functions for reading the EDID and updating the connector. Reviewed-by:
-
Jani Nikula authored
Prefer the struct drm_edid based functions for reading the EDID and updating the connector. Reviewed-by:
-
Jani Nikula authored
Prefer the struct drm_edid based functions for reading the EDID and updating the connector. Reviewed-by:
-
Jani Nikula authored
Prefer the struct drm_edid based functions for reading the EDID and updating the connector. Reviewed-by:
Thomas Zimmermann <tzimmermann@suse.de> Link: https://patchwork.freedesktop.org/patch/msgid/386e3a64efbdd61c3eaed3f49ea9c3ebd4fcd41d.1715691257.git.jani.nikula@intel.comSigned-off-by:
-
Jani Nikula authored
Prefer the struct drm_edid based functions for reading the EDID and updating the connector. Reviewed-by:
-
Maxime Ripard authored
Let's start the new release cycle. Signed-off-by: -
Christophe JAILLET authored
This is an effort to get rid of all multiplications from allocation functions in order to prevent integer overflows [1][2]. The "struct dma_fence_array" can be refactored to add a flex array in order to have the "callback structures allocated behind the array" be more explicit. Do so: - makes the code more readable and safer. - allows using __counted_by() for additional checks - avoids some pointer arithmetic in dma_fence_array_enable_signaling() Link: https://www.kernel.org/doc/html/latest/process/deprecated.html#open-coded-arithmetic-in-allocator-arguments [1] Link: https://github.com/KSPP/linux/issues/160 [2] Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Reviewed-by:
Kees Cook <keescook@chromium.org> Reviewed-by:
Christian König <christian.koenig@amd.com> Link: https://patchwork.freedesktop.org/patch/msgid/8b4e556e07b5dd78bb8a39b67ea0a43b199083c8.1716652811.git.christophe.jaillet@wanadoo.frSigned-off-by:
-
