Lt9611uxd DSI HDMI Bridge for Shikra IQS#841
Conversation
Many bridge drivers store a next_bridge pointer in their private data and
use it for attach and sometimes other purposes. This is going to be risky
when bridge hot-unplug is used.
Considering this example scenario:
1. pipeline: encoder --> bridge A --> bridge B --> bridge C
2. encoder takes a reference to bridge B
3. bridge B takes a next_bridge reference to bridge C
4. encoder calls (bridge B)->b_foo(), which in turns references
next_bridge, e.g.:
b_foo() {
bar(b->next_bridge);
}
If bridges B and C are removed, bridge C can be freed but B is still
allocated because the encoder holds a reference to B. So when step 4
happens, 'b->next-bridge' would be a use-after-free.
Calling drm_bridge_put() in the B bridge .remove function does not solve
the problem as it leaves a (potentially long) risk window between B removal
and the final deallocation of B. A safe moment to put the B reference is in
__drm_bridge_free(), when the last reference has been put. This can be done
by drivers in the .destroy func. However to avoid the need for so many
drivers to implement a .destroy func, just offer a next_bridge pointer to
all bridges that is automatically put it in __drm_bridge_free(), exactly
when the .destroy func is called.
Suggested-by: Maxime Ripard <mripard@kernel.org>
Link: https://lore.kernel.org/all/20251201-thick-jasmine-oarfish-1eceb0@houat/
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Link: https://patch.msgid.link/20251216-drm-bridge-alloc-getput-drm_of_find_bridge-v3-6-b5165fab8058@bootlin.com
Signed-off-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
Having only a single set of callbacks, hdmi_clear_infoframe and hdmi_write_infoframe, bridge drivers don't have an easy way to signal to the DRM framework, which InfoFrames are actually supported by the hardware and by the driver and which are not. Also, it makes it extremely easy for HDMI bridge drivers to skip implementing the seemingly required InfoFrames (e.g. HDMI VSI). Last, but not least, those callbacks take a single 'type' parameter, which makes it impossible to implement support for multiple VSIs (which will be required once we start working on HDMI Forum VSI). Split the callbacks into a per-InfoFrame-kind pairs, letting the bridge drivers actually signal supported features. The implementation follows the overall drm_bridge design, where the bridge has a single drm_bridge_funcs implementation and signals, which functions are to be called using the drm_bridge->ops flags. The AVI and HDMI VSI are assumed to be required for a normal HDMI operation (with the drivers getting a drm_warn_once() stub implementation if one is missing). The Audio InfoFrame is handled by the existing DRM_BRIDGE_OP_HDMI_AUDIO, while the SPD and HDR DRM InfoFrames got new drm_bridge_ops values. Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260107-limit-infoframes-2-v4-5-213d0d3bd490@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
…to OP_HDMI There are DRM_BRIDGE_OP_HDMI_AUDIO bridges (e.g. Lontium LT9611UXC) which don't implement DRM_BRIDGE_OP_HDMI and don't implement hdmi_clear_audio_infoframe / hdmi_write_audio_infoframe callbacks. Move corresponding checks under the DRM_BRIDGE_OP_HDMI condition, making sure that we require those callbacks only from the bridges which are actually going to use them. Fixes: b626b1a ("drm/bridge: refactor HDMI InfoFrame callbacks") Acked-by: Maxime Ripard <mripard@kernel.org> Link: https://patch.msgid.link/20260126-drm-fix-lt9611uxc-v1-1-04a635a8f5cf@oss.qualcomm.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
The KMS framework uses two slightly different definitions for the state
concept. For a given object (plane, CRTC, encoder, etc., so
drm_$OBJECT_state), the state is the entire state of that object.
However, at the device level, drm_atomic_state refers to a state update
for a limited number of objects.
Thus, drm_atomic_state isn't the entire device state, but only the full
state of some objects in that device. This has been an endless source of
confusion and thus bugs.
We can rename the drm_atomic_state structure to drm_atomic_commit to
make it less confusing.
This patch was created using:
rg -l drm_atomic_state | \
xargs sed -i 's/drm_atomic_state/drm_atomic_commit/g; s/drm_atomic_commit_helper/drm_atomic_state_helper/g'
mv drivers/gpu/drm/tests/drm_atomic_state_test.c drivers/gpu/drm/tests/drm_atomic_commit_test.c
Acked-by: Simona Vetter <simona.vetter@ffwll.ch>
Acked-by: Thomas Zimmermann <tzimmermann@suse.de>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com>
Signed-off-by: Maxime Ripard <mripard@kernel.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patch.msgid.link/20260427-drm-drm-atomic-update-v4-1-c0e713bfdf25@kernel.org
Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
All the objects that need to implement some callbacks in KMS have a pointer in there structure to the main drm_device. However, it's not the case for drm_private_objs, which makes it harder than it needs to be to implement some of its callbacks. Let's add that pointer. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Link: https://patch.msgid.link/20251014-drm-private-obj-reset-v2-1-6dd60e985e9d@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
Since we're going to move the drm_private_obj state allocation to a callback, we need to be able to deal with its possible failure. Make drm_private_obj_init return an error code on failure. Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-1-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
…vate_obj The drm_private_obj initialization was inconsistent with the rest of the KMS objects. Indeed, it required to pass a preallocated state in drm_private_obj_init(), while all the others objects would have a reset callback that would be called later on to create the state. However, reset really is meant to reset the hardware and software state. That it creates an initial state is a side-effect that has been used in all objects but drm_private_obj. This is made more complex since some drm_private_obj, the DisplayPort ones in particular, need to be persistent across and suspend/resume cycle, and such a cycle would call drm_mode_config_reset(). Thus, we need to add a new callback to allocate a pristine state for a given private object. This discussion has also came up during the atomic state readout discussion, so it might be introduced into the other objects later on. Until all drivers are converted to that new allocation pattern, we will only call it if the passed state is NULL. This will be removed eventually. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-2-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
Now that we have an atomic_create_state callback for drm_private_objs, we can provide a helper for it. It's somewhat different from the other similar helpers though, because we definitely expect drm_private_obj to be subclassed. It wouldn't make sense for a driver to use it as-is. So we can't provide a straight implementation of the atomic_create_state callback, but rather we provide the parts that will deal with the drm_private_obj initialization, and we will leave the allocation and initialization of the subclass to drivers. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-3-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
…ate_state The bridge implementation relies on a drm_private_obj, that is initialized by allocating and initializing a state, and then passing it to drm_private_obj_init. Since we're gradually moving away from that pattern to the more established one relying on a atomic_create_state implementation, let's migrate this instance to the new pattern. Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20260128-drm-private-obj-reset-v4-4-90891fa3d3b0@redhat.com Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
Commit 47b5ac7 ("drm/atomic: Add new atomic_create_state callback to drm_private_obj") introduced a new pattern for allocating drm object states: atomic_create_state, a dedicated hook that allocates and initializes a pristine state without any side effect. The bridge atomic_reset callback is already fallible and in practice only allocates and initializes state without touching hardware. However, the reset name does not make this contract clear: callers and implementers cannot tell from the name alone whether the hardware will be affected or when the hook is safe to call. Add an atomic_create_state callback to drm_bridge_funcs to make the contract explicit: allocate a pristine state, initialize it, no side effects. The core calls it when available, falling back to atomic_reset otherwise. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-6-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
…e_state() The drm_atomic_helper_bridge_reset() helper is deprecated in favour of the new atomic_create_state callback. Add drm_atomic_helper_bridge_create_state() as the counterpart helper for this new callback, and make drm_atomic_helper_bridge_reset() call this new helper. Reviewed-by: Thomas Zimmermann <tzimmermann@suse.de> Reviewed-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Reviewed-by: Luca Ceresoli <luca.ceresoli@bootlin.com> Tested-by: Luca Ceresoli <luca.ceresoli@bootlin.com> # imx8mp + sn65dsi84 + bridge hotplug Link: https://patch.msgid.link/20260619-drm-no-more-bridge-reset-v3-7-ff399263111b@kernel.org Signed-off-by: Maxime Ripard <mripard@kernel.org> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
…o HDMI driver LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port mipi dsi and output hdmi, differences in hardware features: - LT9611C: supports 1-port mipi dsi to hdmi 1.4 - LT9611EX: supports 2-port mipi dsi to hdmi 1.4 - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0 Link: https://lore.kernel.org/lkml/20260716-lt9611c-v7-v7-1-7553a14735fc@oss.qualcomm.com/ Signed-off-by: Sunyun Yang <syyang@lontium.com> Signed-off-by: Mohit Dsor <mdsor@oss.qualcomm.com>
…iver LT9611C(EX/UXD) is an I2C-controlled chip that Receiver signal/dual port mipi dsi and output hdmi, differences in hardware features: - LT9611C: supports 1-port mipi dsi to hdmi 1.4 - LT9611EX: supports 2-port mipi dsi to hdmi 1.4 - LT9611UXD: supports 2-port mipi dsi to hdmi 1.4/2.0 Link: https://lore.kernel.org/lkml/20260716-lt9611c-v7-v7-2-7553a14735fc@oss.qualcomm.com/ Signed-off-by: Sunyun Yang <syyang@lontium.com> Co-developed-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
68c10e8 to
686f80c
Compare
|
Merge Check Failed: No CR Numbers Found Error: No Change Request numbers were found. Please add Change Request numbers to your pull request description in the format CRs-Fixed: 12345 or link GitHub issues that are associated with Change Requests. |
… support Enable the Shikra MDSS display subsystem on the Qualcomm Shikra IQS EVK board and add the Lontium LT9611UXD DSI-to-HDMI bridge node. The LT9611UXD is connected via I2C (bus 4, address 0x41), powered by a GPIO-controlled 3.3V regulator (PM8150 GPIO4) and an always-on 1.8V rail. Reset is on GPIO76 and interrupt on GPIO85. The bridge receives DSI output from MDSS and drives an HDMI-A connector, with the link wired as: DPU -> DSI0 -> LT9611UXD -> HDMI. Link: https://lore.kernel.org/lkml/20260717-shikra-work-v2-1-86ae8552259e@oss.qualcomm.com/ Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
Enable the Lontium LT9611C DSI-to-HDMI bridge driver as a module. This driver supports the LT9611UXD chip used on the Shikra IQS EVK board to provide HDMI output via the MDSS DSI interface. Link: https://lore.kernel.org/lkml/20260717-shikra-work-v2-2-86ae8552259e@oss.qualcomm.com/ Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
8958547 to
81ea68c
Compare
PR #841 — validate-patchPR: #841
Final Summary
|
PR #841 — checker-log-analyzerPR: #841
Detailed report: Full report
|
Lt9611uxd DSI HDMI Bridge for Shikra IQS
CRs-Fixed: 4552827