linux/drivers/thunderbolt/path.c, branch v5.9

thunderbolt: Add USB3 bandwidth management

2020-06-22T16:58:20Z

USB3 supports both isochronous and non-isochronous traffic. The former requires guaranteed bandwidth and can take up to 90% of the total bandwidth. With USB4 USB3 is tunneled over USB4 fabric which means that we need to make sure there is enough bandwidth allocated for the USB3 tunnels in addition to DisplayPort tunnels. Whereas DisplayPort bandwidth management is static and done before the DP tunnel is established, the USB3 bandwidth management is dynamic and allows increasing and decreasing the allocated bandwidth according to what is currently consumed. This is done through host router USB3 downstream adapter registers. This adds USB3 bandwidth management to the software connection manager so that we always try to allocate maximum bandwidth for DP tunnels and what is left is allocated for USB3. Signed-off-by: Mika Westerberg

thunderbolt: Check that both ports are reachable when allocating path

2020-06-22T16:58:19Z

Add sanity check that given src and dst ports are reachable through path walk before allocating a path. If they are not then bail out early. Signed-off-by: Mika Westerberg

thunderbolt: Make tb_path_alloc() work with tree topologies

2020-06-22T16:58:19Z

With USB4, topologies are not limited to daisy-chains anymore so when calculating how many hops are between two ports we need to walk the whole path instead. Add helper function tb_for_each_port_on_path() that can be used to walk over each port on a path and make tb_path_alloc() to use it. Signed-off-by: Mika Westerberg

thunderbolt: Add bandwidth management for Display Port tunnels

2019-11-02T09:13:31Z

Titan Ridge supports Display Port 1.4 which adds HBR3 (High Bit Rate) rates that may be up to 8.1 Gb/s over 4 lanes. This translates to effective data bandwidth of 25.92 Gb/s (as 8/10 encoding is removed by the DP adapters when going over Thunderbolt fabric). If another high rate monitor is connected we may need to reduce the bandwidth it consumes so that it fits into the total 40 Gb/s available on the Thunderbolt fabric. Signed-off-by: Mika Westerberg

thunderbolt: Add support for lane bonding

2019-11-02T09:13:31Z

Lane bonding allows aggregating two 10/20 Gb/s (depending on the generation) lanes into a single 20/40 Gb/s bonded link. This allows sharing the full bandwidth more efficiently. In order to establish lane bonding we need to check that lane bonding is possible through link controller and that both ends of the link actually supports 2x widths. This also means that all the paths should be established through the primary port so update tb_path_alloc() to handle this as well. Lane bonding is supported starting from Falcon Ridge (2nd generation) controllers. We also expose the current speed and number of lanes under each device except the host router following similar attribute naming than USB bus. Expose speed and number of lanes for both directions to allow possibility of asymmetric link in the future. Signed-off-by: Mika Westerberg

thunderbolt: Reword output of tb_dump_hop()

2019-04-18T08:18:54Z

While tb_dump_hop() prints out necessary information it is in format that is quite hard to read from the logs especially when one needs to follow the path to see that the setup is correct. Signed-off-by: Mika Westerberg

thunderbolt: Make rest of the logging to happen at debug level

2019-04-18T08:18:53Z

Now that the driver can handle every possible tunnel types there is no point to log everything as info level so turn these to happen at debug level instead. While at it remove duplicated tunnel activation log message (tb_tunnel_activate() calls tb_tunnel_restart() which print the same message) and add one missing '\n' termination. Signed-off-by: Mika Westerberg

thunderbolt: Add support for DMA tunnels

2019-04-18T08:18:53Z

In addition to PCIe and Display Port tunnels it is also possible to create tunnels that forward DMA traffic from the host interface adapter (NHI) to a NULL port that is connected to another domain through a Thunderbolt cable. These tunnels can be used to carry software messages such as networking packets. To support this we introduce another tunnel type (TB_TUNNEL_DMA) that supports paths from NHI to NULL port and back. Signed-off-by: Mika Westerberg

thunderbolt: Do not tear down tunnels when driver is unloaded

2019-04-18T08:18:53Z

Now that we have capability to discover existing tunnels during driver load there is no point tearing down tunnels when the driver gets unloaded. Instead we can just leave them running. If user disconnects devices while there is no Thunderbolt driver loaded, tunneled protocol hotplug happens and is handled by the corresponding driver (pciehp in case of PCIe tunnel, GFX driver in case of DP tunnel). Signed-off-by: Mika Westerberg

thunderbolt: Discover preboot PCIe paths the boot firmware established

2019-04-18T08:18:53Z

In Apple Macs the boot firmware (EFI) connects all devices automatically when the system is started, before it hands over to the OS. Instead of ignoring we discover all those PCIe tunnels and record them using our internal structures, just like we do when a device is connected after the OS is already up. By doing this we can properly tear down tunnels when devices are disconnected. Also this allows us to resume the existing tunnels after system suspend/resume cycle. Signed-off-by: Mika Westerberg