<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/gpu, branch v4.19.24</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.24</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v4.19.24'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2019-02-20T09:25:50+00:00</updated>
<entry>
<title>drm/i915: Prevent a race during I915_GEM_MMAP ioctl with WC set</title>
<updated>2019-02-20T09:25:50+00:00</updated>
<author>
<name>Joonas Lahtinen</name>
<email>joonas.lahtinen@linux.intel.com</email>
</author>
<published>2019-02-07T08:54:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=6a204bd5f1e6d75de6c2e88be079c638472bee72'/>
<id>urn:sha1:6a204bd5f1e6d75de6c2e88be079c638472bee72</id>
<content type='text'>
commit 2e7bd10e05afb866b5fb13eda25095c35d7a27cc upstream.

Make sure the underlying VMA in the process address space is the
same as it was during vm_mmap to avoid applying WC to wrong VMA.

A more long-term solution would be to have vm_mmap_locked variant
in linux/mmap.h for when caller wants to hold mmap_sem for an
extended duration.

v2:
- Refactor the compare function

Fixes: 1816f9236303 ("drm/i915: Support creation of unbound wc user mappings for objects")
Reported-by: Adam Zabrocki &lt;adamza@microsoft.com&gt;
Suggested-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.0+
Cc: Akash Goel &lt;akash.goel@intel.com&gt;
Cc: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Cc: Tvrtko Ursulin &lt;tvrtko.ursulin@linux.intel.com&gt;
Cc: Adam Zabrocki &lt;adamza@microsoft.com&gt;
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Reviewed-by: Tvrtko Ursulin &lt;tvrtko.ursulin@intel.com&gt; #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20190207085454.10598-1-joonas.lahtinen@linux.intel.com
(cherry picked from commit 5c4604e757ba9b193b09768d75a7d2105a5b883f)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/i915: Block fbdev HPD processing during suspend</title>
<updated>2019-02-20T09:25:49+00:00</updated>
<author>
<name>Lyude Paul</name>
<email>lyude@redhat.com</email>
</author>
<published>2019-01-29T19:09:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4631e0b4cf46795793cd420fcdab09e26256d2e6'/>
<id>urn:sha1:4631e0b4cf46795793cd420fcdab09e26256d2e6</id>
<content type='text'>
commit e8a8fedd57fdcebf0e4f24ef0fc7e29323df8e66 upstream.

When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.

However, sending a hotplug event involves calling
drm_fb_helper_hotplug_event(), which in turn results in fbcon doing a
connector reprobe in the caller's thread - something we can't do at the
point in which i915 calls drm_dp_mst_topology_mgr_resume() since
hotplugging hasn't been fully initialized yet.

This currently causes some rather subtle but fatal issues. For example,
on my T480s the laptop dock connected to it usually disappears during a
suspend cycle, and comes back up a short while after the system has been
resumed. This guarantees pretty much every suspend and resume cycle,
drm_dp_mst_topology_mgr_set_mst(mgr, false); will be caused and in turn,
a connector hotplug will occur. Now it's Rute Goldberg time: when the
connector hotplug occurs, i915 reprobes /all/ of the connectors,
including eDP. However, eDP probing requires that we power on the panel
VDD which in turn, grabs a wakeref to the appropriate power domain on
the GPU (on my T480s, this is the PORT_DDI_A_IO domain). This is where
things start breaking, since this all happens before
intel_power_domains_enable() is called we end up leaking the wakeref
that was acquired and never releasing it later. Come next suspend/resume
cycle, this causes us to fail to shut down the GPU properly, which
causes it not to resume properly and die a horrible complicated death.

(as a note: this only happens when there's both an eDP panel and MST
topology connected which is removed mid-suspend. One or the other seems
to always be OK).

We could try to fix the VDD wakeref leak, but this doesn't seem like
it's worth it at all since we aren't able to handle hotplug detection
while resuming anyway. So, let's go with a more robust solution inspired
by nouveau: block fbdev from handling hotplug events until we resume
fbdev. This allows us to still send sysfs hotplug events to be handled
later by user space while we're resuming, while also preventing us from
actually processing any hotplug events we receive until it's safe.

This fixes the wakeref leak observed on the T480s and as such, also
fixes suspend/resume with MST topologies connected on this machine.

Changes since v2:
* Don't call drm_fb_helper_hotplug_event() under lock, do it after lock
  (Chris Wilson)
* Don't call drm_fb_helper_hotplug_event() in
  intel_fbdev_output_poll_changed() under lock (Chris Wilson)
* Always set ifbdev-&gt;hpd_waiting (Chris Wilson)

Signed-off-by: Lyude Paul &lt;lyude@redhat.com&gt;
Fixes: 0e32b39ceed6 ("drm/i915: add DP 1.2 MST support (v0.7)")
Cc: Todd Previte &lt;tprevite@gmail.com&gt;
Cc: Dave Airlie &lt;airlied@redhat.com&gt;
Cc: Jani Nikula &lt;jani.nikula@linux.intel.com&gt;
Cc: Joonas Lahtinen &lt;joonas.lahtinen@linux.intel.com&gt;
Cc: Rodrigo Vivi &lt;rodrigo.vivi@intel.com&gt;
Cc: Imre Deak &lt;imre.deak@intel.com&gt;
Cc: intel-gfx@lists.freedesktop.org
Cc: &lt;stable@vger.kernel.org&gt; # v3.17+
Reviewed-by: Chris Wilson &lt;chris@chris-wilson.co.uk&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190129191001.442-2-lyude@redhat.com
(cherry picked from commit fe5ec65668cdaa4348631d8ce1766eed43b33c10)
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/vkms: Fix license inconsistent</title>
<updated>2019-02-20T09:25:49+00:00</updated>
<author>
<name>Rodrigo Siqueira</name>
<email>rodrigosiqueiramelo@gmail.com</email>
</author>
<published>2019-02-06T14:01:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=de48b5f3d0ef74baebe61d68919f1cb833070be7'/>
<id>urn:sha1:de48b5f3d0ef74baebe61d68919f1cb833070be7</id>
<content type='text'>
commit 7fd56e0260a22c0cfaf9adb94a2427b76e239dd0 upstream.

Fixes license inconsistent related to the VKMS driver and remove the
redundant boilerplate comment.

Fixes: 854502fa0a38 ("drm/vkms: Add basic CRTC initialization")

Cc: stable@vger.kernel.org
Signed-off-by: Rodrigo Siqueira &lt;rodrigosiqueiramelo@gmail.com&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190206140116.7qvy2lpwbcd7wds6@smtp.gmail.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm: Use array_size() when creating lease</title>
<updated>2019-02-20T09:25:49+00:00</updated>
<author>
<name>Matthew Wilcox</name>
<email>willy@infradead.org</email>
</author>
<published>2019-02-14T19:03:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3312e0ae2faf4336e9549f13ec0671ec263f4b40'/>
<id>urn:sha1:3312e0ae2faf4336e9549f13ec0671ec263f4b40</id>
<content type='text'>
commit 69ef943dbc14b21987c79f8399ffea08f9a1b446 upstream.

Passing an object_count of sufficient size will make
object_count * 4 wrap around to be very small, then a later function
will happily iterate off the end of the object_ids array.  Using
array_size() will saturate at SIZE_MAX, the kmalloc() will fail and
we'll return an -ENOMEM to the norty userspace.

Fixes: 62884cd386b8 ("drm: Add four ioctls for managing drm mode object leases [v7]")
Signed-off-by: Matthew Wilcox &lt;willy@infradead.org&gt;
Acked-by: Kees Cook &lt;keescook@chromium.org&gt;
Acked-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Cc: &lt;stable@vger.kernel.org&gt; # v4.15+
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>drm/nouveau/falcon: avoid touching registers if engine is off</title>
<updated>2019-02-20T09:25:43+00:00</updated>
<author>
<name>Ilia Mirkin</name>
<email>imirkin@alum.mit.edu</email>
</author>
<published>2018-12-14T03:44:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4b709998564b1d5b9606dc7923cbddbb5e91544d'/>
<id>urn:sha1:4b709998564b1d5b9606dc7923cbddbb5e91544d</id>
<content type='text'>
[ Upstream commit a5176a4cb85bb6213daadf691097cf411da35df2 ]

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108980
Signed-off-by: Ilia Mirkin &lt;imirkin@alum.mit.edu&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>drm/nouveau: Don't disable polling in fallback mode</title>
<updated>2019-02-20T09:25:43+00:00</updated>
<author>
<name>Takashi Iwai</name>
<email>tiwai@suse.de</email>
</author>
<published>2018-09-12T10:58:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=85a088cc4c8eeeb2e4cf6c7e0efde52045360b05'/>
<id>urn:sha1:85a088cc4c8eeeb2e4cf6c7e0efde52045360b05</id>
<content type='text'>
[ Upstream commit 118780066e30c34de3d9349710b51780bfa0ba83 ]

When a fan is controlled via linear fallback without cstate, we
shouldn't stop polling.  Otherwise it won't be adjusted again and
keeps running at an initial crazy pace.

Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan control is specified in the vbios")
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447
Reported-by: Thomas Blume &lt;thomas.blume@suse.com&gt;
Signed-off-by: Takashi Iwai &lt;tiwai@suse.de&gt;
Reviewed-by: Martin Peres &lt;martin.peres@free.fr&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>drm/amdgpu: set WRITE_BURST_LENGTH to 64B to workaround SDMA1 hang</title>
<updated>2019-02-20T09:25:42+00:00</updated>
<author>
<name>Jim Qu</name>
<email>Jim.Qu@amd.com</email>
</author>
<published>2018-12-17T09:00:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=46bf9a8c8bb0f2c746163737da5c7e4a42b48d61'/>
<id>urn:sha1:46bf9a8c8bb0f2c746163737da5c7e4a42b48d61</id>
<content type='text'>
[ Upstream commit 0c6c8125582714e1fd3544983eba3d750db0f5b8 ]

effect asics: VEGA10 and VEGA12

Signed-off-by: Jim Qu &lt;Jim.Qu@amd.com&gt;
Acked-by: Alex Deucher &lt;alexander.deucher@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/bridge: tc358767: fix output H/V syncs</title>
<updated>2019-02-20T09:25:41+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2019-01-03T11:59:53+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=9e4a7beedf43f141e189e0688e412b53cb58b427'/>
<id>urn:sha1:9e4a7beedf43f141e189e0688e412b53cb58b427</id>
<content type='text'>
[ Upstream commit 7923e09c7a766e2d58de7fc395bb84c18e5bc625 ]

The H and V syncs of the DP output are always set to active high. This
patch fixes the syncs by configuring them according to the videomode.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Reviewed-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-7-tomi.valkeinen@ti.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: tc358767: reject modes which require too much BW</title>
<updated>2019-02-20T09:25:41+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2019-01-03T11:59:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=0c13400bc7433a728e510e80a02d580668445799'/>
<id>urn:sha1:0c13400bc7433a728e510e80a02d580668445799</id>
<content type='text'>
[ Upstream commit 51b9e62eb6950c762162ab7eb8390990179be067 ]

The current driver accepts any videomode with pclk &lt; 154MHz. This is not
correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be
supported.

Add code to reject modes that require more bandwidth that is available.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Reviewed-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-6-tomi.valkeinen@ti.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>drm/bridge: tc358767: fix initial DP0/1_SRCCTRL value</title>
<updated>2019-02-20T09:25:40+00:00</updated>
<author>
<name>Tomi Valkeinen</name>
<email>tomi.valkeinen@ti.com</email>
</author>
<published>2019-01-03T11:59:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ad9675e47b495285e3be62a0d9c87edffd0ae8c3'/>
<id>urn:sha1:ad9675e47b495285e3be62a0d9c87edffd0ae8c3</id>
<content type='text'>
[ Upstream commit 9a63bd6fe1b5590ffa42ae2ed22ee21363293e31 ]

Initially DP0_SRCCTRL is set to a static value which includes
DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of
1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number.

This patch changes the configuration as follows:

Configure DP0_SRCCTRL by using tc_srcctrl() which provides the correct
value.

DP1_SRCCTRL needs two bits to be set to the same value as DP0_SRCCTRL:
SSCG and BW27. All other bits can be zero.

Signed-off-by: Tomi Valkeinen &lt;tomi.valkeinen@ti.com&gt;
Reviewed-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Signed-off-by: Andrzej Hajda &lt;a.hajda@samsung.com&gt;
Link: https://patchwork.freedesktop.org/patch/msgid/20190103115954.12785-5-tomi.valkeinen@ti.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
