1 2 Section 1 Overview 3 4The Media Oriented Systems Transport (MOST) driver gives Linux applications 5access a MOST network: The Automotive Information Backbone and the de-facto 6standard for high-bandwidth automotive multimedia networking. 7 8MOST defines the protocol, hardware and software layers necessary to allow 9for the efficient and low-cost transport of control, real-time and packet 10data using a single medium (physical layer). Media currently in use are 11fiber optics, unshielded twisted pair cables (UTP) and coax cables. MOST 12also supports various speed grades up to 150 Mbps. 13For more information on MOST, visit the MOST Cooperation website: 14www.mostcooperation.com. 15 16Cars continue to evolve into sophisticated consumer electronics platforms, 17increasing the demand for reliable and simple solutions to support audio, 18video and data communications. MOST can be used to connect multiple 19consumer devices via optical or electrical physical layers directly to one 20another or in a network configuration. As a synchronous network, MOST 21provides excellent Quality of Service and seamless connectivity for 22audio/video streaming. Therefore, the driver perfectly fits to the mission 23of Automotive Grade Linux to create open source software solutions for 24automotive applications. 25 26The MOST driver uses module stacking to divide the associated modules into 27three layers. From bottom up these layers are: the adapter layer, the core 28layer and the application layer. The core layer implements the MOST 29subsystem and consists basically of the module core.c and its API. It 30registers the MOST bus with the kernel's device model, handles the data 31routing through all three layers, the configuration of the driver, the 32representation of the configuration interface in sysfs and the buffer 33management. 34 35For each of the other two layers a set of modules is provided. Those can be 36arbitrarily combined with the core to meet the connectivity of the desired 37system architecture. 38 39A module of the adapter layer is basically a device driver for a different 40subsystem. It is registered with the core to connect the MOST subsystem to 41the attached network interface controller hardware. Hence, a given module 42of this layer is designed to handle exactly one of the peripheral 43interfaces (e.g. USB, MediaLB, I2C) the hardware provides. 44 45A module of the application layer is referred to as a core component, 46which kind of extends the core by providing connectivity to the user space. 47Applications, then, can access a MOST network via character devices, an 48ALSA soundcard, a Network adapter or a V4L2 capture device. 49 50To physically access MOST, an Intelligent Network Interface Controller 51(INIC) is needed. For more information on available controllers visit: 52www.microchip.com 53 54 55 56 Section 1.1 Adapter Layer 57 58The adapter layer contains a pool of device drivers. For each peripheral 59interface the hardware supports there is one suitable module that handles 60the interface. Adapter drivers encapsulate the peripheral interface 61specific knowledge of the MOST driver stack and provide an easy way of 62extending the number of supported interfaces. Currently the following 63interfaces are available: 64 65 1) MediaLB (DIM2) 66 Host wants to communicate with hardware via MediaLB. 67 68 2) I2C 69 Host wants to communicate with the hardware via I2C. 70 71 3) USB 72 Host wants to communicate with the hardware via USB. 73 74Once an adapter driver recognizes a MOST device being attached, it 75registers it with the core, which, in turn, assigns the necessary members 76of the embedded struct device (e.g. the bus this device belongs to and 77attribute groups) and registers it with the kernel's device model. 78 79 80 Section 1.2 Core Layer 81 82This layer implements the MOST subsystem. It contains the core module and 83the header file most.h that exposes the API of the core. When inserted in 84the kernel, it registers the MOST bus_type with the kernel's device model 85and registers itself as a device driver for this bus. Besides these meta 86tasks the core populates the configuration directory for a registered MOST 87device (represented by struct most_interface) in sysfs and processes the 88configuration of the device's interface. The core layer also handles the 89buffer management and the data/message routing. 90 91 92 Section 1.3 Application Layer 93 94This layer contains a pool of device drivers that are components of the 95core designed to make up the userspace experience of the MOST driver stack. 96Depending on how an application is meant to interface the driver, one or 97more modules of this pool can be registered with the core. Currently the 98following components are available 99 100 1) Character Device 101 Userspace can access the driver by means of character devices. 102 103 2) Networking 104 Standard networking applications (e.g. iperf) can by used to access 105 the driver via the networking subsystem. 106 107 3) Video4Linux (v4l2) 108 Standard video applications (e.g. VLC) can by used to access the 109 driver via the V4L subsystem. 110 111 4) Advanced Linux Sound Architecture (ALSA) 112 Standard sound applications (e.g. aplay, arecord, audacity) can by 113 used to access the driver via the ALSA subsystem. 114 115 116 Section 2 Usage of the MOST Driver 117 118 Section 2.1 Configuration and Data Link 119 120The driver is to be configured via configfs. Each loaded component kernel 121object (see section 1.3) registers a subsystem with configfs, which is used to 122configure and establish communication pathways (links) to attached devices on 123the bus. To do so, the user has to descend into the component's configuration 124directory and create a new directory (child config itmes). The name of this 125directory will be used as a reference for the link and it will contain the 126following attributes: 127 128 - buffer_size 129 configure the buffer size for this channel 130 - subbuffer_size 131 configure the sub-buffer size for this channel (needed for 132 synchronous and isochrnous data) 133 - num_buffers 134 configure number of buffers used for this channel 135 - datatype 136 configure type of data that will travel over this channel 137 - direction 138 configure whether this link will be an input or output 139 - dbr_size 140 configure DBR data buffer size (this is used for MediaLB communication 141 only) 142 - packets_per_xact 143 configure the number of packets that will be collected from the 144 network before being transmitted via USB (this is used for USB 145 communication only) 146 - device 147 name of the device the link is to be attached to 148 - channel 149 name of the channel the link is to be attached to 150 - comp_params 151 pass parameters needed by some components 152 - create_link 153 write '1' to this attribute to trigger the creation of the link. In 154 case of speculative configuration, the creation is post-poned until 155 a physical device is being attached to the bus. 156 - destroy_link 157 write '1' to this attribute to destroy an already established link 158 159 160See ABI/sysfs-bus-most.txt and ABI/configfs-most.txt 161 162 163 Section 2.2 Configure a Sound Card 164 165Setting up synchronous channels to be mapped as an ALSA sound adapter is a two 166step process. Firstly, a directory (child config group) has to be created 167inside the most_sound's configuration directory. This adapter dir will 168represent the sound adapter. The name of the directory is for user reference 169only and has no further influence, as all sound adapters will be given a static 170name in ALSA. The sound adapter will have the following attribute: 171 172 - create_card 173 write '1' to this attribute to trigger the registration of the card 174 with the ALSA subsystem. 175 In case of speculative configuration, the creation is post-poned 176 until a physical device is being attached to the bus. 177 178Secondly, links will have to be created inside the adapter dir as described in 179section 2.1. These links will become the PCM devices of the sound card. The 180name of a PCM device will be inherited from the directory name. When all 181channels have been configured and created, the sound card itself can be created 182by writing '1' to the create_card attribute. 183 184The sound component needs an additional parameter to determine the audio 185resolution that is going to be used. 186The following audio formats are available: 187 188 - "1x8" (Mono) 189 - "2x16" (16-bit stereo) 190 - "2x24" (24-bit stereo) 191 - "2x32" (32-bit stereo) 192 - "6x16" (16-bit surround 5.1) 193 194The resolution string has to be written to the link directory's comp_params 195attribute. 196 197 Section 2.3 USB Padding 198 199When transceiving synchronous or isochronous data, the number of packets 200per USB transaction and the sub-buffer size need to be configured. These 201values are needed for the driver to process buffer padding, as expected by 202hardware, which is for performance optimization purposes of the USB 203transmission. 204 205When transmitting synchronous data the allocated channel width needs to be 206written to 'subbuffer_size'. Additionally, the number of MOST frames that 207should travel to the host within one USB transaction need to be written to 208'packets_per_xact'. 209 210The driver, then, calculates the synchronous threshold as follows: 211 212 frame_size = subbuffer_size * packets_per_xact 213 214In case 'packets_per_xact' is set to 0xFF the maximum number of packets, 215allocated within one MOST frame, is calculated that fit into _one_ 512 byte 216USB full packet. 217 218 frame_size = floor(MTU_USB / bandwidth_sync) * bandwidth_sync 219 220This frame_size is the number of synchronous data within an USB 221transaction, which renders MTU_USB - frame_size bytes for padding. 222 223When transmitting isochronous AVP data the desired packet size needs to be 224written to 'subbuffer_size' and hardware will always expect two isochronous 225packets within one USB transaction. This renders 226 227 MTU_USB - (2 * subbuffer_size) 228 229bytes for padding. 230 231Note that at least (2 * subbuffer_size) bytes for isochronous data or 232(subbuffer_size * packts_per_xact) bytes for synchronous data need to 233be put in the transmission buffer and passed to the driver. 234 235Since adapter drivers are allowed to change a chosen configuration to best 236fit its constraints, it is recommended to always double check the 237configuration and read back the previously written files. 238