linux.git/drivers/gpu/drm, branch v4.0-rc6

drm/i915: Fixup legacy plane->crtc link for initial fb config

2015-03-26T11:39:04+00:00

This is a very similar bug in the load detect code fixed in

commit 9128b040eb774e04bc23777b005ace2b66ab2a85
Author: Daniel Vetter 
Date:   Tue Mar 3 17:31:21 2015 +0100

    drm/i915: Fix modeset state confusion in the load detect code

But this time around it was the initial fb code that forgot to update
the plane->crtc pointer. Otherwise it's the exact same bug, with the
exact same restrains (any set_config call/ioctl that doesn't disable
the pipe papers over the bug for free, so fairly hard to hit in normal
testing). So if you want the full explanation just go read that one
over there - it's rather long ...

Cc: Matt Roper 
Cc: Linus Torvalds 
Cc: Chris Wilson 
Cc: Josh Boyer 
Cc: Jani Nikula 
Reported-and-tested-by: Josh Boyer 
Signed-off-by: Daniel Vetter 
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7ChbtJrknqws1qvZcbrg1CW2pQAFkSMURWWgyASRyGXg@mail.gmail.com
Signed-off-by: Jani Nikula

drm/i915: Fix atomic state when reusing the firmware fb

2015-03-26T11:38:10+00:00

Right now, we get a warning when taking over the firmware fb:

  [drm:drm_atomic_plane_check] FB set but no CRTC

with the following backtrace:

  [] drm_atomic_check_only+0x35d/0x510 [drm]
  [] drm_atomic_commit+0x17/0x60 [drm]
  [] drm_atomic_helper_plane_set_property+0x8d/0xd0 [drm_kms_helper]
  [] drm_mode_plane_set_obj_prop+0x2d/0x90 [drm]
  [] restore_fbdev_mode+0x6b/0xf0 [drm_kms_helper]
  [] drm_fb_helper_restore_fbdev_mode_unlocked+0x29/0x80 [drm_kms_helper]
  [] drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper]
  [] intel_fbdev_set_par+0x1a/0x60 [i915]
  [] fbcon_init+0x4f4/0x580

That's because we update the plane state with the fb from the firmware, but we
never associate the plane to that CRTC.

We don't quite have the full DRM take over from HW state just yet, so
fake enough of the plane atomic state to pass the checks.

v2: Fix the state on which we set the CRTC in the case we're sharing the
    initial fb with another pipe. (Matt)

Signed-off-by: Damien Lespiau 
Reviewed-by: Matt Roper 
Signed-off-by: Daniel Vetter 
[Jani: backported to drm-intel-fixes for v4.0-rc]
Reference: http://mid.gmane.org/CA+5PVA7yXH=U757w8V=Zj2U1URG4nYNav20NpjtQ4svVueyPNw@mail.gmail.com
Reference: http://lkml.kernel.org/r/CA+55aFweWR=nDzc2Y=rCtL_H8JfdprQiCimN5dwc+TgyD4Bjsg@mail.gmail.com
Signed-off-by: Jani Nikula

drm/i915: Keep ring->active_list and ring->requests_list consistent

2015-03-26T09:05:54+00:00

If we retire requests last, we may use a later seqno and so clear
the requests lists without clearing the active list, leading to
confusion. Hence we should retire requests first for consistency with
the early return. The order used to be important as the lifecycle for
the object on the active list was determined by request->seqno. However,
the requests themselves are now reference counted removing the
constraint from the order of retirement.

Fixes regression from

commit 1b5a433a4dd967b125131da42b89b5cc0d5b1f57
Author: John Harrison 
Date:   Mon Nov 24 18:49:42 2014 +0000

    drm/i915: Convert 'i915_seqno_passed' calls into 'i915_gem_request_completed
'

and a

	WARNING: CPU: 0 PID: 1383 at drivers/gpu/drm/i915/i915_gem_evict.c:279 i915_gem_evict_vm+0x10c/0x140()
	WARN_ON(!list_empty(&vm->active_list))

Identified by updating WATCH_LISTS:

	[drm:i915_verify_lists] *ERROR* blitter ring: active list not empty, but no requests
	WARNING: CPU: 0 PID: 681 at drivers/gpu/drm/i915/i915_gem.c:2751 i915_gem_retire_requests_ring+0x149/0x230()
	WARN_ON(i915_verify_lists(ring->dev))

Note that this is only a problem in evict_vm where the following happens
after a retire_request has cleaned out all requests, but not all active
bo:
- intel_ring_idle called from i915_gpu_idle notices that no requests are
  outstanding and immediately returns.
- i915_gem_retire_requests_ring called from i915_gem_retire_requests also
  immediately returns when there's no request, still leaving the bo on the
  active list.
- evict_vm hits the WARN_ON(!list_empty(&vm->active_list)) after evicting
  all active objects that there's still stuff left that shouldn't be
  there.

Signed-off-by: Chris Wilson 
Cc: John Harrison 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula

drm/i915: Don't try to reference the fb in get_initial_plane_config()

2015-03-25T00:01:46+00:00

Tvrtko noticed a new warning on boot:

  WARNING: CPU: 1 PID: 353 at include/linux/kref.h:47 drm_framebuffer_reference+0x6c/0x80 [drm]()
  Call Trace:
  [] dump_stack+0x4f/0x7b
  [] warn_slowpath_common+0xaa/0xd0
  [] warn_slowpath_null+0x1a/0x20
  [] drm_framebuffer_reference+0x6c/0x80 [drm]
  [] update_state_fb.isra.54+0x47/0x50 [i915]
  [] skylake_get_initial_plane_config+0x93c/0x950 [i915]
  [] intel_modeset_init+0x1551/0x17c0 [i915]
  [] i915_driver_load+0xed0/0x11e0 [i915]
  [] ? _raw_spin_unlock_irqrestore+0x51/0x70
  [] drm_dev_register+0x77/0x110 [drm]
  [] drm_get_pci_dev+0x11b/0x1f0 [drm]
  [] ? trace_hardirqs_on+0xd/0x10
  [] ? _raw_spin_unlock_irqrestore+0x51/0x70
  [] i915_pci_probe+0x56/0x60 [i915]
  [] pci_device_probe+0x7c/0x100
  [] driver_probe_device+0x16d/0x380

We cannot take a reference at this point, not before
intel_framebuffer_init() and the underlying drm_framebuffer_init().

Introduced in:

  commit 706dc7b549175e47f23e913b7f1e52874a7d0f56
  Author: Matt Roper 
  Date:   Tue Feb 3 13:10:04 2015 -0800

      drm/i915: Ensure plane->state->fb stays in sync with plane->fb

v2: Don't move update_state_fb(). It was moved around because I
    originally put update_state_fb() in intel_alloc_plane_obj() before
    finding a better place. (Matt)

Reviewed-by: Matt Roper 
Reported-by: Tvrtko Ursulin 
Cc: Matt Roper 
Cc: Tvrtko Ursulin 
Signed-off-by: Damien Lespiau 
Signed-off-by: Daniel Vetter 
From drm-next:
(cherry picked from commit f55548b5af87ebfc586ca75748947f1c1b1a4a52)
Signed-off-by: Dave Airlie

drm: Fixup racy refcounting in plane_force_disable

2015-03-24T02:04:35+00:00

Originally it was impossible to be dropping the last refcount in this
function since there was always one around still from the idr. But in

commit 83f45fc360c8e16a330474860ebda872d1384c8c
Author: Daniel Vetter 
Date:   Wed Aug 6 09:10:18 2014 +0200

    drm: Don't grab an fb reference for the idr

we've switched to weak references, broke that assumption but forgot to
fix it up.

Since we still force-disable planes it's only possible to hit this
when racing multiple rmfb with fbdev restoring or similar evil things.
As long as userspace is nice it's impossible to hit the BUG_ON.

But the BUG_ON would most likely be hit from fbdev code, which usually
invovles the console_lock besides all modeset locks. So very likely
we'd never get the bug reports if this was hit in the wild, hence
better be safe than sorry and backport.

Spotted by Matt Roper while reviewing other patches.

[airlied: pull this back into 4.0 - the oops happens there]

Cc: stable@vger.kernel.org
Cc: Matt Roper 
Reviewed-by: Matt Roper 
Signed-off-by: Daniel Vetter 
Signed-off-by: Dave Airlie

Merge tag 'drm-intel-fixes-2015-03-19' of git://anongit.freedesktop.org/drm-intel into drm-fixes

2015-03-20T07:32:21+00:00

Backporting a couple of plane related fixes from drm-next to v4.0.

* tag 'drm-intel-fixes-2015-03-19' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Make sure the primary plane is enabled before reading out the fb state
  drm/i915: Ensure plane->state->fb stays in sync with plane->fb

Merge tag 'drm-amdkfd-fixes-2015-03-19' of git://people.freedesktop.org/~gabbayo/linux into drm-fixes

2015-03-20T07:32:01+00:00

- Fixing SDMA initialization when in non-HWS mode (debug mode)
- Memory leak fix when destroying kernel queue
- Fix number of available compute pipelines according to new firmware

* tag 'drm-amdkfd-fixes-2015-03-19' of git://people.freedesktop.org/~gabbayo/linux:
  drm/radeon: Changing number of compute pipe lines
  drm/amdkfd: Fix SDMA queue init. in non-HWS mode
  drm/amdkfd: destroy mqd when destroying kernel queue

Merge branch 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux into drm-fixes

2015-03-19T04:02:15+00:00

single radeon fix.

* 'drm-fixes-4.0' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: drop ttm two ended allocation

Merge branch 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes

2015-03-19T04:01:42+00:00

   Some urgent regression fixes to booting failures Exynos DRM occured.

   Summary:
   - Fix two urgent null pointer dereference bugs in case of enabling
     or disabling IOMMU. There was two cases to these issues.
     One is that plane->crtc is accessed by exynos_disable_plane()
     when device tree binding is broken so device driver tries
     to release, which means that the mode set operation isn't invoked yet
     so plane->crtc is still NULL and exynos_disable_plane() will access
     NULL pointer. This issue is fixed by checking if the plane->crtc
     is NULL or not in exynos_disable_plane()

     Other is that fimd_wait_for_vblank() is called to avoid from page fault
     with IOMMU before the ctx object is created. At this time,
     fimd_wait_for_vblank() tries to access ctx->crtc but the ctx->crtc
     is still NULL because exynos_drm_crtc_create() isn't called yet.
     This issue is fixed by creating a crtc object and setting it to
     ctx->crtc prior to fimd_wait_for_vblank() call.

     For more details, you can refer to below an e-mail thread,
     http://www.spinics.net/lists/linux-samsung-soc/msg42436.html

   - Remove unnecessary file not used and fix trivial issues.

* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: fix the initialization order in FIMD
  drm/exynos: fix typo config name correctly.
  drm/exynos: Check for NULL dereference of crtc
  drm/exynos: IS_ERR() vs NULL bug
  drm/exynos: remove unused files

drm/radeon: drop ttm two ended allocation

2015-03-18T13:53:40+00:00

radeon_bo_create() calls radeon_ttm_placement_from_domain()
before ttm_bo_init() is called.  radeon_ttm_placement_from_domain()
uses the ttm bo size to determine when to select top down
allocation but since the ttm bo is not initialized yet the
check is always false.  It only took effect when buffers
were validated later.  It also seemed to regress suspend
and resume on some systems possibly due to it not
taking effect in radeon_bo_create().

radeon_bo_create() and radeon_ttm_placement_from_domain()
need to be reworked substantially for this to be optimally
effective.  Re-enable it at that point.

Noticed-by: Oded Gabbay 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Cc: stable@vger.kernel.org