xref: /linux/Documentation/driver-api/sm501.rst (revision baa293e9)
1*baa293e9SMauro Carvalho Chehab.. include:: <isonum.txt>
2*baa293e9SMauro Carvalho Chehab
3*baa293e9SMauro Carvalho Chehab============
4*baa293e9SMauro Carvalho ChehabSM501 Driver
5*baa293e9SMauro Carvalho Chehab============
6*baa293e9SMauro Carvalho Chehab
7*baa293e9SMauro Carvalho Chehab:Copyright: |copy| 2006, 2007 Simtec Electronics
8*baa293e9SMauro Carvalho Chehab
9*baa293e9SMauro Carvalho ChehabThe Silicon Motion SM501 multimedia companion chip is a multifunction device
10*baa293e9SMauro Carvalho Chehabwhich may provide numerous interfaces including USB host controller USB gadget,
11*baa293e9SMauro Carvalho Chehabasynchronous serial ports, audio functions, and a dual display video interface.
12*baa293e9SMauro Carvalho ChehabThe device may be connected by PCI or local bus with varying functions enabled.
13*baa293e9SMauro Carvalho Chehab
14*baa293e9SMauro Carvalho ChehabCore
15*baa293e9SMauro Carvalho Chehab----
16*baa293e9SMauro Carvalho Chehab
17*baa293e9SMauro Carvalho ChehabThe core driver in drivers/mfd provides common services for the
18*baa293e9SMauro Carvalho Chehabdrivers which manage the specific hardware blocks. These services
19*baa293e9SMauro Carvalho Chehabinclude locking for common registers, clock control and resource
20*baa293e9SMauro Carvalho Chehabmanagement.
21*baa293e9SMauro Carvalho Chehab
22*baa293e9SMauro Carvalho ChehabThe core registers drivers for both PCI and generic bus based
23*baa293e9SMauro Carvalho Chehabchips via the platform device and driver system.
24*baa293e9SMauro Carvalho Chehab
25*baa293e9SMauro Carvalho ChehabOn detection of a device, the core initialises the chip (which may
26*baa293e9SMauro Carvalho Chehabbe specified by the platform data) and then exports the selected
27*baa293e9SMauro Carvalho Chehabperipheral set as platform devices for the specific drivers.
28*baa293e9SMauro Carvalho Chehab
29*baa293e9SMauro Carvalho ChehabThe core re-uses the platform device system as the platform device
30*baa293e9SMauro Carvalho Chehabsystem provides enough features to support the drivers without the
31*baa293e9SMauro Carvalho Chehabneed to create a new bus-type and the associated code to go with it.
32*baa293e9SMauro Carvalho Chehab
33*baa293e9SMauro Carvalho Chehab
34*baa293e9SMauro Carvalho ChehabResources
35*baa293e9SMauro Carvalho Chehab---------
36*baa293e9SMauro Carvalho Chehab
37*baa293e9SMauro Carvalho ChehabEach peripheral has a view of the device which is implicitly narrowed to
38*baa293e9SMauro Carvalho Chehabthe specific set of resources that peripheral requires in order to
39*baa293e9SMauro Carvalho Chehabfunction correctly.
40*baa293e9SMauro Carvalho Chehab
41*baa293e9SMauro Carvalho ChehabThe centralised memory allocation allows the driver to ensure that the
42*baa293e9SMauro Carvalho Chehabmaximum possible resource allocation can be made to the video subsystem
43*baa293e9SMauro Carvalho Chehabas this is by-far the most resource-sensitive of the on-chip functions.
44*baa293e9SMauro Carvalho Chehab
45*baa293e9SMauro Carvalho ChehabThe primary issue with memory allocation is that of moving the video
46*baa293e9SMauro Carvalho Chehabbuffers once a display mode is chosen. Indeed when a video mode change
47*baa293e9SMauro Carvalho Chehaboccurs the memory footprint of the video subsystem changes.
48*baa293e9SMauro Carvalho Chehab
49*baa293e9SMauro Carvalho ChehabSince video memory is difficult to move without changing the display
50*baa293e9SMauro Carvalho Chehab(unless sufficient contiguous memory can be provided for the old and new
51*baa293e9SMauro Carvalho Chehabmodes simultaneously) the video driver fully utilises the memory area
52*baa293e9SMauro Carvalho Chehabgiven to it by aligning fb0 to the start of the area and fb1 to the end
53*baa293e9SMauro Carvalho Chehabof it. Any memory left over in the middle is used for the acceleration
54*baa293e9SMauro Carvalho Chehabfunctions, which are transient and thus their location is less critical
55*baa293e9SMauro Carvalho Chehabas it can be moved.
56*baa293e9SMauro Carvalho Chehab
57*baa293e9SMauro Carvalho Chehab
58*baa293e9SMauro Carvalho ChehabConfiguration
59*baa293e9SMauro Carvalho Chehab-------------
60*baa293e9SMauro Carvalho Chehab
61*baa293e9SMauro Carvalho ChehabThe platform device driver uses a set of platform data to pass
62*baa293e9SMauro Carvalho Chehabconfigurations through to the core and the subsidiary drivers
63*baa293e9SMauro Carvalho Chehabso that there can be support for more than one system carrying
64*baa293e9SMauro Carvalho Chehaban SM501 built into a single kernel image.
65*baa293e9SMauro Carvalho Chehab
66*baa293e9SMauro Carvalho ChehabThe PCI driver assumes that the PCI card behaves as per the Silicon
67*baa293e9SMauro Carvalho ChehabMotion reference design.
68*baa293e9SMauro Carvalho Chehab
69*baa293e9SMauro Carvalho ChehabThere is an errata (AB-5) affecting the selection of the
70*baa293e9SMauro Carvalho Chehabof the M1XCLK and M1CLK frequencies. These two clocks
71*baa293e9SMauro Carvalho Chehabmust be sourced from the same PLL, although they can then
72*baa293e9SMauro Carvalho Chehabbe divided down individually. If this is not set, then SM501 may
73*baa293e9SMauro Carvalho Chehablock and hang the whole system. The driver will refuse to
74*baa293e9SMauro Carvalho Chehabattach if the PLL selection is different.
75