linux.git/drivers/thunderbolt/tb.c, branch for-next

thunderbolt: Improve redrive mode handling

2024-12-16T07:59:38+00:00

When USB-C monitor is connected directly to Intel Barlow Ridge host, it
goes into "redrive" mode that basically routes the DisplayPort signals
directly from the GPU to the USB-C monitor without any tunneling needed.
However, the host router must be powered on for this to work. Aaron
reported that there are a couple of cases where this will not work with
the current code:

  - Booting with USB-C monitor plugged in.
  - Plugging in USB-C monitor when the host router is in sleep state
    (runtime suspended).
  - Plugging in USB-C device while the system is in system sleep state.

In all these cases once the host router is runtime suspended the picture
on the connected USB-C display disappears too. This is certainly not
what the user expected.

For this reason improve the redrive mode handling to keep the host
router from runtime suspending when detect that any of the above cases
is happening.

Fixes: a75e0684efe5 ("thunderbolt: Keep the domain powered when USB4 port is in redrive mode")
Reported-by: Aaron Rainbolt 
Closes: https://lore.kernel.org/linux-usb/20241009220118.70bfedd0@kf-ir16/
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg

thunderbolt: Honor TMU requirements in the domain when setting TMU mode

2024-10-21T06:42:42+00:00

Currently, when configuring TMU (Time Management Unit) mode of a given
router, we take into account only its own TMU requirements ignoring
other routers in the domain. This is problematic if the router we are
configuring has lower TMU requirements than what is already configured
in the domain.

In the scenario below, we have a host router with two USB4 ports: A and
B. Port A connected to device router #1 (which supports CL states) and
existing DisplayPort tunnel, thus, the TMU mode is HiFi uni-directional.

1. Initial topology

          [Host]
         A/
         /
 [Device #1]
   /
Monitor

2. Plug in device #2 (that supports CL states) to downstream port B of
   the host router

         [Host]
        A/    B\
        /       \
 [Device #1]    [Device #2]
   /
Monitor

The TMU mode on port B and port A will be configured to LowRes which is
not what we want and will cause monitor to start flickering.

To address this we first scan the domain and search for any router
configured to HiFi uni-directional mode, and if found, configure TMU
mode of the given router to HiFi uni-directional as well.

Cc: stable@vger.kernel.org
Signed-off-by: Gil Fine 
Signed-off-by: Mika Westerberg

Merge tag 'thunderbolt-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next

2024-05-10T09:25:22+00:00

Mika writes:

thunderbolt: Changes for v6.10 merge window

This includes following USB4/Thunderbolt changes for the v6.10 merge
window:

  - Enable NVM firmare upgrade on Intel Maple Ridge Thunderbolt 4
    controller
  - Improve USB3 tunnel bandwidth calculation
  - Improve sideband access
  - Minor cleanups and fixes.

All these have been in linux-next with no reported issues.

* tag 'thunderbolt-for-v6.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt:
  thunderbolt: Correct trace output of firmware connection manager packets
  thunderbolt: Fix kernel-doc for tb_tunnel_alloc_dp()
  thunderbolt: Fix uninitialized variable in tb_tunnel_alloc_usb3()
  thunderbolt: There are only 5 basic router registers in pre-USB4 routers
  thunderbolt: No need to loop over all retimers if access fails
  thunderbolt: Increase sideband access polling delay
  thunderbolt: Get rid of TB_CFG_PKG_PREPARE_TO_SLEEP
  thunderbolt: Use correct error code with ERROR_NOT_SUPPORTED
  thunderbolt: Allow USB3 bandwidth to be lower than maximum supported
  thunderbolt: Fix calculation of consumed USB3 bandwidth on a path
  thunderbolt: Enable NVM upgrade support on Intel Maple Ridge

thunderbolt: Fix calculation of consumed USB3 bandwidth on a path

2024-04-12T06:43:32+00:00

Currently, when setup a new USB3 tunnel that is starting from downstream USB3
adapter of first depth router (or deeper), to upstream USB3 adapter of a second
depth router (or deeper), we calculate consumed bandwidth. For this calculation
we take into account first USB3 tunnel consumed bandwidth while we shouldn't,
because we just recalculating the first USB3 tunnel allocated bandwidth.

Fix that, so that more bandwidth is available for the new USB3 tunnel being
setup.

While there, fix the kernel-doc to decribe more accurately the purpose of the
function.

Signed-off-by: Gil Fine 
Signed-off-by: Mika Westerberg

thunderbolt: Avoid notify PM core about runtime PM resume

2024-04-10T07:49:58+00:00

Currently we notify PM core about occurred wakes after any resume. This
is not actually needed after resume from runtime suspend. Hence, notify
PM core about occurred wakes only after resume from system sleep. Also,
if the wake occurred in USB4 router upstream port, we don't notify the
PM core about it since it is not actually needed and can cause
unexpected autowake (e.g. if /sys/power/wakeup_count is used).

While there add the missing kernel-doc for tb_switch_resume().

Signed-off-by: Gil Fine 
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg

thunderbolt: Do not create DisplayPort tunnels on adapters of the same router

2024-04-02T05:51:12+00:00

Probably due to a firmware bug Dell TB16 dock announces that one of its
DisplayPort adapters is actually DP IN. Now this is possible and used
with some external GPUs but not likely in this case as we are dealing
with a dock. Anyways the problem is that the driver tries to create a
DisplayPort tunnel between adapters of the same router which then shows
to user that there is no picture on the display (because there are no
available DP OUT adapters on the dock anymore).

Fix this by not creating DisplayPort tunnels between adapters that are
on the same router.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/10265
Fixes: 274baf695b08 ("thunderbolt: Add DP IN added last in the head of the list of DP resources")
Cc: Gil Fine 
Cc: stable@vger.kernel.org
Signed-off-by: Mika Westerberg

thunderbolt: Keep the domain powered when USB4 port is in redrive mode

2024-02-26T07:12:12+00:00

If a DiplayPort cable is directly connected to the host routers USB4
port, there is no tunnel involved but the port is in "redrive" mode
meaning that it is re-driving the DisplayPort signals from its
DisplayPort source. In this case we need to keep the domain powered on
otherwise once the domain enters D3cold the connected monitor blanks
too.

Since this happens only on Intel Barlow Ridge add a quirk that takes
runtime PM reference if we detect that the USB4 port entered redrive
mode (and release it once it exits the mode).

Signed-off-by: Mika Westerberg

thunderbolt: Improve DisplayPort tunnel setup process to be more robust

2024-02-16T10:29:23+00:00

After DisplayPort tunnel setup, we add verification that the DPRX
capabilities read process completed. Otherwise, we bail out, teardown
the tunnel, and try setup another DisplayPort tunnel using next
available DP IN adapter. We do so till all DP IN adapters tried. This
way, we avoid allocating DP IN adapter and (bandwidth for it) for
unusable tunnel.

Signed-off-by: Gil Fine 
Signed-off-by: Mika Westerberg

thunderbolt: Reserve released DisplayPort bandwidth for a group for 10 seconds

2024-02-16T10:29:23+00:00

The USB4 spec says that the Connection Manager should reserve the
bandwidth that is released in the same group for 10 seconds before it
can be shared with other groups. Add support for this. We also delay the
symmetric transition by that same 10 seconds to avoid any unnecessary
transitions (i.e if the released bandwidth is used by another
DisplayPort tunnel in the same group the link can stay asymmetric the
whole time).

Signed-off-by: Mika Westerberg

thunderbolt: Introduce tb_tunnel_direction_downstream()

2024-02-16T10:29:23+00:00

This helper takes tunnel as parameter. Convert existing code to call
this where possible.

No functional changes.

Signed-off-by: Mika Westerberg