<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu/drm, branch v4.14.152</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.152</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.14.152'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-10-29T08:17:36+00:00</updated>
<entry>
<title>drm/amdgpu: Bail earlier when amdgpu.cik_/si_support is not set to 1</title>
<updated>2019-10-29T08:17:36+00:00</updated>
<author>
<name>Hans de Goede</name>
<email>hdegoede@redhat.com</email>
</author>
<published>2019-10-10T16:28:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=df984262a4bcd76f0ef7071ee73329b0fc430d59'/>
<id>urn:sha1:df984262a4bcd76f0ef7071ee73329b0fc430d59</id>
<content type='text'>
commit 984d7a929ad68b7be9990fc9c5cfa5d5c9fc7942 upstream.

Bail from the pci_driver probe function instead of from the drm_driver
load function.

This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events to
userspace.

Specifically this avoids triggering the (userspace) bug fixed by this
plymouth merge-request:
https://gitlab.freedesktop.org/plymouth/plymouth/merge_requests/59

Note that despite that being a userspace bug, not sending unnecessary
udev events is a good idea in general.

BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1490490
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Hans de Goede &lt;hdegoede@redhat.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/edid: Add 6 bpc quirk for SDC panel in Lenovo G50</title>
<updated>2019-10-29T08:17:35+00:00</updated>
<author>
<name>Kai-Heng Feng</name>
<email>kai.heng.feng@canonical.com</email>
</author>
<published>2019-04-02T03:30:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=f991b1fa0ded689f980cc25312b5003f35add8bf'/>
<id>urn:sha1:f991b1fa0ded689f980cc25312b5003f35add8bf</id>
<content type='text'>
commit 11bcf5f78905b90baae8fb01e16650664ed0cb00 upstream.

Another panel that needs 6BPC quirk.

BugLink: https://bugs.launchpad.net/bugs/1819968
Cc: &lt;stable@vger.kernel.org&gt; # v4.8+
Reviewed-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Kai-Heng Feng &lt;kai.heng.feng@canonical.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190402033037.21877-1-kai.heng.feng@canonical.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>Revert "drm/radeon: Fix EEH during kexec"</title>
<updated>2019-10-29T08:17:00+00:00</updated>
<author>
<name>Alex Deucher</name>
<email>alexander.deucher@amd.com</email>
</author>
<published>2019-10-09T18:12:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2e18e22063986658f0ebfb90f742ab1f6e378f33'/>
<id>urn:sha1:2e18e22063986658f0ebfb90f742ab1f6e378f33</id>
<content type='text'>
[ Upstream commit 8d13c187c42e110625d60094668a8f778c092879 ]

This reverts commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6.

This breaks some boards.  Maybe just enable this on PPC for
now?

Bug: https://bugzilla.kernel.org/show_bug.cgi?id=205147
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: stable@vger.kernel.org
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/amdgpu: Check for valid number of registers to read</title>
<updated>2019-10-11T16:18:40+00:00</updated>
<author>
<name>Trek</name>
<email>trek00@inbox.ru</email>
</author>
<published>2019-08-31T19:25:36+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=cc376abf178b7ddfb5f620a8a72d9fe048828203'/>
<id>urn:sha1:cc376abf178b7ddfb5f620a8a72d9fe048828203</id>
<content type='text'>
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]

Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15 (0x2644-0x2673).

Bug: https://bugs.freedesktop.org/show_bug.cgi?id=111273
Signed-off-by: Trek &lt;trek00@inbox.ru&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
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/amdgpu/si: fix ASIC tests</title>
<updated>2019-10-07T16:55:04+00:00</updated>
<author>
<name>Jean Delvare</name>
<email>jdelvare@suse.de</email>
</author>
<published>2019-08-28T15:05:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=02c333e27324a9d627e3db8623cc93479aa96c3a'/>
<id>urn:sha1:02c333e27324a9d627e3db8623cc93479aa96c3a</id>
<content type='text'>
[ Upstream commit 77efe48a729588527afb4d5811b9e0acb29f5e51 ]

Comparing adev-&gt;family with CHIP constants is not correct.
adev-&gt;family can only be compared with AMDGPU_FAMILY constants and
adev-&gt;asic_type is the struct member to compare with CHIP constants.
They are separate identification spaces.

Signed-off-by: Jean Delvare &lt;jdelvare@suse.de&gt;
Fixes: 62a37553414a ("drm/amdgpu: add si implementation v10")
Cc: Ken Wang &lt;Qingqing.Wang@amd.com&gt;
Cc: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Cc: "Christian König" &lt;christian.koenig@amd.com&gt;
Cc: "David (ChunMing) Zhou" &lt;David1.Zhou@amd.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/nouveau/volt: Fix for some cards having 0 maximum voltage</title>
<updated>2019-10-07T16:55:04+00:00</updated>
<author>
<name>Mark Menzynski</name>
<email>mmenzyns@redhat.com</email>
</author>
<published>2019-08-02T09:21:00+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=2e137f0e7d06b791eb945855dae2ead7f92f1b15'/>
<id>urn:sha1:2e137f0e7d06b791eb945855dae2ead7f92f1b15</id>
<content type='text'>
[ Upstream commit a1af2afbd244089560794c260b2d4326a86e39b6 ]

Some, mostly Fermi, vbioses appear to have zero max voltage. That causes Nouveau to not parse voltage entries, thus users not being able to set higher clocks.

When changing this value Nvidia driver still appeared to ignore it, and I wasn't able to find out why, thus the code is ignoring the value if it is zero.

CC: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Signed-off-by: Mark Menzynski &lt;mmenzyns@redhat.com&gt;
Reviewed-by: Karol Herbst &lt;kherbst@redhat.com&gt;
Signed-off-by: Ben Skeggs &lt;bskeggs@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>gpu: drm: radeon: Fix a possible null-pointer dereference in radeon_connector_set_property()</title>
<updated>2019-10-07T16:54:59+00:00</updated>
<author>
<name>Jia-Ju Bai</name>
<email>baijiaju1990@gmail.com</email>
</author>
<published>2019-07-29T08:36:44+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1e662250f4db74614ec28f1080bec3d04f3a4be1'/>
<id>urn:sha1:1e662250f4db74614ec28f1080bec3d04f3a4be1</id>
<content type='text'>
[ Upstream commit f3eb9b8f67bc28783eddc142ad805ebdc53d6339 ]

In radeon_connector_set_property(), there is an if statement on line 743
to check whether connector-&gt;encoder is NULL:
    if (connector-&gt;encoder)

When connector-&gt;encoder is NULL, it is used on line 755:
    if (connector-&gt;encoder-&gt;crtc)

Thus, a possible null-pointer dereference may occur.

To fix this bug, connector-&gt;encoder is checked before being used.

This bug is found by a static analysis tool STCheck written by us.

Signed-off-by: Jia-Ju Bai &lt;baijiaju1990@gmail.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/radeon: Fix EEH during kexec</title>
<updated>2019-10-07T16:54:58+00:00</updated>
<author>
<name>KyleMahlkuch</name>
<email>kmahlkuc@linux.vnet.ibm.com</email>
</author>
<published>2019-07-31T22:10:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=09a0e83e032672d80dfc7ade5759712342cc4b63'/>
<id>urn:sha1:09a0e83e032672d80dfc7ade5759712342cc4b63</id>
<content type='text'>
[ Upstream commit 6f7fe9a93e6c09bf988c5059403f5f88e17e21e6 ]

During kexec some adapters hit an EEH since they are not properly
shut down in the radeon_pci_shutdown() function. Adding
radeon_suspend_kms() fixes this issue.

Signed-off-by: KyleMahlkuch &lt;kmahlkuc@linux.vnet.ibm.com&gt;
Signed-off-by: Alex Deucher &lt;alexander.deucher@amd.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/stm: attach gem fence to atomic state</title>
<updated>2019-10-07T16:54:58+00:00</updated>
<author>
<name>Ahmad Fatoum</name>
<email>a.fatoum@pengutronix.de</email>
</author>
<published>2019-07-12T08:42:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3ba3b24a8f3d5e425edd58ffb785c77b892b0a04'/>
<id>urn:sha1:3ba3b24a8f3d5e425edd58ffb785c77b892b0a04</id>
<content type='text'>
[ Upstream commit 8fabc9c3109a71b3577959a05408153ae69ccd8d ]

To properly synchronize with other devices the fence from the GEM
object backing the framebuffer needs to be attached to the atomic
state, so the commit work can wait on fence signaling.

Signed-off-by: Ahmad Fatoum &lt;a.fatoum@pengutronix.de&gt;
Signed-off-by: Lucas Stach &lt;l.stach@pengutronix.de&gt;
Acked-by: Philippe Cornu &lt;philippe.cornu@st.com&gt;
Tested-by: Philippe Cornu &lt;philippe.cornu@st.com&gt;
Signed-off-by: Benjamin Gaignard &lt;benjamin.gaignard@linaro.org&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190712084228.8338-1-l.stach@pengutronix.de
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
