Documentation/arch/arm/omap/dss.rst

Source file repositories/reference/linux-study-clean/Documentation/arch/arm/omap/dss.rst

File Facts

System
Linux kernel
Corpus path
Documentation/arch/arm/omap/dss.rst
Extension
.rst
Size
12947 bytes
Lines
373
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

=========================
OMAP2/3 Display Subsystem
=========================

This is an almost total rewrite of the OMAP FB driver in drivers/video/omap
(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,
TV-out and multiple display support, but there are lots of small improvements
also.

The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,
panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live
currently side by side, you can choose which one to use.

Features
--------

Working and tested features include:

- MIPI DPI (parallel) output
- MIPI DSI output in command mode
- MIPI DBI (RFBI) output
- SDI output
- TV output
- All pieces can be compiled as a module or inside kernel
- Use DISPC to update any of the outputs
- Use CPU to update RFBI or DSI output
- OMAP DISPC planes
- RGB16, RGB24 packed, RGB24 unpacked
- YUV2, UYVY
- Scaling
- Adjusting DSS FCK to find a good pixel clock
- Use DSI DPLL to create DSS FCK

Tested boards include:
- OMAP3 SDP board
- Beagle board
- N810

omapdss driver
--------------

The DSS driver does not itself have any support for Linux framebuffer, V4L or
such like the current ones, but it has an internal kernel API that upper level
drivers can use.

The DSS driver models OMAP's overlays, overlay managers and displays in a
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

Annotation

Implementation Notes