<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/video/fbdev/omap2, branch v4.0</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v4.0</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v4.0'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2015-02-26T08:23:15Z</updated>
<entry>
<title>OMAPDSS: fix regression with display sysfs files</title>
<updated>2015-02-26T08:23:15Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2015-02-25T08:23:58Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a38bb793eaebe1178fbd8ef6ab66ccc062bad505'/>
<id>urn:sha1:a38bb793eaebe1178fbd8ef6ab66ccc062bad505</id>
<content type='text'>
omapdss's sysfs directories for displays used to have 'name' file,
giving the name for the display. This file was later renamed to
'display_name' to avoid conflicts with i2c sysfs 'name' file. Looks like
at least xserver-xorg-video-omap3 requires the 'name' file to be
present.

To fix the regression, this patch creates new kobjects for each display,
allowing us to create sysfs directories for the displays. This way we
have the whole directory for omapdss, and there will be no sysfs file
clashes with the underlying display device's sysfs files.

We can thus add the 'name' sysfs file back.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Tested-by: NeilBrown &lt;neilb@suse.de&gt;
</content>
</entry>
<entry>
<title>omapfb: Return error code when applying overlay settings fails</title>
<updated>2015-02-04T10:41:53Z</updated>
<author>
<name>Peter Meerwald</name>
<email>pmeerw@pmeerw.net</email>
</author>
<published>2015-01-30T07:59:46Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=811fbb1f580ca024a0af603dfaef08a4d1dcb5ef'/>
<id>urn:sha1:811fbb1f580ca024a0af603dfaef08a4d1dcb5ef</id>
<content type='text'>
the check of the return code is missing, user space does not get notified
about the error condition:

omapdss OVERLAY error: overlay 2 horizontally not inside the display area (403 + 800 &gt;= 800)
omapdss APPLY error: failed to apply settings: illegal configuration.

Signed-off-by: Peter Meerwald &lt;pmeerw@pmeerw.net&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: DPI: DRA7xx support</title>
<updated>2015-02-04T10:32:07Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2014-12-31T09:26:06Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a2408154a14b5633b1f233e4b5fea85c09917eef'/>
<id>urn:sha1:a2408154a14b5633b1f233e4b5fea85c09917eef</id>
<content type='text'>
Add support for DRA7xx DPI output.

DRA7xx has three DPI outputs, each of which gets its input from a DISPC
channel. However, DRA72x has only one video PLL, and DRA74x has two
video PLLs. In both cases the video PLLs need to be shared between
multiple outputs. The driver doesn't handle this at the moment.

Also, DRA7xx requires configuring CONTROL module bits to route the clock
from the PLL to the used DISPC channel.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: HDMI: Add DRA7xx support</title>
<updated>2015-02-04T10:32:06Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2014-12-31T09:26:18Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=adb5ff835c0db95e969c717f981f65f855f147bf'/>
<id>urn:sha1:adb5ff835c0db95e969c717f981f65f855f147bf</id>
<content type='text'>
Add support for DRA7xx to the HDMI driver.

The HDMI block on DRA7xx is the same as on OMAP5, except we need to
enable and disable the HDMI PLL via the CONTROL module.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: DISPC: program dispc polarities to control module</title>
<updated>2015-02-04T10:32:06Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2014-09-05T19:15:03Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=0006fd63d1fbb5deb29ced23da1580036afabe97'/>
<id>urn:sha1:0006fd63d1fbb5deb29ced23da1580036afabe97</id>
<content type='text'>
On DRA7xx, DISPC needs to write output signal polarities not only to a
DISPC register, like for all earlier DSS versions, but to control
module's CTRL_CORE_SMA_SW_1 register.

This patch adds support to write the polarities to control module.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: DISPC: Add DRA7xx support</title>
<updated>2015-02-04T10:32:06Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2014-12-31T09:25:48Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=935509275c2d315c6551da4d73bb3c36871b137c'/>
<id>urn:sha1:935509275c2d315c6551da4d73bb3c36871b137c</id>
<content type='text'>
Add DRA7xx support to DISPC driver. The DISPC block is the same as on
OMAP5, except the PLL's used for clocking are "videoX", not "dsiX".

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: Add Video PLLs for DRA7xx</title>
<updated>2015-02-04T10:32:05Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2014-07-04T08:08:27Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=99767548b128dae8eb46b7039958b2b6a5483c66'/>
<id>urn:sha1:99767548b128dae8eb46b7039958b2b6a5483c66</id>
<content type='text'>
DRA7xx SoCs have one (DRA72x) or two (DRA74x) video PLLs. They are
basically the same as DSI PLLs on OMAPs, but without the rest of the DSI
hardware. The video PLLs also require some configuration via the CONTROL
module.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: Add functions for external control of PLL</title>
<updated>2015-02-04T10:32:05Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2014-07-04T08:07:15Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=be40eecf8dea217a3f3b9df5c2d7235e91e25fb0'/>
<id>urn:sha1:be40eecf8dea217a3f3b9df5c2d7235e91e25fb0</id>
<content type='text'>
Add functions which configure the control module register
CTRL_CORE_DSS_PLL_CONTROL found in DRA7xx SoCs. This register configures
whether the PLL registers are accessed internally by DSS, or externally
using OCP2SCP interface. They also configure muxes which route the PLL
output to a particular LCD overlay manager within DSS.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: DSS: Add DRA7xx base support</title>
<updated>2015-02-04T10:32:05Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2014-12-31T09:23:31Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6d817880cdfd0456ccf5f2b705d7078957ea09cb'/>
<id>urn:sha1:6d817880cdfd0456ccf5f2b705d7078957ea09cb</id>
<content type='text'>
Add base support for DRA7xx to DSS core.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: encoder-tpd12s015: Fix race issue with LS_OE</title>
<updated>2015-02-04T10:32:04Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2014-09-19T16:58:57Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=a87a6d6b09de3118e5679c2057b99b7791b7673b'/>
<id>urn:sha1:a87a6d6b09de3118e5679c2057b99b7791b7673b</id>
<content type='text'>
A race issue has been observed with the encoder-tpd12s015 driver, which
leads to errors when trying to read EDID. This has only now been
observed, as OMAP4 and OMAP5 boards used SoC's GPIOs for LS_OE GPIO. On
dra7-evm boards, the LS_OE is behind a i2c controlled GPIO expander,
which increases the time to set the LS_OE.

This patch simplifies the handling of the LS_OE gpio in the driver by
removing the interrupt handling totally. The only time we actually need
to enable LS_OE is when we are reading the EDID, and thus we can just
set and clear the LS_OE gpio inside the read_edid() function.

This also has the additional benefit of very slightly decreasing the
power consumption.

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