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

[An Wu]

Hi Mika

Another approach I considered is using register_module_notifier() to
detect when a display driver module is loaded, then retrigger the DP
tunnel setup. However, since struct module does not carry any device
class or subsystem metadata, there is no generic way to identify
whether a loaded module is a display driver. We would need to maintain
a hardcoded list of known GPU module names (i915, xe, amdgpu, etc.),
which is fragile and not scalable.

BR
    An

On Mon, Jun 1, 2026 at 10:45 AM An Wu <an.wu@xxxxxxxxxxxxx> wrote:
>
> Hi Mika,
>
>
> Thank you for the suggestion and for explaining the rationale behind
> the current timeout value.
>
> In our case, unfortunately, increasing the timeout alone wouldn't fully
> address the issue. We have LUKS encryption in the middle of the boot
> process, which means the timing of user interaction is unpredictable —
> users may walk away and return at arbitrary points, making it difficult
> to rely on any fixed timeout value regardless of how generous it is.
>
> Appreciate you sharing your perspective on this.
> It helps us better understand the constraints we need to work within.
> We’ll continue investigating how to address this problem under the
> current conditions.
>
> Best regards,
>
> An
>
> On Thu, May 28, 2026 at 6:29 PM Mika Westerberg
> <mika.westerberg@xxxxxxxxxxxxxxx> wrote:
> >
> > 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.