linux-toradex.git/include/video/omapdss.h, branch v3.0.95

OMAPDSS: HDMI: PHY burnout fix

2012-03-12T17:32:59+00:00

commit c49d005b6cc8491fad5b24f82805be2d6bcbd3dd upstream.

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 
Signed-off-by: Greg Kroah-Hartman

OMAP: DSS2: Add support for NV12 format

2011-05-23T05:29:47+00:00

Add the support for NV12 color format.
Configure base address for UV component of NV12 color format.
Change the way chroma scaling is handled for YUV formats on OMAP4 by enabling
chroma-resampling for video pipeline and hence using FIR2 register set for
scaling UV.
Changes to _dispc_set_scaling(), because of the reason above, are:
- call _dispc_set_scaling_common() to handle scaling for all color formats
  except for OMAP4 where it only handles scaling for RGB or Y-component
- call _dispc_set_scaling_uv() for special handling required for UV
  component on OMAP4.
- dispc_set_scaling_uv() also resets chroma-resampling bit for RGB color modes.

Contains chroma scaling (_dispc_set_scaling_uv) design and implemented by
Lajos Molnar 

Signed-off-by: Amber Jain 
Signed-off-by: Tomi Valkeinen

OMAP: DSS2: Add new color formats for OMAP4

2011-05-23T05:29:47+00:00

Add new color formats supported by OMAP4: NV12, RGBA16, RGBX16,
ARGB16_1555, XRGB16_1555.
NV12 color format is defined here, its support in DSS will be added separately.

Signed-off-by: Amber Jain 
Signed-off-by: Tomi Valkeinen

OMAP: DSS2: DSI: Get number of DSI data lanes using DSI_GNQ register

2011-05-16T10:31:09+00:00

On OMAP3, the DSI module has 2 data lanes. On OMAP4, DSI1 has 4 data lanes
and DSI2 has 2 data lanes. Introduce function dsi_get_num_data_lanes() which
returns the number of data lanes on the dsi interface, introduce function
dsi_get_num_data_lanes_dssdev() which returns the number of data lanes used by
the omap_dss_device connected to the lanes.

Use the DSI_GNQ register on OMAP4 to get the number of data lanes, modify
dsi.c to use the number of lanes and the extra data lanes on DSI1.

Signed-off-by: Archit Taneja 
Signed-off-by: Tomi Valkeinen

OMAP: DSS2: RFBI: add omap_rfbi_configure

2011-05-12T16:39:50+00:00

Add omap_rfbi_configure() which the panel driver can use to reconfigure
the data element size and the number of data lines in the RFBI bus.

Signed-off-by: Tomi Valkeinen

OMAP: DSS2: RFBI: add rfbi_bus_lock

2011-05-12T16:39:49+00:00

Add similar bus lock to RFBI as is in DSI. The panel driver can use the
bus lock to mark that the RFBI bus is currently in use.

Signed-off-by: Tomi Valkeinen

OMAP4: DSS2: DSI: Changes for DSI2 on OMAP4

2011-05-12T16:30:27+00:00

Introduce DSI2 PLL clock sources needed by LCD2 channel and DSI2 Protocol
engine and DISPC Functional clock. Do the following:

- Modify dss_get_dsi_clk_source() and dss_select_dsi_clk_source() to take the
  dsi module number as an argument.
- Create debugfs files for dsi2, split the corresponding debugfs functions.
- Allow DPI to use these new clock sources.

Signed-off-by: Archit Taneja 
Signed-off-by: Tomi Valkeinen

OMAP: DSS2: Pass platform_device as an argument in dsi functions

2011-05-12T16:30:26+00:00

The DSI interface is represented as a platform device, using the DSI platform
driver(dsi.c). The current DSI driver design is capable of running only one
instance of a DSI device. On OMAP4, there are 2 very similar DSI modules which
can be represented as instances of "omapdss_dsi" platform device.

Add member "module" in "dssdev.phy.dsi" that tells us which DSI module's lanes
the panel is connected to. Modify dsi.c functions to take the device's
platform_device struct pointer, provide functions dsi_get_dsidev_from_dssdev()
and dsi_get_dsidev_from_id() take the panel's omap_dss_device and module number
respectively, and return the platform_device pointer. Currently, the dsi struct
is declared globally and is accessed when dsi data is needed. The new pdev
argument will be used later to provide the platform device's dsi related data.

Signed-off-by: Archit Taneja 
Signed-off-by: Tomi Valkeinen

OMAP: DSS2: DSI: Add extra omap_dss_device argument in functions exported by dsi

2011-05-12T16:30:26+00:00

Add pointer to omap_dss_device struct as an argument in the functions which
are exported to dsi panel drivers. This argument will tell the DSI driver
which DSI interface's data it has to choose.

Signed-off-by: Archit Taneja 
Signed-off-by: Tomi Valkeinen

OMAP: DSS2: DSI: Add DSI pad muxing support

2011-05-11T11:20:17+00:00

Add dsi_mux_pads function pointer to omap_dss_board_info, and use the
function pointer in DSI code to configure the DSI pads either to normal
DSI operation, or to pull down when in ULPS.

Signed-off-by: Tomi Valkeinen