summaryrefslogtreecommitdiffstats
path: root/drivers/thunderbolt/tb.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
...
* Merge tag 'thunderbolt-for-v6.3-rc1' of ↵Greg Kroah-Hartman2023-02-081-18/+490
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Changes for v6.3 merge window This includes following Thunderbolt/USB4 changes for the v6.3 merge window: - Add support for DisplayPort bandwidth allocation mode - Debug logging improvements - Minor cleanups. All these have been in linux-next with no reported issues. * tag 'thunderbolt-for-v6.3-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: thunderbolt: Add missing kernel-doc comment to tb_tunnel_maximum_bandwidth() thunderbolt: Handle bandwidth allocation mode enablement notification thunderbolt: Add support for DisplayPort bandwidth allocation mode thunderbolt: Include the additional DP IN double word in debugfs dump thunderbolt: Add functions to support DisplayPort bandwidth allocation mode thunderbolt: Increase timeout of DP OUT adapter handshake thunderbolt: Take CL states into account when waiting for link to come up thunderbolt: Improve debug logging in tb_available_bandwidth() thunderbolt: Log DP adapter type thunderbolt: Use decimal port number in control and tunnel logs too thunderbolt: Refactor tb_acpi_add_link() thunderbolt: Use correct type in tb_port_is_clx_enabled() prototype
| * thunderbolt: Handle bandwidth allocation mode enablement notificationMika Westerberg2023-01-271-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | 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>
| * thunderbolt: Add support for DisplayPort bandwidth allocation modeMika Westerberg2023-01-171-14/+479
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USB4 spec defines an optional feature that allows the connection manager to negotiate with the graphics through DPCD registers changes in the bandwidth allocation dynamically. This is referred as "bandwidth allocation mode" in the spec. The connection manager uses DP IN adapters registers to communicate with the graphics, and also gets notifications from these adapters when the graphics wants to change the bandwidth allocation. Both the connection manager and the graphics driver needs to support this. We check if the DP IN adapter supports this and if it does enable it before establishing a DP tunnel. Then we react on DP_BW notifications coming from the DP IN adapter and update the bandwidth allocation accordingly (within the maximum common capabilities the DP IN/OUT support). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * thunderbolt: Improve debug logging in tb_available_bandwidth()Mika Westerberg2023-01-171-2/+5
| | | | | | | | | | | | | | This makes it easier to see what is going on when bandwidth is being allocated for tunneling. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * thunderbolt: Log DP adapter typeMika Westerberg2023-01-171-2/+2
| | | | | | | | | | | | | | | | | | This makes it easier to see from the debug logs what type of DisplayPort adapter is in use or available. No functional changes. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | thunderbolt: Do not call PM runtime functions in tb_retimer_scan()Mika Westerberg2023-01-091-5/+15
|/ | | | | | | | | | | | | | | | | | We cannot call PM runtime functions in tb_retimer_scan() because it will also be called when retimers are scanned from userspace (happens when there is no device connected on ChromeOS for instance) and at the same USB4 port runtime resume hook. This leads to hang because neither can proceed. Fix this by runtime resuming USB4 ports in tb_scan_port() instead. This makes sure the ports are runtime PM active when retimers are added under it while avoiding the reported hang as well. Reported-by: Utkarsh Patel <utkarsh.h.patel@intel.com> Fixes: 1e56c88adecc ("thunderbolt: Runtime resume USB4 port when retimers are scanned") Cc: stable@vger.kernel.org Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* Merge tag 'usb-6.1-rc1' of ↵Linus Torvalds2022-10-081-1/+32
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb Pull USB / Thunderbolt updates from Greg KH: "Here is the big set of USB and Thunderbolt driver changes for 6.1-rc1. Nothing major in here, lots of little things with new devices supported and updates for a few drivers. Highlights include: - thunderbolt/USB4 devices supported a bit better than before, and some new ids to enable new hardware devices - USB gadget uvc updates for newer video formats and better v4l integration (the v4l portions were acked by those maintainers) - typec updates for tiny issues and more typec drivers for new chips. - xhci tiny updates for minor issues - big usb-serial ftdi_sio driver update to handle new devices better - lots of tiny dwc3 fixes and updates for the IP block that is showing up everywhere these days - dts updates for new devices being supported - other tiny janitorial and cleanups fixes for lots of different USB drivers. Full details are in the shortlog. All of these have been in linux-next for a while with no reported issues" * tag 'usb-6.1-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (169 commits) usb: gadget: uvc: don't put item still in use usb: gadget: uvc: Fix argument to sizeof() in uvc_register_video() usb: host: ehci-exynos: switch to using gpiod API Revert "usb: dwc3: Don't switch OTG -> peripheral if extcon is present" Revert "USB: fixup for merge issue with "usb: dwc3: Don't switch OTG -> peripheral if extcon is present"" dt-bindings: usb: Convert FOTG210 to dt schema usb: mtu3: fix failed runtime suspend in host only mode USB: omap_udc: Fix spelling mistake: "tranceiver_ctrl" -> "transceiver_ctrl" usb: typec: ucsi_ccg: Disable UCSI ALT support on Tegra usb: typec: Replace custom implementation of device_match_fwnode() usb: typec: ucsi: Don't warn on probe deferral usb: add quirks for Lenovo OneLink+ Dock MAINTAINERS: switch dwc3 to Thinh usb: idmouse: fix an uninit-value in idmouse_open USB: PHY: JZ4770: Switch to use dev_err_probe() helper usb: phy: generic: Switch to use dev_err_probe() helper usb: ulpi: use DEFINE_SHOW_ATTRIBUTE to simplify ulpi_regs usb: cdns3: remove dead code usb: cdc-wdm: Use skb_put_data() instead of skb_put/memcpy pair usb: musb: sunxi: Switch to use dev_err_probe() helper ...
| * thunderbolt: Allow NVM upgrade of USB4 host routersSzuying Chen2022-09-071-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | Intel pre-USB4 host routers required the firmware connection manager to be active in order to perform NVM firmware upgrade and for this reason it was disabled when software connection manager is active. However, this is not necessary for USB4 host routers as this functionality is part of router operations that the router implements if it wants to support this. Signed-off-by: Szuying Chen <Chloe_Chen@asmedia.com.tw> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * thunderbolt: Add DP OUT resource when DP tunnel is discoveredSanjay R Mehta2022-08-151-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | If the boot firmware implements a connection manager of its own it may create a DisplayPort tunnel and will be handed off to Linux connection manager, but the DP OUT resource is not saved in the dp_resource list. This patch adds tunnelled DP OUT port to the dp_resource list once the DP tunnel is discovered. Signed-off-by: Sanjay R Mehta <sanju.mehta@amd.com> Signed-off-by: Basavaraj Natikar <Basavaraj.Natikar@amd.com> Tested-by: Renjith Pananchikkal <Renjith.Pananchikkal@amd.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | thunderbolt: Show link type for XDomain connections tooMika Westerberg2022-08-311-4/+4
|/ | | | | | | | | 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>
* thunderbolt: Change TMU mode to HiFi uni-directional once DisplayPort tunneledGil Fine2022-06-061-0/+13
| | | | | | | | | | | | Here we configure TMU mode to HiFi uni-directional once DP tunnel is created. This is due to accuracy requirement for DP tunneling as appears in CM guide 1.0, section 7.3.2. Due to Intel hardware limitation, once we changed the TMU mode to HiFi uni-directional (when DP tunnel exists), we don't change TMU mode back to normal uni-directional, even if DP tunnel is torn down later. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add CL1 support for USB4 and Titan Ridge routersGil Fine2022-06-061-15/+40
| | | | | | | | | | | | In this patch we add support for a second low power state of the link: CL1. Low power states (called collectively CLx) are used to reduce transmitter and receiver power when a high-speed lane is idle. 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>
* thunderbolt: Silently ignore CLx enabling in case CLx is not supportedGil Fine2022-06-061-2/+8
| | | | | | | | | We can't enable CLx if it is not supported either by the host or device, or by the USB4/TBT link (e.g. when an optical cable is used). We silently ignore CLx enabling in this case. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for XDomain lane bondingMika Westerberg2022-05-051-6/+0
| | | | | | | | | | | | | | | | | | | | | The USB4 Inter-Domain Service specification defines a protocol that can be used to establish lane bonding between two USB4 domains (hosts). So far we have not implemented it because the host controller DMA was not fast enough to be able to go over 20 Gbits/s even if lanes were bonded. However, starting from Intel Alder Lake CPUs the DMA can go over 20 Gbits/s so now it makes more sense to add this support to the driver. Because both ends need to negotiate the bonding we add a simple state machine that tracks the connection state and does the necessary steps described by the USB4 Inter-Domain Service specification. We only establish lane bonding when both sides of the link support it. Otherwise we default to use the single lane. Also this is only done when software connection manager is used. On systems with firmware based connection manager, it handles the high-speed tunneling so bonding lanes is specific to the implementation (Intel firmware based connection manager does not support lane bonding). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Use different lane for second DisplayPort tunnelMika Westerberg2022-04-191-2/+17
| | | | | | | | | | | | | | | | | | Brad reported that on Apple hardware with Light Ridge or Falcon Ridge controller, plugging in a chain of Thunderbolt displays (Light Ridge based controllers) causes all kinds of tearing and flickering. The reason for this is that on Thunderbolt 1 hardware there is no lane bonding so we have two independent 10 Gb/s lanes, and currently Linux tunnels both displays through the lane 1. This makes the displays to share the 10 Gb/s bandwidth which may not be enough for higher resolutions. For this reason make the second tunnel go through the lane 0 instead. This seems to match what the macOS connection manager is also doing. Reported-by: Brad Campbell <lists2009@fnarfbargle.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Tested-by: Brad Campbell <lists2009@fnarfbargle.com>
* thunderbolt: Add internal xHCI connect flows for Thunderbolt 3 devicesMika Westerberg2022-02-021-0/+11
| | | | | | | | | Both Alpine Ridge and Titan Ridge require special flows in order to activate the internal xHCI controller when there is USB device connected to the downstream type-C port. This implements the missing flows for both. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Enable CL0s for Intel Titan RidgeGil Fine2021-12-281-0/+7
| | | | | | | | | | | Low power link states (called collectively CLx) are used to reduce transmitter and receiver power when a high-speed lane is idle. The simplest one being called CL0s. Follow what we already do for USB4 device routers and enable CL0s for Intel Titan Ridge device router too. This allows better thermal management. Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add CL0s support for USB4 routersGil Fine2021-12-221-1/+8
| | | | | | | | | | | | | 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>
* thunderbolt: Add TMU uni-directional modeGil Fine2021-12-221-1/+8
| | | | | | | | | | Up until Titan Ridge (Thunderbolt 3) device routers only supported bi-directional mode. In this patch we add to TMU a uni-directional mode. The uni-directional mode is needed for enabling of low power state of the link (CLx). Signed-off-by: Gil Fine <gil.fine@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Tear down existing tunnels when resuming from hibernateMika Westerberg2021-12-071-16/+52
| | | | | | | | | | | | | If the boot firmware implements connection manager of its own it may not create the paths in the same way or order we do. For example it may create first PCIe tunnel and then USB3 tunnel. When we restore our tunnels (first de-activating them) we may be doing that over completely different tunnels and that leaves them possibly non-functional. For this reason we re-use the tunnel discovery functionality and find out all the existing tunnels, and tear them down. Once that is done we can restore our tunnels. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add device links only when software connection manager is usedMika Westerberg2021-06-111-0/+67
| | | | | | | | | We only need to set up the device links when software connection manager path is used. The firmware connection manager does not need them and if they are present they may even cause problems. Reviewed-by: Yehezkel Bernat <YehezkelShB@gmail.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for retimer NVM upgrade when there is no linkRajmohan Mani2021-06-011-2/+2
| | | | | | | | | | | | | | | | | | With help from platform firmware (ACPI) it is possible to power on retimers even when there is no USB4 link (e.g nothing is connected to the USB4 ports). This allows us to bring the USB4 sideband up so that we can access retimers and upgrade their NVM firmware. If the platform has support for this, we expose two additional attributes under USB4 ports: offline and rescan. These can be used to bring the port offline, rescan for the retimers and put the port online again. The retimer NVM upgrade itself works the same way than with cable connected. Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* Merge tag 'thunderbolt-for-v5.13-rc1' of ↵Greg Kroah-Hartman2021-04-131-19/+33
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt into usb-next Mika writes: thunderbolt: Changes for v5.13 merge window This includes following Thunderbolt/USB4 changes for v5.13 merge window: * Debugfs improvements * Align the inter-domain (peer-to-peer) support with the USB4 inter-domain spec for better interoperability * Add support for USB4 DROM and the new product descriptor * More KUnit tests * Detailed uevent for routers * Few miscellaneous improvements All these have been in linux-next without reported issues. * tag 'thunderbolt-for-v5.13-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: (24 commits) thunderbolt: Hide authorized attribute if router does not support PCIe tunnels thunderbolt: Add details to router uevent thunderbolt: Unlock on error path in tb_domain_add() thunderbolt: Add support for USB4 DROM thunderbolt: Check quirks in tb_switch_add() thunderbolt: Add KUnit tests for DMA tunnels thunderbolt: Add KUnit tests for XDomain properties net: thunderbolt: Align the driver to the USB4 networking spec thunderbolt: Allow multiple DMA tunnels over a single XDomain connection thunderbolt: Drop unused tb_port_set_initial_credits() thunderbolt: Use dedicated flow control for DMA tunnels thunderbolt: Add support for maxhopid XDomain property thunderbolt: Add tb_property_copy_dir() thunderbolt: Align XDomain protocol timeouts with the spec thunderbolt: Use pseudo-random number as initial property block generation thunderbolt: Do not re-establish XDomain DMA paths automatically thunderbolt: Add more logging to XDomain connections Documentation / thunderbolt: Drop speed/lanes entries for XDomain thunderbolt: Decrease control channel timeout for software connection manager thunderbolt: Do not pass timeout for tb_cfg_reset() ...
| * thunderbolt: Allow multiple DMA tunnels over a single XDomain connectionMika Westerberg2021-03-181-18/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently we have had an artificial limitation of a single DMA tunnel per XDomain connection. However, hardware wise there is no such limit and software based connection manager can take advantage of all the DMA rings available on the host to establish tunnels. For this reason make the tb_xdomain_[enable|disable]_paths() to take the DMA ring and HopID as parameter instead of storing them in the struct tb_xdomain. We also add API functions to allocate input and output HopIDs of the XDomain connection that the service drivers can use instead of hard-coding. Also convert the two existing service drivers over to this API. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
| * thunderbolt: Decrease control channel timeout for software connection managerMika Westerberg2021-03-181-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the firmware connection manager is not proxying between the software and the hardware we can decrease the timeout for control packets significantly. The USB4 spec recommends 10 ms +- 1 ms but we use slightly larger value (100 ms) which is recommendation from Intel Thunderbolt firmware folks. When firmware connection manager is running then we keep using the existing 5000 ms. To implement this we move the control channel allocation to tb_domain_alloc(), and pass the timeout from that function to the tb_ctl_alloc(). Then make both connection manager implementations pass the timeout when they alloc the domain structure. While there update kernel-doc of struct tb_ctl to match the reality. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* | thunderbolt: Increase runtime PM reference count on DP tunnel discoveryMika Westerberg2021-03-081-0/+4
|/ | | | | | | | | | | If the driver is unbound and then bound back it goes over the topology and figure out the existing tunnels. However, if it finds DP tunnel it should make sure the domain does not runtime suspend as otherwise it will tear down the DP tunnel unexpectedly. Fixes: 6ac6faee5d7d ("thunderbolt: Add runtime PM for Software CM") Cc: stable@vger.kernel.org Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for native USB4 _OSCMika Westerberg2021-02-041-1/+18
| | | | | | | | | | | | | | | | ACPI 6.4 introduced a new _OSC capability used to negotiate whether the OS is supposed to use Software (native) or Firmware based Connection Manager. If the native support is granted then there are set of bits that enable/disable different tunnel types that the Software Connection Manager is allowed to tunnel. This adds support for this new USB4 _OSC accordingly. When PCIe tunneling is disabled then the driver switches security level to be "nopcie" following the security level 5 used in Firmware based Connection Manager. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
* thunderbolt: Allow disabling XDomain protocolMika Westerberg2021-02-041-0/+3
| | | | | | | | | | | | | This allows disabling XDomain protocol completely if the user does not plan to use the USB4/Thunderbolt peer-to-peer functionality, or for security reasons. XDomain protocol is enabled by default but with this commit it is possible to disable it by passing "xdomain=0" as module parameter (or through the kernel command line). Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
* thunderbolt: tb: Kernel-doc function headers should document their parametersLee Jones2021-01-281-6/+6
| | | | | | | | | | | | | | | | | | | | | | Fixes the following W=1 kernel build warning(s): drivers/thunderbolt/tb.c:535: warning: Function parameter or member 'sw' not described in 'tb_scan_switch' drivers/thunderbolt/tb.c:551: warning: Function parameter or member 'port' not described in 'tb_scan_port' drivers/thunderbolt/tb.c:711: warning: Function parameter or member 'tb' not described in 'tb_free_invalid_tunnels' drivers/thunderbolt/tb.c:726: warning: Function parameter or member 'sw' not described in 'tb_free_unplugged_children' drivers/thunderbolt/tb.c:1129: warning: Function parameter or member 'work' not described in 'tb_handle_hotplug' drivers/thunderbolt/tb.c:1239: warning: Function parameter or member 'tb' not described in 'tb_handle_event' drivers/thunderbolt/tb.c:1239: warning: Function parameter or member 'type' not described in 'tb_handle_event' drivers/thunderbolt/tb.c:1239: warning: Function parameter or member 'buf' not described in 'tb_handle_event' drivers/thunderbolt/tb.c:1239: warning: Function parameter or member 'size' not described in 'tb_handle_event' drivers/thunderbolt/tb.c:1239: warning: expecting prototype for tb_schedule_hotplug_handler(). Prototype was for tb_handle_event() instead Cc: Andreas Noever <andreas.noever@gmail.com> Cc: Michael Jamet <michael.jamet@intel.com> Cc: Yehezkel Bernat <YehezkelShB@gmail.com> Cc: linux-usb@vger.kernel.org Signed-off-by: Lee Jones <lee.jones@linaro.org> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for de-authorizing devicesMika Westerberg2021-01-151-0/+20
| | | | | | | | | | | | | | | | | | | | In some cases it is useful to be able de-authorize devices. For example if user logs out the userspace can have a policy that disconnects PCIe devices until logged in again. This is only possible for software based connection manager as it directly controls the tunnels. For this reason make the authorized attribute accept writing 0 which makes the software connection manager to tear down the corresponding PCIe tunnel. Userspace can check if this is supported by reading a new domain attribute deauthorization, that holds 1 in that case. While there correct tb_domain_approve_switch() kernel-doc and description of authorized attribute to mention that it is only about PCIe tunnels. Cc: Christian Kellner <christian@kellner.me> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Acked-by: Yehezkel Bernat <YehezkelShB@gmail.com>
* thunderbolt: Log which connection manager implementation is usedMika Westerberg2020-11-301-0/+2
| | | | | | | This makes it easier to figure out whether the driver is using firmware or software based connection manager implementation. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Only stop control channel when entering freezeMika Westerberg2020-09-161-0/+18
| | | | | | | | | | According to the kernel power management documentation freeze phase should only quiesce the device, no need to configure wakes or put it to low power state. For this reason we simply stop the control channel and in case of Software Connection Manager also mark the hotplug disabled. This should align the driver better with the PM framework expectations. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add runtime PM for Software CMMika Westerberg2020-09-031-2/+114
| | | | | | | | | | | | | | | | | | | This adds runtime PM support for the Software Connection Manager parts of the driver. This allows to save power when either there is no device attached at all or there is a device attached and all following conditions are true: - Tunneled PCIe root/downstream ports are runtime suspended - Tunneled USB3 ports are runtime suspended - No active DisplayPort stream - No active XDomain connection For the first two we take advantage of device links that were added in previous patch. Difference for the system sleep case is that we also enable wakes when something is geting plugged in/out of the Thunderbolt ports. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Disable lane 1 for XDomain connectionMika Westerberg2020-09-031-0/+8
| | | | | | | | | USB4 spec mandates that the lane 1 should be disabled if lanes are not bonded. For host-to-host connections (XDomain) we don't support lane bonding so in order to be compatible with the spec, disable lane 1 when another host is connected. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Configure port for XDomainMika Westerberg2020-09-031-4/+28
| | | | | | | | | | | 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>
* thunderbolt: Configure link after lane bonding is enabledMika Westerberg2020-09-031-0/+5
| | | | | | | | | | During testing it was noticed that the link is not properly restored after the domain exits sleep if the link configured bits are set before lane bonding is enabled. The USB4 spec does not say in which order these need to be set but setting link configured afterwards makes the link restoration work so we do that instead. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Tear down DP tunnels when suspendingMika Westerberg2020-09-031-0/+24
| | | | | | | | | | DP tunnels do not need the same kind of treatment as others because they are created based on hot-plug events on DP adapter ports, and the display stack does not need the tunnels to be enabled when resuming from suspend. Also Tiger Lake Thunderbolt controller sends unplug event on D3 exit so this avoids that as well. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Send reset only to first generation routersMika Westerberg2020-09-031-1/+1
| | | | | | | First generation routers may need the reset command upon resume but it is not supported by newer generations. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: No need to log an error if tb_switch_lane_bonding_enable() failsMika Westerberg2020-09-031-4/+2
| | | | | | | The function already logs an error if it fails so get rid of the duplication. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for on-board retimersKranthi Kuntala2020-06-221-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | USB4 spec specifies standard access to retimers (both on-board and cable) through USB4 port sideband access. This makes it possible to upgrade their firmware in the same way than we already do with the routers. This enumerates on-board retimers under each USB4 port when the link comes up and adds them to the bus under the router the retimer belongs to. Retimers are exposed in sysfs with name like <device>:<port>.<index> where device is the router the retimer belongs to, port is the USB4 port the retimer is connected to and index is the retimer index under that port (starting from 1). This applies to the upstream USB4 port as well so if there is on-board retimer between the port and the router it is also added accordingly. At this time we do not add cable retimers but there is no techincal restriction to do so in the future if needed. It is not clear whether it makes sense to upgrade their firmwares and at least Thunderbolt 3 cables it has not been done outside of lab environments. The sysfs interface is made to follow the router NVM upgrade to make it easy to extend the existing userspace (fwupd) to handle these as well. Signed-off-by: Kranthi Kuntala <kranthi.kuntala@intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add USB3 bandwidth managementMika Westerberg2020-06-221-83/+257
| | | | | | | | | | | | | | | | | | | | USB3 supports both isochronous and non-isochronous traffic. The former requires guaranteed bandwidth and can take up to 90% of the total bandwidth. With USB4 USB3 is tunneled over USB4 fabric which means that we need to make sure there is enough bandwidth allocated for the USB3 tunnels in addition to DisplayPort tunnels. Whereas DisplayPort bandwidth management is static and done before the DP tunnel is established, the USB3 bandwidth management is dynamic and allows increasing and decreasing the allocated bandwidth according to what is currently consumed. This is done through host router USB3 downstream adapter registers. This adds USB3 bandwidth management to the software connection manager so that we always try to allocate maximum bandwidth for DP tunnels and what is left is allocated for USB3. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Report consumed bandwidth in both directionsMika Westerberg2020-06-221-4/+5
| | | | | | | | | | | Whereas DisplayPort bandwidth is consumed only in one direction (from DP IN adapter to DP OUT adapter), USB3 adds separate bandwidth for both upstream and downstream directions. For this reason extend the tunnel consumed bandwidth routines to support both directions and implement this for DP. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Make usb4_switch_map_pcie_down() also return enabled portsMika Westerberg2020-06-221-1/+1
| | | | | | | 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>
* thunderbolt: Make usb4_switch_map_usb3_down() also return enabled portsMika Westerberg2020-06-221-11/+3
| | | | | | | | | | 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>
* thunderbolt: Do not tunnel USB3 if link is not USB4Mika Westerberg2020-06-221-0/+3
| | | | | | | 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>
* thunderbolt: Add DP IN resources for all routersMika Westerberg2020-06-221-4/+46
| | | | | | | | | | | | | | | | | | | | USB4 spec allows DP tunneling from any router that has DP IN adapter, not just from host router. The driver currently only added the DP IN resources for the host router because Thunderbolt 1, 2 and 3 devices do not have DP IN adapters. However, USB4 allows device routers to have DP IN adapter as well so update the driver to add DP IN resources for each device that has one. One example would be an eGPU enclosure where the eGPU output is forwarded to DP IN port and then tunneled over the USB4 fabric. Only limitation we add now is that the DP IN and DP OUT that gets paired for tunnel creation should both be under the same topology starting from host router downstream port. In other words we do not create DP tunnels across host router at this time even though that is possible as well but it complicates the bandwidth management and there is no real use-case for this anyway. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
* thunderbolt: Add support for USB 3.x tunnelsRajmohan Mani2019-12-181-24/+130
| | | | | | | | | | | | | | | | | | USB4 added a capability to tunnel USB 3.x protocol over the USB4 fabric. USB4 device routers may include integrated SuperSpeed HUB or a function or both. USB tunneling follows PCIe so that the tunnel is created between the parent and the child router from USB3 downstream adapter port to USB3 upstream adapter port over a single USB4 link. This adds support for USB 3.x tunneling and also capability to discover existing USB 3.x tunnels (for example created by connection manager in boot firmware). Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Co-developed-by: Mika Westerberg <mika.westerberg@linux.intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20191217123345.31850-9-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* thunderbolt: Add support for Time Management UnitRajmohan Mani2019-12-181-0/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Time Management Unit (TMU) is included in each USB4 router. It is used to synchronize time across the USB4 fabric. By default when USB4 router is plugged to the domain, its TMU is turned off. This differs from Thunderbolt (1, 2 and 3) devices whose TMU is by default configured to bi-directional HiFi mode. Since time synchronization is needed for proper Display Port tunneling this means we need to configure the TMU on USB4 compliant devices. The USB4 spec allows some flexibility on how the TMU can be configured. This makes it possible to enable link power management states (CLx) in certain topologies, where for example DP tunneling is not used. TMU can also be re-configured dynamicaly depending on types of tunnels created over the USB4 fabric. In this patch we simply configure the TMU to be in bi-directional HiFi mode. This way we can tunnel any kind of traffic without need to perform complex steps to re-configure the domain dynamically. We can add more fine-grained TMU configuration later on when we start enabling CLx states. 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-8-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* thunderbolt: Add initial support for USB4Mika Westerberg2019-12-181-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | USB4 is the public specification based on Thunderbolt 3 protocol. There are some differences in register layouts and flows. In addition to PCIe and DP tunneling, USB4 supports tunneling of USB 3.x. USB4 is also backward compatible with Thunderbolt 3 (and older generations but the spec only talks about 3rd generation). USB4 compliant devices can be identified by checking USB4 version field in router configuration space. This patch adds initial support for USB4 compliant hosts and devices which enables following features provided by the existing functionality in the driver: - PCIe tunneling - Display Port tunneling - Host and device NVM firmware upgrade - P2P networking This brings the USB4 support to the same level that we already have for Thunderbolt 1, 2 and 3 devices. Note the spec talks about host and device "routers" but in the driver we still use term "switch" in most places. Both can be used interchangeably. Co-developed-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Rajmohan Mani <rajmohan.mani@intel.com> Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20191217123345.31850-5-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* thunderbolt: Populate PG field in hot plug acknowledgment packetMika Westerberg2019-12-181-2/+1
| | | | | | | | | | | | | | | | | | | USB4 1.0 section 6.4.2.7 specifies a new field (PG) in notification packet that is sent as response of hot plug/unplug events. This field tells whether the acknowledgment is for plug or unplug event. This needs to be set accordingly in order the router to send further hot plug notifications. To make it simpler we fill the field unconditionally. Legacy devices do not look at this field so there should be no problems with them. While there rename tb_cfg_error() to tb_cfg_ack_plug() and update the log message accordingly. The function is only used to ack plug/unplug events. Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com> Link: https://lore.kernel.org/r/20191217123345.31850-4-mika.westerberg@linux.intel.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 21:07:48 +0100