linux-stable.git/drivers/gpu, branch v5.2.3

gpu: ipu-v3: ipu-ic: Fix saturation bit offset in TPMEM

2019-07-26T07:11:07+00:00

commit 3d1f62c686acdedf5ed9642b763f3808d6a47d1e upstream.

The saturation bit was being set at bit 9 in the second 32-bit word
of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
which is bit 10 of the second word.

Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")

Signed-off-by: Steve Longerbeam 
Reviewed-by: Philipp Zabel 
Cc: stable@vger.kernel.org
Signed-off-by: Philipp Zabel 
Signed-off-by: Greg Kroah-Hartman

drm/edid: parse CEA blocks embedded in DisplayID

2019-07-26T07:11:03+00:00

commit e28ad544f462231d3fd081a7316339359efbb481 upstream.

DisplayID blocks allow embedding of CEA blocks. The payloads are
identical to traditional top level CEA extension blocks, but the header
is slightly different.

This change allows the CEA parser to find a CEA block inside a DisplayID
block. Additionally, it adds support for parsing the embedded CTA
header. No further changes are necessary due to payload parity.

This change fixes audio support for the Valve Index HMD.

Signed-off-by: Andres Rodriguez 
Reviewed-by: Dave Airlie 
Cc: Jani Nikula 
Cc:  # v4.15
Signed-off-by: Dave Airlie 
Link: https://patchwork.freedesktop.org/patch/msgid/20190619180901.17901-1-andresx7@gmail.com
Signed-off-by: Greg Kroah-Hartman

drm/nouveau/i2c: Enable i2c pads & busses during preinit

2019-07-26T07:11:02+00:00

commit 7cb95eeea6706c790571042a06782e378b2561ea upstream.

It turns out that while disabling i2c bus access from software when the
GPU is suspended was a step in the right direction with:

commit 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after
->fini()")

We also ended up accidentally breaking the vbios init scripts on some
older Tesla GPUs, as apparently said scripts can actually use the i2c
bus. Since these scripts are executed before initializing any
subdevices, we end up failing to acquire access to the i2c bus which has
left a number of cards with their fan controllers uninitialized. Luckily
this doesn't break hardware - it just means the fan gets stuck at 100%.

This also means that we've always been using our i2c busses before
initializing them during the init scripts for older GPUs, we just didn't
notice it until we started preventing them from being used until init.
It's pretty impressive this never caused us any issues before!

So, fix this by initializing our i2c pad and busses during subdev
pre-init. We skip initializing aux busses during pre-init, as those are
guaranteed to only ever be used by nouveau for DP aux transactions.

Signed-off-by: Lyude Paul 
Tested-by: Marc Meledandri 
Fixes: 342406e4fbba ("drm/nouveau/i2c: Disable i2c bus access after ->fini()")
Cc: stable@vger.kernel.org
Signed-off-by: Ben Skeggs 
Signed-off-by: Greg Kroah-Hartman

Merge tag 'imx-drm-fixes-2019-07-04' of git://git.pengutronix.de/git/pza/linux into drm-fixes

2019-07-05T04:51:03+00:00

drm/imx: fix stale vblank timestamp after a modeset

This series fixes stale vblank timestamps in the first event sent after
a crtc was disabled. The core now is notified via drm_crtc_vblank_off
before sending the last pending event in atomic_disable. If the crtc is
reenabled right away during to a modeset, the event is not sent at all,
as the next vblank will take care of it.

Signed-off-by: Dave Airlie 

From: Philipp Zabel 
Link: https://patchwork.freedesktop.org/patch/msgid/1562237119.6641.16.camel@pengutronix.de

drm/imx: only send event on crtc disable if kept disabled

2019-07-04T10:21:25+00:00

The event will be sent as part of the vblank enable during the modeset
if the crtc is not being kept disabled.

Fixes: 5f2f911578fb ("drm/imx: atomic phase 3 step 1: Use atomic configuration")

Signed-off-by: Robert Beckett 
Reviewed-by: Daniel Vetter 
Signed-off-by: Philipp Zabel

drm/imx: notify drm core before sending event during crtc disable

2019-07-04T10:21:25+00:00

Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.

This was seen while debugging weston log message:
Warning: computed repaint delay is insane: -8212 msec

This occurred due to:
1. driver starts up
2. fbcon comes along and restores fbdev, enabling vblank
3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
seq number and time set at current value
(some time later)
4. weston starts and does a modeset
5. atomic commit disables crtc while it does the modeset
6. ipu_crtc_atomic_disable sends vblank with old seq number and time

Fixes: a474478642d5 ("drm/imx: fix crtc vblank state regression")

Signed-off-by: Robert Beckett 
Reviewed-by: Daniel Vetter 
Signed-off-by: Philipp Zabel

Merge branch 'etnaviv/fixes' of https://git.pengutronix.de/git/lst/linux into drm-fixes

2019-07-04T01:19:34+00:00

Fix a kernel nullptr deref on module
unload when any etnaviv GPU failed to initialize properly.

Signed-off-by: Dave Airlie 
From: Lucas Stach 
Link: https://patchwork.freedesktop.org/patch/msgid/1561974148.2321.1.camel@pengutronix.de

Merge tag 'drm-misc-fixes-2019-07-03' of git://anongit.freedesktop.org/drm/drm-misc into drm-fixes

2019-07-04T01:17:48+00:00

panfrost- Avoid double free by deleting GEM handle in create_bo failure
          path (Boris)

Cc: Boris Brezillon 
Signed-off-by: Dave Airlie 

From: Sean Paul 
Link: https://patchwork.freedesktop.org/patch/msgid/20190704001302.GA260390@art_vandelay

Merge tag 'drm-fixes-5.2-2019-07-02' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

2019-07-04T01:17:23+00:00

drm-fixes-5.2-2019-07-02:

Fixes for stable

amdgpu:
- stability fix for gfx9
- regression fix for HG on some polaris boards
- crash fix for some new OEM boards

Signed-off-by: Dave Airlie 
From: Alex Deucher 
Link: https://patchwork.freedesktop.org/patch/msgid/20190703015705.3162-1-alexander.deucher@amd.com

drm/i915/ringbuffer: EMIT_INVALIDATE before switch context

2019-07-02T12:46:29+00:00

Despite what I think the prm recommends, commit f2253bd9859b
("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context") turned out
to be a huge mistake when enabling Ironlake contexts as the GPU would
hang on either a MI_FLUSH or PIPE_CONTROL immediately following the
MI_SET_CONTEXT of an active mesa context (more vanilla contexts, e.g.
simple rendercopies with igt, do not suffer).

Ville found the following clue,

  "[DevCTG+]: For the invalidate operation of the pipe control, the
   following pointers are affected. The
   invalidate operation affects the restore of these packets. If the pipe
   control invalidate operation is completed
   before the context save, the indirect pointers will not be restored from
   memory.
   1. Pipeline State Pointer
   2. Media State Pointer
   3. Constant Buffer Packet"

which suggests by us emitting the INVALIDATE prior to the MI_SET_CONTEXT,
we prevent the context-restore from chasing the dangling pointers within
the image, and explains why this likely prevents the GPU hang.

Signed-off-by: Chris Wilson 
Reviewed-by: Ville Syrjälä 
Link: https://patchwork.freedesktop.org/patch/msgid/20190419111749.3910-1-chris@chris-wilson.co.uk
(cherry picked from commit 928f8f42310f244501a7c70daac82c196112c190 in drm-intel-next)
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111014
Fixes: f2253bd9859b ("drm/i915/ringbuffer: EMIT_INVALIDATE after switch context")
Signed-off-by: Daniel Vetter