Ben Dooks | ffd65af | 2007-06-23 17:16:31 -0700 | [diff] [blame] | 1 | SM501 Driver |
| 2 | ============ |
| 3 | |
| 4 | Copyright 2006, 2007 Simtec Electronics |
| 5 | |
Rob Landley | f0ae566 | 2007-10-16 23:31:24 -0700 | [diff] [blame^] | 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 | |
Ben Dooks | ffd65af | 2007-06-23 17:16:31 -0700 | [diff] [blame] | 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. |