linux-stable.git/drivers/gpu, branch v3.16.65

drm: rcar-du: Fix vblank initialization

2019-04-04T15:13:44+00:00

commit 3d61fe5f59dd3e6f96fc0772156d257cb04dc656 upstream.

The drm_vblank_init() takes the total number of CRTCs as an argument,
but the rcar-du driver passes a bitmask of the CRTC indices. Fix it.

Fixes: 4bf8e1962f91 ("drm: Renesas R-Car Display Unit DRM driver")
Reported-by: Tomi Valkeinen 
Signed-off-by: Laurent Pinchart 
Reviewed-by: Kieran Bingham 
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

drm/i915/ringbuffer: Delay after EMIT_INVALIDATE for gen4/gen5

2019-04-04T15:13:40+00:00

commit 55f99bf2a9c331838c981694bc872cd1ec4070b2 upstream.

Exercising the gpu reloc path strenuously revealed an issue where the
updated relocations (from MI_STORE_DWORD_IMM) were not being observed
upon execution. After some experiments with adding pipecontrols (a lot
of pipecontrols (32) as gen4/5 do not have a bit to wait on earlier pipe
controls or even the current on), it was discovered that we merely
needed to delay the EMIT_INVALIDATE by several flushes. It is important
to note that it is the EMIT_INVALIDATE as opposed to the EMIT_FLUSH that
needs the delay as opposed to what one might first expect -- that the
delay is required for the TLB invalidation to take effect (one presumes
to purge any CS buffers) as opposed to a delay after flushing to ensure
the writes have landed before triggering invalidation.

Testcase: igt/gem_tiled_fence_blits
Signed-off-by: Chris Wilson 
Reviewed-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20181105094305.5767-1-chris@chris-wilson.co.uk
[bwh: Backported to 3.16:
 - Use intel_ring_emit() instead of assignments
 - Use ring->scratch.gtt_offset instead of i915_ggtt_offset()
 - Use (invalidate_domains & I915_GEM_DOMAIN_INSTRUCTION) instead of
   (mode & EMIT_INVALIDATE)
 - Adjust context]
Signed-off-by: Ben Hutchings

drm/ioctl: Fix Spectre v1 vulnerabilities

2019-02-11T17:54:30+00:00

commit 505b5240329b922f21f91d5b5d1e535c805eca6d upstream.

nr is indirectly controlled by user-space, hence leading to a
potential exploitation of the Spectre variant 1 vulnerability.

This issue was detected with the help of Smatch:

drivers/gpu/drm/drm_ioctl.c:805 drm_ioctl() warn: potential spectre issue 'dev->driver->ioctls' [r]
drivers/gpu/drm/drm_ioctl.c:810 drm_ioctl() warn: potential spectre issue 'drm_ioctls' [r] (local cap)
drivers/gpu/drm/drm_ioctl.c:892 drm_ioctl_flags() warn: potential spectre issue 'drm_ioctls' [r] (local cap)

Fix this by sanitizing nr before using it to index dev->driver->ioctls
and drm_ioctls.

Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].

[1] https://marc.info/?l=linux-kernel&m=152449131114778&w=2

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20181220000015.GA18973@embeddedor
[bwh: Backported to 3.16: adjust filename, context]
Signed-off-by: Ben Hutchings

drm: Rewrite drm_ioctl_flags() to resemble the new drm_ioctl() code

2019-02-11T17:54:30+00:00

commit 7ef5f82b100716b23de7d2da6ff602b0842e5804 upstream.

Use the same logic when checking for valid ioctl range in
drm_ioctl_flags() that is used in drm_ioctl() to avoid
confusion.

Signed-off-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
[bwh: Backported to 3.16: adjust filename]
Signed-off-by: Ben Hutchings

drm/ast: fixed cursor may disappear sometimes

2019-02-11T17:54:09+00:00

commit 7989b9ee8bafe5cc625381dd0c3c4586de27ca26 upstream.

Signed-off-by: Y.C. Chen 
Reviewed-by: Dave Airlie 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/ast: change resolution may cause screen blurred

2019-02-11T17:54:09+00:00

commit 1a37bd823891568f8721989aed0615835632d81a upstream.

The value of pitches is not correct while calling mode_set.
The issue we found so far on following system:
- Debian8 with XFCE Desktop
- Ubuntu with KDE Desktop
- SUSE15 with KDE Desktop

Signed-off-by: Y.C. Chen 
Tested-by: Jean Delvare 
Reviewed-by: Jean Delvare 
Signed-off-by: Dave Airlie 
Signed-off-by: Ben Hutchings

drm/i915: Disable LP3 watermarks on all SNB machines

2019-02-11T17:54:07+00:00

commit 21556350ade3cb5d7afecc8b3544e56431d21695 upstream.

I have a Thinkpad X220 Tablet in my hands that is losing vblank
interrupts whenever LP3 watermarks are used.

If I nudge the latency value written to the WM3 register just
by one in either direction the problem disappears. That to me
suggests that the punit will not enter the corrsponding
powersave mode (MPLL shutdown IIRC) unless the latency value
in the register matches exactly what we read from SSKPD. Ie.
it's not really a latency value but rather just a cookie
by which the punit can identify the desired power saving state.
On HSW/BDW this was changed such that we actually just write
the WM level number into those bits, which makes much more
sense given the observed behaviour.

We could try to handle this by disallowing LP3 watermarks
only when vblank interrupts are enabled but we'd first have
to prove that only vblank interrupts are affected, which
seems unlikely. Also we can't grab the wm mutex from the
vblank enable/disable hooks because those are called with
various spinlocks held. Thus we'd have to redesigne the
watermark locking. So to play it safe and keep the code
simple we simply disable LP3 watermarks on all SNB machines.

To do that we simply zero out the latency values for
watermark level 3, and we adjust the watermark computation
to check for that. The behaviour now matches that of the
g4x/vlv/skl wm code in the presence of a zeroed latency
value.

v2: s/USHRT_MAX/U32_MAX/ for consistency with the types (Chris)

Cc: Chris Wilson 
Acked-by: Chris Wilson 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101269
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103713
Signed-off-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20181114173440.6730-1-ville.syrjala@linux.intel.com
(cherry picked from commit 03981c6ebec4fc7056b9b45f847393aeac90d060)
Signed-off-by: Joonas Lahtinen 
[bwh: Backported to 3.16:
 - Pass drm_device pointer, rather than drm_i915_private pointer, to
   snb_wm_lp3_irq_quirk() and intel_print_wm_latency()
 - Adjust context]
Signed-off-by: Ben Hutchings

drm/ast: Remove existing framebuffers before loading driver

2019-02-11T17:54:06+00:00

commit 5478ad10e7850ce3d8b7056db05ddfa3c9ddad9a upstream.

If vesafb attaches to the AST device, it configures the framebuffer memory
for uncached access by default. When ast.ko later tries to attach itself to
the device, it wants to use write-combining on the framebuffer memory, but
vesefb's existing configuration for uncached access takes precedence. This
results in reduced performance.

Removing the framebuffer's configuration before loding the AST driver fixes
the problem. Other DRM drivers already contain equivalent code.

Link: https://bugzilla.opensuse.org/show_bug.cgi?id=1112963
Signed-off-by: Thomas Zimmermann 
Tested-by: Y.C. Chen 
Reviewed-by: Jean Delvare 
Tested-by: Jean Delvare 
Signed-off-by: Dave Airlie 
[bwh: Backported to 3.16: Use remove_conflicting_framebuffers()]
Signed-off-by: Ben Hutchings

drm/i915: Large page offsets for pread/pwrite

2019-02-11T17:53:37+00:00

commit ab0d6a141843e0b4b2709dfd37b53468b5452c3a upstream.

Handle integer overflow when computing the sub-page length for shmem
backed pread/pwrite.

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Reviewed-by: Tvrtko Ursulin 
Link: https://patchwork.freedesktop.org/patch/msgid/20181012140228.29783-1-chris@chris-wilson.co.uk
(cherry picked from commit a5e856a5348f6cd50889d125c40bbeec7328e466)
Signed-off-by: Rodrigo Vivi 
[bwh: Backported to 3.16:
 - Length variable is page_length, not length
 - Page-offset variable is shmem_page_offset, not offset]
Signed-off-by: Ben Hutchings

drm: fb-helper: Reject all pixel format changing requests

2018-12-16T22:09:35+00:00

commit db05c481977599236f12a85e55de9f5ab37b0a2c upstream.

drm fbdev emulation doesn't support changing the pixel format at all,
so reject all pixel format changing requests.

Signed-off-by: Eugeniy Paltsev 
Reviewed-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
Link: https://patchwork.freedesktop.org/patch/msgid/20181003164538.5534-1-Eugeniy.Paltsev@synopsys.com
Signed-off-by: Ben Hutchings