mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-27 06:34:11 +08:00
baa293e954
There are lots of documents under Documentation/*.txt and a few other orphan documents elsehwere that belong to the driver-API book. Move them to their right place. Reviewed-by: Cornelia Huck <cohuck@redhat.com> # vfio-related parts Acked-by: Logan Gunthorpe <logang@deltatee.com> # switchtec Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
75 lines
2.8 KiB
ReStructuredText
75 lines
2.8 KiB
ReStructuredText
.. 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.
|