aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/arm
diff options
context:
space:
mode:
authorRicardo Neri <ricardo.neri@ti.com>2012-03-06 19:20:37 -0500
committerTomi Valkeinen <tomi.valkeinen@ti.com>2012-05-11 08:13:50 -0400
commit9c0b8420369cb5d7fd2fea51d4705cbd0ea52743 (patch)
treec34c59d7a4c6ffc47a97816e396662aa59726084 /Documentation/arm
parent38137c8f0ce8dfaea467884cb2eb45de8df1bdfc (diff)
OMAPDSS: Provide an interface for audio support
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 omap_dss_audio structure may be extended in the future if required. 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. A new enum omap_dss_audio_state is introduced 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 rendered. Signed-off-by: Ricardo Neri <ricardo.neri@ti.com>
Diffstat (limited to 'Documentation/arm')
-rw-r--r--Documentation/arm/OMAP/DSS45
1 files changed, 45 insertions, 0 deletions
diff --git a/Documentation/arm/OMAP/DSS b/Documentation/arm/OMAP/DSS
index d0aea9192204..a564ceea9e98 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
47modelling the hardware overlays, omapdss supports virtual overlays and overlay 47modelling the hardware overlays, omapdss supports virtual overlays and overlay
48managers. These can be used when updating a display with CPU or system DMA. 48managers. These can be used when updating a display with CPU or system DMA.
49 49
50omapdss driver support for audio
51--------------------------------
52There exist several display technologies and standards that support audio as
53well. Hence, it is relevant to update the DSS device driver to provide an audio
54interface that may be used by an audio driver or any other driver interested in
55the functionality.
56
57The audio_enable function is intended to prepare the relevant
58IP for playback (e.g., enabling an audio FIFO, taking in/out of reset
59some IP, enabling companion chips, etc). It is intended to be called before
60audio_start. The audio_disable function performs the reverse operation and is
61intended to be called after audio_stop.
62
63While a given DSS device driver may support audio, it is possible that for
64certain configurations audio is not supported (e.g., an HDMI display using a
65VESA video timing). The audio_supported function is intended to query whether
66the current configuration of the display supports audio.
67
68The audio_config function is intended to configure all the relevant audio
69parameters of the display. In order to make the function independent of any
70specific DSS device driver, a struct omap_dss_audio is defined. Its purpose
71is to contain all the required parameters for audio configuration. At the
72moment, such structure contains pointers to IEC-60958 channel status word
73and CEA-861 audio infoframe structures. This should be enough to support
74HDMI and DisplayPort, as both are based on CEA-861 and IEC-60958.
75
76The audio_enable/disable, audio_config and audio_supported functions could be
77implemented as functions that may sleep. Hence, they should not be called
78while holding a spinlock or a readlock.
79
80The audio_start/audio_stop function is intended to effectively start/stop audio
81playback after the configuration has taken place. These functions are designed
82to be used in an atomic context. Hence, audio_start should return quickly and be
83called only after all the needed resources for audio playback (audio FIFOs,
84DMA channels, companion chips, etc) have been enabled to begin data transfers.
85audio_stop is designed to only stop the audio transfers. The resources used
86for playback are released using audio_disable.
87
88The enum omap_dss_audio_state may be used to help the implementations of
89the interface to keep track of the audio state. The initial state is _DISABLED;
90then, the state transitions to _CONFIGURED, and then, when it is ready to
91play audio, to _ENABLED. The state _PLAYING is used when the audio is being
92rendered.
93
94
50Panel and controller drivers 95Panel and controller drivers
51---------------------------- 96----------------------------
52 97