Hosts the 0x221E linux distro kernel. https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.19.y 2022-05-05T06:25:23Z 2022-05-05T06:25:23Z Mika Westerberg 2022-02-13T14:44:45Z urn:sha1:8e1de7042596abb7cb277ea751fc13a4c2b65aea The USB4 Inter-Domain Service specification defines a protocol that can be used to establish lane bonding between two USB4 domains (hosts). So far we have not implemented it because the host controller DMA was not fast enough to be able to go over 20 Gbits/s even if lanes were bonded. However, starting from Intel Alder Lake CPUs the DMA can go over 20 Gbits/s so now it makes more sense to add this support to the driver. Because both ends need to negotiate the bonding we add a simple state machine that tracks the connection state and does the necessary steps described by the USB4 Inter-Domain Service specification. We only establish lane bonding when both sides of the link support it. Otherwise we default to use the single lane. Also this is only done when software connection manager is used. On systems with firmware based connection manager, it handles the high-speed tunneling so bonding lanes is specific to the implementation (Intel firmware based connection manager does not support lane bonding). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> 2022-04-19T07:26:18Z Mika Westerberg 2022-04-01T14:24:28Z urn:sha1:9d2d0a5cf0ca063f417681cc33e767ce52615286 Brad reported that on Apple hardware with Light Ridge or Falcon Ridge controller, plugging in a chain of Thunderbolt displays (Light Ridge based controllers) causes all kinds of tearing and flickering. The reason for this is that on Thunderbolt 1 hardware there is no lane bonding so we have two independent 10 Gb/s lanes, and currently Linux tunnels both displays through the lane 1. This makes the displays to share the 10 Gb/s bandwidth which may not be enough for higher resolutions. For this reason make the second tunnel go through the lane 0 instead. This seems to match what the macOS connection manager is also doing. Reported-by: Brad Campbell <lists2009@fnarfbargle.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Brad Campbell <lists2009@fnarfbargle.com> 2022-02-02T10:56:51Z Mika Westerberg 2022-01-07T11:00:47Z urn:sha1:30a4eca69b76c0ed5a2f34dd2a3e195c9bf6bed1 Both Alpine Ridge and Titan Ridge require special flows in order to activate the internal xHCI controller when there is USB device connected to the downstream type-C port. This implements the missing flows for both. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> 2021-12-28T07:43:56Z Gil Fine 2021-12-17T01:16:43Z urn:sha1:43f977bc60b1cfd3c1d220a9a0a06493fbf3985d Low power link states (called collectively CLx) are used to reduce transmitter and receiver power when a high-speed lane is idle. The simplest one being called CL0s. Follow what we already do for USB4 device routers and enable CL0s for Intel Titan Ridge device router too. This allows better thermal management. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> 2021-12-22T14:13:14Z Gil Fine 2021-12-17T01:16:39Z urn:sha1:8a90e4fa3b4d6a10c96b0a04abf57bb5a16a8f4e In this patch we add enabling of CL0s - a low power state of the link. Low power states (called collectively CLx) are used to reduce transmitter and receiver power when a high-speed lane is idle. For now, we add support only for first low power state: CL0s. We enable it, if both sides of the link support it, and only for the first hop router. (i.e. the first device that connected to the host router). This is needed for better thermal management. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> 2021-12-22T14:13:14Z Gil Fine 2021-12-17T01:16:38Z urn:sha1:a28ec0e165ba2f90568828a2578aaa8540e13bc5 Up until Titan Ridge (Thunderbolt 3) device routers only supported bi-directional mode. In this patch we add to TMU a uni-directional mode. The uni-directional mode is needed for enabling of low power state of the link (CLx). Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> 2021-12-07T12:18:33Z Mika Westerberg 2021-11-14T15:20:59Z urn:sha1:43bddb26e20af916249b5318200cfe1734c1700c If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> 2021-06-11T08:42:54Z Mika Westerberg 2021-05-24T14:57:32Z urn:sha1:349bfe089d02f18b05ed2c386eeb248a0be49641 We only need to set up the device links when software connection manager path is used. The firmware connection manager does not need them and if they are present they may even cause problems. Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> 2021-06-01T07:53:31Z Rajmohan Mani 2021-04-01T15:42:38Z urn:sha1:3fb10ea4ce86d4d06622be894099c59872e92c57 With help from platform firmware (ACPI) it is possible to power on retimers even when there is no USB4 link (e.g nothing is connected to the USB4 ports). This allows us to bring the USB4 sideband up so that we can access retimers and upgrade their NVM firmware. If the platform has support for this, we expose two additional attributes under USB4 ports: offline and rescan. These can be used to bring the port offline, rescan for the retimers and put the port online again. The retimer NVM upgrade itself works the same way than with cable connected. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2021-04-13T10:17:14Z Greg Kroah-Hartman 2021-04-13T10:17:14Z urn:sha1:5367f82a212305c35b35303a8a21ca348f653ca3 Mika writes: thunderbolt: Changes for v5.13 merge window This includes following Thunderbolt/USB4 changes for v5.13 merge window: * Debugfs improvements * Align the inter-domain (peer-to-peer) support with the USB4 inter-domain spec for better interoperability * Add support for USB4 DROM and the new product descriptor * More KUnit tests * Detailed uevent for routers * Few miscellaneous improvements All these have been in linux-next without reported issues. * tag 'thunderbolt-for-v5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: (24 commits) thunderbolt: Hide authorized attribute if router does not support PCIe tunnels thunderbolt: Add details to router uevent thunderbolt: Unlock on error path in tb_domain_add() thunderbolt: Add support for USB4 DROM thunderbolt: Check quirks in tb_switch_add() thunderbolt: Add KUnit tests for DMA tunnels thunderbolt: Add KUnit tests for XDomain properties net: thunderbolt: Align the driver to the USB4 networking spec thunderbolt: Allow multiple DMA tunnels over a single XDomain connection thunderbolt: Drop unused tb_port_set_initial_credits() thunderbolt: Use dedicated flow control for DMA tunnels thunderbolt: Add support for maxhopid XDomain property thunderbolt: Add tb_property_copy_dir() thunderbolt: Align XDomain protocol timeouts with the spec thunderbolt: Use pseudo-random number as initial property block generation thunderbolt: Do not re-establish XDomain DMA paths automatically thunderbolt: Add more logging to XDomain connections Documentation / thunderbolt: Drop speed/lanes entries for XDomain thunderbolt: Decrease control channel timeout for software connection manager thunderbolt: Do not pass timeout for tb_cfg_reset() ...