summaryrefslogtreecommitdiffstats
path: root/Documentation/rapidio
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/rapidio')
-rw-r--r--Documentation/rapidio/rapidio.txt173
-rw-r--r--Documentation/rapidio/sysfs.txt90
-rw-r--r--Documentation/rapidio/tsi721.txt49
3 files changed, 0 insertions, 312 deletions
diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt
deleted file mode 100644
index c75694b35d0..00000000000
--- a/Documentation/rapidio/rapidio.txt
+++ /dev/null
@@ -1,173 +0,0 @@
- 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
deleted file mode 100644
index 97f71ce575d..00000000000
--- a/Documentation/rapidio/sysfs.txt
+++ /dev/null
@@ -1,90 +0,0 @@
- 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
deleted file mode 100644
index 335f3c6087d..00000000000
--- a/Documentation/rapidio/tsi721.txt
+++ /dev/null
@@ -1,49 +0,0 @@
-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.