<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-stable.git/drivers/gpu, branch linux-4.6.y</title>
<subtitle>Linux kernel stable tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/'/>
<entry>
<title>drm/i915: Revert DisplayPort fast link training feature</title>
<updated>2016-07-27T15:42:25+00:00</updated>
<author>
<name>Mika Kahola</name>
<email>mika.kahola@intel.com</email>
</author>
<published>2016-06-20T08:10:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=b0f7095f8bd503eddf9a91a258e796da0058f182'/>
<id>b0f7095f8bd503eddf9a91a258e796da0058f182</id>
<content type='text'>
commit 34511dce4b35685d3988d5c8b100d11a068db5bd upstream.

It has been found out that in some HW combination the DisplayPort
fast link training feature caused screen flickering. Let's revert
this feature for now until we can ensure that the feature works for
all platforms.

This is a manual revert of commits 5fa836a9d859 ("drm/i915: DP link
training optimization") and 4e96c97742f4 ("drm/i915: eDP link training
optimization").

Fixes: 5fa836a9d859 ("drm/i915: DP link training optimization")
Fixes: 4e96c97742f4 ("drm/i915: eDP link training optimization")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
Reviewed-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Mika Kahola &lt;mika.kahola@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1466410226-19543-1-git-send-email-mika.kahola@intel.com
(cherry picked from commit 91df09d92ad82c8778ca218097bf827f154292ca)
Signed-off-by: Joakim Tjernlund &lt;joakim.tjernlund@infinera.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 34511dce4b35685d3988d5c8b100d11a068db5bd upstream.

It has been found out that in some HW combination the DisplayPort
fast link training feature caused screen flickering. Let's revert
this feature for now until we can ensure that the feature works for
all platforms.

This is a manual revert of commits 5fa836a9d859 ("drm/i915: DP link
training optimization") and 4e96c97742f4 ("drm/i915: eDP link training
optimization").

Fixes: 5fa836a9d859 ("drm/i915: DP link training optimization")
Fixes: 4e96c97742f4 ("drm/i915: eDP link training optimization")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91393
Reviewed-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Signed-off-by: Mika Kahola &lt;mika.kahola@intel.com&gt;
Signed-off-by: Jani Nikula &lt;jani.nikula@intel.com&gt;
Link: http://patchwork.freedesktop.org/patch/msgid/1466410226-19543-1-git-send-email-mika.kahola@intel.com
(cherry picked from commit 91df09d92ad82c8778ca218097bf827f154292ca)
Signed-off-by: Joakim Tjernlund &lt;joakim.tjernlund@infinera.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix error paths when mapping framebuffer</title>
<updated>2016-07-27T15:42:20+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2016-07-07T18:01:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ea6c83c80fc75f6dee0d0c52675287ff5f46a617'/>
<id>ea6c83c80fc75f6dee0d0c52675287ff5f46a617</id>
<content type='text'>
commit 58541f7a6458e17ab417321b284f0090f530aa91 upstream.

Rather than returning immediately, make sure to unlock the
mutexes first.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Charmaine Lee &lt;charmainel@vmware.com&gt;
Reported-by: Emil Velikov &lt;emil.l.velikov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 58541f7a6458e17ab417321b284f0090f530aa91 upstream.

Rather than returning immediately, make sure to unlock the
mutexes first.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Charmaine Lee &lt;charmainel@vmware.com&gt;
Reported-by: Emil Velikov &lt;emil.l.velikov@gmail.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Fix corner case screen target management</title>
<updated>2016-07-27T15:42:20+00:00</updated>
<author>
<name>Thomas Hellstrom</name>
<email>thellstrom@vmware.com</email>
</author>
<published>2016-06-29T20:37:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=6a1c743a96ac3ac22249d0efb001a59165bd8e3d'/>
<id>6a1c743a96ac3ac22249d0efb001a59165bd8e3d</id>
<content type='text'>
commit beca4cf55323147ca9c8a98de1871be6e4fe8f34 upstream.

When the surface backing a framebuffer doesn't match the framebuffer's
dimensions, the screen target code would test the framebuffer dimensions
rather than the surface dimensions when deciding whether to bind the
surface as a screen target directly. This causes a screen target -
surface dimension mismatch and a subsequent device error.

Fix this by testing against the surface dimension.

v2: Fix review comments by Sinclair Yeh.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit beca4cf55323147ca9c8a98de1871be6e4fe8f34 upstream.

When the surface backing a framebuffer doesn't match the framebuffer's
dimensions, the screen target code would test the framebuffer dimensions
rather than the surface dimensions when deciding whether to bind the
surface as a screen target directly. This causes a screen target -
surface dimension mismatch and a subsequent device error.

Fix this by testing against the surface dimension.

v2: Fix review comments by Sinclair Yeh.

Signed-off-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Reviewed-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Delay pinning fbdev framebuffer until after mode set</title>
<updated>2016-07-27T15:42:19+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2016-06-29T20:23:18+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=14f0b144c4fcbc19b3a236802d8fdb84b1a57476'/>
<id>14f0b144c4fcbc19b3a236802d8fdb84b1a57476</id>
<content type='text'>
commit d5f1a291e32309324a8c481ed84b5c118d1360ea upstream.

For the Screen Object display unit, we need to reserve a
guest-invisible region equal to the size of the framebuffer for
the host.  This region can only be reserved in VRAM, whereas
the guest-visible framebuffer can be reserved in either VRAM or
GMR.

As such priority should be given to the guest-invisible
region otherwise in a limited VRAM situation, we can fail to
allocate this region.

This patch makes it so that vmw_sou_backing_alloc() is called
before the framebuffer is pinned.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d5f1a291e32309324a8c481ed84b5c118d1360ea upstream.

For the Screen Object display unit, we need to reserve a
guest-invisible region equal to the size of the framebuffer for
the host.  This region can only be reserved in VRAM, whereas
the guest-visible framebuffer can be reserved in either VRAM or
GMR.

As such priority should be given to the guest-invisible
region otherwise in a limited VRAM situation, we can fail to
allocate this region.

This patch makes it so that vmw_sou_backing_alloc() is called
before the framebuffer is pinned.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Check pin count before attempting to move a buffer</title>
<updated>2016-07-27T15:42:19+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2016-06-29T20:20:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=ea530263cd022119c3799ac932ebbd28e341b201'/>
<id>ea530263cd022119c3799ac932ebbd28e341b201</id>
<content type='text'>
commit 4ed7e2242b637bc4af0416e4aa9f945db30fb44a upstream.

In certain scenarios, e.g. when fbdev is enabled, we can get into
a situation where a vmw_framebuffer_pin() is called on a buffer
that is already pinned.

When this happens, ttm_bo_validate() will unintentially remove the
TTM_PL_FLAG_NO_EVICT flag, thus unpinning it, and leaving no way
to actually pin the buffer again.

To prevent this, if a buffer is already pinned, then instead of
calling ttm_bo_validate(), just make sure the proposed placement is
compatible with the existing placement.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 4ed7e2242b637bc4af0416e4aa9f945db30fb44a upstream.

In certain scenarios, e.g. when fbdev is enabled, we can get into
a situation where a vmw_framebuffer_pin() is called on a buffer
that is already pinned.

When this happens, ttm_bo_validate() will unintentially remove the
TTM_PL_FLAG_NO_EVICT flag, thus unpinning it, and leaving no way
to actually pin the buffer again.

To prevent this, if a buffer is already pinned, then instead of
calling ttm_bo_validate(), just make sure the proposed placement is
compatible with the existing placement.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Work around mode set failure in 2D VMs</title>
<updated>2016-07-27T15:42:19+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2016-06-29T18:29:47+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=3e2dd00e573542f0a97063f32b50f1e3a32ccaa2'/>
<id>3e2dd00e573542f0a97063f32b50f1e3a32ccaa2</id>
<content type='text'>
commit 7c20d213dd3cd6295bf9162730e7a368af957854 upstream.

In a low-memory 2D VM, fbdev can take up a large percentage of
available memory, making them unavailable for other DRM clients.

Since we do not take fbdev into account when filtering modes,
we end up claiming to support more modes than we actually do.

As a result, users get a black screen when setting a mode too
large for current available memory.  In a low-memory VM
configuration, users can get a black screen for a mode as low
as 1024x768.

The current mode filtering mechanism keys off of
SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount
of surface memory we have.  Since this value is a performance
suggestion, not a hard limit, and since there should not be much
of a performance impact for a 2D VM, rather than filtering out
more modes, we will just allow ourselves to exceed the SVGA's
performance suggestion.

Also changed assumed bpp to 32 from 16 to make sure we can
actually support all the modes listed.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 7c20d213dd3cd6295bf9162730e7a368af957854 upstream.

In a low-memory 2D VM, fbdev can take up a large percentage of
available memory, making them unavailable for other DRM clients.

Since we do not take fbdev into account when filtering modes,
we end up claiming to support more modes than we actually do.

As a result, users get a black screen when setting a mode too
large for current available memory.  In a low-memory VM
configuration, users can get a black screen for a mode as low
as 1024x768.

The current mode filtering mechanism keys off of
SVGA_REG_SUGGESTED_GBOBJECT_MEM_SIZE_KB, i.e. the maximum amount
of surface memory we have.  Since this value is a performance
suggestion, not a hard limit, and since there should not be much
of a performance impact for a 2D VM, rather than filtering out
more modes, we will just allow ourselves to exceed the SVGA's
performance suggestion.

Also changed assumed bpp to 32 from 16 to make sure we can
actually support all the modes listed.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/vmwgfx: Add an option to change assumed FB bpp</title>
<updated>2016-07-27T15:42:19+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2016-06-29T19:15:48+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=33c4de41d7d0ec957994d31a39e621d4c2eb65cf'/>
<id>33c4de41d7d0ec957994d31a39e621d4c2eb65cf</id>
<content type='text'>
commit 04319d89fbec72dfd60738003c3813b97c1d5f5a upstream.

Offer an option for advanced users who want larger modes at 16bpp.

This becomes necessary after the fix: "Work around mode set
failure in 2D VMs."  Without this patch, there would be no way
for existing advanced users to get to a high res mode, and the
regression is they will likely get a black screen after a software
update on their current VM.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 04319d89fbec72dfd60738003c3813b97c1d5f5a upstream.

Offer an option for advanced users who want larger modes at 16bpp.

This becomes necessary after the fix: "Work around mode set
failure in 2D VMs."  Without this patch, there would be no way
for existing advanced users to get to a high res mode, and the
regression is they will likely get a black screen after a software
update on their current VM.

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/ttm: Make ttm_bo_mem_compat available</title>
<updated>2016-07-27T15:42:19+00:00</updated>
<author>
<name>Sinclair Yeh</name>
<email>syeh@vmware.com</email>
</author>
<published>2016-06-29T19:58:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=70124a05e699c951f59a670bdca4872d6e75d701'/>
<id>70124a05e699c951f59a670bdca4872d6e75d701</id>
<content type='text'>
commit 94477bff390aa4612d2332c8abafaae0a13d6923 upstream.

There are cases where it is desired to see if a proposed placement
is compatible with a buffer object before calling ttm_bo_validate().

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 94477bff390aa4612d2332c8abafaae0a13d6923 upstream.

There are cases where it is desired to see if a proposed placement
is compatible with a buffer object before calling ttm_bo_validate().

Signed-off-by: Sinclair Yeh &lt;syeh@vmware.com&gt;
Reviewed-by: Thomas Hellstrom &lt;thellstrom@vmware.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm/atomic: Make drm_atomic_legacy_backoff reset crtc-&gt;acquire_ctx</title>
<updated>2016-07-27T15:42:19+00:00</updated>
<author>
<name>Maarten Lankhorst</name>
<email>maarten.lankhorst@linux.intel.com</email>
</author>
<published>2016-06-23T11:45:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=21b8579a4269abca96090544db8fb3499a5a24a7'/>
<id>21b8579a4269abca96090544db8fb3499a5a24a7</id>
<content type='text'>
commit 81e257e964268d050f8e9188becd44d50f241d72 upstream.

Atomic updates may acquire more state than initially locked through
drm_modeset_lock_crtc, running with heavy stress can cause a
WARN_ON(crtc-&gt;acquire_ctx) in drm_modeset_lock_crtc:

[  601.491296] ------------[ cut here ]------------
[  601.491366] WARNING: CPU: 0 PID: 2411 at
drivers/gpu/drm/drm_modeset_lock.c:191 drm_modeset_lock_crtc+0xeb/0xf0 [drm]
[  601.491369] Modules linked in: drm i915 drm_kms_helper
[  601.491414] CPU: 0 PID: 2411 Comm: kms_cursor_lega Tainted: G     U 4.7.0-rc4-patser+ #4798
[  601.491417] Hardware name: Intel Corporation Skylake Client
[  601.491420]  0000000000000000 ffff88044d153c98 ffffffff812ead28 0000000000000000
[  601.491425]  0000000000000000 ffff88044d153cd8 ffffffff810868e6 000000bf58058030
[  601.491431]  ffff880088b415e8 ffff880458058030 ffff88008a271548 ffff88008a271568
[  601.491436] Call Trace:
[  601.491443]  [&lt;ffffffff812ead28&gt;] dump_stack+0x4d/0x65
[  601.491447]  [&lt;ffffffff810868e6&gt;] __warn+0xc6/0xe0
[  601.491452]  [&lt;ffffffff81086968&gt;] warn_slowpath_null+0x18/0x20
[  601.491472]  [&lt;ffffffffc00d4ffb&gt;] drm_modeset_lock_crtc+0xeb/0xf0 [drm]
[  601.491491]  [&lt;ffffffffc00c5526&gt;] drm_mode_cursor_common+0x66/0x180 [drm]
[  601.491509]  [&lt;ffffffffc00c91cc&gt;] drm_mode_cursor_ioctl+0x3c/0x40 [drm]
[  601.491524]  [&lt;ffffffffc00bc94d&gt;] drm_ioctl+0x14d/0x530 [drm]
[  601.491540]  [&lt;ffffffffc00c9190&gt;] ? drm_mode_setcrtc+0x520/0x520 [drm]
[  601.491545]  [&lt;ffffffff81176aeb&gt;] ? handle_mm_fault+0x106b/0x1430
[  601.491550]  [&lt;ffffffff81108441&gt;] ? stop_one_cpu+0x61/0x70
[  601.491556]  [&lt;ffffffff811bb71d&gt;] do_vfs_ioctl+0x8d/0x570
[  601.491560]  [&lt;ffffffff81290d7e&gt;] ? security_file_ioctl+0x3e/0x60
[  601.491565]  [&lt;ffffffff811bbc74&gt;] SyS_ioctl+0x74/0x80
[  601.491571]  [&lt;ffffffff810e321c&gt;] ? posix_get_monotonic_raw+0xc/0x10
[  601.491576]  [&lt;ffffffff8175b11b&gt;] entry_SYSCALL_64_fastpath+0x13/0x8f
[  601.491581] ---[ end trace 56f3d3d85f000d00 ]---

For good measure, test mode_config.acquire_ctx too, although this should
never happen.

Testcase: kms_cursor_legacy
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 81e257e964268d050f8e9188becd44d50f241d72 upstream.

Atomic updates may acquire more state than initially locked through
drm_modeset_lock_crtc, running with heavy stress can cause a
WARN_ON(crtc-&gt;acquire_ctx) in drm_modeset_lock_crtc:

[  601.491296] ------------[ cut here ]------------
[  601.491366] WARNING: CPU: 0 PID: 2411 at
drivers/gpu/drm/drm_modeset_lock.c:191 drm_modeset_lock_crtc+0xeb/0xf0 [drm]
[  601.491369] Modules linked in: drm i915 drm_kms_helper
[  601.491414] CPU: 0 PID: 2411 Comm: kms_cursor_lega Tainted: G     U 4.7.0-rc4-patser+ #4798
[  601.491417] Hardware name: Intel Corporation Skylake Client
[  601.491420]  0000000000000000 ffff88044d153c98 ffffffff812ead28 0000000000000000
[  601.491425]  0000000000000000 ffff88044d153cd8 ffffffff810868e6 000000bf58058030
[  601.491431]  ffff880088b415e8 ffff880458058030 ffff88008a271548 ffff88008a271568
[  601.491436] Call Trace:
[  601.491443]  [&lt;ffffffff812ead28&gt;] dump_stack+0x4d/0x65
[  601.491447]  [&lt;ffffffff810868e6&gt;] __warn+0xc6/0xe0
[  601.491452]  [&lt;ffffffff81086968&gt;] warn_slowpath_null+0x18/0x20
[  601.491472]  [&lt;ffffffffc00d4ffb&gt;] drm_modeset_lock_crtc+0xeb/0xf0 [drm]
[  601.491491]  [&lt;ffffffffc00c5526&gt;] drm_mode_cursor_common+0x66/0x180 [drm]
[  601.491509]  [&lt;ffffffffc00c91cc&gt;] drm_mode_cursor_ioctl+0x3c/0x40 [drm]
[  601.491524]  [&lt;ffffffffc00bc94d&gt;] drm_ioctl+0x14d/0x530 [drm]
[  601.491540]  [&lt;ffffffffc00c9190&gt;] ? drm_mode_setcrtc+0x520/0x520 [drm]
[  601.491545]  [&lt;ffffffff81176aeb&gt;] ? handle_mm_fault+0x106b/0x1430
[  601.491550]  [&lt;ffffffff81108441&gt;] ? stop_one_cpu+0x61/0x70
[  601.491556]  [&lt;ffffffff811bb71d&gt;] do_vfs_ioctl+0x8d/0x570
[  601.491560]  [&lt;ffffffff81290d7e&gt;] ? security_file_ioctl+0x3e/0x60
[  601.491565]  [&lt;ffffffff811bbc74&gt;] SyS_ioctl+0x74/0x80
[  601.491571]  [&lt;ffffffff810e321c&gt;] ? posix_get_monotonic_raw+0xc/0x10
[  601.491576]  [&lt;ffffffff8175b11b&gt;] entry_SYSCALL_64_fastpath+0x13/0x8f
[  601.491581] ---[ end trace 56f3d3d85f000d00 ]---

For good measure, test mode_config.acquire_ctx too, although this should
never happen.

Testcase: kms_cursor_legacy
Signed-off-by: Maarten Lankhorst &lt;maarten.lankhorst@linux.intel.com&gt;
Reviewed-by: Daniel Vetter &lt;daniel.vetter@ffwll.ch&gt;
Signed-off-by: Dave Airlie &lt;airlied@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>drm: atmel-hlcdc: actually disable scaling when no scaling is required</title>
<updated>2016-07-27T15:42:19+00:00</updated>
<author>
<name>Boris Brezillon</name>
<email>boris.brezillon@free-electrons.com</email>
</author>
<published>2016-05-27T14:09:25+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux-stable.git/commit/?id=d1cbd8dabac8ffff6b5ce1ba41b44fd09bbe3116'/>
<id>d1cbd8dabac8ffff6b5ce1ba41b44fd09bbe3116</id>
<content type='text'>
commit 1b7e38b92b0bbd363369f5160f13f4d26140972d upstream.

The driver is only enabling scaling, but never disabling it, thus, if you
enable the scaling feature once it stays enabled forever.

Signed-off-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Reported-by: Alex Vazquez &lt;avazquez.dev@gmail.com&gt;
Reviewed-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 1b7e38b92b0bbd363369f5160f13f4d26140972d upstream.

The driver is only enabling scaling, but never disabling it, thus, if you
enable the scaling feature once it stays enabled forever.

Signed-off-by: Boris Brezillon &lt;boris.brezillon@free-electrons.com&gt;
Reported-by: Alex Vazquez &lt;avazquez.dev@gmail.com&gt;
Reviewed-by: Nicolas Ferre &lt;nicolas.ferre@atmel.com&gt;
Fixes: 1a396789f65a ("drm: add Atmel HLCDC Display Controller support")
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</pre>
</div>
</content>
</entry>
</feed>
