06 Jul, 2017

8 commits

  • Signed-off-by: Serge Semin
    Acked-by: Allen Hubbe
    Signed-off-by: Jon Mason

    Serge Semin
     
  • Signed-off-by: Serge Semin
    Acked-by: Allen Hubbe
    Signed-off-by: Jon Mason

    Serge Semin
     
  • Some IDT NTB-capable PCIe-switches have message registers to communicate with
    peer devices. This patch adds new NTB API callback methods, which can be used
    to utilize these registers functionality:
    ntb_msg_count(); - get number of message registers
    ntb_msg_inbits(); - get bitfield of inbound message registers status
    ntb_msg_outbits(); - get bitfield of outbound message registers status
    ntb_msg_read_sts(); - read the inbound and outbound message registers status
    ntb_msg_clear_sts(); - clear status bits of message registers
    ntb_msg_set_mask(); - mask interrupts raised by status bits of message
    registers.
    ntb_msg_clear_mask(); - clear interrupts mask bits of message registers
    ntb_msg_read(midx, *pidx); - read message register with specified index,
    additionally getting peer port index which data received from
    ntb_msg_write(midx, pidx); - write data to the specified message register
    sending it to the passed peer device connected over a pidx port
    ntb_msg_event(); - notify driver context of a new message event

    Of course there is hardware which doesn't support Message registers, so
    this API is made optional.

    Signed-off-by: Serge Semin
    Acked-by: Allen Hubbe
    Signed-off-by: Jon Mason

    Serge Semin
     
  • Even though there is no any real NTB hardware, which would have both more
    than two ports and Scratchpad registers, it is logically correct to have
    Scratchpad API accepting a peer port index as well. Intel/AMD drivers utilize
    Primary and Secondary topology to split Scratchpad between connected root
    devices. Since port-index API introduced, Intel/AMD NTB hardware drivers can
    use device port to determine which Scratchpad registers actually belong to
    local and peer devices. The same approach can be used if some potential
    hardware in future will be multi-port and have some set of Scratchpads.
    Here are the brief of changes in the API:
    ntb_spad_count() - return number of Scratchpads per each port
    ntb_peer_spad_addr(pidx, sidx) - address of Scratchpad register of the
    peer device with pidx-index
    ntb_peer_spad_read(pidx, sidx) - read specified Scratchpad register of the
    peer with pidx-index
    ntb_peer_spad_write(pidx, sidx) - write data to Scratchpad register of the
    peer with pidx-index

    Since there is hardware which doesn't support Scratchpad registers, the
    corresponding API methods are now made optional.

    Signed-off-by: Serge Semin
    Acked-by: Allen Hubbe
    Signed-off-by: Jon Mason

    Serge Semin
     
  • Multi-port NTB devices permit to share a memory between all accessible peers.
    Memory Windows API is altered to correspondingly initialize and map memory
    windows for such devices:
    ntb_mw_count(pidx); - number of inbound memory windows, which can be allocated
    for shared buffer with specified peer device.
    ntb_mw_get_align(pidx, widx); - get alignment and size restriction parameters
    to properly allocate inbound memory region.
    ntb_peer_mw_count(); - get number of outbound memory windows.
    ntb_peer_mw_get_addr(widx); - get mapping address of an outbound memory window

    If hardware supports inbound translation configured on the local ntb port:
    ntb_mw_set_trans(pidx, widx); - set translation address of allocated inbound
    memory window so a peer device could access it.
    ntb_mw_clear_trans(pidx, widx); - clear the translation address of an inbound
    memory window.

    If hardware supports outbound translation configured on the peer ntb port:
    ntb_peer_mw_set_trans(pidx, widx); - set translation address of a memory
    window retrieved from a peer device
    ntb_peer_mw_clear_trans(pidx, widx); - clear the translation address of an
    outbound memory window

    Signed-off-by: Serge Semin
    Acked-by: Allen Hubbe
    Signed-off-by: Jon Mason

    Serge Semin
     
  • Multi-port devices permit the NTB connections between multiple domains,
    so a local device can have NTB link being up with one peer and being
    down with another. NTB link-state API is appropriately altered to return
    a bitfield of the link-states between the local device and possible peers.

    Signed-off-by: Serge Semin
    Acked-by: Allen Hubbe
    Signed-off-by: Jon Mason

    Serge Semin
     
  • There is some NTB hardware, which can combine more than just two domains
    over NTB. For instance, some IDT PCIe-switches can have NTB-functions
    activated on more than two-ports. The different domains are distinguished
    by ports they are connected to. So the new port-related methods are added to
    the NTB API:
    ntb_port_number() - return local port
    ntb_peer_port_count() - return number of peers local port can connect to
    ntb_peer_port_number(pdix) - return port number by it index
    ntb_peer_port_idx(port) - return port index by it number

    Current test-drivers aren't changed much. They still support two-ports devices
    for the time being while multi-ports hardware drivers aren't added.

    By default port-related API is declared for two-ports hardware.
    So corresponding hardware drivers won't need to implement it.

    Signed-off-by: Serge Semin
    Signed-off-by: Jon Mason

    Serge Semin
     
  • Since link operations are usually performed before memory window access
    operations, it's logically better to declare link-related API before any
    of MW/Doorbell/Scratchpad methods.

    Signed-off-by: Serge Semin
    Signed-off-by: Jon Mason

    Serge Semin
     

25 Dec, 2016

1 commit

  • Pull NTB update from Jon Mason:

    - NTB bug fixes for removing an unnecessary call to ntb_peer_spad_read,
    and correcting a free_irq inconsistency

    - add Intel SKX support

    - change the AMD NTB maintainer, and fix some bugs present there

    * tag 'ntb-4.10' of git://github.com/jonmason/ntb:
    ntb_transport: Remove unnecessary call to ntb_peer_spad_read
    NTB: Fix 'request_irq()' and 'free_irq()' inconsistancy
    ntb: fix SKX NTB config space size register offsets
    NTB: correct ntb_peer_spad_read for case when callback is not supplied.
    MAINTAINERS: Change in maintainer for AMD NTB
    ntb_transport: Limit memory windows based on available, scratchpads
    NTB: Register and offset values fix for memory window
    NTB: add support for hotplug feature
    ntb: Adding Skylake Xeon NTB support

    Linus Torvalds
     

24 Dec, 2016

1 commit


14 Dec, 2016

1 commit


22 Mar, 2016

1 commit

  • The functions ntb_peer_db_addr and ntb_peer_spad_addr were required by
    the api. The functions already support returning an error, so any
    existing calling code should already check for it. Any existing code
    using drivers that implement the functions will not be affected.

    Signed-off-by: Allen Hubbe
    Signed-off-by: Jon Mason

    Allen Hubbe
     

08 Sep, 2015

2 commits


05 Jul, 2015

1 commit


02 Jul, 2015

1 commit

  • This patch only moves files to their new locations, before applying the
    next two patches adding the NTB Abstraction layer. Splitting this patch
    from the next is intended make distinct which code is changed only due
    to moving the files, versus which are substantial code changes in adding
    the NTB Abstraction layer.

    Signed-off-by: Allen Hubbe
    Signed-off-by: Jon Mason

    Allen Hubbe
     

08 Apr, 2014

2 commits


18 Jan, 2013

1 commit

  • A PCI-Express non-transparent bridge (NTB) is a point-to-point PCIe bus
    connecting 2 systems, providing electrical isolation between the two subsystems.
    A non-transparent bridge is functionally similar to a transparent bridge except
    that both sides of the bridge have their own independent address domains. The
    host on one side of the bridge will not have the visibility of the complete
    memory or I/O space on the other side of the bridge. To communicate across the
    non-transparent bridge, each NTB endpoint has one (or more) apertures exposed to
    the local system. Writes to these apertures are mirrored to memory on the
    remote system. Communications can also occur through the use of doorbell
    registers that initiate interrupts to the alternate domain, and scratch-pad
    registers accessible from both sides.

    The NTB device driver is needed to configure these memory windows, doorbell, and
    scratch-pad registers as well as use them in such a way as they can be turned
    into a viable communication channel to the remote system. ntb_hw.[ch]
    determines the usage model (NTB to NTB or NTB to Root Port) and abstracts away
    the underlying hardware to provide access and a common interface to the doorbell
    registers, scratch pads, and memory windows. These hardware interfaces are
    exported so that other, non-mainlined kernel drivers can access these.
    ntb_transport.[ch] also uses the exported interfaces in ntb_hw.[ch] to setup a
    communication channel(s) and provide a reliable way of transferring data from
    one side to the other, which it then exports so that "client" drivers can access
    them. These client drivers are used to provide a standard kernel interface
    (i.e., Ethernet device) to NTB, such that Linux can transfer data from one
    system to the other in a standard way.

    Signed-off-by: Jon Mason
    Reviewed-by: Nicholas Bellinger
    Signed-off-by: Greg Kroah-Hartman

    Jon Mason