diff options
Diffstat (limited to 'Documentation/rapidio')
| -rw-r--r-- | Documentation/rapidio/rapidio.txt | 173 | ||||
| -rw-r--r-- | Documentation/rapidio/sysfs.txt | 90 | ||||
| -rw-r--r-- | Documentation/rapidio/tsi721.txt | 49 |
3 files changed, 312 insertions, 0 deletions
diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt new file mode 100644 index 00000000..c75694b3 --- /dev/null +++ b/Documentation/rapidio/rapidio.txt @@ -0,0 +1,173 @@ + The Linux RapidIO Subsystem + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The RapidIO standard is a packet-based fabric interconnect standard designed for +use in embedded systems. Development of the RapidIO standard is directed by the +RapidIO Trade Association (RTA). The current version of the RapidIO specification +is publicly available for download from the RTA web-site [1]. + +This document describes the basics of the Linux RapidIO subsystem and provides +information on its major components. + +1 Overview +---------- + +Because the RapidIO subsystem follows the Linux device model it is integrated +into the kernel similarly to other buses by defining RapidIO-specific device and +bus types and registering them within the device model. + +The Linux RapidIO subsystem is architecture independent and therefore defines +architecture-specific interfaces that provide support for common RapidIO +subsystem operations. + +2. Core Components +------------------ + +A typical RapidIO network is a combination of endpoints and switches. +Each of these components is represented in the subsystem by an associated data +structure. The core logical components of the RapidIO subsystem are defined +in include/linux/rio.h file. + +2.1 Master Port + +A master port (or mport) is a RapidIO interface controller that is local to the +processor executing the Linux code. A master port generates and receives RapidIO +packets (transactions). In the RapidIO subsystem each master port is represented +by a rio_mport data structure. This structure contains master port specific +resources such as mailboxes and doorbells. The rio_mport also includes a unique +host device ID that is valid when a master port is configured as an enumerating +host. + +RapidIO master ports are serviced by subsystem specific mport device drivers +that provide functionality defined for this subsystem. To provide a hardware +independent interface for RapidIO subsystem operations, rio_mport structure +includes rio_ops data structure which contains pointers to hardware specific +implementations of RapidIO functions. + +2.2 Device + +A RapidIO device is any endpoint (other than mport) or switch in the network. +All devices are presented in the RapidIO subsystem by corresponding rio_dev data +structure. Devices form one global device list and per-network device lists +(depending on number of available mports and networks). + +2.3 Switch + +A RapidIO switch is a special class of device that routes packets between its +ports towards their final destination. The packet destination port within a +switch is defined by an internal routing table. A switch is presented in the +RapidIO subsystem by rio_dev data structure expanded by additional rio_switch +data structure, which contains switch specific information such as copy of the +routing table and pointers to switch specific functions. + +The RapidIO subsystem defines the format and initialization method for subsystem +specific switch drivers that are designed to provide hardware-specific +implementation of common switch management routines. + +2.4 Network + +A RapidIO network is a combination of interconnected endpoint and switch devices. +Each RapidIO network known to the system is represented by corresponding rio_net +data structure. This structure includes lists of all devices and local master +ports that form the same network. It also contains a pointer to the default +master port that is used to communicate with devices within the network. + +3. Subsystem Initialization +--------------------------- + +In order to initialize the RapidIO subsystem, a platform must initialize and +register at least one master port within the RapidIO network. To register mport +within the subsystem controller driver initialization code calls function +rio_register_mport() for each available master port. After all active master +ports are registered with a RapidIO subsystem, the rio_init_mports() routine +is called to perform enumeration and discovery. + +In the current PowerPC-based implementation a subsys_initcall() is specified to +perform controller initialization and mport registration. At the end it directly +calls rio_init_mports() to execute RapidIO enumeration and discovery. + +4. Enumeration and Discovery +---------------------------- + +When rio_init_mports() is called it scans a list of registered master ports and +calls an enumeration or discovery routine depending on the configured role of a +master port: host or agent. + +Enumeration is performed by a master port if it is configured as a host port by +assigning a host device ID greater than or equal to zero. A host device ID is +assigned to a master port through the kernel command line parameter "riohdid=", +or can be configured in a platform-specific manner. If the host device ID for +a specific master port is set to -1, the discovery process will be performed +for it. + +The enumeration and discovery routines use RapidIO maintenance transactions +to access the configuration space of devices. + +The enumeration process is implemented according to the enumeration algorithm +outlined in the RapidIO Interconnect Specification: Annex I [1]. + +The enumeration process traverses the network using a recursive depth-first +algorithm. When a new device is found, the enumerator takes ownership of that +device by writing into the Host Device ID Lock CSR. It does this to ensure that +the enumerator has exclusive right to enumerate the device. If device ownership +is successfully acquired, the enumerator allocates a new rio_dev structure and +initializes it according to device capabilities. + +If the device is an endpoint, a unique device ID is assigned to it and its value +is written into the device's Base Device ID CSR. + +If the device is a switch, the enumerator allocates an additional rio_switch +structure to store switch specific information. Then the switch's vendor ID and +device ID are queried against a table of known RapidIO switches. Each switch +table entry contains a pointer to a switch-specific initialization routine that +initializes pointers to the rest of switch specific operations, and performs +hardware initialization if necessary. A RapidIO switch does not have a unique +device ID; it relies on hopcount and routing for device ID of an attached +endpoint if access to its configuration registers is required. If a switch (or +chain of switches) does not have any endpoint (except enumerator) attached to +it, a fake device ID will be assigned to configure a route to that switch. +In the case of a chain of switches without endpoint, one fake device ID is used +to configure a route through the entire chain and switches are differentiated by +their hopcount value. + +For both endpoints and switches the enumerator writes a unique component tag +into device's Component Tag CSR. That unique value is used by the error +management notification mechanism to identify a device that is reporting an +error management event. + +Enumeration beyond a switch is completed by iterating over each active egress +port of that switch. For each active link, a route to a default device ID +(0xFF for 8-bit systems and 0xFFFF for 16-bit systems) is temporarily written +into the routing table. The algorithm recurs by calling itself with hopcount + 1 +and the default device ID in order to access the device on the active port. + +After the host has completed enumeration of the entire network it releases +devices by clearing device ID locks (calls rio_clear_locks()). For each endpoint +in the system, it sets the Discovered bit in the Port General Control CSR +to indicate that enumeration is completed and agents are allowed to execute +passive discovery of the network. + +The discovery process is performed by agents and is similar to the enumeration +process that is described above. However, the discovery process is performed +without changes to the existing routing because agents only gather information +about RapidIO network structure and are building an internal map of discovered +devices. This way each Linux-based component of the RapidIO subsystem has +a complete view of the network. The discovery process can be performed +simultaneously by several agents. After initializing its RapidIO master port +each agent waits for enumeration completion by the host for the configured wait +time period. If this wait time period expires before enumeration is completed, +an agent skips RapidIO discovery and continues with remaining kernel +initialization. + +5. References +------------- + +[1] RapidIO Trade Association. RapidIO Interconnect Specifications. + http://www.rapidio.org. +[2] Rapidio TA. Technology Comparisons. + http://www.rapidio.org/education/technology_comparisons/ +[3] RapidIO support for Linux. + http://lwn.net/Articles/139118/ +[4] Matt Porter. RapidIO for Linux. Ottawa Linux Symposium, 2005 + http://www.kernel.org/doc/ols/2005/ols2005v2-pages-43-56.pdf diff --git a/Documentation/rapidio/sysfs.txt b/Documentation/rapidio/sysfs.txt new file mode 100644 index 00000000..97f71ce5 --- /dev/null +++ b/Documentation/rapidio/sysfs.txt @@ -0,0 +1,90 @@ + RapidIO sysfs Files + +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +1. Device Subdirectories +------------------------ + +For each RapidIO device, the RapidIO subsystem creates files in an individual +subdirectory with the following name, /sys/bus/rapidio/devices/<device_name>. + +The format of device_name is "nn:d:iiii", where: + +nn - two-digit hexadecimal ID of RapidIO network where the device resides +d - device typr: 'e' - for endpoint or 's' - for switch +iiii - four-digit device destID for endpoints, or switchID for switches + +For example, below is a list of device directories that represents a typical +RapidIO network with one switch, one host, and two agent endpoints, as it is +seen by the enumerating host (destID = 1): + +/sys/bus/rapidio/devices/00:e:0000 +/sys/bus/rapidio/devices/00:e:0002 +/sys/bus/rapidio/devices/00:s:0001 + +NOTE: An enumerating or discovering endpoint does not create a sysfs entry for +itself, this is why an endpoint with destID=1 is not shown in the list. + +2. Attributes Common for All Devices +------------------------------------ + +Each device subdirectory contains the following informational read-only files: + + did - returns the device identifier + vid - returns the device vendor identifier +device_rev - returns the device revision level + asm_did - returns identifier for the assembly containing the device + asm_rev - returns revision level of the assembly containing the device + asm_vid - returns vendor identifier of the assembly containing the device + destid - returns device destination ID assigned by the enumeration routine + (see 4.1 for switch specific details) + lprev - returns name of previous device (switch) on the path to the device + that that owns this attribute + +In addition to the files listed above, each device has a binary attribute file +that allows read/write access to the device configuration registers using +the RapidIO maintenance transactions: + + config - reads from and writes to the device configuration registers. + +This attribute is similar in behavior to the "config" attribute of PCI devices +and provides an access to the RapidIO device registers using standard file read +and write operations. + +3. Endpoint Device Attributes +----------------------------- + +Currently Linux RapidIO subsystem does not create any endpoint specific sysfs +attributes. It is possible that RapidIO master port drivers and endpoint device +drivers will add their device-specific sysfs attributes but such attributes are +outside the scope of this document. + +4. Switch Device Attributes +--------------------------- + +RapidIO switches have additional attributes in sysfs. RapidIO subsystem supports +common and device-specific sysfs attributes for switches. Because switches are +integrated into the RapidIO subsystem, it offers a method to create +device-specific sysfs attributes by specifying a callback function that may be +set by the switch initialization routine during enumeration or discovery process. + +4.1 Common Switch Attributes + + routes - reports switch routing information in "destID port" format. This + attribute reports only valid routing table entries, one line for + each entry. + destid - device destination ID that defines a route to the switch + hopcount - number of hops on the path to the switch + lnext - returns names of devices linked to the switch except one of a device + linked to the ingress port (reported as "lprev"). This is an array + names with number of lines equal to number of ports in switch. If + a switch port has no attached device, returns "null" instead of + a device name. + +4.2 Device-specific Switch Attributes + +Device-specific switch attributes are listed for each RapidIO switch driver +that exports additional attributes. + +IDT_GEN2: + errlog - reads contents of device error log until it is empty. diff --git a/Documentation/rapidio/tsi721.txt b/Documentation/rapidio/tsi721.txt new file mode 100644 index 00000000..335f3c60 --- /dev/null +++ b/Documentation/rapidio/tsi721.txt @@ -0,0 +1,49 @@ +RapidIO subsystem mport driver for IDT Tsi721 PCI Express-to-SRIO bridge. +========================================================================= + +I. Overview + +This driver implements all currently defined RapidIO mport callback functions. +It supports maintenance read and write operations, inbound and outbound RapidIO +doorbells, inbound maintenance port-writes and RapidIO messaging. + +To generate SRIO maintenance transactions this driver uses one of Tsi721 DMA +channels. This mechanism provides access to larger range of hop counts and +destination IDs without need for changes in outbound window translation. + +RapidIO messaging support uses dedicated messaging channels for each mailbox. +For inbound messages this driver uses destination ID matching to forward messages +into the corresponding message queue. Messaging callbacks are implemented to be +fully compatible with RIONET driver (Ethernet over RapidIO messaging services). + +II. Known problems + + None. + +III. To do + + Add DMA data transfers (non-messaging). + Add inbound region (SRIO-to-PCIe) mapping. + +IV. Version History + + 1.0.0 - Initial driver release. + +V. License +----------------------------------------------- + + Copyright(c) 2011 Integrated Device Technology, Inc. All rights reserved. + + This program is free software; you can redistribute it and/or modify it + under the terms of the GNU General Public License as published by the Free + Software Foundation; either version 2 of the License, or (at your option) + any later version. + + This program is distributed in the hope that it will be useful, but WITHOUT + ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or + FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for + more details. + + You should have received a copy of the GNU General Public License along with + this program; if not, write to the Free Software Foundation, Inc., + 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. |