|
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.
|
