<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/gpu, branch linux-4.1.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-4.1.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2018-05-23T01:36:34Z</updated>
<entry>
<title>drm/radeon: Fix PCIe lane width calculation</title>
<updated>2018-05-23T01:36:34Z</updated>
<author>
<name>Paul Parsons</name>
<email>lost.distance@yahoo.com</email>
</author>
<published>2016-04-02T11:32:30Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c2d4fe84bc469d2847bdb16f9e571001804fa178'/>
<id>urn:sha1:c2d4fe84bc469d2847bdb16f9e571001804fa178</id>
<content type='text'>
[ Upstream commit 85e290d92b4b794d0c758c53007eb4248d385386 ]

Two years ago I tried an AMD Radeon E8860 embedded GPU with the drm driver.
The dmesg output included driver warnings about an invalid PCIe lane width.
Tracking the problem back led to si_set_pcie_lane_width_in_smc().
The calculation of the lane widths via ATOM_PPLIB_PCIE_LINK_WIDTH_MASK and
ATOM_PPLIB_PCIE_LINK_WIDTH_SHIFT macros did not increment the resulting
value, per the comment in pptable.h ("lanes - 1"), and per usage elsewhere.
Applying the increment silenced the warnings.
The code has not changed since, so either my analysis was incorrect or the
bug has gone unnoticed. Hence submitting this as an RFC.

Acked-by: Christian König &lt;christian.koenig@amd.com&gt;
Acked-by: Chunming Zhou &lt;david1.zhou@amd.com&gt;
Signed-off-by: Paul Parsons &lt;lost.distance@yahoo.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>radeon: hide pointless #warning when compile testing</title>
<updated>2018-05-23T01:36:31Z</updated>
<author>
<name>Arnd Bergmann</name>
<email>arnd@arndb.de</email>
</author>
<published>2018-02-16T15:26:57Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=a890908a85122c57d76cd27f522982c89329394d'/>
<id>urn:sha1:a890908a85122c57d76cd27f522982c89329394d</id>
<content type='text'>
[ Upstream commit c02216acf4177c4411d33735c81cad687790fa59 ]

In randconfig testing, we sometimes get this warning:

drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_create':
drivers/gpu/drm/radeon/radeon_object.c:242:2: error: #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance thanks to write-combining [-Werror=cpp]
 #warning Please enable CONFIG_MTRR and CONFIG_X86_PAT for better performance \

This is rather annoying since almost all other code produces no build-time
output unless we have found a real bug. We already fixed this in the
amdgpu driver in commit 31bb90f1cd08 ("drm/amdgpu: shut up #warning for
compile testing") by adding a CONFIG_COMPILE_TEST check last year and
agreed to do the same here, but both Michel and I then forgot about it
until I came across the issue again now.

For stable kernels, as this is one of very few remaining randconfig
warnings in 4.14.

Cc: stable@vger.kernel.org
Link: https://patchwork.kernel.org/patch/9550009/
Signed-off-by: Arnd Bergmann &lt;arnd@arndb.de&gt;
Signed-off-by: Michel Dänzer &lt;michel.daenzer@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>drm/omap: fix tiled buffer stride calculations</title>
<updated>2018-05-23T01:36:27Z</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2017-05-18T08:51:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=ee434ab0065be95732a42d30bbcafed8910820a4'/>
<id>urn:sha1:ee434ab0065be95732a42d30bbcafed8910820a4</id>
<content type='text'>
[ Upstream commit cc8dd7661ccc2d8dc88921da8e6cc7c2fcdb0341 ]

omap_gem uses page alignment for buffer stride. The related calculations
are a bit off, though, as byte stride of 4096 gets aligned to 8192,
instead of 4096.

This patch changes the code to use DIV_ROUND_UP(), which fixes those
calculations and makes them more readable.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Reviewed-by: Laurent Pinchart &lt;laurent.pinchart@ideasonboard.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>drm: udl: Properly check framebuffer mmap offsets</title>
<updated>2018-05-23T01:33:53Z</updated>
<author>
<name>Greg Kroah-Hartman</name>
<email>gregkh@linuxfoundation.org</email>
</author>
<published>2018-03-21T15:45:53Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=631334908d120129678f68cdcca333565748fde7'/>
<id>urn:sha1:631334908d120129678f68cdcca333565748fde7</id>
<content type='text'>
[ Upstream commit 3b82a4db8eaccce735dffd50b4d4e1578099b8e8 ]

The memmap options sent to the udl framebuffer driver were not being
checked for all sets of possible crazy values.  Fix this up by properly
bounding the allowed values.

Reported-by: Eyal Itkin &lt;eyalit@checkpoint.com&gt;
Cc: stable &lt;stable@vger.kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
Signed-off-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20180321154553.GA18454@kroah.com
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>drm/radeon: Don't turn off DP sink when disconnected</title>
<updated>2018-05-23T01:33:53Z</updated>
<author>
<name>Michel Dänzer</name>
<email>michel.daenzer@amd.com</email>
</author>
<published>2018-03-14T17:14:04Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1f5c2b9f2d1d01678c7c0698f8cbcbaec8ceafd9'/>
<id>urn:sha1:1f5c2b9f2d1d01678c7c0698f8cbcbaec8ceafd9</id>
<content type='text'>
[ Upstream commit a3f73c8cf43858455a979d0f8354815e1443c496 ]

Turning off the sink in this case causes various issues, because
userspace expects it to stay on until it turns it off explicitly.

Instead, turn the sink off and back on when a display is connected
again. This dance seems necessary for link training to work correctly.

Bugzilla: https://bugs.freedesktop.org/105308
Cc: stable@vger.kernel.org
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Michel Dänzer &lt;michel.daenzer@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>drm/omap: DMM: Check for DMM readiness after successful transaction commit</title>
<updated>2018-05-23T01:33:51Z</updated>
<author>
<name>Peter Ujfalusi</name>
<email>peter.ujfalusi@ti.com</email>
</author>
<published>2017-09-29T11:49:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=6d999a73b81898942e4a02307f19a8ca24fd50cc'/>
<id>urn:sha1:6d999a73b81898942e4a02307f19a8ca24fd50cc</id>
<content type='text'>
[ Upstream commit b7ea6b286c4051e043f691781785e3c4672f014a ]

Check the status of the DMM engine after it is reported that the
transaction was completed as in rare cases the engine might not reached a
working state.

The wait_status() will print information in case the DMM is not reached the
expected state and the dmm_txn_commit() will return with an error code to
make sure that we are not continuing with a broken setup.

Signed-off-by: Peter Ujfalusi &lt;peter.ujfalusi@ti.com&gt;
Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>drm/msm: fix leak in failed get_pages</title>
<updated>2018-05-23T01:33:51Z</updated>
<author>
<name>Prakash Kamliya</name>
<email>pkamliya@codeaurora.org</email>
</author>
<published>2017-12-04T13:40:15Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=c67f1987fdf46cb4083d55ffa7bf8495a893abdb'/>
<id>urn:sha1:c67f1987fdf46cb4083d55ffa7bf8495a893abdb</id>
<content type='text'>
[ Upstream commit 62e3a3e342af3c313ab38603811ecdb1fcc79edb ]

get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.

Signed-off-by: Prakash Kamliya &lt;pkamliya@codeaurora.org&gt;
Signed-off-by: Sharat Masetty &lt;smasetty@codeaurora.org&gt;
Signed-off-by: Rob Clark &lt;robdclark@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>drm/amdkfd: Fix memory leaks in kfd topology</title>
<updated>2018-05-23T01:33:47Z</updated>
<author>
<name>Yong Zhao</name>
<email>yong.zhao@amd.com</email>
</author>
<published>2017-12-09T04:08:48Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=2847dd98bdd67861330712492d9538079948986e'/>
<id>urn:sha1:2847dd98bdd67861330712492d9538079948986e</id>
<content type='text'>
[ Upstream commit 5108d768408abc80e4e8d99f5b406a73cb04056b ]

Kobject created using kobject_create_and_add() can be freed using
kobject_put() when there is no referenece any more. However,
kobject memory allocated with kzalloc() has to set up a release
callback in order to free it when the counter decreases to 0.
Otherwise it causes memory leak.

Signed-off-by: Yong Zhao &lt;yong.zhao@amd.com&gt;
Signed-off-by: Felix Kuehling &lt;Felix.Kuehling@amd.com&gt;
Reviewed-by: Oded Gabbay &lt;oded.gabbay@gmail.com&gt;
Signed-off-by: Oded Gabbay &lt;oded.gabbay@gmail.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>drm/edid: set ELD connector type in drm_edid_to_eld()</title>
<updated>2018-05-23T01:33:46Z</updated>
<author>
<name>Jani Nikula</name>
<email>jani.nikula@intel.com</email>
</author>
<published>2017-11-01T14:20:58Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=51c73403fc125facc4b63a7a052d954baaf285e1'/>
<id>urn:sha1:51c73403fc125facc4b63a7a052d954baaf285e1</id>
<content type='text'>
[ Upstream commit 1d1c36650752b7fb81cee515a9bba4131cac4b7c ]

Since drm_edid_to_eld() knows the connector type, we can set the type in
ELD while at it. Most connectors this gets called on are not DP
encoders, and with the HDMI type being 0, this does not change behaviour
for non-DP.

For i915 having this in place earlier would have saved a considerable
amount of debugging that lead to the fix 2d8f63297b9f ("drm/i915: always
update ELD connector type after get modes"). I don't see other drivers,
even the ones calling drm_edid_to_eld() on DP connectors, setting the
connector type in ELD.

Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: Christian König &lt;christian.koenig@amd.com&gt;
Cc: Archit Taneja &lt;architt@codeaurora.org&gt;
Cc: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Cc: Russell King &lt;linux@armlinux.org.uk&gt;
Cc: CK Hu &lt;ck.hu@mediatek.com&gt;
Cc: Philipp Zabel &lt;p.zabel@pengutronix.de&gt;
Cc: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Cc: Mark Yao &lt;mark.yao@rock-chips.com&gt;
Cc: Benjamin Gaignard &lt;benjamin.gaignard@linaro.org&gt;
Cc: Vincent Abriou &lt;vincent.abriou@st.com&gt;
Cc: Thierry Reding &lt;thierry.reding@gmail.com&gt;
Cc: Eric Anholt &lt;eric@anholt.net&gt;
Reviewed-by: Ville Syrjälä &lt;ville.syrjala@linux.intel.com&gt;
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Acked-by: Thierry Reding &lt;treding@nvidia.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/d527b31619528c477c2c136f25cdf118bc0cfc1d.1509545641.git.jani.nikula@intel.com
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
<entry>
<title>drm/radeon: Fail fb creation from imported dma-bufs.</title>
<updated>2018-05-23T01:33:45Z</updated>
<author>
<name>Christopher James Halse Rogers</name>
<email>christopher.halse.rogers@canonical.com</email>
</author>
<published>2017-03-29T04:00:54Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=603e2917065a8a587527e0a586d6cc7c4acf8e7d'/>
<id>urn:sha1:603e2917065a8a587527e0a586d6cc7c4acf8e7d</id>
<content type='text'>
[ Upstream commit a294043b2fbd8de69d161457ed0c7a4026bbfa5a ]

Any use of the framebuffer will migrate it to VRAM, which is not sensible for
an imported dma-buf.

v2: Use DRM_DEBUG_KMS to prevent userspace accidentally spamming dmesg.

Reviewed-by: Michel Dänzer &lt;michel.daenzer@amd.com&gt;
Reviewed-by: Christian König &lt;christian.koenig@amd.com&gt;
Signed-off-by: Christopher James Halse Rogers &lt;christopher.halse.rogers@canonical.com&gt;
CC: amd-gfx@lists.freedesktop.org
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;alexander.levin@microsoft.com&gt;
</content>
</entry>
</feed>
