FROMLIST: drm/msm/dp: add .shutdown to mask HPD IRQ before system shutdown#1529
Open
yashgupta2126 wants to merge 65 commits into
Open
FROMLIST: drm/msm/dp: add .shutdown to mask HPD IRQ before system shutdown#1529yashgupta2126 wants to merge 65 commits into
yashgupta2126 wants to merge 65 commits into
Conversation
…upport Add binding for the Lontium LT9211C bridge chip. Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com> Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260323-add-lt9211c-bridge-v5-1-9c63bb035c17@oss.qualcomm.com/
Currently edid_read has value from previous connect session and resulting in drm using older edid before new edid is available in lt9611uxc. Reset edid_read so that correct status is updated and correct edid is available for drm. Link: https://lore.kernel.org/lkml/20260202-lt9611uxc-reset-edid-v2-1-b1e1d72edc90@oss.qualcomm.com/ Signed-off-by: Ravi Agola <raviagol@qti.qualcomm.com> Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com>
If HPD IRQ is enabled in the display_connector's probe, it can be triggered too early, before the DRM connector is completely setup. Use the enable_hpd / disable_hpd callbacks to control enablement of the HPD IRQ. Fixes: 0c275c3 ("drm/bridge: Add bridge driver for display connectors") Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260314-dp-connector-hpd-v1-1-786044cedc17@oss.qualcomm.com/
…r DP If the DisplayPort drivers use display-connector for the HPD detection, the internal HPD state machine might be not active and thus the hardware might be not able to handle cable detection correctly. Instead it will depend on the externall HPD notifications to set the cable state, bypassing the internal HPD state machine (for example this is the case for the msm DP driver). However if the cable has been plugged before the HPD IRQ has been enabled, there will be no HPD event coming. The drivers might fail detection in such a case. Trigger the HPD notification after enabling the HPD IRQ, propagating the cable insertion state. Fixes: 2e2bf3a ("drm/bridge: display-connector: add DP support") Reported-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260314-dp-connector-hpd-v1-2-786044cedc17@oss.qualcomm.com/
…Glymur The existing DP PHY PLL and AUX configuration for the Glymur platform does not fully follow the Hardware Programming Guide requirements for DP over Type-C, which results in DP link bring-up failures. Update the DP PHY programming sequence and PLL-related register settings to align with the latest HPG recommendations. With this change, DP link training completes successfully on Glymur-based platforms. Fixes: d10736d ("phy: qualcomm: qmp-combo: Add DP offsets and settings for Glymur platforms") Link: https://lore.kernel.org/r/20260419-glymur_dp-v1-1-ad1067a8e8ae@oss.qualcomm.com Signed-off-by: Ritesh Kumar <ritesh.kumar@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
LT9211c is a Single/Dual-Link DSI/LVDS or Single DPI input to Single-link/Dual-Link DSI/LVDS or Single DPI output bridge chip. Extend the existing lontium-lt9211 driver to support DSI-to-LVDS bridge configuration. Signed-off-by: Yi Zhang <zhanyi@qti.qualcomm.com> Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Gopi Botlagunta <venkata.botlagunta@oss.qualcomm.com> Link:https://lore.kernel.org/all/20260323-add-lt9211c-bridge-v5-2-9c63bb035c17@oss.qualcomm.com/
Currently valid mode checks are only for hdisplay and vdisplay, add htotal and vtotal to filter only specific modes. Link:https://lore.kernel.org/lkml/20251126-lt9611uxc-modes-v2-1-34bf9b351921@oss.qualcomm.com/ Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
Add 3840x2160@30 mode in lt9611uxc modes to add support for 4K@30 resolution. Link:https://lore.kernel.org/r/20251126-lt9611uxc-4k30-v2-1-3de0ea58c24e@oss.qualcomm.com Signed-off-by: Nilesh Laad <nilesh.laad@oss.qualcomm.com> Signed-off-by: Mahadevan P <mahadevan.p@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/20260508134009.4582-3-syyang@lontium.com/ Signed-off-by: Sunyun Yang <syyang@lontium.com> Signed-off-by: Mohit Dsor <mohit.dsor@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/20260508134009.4582-3-syyang@lontium.com/ Signed-off-by: Sunyun Yang <syyang@lontium.com> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
The cached drm_edid seems unnecessary here. Use the drm_edid pointer directly in the plug stage instead of caching it. Remove the cached drm_edid and the corresponding oneliner to simplify the code. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-1-ea04113e8233@oss.qualcomm.com/
The bridge .mode_set() callback is deprecated. Remove it and move all mode setup logic to .atomic_enable(), where the adjusted_mode is available from the atomic CRTC state. Drop msm_dp_mode from msm_dp_display_private and store the mode directly in the panel, as it was only used as a temporary cache. Both changes are limited to msm_dp_display_set_mode and are kept in a single patch. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-2-ea04113e8233@oss.qualcomm.com/
…fo() The display layer directly assigns msm_dp_panel mode fields (bpp, sync polarity, yuv420 flag) instead of letting the panel manage its own state. Pass adjusted_mode and bpp as parameters to msm_dp_panel_init_panel_info() and move the assignments inside it. Suggested-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-3-ea04113e8233@oss.qualcomm.com/
… and stream parts The DP_CONFIGURATION_CTRL register contains both link-level and stream-specific fields. Currently, msm_dp_ctrl_config_ctrl() configures all of them together. Separate the configuration into link parts and stream parts to support MST. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-4-ea04113e8233@oss.qualcomm.com/
…te function Refactor the MISC1_MISC0 register configuration into a standalone helper function to support MST. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-5-ea04113e8233@oss.qualcomm.com/
msm_dp_ctrl_configure_source_params() should only handle stream-related configuration. Move the link setup out of it so MST can program link and stream settings separately. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-6-ea04113e8233@oss.qualcomm.com/
Enable/Disable of DP pixel clock happens in multiple code paths leading to code duplication. Move it into individual helpers so that the helpers can be called wherever necessary. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-7-ea04113e8233@oss.qualcomm.com/
dp_display_enable() currently re-trains the link if needed and then enables the pixel clock, programs the controller to start sending the pixel stream. Split these two parts into prepare/enable APIs, to support MST bridges_enable insert the MST payloads funcs between enable stream_clks and program register. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-8-ea04113e8233@oss.qualcomm.com/
… parts dp_display_disable() handles special case of when monitor is disconnected from the dongle while the dongle stays connected thereby needing a separate function dp_ctrl_off_link_stream() for this. However with a slight rework this can still be handled by keeping common paths same for regular and special case. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-9-ea04113e8233@oss.qualcomm.com/
…ed to it With MST, multiple sinks share a single DP controller, so a cached panel in msm_dp_ctrl_private can no longer represent the per-stream sink. Drop the cache and pass panel explicitly to all stream-related dp_ctrl APIs. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-10-ea04113e8233@oss.qualcomm.com/
Split dp_ctrl_off() into stream and link parts so that for MST cases we can control the link and pixel parts separately. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-11-ea04113e8233@oss.qualcomm.com/
Move the common disable steps out of the sink_count check to make the flow easier to follow. No functional change intended. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-12-ea04113e8233@oss.qualcomm.com/
dp_bridge helpers take drm_bridge as an input and extract the dp_display object to be used in the dp_display module. Rather than doing it in a roundabout way, directly pass the dp_display object to these helpers so that the MST bridge can also re-use the same helpers. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-13-ea04113e8233@oss.qualcomm.com/
For MST, the link setup should only be done once when multiple sinks are enabled, while stream setup may run multiple times for each sink. Split the link-related preparation out of msm_dp_display_atomic_enable() so it can be called separately before the per-stream enable path. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-14-ea04113e8233@oss.qualcomm.com/
Pass struct msm_dp_panel to the display enable/disable helpers to make them easier to reuse for MST stream handling. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260609-dp_mstclean-v7-15-ea04113e8233@oss.qualcomm.com/
With MST, each DP controller can handle multiple streams. There shall be one dp_panel for each stream but the dp_display object shall be shared among them. To represent this abstraction, create a stream_id for each DP panel which shall be dynamically assigned to actual stream IDs by the MST path. For SST, default this to stream 0. In the MST path, panels are dynamically assigned to actual stream IDs at stream enable time by the MST layer. Use the stream ID to control the pixel clock of that respective stream by extending the clock handles and state tracking of the DP pixel clock to an array of max supported streams. The maximum streams currently is 4. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-mst-v5-1-2ed6aee1867a@oss.qualcomm.com/
…port DP controllers across different SoCs vary in the number of concurrent MST streams they can support. Rather than hardcoding per-platform values, the number of available pixel clocks in DT serves as a natural indicator since each stream requires a dedicated pixel clock. Introduce max_stream to capture this at initialization time and expose it for the MST module to use during setup. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-mst-v5-2-2ed6aee1867a@oss.qualcomm.com/
…locks Add support for additional pixel register blocks (p1, p2, p3) to enable 4‑stream MST pixel clocks. Introduce the helper functions msm_dp_read_pn and msm_dp_write_pn for pixel register programming. All pixel clocks share the same register layout but use different base addresses. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-mst-v5-3-2ed6aee1867a@oss.qualcomm.com/
In the DP MST architecture, stream 1 shares the same link clock as stream 0 but uses different register offsets within the same link register space. Use the dp_panel's stream_id to select the correct register offsets for stream 1 in dp_catalog. Also add stream 1 register defines. Streams 2 and 3 are not covered here, as they use separate link clocks and require separate handling. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-mst-v5-4-2ed6aee1867a@oss.qualcomm.com/
Whenever virtual channel slot allocation changes, the DP source must send the action control trigger sequence to notify the sink about the same. This would be applicable during the start and stop of the pixel stream. Add the infrastructure to be able to send ACT packets for the DP controller when operating in MST mode. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-mst-v5-5-2ed6aee1867a@oss.qualcomm.com/
…aths Call drm_dp_mst_atomic_check() from msm_atomic_check() so MST-specific state, such as connector and topology changes, is validated as part of the atomic check. Hook the MST helpers into atomic_commit_setup() and atomic_commit_tail() to support non-blocking atomic commits for DisplayPort MST, and ensure MST commits properly wait for dependencies. For SST, non-blocking commits are already handled via commit_tail(), which waits for dependencies in the DRM core. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-mst-v5-22-2ed6aee1867a@oss.qualcomm.com/
drm/msm/dp: introduce dp_mst_drm for MST stream management Add a dp_mst_drm layer to manage DP MST streams with a clear ownership model between encoder, panel and connector. Each MST stream is represented by a dedicated drm_encoder. At modeset initialization time, one (encoder, dp_panel) pair is created per stream_id and remains fixed for the lifetime of the driver. The dp_panel thus carries a stable stream context, including stream_id and pixel mapping. MST connectors are created and destroyed dynamically on hotplug and are attached to a dp_panel through atomic routing. During an atomic commit, connectors are associated with encoders via atomic_best_encoder(), forming a temporary binding for the duration of the commit. Encoder helper callbacks drive the MST stream lifecycle, including timeslot allocation, link enable/disable and payload programming. A per-MST-instance lock serializes operations on shared link state across multiple streams. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-mst-v5-23-2ed6aee1867a@oss.qualcomm.com/
Introduce an MST connector abstraction for DP MST, with each MST connector associated with a DP panel and connected through a DRM bridge to an MST encoder. The connector is only used for MST helper callbacks, such as detect, get_modes, and get_encoder. Display enable/disable, hotplug handling, and modeset sequencing continue to be handled by the bridge path. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-mst-v5-24-2ed6aee1867a@oss.qualcomm.com/
Add HPD callback for the MST module which shall be invoked from the dp_display's HPD handler to perform MST specific operations in case of HPD. In MST case, route the HPD messages to MST module. Signed-off-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-mst-v5-25-2ed6aee1867a@oss.qualcomm.com/
The DisplayPort standard defines a special kind of events called IRQ. These events are used to notify DP Source about the events on the Sink side. It is extremely important for DP MST handling, where the MST events are reported through this IRQ. In case of the USB-C DP AltMode there is no actual HPD pulse, but the events are reported through the bits in the AltMode VDOs. Rename drm_connector_oob_hotplug_event() to drm_connector_dp_oob_status() and extend its interface to report IRQ events to the DisplayPort Sink drivers. Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260608-hpd-irq-events-v4-1-30b62b335487@oss.qualcomm.com/
The DisplayPort standard defines a special kind of HPD events called IRQ_HPD. These events are used to notify DP Source about the events on the Sink side. Extend drm_connector_funcs::oob_hotplug_event() to pass the notifications about the IRQ_HPD events down to the individual drivers, letting them handle those as required. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260608-hpd-irq-events-v4-2-30b62b335487@oss.qualcomm.com/
The DisplayPort standard defines a special kind of HPD events called IRQ_HPD. These events are used to notify DP Source about the events on the Sink side. Let users of aux-hpd, the UCSI and PMIC GLINK drivers pass the IRQ_HPD events to the DisplayPort drivers. The drm_aux_hpd_bridge_notify() is kept to ease merging of the series, preventing extra cross-tree merges. It will be removed once all drivers are converted. The drm_bridge_hpd_notify() function is kept for the drivers which only care about the connector status and will always pass DRM_CONNECTOR_NO_EXTRA_STATUS as the extra status. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260608-hpd-irq-events-v4-3-30b62b335487@oss.qualcomm.com/
The DisplayPort standard defines a special kind of HPD events called IRQ_HPD. These events are used to notify DP Source about the events on the Sink side. Bridge drivers report these events through the drm_bridge_hpd_notify_extra(). Pass down the extra status to the HPD callback, specified during the drm_bridge_hpd_enable(), letting underlying drivers (e.g. drm_bridge_connector) to receive these events. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Acked-by: Francesco Dolcini <francesco.dolcini@toradex.com> # lt8912b Link: https://lore.kernel.org/all/20260608-hpd-irq-events-v4-4-30b62b335487@oss.qualcomm.com/
The DisplayPort standard defines a special kind of HPD events called IRQ_HPD. These events are used to notify DP Source about the events on the Sink side. Pass down the extra status to the bridge drivers via the hpd_notify() callback, letting DP bridges to act accordingly. Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260608-hpd-irq-events-v4-5-30b62b335487@oss.qualcomm.com/
The DisplayPort standard defines a special kind of HPD events called IRQ_HPD. These events are used to notify DP Source about the events on the Sink side, for example DP MST events. Let the MSM DisplayPort driver properly track and handle IRQ_HPD delivered over the OOB events (e.g. from the USB-C AltMode handler). Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260608-hpd-irq-events-v4-6-30b62b335487@oss.qualcomm.com/
The DisplayPort standard defines a special kind of HPD events called IRQ_HPD. These events are used to notify DP Source about the events on the Sink side. Pass IRQ_HPD events from the firmware to the HPD bridge, letting those to be delivered to the DisplayPort driver. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Acked-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260608-hpd-irq-events-v4-7-30b62b335487@oss.qualcomm.com/
The DisplayPort standard defines a special kind of HPD events called IRQ_HPD. These events are used to notify DP Source about the events on the Sink side. Pass IRQ_HPD events from the EC to the HPD bridge, letting those to be delivered to the DisplayPort driver. Reviewed-by: Pengyu Luo <mitltlatltl@gmail.com> Acked-by: Heikki Krogerus <heikki.krogerus@linux.intel.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260608-hpd-irq-events-v4-8-30b62b335487@oss.qualcomm.com/
…g events The bridge connector framework currently invokes all bridge hpd_notify() callbacks and unconditionally emits a connector hotplug event afterwards. However, not every HPD notification requires a userspace hotplug event. In particular, DP MST bridges may use hpd_notify() to propagate HPD and IRQ notifications through the bridge chain while the actual hotplug handling is performed by the DRM DP MST core. Connector creation, removal and userspace hotplug events are already managed by the MST topology framework. Allow hpd_notify() implementations to suppress the bridge connector hotplug event by introducing a bool *send_hotplug parameter. Drivers can clear this flag when HPD processing should not result in a connector hotplug notification. A NULL pointer indicates that hotplug suppression is not supported by the caller, such as the connector detect polling path. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-msttypec-v1-1-646a10256233@oss.qualcomm.com/
…y HPD events The bridge connector HPD handling path currently updates connector->status for every hpd_notify() invocation. This does not work well for IRQ-only notifications where the event being reported is carried by extra_status and no connector status transition is associated with it. One example is DP MST. HPD IRQs are propagated through drm_bridge_hpd_notify_*() so that bridge drivers can process the notification. During MST operation, however, the SST connector attached to the bridge connector is intentionally kept disconnected while the MST topology manager handles all connector creation, removal and hotplug processing. Updating connector->status for an IRQ-only MST notification may cause the SST connector state to oscillate between connected and disconnected depending on the notification path. These artificial state transitions can later be detected by the polling logic and result in unnecessary hotplug events being generated. Userspace then re-probes connector status, potentially triggering the same sequence again. Treat notifications with status == connector_status_unknown and a valid extra_status as IRQ-only events. Forward the notification to bridge drivers without modifying connector->status. This keeps IRQ delivery working while leaving connector state management to the component that actually owns it, such as the DP MST topology framework. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-msttypec-v1-2-646a10256233@oss.qualcomm.com/
…tion The DP MST framework already generates the required hotplug events for MST topology changes. Suppress connector hotplug event generation from the bridge connector path while MST is active, and continue propagating HPD notifications to the DP driver. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-msttypec-v1-3-646a10256233@oss.qualcomm.com/
MST reuses the SST connector bridge to propagate HPD IRQ events through the bridge chain. For IRQ_HPD notifications there is no connector state transition to report. Use connector_status_unknown together with DRM_CONNECTOR_DP_IRQ_HPD so that the bridge connector framework treats them as IRQ-only notifications and forwards them without modifying connector state. The DP driver handles IRQ_HPD events based on DRM_CONNECTOR_DP_IRQ_HPD rather than connector status transitions. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-msttypec-v1-4-646a10256233@oss.qualcomm.com/
… enabled When MST becomes active, the initial HPD plug notification updates the SST connector state to connected. However, the subsequent SST connector detect path reports disconnected while MST is enabled. This connected -> disconnected transition is then observed by the polling logic and may result in an unnecessary hotplug event. Set the SST connector state to disconnected immediately after MST is initialized so that the detect path does not introduce a transient state change. Signed-off-by: Yongxing Mou <yongxing.mou@oss.qualcomm.com> Link: https://lore.kernel.org/all/20260629-msm-dp-msttypec-v1-5-646a10256233@oss.qualcomm.com/
…nnected PipeWire treats a non-zero return from prepare as fatal, marking the DP audio device as a dummy sink when the cable is unplugged. The active_stream_cnt guard already prevents any unclocked hardware access, so return success instead of -EINVAL when the link is not active. Upstream uses variable of power_on while 0.0 kernel uses active_stream_cnt. Hence we use the active_stream_cnt in the current pull request. Link: https://lore.kernel.org/all/20260616151252.3599089-2-kumar.singh@oss.qualcomm.com/ Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com>
qcomlnxci
requested review from
a team,
Rajesh Kemisetti (quic-rajeshk) and
riteshk-quic
and removed request for
a team
July 20, 2026 06:09
…tdown On reboot, a late DP hot-plug-detect (HPD) IRQ can fire after apps_smmu has already disabled translation for the display subsystem, causing the HPD thread to kick off a new modeset that drives DPU/DP hardware and DMA through a stale IOMMU mapping. DPU's own .shutdown disables all CRTCs first, but a pending HPD IRQ thread wakes up afterwards, reads the DPCD, and fires an unsolicited hotplug event that triggers a second atomic commit turning the display back on -- right as the IOMMU is disabling translation: systemd-shutdown[1]: Rebooting. msm_dpu: drm_atomic_commit: committing (shutdown disabling CRTCs) arm-smmu 3da0000.iommu: disabling translation msm_dpu: drm_dp_read_dpcd_caps (late HPD IRQ thread wakes up) msm_dpu: drm_sysfs_connector_hotplug_event: DP-1 hotplug event msm_dpu: drm_client_modeset_probe: DP-1 found preferred mode msm_dpu: drm_atomic_commit: committing (unsolicited, re-enables display) dpu_crtc_commit_kickoff: crtc94 first commit arm-smmu 15200000.iommu: disabling translation Mask and flush the IRQ in .shutdown so no HPD event can retrigger a modeset once shutdown has started. Reported on lemans-evk and monaco-evk during reboot stress testing. Link: https://lore.kernel.org/all/20260717-dpshutdown-v1-1-b062c2f7dfb1@oss.qualcomm.com/ Assisted-by: Claude:claude-sonnet-5 Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com> Signed-off-by: Yash Gupta <yash.gupta@oss.qualcomm.com>
yashgupta2126
force-pushed
the
yg-tech-mm-drm
branch
from
July 20, 2026 06:16
188af31 to
ced1fdb
Compare
yashgupta2126
changed the title
|
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. |
|
Merge Check Failed: No Component Found Configuration Error: No component found for branch 'tech/mm/drm'. There is no component associated with the provided branch in Polaris. Please verify the branch configuration. Branch: |
riteshk-quic
force-pushed
the
tech/mm/drm
branch
2 times, most recently
from
July 22, 2026 11:56
8b56f4f to
815a70f
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
On reboot, a late DP hot-plug-detect (HPD) IRQ can fire after apps_smmu has already disabled translation for the display subsystem, causing the HPD thread to kick off a new modeset that drives DPU/DP hardware and DMA through a stale IOMMU mapping.
DPU's own .shutdown disables all CRTCs first, but a pending HPD IRQ thread wakes up afterwards, reads the DPCD, and fires an unsolicited hotplug event that triggers a second atomic commit turning the display back on -- right as the IOMMU is disabling translation:
systemd-shutdown[1]: Rebooting.
msm_dpu: drm_atomic_commit: committing (shutdown disabling CRTCs)
arm-smmu 3da0000.iommu: disabling translation
msm_dpu: drm_dp_read_dpcd_caps (late HPD IRQ thread wakes up)
msm_dpu: drm_sysfs_connector_hotplug_event: DP-1 hotplug event
msm_dpu: drm_client_modeset_probe: DP-1 found preferred mode
msm_dpu: drm_atomic_commit: committing (unsolicited, re-enables display)
dpu_crtc_commit_kickoff: crtc94 first commit
arm-smmu 15200000.iommu: disabling translation
Mask and flush the IRQ in .shutdown so no HPD event can retrigger a modeset once shutdown has started. Reported on lemans-evk and monaco-evk during reboot stress testing.
Link: https://lore.kernel.org/all/20260717-dpshutdown-v1-1-b062c2f7dfb1@oss.qualcomm.com/
CRs-Fixed: 4573119