Re: [PATCH] thunderbolt: Defer DP tunnel teardown until display driver is ready

[Mika Westerberg <mika.westerberg@linux.intel.com>]

Hi,

On Thu, May 28, 2026 at 09:03:30AM +0800, An Wu wrote:
> Hi Mika,
> 
> Thank you for the feedback.
> 
> Sorry for the mess, and I understand the concern that the Thunderbolt
> CM core should not call PCI-specific functions, especially since the
> direction is to support non-PCIe hosts as well.
> 
> Putting graphics drivers into the initramfs does not look practical
> for us, because we may need to include many possible graphics drivers
> and dependencies, which would increase the initramfs size and
> complexity. Moving Thunderbolt out of the initramfs may also cause
> regressions for users relying on Thunderbolt docks early in boot, such
> as keyboards in the recovery/LUKS shell or network devices for
> early/rootfs use cases.
> 
> The problem I am trying to solve is that graphics driver readiness can
> affect Thunderbolt DP tunneling, but the graphics and Thunderbolt
> drivers currently run independently without any coordination. As a
> result, Thunderbolt may treat a temporary graphics-side readiness
> issue as a permanent DP tunnel failure.
> 
> So the goal is not to make Thunderbolt depend on PCI, but to find an
> acceptable way for these components to coordinate, or for Thunderbolt
> to retry/check readiness in a more generic way without adding
> PCI-specific logic into the CM core.
> 
> Could you please give us guidance on what direction would be
> acceptable upstream?

The DPRX timeout is there for a reason, although the reason is not really
that common. Basically if there is nothing connected to the DP IN we can
detect that and be able to use another DP IN to provide user a working DP
tunnel.

The timeout itself is currently 10 + 2 = 12s to allow i915 enter runtime
suspend and still be able to detect (via polling) a connected monitor.
However, it is not really "written in stone". VESA spec wants it to be 5s
but for our usage it is way too short. I have no problem increasing it
either but then some users may suffer due to the above reasons (if a DP IN
is not connected). Maybe increasing it is a reasonable compromise?

The other option is to put the DP IN to a "penalty box" for a while but I
don't think this helps because you need the hotplug event for the DP OUT
part and that's not happening after we have acked it.