06 Nov, 2020

1 commit


30 Sep, 2020

1 commit

  • …el/git/westeri/thunderbolt into usb-next

    Mika writes:

    thunderbolt: Changes for v5.10 merge window

    This includes following Thunderbolt/USB4 changes for v5.10 merge window:

    * A couple of optimizations around Tiger Lake force power logic and
    NHI (Native Host Interface) LC (Link Controller) mailbox command
    processing

    * Power management improvements for Software Connection Manager

    * Debugfs support

    * Allow KUnit tests to be enabled also when Thunderbolt driver is
    configured as module.

    * Few minor cleanups and fixes

    All these have been in linux-next with no reported issues.

    * tag 'thunderbolt-for-v5.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/westeri/thunderbolt: (37 commits)
    thunderbolt: Capitalize comment on top of QUIRK_FORCE_POWER_LINK_CONTROLLER
    thunderbolt: Correct tb_check_quirks() kernel-doc
    thunderbolt: Log correct zeroX entries in decode_error()
    thunderbolt: Handle ERR_LOCK notification
    thunderbolt: Use "if USB4" instead of "depends on" in Kconfig
    thunderbolt: Allow KUnit tests to be built also when CONFIG_USB4=m
    thunderbolt: Only stop control channel when entering freeze
    thunderbolt: debugfs: Fix uninitialized return in counters_write()
    thunderbolt: Add debugfs interface
    thunderbolt: No need to warn in TB_CFG_ERROR_INVALID_CONFIG_SPACE
    thunderbolt: Introduce tb_switch_is_tiger_lake()
    thunderbolt: Introduce tb_switch_is_ice_lake()
    thunderbolt: Check for Intel vendor ID when identifying controller
    thunderbolt: Introduce tb_port_is_nhi()
    thunderbolt: Introduce tb_switch_next_cap()
    thunderbolt: Introduce tb_port_next_cap()
    thunderbolt: Move struct tb_cap_any to tb_regs.h
    thunderbolt: Add runtime PM for Software CM
    thunderbolt: Create device links from ACPI description
    ACPI: Export acpi_get_first_physical_node() to modules
    ...

    Greg Kroah-Hartman
     

16 Sep, 2020

3 commits


03 Sep, 2020

15 commits

  • This adds debugfs interface that can be used for debugging possible
    issues in hardware/software. It exposes router and adapter config spaces
    through files like this:

    /sys/kernel/debug/thunderbolt//regs
    /sys/kernel/debug/thunderbolt///regs
    /sys/kernel/debug/thunderbolt///path
    /sys/kernel/debug/thunderbolt///counters
    /sys/kernel/debug/thunderbolt///regs
    /sys/kernel/debug/thunderbolt///path
    /sys/kernel/debug/thunderbolt///counters
    ...

    The "regs" is either the router or port configuration space register
    dump. The "path" is the port path configuration space and "counters" is
    the optional counters configuration space.

    These files contains one register per line so it should be easy to use
    normal filtering tools to find the registers of interest if needed.

    The router and adapter regs file becomes writable when
    CONFIG_USB4_DEBUGFS_WRITE is enabled (which is not supposed to be done
    in production systems) and in this case the developer can write "offset
    value" lines there to modify the hardware directly. For convenience this
    also supports the long format the read side produces (but ignores the
    additional fields). The counters file can be written even when
    CONFIG_USB4_DEBUGFS_WRITE is not enabled and it is only used to clear
    the counter values.

    Signed-off-by: Gil Fine
    Signed-off-by: Mika Westerberg
    Reviewed-by: Greg Kroah-Hartman

    Gil Fine
     
  • This is needed to differentiate Tiger Lake from other controllers.

    Signed-off-by: Gil Fine
    Signed-off-by: Mika Westerberg
    Reviewed-by: Greg Kroah-Hartman

    Gil Fine
     
  • This is needed to differentiate Ice Lake from other controllers.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Greg Kroah-Hartman

    Mika Westerberg
     
  • With USB4 there will be other vendors so make sure the current checks
    for different Intel controllers will not accidentally match those.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Greg Kroah-Hartman

    Mika Westerberg
     
  • This is useful if one needs to check if adapter (port) is the host
    interface (NHI). Make tb_port_alloc_hopid() take advantage of this.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Greg Kroah-Hartman

    Mika Westerberg
     
  • This is similar to tb_port_next_cap() but instead allows walking
    capability list of a switch (router). Convert tb_switch_find_cap() and
    tb_switch_find_vse_cap() to use this as well.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Greg Kroah-Hartman

    Mika Westerberg
     
  • This function is useful for walking port config space (adapter)
    capability lists. Convert the tb_port_find_cap() to use this as well.

    Signed-off-by: Mika Westerberg
    Reviewed-by: Greg Kroah-Hartman

    Mika Westerberg
     
  • 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
     
  • The new way to describe relationship between tunneled ports and USB4 NHI
    (Native Host Interface) is with ACPI _DSD looking like below for a PCIe
    downstream port:

    Scope (\_SB.PCI0)
    {
    Device (NHI0) { } // Thunderbolt NHI

    Device (DSB0) // Hotplug downstream port
    {
    Name (_DSD, Package () {
    ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
    Package () {
    Package () {"usb4-host-interface", \_SB.PCI0.NHI0},
    ...
    }
    })
    }
    }

    This is "documented" in these [1] USB-IF slides and being used on
    systems that ship with Windows.

    The _DSD can be added to tunneled USB3 and PCIe ports, and is needed to
    make sure the USB4 NHI is resumed before any of the tunneled ports so
    the protocol tunnels get established properly before the actual port
    itself is resumed. Othwerwise the USB/PCI core find the link may not be
    established and starts tearing down the device stack.

    This parses the ACPI description each time NHI is probed and tries to
    find devices that has the property and it references the NHI in
    question. For each matching device a device link from that device to the
    NHI is created.

    Since USB3 ports themselves do not get runtime suspended with the parent
    device (hub) we do not add the link from the USB3 port to USB4 NHI but
    instead we add the link from the xHCI device. This makes the device link
    usable for runtime PM as well.

    [1] https://www.usb.org/sites/default/files/D1T2-2%20-%20USB4%20on%20Windows.pdf

    Signed-off-by: Mika Westerberg
    Acked-by: Rafael J. Wysocki

    Mika Westerberg
     
  • 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
     
  • 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
     
  • 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
     
  • 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
     
  • 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
     
  • 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
     

25 Aug, 2020

1 commit

  • Commit 4caf2511ec49 ("thunderbolt: Add trivial .shutdown") exposes a bug
    in the Thunderbolt driver, that frees an unallocated id, resulting in the
    following spinlock bad magic bug.

    [ 20.633803] BUG: spinlock bad magic on CPU#4, halt/3313
    [ 20.640030] lock: 0xffff92e6ad5c97e0, .magic: 00000000, .owner: /-1, .owner_cpu: 0
    [ 20.672139] Call Trace:
    [ 20.675032] dump_stack+0x97/0xdb
    [ 20.678950] ? spin_bug+0xa5/0xb0
    [ 20.682865] do_raw_spin_lock+0x68/0x98
    [ 20.687397] _raw_spin_lock_irqsave+0x3f/0x5d
    [ 20.692535] ida_destroy+0x4f/0x124
    [ 20.696657] tb_switch_release+0x6d/0xfd
    [ 20.701295] device_release+0x2c/0x7d
    [ 20.705622] kobject_put+0x8e/0xac
    [ 20.709637] tb_stop+0x55/0x66
    [ 20.713243] tb_domain_remove+0x36/0x62
    [ 20.717774] nhi_remove+0x4d/0x58

    Fix the issue by disabling ports that are enabled as per the EEPROM, but
    not implemented. While at it, update the kernel doc for the disabled
    field, to reflect this.

    Cc: stable@vger.kernel.org
    Fixes: 4caf2511ec49 ("thunderbolt: Add trivial .shutdown")
    Reported-by: Srikanth Nandamuri
    Signed-off-by: Nikunj A. Dadhania
    Signed-off-by: Mika Westerberg

    Nikunj A. Dadhania
     

01 Jul, 2020

2 commits


23 Jun, 2020

9 commits

  • 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 :.
    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
    Co-developed-by: Mika Westerberg
    Signed-off-by: Mika Westerberg

    Kranthi Kuntala
     
  • 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
    Co-developed-by: Mika Westerberg
    Signed-off-by: Mika Westerberg

    Rajmohan Mani
     
  • We are going to reuse some of this functionality to implement retimer
    NVM upgrade so move common NVM functionality into its own file. We also
    rename the structure from tb_switch_nvm to tb_nvm to make it clear that
    it is not just for switches.

    Signed-off-by: Mika Westerberg

    Mika Westerberg
     
  • 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
     
  • We need to call this from tb.c when we improve the bandwidth management
    to take USB3 into account.

    Signed-off-by: Mika Westerberg

    Mika Westerberg
     
  • 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
     
  • 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
     
  • Currently we have only supported paths that follow daisy-chain topology
    but USB4 also allows to build trees of devices. For this reason increase
    maximum path length we use for discovery to be from the lowest level to
    the host router and back to the same level.

    Signed-off-by: Mika Westerberg

    Mika Westerberg
     
  • With USB4, topologies are not limited to daisy-chains anymore so when
    calculating how many hops are between two ports we need to walk the
    whole path instead.

    Add helper function tb_for_each_port_on_path() that can be used to walk
    over each port on a path and make tb_path_alloc() to use it.

    Signed-off-by: Mika Westerberg

    Mika Westerberg
     

18 Dec, 2019

5 commits

  • 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
    Co-developed-by: Mika Westerberg
    Signed-off-by: Mika Westerberg
    Link: https://lore.kernel.org/r/20191217123345.31850-9-mika.westerberg@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman

    Rajmohan Mani
     
  • 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
    Co-developed-by: Mika Westerberg
    Signed-off-by: Mika Westerberg
    Link: https://lore.kernel.org/r/20191217123345.31850-8-mika.westerberg@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman

    Rajmohan Mani
     
  • We need to find switch capabilities in order to implement TMU support so
    make it available to other files as well.

    Signed-off-by: Rajmohan Mani
    Signed-off-by: Mika Westerberg
    Link: https://lore.kernel.org/r/20191217123345.31850-7-mika.westerberg@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman

    Rajmohan Mani
     
  • 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
    Signed-off-by: Rajmohan Mani
    Signed-off-by: Mika Westerberg
    Link: https://lore.kernel.org/r/20191217123345.31850-5-mika.westerberg@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman

    Mika Westerberg
     
  • We will be needing this when adding initial USB4 support so make it
    available to other files in the driver as well. We also rename it to
    tb_switch_find_port() to follow conventions used in switch.c.

    No functional changes.

    Signed-off-by: Mika Westerberg
    Link: https://lore.kernel.org/r/20191217123345.31850-2-mika.westerberg@linux.intel.com
    Signed-off-by: Greg Kroah-Hartman

    Mika Westerberg
     

02 Nov, 2019

3 commits

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

    Signed-off-by: Mika Westerberg

    Mika Westerberg
     
  • To perform proper Display Port tunneling for Thunderbolt 3 devices we
    need to allocate DP resources for DP IN port before they can be used.
    The reason for this is that the user can also connect a monitor directly
    to the Type-C ports in which case the Thunderbolt controller acts as
    re-driver for Display Port (no tunneling takes place) taking the DP
    sinks away from the connection manager. This allocation is done using
    special sink allocation registers available through the link controller.

    We can pair DP IN to DP OUT only if

    * DP IN has sink allocated via link controller
    * DP OUT port receives hotplug event

    For DP IN adapters (only for the host router) we first query whether
    there is DP resource available (it may be the previous instance of the
    driver for example already allocated it) and if it is we add it to the
    list. We then update the list when after each plug/unplug event to a DP
    IN/OUT adapter. Each time the list is updated we try to find additional
    DP IN DP OUT pairs for tunnel establishment. This strategy also
    makes it possible to establish another tunnel in case there are 3
    monitors connected and one gets unplugged releasing the DP IN adapter
    for the new tunnel.

    Signed-off-by: Mika Westerberg

    Mika Westerberg
     
  • In order to keep PCIe hierarchies consistent across hotplugs, add
    hard-coded PCIe downstream port to Thunderbolt port for Alpine Ridge and
    Titan Ridge as well.

    Signed-off-by: Mika Westerberg

    Mika Westerberg