mirror of
https://github.com/AuxXxilium/linux_dsm_epyc7002.git
synced 2024-12-05 08:16:49 +07:00
19f5946001
Fix various typos in documentation txts. Signed-off-by: Matt LaPlante <kernel1@cyberdogtech.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
72 lines
2.8 KiB
Plaintext
72 lines
2.8 KiB
Plaintext
SM501 Driver
|
|
============
|
|
|
|
Copyright 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.
|