summaryrefslogtreecommitdiffstats
path: root/drivers/thunderbolt/tunnel.c
Commit message (Collapse)AuthorAgeFilesLines
* thunderbolt: Add DisplayPort 2.x tunneling supportMika Westerberg2023-06-161-16/+84
| | | | | | | | | | | This adds support for the UHBR (Ultra High Bit Rate) bandwidths introduced with DisplayPort 2.0 (and refined in 2.1). These can go up to 80 Gbit/s and their support is represent in additional bits in the DP IN capability. This updates the DisplayPort tunneling to support these new rates too. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Make bandwidth allocation mode function names consistentMika Westerberg2023-06-161-20/+21
| | | | | | | | | Make sure the DisplayPort bandwidth allocation mode function names are consistent with the existing ones, such as USB3. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Enable USB4 v2 PCIe TLP/DLLP extended encapsulationGil Fine2023-06-161-3/+35
| | | | | | | | | USB4 v2 spec introduces modified encapsulation of PCIe TLP and DLLP packets. This improves the PCIe tunneled traffic usage by reducing overhead. Enable this if both sides of the link support it. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* Merge branch 'thunderbolt/fixes' into thunderbolt/nextMika Westerberg2023-06-091-1/+1
|\ | | | | | | | | | | We need Thunderbolt/USB4 fixes here as well. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * thunderbolt: Increase DisplayPort Connection Manager handshake timeoutMika Westerberg2023-05-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out that when plugging in VGA cable through USB-C to VGA/DVI dongle the Connection Manager handshake can take longer time, at least on Intel Titan Ridge based docks such as Dell WD91TB. This leads to following error in the dmesg: thunderbolt 0000:00:0d.3: 3:10: DP tunnel activation failed, aborting and the display stays blank (because we failed to establish the tunnel). For this reason increase the timeout to 3s. Reported-by: Koba Ko <koba.ko@canonical.com> Cc: stable@vger.kernel.org Acked-By: Yehezkel Bernat <YehezkelShB@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | thunderbolt: Log DisplayPort adapter rate and lanes on discoveryMika Westerberg2023-05-301-0/+43
| | | | | | | | | | | | | | This may be helpful when debugging possible issues around DisplayPort port tunneling. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | thunderbolt: Allow specifying custom credits for DMA tunnelsMika Westerberg2023-05-241-4/+9
| | | | | | | | | | | | | | The default ones should be find but this allows the user to tweak the credits to get more performance out of the P2P connection. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | thunderbolt: Check for ring 0 in tb_tunnel_alloc_dma()Mika Westerberg2023-05-241-0/+4
|/ | | | | | | | Ring 0 cannot be used for anything else than control channel messages. For this reason add a check to tb_tunnel_alloc_dma() and fail if someone tries to do that. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* Merge tag 'thunderbolt-for-v6.3-rc1' of ↵Greg Kroah-Hartman2023-02-081-36/+470
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Changes for v6.3 merge window This includes following Thunderbolt/USB4 changes for the v6.3 merge window: - Add support for DisplayPort bandwidth allocation mode - Debug logging improvements - Minor cleanups. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Add missing kernel-doc comment to tb_tunnel_maximum_bandwidth() thunderbolt: Handle bandwidth allocation mode enablement notification thunderbolt: Add support for DisplayPort bandwidth allocation mode thunderbolt: Include the additional DP IN double word in debugfs dump thunderbolt: Add functions to support DisplayPort bandwidth allocation mode thunderbolt: Increase timeout of DP OUT adapter handshake thunderbolt: Take CL states into account when waiting for link to come up thunderbolt: Improve debug logging in tb_available_bandwidth() thunderbolt: Log DP adapter type thunderbolt: Use decimal port number in control and tunnel logs too thunderbolt: Refactor tb_acpi_add_link() thunderbolt: Use correct type in tb_port_is_clx_enabled() prototype
| * thunderbolt: Add missing kernel-doc comment to tb_tunnel_maximum_bandwidth()Mika Westerberg2023-01-271-0/+10
| | | | | | | | | | | | | | These were missing from the original commit so add them now. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * thunderbolt: Add support for DisplayPort bandwidth allocation modeMika Westerberg2023-01-171-30/+453
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USB4 spec defines an optional feature that allows the connection manager to negotiate with the graphics through DPCD registers changes in the bandwidth allocation dynamically. This is referred as "bandwidth allocation mode" in the spec. The connection manager uses DP IN adapters registers to communicate with the graphics, and also gets notifications from these adapters when the graphics wants to change the bandwidth allocation. Both the connection manager and the graphics driver needs to support this. We check if the DP IN adapter supports this and if it does enable it before establishing a DP tunnel. Then we react on DP_BW notifications coming from the DP IN adapter and update the bandwidth allocation accordingly (within the maximum common capabilities the DP IN/OUT support). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * thunderbolt: Increase timeout of DP OUT adapter handshakeMika Westerberg2023-01-171-5/+6
| | | | | | | | | | | | | | Sometimes the current timeout is not enough so increase it to 1500 ms and while there make the loop use ktime instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * thunderbolt: Use decimal port number in control and tunnel logs tooMika Westerberg2023-01-171-1/+1
| | | | | | | | | | | | | | Use decimal number instead of hex in port numbers as we have been doing with other logging functions too. This makes the output more consistent. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | thunderbolt: Use correct function to calculate maximum USB3 link rateMika Westerberg2023-01-091-1/+1
|/ | | | | | | | | | | We need to take minimum of both sides of the USB3 link into consideration, not just the downstream port. Fix this by calling tb_usb3_max_link_rate() instead. Fixes: 0bd680cd900c ("thunderbolt: Add USB3 bandwidth management") Cc: stable@vger.kernel.org Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Fix buffer allocation of devices with no DisplayPort adaptersGil Fine2022-05-121-2/+5
| | | | | | | | For the case of a device without DisplayPort adapters we calculate incorrectly the amount of buffers. Fix the calculation for this case. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Use different lane for second DisplayPort tunnelMika Westerberg2022-04-191-5/+6
| | | | | | | | | | | | | | | | | | 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>
* thunderbolt: Disable LTTPR on Intel Titan RidgeMika Westerberg2022-02-021-0/+10
| | | | | | | | Intel Titan Ridge does not disable AUX timers when it gets SET_CONFIG with SET_LTTPR_MODE set which makes DP tunneling to fail. For this reason disable LTTPR on Titan Ridge device side. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Tear down existing tunnels when resuming from hibernateMika Westerberg2021-12-071-10/+17
| | | | | | | | | | | | | 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>
* thunderbolt: Allocate credits according to router preferencesMika Westerberg2021-06-011-74/+330
| | | | | | | | | | | | | | | | | | | The USB4 Connection Manager guide provides detailed information how the USB4 router buffer (credit) allocation information should be used by the connection manager when it allocates buffers for different paths. This patch implements it for Linux. For USB 3.x and DisplayPort we use directly the router preferences. The rest of the buffer space is then used for PCIe and DMA (peer-to-peer, XDomain) traffic. DMA tunnels require at least one buffer and PCIe six, so if there is not enough buffers we fail the tunnel creation. For the legacy Thunderbolt 1-3 devices we use the existing hard-coded scheme except for DMA where we use the values suggested by the USB4 spec chapter 13. Co-developed-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Move nfc_credits field to struct tb_path_hopMika Westerberg2021-06-011-11/+14
| | | | | | | | | With the USB4 buffer allocation the number of credits (and non-flow credits) may be different depending on the router buffer allocation preferences. To allow this move the nfc_credits field to struct tb_path_hop. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Allow multiple DMA tunnels over a single XDomain connectionMika Westerberg2021-03-181-11/+71
| | | | | | | | | | | | | | | | | Currently we have had an artificial limitation of a single DMA tunnel per XDomain connection. However, hardware wise there is no such limit and software based connection manager can take advantage of all the DMA rings available on the host to establish tunnels. For this reason make the tb_xdomain_[enable|disable]_paths() to take the DMA ring and HopID as parameter instead of storing them in the struct tb_xdomain. We also add API functions to allocate input and output HopIDs of the XDomain connection that the service drivers can use instead of hard-coding. Also convert the two existing service drivers over to this API. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Use dedicated flow control for DMA tunnelsMika Westerberg2021-03-181-16/+4
| | | | | | | The USB4 inter-domain service spec recommends using dedicated flow control scheme so update the driver accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for native USB4 _OSCMika Westerberg2021-02-041-4/+6
| | | | | | | | | | | | | | | | ACPI 6.4 introduced a new _OSC capability used to negotiate whether the OS is supposed to use Software (native) or Firmware based Connection Manager. If the native support is granted then there are set of bits that enable/disable different tunnel types that the Software Connection Manager is allowed to tunnel. This adds support for this new USB4 _OSC accordingly. When PCIe tunneling is disabled then the driver switches security level to be "nopcie" following the security level 5 used in Firmware based Connection Manager. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
* thunderbolt: tunnel: Fix misspelling of 'receive_path'Lee Jones2021-01-281-1/+1
| | | | | | | | | | | | | | Fixes the following W=1 kernel build warning(s): drivers/thunderbolt/tunnel.c:841: warning: Function parameter or member 'receive_path' not described in 'tb_tunnel_alloc_dma' drivers/thunderbolt/tunnel.c:841: warning: Excess function parameter 'reveive_path' description in 'tb_tunnel_alloc_dma' Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Michael Jamet <michael.jamet@intel.com> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Make it possible to allocate one directional DMA tunnelMika Westerberg2020-11-111-19/+31
| | | | | | | | | | With DMA tunnels it is possible that the service using it does not require bi-directional paths so make RX and TX optional (but of course one of them needs to be set). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'thunderbolt-for-v5.9-rc4' of ↵Greg Kroah-Hartman2020-09-011-2/+10
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-linus Mika writes: thunderbolt: Fixes for v5.9-rc4 This includes two fixes, one that fixes a regression around reboot and other that uses a correct link rate when USB3 bandwidth is reclaimed when the link is not up. Both have been in linux-next with no reported issues. * tag 'thunderbolt-for-v5.9-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Use maximum USB3 link rate when reclaiming if link is not up thunderbolt: Disable ports that are not implemented
| * thunderbolt: Use maximum USB3 link rate when reclaiming if link is not upMika Westerberg2020-08-251-2/+10
| | | | | | | | | | | | | | | | | | If the USB3 link is not up the actual link rate is 0 so when reclaiming bandwidth we should look at maximum supported link rate instead. Cc: stable@vger.kernel.org Fixes: 0bd680cd900c ("thunderbolt: Add USB3 bandwidth management") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | treewide: Use fallthrough pseudo-keywordGustavo A. R. Silva2020-08-231-2/+2
|/ | | | | | | | | | Replace the existing /* fall through */ comments and its variants with the new pseudo-keyword macro fallthrough[1]. Also, remove unnecessary fall-through markings when it is the case. [1] https://www.kernel.org/doc/html/v5.7/process/deprecated.html?highlight=fallthrough#implicit-switch-case-fall-through Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
* thunderbolt: Add USB3 bandwidth managementMika Westerberg2020-06-221-13/+242
| | | | | | | | | | | | | | | | | | | | 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 <mika.westerberg@linux.intel.com>
* thunderbolt: Increase DP DPRX wait timeoutMika Westerberg2020-06-221-1/+1
| | | | | | | Sometimes it takes longer for DPRX to be set so increase the timeout to cope with this. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Report consumed bandwidth in both directionsMika Westerberg2020-06-221-9/+38
| | | | | | | | | | | Whereas DisplayPort bandwidth is consumed only in one direction (from DP IN adapter to DP OUT adapter), USB3 adds separate bandwidth for both upstream and downstream directions. For this reason extend the tunnel consumed bandwidth routines to support both directions and implement this for DP. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Handle incomplete PCIe/USB3 paths correctly in discoveryMika Westerberg2020-06-221-4/+6
| | | | | | | | | | | | If the path is not complete when we do discovery the number of hops may be less than with the full path. As an example when this can happen is that user unloads the driver, disconnects the topology, and loads the driver back. If there is PCIe or USB3 tunnel involved this may happen. Take this into account in tb_pcie_init_path() and tb_usb3_init_path() and prevent potential access over array limits. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Fix path indices used in USB3 tunnel discoveryMika Westerberg2020-06-221-6/+6
| | | | | | | | | | | The USB3 discovery used wrong indices when tunnel is discovered. It should use TB_USB3_PATH_DOWN for path that flows downstream and TB_USB3_PATH_UP when it flows upstream. This should not affect the functionality but better to fix it. Fixes: e6f818585713 ("thunderbolt: Add support for USB 3.x tunnels") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Cc: stable@vger.kernel.org # v5.6+
* thunderbolt: Add support for USB 3.x tunnelsRajmohan Mani2019-12-181-1/+157
| | | | | | | | | | | | | | | | | | USB4 added a capability to tunnel USB 3.x protocol over the USB4 fabric. USB4 device routers may include integrated SuperSpeed HUB or a function or both. USB tunneling follows PCIe so that the tunnel is created between the parent and the child router from USB3 downstream adapter port to USB3 upstream adapter port over a single USB4 link. This adds support for USB 3.x tunneling and also capability to discover existing USB 3.x tunnels (for example created by connection manager in boot firmware). 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> Link: https://lore.kernel.org/r/20191217123345.31850-9-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* thunderbolt: Add initial support for USB4Mika Westerberg2019-12-181-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB4 is the public specification based on Thunderbolt 3 protocol. There are some differences in register layouts and flows. In addition to PCIe and DP tunneling, USB4 supports tunneling of USB 3.x. USB4 is also backward compatible with Thunderbolt 3 (and older generations but the spec only talks about 3rd generation). USB4 compliant devices can be identified by checking USB4 version field in router configuration space. This patch adds initial support for USB4 compliant hosts and devices which enables following features provided by the existing functionality in the driver: - PCIe tunneling - Display Port tunneling - Host and device NVM firmware upgrade - P2P networking This brings the USB4 support to the same level that we already have for Thunderbolt 1, 2 and 3 devices. Note the spec talks about host and device "routers" but in the driver we still use term "switch" in most places. Both can be used interchangeably. Co-developed-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20191217123345.31850-5-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* thunderbolt: Add bandwidth management for Display Port tunnelsMika Westerberg2019-11-021-2/+280
| | | | | | | | | | | | 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 <mika.westerberg@linux.intel.com>
* thunderbolt: Add Display Port CM handshake for Titan Ridge devicesMika Westerberg2019-11-021-0/+45
| | | | | | | Titan Ridge needs an additional connection manager handshake in order to do proper Display Port tunneling so implement it here. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for lane bondingMika Westerberg2019-11-021-1/+18
| | | | | | | | | | | | | | | | | | | | 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 <mika.westerberg@linux.intel.com>
* thunderbolt: Convert DP adapter register names to follow the USB4 specMika Westerberg2019-11-011-4/+4
| | | | | | | | | Now that USB4 spec has names for these DP adapter registers we can use them instead. This makes it easier to match certain register to the spec. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Convert basic adapter register names to follow the USB4 specMika Westerberg2019-11-011-5/+5
| | | | | | | | | Now that USB4 spec has names for these basic registers we can use them instead. This makes it easier to match certain register to the spec. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Correct path indices for PCIe tunnelMika Westerberg2019-08-261-2/+2
| | | | | | | | | | | | PCIe tunnel path indices got mixed up when we added support for tunnels between switches that are not adjacent. This did not affect the functionality as it is just an index but fix it now nevertheless to make the code easier to understand. Reported-by: Rajmohan Mani <rajmohan.mani@intel.com> Fixes: 8c7acaaf020f ("thunderbolt: Extend tunnel creation to more than 2 adjacent switches") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com>
* thunderbolt: Make rest of the logging to happen at debug levelMika Westerberg2019-04-181-4/+2
| | | | | | | | | | | | 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 <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for DMA tunnelsMika Westerberg2019-04-181-1/+92
| | | | | | | | | | | | | 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 <mika.westerberg@linux.intel.com>
* thunderbolt: Do not tear down tunnels when driver is unloadedMika Westerberg2019-04-181-9/+1
| | | | | | | | | | | 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 <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for Display Port tunnelsMika Westerberg2019-04-181-4/+273
| | | | | | | | | | | Display Port tunnels are somewhat more complex than PCIe tunnels as it requires 3 tunnels (AUX Rx/Tx and Video). In addition we are not supposed to create the tunnels immediately when a DP OUT is enumerated. Instead we need to wait until we get hotplug event to that adapter port or check if the port has HPD set before tunnels can be established. This adds Display Port tunneling support to the software connection manager. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Discover preboot PCIe paths the boot firmware establishedMika Westerberg2019-04-181-2/+84
| | | | | | | | | | | | | | 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 <mika.westerberg@linux.intel.com>
* thunderbolt: Deactivate all paths before restarting themMika Westerberg2019-04-181-1/+11
| | | | | | | | | | State of the connected devices and tunnel configuration is not known during resume. For example some paths may not be complete anymore if the user has unplugged the related devices. So instead of marking all paths as inactive we go ahead and deactivate them explicitly before we restart them. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Extend tunnel creation to more than 2 adjacent switchesMika Westerberg2019-04-181-42/+14
| | | | | | | | | | | | | Now that we can allocate hop IDs per port on a path, we can take advantage of this and create tunnels covering longer paths than just between two adjacent switches. PCIe actually does not need this as it is typically a daisy chain between two adjacent switches but this way we do not need to hard-code creation of the tunnel. While there add name to struct tb_path to make debugging easier, and update kernel-doc comments. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Generalize tunnel creation functionalityMika Westerberg2019-04-181-122/+176
| | | | | | | | | | | | To be able to tunnel non-PCIe traffic, separate tunnel functionality into generic and PCIe specific parts. Rename struct tb_pci_tunnel to tb_tunnel, and make it hold an array of paths instead of just two. Update all the tunneling functions to take this structure as parameter. We also move tb_pci_port_active() to switch.c (and rename it) where we will be keeping all port and switch related functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Rename tunnel_pci to tunnelMika Westerberg2019-04-181-0/+223
In order to tunnel non-PCIe traffic as well rename tunnel_pci.[ch] to tunnel.[ch] to reflect this fact. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-14 08:27:30 +0000