path: root/Documentation/arm
diff options
authorAnton Arapov <>2012-08-07 11:21:50 +0200
committerAnton Arapov <>2012-08-07 12:52:25 +0200
commit1d44b6f3fcf6058fb7c960b7558766967e8028f7 (patch)
tree53d88547c973ba048d233091a3f91f3173ad01df /Documentation/arm
parentd91eda5d7b0383e6a0c83e0146ff141ff3b1355b (diff)
fedora kernel: 222b075b3ff0d9e88aa9353e3c80667756ed7361v3.5.0-4
Signed-off-by: Anton Arapov <>
Diffstat (limited to 'Documentation/arm')
4 files changed, 68 insertions, 90 deletions
diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX
index 91c24a1e8a9..36420e116c9 100644
--- a/Documentation/arm/00-INDEX
+++ b/Documentation/arm/00-INDEX
@@ -4,8 +4,6 @@ Booting
- requirements for booting
- ARM Interrupt subsystem documentation
- - Release Notes for Linux on Intel's IXP2000 Network Processor
- MSM specific documentation
diff --git a/Documentation/arm/IXP2000 b/Documentation/arm/IXP2000
deleted file mode 100644
index 68d21d92a30..00000000000
--- a/Documentation/arm/IXP2000
+++ /dev/null
@@ -1,69 +0,0 @@
-Release Notes for Linux on Intel's IXP2000 Network Processor
-Maintained by Deepak Saxena <>
-1. Overview
-Intel's IXP2000 family of NPUs (IXP2400, IXP2800, IXP2850) is designed
-for high-performance network applications such high-availability
-telecom systems. In addition to an XScale core, it contains up to 8
-"MicroEngines" that run special code, several high-end networking
-interfaces (UTOPIA, SPI, etc), a PCI host bridge, one serial port,
-flash interface, and some other odds and ends. For more information, see:
-2. Linux Support
-Linux currently supports the following features on the IXP2000 NPUs:
-- On-chip serial
-- PCI
-- Flash (MTD/JFFS2)
-- I2C through GPIO
-- Timers (watchdog, OS)
-That is about all we can support under Linux ATM b/c the core networking
-components of the chip are accessed via Intel's closed source SDK.
-Please contact Intel directly on issues with using those. There is
-also a mailing list run by some folks at Princeton University that might
-be of help:
-3. Supported Platforms
-- Intel IXDP2400 Reference Platform
-- Intel IXDP2800 Reference Platform
-- Intel IXDP2401 Reference Platform
-- Intel IXDP2801 Reference Platform
-- RadiSys ENP-2611
-4. Usage Notes
-- The IXP2000 platforms usually have rather complex PCI bus topologies
- with large memory space requirements. In addition, b/c of the way the
- Intel SDK is designed, devices are enumerated in a very specific
- way. B/c of this this, we use "pci=firmware" option in the kernel
- command line so that we do not re-enumerate the bus.
-- IXDP2x01 systems have variable clock tick rates that we cannot determine
- via HW registers. The "ixdp2x01_clk=XXX" cmd line options allow you
- to pass the clock rate to the board port.
-5. Thanks
-The IXP2000 work has been funded by Intel Corp. and MontaVista Software, Inc.
-The following people have contributed patches/comments/etc:
-Naeem F. Afzal
-Lennert Buytenhek
-Jeffrey Daly
-Last Update: 8/09/2004
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index 888ae7b83ae..a564ceea9e9 100644
--- a/Documentation/arm/OMAP/DSS
+++ b/Documentation/arm/OMAP/DSS
@@ -47,6 +47,51 @@ flexible way to enable non-common multi-display configuration. In addition to
modelling the hardware overlays, omapdss supports virtual overlays and overlay
managers. These can be used when updating a display with CPU or system DMA.
+omapdss driver support for audio
+There exist several display technologies and standards that support audio as
+well. Hence, it is relevant to update the DSS device driver to provide an audio
+interface that may be used by an audio driver or any other driver interested in
+the functionality.
+The audio_enable function is intended to prepare the relevant
+IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
+some IP, enabling companion chips, etc). It is intended to be called before
+audio_start. The audio_disable function performs the reverse operation and is
+intended to be called after audio_stop.
+While a given DSS device driver may support audio, it is possible that for
+certain configurations audio is not supported (e.g., an HDMI display using a
+VESA video timing). The audio_supported function is intended to query whether
+the current configuration of the display supports audio.
+The audio_config function is intended to configure all the relevant audio
+parameters of the display. In order to make the function independent of any
+specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
+is to contain all the required parameters for audio configuration. At the
+moment, such structure contains pointers to IEC-60958 channel status word
+and CEA-861 audio infoframe structures. This should be enough to support
+HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.
+The audio_enable/disable, audio_config and audio_supported functions could be
+implemented as functions that may sleep. Hence, they should not be called
+while holding a spinlock or a readlock.
+The audio_start/audio_stop function is intended to effectively start/stop audio
+playback after the configuration has taken place. These functions are designed
+to be used in an atomic context. Hence, audio_start should return quickly and be
+called only after all the needed resources for audio playback (audio FIFOs,
+DMA channels, companion chips, etc) have been enabled to begin data transfers.
+audio_stop is designed to only stop the audio transfers. The resources used
+for playback are released using audio_disable.
+The enum omap_dss_audio_state may be used to help the implementations of
+the interface to keep track of the audio state. The initial state is _DISABLED;
+then, the state transitions to _CONFIGURED, and then, when it is ready to
+play audio, to _ENABLED. The state _PLAYING is used when the audio is being
Panel and controller drivers
@@ -156,6 +201,7 @@ timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
"pal" and "ntsc"
tear_elim Tearing elimination 0=off, 1=on
+output_type Output type (video encoder only): "composite" or "svideo"
There are also some debugfs files at <debugfs>/omapdss/ which show information
about clocks and registers.
diff --git a/Documentation/arm/SPEAr/overview.txt b/Documentation/arm/SPEAr/overview.txt
index 253a35c6f78..65610bf52eb 100644
--- a/Documentation/arm/SPEAr/overview.txt
+++ b/Documentation/arm/SPEAr/overview.txt
@@ -8,53 +8,56 @@ Introduction
weblink :
The ST Microelectronics SPEAr range of ARM9/CortexA9 System-on-Chip CPUs are
- supported by the 'spear' platform of ARM Linux. Currently SPEAr300,
- SPEAr310, SPEAr320 and SPEAr600 SOCs are supported. Support for the SPEAr13XX
- series is in progress.
+ supported by the 'spear' platform of ARM Linux. Currently SPEAr1310,
+ SPEAr1340, SPEAr300, SPEAr310, SPEAr320 and SPEAr600 SOCs are supported.
Hierarchy in SPEAr is as follows:
SPEAr (Platform)
- SPEAr3XX (3XX SOC series, based on ARM9)
- SPEAr300 (SOC)
- - SPEAr300_EVB (Evaluation Board)
+ - SPEAr300 Evaluation Board
- SPEAr310 (SOC)
- - SPEAr310_EVB (Evaluation Board)
+ - SPEAr310 Evaluation Board
- SPEAr320 (SOC)
- - SPEAr320_EVB (Evaluation Board)
+ - SPEAr320 Evaluation Board
- SPEAr6XX (6XX SOC series, based on ARM9)
- SPEAr600 (SOC)
- - SPEAr600_EVB (Evaluation Board)
+ - SPEAr600 Evaluation Board
- SPEAr13XX (13XX SOC series, based on ARM CORTEXA9)
- - SPEAr1300 (SOC)
+ - SPEAr1310 (SOC)
+ - SPEAr1310 Evaluation Board
+ - SPEAr1340 (SOC)
+ - SPEAr1340 Evaluation Board
A generic configuration is provided for each machine, and can be used as the
default by
- make spear600_defconfig
- make spear300_defconfig
- make spear310_defconfig
- make spear320_defconfig
+ make spear13xx_defconfig
+ make spear3xx_defconfig
+ make spear6xx_defconfig
- The common files for multiple machine families (SPEAr3XX, SPEAr6XX and
- SPEAr13XX) are located in the platform code contained in arch/arm/plat-spear
+ The common files for multiple machine families (SPEAr3xx, SPEAr6xx and
+ SPEAr13xx) are located in the platform code contained in arch/arm/plat-spear
with headers in plat/.
Each machine series have a directory with name arch/arm/mach-spear followed by
series name. Like mach-spear3xx, mach-spear6xx and mach-spear13xx.
- Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c and for
- spear6xx is mach-spear6xx/spear6xx.c. mach-spear* also contain soc/machine
- specific files, like spear300.c, spear310.c, spear320.c and spear600.c.
- mach-spear* also contains board specific files for each machine type.
+ Common file for machines of spear3xx family is mach-spear3xx/spear3xx.c, for
+ spear6xx is mach-spear6xx/spear6xx.c and for spear13xx family is
+ mach-spear13xx/spear13xx.c. mach-spear* also contain soc/machine specific
+ files, like spear1310.c, spear1340.c spear300.c, spear310.c, spear320.c and
+ spear600.c. mach-spear* doesn't contains board specific files as they fully
+ support Flattened Device Tree.
Document Author
- Viresh Kumar, (c) 2010 ST Microelectronics
+ Viresh Kumar <>, (c) 2010-2012 ST Microelectronics