<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm/omapdrm, branch v4.14.286</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.286</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.286'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2020-12-29T12:46:54+00:00</updated>
<entry>
<title>drm/omap: dmm_tiler: fix return error code in omap_dmm_probe()</title>
<updated>2020-12-29T12:46:54+00:00</updated>
<author>
<name>Yang Yingliang</name>
<email>yangyingliang@huawei.com</email>
</author>
<published>2020-11-17T06:10:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=8c2031e5c0700ea30df3beae92d70f5f053f5cdb'/>
<id>urn:sha1:8c2031e5c0700ea30df3beae92d70f5f053f5cdb</id>
<content type='text'>
[ Upstream commit 723ae803218da993143387bf966042eccefac077 ]

Return -ENOMEM when allocating refill memory failed.

Fixes: 71e8831f6407 ("drm/omap: DMM/TILER support for OMAP4+ platform")
Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Yang Yingliang &lt;yangyingliang@huawei.com&gt;
Signed-off-by: Thomas Zimmermann &lt;tzimmermann@suse.de&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20201117061045.3452287-1-yangyingliang@huawei.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/omap: fix possible object reference leak</title>
<updated>2020-10-01T11:12:34+00:00</updated>
<author>
<name>Wen Yang</name>
<email>wen.yang99@zte.com.cn</email>
</author>
<published>2019-04-08T02:58:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e12a8a61d193ab8db718ca188cbf452efd960b65'/>
<id>urn:sha1:e12a8a61d193ab8db718ca188cbf452efd960b65</id>
<content type='text'>
[ Upstream commit 47340e46f34a3b1d80e40b43ae3d7a8da34a3541 ]

The call to of_find_matching_node returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.

Detected by coccinelle with the following warnings:
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:212:2-8: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.
drivers/gpu/drm/omapdrm/dss/omapdss-boot-init.c:237:1-7: ERROR: missing of_node_put; acquired a node pointer with refcount incremented on line 209, but without a corresponding object release within this function.

Signed-off-by: Wen Yang &lt;wen.yang99@zte.com.cn&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Reviewed-by: Mukesh Ojha &lt;mojha@codeaurora.org&gt;
Cc: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: David Airlie &lt;airlied@linux.ie&gt;
Cc: Daniel Vetter &lt;daniel@ffwll.ch&gt;
Cc: Sebastian Reichel &lt;sebastian.reichel@collabora.com&gt;
Cc: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
Cc: Markus Elfring &lt;Markus.Elfring@web.de&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/1554692313-28882-2-git-send-email-wen.yang99@zte.com.cn
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/omap: fix max fclk divider for omap36xx</title>
<updated>2019-10-11T16:18:35+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2019-10-02T12:25:42+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2ed8cd8998cd93ac5088b6253f3986ad89aaf36f'/>
<id>urn:sha1:2ed8cd8998cd93ac5088b6253f3986ad89aaf36f</id>
<content type='text'>
commit e2c4ed148cf3ec8669a1d90dc66966028e5fad70 upstream.

The OMAP36xx and AM/DM37x TRMs say that the maximum divider for DSS fclk
(in CM_CLKSEL_DSS) is 32. Experimentation shows that this is not
correct, and using divider of 32 breaks DSS with a flood or underflows
and sync losts. Dividers up to 31 seem to work fine.

There is another patch to the DT files to limit the divider correctly,
but as the DSS driver also needs to know the maximum divider to be able
to iteratively find good rates, we also need to do the fix in the DSS
driver.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Cc: Adam Ford &lt;aford173@gmail.com&gt;
Cc: stable@vger.kernel.org
Link: https://patchwork.freedesktop.org/patch/msgid/20191002122542.8449-1-tomi.valkeinen@ti.com
Tested-by: Adam Ford &lt;aford173@gmail.com&gt;
Reviewed-by: Jyri Sarha &lt;jsarha@ti.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/omap: fix memory barrier bug in DMM driver</title>
<updated>2018-11-21T08:24:03+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2018-09-26T09:11:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=547d528ea395d104dcb31a18b2d51a285e0973aa'/>
<id>urn:sha1:547d528ea395d104dcb31a18b2d51a285e0973aa</id>
<content type='text'>
[ Upstream commit 538f66ba204944470a653a4cccc5f8befdf97c22 ]

A DMM timeout "timed out waiting for done" has been observed on DRA7
devices. The timeout happens rarely, and only when the system is under
heavy load.

Debugging showed that the timeout can be made to happen much more
frequently by optimizing the DMM driver, so that there's almost no code
between writing the last DMM descriptors to RAM, and writing to DMM
register which starts the DMM transaction.

The current theory is that a wmb() does not properly ensure that the
data written to RAM is observable by all the components in the system.

This DMM timeout has caused interesting (and rare) bugs as the error
handling was not functioning properly (the error handling has been fixed
in previous commits):

 * If a DMM timeout happened when a GEM buffer was being pinned for
   display on the screen, a timeout error would be shown, but the driver
   would continue programming DSS HW with broken buffer, leading to
   SYNCLOST floods and possible crashes.

 * If a DMM timeout happened when other user (say, video decoder) was
   pinning a GEM buffer, a timeout would be shown but if the user
   handled the error properly, no other issues followed.

 * If a DMM timeout happened when a GEM buffer was being released, the
   driver does not even notice the error, leading to crashes or hang
   later.

This patch adds wmb() and readl() calls after the last bit is written to
RAM, which should ensure that the execution proceeds only after the data
is actually in RAM, and thus observable by DMM.

The read-back should not be needed. Further study is required to understand
if DMM is somehow special case and read-back is ok, or if DRA7's memory
barriers do not work correctly.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/omap: handle alloc failures in omap_connector</title>
<updated>2018-06-20T19:02:55+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2018-05-02T09:11:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bc707b2d950b549b6071f39fe269291ec6031d5a'/>
<id>urn:sha1:bc707b2d950b549b6071f39fe269291ec6031d5a</id>
<content type='text'>
[ Upstream commit 47aaaec818dfd1009d1358974a2931f05dd57203 ]

Handle memory allocation failures in omap_connector to avoid NULL
derefs.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-5-tomi.valkeinen@ti.com
Reviewed-by: Benoit Parrot &lt;bparrot@ti.com&gt;
Reviewed-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/omap: check return value from soc_device_match</title>
<updated>2018-06-20T19:02:55+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2018-05-02T09:11:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=771f573cc158884bae8cf22d1a5627c396aa868f'/>
<id>urn:sha1:771f573cc158884bae8cf22d1a5627c396aa868f</id>
<content type='text'>
[ Upstream commit 4d6cb5e2fee52af17001e92950f0894304706ee4 ]

soc_device_match() can return NULL, so add a check and fail if
soc_device_match() fails.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180502091159.7071-2-tomi.valkeinen@ti.com
Reviewed-by: Benoit Parrot &lt;bparrot@ti.com&gt;
Reviewed-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/omap: fix possible NULL ref issue in tiler_reserve_2d</title>
<updated>2018-06-20T19:02:55+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2018-03-29T10:40:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=a490d0570df2d7fe7ffe40e4049c7846677aa078'/>
<id>urn:sha1:a490d0570df2d7fe7ffe40e4049c7846677aa078</id>
<content type='text'>
[ Upstream commit 6a0f0c55619f0b82a677cab72e77c3444a5eee58 ]

tiler_reserve_2d allocates memory but does not check if it got the
memory. Add the check and return ENOMEM on failure.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180329104038.29154-2-tomi.valkeinen@ti.com
Reviewed-by: Emil Velikov &lt;emil.velikov@collabora.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/omap: fix uninitialized ret variable</title>
<updated>2018-06-20T19:02:55+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2018-03-29T10:40:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9631f32b61dcdaf4f52976f3706364f470cfcca0'/>
<id>urn:sha1:9631f32b61dcdaf4f52976f3706364f470cfcca0</id>
<content type='text'>
[ Upstream commit 77eeac24b10fc84d3ffd5b11a897dff88dde244d ]

audio_config function for both HDMI4 and HDMI5 return uninitialized
value as the error code if the display is not currently enabled. For
some reason this has not caused any issues.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180329104038.29154-1-tomi.valkeinen@ti.com
Reviewed-by: Emil Velikov &lt;emil.velikov@collabora.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm/omap: silence unititialized variable warning</title>
<updated>2018-06-20T19:02:54+00:00</updated>
<author>
<name>Dan Carpenter</name>
<email>dan.carpenter@oracle.com</email>
</author>
<published>2018-04-18T14:29:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ca3c09a74945bfa9db326cee60601f60237e5606'/>
<id>urn:sha1:ca3c09a74945bfa9db326cee60601f60237e5606</id>
<content type='text'>
[ Upstream commit 4a9fbfcab19d3f71ad2bf0bcb653c4ee84e69c7f ]

Smatch complains that "area_free" could be used without being
initialized.  This code is several years old and premusably works fine
so this can't be a very serious bug.  But it's easy enough to silence
the warning.  If "area_free" is false at the end of the function then
we return -ENOMEM.

Signed-off-by: Dan Carpenter &lt;dan.carpenter@oracle.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180418142937.GA13828@mwanda
Signed-off-by: Sean Paul &lt;seanpaul@chromium.org&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>drm: omapdrm: dss: Move initialization code from component bind to probe</title>
<updated>2018-05-30T05:52:37+00:00</updated>
<author>
<name>Laurent Pinchart</name>
<email>laurent.pinchart@ideasonboard.com</email>
</author>
<published>2018-02-11T13:07:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ee6f703020ab473b72298fc63b61060f8c8bd1c2'/>
<id>urn:sha1:ee6f703020ab473b72298fc63b61060f8c8bd1c2</id>
<content type='text'>
[ Upstream commit 215003b4ae1d47035092fef73b6a22aa82037091 ]

There's no reason to delay initialization of most of the driver (such as
mapping memory I/O, getting clocks or enabling runtime PM) to the
component master bind handler.

This additionally fixes a real PM issue caused enabling runtime PM in
the bind handler.

The bind handler performs the following sequence of PM operations:

	pm_runtime_enable(dev);
	pm_runtime_get_sync(dev);

	... (access the hardware to read the device revision) ...

	pm_runtime_put_sync(dev);

If a failure occurs at this point, the error path calls
pm_runtime_disable() to balance the pm_runtime_enable() call.

To understand the problem, it should be noted that the bind handler is
called when one of the component registers itself, which happens in the
component's probe handler. Furthermore, as the components are children
of the DSS, the device core calls pm_runtime_get_sync() on the DSS
platform device before calling the component's probe handler. This
increases the DSS power usage count but doesn't runtime resume the
device, as runtime PM is disabled at that point.

The bind handler is thus called with runtime PM disabled, with the
device runtime suspended, but with the power usage count larger than 0.
The pm_runtime_get_sync() call will thus further increase the power
usage count and runtime resume the device. The pm_runtime_put_sync()
handler will decrease the power usage count to a non-zero value and will
thus not suspend the device. Finally, the pm_runtime_disable() call will
disable runtime PM, preventing the pm_runtime_put() call in the device
core from runtime suspending the device. The DSS device is thus left
powered on.

To fix this, move the initialization code from the bind handler to the
probe handler.

Signed-off-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Reviewed-by: Sebastian Reichel &lt;sebastian.reichel@collabora.co.uk&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
