diff options
author | Ben Dooks <ben-linux@fluff.org> | 2007-06-23 20:16:31 -0400 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-06-24 11:59:11 -0400 |
commit | ffd65af0e67a054e1e2393c9b0995c03c47cdc30 (patch) | |
tree | 25c7462c8e3ffecfd9f7835581098dec045b49bb | |
parent | 819062219abf8a78e54cad5c1c8716e6c8e7b870 (diff) |
SM501: Add Documentation/SM501.txt
Add documentation for the SM501 in Documentation/SM501.txt outlining the SM501
driver.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
-rw-r--r-- | Documentation/SM501.txt | 66 |
1 files changed, 66 insertions, 0 deletions
diff --git a/Documentation/SM501.txt b/Documentation/SM501.txt new file mode 100644 index 000000000000..3a1bd95d3767 --- /dev/null +++ b/Documentation/SM501.txt | |||
@@ -0,0 +1,66 @@ | |||
1 | SM501 Driver | ||
2 | ============ | ||
3 | |||
4 | Copyright 2006, 2007 Simtec Electronics | ||
5 | |||
6 | Core | ||
7 | ---- | ||
8 | |||
9 | The core driver in drivers/mfd provides common services for the | ||
10 | drivers which manage the specific hardware blocks. These services | ||
11 | include locking for common registers, clock control and resource | ||
12 | management. | ||
13 | |||
14 | The core registers drivers for both PCI and generic bus based | ||
15 | chips via the platform device and driver system. | ||
16 | |||
17 | On detection of a device, the core initialises the chip (which may | ||
18 | be specified by the platform data) and then exports the selected | ||
19 | peripheral set as platform devices for the specific drivers. | ||
20 | |||
21 | The core re-uses the platform device system as the platform device | ||
22 | system provides enough features to support the drivers without the | ||
23 | need to create a new bus-type and the associated code to go with it. | ||
24 | |||
25 | |||
26 | Resources | ||
27 | --------- | ||
28 | |||
29 | Each peripheral has a view of the device which is implicitly narrowed to | ||
30 | the specific set of resources that peripheral requires in order to | ||
31 | function correctly. | ||
32 | |||
33 | The centralised memory allocation allows the driver to ensure that the | ||
34 | maximum possible resource allocation can be made to the video subsystem | ||
35 | as this is by-far the most resource-sensitive of the on-chip functions. | ||
36 | |||
37 | The primary issue with memory allocation is that of moving the video | ||
38 | buffers once a display mode is chosen. Indeed when a video mode change | ||
39 | occurs the memory footprint of the video subsystem changes. | ||
40 | |||
41 | Since video memory is difficult to move without changing the display | ||
42 | (unless sufficient contiguous memory can be provided for the old and new | ||
43 | modes simultaneously) the video driver fully utilises the memory area | ||
44 | given to it by aligning fb0 to the start of the area and fb1 to the end | ||
45 | of it. Any memory left over in the middle is used for the acceleration | ||
46 | functions, which are transient and thus their location is less critical | ||
47 | as it can be moved. | ||
48 | |||
49 | |||
50 | Configuration | ||
51 | ------------- | ||
52 | |||
53 | The platform device driver uses a set of platform data to pass | ||
54 | configurations through to the core and the subsidiary drivers | ||
55 | so that there can be support for more than one system carrying | ||
56 | an SM501 built into a single kernel image. | ||
57 | |||
58 | The PCI driver assumes that the PCI card behaves as per the Silicon | ||
59 | Motion reference design. | ||
60 | |||
61 | There is an errata (AB-5) affecting the selection of the | ||
62 | of the M1XCLK and M1CLK frequencies. These two clocks | ||
63 | must be sourced from the same PLL, although they can then | ||
64 | be divided down individually. If this is not set, then SM501 may | ||
65 | lock and hang the whole system. The driver will refuse to | ||
66 | attach if the PLL selection is different. | ||