diff options
Diffstat (limited to 'Documentation')
| -rw-r--r-- | Documentation/devicetree/bindings/fb/sm501fb.txt | 34 | ||||
| -rw-r--r-- | Documentation/fb/sm501.txt | 10 | ||||
| -rw-r--r-- | Documentation/filesystems/exofs.txt | 10 | ||||
| -rw-r--r-- | Documentation/rapidio/rapidio.txt | 173 | ||||
| -rw-r--r-- | Documentation/rapidio/sysfs.txt | 90 |
5 files changed, 316 insertions, 1 deletions
diff --git a/Documentation/devicetree/bindings/fb/sm501fb.txt b/Documentation/devicetree/bindings/fb/sm501fb.txt new file mode 100644 index 000000000000..7d319fba9b5b --- /dev/null +++ b/Documentation/devicetree/bindings/fb/sm501fb.txt @@ -0,0 +1,34 @@ +* SM SM501 + +The SM SM501 is a LCD controller, with proper hardware, it can also +drive DVI monitors. + +Required properties: +- compatible : should be "smi,sm501". +- reg : contain two entries: + - First entry: System Configuration register + - Second entry: IO space (Display Controller register) +- interrupts : SMI interrupt to the cpu should be described here. +- interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + +Optional properties: +- mode : select a video mode: + <xres>x<yres>[-<bpp>][@<refresh>] +- edid : verbatim EDID data block describing attached display. + Data from the detailed timing descriptor will be used to + program the display controller. +- little-endian: availiable on big endian systems, to + set different foreign endian. +- big-endian: availiable on little endian systems, to + set different foreign endian. + +Example for MPC5200: + display@1,0 { + compatible = "smi,sm501"; + reg = <1 0x00000000 0x00800000 + 1 0x03e00000 0x00200000>; + interrupts = <1 1 3>; + mode = "640x480-32@60"; + edid = [edid-data]; + }; diff --git a/Documentation/fb/sm501.txt b/Documentation/fb/sm501.txt new file mode 100644 index 000000000000..8d17aebd2648 --- /dev/null +++ b/Documentation/fb/sm501.txt @@ -0,0 +1,10 @@ +Configuration: + +You can pass the following kernel command line options to sm501 videoframebuffer: + + sm501fb.bpp= SM501 Display driver: + Specifiy bits-per-pixel if not specified by 'mode' + + sm501fb.mode= SM501 Display driver: + Specify resolution as + "<xres>x<yres>[-<bpp>][@<refresh>]" diff --git a/Documentation/filesystems/exofs.txt b/Documentation/filesystems/exofs.txt index abd2a9b5b787..23583a136975 100644 --- a/Documentation/filesystems/exofs.txt +++ b/Documentation/filesystems/exofs.txt @@ -104,7 +104,15 @@ Where: exofs specific options: Options are separated by commas (,) pid=<integer> - The partition number to mount/create as container of the filesystem. - This option is mandatory. + This option is mandatory. integer can be + Hex by pre-pending an 0x to the number. + osdname=<id> - Mount by a device's osdname. + osdname is usually a 36 character uuid of the + form "d2683732-c906-4ee1-9dbd-c10c27bb40df". + It is one of the device's uuid specified in the + mkfs.exofs format command. + If this option is specified then the /dev/osdX + above can be empty and is ignored. to=<integer> - Timeout in ticks for a single command. default is (60 * HZ) [for debugging only] diff --git a/Documentation/rapidio/rapidio.txt b/Documentation/rapidio/rapidio.txt new file mode 100644 index 000000000000..be70ee15f8ca --- /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 Master Enable 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 000000000000..97f71ce575d6 --- /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. |