Skip to content

[Deepin-Kernel-SIG] [linux 6.6.y] [Upstream] i915 fixes backport - #2246

Merged
opsiff merged 7 commits into
deepin-community:linux-6.6.yfrom
opsiff:linux-6.6.y-2026-11-04-i915-fix-4
Nov 4, 2026
Merged

opsiff merged 7 commits into
deepin-community:linux-6.6.yfrom
opsiff:linux-6.6.y-2026-11-04-i915-fix-4

Conversation

@opsiff

@opsiff opsiff commented Nov 4, 2026 •

Copy link
Copy Markdown
Member

Summary by Sourcery

Backport i915 display and GuC stability fixes for HDCP recovery, SDVO DDC routing, and reset handling.

Bug Fixes:

  • Improve HDCP link recovery by retrying HDCP1 enablement and re-authenticating HDCP2 repeater topology changes.
  • Fix Intel SDVO DDC handling to support per-output DDC buses and reliable EDID access and cleanup.
  • Ensure GuC submission reset flushes the receive tasklet before processing pending work.

Enhancements:

  • Refactor SDVO connector and DDC proxy management for safer initialization, selection, and teardown across multiple DDC buses.

zhanjun and others added 7 commits November 4, 2026 21:58
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>
@sourcery-ai

sourcery-ai Bot commented Nov 4, 2026 •

Copy link
Copy Markdown

Reviewer's Guide

Backports 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 routing

sequenceDiagram
    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
Loading

Sequence diagram for GuC reset tasklet synchronization

sequenceDiagram
    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()
Loading

Sequence diagram for HDCP link recovery

sequenceDiagram
    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
Loading

File-Level Changes

Change Details Files
Improve HDCP link recovery so failed HDCP1 checks retry enablement and HDCP2 repeater topology changes can complete authentication without unnecessary full renegotiation.
  • Retry HDCP1 enablement during link checks and restore the desired content-protection state on failure.
  • Authenticate HDCP2 repeater topology changes and mark content protection enabled when successful.
drivers/gpu/drm/i915/display/intel_hdcp.c
Refactor SDVO DDC handling to expose separate proxy I2C adapters for each possible DDC bus and bind connectors directly to the appropriate adapter.
  • Replace the single mutable DDC adapter and output-state fields with three per-bus proxy adapters.
  • Select a connector-specific DDC bus from VBT mappings or output priority, and initialize connectors with drm_connector_init_with_ddc().
  • Update proxy transfer and locking callbacks to use per-bus state, add adapter lifecycle cleanup, and improve initialization/error handling and diagnostics.
  • Preserve fallback EDID probing behavior through connector DDC assignments and add null checks for unavailable adapters.
drivers/gpu/drm/i915/display/intel_sdvo.c
Ensure GuC submission reset drains pending receive-tasklet work before flushing submissions and destroyed contexts.
  • Temporarily disable and re-enable the GuC CT receive tasklet to flush it during reset preparation.
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c

Tips and commands

Interacting with Sourcery

  • Trigger a new review: Comment @sourcery-ai review on the pull request.
  • Continue discussions: Reply directly to Sourcery's review comments.
  • Generate a GitHub issue from a review comment: Ask Sourcery to create an
    issue from a review comment by replying to it. You can also reply to a
    review comment with @sourcery-ai issue to create an issue from it.
  • Generate a pull request title: Write @sourcery-ai anywhere in the pull
    request title to generate a title at any time. You can also comment
    @sourcery-ai title on the pull request to (re-)generate the title at any time.
  • Generate a pull request summary: Write @sourcery-ai summary anywhere in
    the pull request body to generate a PR summary at any time exactly where you
    want it. You can also comment @sourcery-ai summary on the pull request to
    (re-)generate the summary at any time.
  • Generate reviewer's guide: Comment @sourcery-ai guide on the pull
    request to (re-)generate the reviewer's guide at any time.
  • Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
    pull request to resolve all Sourcery comments. Useful if you've already
    addressed all the comments and don't want to see them anymore.
  • Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
    request to dismiss all existing Sourcery reviews. Especially useful if you
    want to start fresh with a new review - don't forget to comment
    @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

  • Enable or disable review features such as the Sourcery-generated pull request
    summary, the reviewer's guide, and others.
  • Change the review language.
  • Add, remove or edit custom review instructions.
  • Adjust other review settings.

Getting Help

@deepin-ci-robot

Copy link
Copy Markdown

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please ask for approval from opsiff. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@sourcery-ai sourcery-ai Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey - I've reviewed your changes and they look great!


Sourcery is free for open source - if you like our reviews please consider sharing them ✨

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 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);
Comment on lines +2066 to +2067
ret = hdcp2_authenticate_repeater_topology(connector);
if (!ret) {
@opsiff
opsiff merged commit 77a346c into deepin-community:linux-6.6.y Nov 4, 2026
12 of 13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants