2009-11-03 16:23:50 +07:00
|
|
|
/*
|
|
|
|
* Copyright (C) 2008 Nokia Corporation
|
|
|
|
* Author: Tomi Valkeinen <tomi.valkeinen@nokia.com>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify it
|
|
|
|
* under the terms of the GNU General Public License version 2 as published by
|
|
|
|
* the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful, but WITHOUT
|
|
|
|
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
|
|
|
|
* more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License along with
|
|
|
|
* this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
2011-05-11 18:05:07 +07:00
|
|
|
#ifndef __OMAP_OMAPDSS_H
|
|
|
|
#define __OMAP_OMAPDSS_H
|
2009-11-03 16:23:50 +07:00
|
|
|
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/kobject.h>
|
|
|
|
#include <linux/device.h>
|
2012-11-07 23:17:35 +07:00
|
|
|
#include <linux/interrupt.h>
|
2009-11-03 16:23:50 +07:00
|
|
|
|
2013-05-10 17:02:32 +07:00
|
|
|
#include <video/videomode.h>
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
#define DISPC_IRQ_FRAMEDONE (1 << 0)
|
|
|
|
#define DISPC_IRQ_VSYNC (1 << 1)
|
|
|
|
#define DISPC_IRQ_EVSYNC_EVEN (1 << 2)
|
|
|
|
#define DISPC_IRQ_EVSYNC_ODD (1 << 3)
|
|
|
|
#define DISPC_IRQ_ACBIAS_COUNT_STAT (1 << 4)
|
|
|
|
#define DISPC_IRQ_PROG_LINE_NUM (1 << 5)
|
|
|
|
#define DISPC_IRQ_GFX_FIFO_UNDERFLOW (1 << 6)
|
|
|
|
#define DISPC_IRQ_GFX_END_WIN (1 << 7)
|
|
|
|
#define DISPC_IRQ_PAL_GAMMA_MASK (1 << 8)
|
|
|
|
#define DISPC_IRQ_OCP_ERR (1 << 9)
|
|
|
|
#define DISPC_IRQ_VID1_FIFO_UNDERFLOW (1 << 10)
|
|
|
|
#define DISPC_IRQ_VID1_END_WIN (1 << 11)
|
|
|
|
#define DISPC_IRQ_VID2_FIFO_UNDERFLOW (1 << 12)
|
|
|
|
#define DISPC_IRQ_VID2_END_WIN (1 << 13)
|
|
|
|
#define DISPC_IRQ_SYNC_LOST (1 << 14)
|
|
|
|
#define DISPC_IRQ_SYNC_LOST_DIGIT (1 << 15)
|
|
|
|
#define DISPC_IRQ_WAKEUP (1 << 16)
|
2010-12-02 18:27:12 +07:00
|
|
|
#define DISPC_IRQ_SYNC_LOST2 (1 << 17)
|
|
|
|
#define DISPC_IRQ_VSYNC2 (1 << 18)
|
2011-09-13 19:50:33 +07:00
|
|
|
#define DISPC_IRQ_VID3_END_WIN (1 << 19)
|
|
|
|
#define DISPC_IRQ_VID3_FIFO_UNDERFLOW (1 << 20)
|
2010-12-02 18:27:12 +07:00
|
|
|
#define DISPC_IRQ_ACBIAS_COUNT_STAT2 (1 << 21)
|
|
|
|
#define DISPC_IRQ_FRAMEDONE2 (1 << 22)
|
2011-08-31 17:39:03 +07:00
|
|
|
#define DISPC_IRQ_FRAMEDONEWB (1 << 23)
|
|
|
|
#define DISPC_IRQ_FRAMEDONETV (1 << 24)
|
|
|
|
#define DISPC_IRQ_WBBUFFEROVERFLOW (1 << 25)
|
2012-08-27 15:53:19 +07:00
|
|
|
#define DISPC_IRQ_SYNC_LOST3 (1 << 27)
|
|
|
|
#define DISPC_IRQ_VSYNC3 (1 << 28)
|
|
|
|
#define DISPC_IRQ_ACBIAS_COUNT_STAT3 (1 << 29)
|
|
|
|
#define DISPC_IRQ_FRAMEDONE3 (1 << 30)
|
2009-11-03 16:23:50 +07:00
|
|
|
|
|
|
|
struct omap_dss_device;
|
|
|
|
struct omap_overlay_manager;
|
2012-10-24 17:52:40 +07:00
|
|
|
struct dss_lcd_mgr_config;
|
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>
2012-03-07 07:20:37 +07:00
|
|
|
struct snd_aes_iec958;
|
|
|
|
struct snd_cea_861_aud_if;
|
2009-11-03 16:23:50 +07:00
|
|
|
|
|
|
|
enum omap_display_type {
|
|
|
|
OMAP_DISPLAY_TYPE_NONE = 0,
|
|
|
|
OMAP_DISPLAY_TYPE_DPI = 1 << 0,
|
|
|
|
OMAP_DISPLAY_TYPE_DBI = 1 << 1,
|
|
|
|
OMAP_DISPLAY_TYPE_SDI = 1 << 2,
|
|
|
|
OMAP_DISPLAY_TYPE_DSI = 1 << 3,
|
|
|
|
OMAP_DISPLAY_TYPE_VENC = 1 << 4,
|
2011-03-08 18:45:54 +07:00
|
|
|
OMAP_DISPLAY_TYPE_HDMI = 1 << 5,
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_plane {
|
|
|
|
OMAP_DSS_GFX = 0,
|
|
|
|
OMAP_DSS_VIDEO1 = 1,
|
2011-09-13 19:50:33 +07:00
|
|
|
OMAP_DSS_VIDEO2 = 2,
|
|
|
|
OMAP_DSS_VIDEO3 = 3,
|
2012-08-22 20:57:02 +07:00
|
|
|
OMAP_DSS_WB = 4,
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_channel {
|
|
|
|
OMAP_DSS_CHANNEL_LCD = 0,
|
|
|
|
OMAP_DSS_CHANNEL_DIGIT = 1,
|
OMAP: DSS2: Represent DISPC register defines with channel as parameter
On OMAP4, we have a new DISPC channel for Overlay Manager LCD2. There is a set
of regsiters for LCD2 channel similar to the existing LCD channel, like
DISPC_CONTROL2, DISPC_DIVISOR2, DISPC_CONFIG2 and so on.
Introduce new enum members for LCD2 Channel and corresponding Overlay Manager
in display.h.
Represent the following DISPC register defines with channel as a parameter
to differentiate between LCD and LCD2 registers (and also DIGIT in some cases):
DISPC_DEFAULT_COLOR, DISPC_TRANS_COLOR, DISPC_TIMING_H, DISPC_TIMING_V,
DISPC_POL_FREQ, DISPC_DIVISOR, DISPC_SIZE_LCD, DISPC_DATA_CYCLEk,
DISPC_CPR_COEF_R, DISPC_CPR_COEF_G and DISPC_CPR_COEF_B
This parametrization helps in reducing the number of register defines for DISPC.
Replace the existing reads/writes to these registers in this new way.
Also, Introduce defines for registers DISPC_CONTROL2 and DISPC_CONFIG2 which
are used exclusively for LCD2 channel.
Signed-off-by: Sumit Semwal <sumit.semwal@ti.com>
Signed-off-by: Mukund Mittal <mmittal@ti.com>
Signed-off-by: Samreen <samreen@ti.com>
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@nokia.com>
2010-12-02 18:27:09 +07:00
|
|
|
OMAP_DSS_CHANNEL_LCD2 = 2,
|
2012-06-19 16:38:16 +07:00
|
|
|
OMAP_DSS_CHANNEL_LCD3 = 3,
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_color_mode {
|
|
|
|
OMAP_DSS_COLOR_CLUT1 = 1 << 0, /* BITMAP 1 */
|
|
|
|
OMAP_DSS_COLOR_CLUT2 = 1 << 1, /* BITMAP 2 */
|
|
|
|
OMAP_DSS_COLOR_CLUT4 = 1 << 2, /* BITMAP 4 */
|
|
|
|
OMAP_DSS_COLOR_CLUT8 = 1 << 3, /* BITMAP 8 */
|
|
|
|
OMAP_DSS_COLOR_RGB12U = 1 << 4, /* RGB12, 16-bit container */
|
|
|
|
OMAP_DSS_COLOR_ARGB16 = 1 << 5, /* ARGB16 */
|
|
|
|
OMAP_DSS_COLOR_RGB16 = 1 << 6, /* RGB16 */
|
|
|
|
OMAP_DSS_COLOR_RGB24U = 1 << 7, /* RGB24, 32-bit container */
|
|
|
|
OMAP_DSS_COLOR_RGB24P = 1 << 8, /* RGB24, 24-bit container */
|
|
|
|
OMAP_DSS_COLOR_YUV2 = 1 << 9, /* YUV2 4:2:2 co-sited */
|
|
|
|
OMAP_DSS_COLOR_UYVY = 1 << 10, /* UYVY 4:2:2 co-sited */
|
|
|
|
OMAP_DSS_COLOR_ARGB32 = 1 << 11, /* ARGB32 */
|
|
|
|
OMAP_DSS_COLOR_RGBA32 = 1 << 12, /* RGBA32 */
|
|
|
|
OMAP_DSS_COLOR_RGBX32 = 1 << 13, /* RGBx32 */
|
2011-05-19 21:17:50 +07:00
|
|
|
OMAP_DSS_COLOR_NV12 = 1 << 14, /* NV12 format: YUV 4:2:0 */
|
|
|
|
OMAP_DSS_COLOR_RGBA16 = 1 << 15, /* RGBA16 - 4444 */
|
|
|
|
OMAP_DSS_COLOR_RGBX16 = 1 << 16, /* RGBx16 - 4444 */
|
|
|
|
OMAP_DSS_COLOR_ARGB16_1555 = 1 << 17, /* ARGB16 - 1555 */
|
|
|
|
OMAP_DSS_COLOR_XRGB16_1555 = 1 << 18, /* xRGB16 - 1555 */
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_dss_load_mode {
|
|
|
|
OMAP_DSS_LOAD_CLUT_AND_FRAME = 0,
|
|
|
|
OMAP_DSS_LOAD_CLUT_ONLY = 1,
|
|
|
|
OMAP_DSS_LOAD_FRAME_ONLY = 2,
|
|
|
|
OMAP_DSS_LOAD_CLUT_ONCE_FRAME = 3,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_dss_trans_key_type {
|
|
|
|
OMAP_DSS_COLOR_KEY_GFX_DST = 0,
|
|
|
|
OMAP_DSS_COLOR_KEY_VID_SRC = 1,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_rfbi_te_mode {
|
|
|
|
OMAP_DSS_RFBI_TE_MODE_1 = 1,
|
|
|
|
OMAP_DSS_RFBI_TE_MODE_2 = 2,
|
|
|
|
};
|
|
|
|
|
2012-06-25 13:56:38 +07:00
|
|
|
enum omap_dss_signal_level {
|
|
|
|
OMAPDSS_SIG_ACTIVE_HIGH = 0,
|
|
|
|
OMAPDSS_SIG_ACTIVE_LOW = 1,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_dss_signal_edge {
|
|
|
|
OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
|
|
|
|
OMAPDSS_DRIVE_SIG_RISING_EDGE,
|
|
|
|
OMAPDSS_DRIVE_SIG_FALLING_EDGE,
|
|
|
|
};
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
enum omap_dss_venc_type {
|
|
|
|
OMAP_DSS_VENC_TYPE_COMPOSITE,
|
|
|
|
OMAP_DSS_VENC_TYPE_SVIDEO,
|
|
|
|
};
|
|
|
|
|
2011-09-08 20:12:16 +07:00
|
|
|
enum omap_dss_dsi_pixel_format {
|
|
|
|
OMAP_DSS_DSI_FMT_RGB888,
|
|
|
|
OMAP_DSS_DSI_FMT_RGB666,
|
|
|
|
OMAP_DSS_DSI_FMT_RGB666_PACKED,
|
|
|
|
OMAP_DSS_DSI_FMT_RGB565,
|
|
|
|
};
|
|
|
|
|
2011-07-22 14:15:04 +07:00
|
|
|
enum omap_dss_dsi_mode {
|
|
|
|
OMAP_DSS_DSI_CMD_MODE = 0,
|
|
|
|
OMAP_DSS_DSI_VIDEO_MODE,
|
|
|
|
};
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
enum omap_display_caps {
|
|
|
|
OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE = 1 << 0,
|
|
|
|
OMAP_DSS_DISPLAY_CAP_TEAR_ELIM = 1 << 1,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_dss_display_state {
|
|
|
|
OMAP_DSS_DISPLAY_DISABLED = 0,
|
|
|
|
OMAP_DSS_DISPLAY_ACTIVE,
|
|
|
|
};
|
|
|
|
|
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>
2012-03-07 07:20:37 +07:00
|
|
|
enum omap_dss_audio_state {
|
|
|
|
OMAP_DSS_AUDIO_DISABLED = 0,
|
|
|
|
OMAP_DSS_AUDIO_ENABLED,
|
|
|
|
OMAP_DSS_AUDIO_CONFIGURED,
|
|
|
|
OMAP_DSS_AUDIO_PLAYING,
|
|
|
|
};
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
enum omap_dss_rotation_type {
|
2012-05-11 20:49:55 +07:00
|
|
|
OMAP_DSS_ROT_DMA = 1 << 0,
|
|
|
|
OMAP_DSS_ROT_VRFB = 1 << 1,
|
|
|
|
OMAP_DSS_ROT_TILER = 1 << 2,
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
/* clockwise rotation angle */
|
|
|
|
enum omap_dss_rotation_angle {
|
|
|
|
OMAP_DSS_ROT_0 = 0,
|
|
|
|
OMAP_DSS_ROT_90 = 1,
|
|
|
|
OMAP_DSS_ROT_180 = 2,
|
|
|
|
OMAP_DSS_ROT_270 = 3,
|
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_overlay_caps {
|
|
|
|
OMAP_DSS_OVL_CAP_SCALE = 1 << 0,
|
2011-08-15 19:18:20 +07:00
|
|
|
OMAP_DSS_OVL_CAP_GLOBAL_ALPHA = 1 << 1,
|
|
|
|
OMAP_DSS_OVL_CAP_PRE_MULT_ALPHA = 1 << 2,
|
2011-09-26 13:17:29 +07:00
|
|
|
OMAP_DSS_OVL_CAP_ZORDER = 1 << 3,
|
2012-09-22 14:00:17 +07:00
|
|
|
OMAP_DSS_OVL_CAP_POS = 1 << 4,
|
|
|
|
OMAP_DSS_OVL_CAP_REPLICATION = 1 << 5,
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
enum omap_overlay_manager_caps {
|
2011-08-15 15:22:21 +07:00
|
|
|
OMAP_DSS_DUMMY_VALUE, /* add a dummy value to prevent compiler error */
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
2011-04-12 15:22:23 +07:00
|
|
|
enum omap_dss_clk_source {
|
|
|
|
OMAP_DSS_CLK_SRC_FCK = 0, /* OMAP2/3: DSS1_ALWON_FCLK
|
|
|
|
* OMAP4: DSS_FCLK */
|
|
|
|
OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DISPC, /* OMAP3: DSI1_PLL_FCLK
|
|
|
|
* OMAP4: PLL1_CLK1 */
|
|
|
|
OMAP_DSS_CLK_SRC_DSI_PLL_HSDIV_DSI, /* OMAP3: DSI2_PLL_FCLK
|
|
|
|
* OMAP4: PLL1_CLK2 */
|
2011-05-12 18:56:29 +07:00
|
|
|
OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DISPC, /* OMAP4: PLL2_CLK1 */
|
|
|
|
OMAP_DSS_CLK_SRC_DSI2_PLL_HSDIV_DSI, /* OMAP4: PLL2_CLK2 */
|
2011-04-12 15:22:23 +07:00
|
|
|
};
|
|
|
|
|
2012-01-02 15:32:38 +07:00
|
|
|
enum omap_hdmi_flags {
|
|
|
|
OMAP_HDMI_SDA_SCL_EXTERNAL_PULLUP = 1 << 0,
|
|
|
|
};
|
|
|
|
|
OMAPDSS: outputs: Create a new entity called outputs
The current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to display the content.
The part of DSS hardware which isn't represented by any of the above entities
are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
HDMI, VENC and so on. Currently, an overlay manager directly connects to the
display, and the output to which it is actually connected is ignored. The panel
driver of the display is responsible of calling output specific functions to
configure the output.
Adding outputs as a new software entity gives us the following benefits:
- Have exact information on the possible connections between managers and
outputs: A manager can't connect to each and every output, there only limited
hardware links between a manager's video port and some of the outputs.
- Remove hacks related to connecting managers and devices: Currently, default
links between managers and devices are set in a not so clean way. Matching is
done via comparing the device type, and the display types supported by the
manager. This isn't sufficient to establish all the possible links between
managers, outputs and devices in hardware.
- Make panel drivers more generic: The DSS panel drivers currently call
interface/output specific functions to configure the hardware IP. When making
these calls, the driver isn't actually aware of the underlying output. The
output driver extracts information from the panel's omap_dss_device pointer
to figure out which interface it is connected to, and then configures the
corresponding output block. An example of this is when a DSI panel calls
dsi functions, the dsi driver figures out whether the panel is connected
to DSI1 or DSI2. This isn't correct, and having output as entities will
give the panel driver the exact information on which output to configure.
Having outputs also gives the opportunity to make panel drivers generic
across different platforms/SoCs, this is achieved as omap specific output
calls can be replaced by ops of a particular output type.
- Have more complex connections between managers, outputs and devices: OMAPDSS
currently doesn't support use cases like 2 outputs connect to a single
device. This can be achieved by extending properties of outputs to connect to
more managers or devices.
- Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
as compared to overlays, managers or devices.
Add a new struct to represent outputs. An output struct holds pointers to the
manager and device structs to which it is connected. Add functions which can
register/unregister an output, or look for one. Create an enum which represent
each output instance.
Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-07 19:08:00 +07:00
|
|
|
enum omap_dss_output_id {
|
|
|
|
OMAP_DSS_OUTPUT_DPI = 1 << 0,
|
|
|
|
OMAP_DSS_OUTPUT_DBI = 1 << 1,
|
|
|
|
OMAP_DSS_OUTPUT_SDI = 1 << 2,
|
|
|
|
OMAP_DSS_OUTPUT_DSI1 = 1 << 3,
|
|
|
|
OMAP_DSS_OUTPUT_DSI2 = 1 << 4,
|
|
|
|
OMAP_DSS_OUTPUT_VENC = 1 << 5,
|
|
|
|
OMAP_DSS_OUTPUT_HDMI = 1 << 6,
|
|
|
|
};
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
/* RFBI */
|
|
|
|
|
|
|
|
struct rfbi_timings {
|
|
|
|
int cs_on_time;
|
|
|
|
int cs_off_time;
|
|
|
|
int we_on_time;
|
|
|
|
int we_off_time;
|
|
|
|
int re_on_time;
|
|
|
|
int re_off_time;
|
|
|
|
int we_cycle_time;
|
|
|
|
int re_cycle_time;
|
|
|
|
int cs_pulse_width;
|
|
|
|
int access_time;
|
|
|
|
|
|
|
|
int clk_div;
|
|
|
|
|
|
|
|
u32 tim[5]; /* set by rfbi_convert_timings() */
|
|
|
|
|
|
|
|
int converted;
|
|
|
|
};
|
|
|
|
|
|
|
|
void omap_rfbi_write_command(const void *buf, u32 len);
|
|
|
|
void omap_rfbi_read_data(void *buf, u32 len);
|
|
|
|
void omap_rfbi_write_data(const void *buf, u32 len);
|
|
|
|
void omap_rfbi_write_pixels(const void __iomem *buf, int scr_width,
|
|
|
|
u16 x, u16 y,
|
|
|
|
u16 w, u16 h);
|
|
|
|
int omap_rfbi_enable_te(bool enable, unsigned line);
|
|
|
|
int omap_rfbi_setup_te(enum omap_rfbi_te_mode mode,
|
|
|
|
unsigned hs_pulse_time, unsigned vs_pulse_time,
|
|
|
|
int hs_pol_inv, int vs_pol_inv, int extif_div);
|
2011-04-21 23:50:31 +07:00
|
|
|
void rfbi_bus_lock(void);
|
|
|
|
void rfbi_bus_unlock(void);
|
2009-11-03 16:23:50 +07:00
|
|
|
|
|
|
|
/* DSI */
|
2011-09-05 18:18:27 +07:00
|
|
|
|
2013-03-05 21:29:36 +07:00
|
|
|
enum omap_dss_dsi_trans_mode {
|
|
|
|
/* Sync Pulses: both sync start and end packets sent */
|
|
|
|
OMAP_DSS_DSI_PULSE_MODE,
|
|
|
|
/* Sync Events: only sync start packets sent */
|
|
|
|
OMAP_DSS_DSI_EVENT_MODE,
|
|
|
|
/* Burst: only sync start packets sent, pixels are time compressed */
|
|
|
|
OMAP_DSS_DSI_BURST_MODE,
|
|
|
|
};
|
|
|
|
|
2012-08-13 23:42:24 +07:00
|
|
|
struct omap_dss_dsi_videomode_timings {
|
2013-03-05 22:21:35 +07:00
|
|
|
unsigned long hsclk;
|
|
|
|
|
|
|
|
unsigned ndl;
|
|
|
|
unsigned bitspp;
|
|
|
|
|
|
|
|
/* pixels */
|
|
|
|
u16 hact;
|
|
|
|
/* lines */
|
|
|
|
u16 vact;
|
|
|
|
|
2011-09-05 18:18:27 +07:00
|
|
|
/* DSI video mode blanking data */
|
|
|
|
/* Unit: byte clock cycles */
|
2013-03-05 22:21:35 +07:00
|
|
|
u16 hss;
|
2011-09-05 18:18:27 +07:00
|
|
|
u16 hsa;
|
2013-03-05 22:21:35 +07:00
|
|
|
u16 hse;
|
2011-09-05 18:18:27 +07:00
|
|
|
u16 hfp;
|
|
|
|
u16 hbp;
|
|
|
|
/* Unit: line clocks */
|
|
|
|
u16 vsa;
|
|
|
|
u16 vfp;
|
|
|
|
u16 vbp;
|
|
|
|
|
|
|
|
/* DSI blanking modes */
|
|
|
|
int blanking_mode;
|
|
|
|
int hsa_blanking_mode;
|
|
|
|
int hbp_blanking_mode;
|
|
|
|
int hfp_blanking_mode;
|
|
|
|
|
2013-03-05 21:29:36 +07:00
|
|
|
enum omap_dss_dsi_trans_mode trans_mode;
|
2011-09-05 18:18:27 +07:00
|
|
|
|
|
|
|
bool ddr_clk_always_on;
|
|
|
|
int window_sync;
|
|
|
|
};
|
|
|
|
|
2013-03-06 16:10:29 +07:00
|
|
|
struct omap_dss_dsi_config {
|
|
|
|
enum omap_dss_dsi_mode mode;
|
|
|
|
enum omap_dss_dsi_pixel_format pixel_format;
|
|
|
|
const struct omap_video_timings *timings;
|
|
|
|
|
2013-03-05 22:21:35 +07:00
|
|
|
unsigned long hs_clk_min, hs_clk_max;
|
|
|
|
unsigned long lp_clk_min, lp_clk_max;
|
|
|
|
|
|
|
|
bool ddr_clk_always_on;
|
|
|
|
enum omap_dss_dsi_trans_mode trans_mode;
|
2013-03-06 16:10:29 +07:00
|
|
|
};
|
|
|
|
|
2011-05-12 18:56:24 +07:00
|
|
|
void dsi_bus_lock(struct omap_dss_device *dssdev);
|
|
|
|
void dsi_bus_unlock(struct omap_dss_device *dssdev);
|
|
|
|
int dsi_vc_dcs_write(struct omap_dss_device *dssdev, int channel, u8 *data,
|
|
|
|
int len);
|
2011-08-25 20:05:58 +07:00
|
|
|
int dsi_vc_generic_write(struct omap_dss_device *dssdev, int channel, u8 *data,
|
|
|
|
int len);
|
|
|
|
int dsi_vc_dcs_write_0(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd);
|
|
|
|
int dsi_vc_generic_write_0(struct omap_dss_device *dssdev, int channel);
|
2011-05-12 18:56:24 +07:00
|
|
|
int dsi_vc_dcs_write_1(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd,
|
|
|
|
u8 param);
|
2011-08-25 20:05:58 +07:00
|
|
|
int dsi_vc_generic_write_1(struct omap_dss_device *dssdev, int channel,
|
|
|
|
u8 param);
|
|
|
|
int dsi_vc_generic_write_2(struct omap_dss_device *dssdev, int channel,
|
|
|
|
u8 param1, u8 param2);
|
2011-05-12 18:56:24 +07:00
|
|
|
int dsi_vc_dcs_write_nosync(struct omap_dss_device *dssdev, int channel,
|
|
|
|
u8 *data, int len);
|
2011-08-25 20:05:58 +07:00
|
|
|
int dsi_vc_generic_write_nosync(struct omap_dss_device *dssdev, int channel,
|
|
|
|
u8 *data, int len);
|
2011-05-12 18:56:24 +07:00
|
|
|
int dsi_vc_dcs_read(struct omap_dss_device *dssdev, int channel, u8 dcs_cmd,
|
|
|
|
u8 *buf, int buflen);
|
2011-08-30 17:37:39 +07:00
|
|
|
int dsi_vc_generic_read_0(struct omap_dss_device *dssdev, int channel, u8 *buf,
|
|
|
|
int buflen);
|
|
|
|
int dsi_vc_generic_read_1(struct omap_dss_device *dssdev, int channel, u8 param,
|
|
|
|
u8 *buf, int buflen);
|
|
|
|
int dsi_vc_generic_read_2(struct omap_dss_device *dssdev, int channel,
|
|
|
|
u8 param1, u8 param2, u8 *buf, int buflen);
|
2011-05-12 18:56:24 +07:00
|
|
|
int dsi_vc_set_max_rx_packet_size(struct omap_dss_device *dssdev, int channel,
|
|
|
|
u16 len);
|
|
|
|
int dsi_vc_send_null(struct omap_dss_device *dssdev, int channel);
|
|
|
|
int dsi_vc_send_bta_sync(struct omap_dss_device *dssdev, int channel);
|
2011-11-09 20:30:11 +07:00
|
|
|
int dsi_enable_video_output(struct omap_dss_device *dssdev, int channel);
|
|
|
|
void dsi_disable_video_output(struct omap_dss_device *dssdev, int channel);
|
2009-11-03 16:23:50 +07:00
|
|
|
|
2012-09-28 16:42:28 +07:00
|
|
|
enum omapdss_version {
|
|
|
|
OMAPDSS_VER_UNKNOWN = 0,
|
|
|
|
OMAPDSS_VER_OMAP24xx,
|
|
|
|
OMAPDSS_VER_OMAP34xx_ES1, /* OMAP3430 ES1.0, 2.0 */
|
|
|
|
OMAPDSS_VER_OMAP34xx_ES3, /* OMAP3430 ES3.0+ */
|
|
|
|
OMAPDSS_VER_OMAP3630,
|
|
|
|
OMAPDSS_VER_AM35xx,
|
|
|
|
OMAPDSS_VER_OMAP4430_ES1, /* OMAP4430 ES1.0 */
|
|
|
|
OMAPDSS_VER_OMAP4430_ES2, /* OMAP4430 ES2.0, 2.1, 2.2 */
|
|
|
|
OMAPDSS_VER_OMAP4, /* All other OMAP4s */
|
|
|
|
OMAPDSS_VER_OMAP5,
|
|
|
|
};
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
/* Board specific data */
|
|
|
|
struct omap_dss_board_info {
|
2011-05-23 19:46:54 +07:00
|
|
|
int (*get_context_loss_count)(struct device *dev);
|
2009-11-03 16:23:50 +07:00
|
|
|
int num_devices;
|
|
|
|
struct omap_dss_device **devices;
|
|
|
|
struct omap_dss_device *default_device;
|
2012-11-16 19:59:56 +07:00
|
|
|
const char *default_display_name;
|
2011-06-15 19:21:12 +07:00
|
|
|
int (*dsi_enable_pads)(int dsi_id, unsigned lane_mask);
|
|
|
|
void (*dsi_disable_pads)(int dsi_id, unsigned lane_mask);
|
2012-03-08 17:37:58 +07:00
|
|
|
int (*set_min_bus_tput)(struct device *dev, unsigned long r);
|
2012-09-28 16:42:28 +07:00
|
|
|
enum omapdss_version version;
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
2011-01-24 13:21:54 +07:00
|
|
|
/* Init with the board info */
|
|
|
|
extern int omap_display_init(struct omap_dss_board_info *board_data);
|
2012-01-02 15:32:37 +07:00
|
|
|
/* HDMI mux init*/
|
2012-01-02 15:32:38 +07:00
|
|
|
extern int omap_hdmi_init(enum omap_hdmi_flags flags);
|
2011-01-24 13:21:54 +07:00
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
struct omap_video_timings {
|
|
|
|
/* Unit: pixels */
|
|
|
|
u16 x_res;
|
|
|
|
/* Unit: pixels */
|
|
|
|
u16 y_res;
|
|
|
|
/* Unit: KHz */
|
|
|
|
u32 pixel_clock;
|
|
|
|
/* Unit: pixel clocks */
|
|
|
|
u16 hsw; /* Horizontal synchronization pulse width */
|
|
|
|
/* Unit: pixel clocks */
|
|
|
|
u16 hfp; /* Horizontal front porch */
|
|
|
|
/* Unit: pixel clocks */
|
|
|
|
u16 hbp; /* Horizontal back porch */
|
|
|
|
/* Unit: line clocks */
|
|
|
|
u16 vsw; /* Vertical synchronization pulse width */
|
|
|
|
/* Unit: line clocks */
|
|
|
|
u16 vfp; /* Vertical front porch */
|
|
|
|
/* Unit: line clocks */
|
|
|
|
u16 vbp; /* Vertical back porch */
|
2012-06-25 13:56:38 +07:00
|
|
|
|
|
|
|
/* Vsync logic level */
|
|
|
|
enum omap_dss_signal_level vsync_level;
|
|
|
|
/* Hsync logic level */
|
|
|
|
enum omap_dss_signal_level hsync_level;
|
2012-06-28 12:45:51 +07:00
|
|
|
/* Interlaced or Progressive timings */
|
|
|
|
bool interlace;
|
2012-06-25 13:56:38 +07:00
|
|
|
/* Pixel clock edge to drive LCD data */
|
|
|
|
enum omap_dss_signal_edge data_pclk_edge;
|
|
|
|
/* Data enable logic level */
|
|
|
|
enum omap_dss_signal_level de_level;
|
|
|
|
/* Pixel clock edges to drive HSYNC and VSYNC signals */
|
|
|
|
enum omap_dss_signal_edge sync_pclk_edge;
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
#ifdef CONFIG_OMAP2_DSS_VENC
|
|
|
|
/* Hardcoded timings for tv modes. Venc only uses these to
|
|
|
|
* identify the mode, and does not actually use the configs
|
|
|
|
* itself. However, the configs should be something that
|
|
|
|
* a normal monitor can also show */
|
2010-05-20 22:12:52 +07:00
|
|
|
extern const struct omap_video_timings omap_dss_pal_timings;
|
|
|
|
extern const struct omap_video_timings omap_dss_ntsc_timings;
|
2009-11-03 16:23:50 +07:00
|
|
|
#endif
|
|
|
|
|
2011-06-21 13:34:30 +07:00
|
|
|
struct omap_dss_cpr_coefs {
|
|
|
|
s16 rr, rg, rb;
|
|
|
|
s16 gr, gg, gb;
|
|
|
|
s16 br, bg, bb;
|
|
|
|
};
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
struct omap_overlay_info {
|
|
|
|
u32 paddr;
|
2011-05-19 21:17:54 +07:00
|
|
|
u32 p_uv_addr; /* for NV12 format */
|
2009-11-03 16:23:50 +07:00
|
|
|
u16 screen_width;
|
|
|
|
u16 width;
|
|
|
|
u16 height;
|
|
|
|
enum omap_color_mode color_mode;
|
|
|
|
u8 rotation;
|
|
|
|
enum omap_dss_rotation_type rotation_type;
|
|
|
|
bool mirror;
|
|
|
|
|
|
|
|
u16 pos_x;
|
|
|
|
u16 pos_y;
|
|
|
|
u16 out_width; /* if 0, out_width == width */
|
|
|
|
u16 out_height; /* if 0, out_height == height */
|
|
|
|
u8 global_alpha;
|
2010-11-04 18:28:42 +07:00
|
|
|
u8 pre_mult_alpha;
|
2011-09-08 12:59:17 +07:00
|
|
|
u8 zorder;
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
struct omap_overlay {
|
|
|
|
struct kobject kobj;
|
|
|
|
struct list_head list;
|
|
|
|
|
|
|
|
/* static fields */
|
|
|
|
const char *name;
|
2011-08-15 15:22:21 +07:00
|
|
|
enum omap_plane id;
|
2009-11-03 16:23:50 +07:00
|
|
|
enum omap_color_mode supported_modes;
|
|
|
|
enum omap_overlay_caps caps;
|
|
|
|
|
|
|
|
/* dynamic fields */
|
|
|
|
struct omap_overlay_manager *manager;
|
|
|
|
|
2011-11-18 17:38:38 +07:00
|
|
|
/*
|
|
|
|
* The following functions do not block:
|
|
|
|
*
|
|
|
|
* is_enabled
|
|
|
|
* set_overlay_info
|
|
|
|
* get_overlay_info
|
|
|
|
*
|
|
|
|
* The rest of the functions may block and cannot be called from
|
|
|
|
* interrupt context
|
|
|
|
*/
|
|
|
|
|
OMAPDSS: APPLY: rewrite overlay enable/disable
Overlays are currently enabled and disabled with a boolean in the struct
omap_overlay_info. The overlay info is set with ovl->set_overlay_info(),
and made into use with mgr->apply().
This doesn't work properly, as the enable/disable status may affect also
other overlays, for example when using fifo-merge. Thus the enabling and
disabling of the overlay needs to be done outside the normal overlay
configuration.
This patch achieves that by doing the following things:
1) Add function pointers to struct omap_overlay: enable(), disable() and
is_enabled(). These are used to do the obvious. The functions may block.
2) Move the "enabled" field from struct omap_overlay to ovl_priv_data.
3) Add a new route for settings to be applied to the HW, called
"extra_info". The status of the normal info and extra_info are tracked
separately.
The point here is to allow the normal info to be changed and
applied in non-blocking matter, whereas the extra_info can only be
changed when holding the mutex. This makes it possible to, for example,
set the overlay enable flag, apply it, and wait until the HW has taken
the flag into use.
This is not possible if the enable flag would be in the normal info, as
a new value for the flag could be set at any time from the users of
omapdss.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2011-11-15 21:37:53 +07:00
|
|
|
int (*enable)(struct omap_overlay *ovl);
|
|
|
|
int (*disable)(struct omap_overlay *ovl);
|
|
|
|
bool (*is_enabled)(struct omap_overlay *ovl);
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
int (*set_manager)(struct omap_overlay *ovl,
|
|
|
|
struct omap_overlay_manager *mgr);
|
|
|
|
int (*unset_manager)(struct omap_overlay *ovl);
|
|
|
|
|
|
|
|
int (*set_overlay_info)(struct omap_overlay *ovl,
|
|
|
|
struct omap_overlay_info *info);
|
|
|
|
void (*get_overlay_info)(struct omap_overlay *ovl,
|
|
|
|
struct omap_overlay_info *info);
|
|
|
|
|
|
|
|
int (*wait_for_go)(struct omap_overlay *ovl);
|
2012-09-07 19:14:51 +07:00
|
|
|
|
|
|
|
struct omap_dss_device *(*get_device)(struct omap_overlay *ovl);
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
struct omap_overlay_manager_info {
|
|
|
|
u32 default_color;
|
|
|
|
|
|
|
|
enum omap_dss_trans_key_type trans_key_type;
|
|
|
|
u32 trans_key;
|
|
|
|
bool trans_enabled;
|
|
|
|
|
2011-09-26 13:17:29 +07:00
|
|
|
bool partial_alpha_enabled;
|
2011-06-21 13:34:30 +07:00
|
|
|
|
|
|
|
bool cpr_enable;
|
|
|
|
struct omap_dss_cpr_coefs cpr_coefs;
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
struct omap_overlay_manager {
|
|
|
|
struct kobject kobj;
|
|
|
|
|
|
|
|
/* static fields */
|
|
|
|
const char *name;
|
2011-08-15 15:22:21 +07:00
|
|
|
enum omap_channel id;
|
2009-11-03 16:23:50 +07:00
|
|
|
enum omap_overlay_manager_caps caps;
|
2011-11-05 15:59:59 +07:00
|
|
|
struct list_head overlays;
|
2009-11-03 16:23:50 +07:00
|
|
|
enum omap_display_type supported_displays;
|
2012-09-26 18:12:39 +07:00
|
|
|
enum omap_dss_output_id supported_outputs;
|
2009-11-03 16:23:50 +07:00
|
|
|
|
|
|
|
/* dynamic fields */
|
2012-09-26 18:12:39 +07:00
|
|
|
struct omap_dss_output *output;
|
2009-11-03 16:23:50 +07:00
|
|
|
|
2011-11-18 17:38:38 +07:00
|
|
|
/*
|
|
|
|
* The following functions do not block:
|
|
|
|
*
|
|
|
|
* set_manager_info
|
|
|
|
* get_manager_info
|
|
|
|
* apply
|
|
|
|
*
|
|
|
|
* The rest of the functions may block and cannot be called from
|
|
|
|
* interrupt context
|
|
|
|
*/
|
|
|
|
|
2012-09-26 18:12:39 +07:00
|
|
|
int (*set_output)(struct omap_overlay_manager *mgr,
|
|
|
|
struct omap_dss_output *output);
|
|
|
|
int (*unset_output)(struct omap_overlay_manager *mgr);
|
2009-11-03 16:23:50 +07:00
|
|
|
|
|
|
|
int (*set_manager_info)(struct omap_overlay_manager *mgr,
|
|
|
|
struct omap_overlay_manager_info *info);
|
|
|
|
void (*get_manager_info)(struct omap_overlay_manager *mgr,
|
|
|
|
struct omap_overlay_manager_info *info);
|
|
|
|
|
|
|
|
int (*apply)(struct omap_overlay_manager *mgr);
|
|
|
|
int (*wait_for_go)(struct omap_overlay_manager *mgr);
|
2010-01-08 22:06:04 +07:00
|
|
|
int (*wait_for_vsync)(struct omap_overlay_manager *mgr);
|
2012-09-07 19:14:51 +07:00
|
|
|
|
|
|
|
struct omap_dss_device *(*get_device)(struct omap_overlay_manager *mgr);
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
2012-03-28 19:58:56 +07:00
|
|
|
/* 22 pins means 1 clk lane and 10 data lanes */
|
|
|
|
#define OMAP_DSS_MAX_DSI_PINS 22
|
|
|
|
|
|
|
|
struct omap_dsi_pin_config {
|
|
|
|
int num_pins;
|
|
|
|
/*
|
|
|
|
* pin numbers in the following order:
|
|
|
|
* clk+, clk-
|
|
|
|
* data1+, data1-
|
|
|
|
* data2+, data2-
|
|
|
|
* ...
|
|
|
|
*/
|
|
|
|
int pins[OMAP_DSS_MAX_DSI_PINS];
|
|
|
|
};
|
|
|
|
|
2012-08-31 14:02:52 +07:00
|
|
|
struct omap_dss_writeback_info {
|
|
|
|
u32 paddr;
|
|
|
|
u32 p_uv_addr;
|
|
|
|
u16 buf_width;
|
|
|
|
u16 width;
|
|
|
|
u16 height;
|
|
|
|
enum omap_color_mode color_mode;
|
|
|
|
u8 rotation;
|
|
|
|
enum omap_dss_rotation_type rotation_type;
|
|
|
|
bool mirror;
|
|
|
|
u8 pre_mult_alpha;
|
|
|
|
};
|
|
|
|
|
OMAPDSS: outputs: Create a new entity called outputs
The current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to display the content.
The part of DSS hardware which isn't represented by any of the above entities
are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
HDMI, VENC and so on. Currently, an overlay manager directly connects to the
display, and the output to which it is actually connected is ignored. The panel
driver of the display is responsible of calling output specific functions to
configure the output.
Adding outputs as a new software entity gives us the following benefits:
- Have exact information on the possible connections between managers and
outputs: A manager can't connect to each and every output, there only limited
hardware links between a manager's video port and some of the outputs.
- Remove hacks related to connecting managers and devices: Currently, default
links between managers and devices are set in a not so clean way. Matching is
done via comparing the device type, and the display types supported by the
manager. This isn't sufficient to establish all the possible links between
managers, outputs and devices in hardware.
- Make panel drivers more generic: The DSS panel drivers currently call
interface/output specific functions to configure the hardware IP. When making
these calls, the driver isn't actually aware of the underlying output. The
output driver extracts information from the panel's omap_dss_device pointer
to figure out which interface it is connected to, and then configures the
corresponding output block. An example of this is when a DSI panel calls
dsi functions, the dsi driver figures out whether the panel is connected
to DSI1 or DSI2. This isn't correct, and having output as entities will
give the panel driver the exact information on which output to configure.
Having outputs also gives the opportunity to make panel drivers generic
across different platforms/SoCs, this is achieved as omap specific output
calls can be replaced by ops of a particular output type.
- Have more complex connections between managers, outputs and devices: OMAPDSS
currently doesn't support use cases like 2 outputs connect to a single
device. This can be achieved by extending properties of outputs to connect to
more managers or devices.
- Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
as compared to overlays, managers or devices.
Add a new struct to represent outputs. An output struct holds pointers to the
manager and device structs to which it is connected. Add functions which can
register/unregister an output, or look for one. Create an enum which represent
each output instance.
Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-07 19:08:00 +07:00
|
|
|
struct omap_dss_output {
|
|
|
|
struct list_head list;
|
|
|
|
|
2013-02-18 18:06:01 +07:00
|
|
|
const char *name;
|
|
|
|
|
OMAPDSS: outputs: Create a new entity called outputs
The current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to display the content.
The part of DSS hardware which isn't represented by any of the above entities
are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
HDMI, VENC and so on. Currently, an overlay manager directly connects to the
display, and the output to which it is actually connected is ignored. The panel
driver of the display is responsible of calling output specific functions to
configure the output.
Adding outputs as a new software entity gives us the following benefits:
- Have exact information on the possible connections between managers and
outputs: A manager can't connect to each and every output, there only limited
hardware links between a manager's video port and some of the outputs.
- Remove hacks related to connecting managers and devices: Currently, default
links between managers and devices are set in a not so clean way. Matching is
done via comparing the device type, and the display types supported by the
manager. This isn't sufficient to establish all the possible links between
managers, outputs and devices in hardware.
- Make panel drivers more generic: The DSS panel drivers currently call
interface/output specific functions to configure the hardware IP. When making
these calls, the driver isn't actually aware of the underlying output. The
output driver extracts information from the panel's omap_dss_device pointer
to figure out which interface it is connected to, and then configures the
corresponding output block. An example of this is when a DSI panel calls
dsi functions, the dsi driver figures out whether the panel is connected
to DSI1 or DSI2. This isn't correct, and having output as entities will
give the panel driver the exact information on which output to configure.
Having outputs also gives the opportunity to make panel drivers generic
across different platforms/SoCs, this is achieved as omap specific output
calls can be replaced by ops of a particular output type.
- Have more complex connections between managers, outputs and devices: OMAPDSS
currently doesn't support use cases like 2 outputs connect to a single
device. This can be achieved by extending properties of outputs to connect to
more managers or devices.
- Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
as compared to overlays, managers or devices.
Add a new struct to represent outputs. An output struct holds pointers to the
manager and device structs to which it is connected. Add functions which can
register/unregister an output, or look for one. Create an enum which represent
each output instance.
Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-07 19:08:00 +07:00
|
|
|
/* display type supported by the output */
|
|
|
|
enum omap_display_type type;
|
|
|
|
|
2013-02-13 16:23:54 +07:00
|
|
|
/* DISPC channel for this output */
|
|
|
|
enum omap_channel dispc_channel;
|
|
|
|
|
OMAPDSS: outputs: Create a new entity called outputs
The current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to display the content.
The part of DSS hardware which isn't represented by any of the above entities
are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
HDMI, VENC and so on. Currently, an overlay manager directly connects to the
display, and the output to which it is actually connected is ignored. The panel
driver of the display is responsible of calling output specific functions to
configure the output.
Adding outputs as a new software entity gives us the following benefits:
- Have exact information on the possible connections between managers and
outputs: A manager can't connect to each and every output, there only limited
hardware links between a manager's video port and some of the outputs.
- Remove hacks related to connecting managers and devices: Currently, default
links between managers and devices are set in a not so clean way. Matching is
done via comparing the device type, and the display types supported by the
manager. This isn't sufficient to establish all the possible links between
managers, outputs and devices in hardware.
- Make panel drivers more generic: The DSS panel drivers currently call
interface/output specific functions to configure the hardware IP. When making
these calls, the driver isn't actually aware of the underlying output. The
output driver extracts information from the panel's omap_dss_device pointer
to figure out which interface it is connected to, and then configures the
corresponding output block. An example of this is when a DSI panel calls
dsi functions, the dsi driver figures out whether the panel is connected
to DSI1 or DSI2. This isn't correct, and having output as entities will
give the panel driver the exact information on which output to configure.
Having outputs also gives the opportunity to make panel drivers generic
across different platforms/SoCs, this is achieved as omap specific output
calls can be replaced by ops of a particular output type.
- Have more complex connections between managers, outputs and devices: OMAPDSS
currently doesn't support use cases like 2 outputs connect to a single
device. This can be achieved by extending properties of outputs to connect to
more managers or devices.
- Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
as compared to overlays, managers or devices.
Add a new struct to represent outputs. An output struct holds pointers to the
manager and device structs to which it is connected. Add functions which can
register/unregister an output, or look for one. Create an enum which represent
each output instance.
Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-07 19:08:00 +07:00
|
|
|
/* output instance */
|
|
|
|
enum omap_dss_output_id id;
|
|
|
|
|
|
|
|
/* output's platform device pointer */
|
|
|
|
struct platform_device *pdev;
|
|
|
|
|
|
|
|
/* dynamic fields */
|
|
|
|
struct omap_overlay_manager *manager;
|
|
|
|
|
|
|
|
struct omap_dss_device *device;
|
|
|
|
};
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
struct omap_dss_device {
|
OMAPDSS: Add panel dev pointer to dssdev
We are about to remove the dss bus support, which also means that the
omap_dss_device won't be a real device anymore. This means that the
embedded "dev" struct needs to be removed from omap_dss_device.
After we've finished the removal of the dss bus, we see the following
changes:
- struct omap_dss_device won't be a real Linux device anymore, but more
like a "display entity".
- struct omap_dss_driver won't be a Linux device driver, but "display
entity ops".
- The panel devices/drivers won't be omapdss devices/drivers, but
platform/i2c/spi/etc devices/drivers, whichever fits the control
mechanism of the panel.
- The panel drivers will create omap_dss_device and omap_dss_driver,
fill the required fields, and register the omap_dss_device to
omapdss.
- omap_dss_device won't have an embedded dev struct anymore, but a
dev pointer to the actual device that manages the omap_dss_device.
The model described above resembles the model that has been discussed
with CDF (common display framework).
For the duration of the conversion, we temporarily have two devs in the
dssdev, the old "old_dev", which is a full embedded device struct, and the
new "dev", which is a pointer to the device. "old_dev" will be removed
in the future.
For devices belonging to dss bus the dev is initialized to point to
old_dev. This way all the code can just use the dev, for both old and
new style panels.
Both the new and old style panel drivers work during the conversion, and
only after the dss bus support is removed will the old style panels stop
to compile.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-02-14 19:17:28 +07:00
|
|
|
/* old device, to be removed */
|
|
|
|
struct device old_dev;
|
|
|
|
|
|
|
|
/* new device, pointer to panel device */
|
|
|
|
struct device *dev;
|
2009-11-03 16:23:50 +07:00
|
|
|
|
2012-11-16 20:45:26 +07:00
|
|
|
struct list_head panel_list;
|
|
|
|
|
|
|
|
/* alias in the form of "display%d" */
|
|
|
|
char alias[16];
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
enum omap_display_type type;
|
|
|
|
|
2013-02-13 16:23:54 +07:00
|
|
|
/* obsolete, to be removed */
|
2010-12-02 18:27:14 +07:00
|
|
|
enum omap_channel channel;
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
union {
|
|
|
|
struct {
|
|
|
|
u8 data_lines;
|
|
|
|
} dpi;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
u8 channel;
|
|
|
|
u8 data_lines;
|
|
|
|
} rfbi;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
u8 datapairs;
|
|
|
|
} sdi;
|
|
|
|
|
|
|
|
struct {
|
2011-05-12 18:56:26 +07:00
|
|
|
int module;
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
bool ext_te;
|
|
|
|
u8 ext_te_gpio;
|
|
|
|
} dsi;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
enum omap_dss_venc_type type;
|
|
|
|
bool invert_polarity;
|
|
|
|
} venc;
|
|
|
|
} phy;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
struct omap_video_timings timings;
|
|
|
|
|
2011-09-08 20:12:16 +07:00
|
|
|
enum omap_dss_dsi_pixel_format dsi_pix_fmt;
|
2011-07-22 14:15:04 +07:00
|
|
|
enum omap_dss_dsi_mode dsi_mode;
|
2009-11-03 16:23:50 +07:00
|
|
|
} panel;
|
|
|
|
|
|
|
|
struct {
|
|
|
|
u8 pixel_size;
|
|
|
|
struct rfbi_timings rfbi_timings;
|
|
|
|
} ctrl;
|
|
|
|
|
|
|
|
int reset_gpio;
|
|
|
|
|
|
|
|
int max_backlight_level;
|
|
|
|
|
|
|
|
const char *name;
|
|
|
|
|
|
|
|
/* used to match device to driver */
|
|
|
|
const char *driver_name;
|
|
|
|
|
|
|
|
void *data;
|
|
|
|
|
|
|
|
struct omap_dss_driver *driver;
|
|
|
|
|
|
|
|
/* helper variable for driver suspend/resume */
|
|
|
|
bool activate_after_resume;
|
|
|
|
|
|
|
|
enum omap_display_caps caps;
|
|
|
|
|
2012-08-29 15:00:15 +07:00
|
|
|
struct omap_dss_output *output;
|
2009-11-03 16:23:50 +07:00
|
|
|
|
|
|
|
enum omap_dss_display_state state;
|
|
|
|
|
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>
2012-03-07 07:20:37 +07:00
|
|
|
enum omap_dss_audio_state audio_state;
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
/* platform specific */
|
|
|
|
int (*platform_enable)(struct omap_dss_device *dssdev);
|
|
|
|
void (*platform_disable)(struct omap_dss_device *dssdev);
|
|
|
|
int (*set_backlight)(struct omap_dss_device *dssdev, int level);
|
|
|
|
int (*get_backlight)(struct omap_dss_device *dssdev);
|
|
|
|
};
|
|
|
|
|
OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.
The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.
The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
"ticking" and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-01-17 16:09:57 +07:00
|
|
|
struct omap_dss_hdmi_data
|
|
|
|
{
|
2012-04-26 18:48:32 +07:00
|
|
|
int ct_cp_hpd_gpio;
|
|
|
|
int ls_oe_gpio;
|
OMAPDSS: HDMI: PHY burnout fix
A hardware bug in the OMAP4 HDMI PHY causes physical damage to the board
if the HDMI PHY is kept powered on when the cable is not connected.
This patch solves the problem by adding hot-plug-detection into the HDMI
IP driver. This is not a real HPD support in the sense that nobody else
than the IP driver gets to know about the HPD events, but is only meant
to fix the HW bug.
The strategy is simple: If the display device is turned off by the user,
the PHY power is set to OFF. When the display device is turned on by the
user, the PHY power is set either to LDOON or TXON, depending on whether
the HDMI cable is connected.
The reason to avoid PHY OFF when the display device is on, but the cable
is disconnected, is that when the PHY is turned OFF, the HDMI IP is not
"ticking" and thus the DISPC does not receive pixel clock from the HDMI
IP. This would, for example, prevent any VSYNCs from happening, and
would thus affect the users of omapdss. By using LDOON when the cable is
disconnected we'll avoid the HW bug, but keep the HDMI working as usual
from the user's point of view.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2012-01-17 16:09:57 +07:00
|
|
|
int hpd_gpio;
|
|
|
|
};
|
|
|
|
|
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>
2012-03-07 07:20:37 +07:00
|
|
|
struct omap_dss_audio {
|
|
|
|
struct snd_aes_iec958 *iec;
|
|
|
|
struct snd_cea_861_aud_if *cea;
|
|
|
|
};
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
struct omap_dss_driver {
|
|
|
|
struct device_driver driver;
|
|
|
|
|
|
|
|
int (*probe)(struct omap_dss_device *);
|
|
|
|
void (*remove)(struct omap_dss_device *);
|
|
|
|
|
OMAPDSS: Implement display (dis)connect support
We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.
This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.
To support that kind of scenarios, we need to add new step to the
initialization: connect.
This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.
One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.
This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-08 20:23:32 +07:00
|
|
|
int (*connect)(struct omap_dss_device *dssdev);
|
|
|
|
void (*disconnect)(struct omap_dss_device *dssdev);
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
int (*enable)(struct omap_dss_device *display);
|
|
|
|
void (*disable)(struct omap_dss_device *display);
|
|
|
|
int (*run_test)(struct omap_dss_device *display, int test);
|
|
|
|
|
2010-01-12 19:16:41 +07:00
|
|
|
int (*update)(struct omap_dss_device *dssdev,
|
|
|
|
u16 x, u16 y, u16 w, u16 h);
|
|
|
|
int (*sync)(struct omap_dss_device *dssdev);
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
int (*enable_te)(struct omap_dss_device *dssdev, bool enable);
|
2010-01-11 20:11:01 +07:00
|
|
|
int (*get_te)(struct omap_dss_device *dssdev);
|
2009-11-03 16:23:50 +07:00
|
|
|
|
|
|
|
u8 (*get_rotate)(struct omap_dss_device *dssdev);
|
|
|
|
int (*set_rotate)(struct omap_dss_device *dssdev, u8 rotate);
|
|
|
|
|
|
|
|
bool (*get_mirror)(struct omap_dss_device *dssdev);
|
|
|
|
int (*set_mirror)(struct omap_dss_device *dssdev, bool enable);
|
|
|
|
|
|
|
|
int (*memory_read)(struct omap_dss_device *dssdev,
|
|
|
|
void *buf, size_t size,
|
|
|
|
u16 x, u16 y, u16 w, u16 h);
|
2010-01-11 18:54:33 +07:00
|
|
|
|
|
|
|
void (*get_resolution)(struct omap_dss_device *dssdev,
|
|
|
|
u16 *xres, u16 *yres);
|
2010-06-16 19:26:36 +07:00
|
|
|
void (*get_dimensions)(struct omap_dss_device *dssdev,
|
|
|
|
u32 *width, u32 *height);
|
2010-01-11 19:33:40 +07:00
|
|
|
int (*get_recommended_bpp)(struct omap_dss_device *dssdev);
|
2010-01-19 20:53:16 +07:00
|
|
|
|
2010-01-20 17:11:25 +07:00
|
|
|
int (*check_timings)(struct omap_dss_device *dssdev,
|
|
|
|
struct omap_video_timings *timings);
|
|
|
|
void (*set_timings)(struct omap_dss_device *dssdev,
|
|
|
|
struct omap_video_timings *timings);
|
|
|
|
void (*get_timings)(struct omap_dss_device *dssdev,
|
|
|
|
struct omap_video_timings *timings);
|
|
|
|
|
2010-01-19 20:53:16 +07:00
|
|
|
int (*set_wss)(struct omap_dss_device *dssdev, u32 wss);
|
|
|
|
u32 (*get_wss)(struct omap_dss_device *dssdev);
|
2011-08-25 21:10:41 +07:00
|
|
|
|
|
|
|
int (*read_edid)(struct omap_dss_device *dssdev, u8 *buf, int len);
|
2011-08-29 21:26:01 +07:00
|
|
|
bool (*detect)(struct omap_dss_device *dssdev);
|
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>
2012-03-07 07:20:37 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* For display drivers that support audio. This encompasses
|
|
|
|
* HDMI and DisplayPort at the moment.
|
|
|
|
*/
|
|
|
|
/*
|
|
|
|
* Note: These functions might sleep. Do not call while
|
|
|
|
* holding a spinlock/readlock.
|
|
|
|
*/
|
|
|
|
int (*audio_enable)(struct omap_dss_device *dssdev);
|
|
|
|
void (*audio_disable)(struct omap_dss_device *dssdev);
|
|
|
|
bool (*audio_supported)(struct omap_dss_device *dssdev);
|
|
|
|
int (*audio_config)(struct omap_dss_device *dssdev,
|
|
|
|
struct omap_dss_audio *audio);
|
|
|
|
/* Note: These functions may not sleep */
|
|
|
|
int (*audio_start)(struct omap_dss_device *dssdev);
|
|
|
|
void (*audio_stop)(struct omap_dss_device *dssdev);
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
};
|
|
|
|
|
2012-10-18 17:46:29 +07:00
|
|
|
enum omapdss_version omapdss_get_version(void);
|
2013-05-23 16:07:50 +07:00
|
|
|
bool omapdss_is_initialized(void);
|
2012-10-18 17:46:29 +07:00
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
int omap_dss_register_driver(struct omap_dss_driver *);
|
|
|
|
void omap_dss_unregister_driver(struct omap_dss_driver *);
|
|
|
|
|
2012-11-16 20:45:26 +07:00
|
|
|
int omapdss_register_display(struct omap_dss_device *dssdev);
|
|
|
|
void omapdss_unregister_display(struct omap_dss_device *dssdev);
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
void omap_dss_get_device(struct omap_dss_device *dssdev);
|
|
|
|
void omap_dss_put_device(struct omap_dss_device *dssdev);
|
|
|
|
#define for_each_dss_dev(d) while ((d = omap_dss_get_next_device(d)) != NULL)
|
|
|
|
struct omap_dss_device *omap_dss_get_next_device(struct omap_dss_device *from);
|
|
|
|
struct omap_dss_device *omap_dss_find_device(void *data,
|
|
|
|
int (*match)(struct omap_dss_device *dssdev, void *data));
|
2012-10-29 17:40:46 +07:00
|
|
|
const char *omapdss_get_default_display_name(void);
|
2009-11-03 16:23:50 +07:00
|
|
|
|
2013-05-10 17:02:32 +07:00
|
|
|
void videomode_to_omap_video_timings(const struct videomode *vm,
|
|
|
|
struct omap_video_timings *ovt);
|
|
|
|
void omap_video_timings_to_videomode(const struct omap_video_timings *ovt,
|
|
|
|
struct videomode *vm);
|
|
|
|
|
2012-11-07 21:26:11 +07:00
|
|
|
int dss_feat_get_num_mgrs(void);
|
|
|
|
int dss_feat_get_num_ovls(void);
|
|
|
|
enum omap_display_type dss_feat_get_supported_displays(enum omap_channel channel);
|
|
|
|
enum omap_dss_output_id dss_feat_get_supported_outputs(enum omap_channel channel);
|
|
|
|
enum omap_color_mode dss_feat_get_supported_color_modes(enum omap_plane plane);
|
|
|
|
|
|
|
|
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
int omap_dss_get_num_overlay_managers(void);
|
|
|
|
struct omap_overlay_manager *omap_dss_get_overlay_manager(int num);
|
|
|
|
|
|
|
|
int omap_dss_get_num_overlays(void);
|
|
|
|
struct omap_overlay *omap_dss_get_overlay(int num);
|
|
|
|
|
OMAPDSS: outputs: Create a new entity called outputs
The current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to display the content.
The part of DSS hardware which isn't represented by any of the above entities
are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
HDMI, VENC and so on. Currently, an overlay manager directly connects to the
display, and the output to which it is actually connected is ignored. The panel
driver of the display is responsible of calling output specific functions to
configure the output.
Adding outputs as a new software entity gives us the following benefits:
- Have exact information on the possible connections between managers and
outputs: A manager can't connect to each and every output, there only limited
hardware links between a manager's video port and some of the outputs.
- Remove hacks related to connecting managers and devices: Currently, default
links between managers and devices are set in a not so clean way. Matching is
done via comparing the device type, and the display types supported by the
manager. This isn't sufficient to establish all the possible links between
managers, outputs and devices in hardware.
- Make panel drivers more generic: The DSS panel drivers currently call
interface/output specific functions to configure the hardware IP. When making
these calls, the driver isn't actually aware of the underlying output. The
output driver extracts information from the panel's omap_dss_device pointer
to figure out which interface it is connected to, and then configures the
corresponding output block. An example of this is when a DSI panel calls
dsi functions, the dsi driver figures out whether the panel is connected
to DSI1 or DSI2. This isn't correct, and having output as entities will
give the panel driver the exact information on which output to configure.
Having outputs also gives the opportunity to make panel drivers generic
across different platforms/SoCs, this is achieved as omap specific output
calls can be replaced by ops of a particular output type.
- Have more complex connections between managers, outputs and devices: OMAPDSS
currently doesn't support use cases like 2 outputs connect to a single
device. This can be achieved by extending properties of outputs to connect to
more managers or devices.
- Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
as compared to overlays, managers or devices.
Add a new struct to represent outputs. An output struct holds pointers to the
manager and device structs to which it is connected. Add functions which can
register/unregister an output, or look for one. Create an enum which represent
each output instance.
Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-07 19:08:00 +07:00
|
|
|
struct omap_dss_output *omap_dss_get_output(enum omap_dss_output_id id);
|
2013-03-13 18:56:42 +07:00
|
|
|
struct omap_dss_output *omap_dss_find_output(const char *name);
|
2013-03-13 19:22:30 +07:00
|
|
|
struct omap_dss_output *omap_dss_find_output_by_node(struct device_node *node);
|
2012-08-29 15:00:15 +07:00
|
|
|
int omapdss_output_set_device(struct omap_dss_output *out,
|
|
|
|
struct omap_dss_device *dssdev);
|
|
|
|
int omapdss_output_unset_device(struct omap_dss_output *out);
|
OMAPDSS: outputs: Create a new entity called outputs
The current OMAPDSS design contains 3 software entities: Overlays, Managers and
Devices. These map to pipelines, overlay managers and the panels respectively in
hardware. One or more overlays connect to a manager to represent a composition,
the manager connects to a device(generally a display) to display the content.
The part of DSS hardware which isn't represented by any of the above entities
are interfaces/outputs that connect to an overlay manager, i.e blocks like DSI,
HDMI, VENC and so on. Currently, an overlay manager directly connects to the
display, and the output to which it is actually connected is ignored. The panel
driver of the display is responsible of calling output specific functions to
configure the output.
Adding outputs as a new software entity gives us the following benefits:
- Have exact information on the possible connections between managers and
outputs: A manager can't connect to each and every output, there only limited
hardware links between a manager's video port and some of the outputs.
- Remove hacks related to connecting managers and devices: Currently, default
links between managers and devices are set in a not so clean way. Matching is
done via comparing the device type, and the display types supported by the
manager. This isn't sufficient to establish all the possible links between
managers, outputs and devices in hardware.
- Make panel drivers more generic: The DSS panel drivers currently call
interface/output specific functions to configure the hardware IP. When making
these calls, the driver isn't actually aware of the underlying output. The
output driver extracts information from the panel's omap_dss_device pointer
to figure out which interface it is connected to, and then configures the
corresponding output block. An example of this is when a DSI panel calls
dsi functions, the dsi driver figures out whether the panel is connected
to DSI1 or DSI2. This isn't correct, and having output as entities will
give the panel driver the exact information on which output to configure.
Having outputs also gives the opportunity to make panel drivers generic
across different platforms/SoCs, this is achieved as omap specific output
calls can be replaced by ops of a particular output type.
- Have more complex connections between managers, outputs and devices: OMAPDSS
currently doesn't support use cases like 2 outputs connect to a single
device. This can be achieved by extending properties of outputs to connect to
more managers or devices.
- Represent writeback as an output: The writeback pipeline fits well in OMAPDSS
as compared to overlays, managers or devices.
Add a new struct to represent outputs. An output struct holds pointers to the
manager and device structs to which it is connected. Add functions which can
register/unregister an output, or look for one. Create an enum which represent
each output instance.
Signed-off-by: Archit Taneja <archit@ti.com>
2012-09-07 19:08:00 +07:00
|
|
|
|
2013-04-23 19:35:35 +07:00
|
|
|
struct omap_dss_output *omapdss_find_output_from_display(struct omap_dss_device *dssdev);
|
|
|
|
struct omap_overlay_manager *omapdss_find_mgr_from_display(struct omap_dss_device *dssdev);
|
|
|
|
|
2010-01-11 18:54:33 +07:00
|
|
|
void omapdss_default_get_resolution(struct omap_dss_device *dssdev,
|
|
|
|
u16 *xres, u16 *yres);
|
2010-01-11 19:33:40 +07:00
|
|
|
int omapdss_default_get_recommended_bpp(struct omap_dss_device *dssdev);
|
2012-03-16 01:00:23 +07:00
|
|
|
void omapdss_default_get_timings(struct omap_dss_device *dssdev,
|
|
|
|
struct omap_video_timings *timings);
|
2010-01-11 19:33:40 +07:00
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
typedef void (*omap_dispc_isr_t) (void *arg, u32 mask);
|
|
|
|
int omap_dispc_register_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
|
|
|
|
int omap_dispc_unregister_isr(omap_dispc_isr_t isr, void *arg, u32 mask);
|
|
|
|
|
2012-11-07 23:17:35 +07:00
|
|
|
u32 dispc_read_irqstatus(void);
|
|
|
|
void dispc_clear_irqstatus(u32 mask);
|
|
|
|
u32 dispc_read_irqenable(void);
|
|
|
|
void dispc_write_irqenable(u32 mask);
|
|
|
|
|
|
|
|
int dispc_request_irq(irq_handler_t handler, void *dev_id);
|
|
|
|
void dispc_free_irq(void *dev_id);
|
|
|
|
|
|
|
|
int dispc_runtime_get(void);
|
|
|
|
void dispc_runtime_put(void);
|
|
|
|
|
|
|
|
void dispc_mgr_enable(enum omap_channel channel, bool enable);
|
|
|
|
bool dispc_mgr_is_enabled(enum omap_channel channel);
|
|
|
|
u32 dispc_mgr_get_vsync_irq(enum omap_channel channel);
|
|
|
|
u32 dispc_mgr_get_framedone_irq(enum omap_channel channel);
|
|
|
|
u32 dispc_mgr_get_sync_lost_irq(enum omap_channel channel);
|
|
|
|
bool dispc_mgr_go_busy(enum omap_channel channel);
|
|
|
|
void dispc_mgr_go(enum omap_channel channel);
|
|
|
|
void dispc_mgr_set_lcd_config(enum omap_channel channel,
|
|
|
|
const struct dss_lcd_mgr_config *config);
|
|
|
|
void dispc_mgr_set_timings(enum omap_channel channel,
|
|
|
|
const struct omap_video_timings *timings);
|
|
|
|
void dispc_mgr_setup(enum omap_channel channel,
|
|
|
|
const struct omap_overlay_manager_info *info);
|
|
|
|
|
|
|
|
int dispc_ovl_check(enum omap_plane plane, enum omap_channel channel,
|
|
|
|
const struct omap_overlay_info *oi,
|
|
|
|
const struct omap_video_timings *timings,
|
|
|
|
int *x_predecim, int *y_predecim);
|
|
|
|
|
|
|
|
int dispc_ovl_enable(enum omap_plane plane, bool enable);
|
|
|
|
bool dispc_ovl_enabled(enum omap_plane plane);
|
|
|
|
void dispc_ovl_set_channel_out(enum omap_plane plane,
|
|
|
|
enum omap_channel channel);
|
|
|
|
int dispc_ovl_setup(enum omap_plane plane, const struct omap_overlay_info *oi,
|
|
|
|
bool replication, const struct omap_video_timings *mgr_timings,
|
|
|
|
bool mem_to_mem);
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
#define to_dss_driver(x) container_of((x), struct omap_dss_driver, driver)
|
OMAPDSS: Add panel dev pointer to dssdev
We are about to remove the dss bus support, which also means that the
omap_dss_device won't be a real device anymore. This means that the
embedded "dev" struct needs to be removed from omap_dss_device.
After we've finished the removal of the dss bus, we see the following
changes:
- struct omap_dss_device won't be a real Linux device anymore, but more
like a "display entity".
- struct omap_dss_driver won't be a Linux device driver, but "display
entity ops".
- The panel devices/drivers won't be omapdss devices/drivers, but
platform/i2c/spi/etc devices/drivers, whichever fits the control
mechanism of the panel.
- The panel drivers will create omap_dss_device and omap_dss_driver,
fill the required fields, and register the omap_dss_device to
omapdss.
- omap_dss_device won't have an embedded dev struct anymore, but a
dev pointer to the actual device that manages the omap_dss_device.
The model described above resembles the model that has been discussed
with CDF (common display framework).
For the duration of the conversion, we temporarily have two devs in the
dssdev, the old "old_dev", which is a full embedded device struct, and the
new "dev", which is a pointer to the device. "old_dev" will be removed
in the future.
For devices belonging to dss bus the dev is initialized to point to
old_dev. This way all the code can just use the dev, for both old and
new style panels.
Both the new and old style panel drivers work during the conversion, and
only after the dss bus support is removed will the old style panels stop
to compile.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-02-14 19:17:28 +07:00
|
|
|
#define to_dss_device(x) container_of((x), struct omap_dss_device, old_dev)
|
2009-11-03 16:23:50 +07:00
|
|
|
|
2011-05-12 18:56:24 +07:00
|
|
|
void omapdss_dsi_vc_enable_hs(struct omap_dss_device *dssdev, int channel,
|
|
|
|
bool enable);
|
2010-01-11 20:11:01 +07:00
|
|
|
int omapdss_dsi_enable_te(struct omap_dss_device *dssdev, bool enable);
|
2013-03-06 16:10:29 +07:00
|
|
|
int omapdss_dsi_set_config(struct omap_dss_device *dssdev,
|
|
|
|
const struct omap_dss_dsi_config *config);
|
2010-01-12 21:00:30 +07:00
|
|
|
|
2011-11-03 21:34:20 +07:00
|
|
|
int omap_dsi_update(struct omap_dss_device *dssdev, int channel,
|
2010-01-12 19:16:41 +07:00
|
|
|
void (*callback)(int, void *), void *data);
|
2011-03-02 14:05:53 +07:00
|
|
|
int omap_dsi_request_vc(struct omap_dss_device *dssdev, int *channel);
|
|
|
|
int omap_dsi_set_vc_id(struct omap_dss_device *dssdev, int channel, int vc_id);
|
|
|
|
void omap_dsi_release_vc(struct omap_dss_device *dssdev, int channel);
|
2012-03-28 19:58:56 +07:00
|
|
|
int omapdss_dsi_configure_pins(struct omap_dss_device *dssdev,
|
|
|
|
const struct omap_dsi_pin_config *pin_cfg);
|
2010-01-12 19:16:41 +07:00
|
|
|
|
2010-01-12 20:12:07 +07:00
|
|
|
int omapdss_dsi_display_enable(struct omap_dss_device *dssdev);
|
2010-07-30 16:39:34 +07:00
|
|
|
void omapdss_dsi_display_disable(struct omap_dss_device *dssdev,
|
2010-10-11 15:33:30 +07:00
|
|
|
bool disconnect_lanes, bool enter_ulps);
|
2010-01-12 20:12:07 +07:00
|
|
|
|
|
|
|
int omapdss_dpi_display_enable(struct omap_dss_device *dssdev);
|
|
|
|
void omapdss_dpi_display_disable(struct omap_dss_device *dssdev);
|
2012-08-08 15:58:54 +07:00
|
|
|
void omapdss_dpi_set_timings(struct omap_dss_device *dssdev,
|
|
|
|
struct omap_video_timings *timings);
|
2010-01-20 17:11:25 +07:00
|
|
|
int dpi_check_timings(struct omap_dss_device *dssdev,
|
|
|
|
struct omap_video_timings *timings);
|
2012-07-06 17:00:52 +07:00
|
|
|
void omapdss_dpi_set_data_lines(struct omap_dss_device *dssdev, int data_lines);
|
2010-01-12 20:12:07 +07:00
|
|
|
|
|
|
|
int omapdss_sdi_display_enable(struct omap_dss_device *dssdev);
|
|
|
|
void omapdss_sdi_display_disable(struct omap_dss_device *dssdev);
|
2012-07-05 18:41:12 +07:00
|
|
|
void omapdss_sdi_set_timings(struct omap_dss_device *dssdev,
|
|
|
|
struct omap_video_timings *timings);
|
2012-07-20 18:48:49 +07:00
|
|
|
void omapdss_sdi_set_datapairs(struct omap_dss_device *dssdev, int datapairs);
|
2010-01-12 20:12:07 +07:00
|
|
|
|
|
|
|
int omapdss_rfbi_display_enable(struct omap_dss_device *dssdev);
|
|
|
|
void omapdss_rfbi_display_disable(struct omap_dss_device *dssdev);
|
2012-08-13 13:54:53 +07:00
|
|
|
int omap_rfbi_update(struct omap_dss_device *dssdev, void (*callback)(void *),
|
|
|
|
void *data);
|
2012-08-13 16:58:15 +07:00
|
|
|
int omap_rfbi_configure(struct omap_dss_device *dssdev);
|
2012-08-13 16:42:10 +07:00
|
|
|
void omapdss_rfbi_set_size(struct omap_dss_device *dssdev, u16 w, u16 h);
|
2012-08-13 16:56:49 +07:00
|
|
|
void omapdss_rfbi_set_pixel_size(struct omap_dss_device *dssdev,
|
|
|
|
int pixel_size);
|
2012-08-13 16:58:15 +07:00
|
|
|
void omapdss_rfbi_set_data_lines(struct omap_dss_device *dssdev,
|
|
|
|
int data_lines);
|
2012-08-13 23:53:29 +07:00
|
|
|
void omapdss_rfbi_set_interface_timings(struct omap_dss_device *dssdev,
|
|
|
|
struct rfbi_timings *timings);
|
2010-01-12 19:16:41 +07:00
|
|
|
|
2012-10-10 14:26:45 +07:00
|
|
|
int omapdss_compat_init(void);
|
|
|
|
void omapdss_compat_uninit(void);
|
|
|
|
|
2012-10-24 17:52:40 +07:00
|
|
|
struct dss_mgr_ops {
|
OMAPDSS: Implement display (dis)connect support
We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.
This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.
To support that kind of scenarios, we need to add new step to the
initialization: connect.
This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.
One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.
This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-08 20:23:32 +07:00
|
|
|
int (*connect)(struct omap_overlay_manager *mgr,
|
|
|
|
struct omap_dss_output *dst);
|
|
|
|
void (*disconnect)(struct omap_overlay_manager *mgr,
|
|
|
|
struct omap_dss_output *dst);
|
|
|
|
|
2012-10-24 17:52:40 +07:00
|
|
|
void (*start_update)(struct omap_overlay_manager *mgr);
|
|
|
|
int (*enable)(struct omap_overlay_manager *mgr);
|
|
|
|
void (*disable)(struct omap_overlay_manager *mgr);
|
|
|
|
void (*set_timings)(struct omap_overlay_manager *mgr,
|
|
|
|
const struct omap_video_timings *timings);
|
|
|
|
void (*set_lcd_config)(struct omap_overlay_manager *mgr,
|
|
|
|
const struct dss_lcd_mgr_config *config);
|
|
|
|
int (*register_framedone_handler)(struct omap_overlay_manager *mgr,
|
|
|
|
void (*handler)(void *), void *data);
|
|
|
|
void (*unregister_framedone_handler)(struct omap_overlay_manager *mgr,
|
|
|
|
void (*handler)(void *), void *data);
|
|
|
|
};
|
|
|
|
|
|
|
|
int dss_install_mgr_ops(const struct dss_mgr_ops *mgr_ops);
|
|
|
|
void dss_uninstall_mgr_ops(void);
|
|
|
|
|
OMAPDSS: Implement display (dis)connect support
We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.
This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.
To support that kind of scenarios, we need to add new step to the
initialization: connect.
This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.
One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.
This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-08 20:23:32 +07:00
|
|
|
int dss_mgr_connect(struct omap_overlay_manager *mgr,
|
|
|
|
struct omap_dss_output *dst);
|
|
|
|
void dss_mgr_disconnect(struct omap_overlay_manager *mgr,
|
|
|
|
struct omap_dss_output *dst);
|
2012-10-24 17:52:40 +07:00
|
|
|
void dss_mgr_set_timings(struct omap_overlay_manager *mgr,
|
|
|
|
const struct omap_video_timings *timings);
|
|
|
|
void dss_mgr_set_lcd_config(struct omap_overlay_manager *mgr,
|
|
|
|
const struct dss_lcd_mgr_config *config);
|
|
|
|
int dss_mgr_enable(struct omap_overlay_manager *mgr);
|
|
|
|
void dss_mgr_disable(struct omap_overlay_manager *mgr);
|
|
|
|
void dss_mgr_start_update(struct omap_overlay_manager *mgr);
|
|
|
|
int dss_mgr_register_framedone_handler(struct omap_overlay_manager *mgr,
|
|
|
|
void (*handler)(void *), void *data);
|
|
|
|
void dss_mgr_unregister_framedone_handler(struct omap_overlay_manager *mgr,
|
|
|
|
void (*handler)(void *), void *data);
|
OMAPDSS: Implement display (dis)connect support
We currently have two steps in panel initialization and startup: probing
and enabling. After the panel has been probed, it's ready and can be
configured and later enabled.
This model is not enough with more complex display pipelines, where we
may have, for example, two panels, of which only one can be used at a
time, connected to the same video output.
To support that kind of scenarios, we need to add new step to the
initialization: connect.
This patch adds support for connecting and disconnecting panels. After
probe, but before connect, no panel ops should be called. When the
connect is called, a proper video pipeline is established, and the panel
is ready for use. If some part in the video pipeline is already
connected (by some other panel), the connect call fails.
One key difference with the old style setup is that connect() handles
also connecting to the overlay manager. This means that the omapfb (or
omapdrm) no longer needs to figure out which overlay manager to use, but
it can just call connect() on the panel, and the proper overlay manager
is connected by omapdss.
This also allows us to add back the support for dynamic switching
between two exclusive panels. However, the current panel device model is
not changed to support this, as the new device model is implemented in
the following patches and the old model will be removed. The new device
model supports dynamic switching.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
2013-05-08 20:23:32 +07:00
|
|
|
|
|
|
|
static inline bool omapdss_device_is_connected(struct omap_dss_device *dssdev)
|
|
|
|
{
|
|
|
|
return dssdev->output;
|
|
|
|
}
|
|
|
|
|
|
|
|
static inline bool omapdss_device_is_enabled(struct omap_dss_device *dssdev)
|
|
|
|
{
|
|
|
|
return dssdev->state == OMAP_DSS_DISPLAY_ACTIVE;
|
|
|
|
}
|
|
|
|
|
2009-11-03 16:23:50 +07:00
|
|
|
#endif
|