Documentation/driver-api/sm501.rst - kernel/common - Git at Google

 .. include:: <isonum.txt>

 ============
 SM501 Driver
 ============

 :Copyright: |copy| 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.
	.. include:: <isonum.txt>

	============
	SM501 Driver
	============

	:Copyright: \|copy\| 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.