mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-17 09:43:59 +08:00
d1bb1d04f5
Each text file under Documentation follows a different format. Some doesn't even have titles! Change its representation to follow the adopted standard, using ReST markups for it to be parseable by Sphinx: - adjust document title; - use the copyright markup. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
75 lines
2.8 KiB
Plaintext
75 lines
2.8 KiB
Plaintext
.. include:: <isonum.txt>
|
|
|
|
============
|
|
SM501 Driver
|
|
============
|
|
|
|
:Copyright: |copy| 2006, 2007 Simtec Electronics
|
|
|
|
The Silicon Motion SM501 multimedia companion chip is a multifunction device
|
|
which may provide numerous interfaces including USB host controller USB gadget,
|
|
asynchronous serial ports, audio functions, and a dual display video interface.
|
|
The device may be connected by PCI or local bus with varying functions enabled.
|
|
|
|
Core
|
|
----
|
|
|
|
The core driver in drivers/mfd provides common services for the
|
|
drivers which manage the specific hardware blocks. These services
|
|
include locking for common registers, clock control and resource
|
|
management.
|
|
|
|
The core registers drivers for both PCI and generic bus based
|
|
chips via the platform device and driver system.
|
|
|
|
On detection of a device, the core initialises the chip (which may
|
|
be specified by the platform data) and then exports the selected
|
|
peripheral set as platform devices for the specific drivers.
|
|
|
|
The core re-uses the platform device system as the platform device
|
|
system provides enough features to support the drivers without the
|
|
need to create a new bus-type and the associated code to go with it.
|
|
|
|
|
|
Resources
|
|
---------
|
|
|
|
Each peripheral has a view of the device which is implicitly narrowed to
|
|
the specific set of resources that peripheral requires in order to
|
|
function correctly.
|
|
|
|
The centralised memory allocation allows the driver to ensure that the
|
|
maximum possible resource allocation can be made to the video subsystem
|
|
as this is by-far the most resource-sensitive of the on-chip functions.
|
|
|
|
The primary issue with memory allocation is that of moving the video
|
|
buffers once a display mode is chosen. Indeed when a video mode change
|
|
occurs the memory footprint of the video subsystem changes.
|
|
|
|
Since video memory is difficult to move without changing the display
|
|
(unless sufficient contiguous memory can be provided for the old and new
|
|
modes simultaneously) the video driver fully utilises the memory area
|
|
given to it by aligning fb0 to the start of the area and fb1 to the end
|
|
of it. Any memory left over in the middle is used for the acceleration
|
|
functions, which are transient and thus their location is less critical
|
|
as it can be moved.
|
|
|
|
|
|
Configuration
|
|
-------------
|
|
|
|
The platform device driver uses a set of platform data to pass
|
|
configurations through to the core and the subsidiary drivers
|
|
so that there can be support for more than one system carrying
|
|
an SM501 built into a single kernel image.
|
|
|
|
The PCI driver assumes that the PCI card behaves as per the Silicon
|
|
Motion reference design.
|
|
|
|
There is an errata (AB-5) affecting the selection of the
|
|
of the M1XCLK and M1CLK frequencies. These two clocks
|
|
must be sourced from the same PLL, although they can then
|
|
be divided down individually. If this is not set, then SM501 may
|
|
lock and hang the whole system. The driver will refuse to
|
|
attach if the PLL selection is different.
|