Repository navigation
Conversation
mainline inclusion from mainline-v6.14-rc1 category: bugfix GuC to host communication is interrupt driven, the handling has 3 parts: interrupt context, tasklet and request queue worker. During GuC reset prepare, interrupt is disabled before destroy contexts steps start. The IRQ and worker are flushed to finish any outstanding in-progress message handling. But, the tasklet flush is missing, it might causes 2 race conditions: 1. Tasklet runs after IRQ flushed, add request to queue after worker flush started, causes unexpected G2H message request processing, meanwhile, reset prepare code already get the context destroyed. This will causes error reported about bad context state. (https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/11349 and https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12303) 2. Tasklet runs after intel_guc_submission_reset_prepare, ct_try_receive_message start to run, while intel_uc_reset_prepare already finished guc sanitize and set ct->enable to false. This will causes warning on incorrect ct->enable state. (https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12439) Add the missing tasklet flush to flush all 3 parts. Signed-off-by: Zhanjun Dong <zhanjun.dong@intel.com> Reviewed-by: Alan Previn <alan.previn.teres.alexis@intel.com> Signed-off-by: John Harrison <John.C.Harrison@Intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241104214103.214702-1-zhanjun.dong@intel.com (cherry picked from commit b939a08) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.14-rc1 category: bugfix This reverts commit 483f7d9. This needs to be reverted since HDCP even after updating the connector state HDCP property we don't reenable HDCP until the next commit in which the CP Property is set causing compliance to fail. --v2 -Fix build issue [Dnyaneshwar] Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Dnyaneshwar Bhadane <dnyaneshwar.bhadane@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250103084517.239998-1-suraj.kandpal@intel.com (cherry picked from commit fcf73e2) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.15-rc1 category: bugfix When topology changes, before beginning a new HDCP authentication by sending AKE_init message we need to first authenticate only the repeater. Only after repeater authentication failure, it makes sense to start a new HDCP authentication. Even though it made sense to not enable HDCP directly from check_link and schedule it for later, repeater authentication needs to be done immediately. --v2 -Fix comment grammatical errors [Ankit] Fixes: 47ef55a ("drm/i915/hdcp: Don't enable HDCP2.2 directly from check_link") Signed-off-by: Suraj Kandpal <suraj.kandpal@intel.com> Reviewed-by: Ankit Nautiyal <ankit.k.nautiyal@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20241217083723.2883317-1-suraj.kandpal@intel.com (cherry picked from commit 605a33e) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix Call drm_encoder_init() earlier so that we don't have to keep passing the i915/dev_priv around separately. v2: Reorder drm_encoder_cleanup() in the error path (Jani) Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230825134431.24391-3-ville.syrjala@linux.intel.com (cherry picked from commit 0eb8252) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix Each SDVO device can have up to three sets of DDC pins. Currently we just register a single i2c_adapter for the entire SDVO device and semi-randomly pick the "correct" set of DDC pins during intel_sdvo_tmds_sink_detect(). This doesn't make any real sense especially if we have multiple outputs each with their own dedicated DDC bus. Let's clean up this mess and register a dedicated i2c_adapter for each of the possible pin pairs. Each output (ie. connector) can then pick the correct i2c_adapter to use for its DDC bus. And we can just switch over to drm_connector_init_with_ddc() to take care of the connector->ddc association, which also populates the "ddc" sysfs symlink as a bonus. And now that things are based on the actual connector we can also nuke the sketchy sdvo->controller_output thing. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230825134431.24391-6-ville.syrjala@linux.intel.com (cherry picked from commit c0ff6c6) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix To reduce the guesswork a bit let's print out the SDVO device i2c bus and slave address during init. Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230825134431.24391-7-ville.syrjala@linux.intel.com (cherry picked from commit 9c7e9db) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
mainline inclusion from mainline-v6.7-rc1 category: bugfix We aren't intending to mutate the SDVO device mapping structs, so make them const. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20230829113920.13713-13-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 32c3215) Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
Reviewer's GuideBackports i915 fixes for HDCP link recovery, SDVO multi-DDC/EDID routing, and GuC reset synchronization. The SDVO changes are the largest component, replacing a shared mutable DDC proxy with three independently registered adapters selected per connector, while initialization, cleanup, and error paths are updated accordingly. Sequence diagram for SDVO connector-specific DDC and EDID routingsequenceDiagram
participant Connector
participant SDVO
participant DDCProxy
participant GMBUS
participant Display
Connector->>SDVO: intel_sdvo_connector_init()
SDVO->>SDVO: intel_sdvo_select_ddc_bus()
SDVO->>Connector: drm_connector_init_with_ddc()
Connector->>Display: intel_sdvo_get_edid()
Display->>DDCProxy: drm_edid_read_ddc()
DDCProxy->>SDVO: __intel_sdvo_set_control_bus_switch()
DDCProxy->>GMBUS: master_xfer()
GMBUS-->>Display: EDID
Sequence diagram for GuC reset tasklet synchronizationsequenceDiagram
participant Reset as GuC reset
participant GuC
participant Tasklet
participant Worker
Reset->>GuC: intel_guc_submission_reset_prepare()
GuC->>Tasklet: tasklet_disable()
GuC->>Tasklet: tasklet_enable()
GuC->>GuC: guc_flush_submissions()
GuC->>GuC: guc_flush_destroyed_contexts()
GuC->>Worker: flush_work()
Sequence diagram for HDCP link recoverysequenceDiagram
participant HDCP
participant Connector
participant Auth
HDCP->>Connector: intel_hdcp_check_link()
HDCP->>Auth: intel_hdcp1_enable()
alt HDCP1 enable fails
HDCP->>Connector: intel_hdcp_update_value(DESIRED)
end
HDCP->>Connector: intel_hdcp2_check_link()
HDCP->>Auth: hdcp2_authenticate_repeater_topology()
alt topology authentication succeeds
HDCP->>Connector: intel_hdcp_update_value(ENABLED)
end
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
There was a problem hiding this comment.
🟡 Changes recommended
An unguarded NULL DDC adapter can crash i915 initialization, while a skipped HDCP stream-management exchange can leave protected output blank.
2 open issues
What changed in this PR
Backports upstream i915 display and GuC stability fixes to the Linux 6.6.y kernel.
Changes:
- Retry HDCP1 enablement and re-authenticate HDCP2 repeater topology changes.
- Introduce per-output SDVO DDC routing and refactor EDID access and adapter cleanup.
- Synchronize the GuC receive tasklet before flushing pending reset work.
| File | Description |
|---|---|
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c |
Synchronizes receive-tasklet execution during reset preparation. |
drivers/gpu/drm/i915/display/intel_sdvo.c |
Adds per-output DDC proxies and updates connector initialization and cleanup. |
drivers/gpu/drm/i915/display/intel_hdcp.c |
Adds HDCP1 recovery retries and HDCP2 topology re-authentication. |
Review effort: Max
| mutex_lock(&i915->drm.mode_config.mutex); | ||
|
|
||
| intel_ddc_get_modes(connector, &intel_sdvo->ddc); | ||
| intel_ddc_get_modes(connector, connector->ddc); |
| ret = hdcp2_authenticate_repeater_topology(connector); | ||
| if (!ret) { |


Summary by Sourcery
Backport i915 display and GuC stability fixes for HDCP recovery, SDVO DDC routing, and reset handling.
Bug Fixes:
Enhancements: