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