kernel/linux
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ synced 2026-11-15 19:56:03 +00:00
Code Issues Releases Packages Activity
linux/drivers/thunderbolt/usb4.c

3015 lines
74 KiB
Raw Normal View History

thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Make use of SI units from units.h In a couple of places it seems reasonable to use MEGA intead of explicit number. It makes code more readable and robust. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-27 20:20:17 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Move constants related to NVM into nvm.c Move constants related to NVM into nvm.c to make the code cleaner. Use a separate constant for USB4_DATA_DWORDS in usb4.c. No functional changes. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-05-11 11:19:19 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Read router preferred credit allocation information USB4 routers must expose their preferred credit (buffer) allocation information through router operation. This information tells the connection manager how the router prefers its buffers to be allocated to get the expected bandwidth for the supported protocols. Read this information and store it as part of struct tb_switch for each USB4 router. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-03-10 13:34:12 +02:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Fix connection issue with Pluggable UD-4VPD dock Rick reported that his Pluggable USB4 dock does not work anymore after upgrading to v6.10 kernel. It looks like commit c6ca1ac9f472 ("thunderbolt: Increase sideband access polling delay") makes the device router enumeration happen later than what might be expected by the dock (although there is no such limit in the USB4 spec) which probably makes it assume there is something wrong with the high-speed link and reset it. After the link is reset the same issue happens again and again. For this reason lower the sideband access delay from 5ms to 1ms. This seems to work fine according to Rick's testing. Reported-by: Rick Lahaye <rick@581238.xyz> Closes: https://lore.kernel.org/linux-usb/000f01db247b$d10e1520$732a3f60$@581238.xyz/ Tested-by: Rick Lahaye <rick@581238.xyz> Fixes: c6ca1ac9f472 ("thunderbolt: Increase sideband access polling delay") Cc: stable@vger.kernel.org Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-11-05 09:19:02 +02:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Add connection manager specific hooks for USB4 router operations Intel USB4 host routers that run the firmware based connection manager (ICM) may implement a proxy for USB4 router operations. This is to avoid the firmware to race with the OS driver, as both may need to run these operations. This adds two new connection manager specific callbacks which, if provided, get called instead of the native USB4 router operation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-03 13:58:00 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Pass TX and RX data directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason rename usb4_switch_op() to __usb4_switch_op() that provides the most complete interface. Then make usb4_switch_op() and usb4_switch_op_data() call it with correct set of parameters and update the callers accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 15:09:44 +02:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Move usb4_switch_wait_for_bit() to switch.c Currently usb4_switch_wait_for_bit() used only in usb4.c Moving to switch.c to call it from other files. Also change the prefix to "tb_" to follow to the naming convention. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-12-17 03:16:40 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Check return value of tb_sw_read() in usb4_switch_op() The function misses checking return value of tb_sw_read() before it accesses the value that was read. Fix this by checking the return value first. Fixes: b04079837b20 ("thunderbolt: Add initial support for USB4") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Yehezkel Bernat <yehezkelshb@gmail.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-04-09 10:18:10 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Perform USB4 router NVM upgrade in two phases The currect code expects that the router returns back the status of the NVM authentication immediately. When tested against a real USB4 device what happens is that the router is reset and only after that the result is updated in the ROUTER_CS_26 register status field. This also seems to align better what the spec suggests. For this reason do the same what we already do with the Thunderbolt 3 devices and perform the NVM upgrade in two phases. First start the NVM_AUTH router operation and once the router is added back after the reset read the status in ROUTER_CS_26 and expose it to the userspace accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-10 11:34:07 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Pass TX and RX data directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason rename usb4_switch_op() to __usb4_switch_op() that provides the most complete interface. Then make usb4_switch_op() and usb4_switch_op_data() call it with correct set of parameters and update the callers accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 15:09:44 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Add connection manager specific hooks for USB4 router operations Intel USB4 host routers that run the firmware based connection manager (ICM) may implement a proxy for USB4 router operations. This is to avoid the firmware to race with the OS driver, as both may need to run these operations. This adds two new connection manager specific callbacks which, if provided, get called instead of the native USB4 router operation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-03 13:58:00 +02:00
thunderbolt: Move constants related to NVM into nvm.c Move constants related to NVM into nvm.c to make the code cleaner. Use a separate constant for USB4_DATA_DWORDS in usb4.c. No functional changes. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-05-11 11:19:19 +03:00
thunderbolt: Add connection manager specific hooks for USB4 router operations Intel USB4 host routers that run the firmware based connection manager (ICM) may implement a proxy for USB4 router operations. This is to avoid the firmware to race with the OS driver, as both may need to run these operations. This adds two new connection manager specific callbacks which, if provided, get called instead of the native USB4 router operation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-03 13:58:00 +02:00
thunderbolt: Pass TX and RX data directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason rename usb4_switch_op() to __usb4_switch_op() that provides the most complete interface. Then make usb4_switch_op() and usb4_switch_op_data() call it with correct set of parameters and update the callers accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 15:09:44 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Avoid notify PM core about runtime PM resume 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 <gil.fine@linux.intel.com> Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-03-01 15:11:18 +02:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add wake on connect/disconnect on USB4 ports Wake on connect/disconnect is only supported while runtime suspend for now, which is obviously necessary. It is also not inherently desired for the system to wakeup on Thunderbolt/USB4 hot plug events. However, we can still make user in control of waking up the system in the events of hot plug/unplug. This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs attribute and only enables wakes on connect/disconnect to the respective port when 'wakeup' is set to 'enabled'. The attribute is set to 'disabled' by default. Signed-off-by: Rajat Khandelwal <rajat.khandelwal@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-11-01 17:20:42 +05:30
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add wake on connect/disconnect on USB4 ports Wake on connect/disconnect is only supported while runtime suspend for now, which is obviously necessary. It is also not inherently desired for the system to wakeup on Thunderbolt/USB4 hot plug events. However, we can still make user in control of waking up the system in the events of hot plug/unplug. This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs attribute and only enables wakes on connect/disconnect to the respective port when 'wakeup' is set to 'enabled'. The attribute is set to 'disabled' by default. Signed-off-by: Rajat Khandelwal <rajat.khandelwal@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-11-01 17:20:42 +05:30
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add wake on connect/disconnect on USB4 ports Wake on connect/disconnect is only supported while runtime suspend for now, which is obviously necessary. It is also not inherently desired for the system to wakeup on Thunderbolt/USB4 hot plug events. However, we can still make user in control of waking up the system in the events of hot plug/unplug. This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs attribute and only enables wakes on connect/disconnect to the respective port when 'wakeup' is set to 'enabled'. The attribute is set to 'disabled' by default. Signed-off-by: Rajat Khandelwal <rajat.khandelwal@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-11-01 17:20:42 +05:30
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add wake on connect/disconnect on USB4 ports Wake on connect/disconnect is only supported while runtime suspend for now, which is obviously necessary. It is also not inherently desired for the system to wakeup on Thunderbolt/USB4 hot plug events. However, we can still make user in control of waking up the system in the events of hot plug/unplug. This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs attribute and only enables wakes on connect/disconnect to the respective port when 'wakeup' is set to 'enabled'. The attribute is set to 'disabled' by default. Signed-off-by: Rajat Khandelwal <rajat.khandelwal@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-11-01 17:20:42 +05:30
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add wake on connect/disconnect on USB4 ports Wake on connect/disconnect is only supported while runtime suspend for now, which is obviously necessary. It is also not inherently desired for the system to wakeup on Thunderbolt/USB4 hot plug events. However, we can still make user in control of waking up the system in the events of hot plug/unplug. This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs attribute and only enables wakes on connect/disconnect to the respective port when 'wakeup' is set to 'enabled'. The attribute is set to 'disabled' by default. Signed-off-by: Rajat Khandelwal <rajat.khandelwal@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-11-01 17:20:42 +05:30
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Do not tunnel USB3 if link is not USB4 USB3 tunneling is possible only over USB4 link so don't create USB3 tunnels if that's not the case. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-03-04 17:09:14 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Add support for enhanced uni-directional TMU mode This is new TMU mode introduced with the USB4 v2. This mode is simpler than the existing ones and allows all CL states as well. Enable this for all links where both side routers are v2 and keep the existing functionality for the v1 and earlier links. Currently only support the MedRes rate. We can add the HiFi rate later too if it turns out to be useful. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-10-11 12:11:09 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Introduce tb_switch_downstream_port() Introduce tb_switch_downstream_port() helper function that returns the downstream port of a parent switch that is connected to the upstream port of specified switch. From now on, we use it all across the driver where applicable. While there fix a whitespace in comment and rename 'downstream' to 'down' to be consistent with the rest of the driver. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-23 01:30:38 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Introduce tb_switch_downstream_port() Introduce tb_switch_downstream_port() helper function that returns the downstream port of a parent switch that is connected to the upstream port of specified switch. From now on, we use it all across the driver where applicable. While there fix a whitespace in comment and rename 'downstream' to 'down' to be consistent with the rest of the driver. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-23 01:30:38 +03:00
thunderbolt: Log the link as TBT instead of TBT3 The upstream port can be connected to any previous generation Thunderbolt port so logging as "TBT" is more accurate than "TBT3. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-01 20:16:25 +03:00
thunderbolt: Do not tunnel USB3 if link is not USB4 USB3 tunneling is possible only over USB4 link so don't create USB3 tunnels if that's not the case. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-03-04 17:09:14 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Add support for native USB4 _OSC 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>
2020-02-18 16:14:42 +02:00
thunderbolt: Add support for USB 3.x tunnels 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>
2019-12-17 15:33:44 +03:00
thunderbolt: Add support for native USB4 _OSC 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>
2020-02-18 16:14:42 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Add support for USB 3.x tunnels 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>
2019-12-17 15:33:44 +03:00
thunderbolt: Fix xhci check in usb4_switch_setup() The code tried to check whether xhci variable has ROUTER_CS_6_HCI bit set but since xhci type is bool and it already holds true or false based on that very bit, fix the check to use the variable directly. Reported-by: Dan Carpenter <dan.carpenter@oracle.com> Fixes: b04079837b20 ("thunderbolt: Add initial support for USB4") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20200108125317.36444-2-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-01-08 15:53:16 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Fix setting the CNS bit in ROUTER_CS_5 The bit 23, CM TBT3 Not Supported (CNS), in ROUTER_CS_5 indicates whether a USB4 Connection Manager is TBT3-Compatible and should be: 0b for TBT3-Compatible 1b for Not TBT3-Compatible Fixes: b04079837b20 ("thunderbolt: Add initial support for USB4") Cc: stable@vger.kernel.org Signed-off-by: Mohammad Rahimi <rahimi.mhmmd@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-01-27 11:26:28 +08:00
thunderbolt: Add support for enhanced uni-directional TMU mode This is new TMU mode introduced with the USB4 v2. This mode is simpler than the existing ones and allows all CL states as well. Enable this for all links where both side routers are v2 and keep the existing functionality for the v1 and earlier links. Currently only support the MedRes rate. We can add the HiFi rate later too if it turns out to be useful. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-10-11 12:11:09 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Move usb4_switch_wait_for_bit() to switch.c Currently usb4_switch_wait_for_bit() used only in usb4.c Moving to switch.c to call it from other files. Also change the prefix to "tb_" to follow to the naming convention. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-12-17 03:16:40 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Add missing kernel-doc parameter descriptions Two functions that were added for USB4 support miss kernel-doc parameter descriptions so add them now. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20200214121638.75589-1-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-14 15:16:38 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Generalize usb4_switch_do_[read|write]_data() Currently these functions operate on struct tb_switch but we are going to need the same functionality with retimers as well so make the two functions work with an arbitrary object that gets passed as parameter to the callbacks. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-14 19:23:03 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Generalize usb4_switch_do_[read|write]_data() Currently these functions operate on struct tb_switch but we are going to need the same functionality with retimers as well so make the two functions work with an arbitrary object that gets passed as parameter to the callbacks. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-14 19:23:03 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass TX and RX data directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason rename usb4_switch_op() to __usb4_switch_op() that provides the most complete interface. Then make usb4_switch_op() and usb4_switch_op_data() call it with correct set of parameters and update the callers accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 15:09:44 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass TX and RX data directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason rename usb4_switch_op() to __usb4_switch_op() that provides the most complete interface. Then make usb4_switch_op() and usb4_switch_op_data() call it with correct set of parameters and update the callers accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 15:09:44 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Add missing kernel-doc parameter descriptions Two functions that were added for USB4 support miss kernel-doc parameter descriptions so add them now. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20200214121638.75589-1-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-02-14 15:16:38 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Split NVM read/write generic functions out from usb4.c We do this for Thunderbolt 2/3 devices through DMA port, USB4 devices and retimers pretty much the same way. Only the actual block read/write is different. For this reason split out the NVM read/write functions from usb4.c to nvm.c and make USB4 device code call these when needed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-01 16:54:15 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add wake on connect/disconnect on USB4 ports Wake on connect/disconnect is only supported while runtime suspend for now, which is obviously necessary. It is also not inherently desired for the system to wakeup on Thunderbolt/USB4 hot plug events. However, we can still make user in control of waking up the system in the events of hot plug/unplug. This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs attribute and only enables wakes on connect/disconnect to the respective port when 'wakeup' is set to 'enabled'. The attribute is set to 'disabled' by default. Signed-off-by: Rajat Khandelwal <rajat.khandelwal@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-11-01 17:20:42 +05:30
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Only configure USB4 wake for lane 0 adapters Only USB4 lane 0 adapter has the USB4 port capability for wakes so only program wakes on such adapters. Fixes: b2911a593a70 ("thunderbolt: Enable wakes from system suspend") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-10-05 18:55:24 +03:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Only configure USB4 wake for lane 0 adapters Only USB4 lane 0 adapter has the USB4 port capability for wakes so only program wakes on such adapters. Fixes: b2911a593a70 ("thunderbolt: Enable wakes from system suspend") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-10-05 18:55:24 +03:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Align USB4 router wakes configuration with the CM guide The USB4 Configuration Manager guide suggests that the USB4 port wakes are configured in a certain way, like that when the port is configured the wake-on-connect should not be set and so forth, so align the driver with this. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-14 16:41:31 +02:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Align USB4 router wakes configuration with the CM guide The USB4 Configuration Manager guide suggests that the USB4 port wakes are configured in a certain way, like that when the port is configured the wake-on-connect should not be set and so forth, so align the driver with this. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-14 16:41:31 +02:00
thunderbolt: Add wake on connect/disconnect on USB4 ports Wake on connect/disconnect is only supported while runtime suspend for now, which is obviously necessary. It is also not inherently desired for the system to wakeup on Thunderbolt/USB4 hot plug events. However, we can still make user in control of waking up the system in the events of hot plug/unplug. This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs attribute and only enables wakes on connect/disconnect to the respective port when 'wakeup' is set to 'enabled'. The attribute is set to 'disabled' by default. Signed-off-by: Rajat Khandelwal <rajat.khandelwal@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-11-01 17:20:42 +05:30
thunderbolt: Align USB4 router wakes configuration with the CM guide The USB4 Configuration Manager guide suggests that the USB4 port wakes are configured in a certain way, like that when the port is configured the wake-on-connect should not be set and so forth, so align the driver with this. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-14 16:41:31 +02:00
thunderbolt: Add wake on connect/disconnect on USB4 ports Wake on connect/disconnect is only supported while runtime suspend for now, which is obviously necessary. It is also not inherently desired for the system to wakeup on Thunderbolt/USB4 hot plug events. However, we can still make user in control of waking up the system in the events of hot plug/unplug. This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs attribute and only enables wakes on connect/disconnect to the respective port when 'wakeup' is set to 'enabled'. The attribute is set to 'disabled' by default. Signed-off-by: Rajat Khandelwal <rajat.khandelwal@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-11-01 17:20:42 +05:30
thunderbolt: Align USB4 router wakes configuration with the CM guide The USB4 Configuration Manager guide suggests that the USB4 port wakes are configured in a certain way, like that when the port is configured the wake-on-connect should not be set and so forth, so align the driver with this. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-14 16:41:31 +02:00
thunderbolt: Add wake on connect/disconnect on USB4 ports Wake on connect/disconnect is only supported while runtime suspend for now, which is obviously necessary. It is also not inherently desired for the system to wakeup on Thunderbolt/USB4 hot plug events. However, we can still make user in control of waking up the system in the events of hot plug/unplug. This patch adds 'wakeup' attribute under 'usb4_portX/power' sysfs attribute and only enables wakes on connect/disconnect to the respective port when 'wakeup' is set to 'enabled'. The attribute is set to 'disabled' by default. Signed-off-by: Rajat Khandelwal <rajat.khandelwal@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-11-01 17:20:42 +05:30
thunderbolt: Align USB4 router wakes configuration with the CM guide The USB4 Configuration Manager guide suggests that the USB4 port wakes are configured in a certain way, like that when the port is configured the wake-on-connect should not be set and so forth, so align the driver with this. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-14 16:41:31 +02:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add wake from DisplayPort Latest USB4 spec added a new wake bit for DisplayPort so add this to the driver when runtime suspending. This way wake up the domain when a new monitor is plugged in to any of the device routers. Also do the same for pre-USB4 devices through the link controller registers as documented in chapter 13 of the USB4 spec. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-14 16:44:17 +02:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add wake from DisplayPort Latest USB4 spec added a new wake bit for DisplayPort so add this to the driver when runtime suspending. This way wake up the domain when a new monitor is plugged in to any of the device routers. Also do the same for pre-USB4 devices through the link controller registers as documented in chapter 13 of the USB4 spec. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-14 16:44:17 +02:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add wake from DisplayPort Latest USB4 spec added a new wake bit for DisplayPort so add this to the driver when runtime suspending. This way wake up the domain when a new monitor is plugged in to any of the device routers. Also do the same for pre-USB4 devices through the link controller registers as documented in chapter 13 of the USB4 spec. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-01-14 16:44:17 +02:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Enable wakes from system suspend In order for the router and the whole domain to wake up from system suspend states we need to enable wakes for the connected routers. For device routers we enable wakes from PCIe and USB 3.x. This allows devices such as keyboards connected to USB 3.x hub that is tunneled to wake the system up as expected. For all routers we enabled wake on USB4 for each connected ports. This is used to propagate the wake from router to another. Do the same for legacy routers through link controller vendor specific registers as documented in USB4 spec chapter 13. While there correct kernel-doc of usb4_switch_set_sleep() -- it does not enable wakes instead there is a separate function (usb4_switch_set_wake()) that does. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2019-12-06 18:36:07 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Move usb4_switch_wait_for_bit() to switch.c Currently usb4_switch_wait_for_bit() used only in usb4.c Moving to switch.c to call it from other files. Also change the prefix to "tb_" to follow to the naming convention. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-12-17 03:16:40 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Generalize usb4_switch_do_[read|write]_data() Currently these functions operate on struct tb_switch but we are going to need the same functionality with retimers as well so make the two functions work with an arbitrary object that gets passed as parameter to the callbacks. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-14 19:23:03 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Generalize usb4_switch_do_[read|write]_data() Currently these functions operate on struct tb_switch but we are going to need the same functionality with retimers as well so make the two functions work with an arbitrary object that gets passed as parameter to the callbacks. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-14 19:23:03 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass TX and RX data directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason rename usb4_switch_op() to __usb4_switch_op() that provides the most complete interface. Then make usb4_switch_op() and usb4_switch_op_data() call it with correct set of parameters and update the callers accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 15:09:44 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass TX and RX data directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason rename usb4_switch_op() to __usb4_switch_op() that provides the most complete interface. Then make usb4_switch_op() and usb4_switch_op_data() call it with correct set of parameters and update the callers accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 15:09:44 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Split NVM read/write generic functions out from usb4.c We do this for Thunderbolt 2/3 devices through DMA port, USB4 devices and retimers pretty much the same way. Only the actual block read/write is different. For this reason split out the NVM read/write functions from usb4.c to nvm.c and make USB4 device code call these when needed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-01 16:54:15 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Allow router NVM authenticate separately It may be useful if the actual NVM authentication can be delayed to be run later, for instance when the user logs out. For this reason add a new NVM operation (AUHENTICATE_ONLY) that just triggers the authentication procedure over whatever was written to the NVM storage. This is not supported with Thunderbolt 1-3 devices, though. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-12 15:25:08 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Split NVM read/write generic functions out from usb4.c We do this for Thunderbolt 2/3 devices through DMA port, USB4 devices and retimers pretty much the same way. Only the actual block read/write is different. For this reason split out the NVM read/write functions from usb4.c to nvm.c and make USB4 device code call these when needed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-01 16:54:15 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Generalize usb4_switch_do_[read|write]_data() Currently these functions operate on struct tb_switch but we are going to need the same functionality with retimers as well so make the two functions work with an arbitrary object that gets passed as parameter to the callbacks. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-14 19:23:03 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass TX and RX data directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason rename usb4_switch_op() to __usb4_switch_op() that provides the most complete interface. Then make usb4_switch_op() and usb4_switch_op_data() call it with correct set of parameters and update the callers accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 15:09:44 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Split NVM read/write generic functions out from usb4.c We do this for Thunderbolt 2/3 devices through DMA port, USB4 devices and retimers pretty much the same way. Only the actual block read/write is different. For this reason split out the NVM read/write functions from usb4.c to nvm.c and make USB4 device code call these when needed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-01 16:54:15 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Perform USB4 router NVM upgrade in two phases The currect code expects that the router returns back the status of the NVM authentication immediately. When tested against a real USB4 device what happens is that the router is reset and only after that the result is updated in the ROUTER_CS_26 register status field. This also seems to align better what the spec suggests. For this reason do the same what we already do with the Thunderbolt 3 devices and perform the NVM upgrade in two phases. First start the NVM_AUTH router operation and once the router is added back after the reset read the status in ROUTER_CS_26 and expose it to the userspace accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-10 11:34:07 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Perform USB4 router NVM upgrade in two phases The currect code expects that the router returns back the status of the NVM authentication immediately. When tested against a real USB4 device what happens is that the router is reset and only after that the result is updated in the ROUTER_CS_26 register status field. This also seems to align better what the spec suggests. For this reason do the same what we already do with the Thunderbolt 3 devices and perform the NVM upgrade in two phases. First start the NVM_AUTH router operation and once the router is added back after the reset read the status in ROUTER_CS_26 and expose it to the userspace accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-10 11:34:07 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Perform USB4 router NVM upgrade in two phases The currect code expects that the router returns back the status of the NVM authentication immediately. When tested against a real USB4 device what happens is that the router is reset and only after that the result is updated in the ROUTER_CS_26 register status field. This also seems to align better what the spec suggests. For this reason do the same what we already do with the Thunderbolt 3 devices and perform the NVM upgrade in two phases. First start the NVM_AUTH router operation and once the router is added back after the reset read the status in ROUTER_CS_26 and expose it to the userspace accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-10 11:34:07 +03:00
thunderbolt: Add connection manager specific hooks for USB4 router operations Intel USB4 host routers that run the firmware based connection manager (ICM) may implement a proxy for USB4 router operations. This is to avoid the firmware to race with the OS driver, as both may need to run these operations. This adds two new connection manager specific callbacks which, if provided, get called instead of the native USB4 router operation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-03 13:58:00 +02:00
thunderbolt: Perform USB4 router NVM upgrade in two phases The currect code expects that the router returns back the status of the NVM authentication immediately. When tested against a real USB4 device what happens is that the router is reset and only after that the result is updated in the ROUTER_CS_26 register status field. This also seems to align better what the spec suggests. For this reason do the same what we already do with the Thunderbolt 3 devices and perform the NVM upgrade in two phases. First start the NVM_AUTH router operation and once the router is added back after the reset read the status in ROUTER_CS_26 and expose it to the userspace accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-10 11:34:07 +03:00
thunderbolt: Add connection manager specific hooks for USB4 router operations Intel USB4 host routers that run the firmware based connection manager (ICM) may implement a proxy for USB4 router operations. This is to avoid the firmware to race with the OS driver, as both may need to run these operations. This adds two new connection manager specific callbacks which, if provided, get called instead of the native USB4 router operation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-03 13:58:00 +02:00
thunderbolt: Perform USB4 router NVM upgrade in two phases The currect code expects that the router returns back the status of the NVM authentication immediately. When tested against a real USB4 device what happens is that the router is reset and only after that the result is updated in the ROUTER_CS_26 register status field. This also seems to align better what the spec suggests. For this reason do the same what we already do with the Thunderbolt 3 devices and perform the NVM upgrade in two phases. First start the NVM_AUTH router operation and once the router is added back after the reset read the status in ROUTER_CS_26 and expose it to the userspace accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-10 11:34:07 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Perform USB4 router NVM upgrade in two phases The currect code expects that the router returns back the status of the NVM authentication immediately. When tested against a real USB4 device what happens is that the router is reset and only after that the result is updated in the ROUTER_CS_26 register status field. This also seems to align better what the spec suggests. For this reason do the same what we already do with the Thunderbolt 3 devices and perform the NVM upgrade in two phases. First start the NVM_AUTH router operation and once the router is added back after the reset read the status in ROUTER_CS_26 and expose it to the userspace accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-10 11:34:07 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Perform USB4 router NVM upgrade in two phases The currect code expects that the router returns back the status of the NVM authentication immediately. When tested against a real USB4 device what happens is that the router is reset and only after that the result is updated in the ROUTER_CS_26 register status field. This also seems to align better what the spec suggests. For this reason do the same what we already do with the Thunderbolt 3 devices and perform the NVM upgrade in two phases. First start the NVM_AUTH router operation and once the router is added back after the reset read the status in ROUTER_CS_26 and expose it to the userspace accordingly. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-10 11:34:07 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Read router preferred credit allocation information USB4 routers must expose their preferred credit (buffer) allocation information through router operation. This information tells the connection manager how the router prefers its buffers to be allocated to get the expected bandwidth for the supported protocols. Read this information and store it as part of struct tb_switch for each USB4 router. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-03-10 13:34:12 +02:00
thunderbolt: Move constants related to NVM into nvm.c Move constants related to NVM into nvm.c to make the code cleaner. Use a separate constant for USB4_DATA_DWORDS in usb4.c. No functional changes. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-05-11 11:19:19 +03:00
thunderbolt: Read router preferred credit allocation information USB4 routers must expose their preferred credit (buffer) allocation information through router operation. This information tells the connection manager how the router prefers its buffers to be allocated to get the expected bandwidth for the supported protocols. Read this information and store it as part of struct tb_switch for each USB4 router. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-03-10 13:34:12 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Get rid of redundant 'else' In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-27 20:20:16 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Get rid of redundant 'else' In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-27 20:20:16 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Pass metadata directly to usb4_switch_op() We are going to make usb4_switch_op() to match better the corresponding firmware (ICM) USB4 router operation proxy interface, so that we can use either based on the connection manager implementation. For this reason pass metadata directly to usb4_switch_op(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-11-02 14:54:23 +02:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Get rid of redundant 'else' In the snippets like the following if (...) return / goto / break / continue ...; else ... the 'else' is redundant. Get rid of it. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-27 20:20:16 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Make usb4_switch_map_pcie_down() also return enabled ports Just for symmetry with the usb4_switch_map_usb3_down() make this one also return ports that are enabled. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-03-11 16:12:50 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Add support for USB 3.x tunnels 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>
2019-12-17 15:33:44 +03:00
thunderbolt: Make usb4_switch_map_usb3_down() also return enabled ports We need to call this on enabled ports in order to find the mapping from host router USB4 port to a USB 3.x downstream adapter, so make the function return enabled ports as well. While there fix parameter alignment in tb_find_usb3_down(). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-03-11 16:00:46 +03:00
thunderbolt: Add support for USB 3.x tunnels 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>
2019-12-17 15:33:44 +03:00
thunderbolt: Add USB4 port devices Create devices for each USB4 port. This is needed when we add retimer access when there is no device connected but may be useful for other purposes too following what USB subsystem does. This exports a single attribute "link" that shows the type of the USB4 link (or "none" if there is no cable connected). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-01 17:34:20 +03:00
thunderbolt: Add initial support for USB4 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>
2019-12-17 15:33:40 +03:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Explicitly enable lane adapter hotplug events at startup Software that has run before the USB4 CM in Linux runs may have disabled hotplug events for a given lane adapter. Other CMs such as that one distributed with Windows 11 will enable hotplug events. Do the same thing in the Linux CM which fixes hotplug events on "AMD Pink Sardine". Cc: stable@vger.kernel.org Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-09-26 09:33:50 -05:00
thunderbolt: Introduce tb_port_reset() Introduce a function that issues Downstream Port Reset to a USB4 port. This supports Thunderbolt 2, 3 and USB4 routers. Signed-off-by: Sanath S <Sanath.S@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-01-13 11:39:57 +02:00
thunderbolt: Set port configured for both ends of the link Both ends of the link needs to have this set. Otherwise the link is not re-established properly after sleep. Now since it is possible to have mixed USB4 and Thunderbolt 1, 2 and 3 devices we need to split the link configuration functionality to happen per port so we can pick the correct implementation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-04-02 12:42:44 +03:00
thunderbolt: Configure port for XDomain When the port is connected to another host it should be marked as such in the USB4 port capability. This information is used by the router during sleep and wakeup. Also do the same for legacy switches via link controller vendor specific registers. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-04-09 14:23:32 +03:00
thunderbolt: Show link type for XDomain connections too Following what we do for routers already, extend this to XDomain connections as well. This will show in sysfs whether the link is in USB4 or Thunderbolt mode. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-30 18:32:47 +03:00
thunderbolt: Configure port for XDomain When the port is connected to another host it should be marked as such in the USB4 port capability. This information is used by the router during sleep and wakeup. Also do the same for legacy switches via link controller vendor specific registers. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-04-09 14:23:32 +03:00
thunderbolt: Show link type for XDomain connections too Following what we do for routers already, extend this to XDomain connections as well. This will show in sysfs whether the link is in USB4 or Thunderbolt mode. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-30 18:32:47 +03:00
thunderbolt: Configure port for XDomain When the port is connected to another host it should be marked as such in the USB4 port capability. This information is used by the router during sleep and wakeup. Also do the same for legacy switches via link controller vendor specific registers. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-04-09 14:23:32 +03:00
thunderbolt: Show link type for XDomain connections too Following what we do for routers already, extend this to XDomain connections as well. This will show in sysfs whether the link is in USB4 or Thunderbolt mode. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-30 18:32:47 +03:00
thunderbolt: Configure port for XDomain When the port is connected to another host it should be marked as such in the USB4 port capability. This information is used by the router during sleep and wakeup. Also do the same for legacy switches via link controller vendor specific registers. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-04-09 14:23:32 +03:00
thunderbolt: Show link type for XDomain connections too Following what we do for routers already, extend this to XDomain connections as well. This will show in sysfs whether the link is in USB4 or Thunderbolt mode. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: David S. Miller <davem@davemloft.net>
2022-08-30 18:32:47 +03:00
thunderbolt: Configure port for XDomain When the port is connected to another host it should be marked as such in the USB4 port capability. This information is used by the router during sleep and wakeup. Also do the same for legacy switches via link controller vendor specific registers. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-04-09 14:23:32 +03:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Move constants related to NVM into nvm.c Move constants related to NVM into nvm.c to make the code cleaner. Use a separate constant for USB4_DATA_DWORDS in usb4.c. No functional changes. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-05-11 11:19:19 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Move constants related to NVM into nvm.c Move constants related to NVM into nvm.c to make the code cleaner. Use a separate constant for USB4_DATA_DWORDS in usb4.c. No functional changes. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-05-11 11:19:19 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Introduce usb4_port_sb_opcode_err_to_errno() helper The usb4_port_sb_opcode_err_to_errno() converts from USB4 error codes to the Linux errno space. In particular, this makes the intention of the repeating usb4_port_retimer_read() call in the usb4_port_retimer_nvm_authenticate_status() clearer. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-30 13:23:42 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Introduce usb4_port_sb_opcode_err_to_errno() helper The usb4_port_sb_opcode_err_to_errno() converts from USB4 error codes to the Linux errno space. In particular, this makes the intention of the repeating usb4_port_retimer_read() call in the usb4_port_retimer_nvm_authenticate_status() clearer. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-30 13:23:42 +03:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Add additional USB4 port operations for retimer access When accessing retimers when there is no cable connected we are going to need additional USB4 port operations. First the port needs to be put into offline mode, and then the sideband channel transactions must be enabled on the SBTX line. This adds support for these operations. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-01 18:38:05 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Add CL0s support for USB4 routers 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-17 03:16:39 +02:00
thunderbolt: Add support for asymmetric link USB4 v2 spec defines a Gen 4 link that can operate as an aggregated symmetric (80/80G) or asymmetric (120/40G). When the link is asymmetric, the USB4 port on one side of the link operates with three TX lanes and one RX lane, while the USB4 port on the opposite side of the link operates with three RX lanes and one TX lane. Add support for the asymmetric link and provide functions that can be used to transition the link to asymmetric and back. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-08-10 22:37:15 +03:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Add support for asymmetric link USB4 v2 spec defines a Gen 4 link that can operate as an aggregated symmetric (80/80G) or asymmetric (120/40G). When the link is asymmetric, the USB4 port on one side of the link operates with three TX lanes and one RX lane, while the USB4 port on the opposite side of the link operates with three RX lanes and one TX lane. Add support for the asymmetric link and provide functions that can be used to transition the link to asymmetric and back. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-08-10 22:37:15 +03:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Add support for asymmetric link USB4 v2 spec defines a Gen 4 link that can operate as an aggregated symmetric (80/80G) or asymmetric (120/40G). When the link is asymmetric, the USB4 port on one side of the link operates with three TX lanes and one RX lane, while the USB4 port on the opposite side of the link operates with three RX lanes and one TX lane. Add support for the asymmetric link and provide functions that can be used to transition the link to asymmetric and back. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-08-10 22:37:15 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Don't hardcode margining capabilities size Use or pass ARRAY_SIZE() of the capabilities array instead of hardcoding it. USB4 Gen 4 introduces an additional data word, which requires expanding the capabilities array. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-15 21:45:13 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Don't hardcode margining capabilities size Use or pass ARRAY_SIZE() of the capabilities array instead of hardcoding it. USB4 Gen 4 introduces an additional data word, which requires expanding the capabilities array. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-15 21:45:13 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Don't hardcode margining capabilities size Use or pass ARRAY_SIZE() of the capabilities array instead of hardcoding it. USB4 Gen 4 introduces an additional data word, which requires expanding the capabilities array. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-15 21:45:13 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Consolidate margining parameters into a structure Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:18 +03:00
thunderbolt: debugfs: Don't hardcode margining results size Use ARRAY_SIZE() when available or pass in the array size derived from it. This is in preparation for adding another result data word for supporting Gen 4 asymmetric links with an additional lane. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-15 21:45:19 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Consolidate margining parameters into a structure Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:18 +03:00
thunderbolt: debugfs: Don't hardcode margining results size Use ARRAY_SIZE() when available or pass in the array size derived from it. This is in preparation for adding another result data word for supporting Gen 4 asymmetric links with an additional lane. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-15 21:45:19 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Consolidate margining parameters into a structure Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:18 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: debugfs: Implement Gen 4 margining eye selection Add a debugfs knob for USB4 Gen 4 margining eye selection. Gen 4 uses 3-level pulse amplitude modulation (PAM3) which changes how margining measurements are made because PAM3 has two eyes per lane from which the margins can be measured. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-15 21:45:15 +03:00
thunderbolt: Consolidate margining parameters into a structure Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:18 +03:00
thunderbolt: Add optional voltage offset range for receiver lane margining Add optional extended voltage offset range support for software and hardware margining as defined by the USB4 specification. If supported, it can be enabled like below: # cd /sys/kernel/debug/thunderbolt/ROUTER/portX/margining/ # echo Y > optional_voltage_offset Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: R Kannappan <r.kannappan@intel.com> Signed-off-by: R Kannappan <r.kannappan@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:19 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: debugfs: Don't hardcode margining results size Use ARRAY_SIZE() when available or pass in the array size derived from it. This is in preparation for adding another result data word for supporting Gen 4 asymmetric links with an additional lane. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-15 21:45:19 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Consolidate margining parameters into a structure Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:18 +03:00
thunderbolt: Add missing usb4_port_sb_read() to usb4_port_sw_margin() Synchronize the operation completion by reading back the software margining operation completion metadata into margining->results. Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Co-developed-by: R Kannappan <r.kannappan@intel.com> Signed-off-by: R Kannappan <r.kannappan@intel.com> Co-developed-by: Rene Sapiens <rene.sapiens@intel.com> Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:17 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Consolidate margining parameters into a structure Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:18 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Consolidate margining parameters into a structure Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:18 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Add optional voltage offset range for receiver lane margining Add optional extended voltage offset range support for software and hardware margining as defined by the USB4 specification. If supported, it can be enabled like below: # cd /sys/kernel/debug/thunderbolt/ROUTER/portX/margining/ # echo Y > optional_voltage_offset Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: R Kannappan <r.kannappan@intel.com> Signed-off-by: R Kannappan <r.kannappan@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:19 +03:00
thunderbolt: Consolidate margining parameters into a structure Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:18 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: debugfs: Implement Gen 4 margining eye selection Add a debugfs knob for USB4 Gen 4 margining eye selection. Gen 4 uses 3-level pulse amplitude modulation (PAM3) which changes how margining measurements are made because PAM3 has two eyes per lane from which the margins can be measured. Signed-off-by: Aapo Vienamo <aapo.vienamo@iki.fi> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-08-15 21:45:15 +03:00
thunderbolt: Consolidate margining parameters into a structure Consolidate the hardware and software margining parameters into a single structure to reduce the number of parameters passed to the margining functions. Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:18 +03:00
thunderbolt: Improve software receiver lane margining USB4 specification defines the metadata needed to perform software margining, as well as the necessary steps which include waiting for dwell time. - Add dwell_time attribute to set the wait time while performing margining and checking for link errors. - Add error_counter attribute to configure error counter prior to margining test. - Add voltage_time_offset attribute to set the voltage or time offset steps before performing the software margining test. - Perform software margining test for dwell duration, break if there are link errors, stop the clocks and provide results. Below is a minimalistic example how this can be used. Note these values are just examples. The exact values in practice depend on host specific capabilities and the type of measurement to be performed. # cd /sys/kernel/debug/thunderbolt/ROUTER/portX/margining/ # echo software > mode # echo 400 > dwell_time # echo 1 > run As usual the results attribute contains the results of a succesfull run. Signed-off-by: R Kannappan <r.kannappan@intel.com> Co-developed-by: Rene Sapiens <rene.sapiens@intel.com> Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Co-developed-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:20 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Add missing usb4_port_sb_read() to usb4_port_sw_margin() Synchronize the operation completion by reading back the software margining operation completion metadata into margining->results. Signed-off-by: Aapo Vienamo <aapo.vienamo@linux.intel.com> Co-developed-by: R Kannappan <r.kannappan@intel.com> Signed-off-by: R Kannappan <r.kannappan@intel.com> Co-developed-by: Rene Sapiens <rene.sapiens@intel.com> Signed-off-by: Rene Sapiens <rene.sapiens@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-07-19 21:37:17 +03:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Make margining functions accept target and retimer index In order to add lane margining support for retimers make the margining functions take sideband target and retimer index as parameters. This makes it possible to access both router and retimer sideband using the same functions. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 10:02:55 +02:00
thunderbolt: Add support for receiver lane margining USB4 spec defines standard set of registers to be used for receiver lane margining. This is useful for I/O interface quality and electrical robustness validation during manufacturing. Expose receiver lane margining through new debugfs directory "margining" that is added under each connected USB4 port. Users can then run the margining by writing to the exposed attributes under that directory. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-02-22 19:31:47 +02:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Add additional USB4 port operations for retimer access When accessing retimers when there is no cable connected we are going to need additional USB4 port operations. First the port needs to be put into offline mode, and then the sideband channel transactions must be enabled on the SBTX line. This adds support for these operations. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2021-04-01 18:38:05 +03:00
thunderbolt: Add missing UNSET_INBOUND_SBTX for retimer access According to USB4 retimer specification, the process of firmware update sequence requires issuing a SET_INBOUND_SBTX port operation that later shall be followed by UNSET_INBOUND_SBTX port operation. This last step is not currently issued by the driver but it is necessary to make sure the retimers are put back to passthrough mode even during enumeration. If this step is missing the link may not come up properly after soft-reboot for example. For this reason issue UNSET_INBOUND_SBTX after SET_INBOUND_SBTX for enumeration and also when the NVM upgrade is run. Reported-by: Christian Schaubschläger <christian.schaubschlaeger@gmx.at> Link: https://lore.kernel.org/linux-usb/b556f5ed-5ee8-9990-9910-afd60db93310@gmx.at/ Cc: stable@vger.kernel.org Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-03 00:17:24 +02:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Add receiver lane margining support for retimers Retimers support lane margining as well so make this available through debugfs in the same way as we do for the USB4 ports. When this is enabled we also expose retimers on the other side of the cable because typically margining is implemented only on direction towards the cable. However, for the retimers on the other side of the cable we do not allow NVM upgrade to avoid confusing the existing userspace (the same retimer may now appear twice with different name) and is probably not a good idea anyway. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-21 11:40:49 +02:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Add WRITE_ONLY and AUTHENTICATE_ONLY NVM operations for retimers The same way we support these two operations for USB4 routers we can extend the retimer NVM operations to support retimers also. 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-12 15:29:16 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Split NVM read/write generic functions out from usb4.c We do this for Thunderbolt 2/3 devices through DMA port, USB4 devices and retimers pretty much the same way. Only the actual block read/write is different. For this reason split out the NVM read/write functions from usb4.c to nvm.c and make USB4 device code call these when needed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-01 16:54:15 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Split NVM read/write generic functions out from usb4.c We do this for Thunderbolt 2/3 devices through DMA port, USB4 devices and retimers pretty much the same way. Only the actual block read/write is different. For this reason split out the NVM read/write functions from usb4.c to nvm.c and make USB4 device code call these when needed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-01 16:54:15 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Introduce usb4_port_sb_opcode_err_to_errno() helper The usb4_port_sb_opcode_err_to_errno() converts from USB4 error codes to the Linux errno space. In particular, this makes the intention of the repeating usb4_port_retimer_read() call in the usb4_port_retimer_nvm_authenticate_status() clearer. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-30 13:23:42 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Introduce usb4_port_sb_opcode_err_to_errno() helper The usb4_port_sb_opcode_err_to_errno() converts from USB4 error codes to the Linux errno space. In particular, this makes the intention of the repeating usb4_port_retimer_read() call in the usb4_port_retimer_nvm_authenticate_status() clearer. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-30 13:23:42 +03:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Introduce usb4_port_sb_opcode_err_to_errno() helper The usb4_port_sb_opcode_err_to_errno() converts from USB4 error codes to the Linux errno space. In particular, this makes the intention of the repeating usb4_port_retimer_read() call in the usb4_port_retimer_nvm_authenticate_status() clearer. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-30 13:23:42 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Move constants related to NVM into nvm.c Move constants related to NVM into nvm.c to make the code cleaner. Use a separate constant for USB4_DATA_DWORDS in usb4.c. No functional changes. Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-05-11 11:19:19 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Make usb4_port_sb_read/write() available outside of usb4.c We need to call these from other files too so make them available outside of usb4.c. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-16 09:41:14 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Split NVM read/write generic functions out from usb4.c We do this for Thunderbolt 2/3 devices through DMA port, USB4 devices and retimers pretty much the same way. Only the actual block read/write is different. For this reason split out the NVM read/write functions from usb4.c to nvm.c and make USB4 device code call these when needed. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2021-04-01 16:54:15 +03:00
thunderbolt: Implement USB4 port sideband operations for retimer access USB4 spec specifies standard set of sideband operations that are send over the low speed link to access either retimers on the link or the link parter (the other router). The USB4 retimer spec extends these and adds operations for retimer NVM upgrade. This implements the retimer access and NVM upgrade USB4 port sideband operations which we need for retimer support in the patch that follows. 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>
2020-03-05 16:33:46 +02:00
thunderbolt: Limit USB3 bandwidth of certain Intel USB4 host routers Current Intel USB4 host routers have hardware limitation that the USB3 bandwidth cannot go higher than 16376 Mb/s. Work this around by adding a new quirk that limits the bandwidth for the affected host routers. Cc: stable@vger.kernel.org Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-01-31 13:04:52 +02:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Limit USB3 bandwidth of certain Intel USB4 host routers Current Intel USB4 host routers have hardware limitation that the USB3 bandwidth cannot go higher than 16376 Mb/s. Work this around by adding a new quirk that limits the bandwidth for the affected host routers. Cc: stable@vger.kernel.org Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-01-31 13:04:52 +02:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Increase sideband access polling delay The USB4 sideband access is slow compared to the high-speed link and the access timing parameters are tens of milliseconds according the spec. To avoid too much unnecessary polling for the sideband pass the wait delay to usb4_port_wait_for_bit() and use larger (5ms) value compared to the high-speed access. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2024-04-05 07:50:50 +03:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Ensure left shift of 512 does not overflow a 32 bit int The 32 bit int value 512 is being left shifted and then used in a context that expects the expression to be a larger unsigned long. There may be a potential integer overflow, so make 512 a UL before shift to avoid any such issues. Addresses-Coverity: ("Uninintentional integer overflow") Fixes: 3b1d8d577ca8 ("thunderbolt: Implement USB3 bandwidth negotiation routines") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-06-30 15:55:58 +01:00
thunderbolt: Make use of SI units from units.h In a couple of places it seems reasonable to use MEGA intead of explicit number. It makes code more readable and robust. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-27 20:20:17 +03:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Make use of SI units from units.h In a couple of places it seems reasonable to use MEGA intead of explicit number. It makes code more readable and robust. Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-03-27 20:20:17 +03:00
thunderbolt: Ensure left shift of 512 does not overflow a 32 bit int The 32 bit int value 512 is being left shifted and then used in a context that expects the expression to be a larger unsigned long. There may be a potential integer overflow, so make 512 a UL before shift to avoid any such issues. Addresses-Coverity: ("Uninintentional integer overflow") Fixes: 3b1d8d577ca8 ("thunderbolt: Implement USB3 bandwidth negotiation routines") Signed-off-by: Colin Ian King <colin.king@canonical.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-06-30 15:55:58 +01:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Use scale field when allocating USB3 bandwidth When tunneling aggregated USB3 (20 Gb/s) the bandwidth values that are programmed to the ADP_USB3_CS_2 go higher than 4096 and that does not fit anymore to the 12-bit field. Fix this by scaling the value using the scale field accordingly. Fixes: 3b1d8d577ca8 ("thunderbolt: Implement USB3 bandwidth negotiation routines") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-12-27 11:55:26 +02:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Use scale field when allocating USB3 bandwidth When tunneling aggregated USB3 (20 Gb/s) the bandwidth values that are programmed to the ADP_USB3_CS_2 go higher than 4096 and that does not fit anymore to the 12-bit field. Fix this by scaling the value using the scale field accordingly. Fixes: 3b1d8d577ca8 ("thunderbolt: Implement USB3 bandwidth negotiation routines") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-12-27 11:55:26 +02:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Use scale field when allocating USB3 bandwidth When tunneling aggregated USB3 (20 Gb/s) the bandwidth values that are programmed to the ADP_USB3_CS_2 go higher than 4096 and that does not fit anymore to the 12-bit field. Fix this by scaling the value using the scale field accordingly. Fixes: 3b1d8d577ca8 ("thunderbolt: Implement USB3 bandwidth negotiation routines") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-12-27 11:55:26 +02:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Fix minimum allocated USB 3.x and PCIe bandwidth With the current bandwidth allocation we end up reserving too much for the USB 3.x and PCIe tunnels that leads to reduced capabilities for the second DisplayPort tunnel. Fix this by decreasing the USB 3.x allocation to 900 Mb/s which then allows both tunnels to get the maximum HBR2 bandwidth. This way, the reserved bandwidth for USB 3.x and PCIe, would be 1350 Mb/s (taking weights of USB 3.x and PCIe into account). So bandwidth allocations on a link are: USB 3.x + PCIe tunnels => 1350 Mb/s DisplayPort tunnel #1 => 17280 Mb/s DisplayPort tunnel #2 => 17280 Mb/s Total consumed bandwidth is 35910 Mb/s. So that all the above can be tunneled on a Gen 3 link (which allows maximum of 36000 Mb/s). Fixes: 582e70b0d3a4 ("thunderbolt: Change bandwidth reservations to comply USB4 v2") Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-11-30 18:17:13 +02:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Fix minimum allocated USB 3.x and PCIe bandwidth With the current bandwidth allocation we end up reserving too much for the USB 3.x and PCIe tunnels that leads to reduced capabilities for the second DisplayPort tunnel. Fix this by decreasing the USB 3.x allocation to 900 Mb/s which then allows both tunnels to get the maximum HBR2 bandwidth. This way, the reserved bandwidth for USB 3.x and PCIe, would be 1350 Mb/s (taking weights of USB 3.x and PCIe into account). So bandwidth allocations on a link are: USB 3.x + PCIe tunnels => 1350 Mb/s DisplayPort tunnel #1 => 17280 Mb/s DisplayPort tunnel #2 => 17280 Mb/s Total consumed bandwidth is 35910 Mb/s. So that all the above can be tunneled on a Gen 3 link (which allows maximum of 36000 Mb/s). Fixes: 582e70b0d3a4 ("thunderbolt: Change bandwidth reservations to comply USB4 v2") Signed-off-by: Gil Fine <gil.fine@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-11-30 18:17:13 +02:00
thunderbolt: Implement USB3 bandwidth negotiation routines Each host router USB3 downstream adapter has a set of registers that are used to negotiate bandwidth between the connection manager and the internal xHCI controller. These registers allow dynamic bandwidth management for USB3 isochronous traffic based on what is actually consumed vs. allocated at any given time. Implement these USB3 bandwidth negotiation routines to allow the software connection manager take advantage of these. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2020-02-21 23:14:41 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Log an error if DPTX request is not cleared This helps debugging issues around DisplayPort bandwidth allocation mode. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-12-28 16:49:45 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Log an error if DPTX request is not cleared This helps debugging issues around DisplayPort bandwidth allocation mode. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-12-28 16:49:45 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Handle bandwidth allocation mode enablement notification When the graphics side enables bandwidth allocation mode the DP IN adapter sends notification to the connection manager about this. Currently the handler misses this and tries to allocate 0 Mb/s that then makes the graphics side to think the request failed. Fix this by properly handling the enablement notification. Fixes: 6ce3563520be ("thunderbolt: Add support for DisplayPort bandwidth allocation mode") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-01-23 08:28:20 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Make bandwidth allocation mode function names consistent 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>
2023-02-01 13:21:37 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Handle bandwidth allocation mode enablement notification When the graphics side enables bandwidth allocation mode the DP IN adapter sends notification to the connection manager about this. Currently the handler misses this and tries to allocate 0 Mb/s that then makes the graphics side to think the request failed. Fix this by properly handling the enablement notification. Fixes: 6ce3563520be ("thunderbolt: Add support for DisplayPort bandwidth allocation mode") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-01-23 08:28:20 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Handle bandwidth allocation mode enablement notification When the graphics side enables bandwidth allocation mode the DP IN adapter sends notification to the connection manager about this. Currently the handler misses this and tries to allocate 0 Mb/s that then makes the graphics side to think the request failed. Fix this by properly handling the enablement notification. Fixes: 6ce3563520be ("thunderbolt: Add support for DisplayPort bandwidth allocation mode") Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2023-01-23 08:28:20 +02:00
thunderbolt: Add functions to support DisplayPort bandwidth allocation mode USB4 spec defines an additional feature that DP IN adapters can implement (alongside with the graphics DPCD register set) to support more dynamic bandwidth management for DisplayPort tunnels. For the connection manager the communication happens through the DP IN adapter using a set of registers in the adapter config space allocated for this. Add functions that export this functionality for the rest of the driver. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
2022-03-23 16:18:28 +02:00
thunderbolt: Enable USB4 v2 PCIe TLP/DLLP extended encapsulation 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>
2022-09-29 12:49:48 +03:00