1 |
3 |
xianfeng |
SM501 Driver
|
2 |
|
|
============
|
3 |
|
|
|
4 |
|
|
Copyright 2006, 2007 Simtec Electronics
|
5 |
|
|
|
6 |
|
|
The Silicon Motion SM501 multimedia companion chip is a multifunction device
|
7 |
|
|
which may provide numerous interfaces including USB host controller USB gadget,
|
8 |
|
|
Asyncronous Serial ports, Audio functions and a dual display video interface.
|
9 |
|
|
The device may be connected by PCI or local bus with varying functions enabled.
|
10 |
|
|
|
11 |
|
|
Core
|
12 |
|
|
----
|
13 |
|
|
|
14 |
|
|
The core driver in drivers/mfd provides common services for the
|
15 |
|
|
drivers which manage the specific hardware blocks. These services
|
16 |
|
|
include locking for common registers, clock control and resource
|
17 |
|
|
management.
|
18 |
|
|
|
19 |
|
|
The core registers drivers for both PCI and generic bus based
|
20 |
|
|
chips via the platform device and driver system.
|
21 |
|
|
|
22 |
|
|
On detection of a device, the core initialises the chip (which may
|
23 |
|
|
be specified by the platform data) and then exports the selected
|
24 |
|
|
peripheral set as platform devices for the specific drivers.
|
25 |
|
|
|
26 |
|
|
The core re-uses the platform device system as the platform device
|
27 |
|
|
system provides enough features to support the drivers without the
|
28 |
|
|
need to create a new bus-type and the associated code to go with it.
|
29 |
|
|
|
30 |
|
|
|
31 |
|
|
Resources
|
32 |
|
|
---------
|
33 |
|
|
|
34 |
|
|
Each peripheral has a view of the device which is implicitly narrowed to
|
35 |
|
|
the specific set of resources that peripheral requires in order to
|
36 |
|
|
function correctly.
|
37 |
|
|
|
38 |
|
|
The centralised memory allocation allows the driver to ensure that the
|
39 |
|
|
maximum possible resource allocation can be made to the video subsystem
|
40 |
|
|
as this is by-far the most resource-sensitive of the on-chip functions.
|
41 |
|
|
|
42 |
|
|
The primary issue with memory allocation is that of moving the video
|
43 |
|
|
buffers once a display mode is chosen. Indeed when a video mode change
|
44 |
|
|
occurs the memory footprint of the video subsystem changes.
|
45 |
|
|
|
46 |
|
|
Since video memory is difficult to move without changing the display
|
47 |
|
|
(unless sufficient contiguous memory can be provided for the old and new
|
48 |
|
|
modes simultaneously) the video driver fully utilises the memory area
|
49 |
|
|
given to it by aligning fb0 to the start of the area and fb1 to the end
|
50 |
|
|
of it. Any memory left over in the middle is used for the acceleration
|
51 |
|
|
functions, which are transient and thus their location is less critical
|
52 |
|
|
as it can be moved.
|
53 |
|
|
|
54 |
|
|
|
55 |
|
|
Configuration
|
56 |
|
|
-------------
|
57 |
|
|
|
58 |
|
|
The platform device driver uses a set of platform data to pass
|
59 |
|
|
configurations through to the core and the subsidiary drivers
|
60 |
|
|
so that there can be support for more than one system carrying
|
61 |
|
|
an SM501 built into a single kernel image.
|
62 |
|
|
|
63 |
|
|
The PCI driver assumes that the PCI card behaves as per the Silicon
|
64 |
|
|
Motion reference design.
|
65 |
|
|
|
66 |
|
|
There is an errata (AB-5) affecting the selection of the
|
67 |
|
|
of the M1XCLK and M1CLK frequencies. These two clocks
|
68 |
|
|
must be sourced from the same PLL, although they can then
|
69 |
|
|
be divided down individually. If this is not set, then SM501 may
|
70 |
|
|
lock and hang the whole system. The driver will refuse to
|
71 |
|
|
attach if the PLL selection is different.
|