<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/drivers/video/omap2/dss, branch linux-3.5.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.5.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.5.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2012-07-08T14:00:27Z</updated>
<entry>
<title>OMAPDSS: fix warnings if CONFIG_PM_RUNTIME=n</title>
<updated>2012-07-08T14:00:27Z</updated>
<author>
<name>Tomi Valkeinen</name>
</author>
<published>2012-07-04T12:43:49Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=373b43652150c9342168c846a1efbd81438ea241'/>
<id>urn:sha1:373b43652150c9342168c846a1efbd81438ea241</id>
<content type='text'>
If runtime PM is not enabled in the kernel config, pm_runtime_get_sync()
will always return 1 and pm_runtime_put_sync() will always return
-ENOSYS. pm_runtime_get_sync() returning 1 presents no problem to the
driver, but -ENOSYS from pm_runtime_put_sync() causes the driver to
print a warning.

One option would be to ignore errors returned by pm_runtime_put_sync()
totally, as they only say that the call was unable to put the hardware
into suspend mode.

However, I chose to ignore the returned -ENOSYS explicitly, and print a
warning for other errors, as I think we should get notified if the HW
failed to go to suspend properly.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: Jassi Brar &lt;jaswinder.singh@linaro.org&gt;
Cc: Grazvydas Ignotas &lt;notasas@gmail.com&gt;
Signed-off-by: Archit Taneja &lt;archit@ti.com&gt;
Signed-off-by: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: Use PM notifiers for system suspend</title>
<updated>2012-07-08T14:00:26Z</updated>
<author>
<name>Tomi Valkeinen</name>
</author>
<published>2012-07-04T12:43:48Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=736f29cd6b7af9646a21a34866cd16277e03ee69'/>
<id>urn:sha1:736f29cd6b7af9646a21a34866cd16277e03ee69</id>
<content type='text'>
The current way how omapdss handles system suspend and resume is that
omapdss device (a platform device, which is not part of the device
hierarchy of the DSS HW devices, like DISPC and DSI, or panels.) uses
the suspend and resume callbacks from platform_driver to handle system
suspend. It does this by disabling all enabled panels on suspend, and
resuming the previously disabled panels on resume.

This presents a few problems.

One is that as omapdss device is not related to the panel devices or the
DSS HW devices, there's no ordering in the suspend process. This means
that suspend could be first ran for DSS HW devices and panels, and only
then for omapdss device. Currently this is not a problem, as DSS HW
devices and panels do not handle suspend.

Another, more pressing problem, is that when suspending or resuming, the
runtime PM functions return -EACCES as runtime PM is disabled during
system suspend. This causes the driver to print warnings, and operations
to fail as they think that they failed to bring up the HW.

This patch changes the omapdss suspend handling to use PM notifiers,
which are called before suspend and after resume. This way we have a
normally functioning system when we are suspending and resuming the
panels.

This patch, I believe, creates a problem that somebody could enable or
disable a panel between PM_SUSPEND_PREPARE and the system suspend, and
similarly the other way around in resume. I choose to ignore the problem
for now, as it sounds rather unlikely, and if it happens, it's not
fatal.

In the long run the system suspend handling of omapdss and panels should
be thought out properly. The current approach feels rather hacky.
Perhaps the panel drivers should handle system suspend, or the users of
omapdss (omapfb, omapdrm) should handle system suspend.

Note that after this patch we could probably revert
0eaf9f52e94f756147dbfe1faf1f77a02378dbf9 (OMAPDSS: use sync versions of
pm_runtime_put). But as I said, this patch may be temporary, so let's
leave the sync version still in place.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Reported-by: Jassi Brar &lt;jaswinder.singh@linaro.org&gt;
Tested-by: Jassi Brar &lt;jaswinder.singh@linaro.org&gt;
Tested-by: Joe Woodward &lt;jw@terrafix.co.uk&gt;
Signed-off-by: Archit Taneja &lt;archit@ti.com&gt;
[fts: fixed 2 brace coding style issues]
Signed-off-by: Florian Tobias Schandinat &lt;FlorianSchandinat@gmx.de&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: DSI: Fix bug when calculating LP command interleaving parameters</title>
<updated>2012-06-04T10:07:51Z</updated>
<author>
<name>Archit Taneja</name>
</author>
<published>2012-06-04T08:06:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2e063c305a3da896ec3db99e66891411d0e38820'/>
<id>urn:sha1:2e063c305a3da896ec3db99e66891411d0e38820</id>
<content type='text'>
In function dsi_compute_interleave_lp(), the escape clock/LP clock time period
is calculated incorrectly. The escape clock/LP clock is calculated as:

LP Clock(Hz) = DSI_FCLK(Hz) / lp_clk_div

Since we are calculating the time period of LP clock, the LP clock divider
should be multiplied with the time period of DSI_FCLK.

Calculating incorrect value of txclkesc results in incorrect calculation of LP
interleaving parameters, it also creates a possibility of a divide by zero
error.

Reported-by: Sureshkumar Manimuthu &lt;mail2msuresh@ti.com&gt;

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: fix bogus WARN_ON in dss_runtime_put()</title>
<updated>2012-06-04T08:04:41Z</updated>
<author>
<name>Tomi Valkeinen</name>
</author>
<published>2012-05-23T14:02:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5025ce070e2dff80bcf015a34a82edcf78229287'/>
<id>urn:sha1:5025ce070e2dff80bcf015a34a82edcf78229287</id>
<content type='text'>
pm_runtime_put_sync() in dss_runtime_put() returns -EBUSY when any child
of dss is still enabled. This happens, for example, when a display
output is enabled and one dumps the clocks via debugfs. This causes
dss_runtime_get &amp; put to be called.

While I couldn't find anything about this in the documentation and it
wasn't immediately clear from runtime_pm code, it looks to me that
pm_runtime_put_sync() returns -EBUSY to inform that things went fine,
but the device could not be turned off as there are still child devices
that are enabled. This is not a problem.

This patch skips the WARN_ON if pm_runtime_put_sync() returns -EBUSY.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: fix build when DEBUG_FS or DSS_DEBUG_SUPPORT disabled</title>
<updated>2012-06-04T08:04:40Z</updated>
<author>
<name>Tomi Valkeinen</name>
</author>
<published>2012-05-23T13:45:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=0e9a126e95748e8283488818d98ae5bcb7b84515'/>
<id>urn:sha1:0e9a126e95748e8283488818d98ae5bcb7b84515</id>
<content type='text'>
If CONFIG_DEBUG_FS or CONFIG_OMAP2_DSS_DEBUG_SUPPORT is disabled, the
build fails:

drivers/video/omap2/dss/core.c:197:50: error: static declaration of
'dss_debugfs_create_file' follows non-static declaration
drivers/video/omap2/dss/dss.h:166:5: note: previous declaration of
'dss_debugfs_create_file' was here

This patch fixes the dummy dss_debugfs_create_file() so that the driver
builds.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: HDMI: OMAP4: Update IRQ flags for the HPD IRQ request</title>
<updated>2012-05-22T08:00:09Z</updated>
<author>
<name>Ricardo Neri</name>
</author>
<published>2012-05-22T02:47:21Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e92a5b28f71aea01b281f9c89d97a4bc5b24748f'/>
<id>urn:sha1:e92a5b28f71aea01b281f9c89d97a4bc5b24748f</id>
<content type='text'>
genirq requires that the IRQ requests that do not provided a handler to
use the IRQF_ONESHOT flag. This is to prevent situations in which the irq line
is reenabled while the interrupt is still asserted. While this situation may
not happen in edge type interrupts, genirq still requires to use IRQF_ONESHOT.

Also, remove the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated.

Signed-off-by: Ricardo Neri &lt;ricardo.neri@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
</content>
</entry>
<entry>
<title>OMAPDSS: Apply VENC timings even if panel is disabled</title>
<updated>2012-05-22T08:00:08Z</updated>
<author>
<name>Archit Taneja</name>
</author>
<published>2012-05-21T04:17:12Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c808ab9c82b20227a8b7659c5c8b75290047523c'/>
<id>urn:sha1:c808ab9c82b20227a8b7659c5c8b75290047523c</id>
<content type='text'>
The VENC interfaces uses it's venc_set_timing() function to take in a new set
of timings. If the panel is disabled, it does not disable and re-enable the
interface. Currently, the manager timings are applied in venc_power_on(), these
are not called by set_timings if the panel is disabled. When checking overlay
and manager data, the DSS driver uses the last applied manager timings, and not
the timings held by omap_dss_device struct. Hence, there is a need to apply the
new manager timings even if the panel is disabled.

Apply the manager timings if the VENC panel is disabled.

This is similar to the commit below which fixed the same issue for HDMI/DPI
interfaces:

fcc36619901064a76e15a545ea36d38ba0e54192

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: VENC/DISPC: Delay dividing Y resolution for managers connected to VENC</title>
<updated>2012-05-22T08:00:01Z</updated>
<author>
<name>Archit Taneja</name>
</author>
<published>2012-05-18T09:06:54Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=2aefad49d8e3a898cf629d4c5264ffd061113531'/>
<id>urn:sha1:2aefad49d8e3a898cf629d4c5264ffd061113531</id>
<content type='text'>
DSS2 driver uses the timings in manager's private data to check the validity of
overlay and manager infos written by the user. For VENC interface, we divide the
Y resolution by half when writing to the DISPC_DIGIT_SIZE register as the
content is interlaced. However, the height of the manager/display with respect
to the content shown through VENC still remains the same.

The VENC driver divides the y_res parameter in omap_video_timings by half, and
then applies the configuration. This leads to manager's private data storing
the wrong Y resolution. Hence, overlay related checks fail.

Ensure that manager's private data stores the original timings, and the Y
resolution is halved only when we write to the DISPC register. This is a hack,
the proper solution would be to pass some sort of interlace parameter which
makes the call whether we should divide y_res or not.

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: Support rotation through TILER</title>
<updated>2012-05-22T07:59:15Z</updated>
<author>
<name>Chandrabhanu Mahapatra</name>
</author>
<published>2012-05-11T13:49:55Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=65e006ff4bb06d42b532f866a846db6e4e637723'/>
<id>urn:sha1: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>
</entry>
<entry>
<title>OMAPDSS: remove compiler warnings when CONFIG_BUG=n</title>
<updated>2012-05-22T07:59:14Z</updated>
<author>
<name>Tomi Valkeinen</name>
</author>
<published>2012-05-18T08:47:02Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c6eee968d40d319f0ac7a8a63dcbc633d9e6a2ea'/>
<id>urn:sha1:c6eee968d40d319f0ac7a8a63dcbc633d9e6a2ea</id>
<content type='text'>
If CONFIG_BUG is not enabled, BUG() does not stop the execution. Many
places in code expect the execution to stop, and this causes compiler
warnings about uninitialized variables and returning from a non-void
function without a return value.

This patch fixes the warnings by initializing the variables and
returning properly after BUG() lines. However, the behaviour is still
undefined after the BUG, but this is the choice the user makes when
using CONFIG_BUG=n.

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