<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include/video, branch v3.2.38</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include/video?h=v3.2.38</id>
<link rel='self' href='https://git.amat.us/linux/atom/include/video?h=v3.2.38'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2012-03-12T19:31:38Z</updated>
<entry>
<title>OMAPDSS: HDMI: PHY burnout fix</title>
<updated>2012-03-12T19:31:38Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2012-01-17T09:09:57Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=338b2875624561c3ea57d95519497527c06d123f'/>
<id>urn:sha1:338b2875624561c3ea57d95519497527c06d123f</id>
<content type='text'>
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 &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>ARM: OMAP: HWMOD: Unify DSS resets for OMAPs</title>
<updated>2011-11-08T10:16:13Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2011-11-08T10:16:13Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=13662dc5b177d68885695ef513dd4ae0e4d2a099'/>
<id>urn:sha1:13662dc5b177d68885695ef513dd4ae0e4d2a099</id>
<content type='text'>
This patch adds a custom DSS reset function used on OMAPs from OMAP2
forward.

The function doesn't actually do a reset, it only waits for the reset to
complete. The reason for this is that on OMAP4 there is no possibility
to do a SW reset, and on OMAP2/3 doing a SW reset for dss_core resets
all the other DSS modules also, thus breaking the HWMOD model where
every DSS module is handled independently.

This fixes the problem with DSS reset on OMAP4, caused by the fact that
because there's no SW reset for dss_core on OMAP4, the HWMOD framework
doesn't try to reset dss_core and thus the DSS clocks were never enabled
at the same time. This causes causes the HWMOD reset to fail for
dss_dispc and dss_rfbi.

The common reset function will also allow us to fix another problem in
the future: before doing a reset we need to disable DSS outputs, which
are in some cases enabled by the bootloader, as otherwise DSS HW seems
to get more or less stuck, requiring a power reset to recover.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
[paul@pwsan.com: modified to build arch/arm/mach-omap2/display.o
 unconditionally to avoid an error when !CONFIG_OMAP2_DSS]
Signed-off-by: Paul Walmsley &lt;paul@pwsan.com&gt;
</content>
</entry>
<entry>
<title>Merge branch 'for-florian' of git://gitorious.org/linux-omap-dss2/linux into fbdev-next</title>
<updated>2011-10-15T00:19:52Z</updated>
<author>
<name>Florian Tobias Schandinat</name>
<email>FlorianSchandinat@gmx.de</email>
</author>
<published>2011-10-15T00:19:52Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ef26b7943c5821aaff1efc14c098840c49fe15c0'/>
<id>urn:sha1:ef26b7943c5821aaff1efc14c098840c49fe15c0</id>
<content type='text'>
</content>
</entry>
<entry>
<title>OMAPDSS: DISPC: zorder support for DSS overlays</title>
<updated>2011-10-03T13:51:55Z</updated>
<author>
<name>Archit Taneja</name>
<email>archit@ti.com</email>
</author>
<published>2011-09-08T05:59:17Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=54128701ecccbeb6f740030e0cc5f8e5701fe8ee'/>
<id>urn:sha1:54128701ecccbeb6f740030e0cc5f8e5701fe8ee</id>
<content type='text'>
Add zorder support on OMAP4, this feature allows deciding the visibility order
of the overlays based on the zorder value provided as an overlay info parameter
or a sysfs attribute of the overlay object.

Use the overlay cap OMAP_DSS_OVL_CAP_ZORDER to determine whether zorder is
supported for the overlay or not. Use dss feature FEAT_ALPHA_FREE_ZORDER
if the caps are not available.

Ensure that all overlays that are enabled and connected to the same manager
have different zorders. Swapping zorders of 2 enabled overlays currently
requires disabling one of the overlays.

Signed-off-by: Archit Taneja &lt;archit@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: DISPC: VIDEO3 pipeline support</title>
<updated>2011-10-03T13:51:54Z</updated>
<author>
<name>Archit Taneja</name>
<email>archit@ti.com</email>
</author>
<published>2011-09-13T12:50:33Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=b8c095b4d62f90ed8da0cca7116125863b1d8bef'/>
<id>urn:sha1:b8c095b4d62f90ed8da0cca7116125863b1d8bef</id>
<content type='text'>
Add support for VIDEO3 pipeline on OMAP4:
- Add VIDEO3 pipeline information in dss_features and omapdss.h
- Add VIDEO3 pipeline register coefficients in dispc.h
- Create a new overlay structure corresponding to VIDEO3.
- Make changes in dispc.c for VIDEO3

Signed-off-by: Archit Taneja &lt;archit@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS/OMAP_VOUT: Fix incorrect OMAP3-alpha compatibility setting</title>
<updated>2011-10-03T13:51:54Z</updated>
<author>
<name>Archit Taneja</name>
<email>archit@ti.com</email>
</author>
<published>2011-09-26T06:17:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=11354dd58da1134ec9c96b65104e5cf2d50e1eb9'/>
<id>urn:sha1:11354dd58da1134ec9c96b65104e5cf2d50e1eb9</id>
<content type='text'>
On OMAP3, in order to enable alpha blending for LCD and TV managers, we needed
to set LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits in DISPC_CONFIG. On
OMAP4, alpha blending is always enabled by default, if the above bits are set,
we switch to an OMAP3 compatibility mode where the zorder values in the pipeline
attribute registers are ignored and a fixed priority is configured.

Rename the manager_info member "alpha_enabled" to "partial_alpha_enabled" for
more clarity. Introduce two dss_features FEAT_ALPHA_FIXED_ZORDER and
FEAT_ALPHA_FREE_ZORDER which represent OMAP3-alpha compatibility mode and OMAP4
alpha mode respectively. Introduce an overlay cap for ZORDER. The DSS2 user is
expected to check for the ZORDER cap, if an overlay doesn't have this cap, the
user is expected to set the parameter partial_alpha_enabled. If the overlay has
ZORDER cap, the DSS2 user can assume that alpha blending is already enabled.

Don't support OMAP3 compatibility mode for now. Trying to read/write to
alpha_blending_enabled sysfs attribute issues a warning for OMAP4 and does not
set the LCDALPHABLENDERENABLE/TVALPHABLENDERENABLE bits.

Change alpha_enabled to partial_alpha_enabled in the omap_vout driver. Use
overlay cap "OMAP_DSS_OVL_CAP_GLOBAL_ALPHA" to check if overlay supports alpha
blending or not. Replace this with checks for VIDEO1 pipeline.

Cc: linux-media@vger.kernel.org
Cc: Lajos Molnar &lt;molnar@ti.com&gt;
Signed-off-by: Archit Taneja &lt;archit@ti.com&gt;
Acked-by: Vaibhav Hiremath &lt;hvaibhav@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: remove vaddr from overlay info</title>
<updated>2011-09-30T13:17:32Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2011-09-26T16:16:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=212b0d50e2eb7fc60f7bea1e90e5867b5fc0647d'/>
<id>urn:sha1:212b0d50e2eb7fc60f7bea1e90e5867b5fc0647d</id>
<content type='text'>
overlay_info struct, used to configure overlays, currently includes both
physical and virtual addresses for the pixels. The vaddr was added to
support more exotic configurations where CPU would be used to update a
display, but it is not currently used and there has been no interest in
the feature. Using CPU to update a screen is also less interesting now
that OMAP4 has two LCD outputs.

This patch removes the vaddr field, and modifies the users of omapdss
accordingly. This makes the use of omapdss a bit simpler, as the user
doesn't need to think if it needs to give the vaddr.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: Add N800 panel driver</title>
<updated>2011-09-30T13:17:30Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2011-04-21T16:53:59Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=562a060611de60d6cceecb8a71847216679eef2a'/>
<id>urn:sha1:562a060611de60d6cceecb8a71847216679eef2a</id>
<content type='text'>
This is a driver for N800's display, ported from the old omapfb. This is
a slightly lighter version of the driver as not all features of the old
driver can be ported without big changes to DSS2, and also because some
of the HW features used in the old driver are unclear (e.g. the power
management part).

That said, the new driver works fine for basic use.

Architecturally the driver is not as neat as it could be. N800's display
HW consists of a display buffer chip and a panel, and ideally they would
be represented by separate, independent drivers. This is not currently
possible, and this driver contains both buffer chip and panel driver.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: Taal: remove external backlight support</title>
<updated>2011-09-30T13:17:27Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2011-08-09T08:39:27Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bb36dbfd23033282991ac47d9eac8ad26514a0d1'/>
<id>urn:sha1:bb36dbfd23033282991ac47d9eac8ad26514a0d1</id>
<content type='text'>
Taal panel driver supports two kinds of backlight control: 1) using DSI
commands sent to the panel to control the backlight, 2) calling function
pointers going to the board file to control the backlight.

The second option is a bit hacky, and will no longer be needed when the
PWM driver supports the backlight features. After that we can use the
standard PWM backlight driver.

This patch removes the second backlight control mechanism, and adds a
boolean field, use_dsi_backlight, to nokia_dsi_panel_data which the
board file can use to inform whether the panel driver should use DSI
commands to control the backlight.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAP: DSS2: add panel-dvi driver</title>
<updated>2011-09-30T13:16:48Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2011-09-01T06:17:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=ba2eac9ed32e4485b2a76e1a0922837d3ffd6149'/>
<id>urn:sha1:ba2eac9ed32e4485b2a76e1a0922837d3ffd6149</id>
<content type='text'>
We have currently panel-generic-dpi driver, which is a combined driver
for dummy panels and also for DVI output.

The aim is to split the panel-generic-dpi into two, one for fixed size
dummy panels connected via DPI, and the other (this) for variable
resolution output which supports DDC channel (in practice a DVI framer
chip connected to DPI output).

Original i2c code by: Ricardo Salveti de Araujo
&lt;ricardo.salveti@canonical.com&gt;

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
</feed>
