user/sven/linux.git/drivers/gpu, branch v5.2.2

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

2019-07-05T04:51:03Z

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:25Z

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:25Z

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:34Z

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:48Z

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:23Z

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:29Z

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

drm/amdgpu/gfx9: use reset default for PA_SC_FIFO_SIZE

2019-07-01T17:16:26Z

Recommended by the hw team. Reviewed-and-Tested-by: Huang Rui Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org

drm/amdgpu: Don't skip display settings in hwmgr_resume()

2019-07-01T14:15:00Z

I'm not entirely sure why this is, but for some reason: 921935dc6404 ("drm/amd/powerplay: enforce display related settings only on needed") Breaks runtime PM resume on the Radeon PRO WX 3100 (Lexa) in one the pre-production laptops I have. The issue manifests as the following messages in dmesg: [drm] UVD and UVD ENC initialized successfully. amdgpu 0000:3b:00.0: [drm:amdgpu_ring_test_helper [amdgpu]] *ERROR* ring vce1 test failed (-110) [drm:amdgpu_device_ip_resume_phase2 [amdgpu]] *ERROR* resume of IP block failed -110 [drm:amdgpu_device_resume [amdgpu]] *ERROR* amdgpu_device_ip_resume failed (-110). And happens after about 6-10 runtime PM suspend/resume cycles (sometimes sooner, if you're lucky!). Unfortunately I can't seem to pin down precisely which part in psm_adjust_power_state_dynamic that is causing the issue, but not skipping the display setting setup seems to fix it. Hopefully if there is a better fix for this, this patch will spark discussion around it. Fixes: 921935dc6404 ("drm/amd/powerplay: enforce display related settings only on needed") Cc: Evan Quan Cc: Alex Deucher Cc: Huang Rui Cc: Rex Zhu Cc: Likun Gao Cc: # v5.1+ Signed-off-by: Lyude Paul Signed-off-by: Alex Deucher

drm/amd/powerplay: use hardware fan control if no powerplay fan table

2019-07-01T14:14:05Z

Otherwise, you may get divided-by-zero error or corrput the SMU fan control feature. Signed-off-by: Evan Quan Reviewed-by: Alex Deucher Tested-by: Slava Abramov Acked-by: Slava Abramov Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org