
		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 comoponent,
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

See ABI/sysfs-bus-most.txt


		Section 2.2 Routing Channels

To connect a configured channel to a certain core component and make it
accessible for user space applications, the driver attribute 'add_link' is
used. The configuration string passed to it has the following format:

	"device_name:channel_name:component_name:link_name[.param]"

It is the concatenation of up to four substrings separated by a colon. The
substrings contain the names of the MOST interface, the channel, the
component driver and a custom name with which the link is going to be
referenced with. Since some components need additional information, the
link name can be extended with a component-specific parameter (separated by
a dot). In case the character device component is loaded, the handle would
also appear as a device node in the /dev directory.

Cdev component example:
        $ echo "mdev0:ep_81:cdev:my_rx_channel" >$(DRV_DIR)/add_link


Sound component example:

The sound component needs additional parameters to determine the audio
resolution that is going to be used and to trigger the registration of a
sound card with ALSA. 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)

To make the sound module create a sound card and register it with ALSA the
string "create" needs to be attached to the module parameter section of the
configuration string. To create a sound card with with two playback devices
(linked to channel ep01 and ep02) and one capture device (linked to channel
ep83) the following is written to the add_link file:

        $ echo "mdev0:ep01:sound:most51_playback.6x16" >$(DRV_DIR)/add_link
        $ echo "mdev0:ep02:sound:most_playback.2x16" >$(DRV_DIR)/add_link
        $ echo "mdev0:ep83:sound:most_capture.2x16.create" >$(DRV_DIR)/add_link

The link names (most51_playback, most_playback and most_capture) will
become the names of the PCM devices of the sound card.

		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 'set_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 = set_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 'set_subbuffer_size' and hardware will always expect two
isochronous packets within one USB transaction. This renders

	MTU_USB - (2 * set_subbuffer_size)

bytes for padding.

Note that at least (2 * set_subbuffer_size) bytes for isochronous data or
(set_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.