Section 1 Overview The Media Oriented Systems Transport (MOST) driver gives Linux applications access a MOST network: The Automotive Information Backbone and the de-facto standard for high-bandwidth automotive multimedia networking. MOST defines the protocol, hardware and software layers necessary to allow for the efficient and low-cost transport of control, real-time and packet data using a single medium (physical layer). Media currently in use are fiber optics, unshielded twisted pair cables (UTP) and coax cables. MOST also supports various speed grades up to 150 Mbps. For more information on MOST, visit the MOST Cooperation website: www.mostcooperation.com. Cars continue to evolve into sophisticated consumer electronics platforms, increasing the demand for reliable and simple solutions to support audio, video and data communications. MOST can be used to connect multiple consumer devices via optical or electrical physical layers directly to one another or in a network configuration. As a synchronous network, MOST provides excellent Quality of Service and seamless connectivity for audio/video streaming. Therefore, the driver perfectly fits to the mission of Automotive Grade Linux to create open source software solutions for automotive applications. The MOST driver uses module stacking to divide the associated modules into three layers. From bottom up these layers are: the adapter layer, the core layer and the application layer. The core layer implements the MOST subsystem and consists basically of the module core.c and its API. It registers the MOST bus with the kernel's device model, handles the data routing through all three layers, the configuration of the driver, the representation of the configuration interface in sysfs and the buffer management. For each of the other two layers a set of modules is provided. Those can be arbitrarily combined with the core to meet the connectivity of the desired system architecture. A module of the adapter layer is basically a device driver for a different subsystem. It is registered with the core to connect the MOST subsystem to the attached network interface controller hardware. Hence, a given module of this layer is designed to handle exactly one of the peripheral interfaces (e.g. USB, MediaLB, I2C) the hardware provides. A module of the application layer is referred to as a core component, which kind of extends the core by providing connectivity to the user space. Applications, then, can access a MOST network via character devices, an ALSA soundcard, a Network adapter or a V4L2 capture device. To physically access MOST, an Intelligent Network Interface Controller (INIC) is needed. For more information on available controllers visit: www.microchip.com Section 1.1 Adapter Layer The adapter layer contains a pool of device drivers. For each peripheral interface the hardware supports there is one suitable module that handles the interface. Adapter drivers encapsulate the peripheral interface specific knowledge of the MOST driver stack and provide an easy way of extending the number of supported interfaces. Currently the following interfaces are available: 1) MediaLB (DIM2) Host wants to communicate with hardware via MediaLB. 2) I2C Host wants to communicate with the hardware via I2C. 3) USB Host wants to communicate with the hardware via USB. Once an adapter driver recognizes a MOST device being attached, it registers it with the core, which, in turn, assigns the necessary members of the embedded struct device (e.g. the bus this device belongs to and attribute groups) and registers it with the kernel's device model. Section 1.2 Core Layer This layer implements the MOST subsystem. It contains the core module and the header file most.h that exposes the API of the core. When inserted in the kernel, it registers the MOST bus_type with the kernel's device model and registers itself as a device driver for this bus. Besides these meta tasks the core populates the configuration directory for a registered MOST device (represented by struct most_interface) in sysfs and processes the configuration of the device's interface. The core layer also handles the buffer management and the data/message routing. Section 1.3 Application Layer This layer contains a pool of device drivers that are components of the core designed to make up the userspace experience of the MOST driver stack. Depending on how an application is meant to interface the driver, one or more modules of this pool can be registered with the core. Currently the following components are available 1) Character Device Userspace can access the driver by means of character devices. 2) Networking Standard networking applications (e.g. iperf) can by used to access the driver via the networking subsystem. 3) Video4Linux (v4l2) Standard video applications (e.g. VLC) can by used to access the driver via the V4L subsystem. 4) Advanced Linux Sound Architecture (ALSA) Standard sound applications (e.g. aplay, arecord, audacity) can by used to access the driver via the ALSA subsystem. Section 2 Usage of the MOST Driver Section 2.1 Configuration and Data Link The driver is to be configured via configfs. Each loaded component kernel object (see section 1.3) registers a subsystem with configfs, which is used to configure and establish communication pathways (links) to attached devices on the bus. To do so, the user has to descend into the component's configuration directory and create a new directory (child config itmes). The name of this directory will be used as a reference for the link and it will contain the following attributes: - buffer_size configure the buffer size for this channel - subbuffer_size configure the sub-buffer size for this channel (needed for synchronous and isochrnous data) - num_buffers configure number of buffers used for this channel - datatype configure type of data that will travel over this channel - direction configure whether this link will be an input or output - dbr_size configure DBR data buffer size (this is used for MediaLB communication only) - packets_per_xact configure the number of packets that will be collected from the network before being transmitted via USB (this is used for USB communication only) - device name of the device the link is to be attached to - channel name of the channel the link is to be attached to - comp_params pass parameters needed by some components - create_link write '1' to this attribute to trigger the creation of the link. In case of speculative configuration, the creation is post-poned until a physical device is being attached to the bus. - destroy_link write '1' to this attribute to destroy an already established link See ABI/sysfs-bus-most.txt and ABI/configfs-most.txt Section 2.2 Configure a Sound Card Setting up synchronous channels to be mapped as an ALSA sound adapter is a two step process. Firstly, a directory (child config group) has to be created inside the most_sound's configuration directory. This adapter dir will represent the sound adapter. The name of the directory is for user reference only and has no further influence, as all sound adapters will be given a static name in ALSA. The sound adapter will have the following attribute: - create_card write '1' to this attribute to trigger the registration of the card with the ALSA subsystem. In case of speculative configuration, the creation is post-poned until a physical device is being attached to the bus. Secondly, links will have to be created inside the adapter dir as described in section 2.1. These links will become the PCM devices of the sound card. The name of a PCM device will be inherited from the directory name. When all channels have been configured and created, the sound card itself can be created by writing '1' to the create_card attribute. The sound component needs an additional parameter to determine the audio resolution that is going to be used. The following audio formats are available: - "1x8" (Mono) - "2x16" (16-bit stereo) - "2x24" (24-bit stereo) - "2x32" (32-bit stereo) - "6x16" (16-bit surround 5.1) The resolution string has to be written to the link directory's comp_params attribute. Section 2.3 USB Padding When transceiving synchronous or isochronous data, the number of packets per USB transaction and the sub-buffer size need to be configured. These values are needed for the driver to process buffer padding, as expected by hardware, which is for performance optimization purposes of the USB transmission. When transmitting synchronous data the allocated channel width needs to be written to 'subbuffer_size'. Additionally, the number of MOST frames that should travel to the host within one USB transaction need to be written to 'packets_per_xact'. The driver, then, calculates the synchronous threshold as follows: frame_size = subbuffer_size * packets_per_xact In case 'packets_per_xact' is set to 0xFF the maximum number of packets, allocated within one MOST frame, is calculated that fit into _one_ 512 byte USB full packet. frame_size = floor(MTU_USB / bandwidth_sync) * bandwidth_sync This frame_size is the number of synchronous data within an USB transaction, which renders MTU_USB - frame_size bytes for padding. When transmitting isochronous AVP data the desired packet size needs to be written to 'subbuffer_size' and hardware will always expect two isochronous packets within one USB transaction. This renders MTU_USB - (2 * subbuffer_size) bytes for padding. Note that at least (2 * subbuffer_size) bytes for isochronous data or (subbuffer_size * packts_per_xact) bytes for synchronous data need to be put in the transmission buffer and passed to the driver. Since adapter drivers are allowed to change a chosen configuration to best fit its constraints, it is recommended to always double check the configuration and read back the previously written files.