<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/include/video/omapdss.h, branch linux-3.5.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>OMAPDSS: DISPC: Support rotation through TILER</title>
<updated>2012-05-22T07:59:15+00:00</updated>
<author>
<name>Chandrabhanu Mahapatra</name>
<email>cmahapatra@ti.com</email>
</author>
<published>2012-05-11T13:49:55+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=65e006ff4bb06d42b532f866a846db6e4e637723'/>
<id>65e006ff4bb06d42b532f866a846db6e4e637723</id>
<content type='text'>
TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner.
Physical memory can be mapped to a portion of OMAP's system address space called
TILER address space. The TILER address space is split into 8 views. Each view
represents a rotated or mirrored form of the mapped physical memory. When a
DISPC overlay's base address is programmed to one of these views, the TILER
fetches the pixels according to the orientation of the view. A view is further
split into 4 containers, each container holds elements of a particular size.
Rotation can be achieved at the granularity of elements in the container. For
more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM.
Rotation type TILER has been added which is used to exploit the capabilities of
these 8 views for performing various rotations.

When fetching from addresses mapped to TILER space, the DISPC DMA can fetch
pixels in either 1D or 2D bursts. The fetch depends on which TILER container we
are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts,
and page mode sized containers require 1D bursts.

The DSS2 user is expected to provide the Tiler address of the view that it is
interested in. This is passed to the paddr and p_uv_addr parameters in
omap_overlay_info. It is also expected to provide the stride value based on the
view's orientation and container type, this should be passed to the screen_width
parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is
used to calculate the required row_inc for DISPC. x_predecim and y_predecim are
also used to calculate row_inc and pix_inc thereby adding predecimation support
for TILER.

Signed-off-by: Chandrabhanu Mahapatra &lt;cmahapatra@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
TILER is a block in OMAP4's DMM which lets DSS fetch frames in a rotated manner.
Physical memory can be mapped to a portion of OMAP's system address space called
TILER address space. The TILER address space is split into 8 views. Each view
represents a rotated or mirrored form of the mapped physical memory. When a
DISPC overlay's base address is programmed to one of these views, the TILER
fetches the pixels according to the orientation of the view. A view is further
split into 4 containers, each container holds elements of a particular size.
Rotation can be achieved at the granularity of elements in the container. For
more information on TILER, refer to the Memory Subsytem section in OMAP4 TRM.
Rotation type TILER has been added which is used to exploit the capabilities of
these 8 views for performing various rotations.

When fetching from addresses mapped to TILER space, the DISPC DMA can fetch
pixels in either 1D or 2D bursts. The fetch depends on which TILER container we
are accessing. Accessing 8, 16 and 32 bit sized containers requires 2D bursts,
and page mode sized containers require 1D bursts.

The DSS2 user is expected to provide the Tiler address of the view that it is
interested in. This is passed to the paddr and p_uv_addr parameters in
omap_overlay_info. It is also expected to provide the stride value based on the
view's orientation and container type, this should be passed to the screen_width
parameter of omap_overlay_info. In calc_tiler_rotation_offset screen_width is
used to calculate the required row_inc for DISPC. x_predecim and y_predecim are
also used to calculate row_inc and pix_inc thereby adding predecimation support
for TILER.

Signed-off-by: Chandrabhanu Mahapatra &lt;cmahapatra@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>OMAPDSS: Provide an interface for audio support</title>
<updated>2012-05-11T12:13:50+00:00</updated>
<author>
<name>Ricardo Neri</name>
<email>ricardo.neri@ti.com</email>
</author>
<published>2012-03-07T00:20:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9c0b8420369cb5d7fd2fea51d4705cbd0ea52743'/>
<id>9c0b8420369cb5d7fd2fea51d4705cbd0ea52743</id>
<content type='text'>
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 &lt;ricardo.neri@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;ricardo.neri@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>OMAPDSS: clean up the omapdss platform data mess</title>
<updated>2012-05-11T11:44:51+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2012-02-20T09:50:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=00928eaf52007ee4e1fb7dc860bc02a56c125bb4'/>
<id>00928eaf52007ee4e1fb7dc860bc02a56c125bb4</id>
<content type='text'>
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:

- Remove struct omap_display_platform_data. It was used just as a
  wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
  dss hwmods do not need the platform data. This should also work better
  for DT, as we can create omapdss device programmatically in generic omap
  boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
  that the dss hwmod drivers can call.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:

- Remove struct omap_display_platform_data. It was used just as a
  wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
  dss hwmods do not need the platform data. This should also work better
  for DT, as we can create omapdss device programmatically in generic omap
  boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
  that the dss hwmod drivers can call.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Merge branch 'for-l-o-3.5'</title>
<updated>2012-05-10T17:24:14+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2012-05-10T16:55:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9b71fb5cbcdd83c65e5fe6db9cd12246f7ea0262'/>
<id>9b71fb5cbcdd83c65e5fe6db9cd12246f7ea0262</id>
<content type='text'>
Conflicts:
	drivers/video/omap2/displays/panel-taal.c

Merge OMAP DSS related board file changes. The branch will also be
merged through linux-omap tree to solve conflicts.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Conflicts:
	drivers/video/omap2/displays/panel-taal.c

Merge OMAP DSS related board file changes. The branch will also be
merged through linux-omap tree to solve conflicts.
</pre>
</div>
</content>
</entry>
<entry>
<title>OMAPDSS: DSI: implement generic DSI pin config</title>
<updated>2012-05-09T07:53:05+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2012-03-28T12:58:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07'/>
<id>e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07</id>
<content type='text'>
In preparation for device tree, this patch changes how the DSI pins are
configured. The current configuration method is only doable with board
files and the configuration data is OMAP specific.

This patch moves the configuration data to the panel's platform data,
and the data can easily be given via DT in the future. The configuration
data format is also changed to a generic one which should be suitable
for all platforms.

The new format is an array of pin numbers, where the array items start
from clock + and -, then data1 + and -, and so on. For example:

{
	0,	// pin num for clock lane +
	1,	// pin num for clock lane -
	2,	// pin num for data1 lane +
	3,	// pin num for data1 lane -
	...
}

The pin numbers are translated by the DSI driver and used to configure
the hardware appropriately.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In preparation for device tree, this patch changes how the DSI pins are
configured. The current configuration method is only doable with board
files and the configuration data is OMAP specific.

This patch moves the configuration data to the panel's platform data,
and the data can easily be given via DT in the future. The configuration
data format is also changed to a generic one which should be suitable
for all platforms.

The new format is an array of pin numbers, where the array items start
from clock + and -, then data1 + and -, and so on. For example:

{
	0,	// pin num for clock lane +
	1,	// pin num for clock lane -
	2,	// pin num for data1 lane +
	3,	// pin num for data1 lane -
	...
}

The pin numbers are translated by the DSI driver and used to configure
the hardware appropriately.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Acked-by: Tony Lindgren &lt;tony@atomide.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>OMAPDSS: provide default get_timings function for panels</title>
<updated>2012-04-23T07:48:07+00:00</updated>
<author>
<name>Grazvydas Ignotas</name>
<email>notasas@gmail.com</email>
</author>
<published>2012-03-15T18:00:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=4b6430fc98cfe051eab69f4696a608bba14ebd6c'/>
<id>4b6430fc98cfe051eab69f4696a608bba14ebd6c</id>
<content type='text'>
With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.

Signed-off-by: Grazvydas Ignotas &lt;notasas@gmail.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
With this we can eliminate some duplicate code in panel drivers.
Also lgphilips-lb035q02, nec-nl8048hl11-01b, picodlp and
tpo-td043mtea1 gain support of reading timings over sysfs.

Signed-off-by: Grazvydas Ignotas &lt;notasas@gmail.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>OMAPDSS: add set_min_bus_tput pointer to omapdss's platform data</title>
<updated>2012-04-23T07:48:03+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2012-03-08T10:37:58+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=62c1dcfc7451a8e42104776705a317e06a8e24a3'/>
<id>62c1dcfc7451a8e42104776705a317e06a8e24a3</id>
<content type='text'>
omapdss driver needs to use the omap_pm_set_min_bus_tput(), so add a new
entry for that in omapdss's platform data, and set it.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: Paul Walmsley &lt;paul@pwsan.com&gt;
Acked-by: Kevin Hilman &lt;khilman@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
omapdss driver needs to use the omap_pm_set_min_bus_tput(), so add a new
entry for that in omapdss's platform data, and set it.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: Paul Walmsley &lt;paul@pwsan.com&gt;
Acked-by: Kevin Hilman &lt;khilman@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>OMAPDSS: HDMI: PHY burnout fix</title>
<updated>2012-01-26T11:51:36+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2012-01-17T09:09:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=c49d005b6cc8491fad5b24f82805be2d6bcbd3dd'/>
<id>c49d005b6cc8491fad5b24f82805be2d6bcbd3dd</id>
<content type='text'>
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 &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>OMAPDSS: HDMI: Disable DDC internal pull up</title>
<updated>2012-01-05T08:34:50+00:00</updated>
<author>
<name>Mythri P K</name>
<email>mythripk@ti.com</email>
</author>
<published>2012-01-02T08:32:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=9a9016832d2601a290db4dce6dd55552bdae5b1a'/>
<id>9a9016832d2601a290db4dce6dd55552bdae5b1a</id>
<content type='text'>
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are external pull up's in 4460 and 4430 ES2.3
SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.

Signed-off-by: Ricardo Salveti de Araujo &lt;ricardo.salveti@linaro.org&gt;
Signed-off-by: Mythri P K &lt;mythripk@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Disables the internal pull resistor for SDA and SCL which are enabled by
default, as there are external pull up's in 4460 and 4430 ES2.3
SDP, Blaze and Panda Boards, It is done to avoid the EDID read failure.

Signed-off-by: Ricardo Salveti de Araujo &lt;ricardo.salveti@linaro.org&gt;
Signed-off-by: Mythri P K &lt;mythripk@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>OMAPDSS: HDMI: Move duplicate code from boardfile</title>
<updated>2012-01-05T08:34:49+00:00</updated>
<author>
<name>Mythri P K</name>
<email>mythripk@ti.com</email>
</author>
<published>2012-01-02T08:32:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ee9dfd82ff1317ac5c0147fe21508ad6d7df4cff'/>
<id>ee9dfd82ff1317ac5c0147fe21508ad6d7df4cff</id>
<content type='text'>
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.

Signed-off-by: Mythri P K &lt;mythripk@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Move duplicate HDMI mux_init code from omap4 and panda board file
to display file.

Signed-off-by: Mythri P K &lt;mythripk@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</pre>
</div>
</content>
</entry>
</feed>
