Commit Graph

36794 Commits

Author SHA1 Message Date
Lothar Waßmann
fafc79ef2e drm/imx: convey the pixelclk-active and de-active flags from DT to the ipu-di driver
The 'de-active' and 'pixelclk-active' DT properties are evaluated
by of_parse_display_timing() called from  of_get_drm_display_mode(),
but later lost in the conversion from videomode.flags to
drm_display_mode.flags.
Enhance of_get_drm_display_mode() to also return the bus flags in a
separate variable, so that they can be passed on to the ipu-di
driver.

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08 11:44:20 +02:00
Lothar Waßmann
d72daa0d75 drm: add a helper function to extract 'de-active' and 'pixelclk-active' from DT
add a helper function to extract information about pixel clock and DE
polarity from DT for use by of_get_drm_display_mode().
While at it, convert spaces to tabs in indentation in drm_modes.h.

Signed-off-by: Lothar Waßmann <LW@KARO-electronics.de>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
2016-08-08 11:44:20 +02:00
Keith Packard
fcc60b413d drm: Don't prepare or cleanup unchanging frame buffers [v3]
When reconfiguring a plane position (as in moving the cursor), the
frame buffer for the cursor isn't changing, so don't call the prepare
or cleanup driver functions.

This avoids making cursor position updates block on all pending rendering.

v3: use drm_atomic_helper_framebuffer_changed in both prepare and
    cleanup phases instead of keeping state in the plane.

cc: dri-devel@lists.freedesktop.org
cc: David Airlie <airlied@linux.ie>
cc: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Keith Packard <keithp@keithp.com>
[danvet: Rebase onto 4.8]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-08 10:59:56 +02:00
Daniel Vetter
fa5386459f drm: Used DRM_LEGACY for all legacy functions
Except for nouveau, only legacy drivers need this really. And nouveau
is already marked up with DRIVER_KMS_LEGACY_CONTEXT as the special
case.

I've tried to be careful to leave everything related to modeset still
using the DRIVER_MODESET flag. Otherwise it's a direct replacement of
!DRIVER_MODESET with DRIVER_LEGACY checks. Also helps readability
since fewer negative checks overall.

Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-2-git-send-email-daniel.vetter@ffwll.ch
2016-08-08 10:05:23 +02:00
Daniel Vetter
3cbf6a5deb drm: Mark up legacy/dri1 drivers with DRM_LEGACY
It's super confusing that new drivers need to be marked with
DRIVER_MODESET when really it means DRIVER_MODERN. Much better to
invert the meaning and rename it to something that's suitably
off-putting.

Since there's over 100 places using DRIVER_MODESET we need to roll out
this change without a flag day.

v2: Update docs.

Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470251470-30830-1-git-send-email-daniel.vetter@ffwll.ch
2016-08-08 10:05:22 +02:00
Chris Wilson
aafdcfd3f9 drm: Declare that create drm_mm nodes with size 0 is illegal
At a higher level, all objects are created with definite size i.e. 0 is
illegal. In forthcoming patches, this assumption is dependent upon in
the drm_mm range manager, i.e. trying to create a drm_mm node with size
0 will have undefined behaviour. Add a couple of WARNs upon creating the
drm_mm node to prevent later bugs.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470248788-30873-1-git-send-email-chris@chris-wilson.co.uk
2016-08-08 10:05:21 +02:00
David Herrmann
a3ccc46166 drm: rename DRM_MINOR_LEGACY to DRM_MINOR_PRIMARY
The minor referred to by "DRM_MINOR_LEGACY" is called 'dev->primary' and
gets 'cardX' as name assigned. Lets reduce this magnificent number of
names for the same concept by one and rename DRM_MINOR_LEGACY to
DRM_MINOR_PRIMARY (to match the actual struct-member name).

Furthermore, this is in no way a legacy node, so lets not call it that.

Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Frank Binns <frank.binns@imgtec.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20160803180432.1341-2-dh.herrmann@gmail.com
2016-08-08 10:05:20 +02:00
Chris Wilson
a787900564 drm: Skip initialising the drm_mm_node->hole_stack
As we always add this to the drm_mm->hole_stack as our first operation,
we do not need to initialise the list node.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-3-git-send-email-chris@chris-wilson.co.uk
2016-08-08 10:05:18 +02:00
Chris Wilson
db2395eccf drm: Convert drm_vma_manager to embedded interval-tree in drm_mm
Having added an interval-tree to struct drm_mm, we can replace the
auxiliary rb-tree inside the drm_vma_manager with it.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-2-git-send-email-chris@chris-wilson.co.uk
2016-08-08 10:05:17 +02:00
Chris Wilson
202b52b7fb drm: Track drm_mm nodes with an interval tree
In addition to the last-in/first-out stack for accessing drm_mm nodes,
we occasionally and in the future often want to find a drm_mm_node by an
address. To do so efficiently we need to track the nodes in an interval
tree - lookups for a particular address will then be O(lg(N)), where N
is the number of nodes in the range manager as opposed to O(N).
Insertion however gains an extra O(lg(N)) step for all nodes
irrespective of whether the interval tree is in use. For future i915
patches, eliminating the linear walk is a significant improvement.

v2: Use generic interval-tree template for u64 and faster insertion.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: David Herrmann <dh.herrmann@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Reviewed-by: David Herrmann <dh.herrmann@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470236651-678-1-git-send-email-chris@chris-wilson.co.uk
2016-08-08 10:05:16 +02:00
Rodrigo Vivi
1d776851a6 drm: Avoid printing negative values for unsigned variables.
It was really strange to see negative vblank seqs on debug
messages. It is rare to have that big number, but when it
happens it is confusing and misleading.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470243226-2750-1-git-send-email-rodrigo.vivi@intel.com
2016-08-08 10:05:15 +02:00
Daniel Vetter
c5b7e97b27 drm/i915: Update DRIVER_DATE to 20160808
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-08 09:37:31 +02:00
Dave Airlie
4872850a19 Merge branch 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux into drm-next
A few fixes for amdgpu and ttm for 4.8
- fix a ttm regression caused by the new pipelining code
- fixes for mullins on amdgpu
- updated golden settings for amdgpu

* 'drm-next-4.8' of git://people.freedesktop.org/~agd5f/linux:
  drm/ttm: Wait for a BO to become idle before unbinding it from GTT
  drm/amdgpu: update golden setting of polaris10
  drm/amdgpu: update golden setting of stoney
  drm/amdgpu: update golden setting of polaris11
  drm/amdgpu: update golden setting of carrizo
  drm/amdgpu: update golden setting of iceland
  drm/amd/amdgpu: change pptable output format from ASCII to binary
  drm/amdgpu/ci: add mullins to default case for smc ucode
  drm/amdgpu/gmc7: add missing mullins case
2016-08-08 16:45:33 +10:00
Dave Airlie
e8285cec4e Merge tag 'drm-intel-next-fixes-2016-08-05' of git://anongit.freedesktop.org/drm-intel into drm-next
3 intel fixes.

* tag 'drm-intel-next-fixes-2016-08-05' of git://anongit.freedesktop.org/drm-intel:
  drm/i915/fbdev: Check for the framebuffer before use
  drm/i915: Never fully mask the the EI up rps interrupt on SNB/IVB
  drm/i915: Wait up to 3ms for the pcu to ack the cdclk change request on SKL
2016-08-08 16:16:26 +10:00
Daniel Vetter
5c6c201ccb drm: Paper over locking inversion after registration rework
drm_connector_register_all requires a few too many locks because our
connector_list locking is busted. Add another FIXME+hack to work
around this. This should address the below lockdep splat:

======================================================
[ INFO: possible circular locking dependency detected ]
4.7.0-rc5+ #524 Tainted: G           O
-------------------------------------------------------
kworker/u8:0/6 is trying to acquire lock:
 (&dev->mode_config.mutex){+.+.+.}, at: [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120

but task is already holding lock:
 ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 ((fb_notifier_list).rwsem){++++.+}:
       [<ffffffff810df611>] lock_acquire+0xb1/0x200
       [<ffffffff819a55b4>] down_write+0x44/0x80
       [<ffffffff810abf91>] blocking_notifier_chain_register+0x21/0xb0
       [<ffffffff814c7448>] fb_register_client+0x18/0x20
       [<ffffffff814c6c86>] backlight_device_register+0x136/0x260
       [<ffffffffa0127eb2>] intel_backlight_device_register+0xa2/0x160 [i915]
       [<ffffffffa00f46be>] intel_connector_register+0xe/0x10 [i915]
       [<ffffffffa0112bfb>] intel_dp_connector_register+0x1b/0x80 [i915]
       [<ffffffff8159dfea>] drm_connector_register+0x4a/0x80
       [<ffffffff8159fe44>] drm_connector_register_all+0x64/0xf0
       [<ffffffff815a2a64>] drm_modeset_register_all+0x174/0x1c0
       [<ffffffff81599b72>] drm_dev_register+0xc2/0xd0
       [<ffffffffa00621d7>] i915_driver_load+0x1547/0x2200 [i915]
       [<ffffffffa006d80f>] i915_pci_probe+0x4f/0x70 [i915]
       [<ffffffff814a2135>] local_pci_probe+0x45/0xa0
       [<ffffffff814a349b>] pci_device_probe+0xdb/0x130
       [<ffffffff815c07e3>] driver_probe_device+0x223/0x440
       [<ffffffff815c0ad5>] __driver_attach+0xd5/0x100
       [<ffffffff815be386>] bus_for_each_dev+0x66/0xa0
       [<ffffffff815c002e>] driver_attach+0x1e/0x20
       [<ffffffff815bf9be>] bus_add_driver+0x1ee/0x280
       [<ffffffff815c1810>] driver_register+0x60/0xe0
       [<ffffffff814a1a10>] __pci_register_driver+0x60/0x70
       [<ffffffffa01a905b>] i915_init+0x5b/0x62 [i915]
       [<ffffffff8100042d>] do_one_initcall+0x3d/0x150
       [<ffffffff811a935b>] do_init_module+0x5f/0x1d9
       [<ffffffff81124416>] load_module+0x20e6/0x27e0
       [<ffffffff81124d63>] SYSC_finit_module+0xc3/0xf0
       [<ffffffff81124dae>] SyS_finit_module+0xe/0x10
       [<ffffffff819a83a9>] entry_SYSCALL_64_fastpath+0x1c/0xac

-> #0 (&dev->mode_config.mutex){+.+.+.}:
       [<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260
       [<ffffffff810df611>] lock_acquire+0xb1/0x200
       [<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0
       [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
       [<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
       [<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50
       [<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]
       [<ffffffff814c13c6>] fbcon_init+0x586/0x610
       [<ffffffff8154d16a>] visual_init+0xca/0x130
       [<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0
       [<ffffffff8154eaf6>] do_take_over_console+0x116/0x180
       [<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0
       [<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750
       [<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0
       [<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70
       [<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20
       [<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20
       [<ffffffff814c86b1>] register_framebuffer+0x251/0x330
       [<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0
       [<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]
       [<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150
       [<ffffffff810a3947>] process_one_work+0x1e7/0x750
       [<ffffffff810a3efb>] worker_thread+0x4b/0x4f0
       [<ffffffff810aad4f>] kthread+0xef/0x110
       [<ffffffff819a85ef>] ret_from_fork+0x1f/0x40

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock((fb_notifier_list).rwsem);
                               lock(&dev->mode_config.mutex);
                               lock((fb_notifier_list).rwsem);
  lock(&dev->mode_config.mutex);

 *** DEADLOCK ***

6 locks held by kworker/u8:0/6:
 #0:  ("events_unbound"){.+.+.+}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750
 #1:  ((&entry->work)){+.+.+.}, at: [<ffffffff810a38c9>] process_one_work+0x169/0x750
 #2:  (registration_lock){+.+.+.}, at: [<ffffffff814c8487>] register_framebuffer+0x27/0x330
 #3:  (console_lock){+.+.+.}, at: [<ffffffff814c86ce>] register_framebuffer+0x26e/0x330
 #4:  (&fb_info->lock){+.+.+.}, at: [<ffffffff814c78dd>] lock_fb_info+0x1d/0x40
 #5:  ((fb_notifier_list).rwsem){++++.+}, at: [<ffffffff810ac195>] __blocking_notifier_call_chain+0x35/0x70

stack backtrace:
CPU: 2 PID: 6 Comm: kworker/u8:0 Tainted: G           O    4.7.0-rc5+ #524
Hardware name: Intel Corp. Broxton P/NOTEBOOK, BIOS APLKRVPA.X64.0138.B33.1606250842 06/25/2016
Workqueue: events_unbound async_run_entry_fn
 0000000000000000 ffff8800758577f0 ffffffff814507a5 ffffffff828b9900
 ffffffff828b9900 ffff880075857830 ffffffff810dc6fa ffff880075857880
 ffff88007584d688 0000000000000005 0000000000000006 ffff88007584d6b0
Call Trace:
 [<ffffffff814507a5>] dump_stack+0x67/0x92
 [<ffffffff810dc6fa>] print_circular_bug+0x1aa/0x200
 [<ffffffff810df0ac>] __lock_acquire+0x10fc/0x1260
 [<ffffffff810df611>] lock_acquire+0xb1/0x200
 [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
 [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
 [<ffffffff819a3097>] mutex_lock_nested+0x67/0x3c0
 [<ffffffff815afde0>] ? drm_modeset_lock_all+0x40/0x120
 [<ffffffff810fa85f>] ? rcu_read_lock_sched_held+0x7f/0x90
 [<ffffffff81208218>] ? kmem_cache_alloc_trace+0x248/0x2b0
 [<ffffffff815afdc5>] ? drm_modeset_lock_all+0x25/0x120
 [<ffffffff815afde0>] drm_modeset_lock_all+0x40/0x120
 [<ffffffff8158f79b>] drm_fb_helper_restore_fbdev_mode_unlocked+0x2b/0x80
 [<ffffffff8158f81d>] drm_fb_helper_set_par+0x2d/0x50
 [<ffffffffa0105f7a>] intel_fbdev_set_par+0x1a/0x60 [i915]
 [<ffffffff814c13c6>] fbcon_init+0x586/0x610
 [<ffffffff8154d16a>] visual_init+0xca/0x130
 [<ffffffff8154e611>] do_bind_con_driver+0x1c1/0x3a0
 [<ffffffff8154eaf6>] do_take_over_console+0x116/0x180
 [<ffffffff814bd3a7>] do_fbcon_takeover+0x57/0xb0
 [<ffffffff814c1e48>] fbcon_event_notify+0x658/0x750
 [<ffffffff810abcae>] notifier_call_chain+0x3e/0xb0
 [<ffffffff810ac1ad>] __blocking_notifier_call_chain+0x4d/0x70
 [<ffffffff810ac1e6>] blocking_notifier_call_chain+0x16/0x20
 [<ffffffff814c748b>] fb_notifier_call_chain+0x1b/0x20
 [<ffffffff814c86b1>] register_framebuffer+0x251/0x330
 [<ffffffff815b7e8d>] ? vga_switcheroo_client_fb_set+0x5d/0x70
 [<ffffffff8158fa9f>] drm_fb_helper_initial_config+0x25f/0x3f0
 [<ffffffffa0106b48>] intel_fbdev_initial_config+0x18/0x30 [i915]
 [<ffffffff810adfd8>] async_run_entry_fn+0x48/0x150
 [<ffffffff810a3947>] process_one_work+0x1e7/0x750
 [<ffffffff810a38c9>] ? process_one_work+0x169/0x750
 [<ffffffff810a3efb>] worker_thread+0x4b/0x4f0
 [<ffffffff810a3eb0>] ? process_one_work+0x750/0x750
 [<ffffffff810aad4f>] kthread+0xef/0x110
 [<ffffffff819a85ef>] ret_from_fork+0x1f/0x40
 [<ffffffff810aac60>] ? kthread_stop+0x2e0/0x2e0

v2: Rebase onto the right branch (hand-editing patches ftw) and add more
reporters.

Reported-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: Jiri Kosina <jikos@kernel.org>
Cc: Jiri Kosina <jikos@kernel.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-08-08 16:08:25 +10:00
Laurent Pinchart
29986cc8a6 drm: rcar-du: Link HDMI encoder with bridge
The conversion of the rcar-du driver from the I2C slave encoder to the
DRM bridge API left the HDMI encoder's bridge pointer NULL, preventing
the bridge from being handled automatically by the DRM core. Fix it.

Fixes: 1d926114d8 ("drm: rcar-du: Remove i2c slave encoder interface for hdmi encoder")
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
2016-08-08 15:27:11 +10:00
Al Viro
bcd599e790 gpu: use %pd
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
2016-08-07 23:38:48 -04:00
Linus Torvalds
635a4ba111 Merge tag 'drm-for-v4.8-zpos' of git://people.freedesktop.org/~airlied/linux
Pull drm zpos property support from Dave Airlie:
 "This tree was waiting on some media stuff I hadn't had time to get a
  stable branchpoint off, so I just waited until it was all in your tree
  first.

  It's been around a bit on the list and shouldn't affect anything
  outside adding the generic API and moving some ARM drivers to using
  it"

* tag 'drm-for-v4.8-zpos' of git://people.freedesktop.org/~airlied/linux:
  drm: rcar: use generic code for managing zpos plane property
  drm/exynos: use generic code for managing zpos plane property
  drm: sti: use generic zpos for plane
  drm: add generic zpos property
2016-08-07 16:35:08 -07:00
Matthew Auld
cb7f27601c drm/i915: fix aliasing_ppgtt leak
In i915_ggtt_cleanup_hw we need to remember to free aliasing_ppgtt. This
fixes the following kmemleak message:

unreferenced object 0xffff880213cca000 (size 8192):
  comm "modprobe", pid 1298, jiffies 4294745402 (age 703.930s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<ffffffff817c808e>] kmemleak_alloc+0x4e/0xb0
    [<ffffffff8121f9c2>] kmem_cache_alloc_trace+0x142/0x1d0
    [<ffffffffa06d11ef>] i915_gem_init_ggtt+0x10f/0x210 [i915]
    [<ffffffffa06d71bb>] i915_gem_init+0x5b/0xd0 [i915]
    [<ffffffffa069749a>] i915_driver_load+0x97a/0x1460 [i915]
    [<ffffffffa06a26ef>] i915_pci_probe+0x4f/0x70 [i915]
    [<ffffffff81423015>] local_pci_probe+0x45/0xa0
    [<ffffffff81424463>] pci_device_probe+0x103/0x150
    [<ffffffff81515e6c>] driver_probe_device+0x22c/0x440
    [<ffffffff81516151>] __driver_attach+0xd1/0xf0
    [<ffffffff8151379c>] bus_for_each_dev+0x6c/0xc0
    [<ffffffff8151555e>] driver_attach+0x1e/0x20
    [<ffffffff81514fa3>] bus_add_driver+0x1c3/0x280
    [<ffffffff81516aa0>] driver_register+0x60/0xe0
    [<ffffffff8142297c>] __pci_register_driver+0x4c/0x50
    [<ffffffffa013605b>] 0xffffffffa013605b

Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Fixes: b18b6bde30 ("drm/i915/bdw: Free PPGTT struct")
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470420280-21417-1-git-send-email-matthew.auld@intel.com
2016-08-05 22:39:32 +02:00
Daniel Vetter
437c30874c drm/i915: Update comment before i915_spin_request
~jiffie and a few usecs is 3 orders of magnitude different. A bit
much. This was changed in

commit ca5b721e23
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Dec 11 11:32:58 2015 +0000

    drm/i915: Limit the busy wait on requests to 5us not 10ms!

But probably missed the comment since the change was non-local to the
comment.

v2: Polish comment more (Chris).

Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470413484-23775-1-git-send-email-daniel.vetter@ffwll.ch
2016-08-05 22:30:56 +02:00
Ville Syrjälä
ae98104bec drm/i915: Use the g4x+ approach on gen2 for handling display stuff around GPU reset
We don't have GPU reset support for gen2, which means the display
hardware is unaffected when a GPU hang is handled. However as the ring
has in fact stopped, any flips still in the ring will never complete,
and thus the display base address updates will never happen. So we
really need to fix that up manually just like we do on g4x+.

In fact, let's just use intel_has_gpu_reset() instead of IS_GEN2()
since that'll also handle cases where someone would disable the GPU
reset support on gen3/4 for whatever reason.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470428910-12125-5-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-05 23:28:30 +03:00
Ville Syrjälä
4ac2ba2f8c drm/i915: Introduce gpu_reset_clobbers_display()
Factor out the "does the GPU reset clobber the display?" check into a
small helper.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470428910-12125-4-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-05 23:28:29 +03:00
Maarten Lankhorst
522a63de18 drm/i915: Add a way to test the modeset done during gpu reset, v3.
Add force_reset_modeset_test as a parameter to force the modeset path during gpu reset.
This allows a IGT test to set the knob and trigger a hang to force the gpu reset,
even on platforms that wouldn't otherwise require it.

Changes since v1:
- Split out fix to separate commit.
Changes since v2:
- This commit is purely about force_reset_modeset_test now.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Testcase: drv_hangman.reset-with-forced-modeset
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470428910-12125-3-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2016-08-05 23:28:28 +03:00
Maarten Lankhorst
7397489399 drm/i915: Fix modeset handling during gpu reset, v5.
This function would call drm_modeset_lock_all, while the suspend/resume
functions already have their own locking. Fix this by factoring out
__intel_display_resume, and calling the atomic helpers for duplicating
atomic state and disabling all crtc's during suspend.

Changes since v1:
- Deal with -EDEADLK right after lock_all and clean up calls
  to hw readout.
- Always take all modeset locks so updates during gpu reset are blocked.
Changes since v2:
- Fix deadlock in intel_update_primary_planes.
- Move WARN_ON(EDEADLK) to __intel_display_resume.
- pctx -> ctx
- only call __intel_display_resume on success in intel_display_resume.
Changes since v3:
- Rebase on top of dev_priv -> dev change.
- Use drm_modeset_lock_all_ctx instead of drm_modeset_lock_all.
Changes since v4 [by vsyrjala]:
- Deal with skip_intermediate_wm
- Update comment w.r.t. mode_config.mutex vs. ->detect()
- Rebase due to INTEL_GEN() etc.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: e2c8b8701e ("drm/i915: Use atomic helpers for suspend, v2.")
Cc: stable@vger.kernel.org
Tested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470428910-12125-2-git-send-email-ville.syrjala@linux.intel.com
2016-08-05 23:28:27 +03:00
Michel Dänzer
34b58355ad drm/ttm: Wait for a BO to become idle before unbinding it from GTT
Fixes hangs under memory pressure, e.g. running the piglit test
tex3d-maxsize concurrently with other tests.

Fixes: 17d33bc9d6 ("drm/ttm: drop waiting for idle in ttm_bo_evict.")
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2016-08-05 13:37:02 -04:00
Ville Syrjälä
a168f5b3f1 drm/i915: Don't mark PCH underrun reporting as disabled for transcoder B/C on LPT-H
Marking PCH transcoder FIFO underrun reporting as disabled for
transcoder B/C on LPT-H will block us from enabling the south error
interrupt. So let's only mark transcoder A underrun reporting as
disabled initially.

This is a little tricky to hit since you need a machine with LPT-H, and
the BIOS must enable either pipe B or C at boot. Then i915 would mark
the "transcoder B/C" underrun reporting as disabled and never enable it
again, meaning south interrupts would never get enabled either. The only
other interrupt in there is actually the poison interrupt which, if we
could ever trigger it, would just result in a little error in dmesg.

Here's the resulting change in SDEIMR on my HSW when I boot it with
multiple displays attached:
- (0x000c4004): 0xf115ffff
+ (0x000c4004): 0xf114ffff

My previous attempt [1] tried to fix this a little differently, but
Daniel requested I do this instead.

[1] https://lists.freedesktop.org/archives/intel-gfx/2015-November/081420.html

Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470416417-15021-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-05 20:00:17 +03:00
Ville Syrjälä
09fa8bb909 drm/i915: Add some curly braces
intel_enable_pipe() looks rather confusing when one side doesn't have
the curly braces, and the other one does. And what's even worse,
there's another if-else inside the braceless side. Let's put braces
around it to make it clear which branch goes where.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470418894-1249-1-git-send-email-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-08-05 20:41:34 +03:00
Chris Wilson
5a198b8c53 drm/i915: Do not overwrite the request with zero on reallocation
When using RCU lookup for the request, commit 0eafec6d32 ("drm/i915:
Enable lockless lookup of request tracking via RCU"), we acknowledge that
we may race with another thread that could have reallocated the request.
In order for the first thread not to blow up, the second thread must not
clear the request completed before overwriting it. In the RCU lookup, we
allow for the engine/seqno to be replaced but we do not allow for it to
be zeroed.

The choice we make is to either add extra checking to the RCU lookup, or
embrace the inherent races (as intended). It is more complicated as we
need to manually clear everything we depend upon being zero initialised,
but we benefit from not emiting the memset() to clear the entire
frequently allocated structure (that memset turns up in throughput
profiles). And at the same time, the lookup remains flexible for future
adjustments.

v2: Old style LRC requires another variable to be initialize. (The
danger inherent in not zeroing everything.)
v3: request->batch also needs to be cleared
v4: signaling.tsk is no long used unset, but pid still exists

Fixes: 0eafec6d32 ("drm/i915: Enable lockless lookup of request...")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: "Goel, Akash" <akash.goel@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470731014-6894-2-git-send-email-chris@chris-wilson.co.uk
2016-08-09 10:17:27 +01:00
Chris Wilson
edf6b76f64 drm/i915: Add smp_rmb() to busy ioctl's RCU dance
In the debate as to whether the second read of active->request is
ordered after the dependent reads of the first read of active->request,
just give in and throw a smp_rmb() in there so that ordering of loads is
assured.

v2: Explain the manual smp_rmb()

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470731014-6894-1-git-send-email-chris@chris-wilson.co.uk
2016-08-09 10:17:26 +01:00
Chris Wilson
87b723a16d drm/i915: Don't check for idleness before retiring after a GPU hang
When we force the cleanup after a GPU hang, we want to retire all
requests, or else we may leak them if truly wedged (and the GPU never
advances again). Converting to the active request helpers had the issue
of doing the check against busyness before reporting the request, so if
we claim the GPU had hung but this engine hadn't we could potential skip
the request cleanup - triggering the self-check BUG.

Fixes: dcff85c844 ("drm/i915: Enable i915_gem_wait_for_idle() ...")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470728222-10243-3-git-send-email-chris@chris-wilson.co.uk
2016-08-09 09:11:59 +01:00
Chris Wilson
385384a82c drm/i915: Wrap the protected active RCU dereference in a helper
As we do the lockdep protected RCU lookup in a couple of places,
refactor that code to a common helper i915_gem_active_raw().

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470728222-10243-2-git-send-email-chris@chris-wilson.co.uk
2016-08-09 09:11:59 +01:00
Chris Wilson
2e7ba01494 drm/i915: Remove unused i915_gem_active_peek_rcu()
This was originally introduced to be used by the busy-ioctl, but in the
end busy ioctl performed a different dance. Since there are no users,
and no likely users, remove an unwanted chunk of the API.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1470728222-10243-1-git-send-email-chris@chris-wilson.co.uk
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-08-09 09:11:39 +01:00
Rodrigo Vivi
4194c088df drm/i915: Use drm official vblank_no_hw_counter callback.
No functional change. Instead of defining a new empty function
let's use what is available on drm.

It gets cleaner, and easy to read, and understand.

Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2016-08-05 09:40:07 -07:00
Rodrigo Vivi
4e9121e6b4 drm/i915: Fix copy_to_user usage for pipe_crc
Copy to user return the number of bytes it couldn't write
and zero on success. So any number different than 0 should
be considered a fault, not only when it doesn't write
the full size.

v2: fixed the inverted logic. (Ville)

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2016-08-05 09:39:47 -07:00
Ville Syrjälä
19e0b4cab9 Revert "drm/i915: Track active streams also for DP SST"
This reverts commit f64425a82b.

active_streams will get totally out of whack with SST unless we
sync up with the hw state at readout, obviously! We don't yet
do that, so now the WARNs fire all the time. Let's revert :(

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470413142-26402-1-git-send-email-ville.syrjala@linux.intel.com
References: https://bugs.freedesktop.org/show_bug.cgi?id=95472#c14
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
2016-08-05 19:20:31 +03:00
Matthew Auld
575e3ccbce drm/i915: fix WaInsertDummyPushConstPs
As pointed out by Chris Harris, we are using the wrong WA name, it
should in fact be WaToEnableHwFixForPushConstHWBug, also it should be
applied from C0 onwards for both BXT and KBL.

Fixes: 7b9005cd45 ("drm/i915: Add WaInsertDummyPushConstP for bxt and kbl")

Cc: Chris Harris <chris.harris@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reported-by: Chris Harris <chris.harris@intel.com>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470127013-29653-1-git-send-email-matthew.auld@intel.com
2016-08-05 13:16:55 +03:00
Chris Wilson
209b3f7ed0 drm/i915: Assert that the request hasn't been retired
With all callers now not playing tricks with dropping the struct_mutex
between waiting and retiring, we can assert that the request is ready to
be retired.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-19-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:44 +01:00
Chris Wilson
3e510a8e65 drm/i915: Repack fence tiling mode and stride into a single integer
In the previous commit, we moved the obj->tiling_mode out of a bitfield
and into its own integer so that we could safely use READ_ONCE(). Let us
now repair some of that damage by sharing the tiling_mode with its
companion, the fence stride.

v2: New magic

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-18-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:43 +01:00
Chris Wilson
deeb1519b6 drm/i915: Document and reject invalid tiling modes
Through the GTT interface to the fence registers, we can only handle
linear, X and Y tiling. The more esoteric tiling patterns are ignored.
Document that the tiling ABI only supports upto Y tiling, and reject any
attempts to set a tiling mode other than NONE, X or Y.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-17-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:42 +01:00
Chris Wilson
9ad3676148 drm/i915: Remove locking for get_tiling
Since we are not concerned with userspace racing itself with set-tiling
(the order is indeterminant even if we take a lock), then we can safely
read back the single obj->tiling_mode and do the static lookup of
swizzle mode without having to take a lock.

get-tiling is reasonably frequent due to the back-channel passing around
of tiling parameters in DRI2/DRI3.

v2: Make tiling_mode a full unsigned int so that we can trivially use it
with READ_ONCE(). Separating it out into manual control over the flags
field was too noisy for a simple patch. Note that we could use the lower
bits of obj->stride for the tiling mode.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-16-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:42 +01:00
Chris Wilson
e883d73503 drm/i915: Remove pinned check from madvise ioctl
We don't need to incur the overhead of checking whether the object is
pinned prior to changing its madvise. If the object is pinned, the
madvise will not take effect until it is unpinned and so we cannot free
the pages being pointed at by hardware. Marking a pinned object with
allocated pages as DONTNEED will not trigger any undue warnings. The check
is therefore superfluous, and by removing it we can remove a linear walk
over all the vma the object has.

Still despite it being an overzealous check, that error code is part of
the current ABI and so we must proceed with caution.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-15-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:41 +01:00
Chris Wilson
c21724cc4d drm/i915: Reduce locking inside swfinish ioctl
We only need to take the struct_mutex if the object is pinned to the
display engine and so requires checking for clflush. (The race with
userspace pinning the object to a framebuffer is irrelevant.)

v2: Use access once for compiler hints (or not as it is a bitfield)
v3: READ_ONCE, obj->pin_display is not a bitfield anymore
v4: Don't be creative with goto.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-14-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:41 +01:00
Chris Wilson
3fdc13c7a3 drm/i915: Remove (struct_mutex) locking for busy-ioctl
By applying the same logic as for wait-ioctl, we can query whether a
request has completed without holding struct_mutex. The biggest impact
system-wide is removing the flush_active and the contention that causes.

Testcase: igt/gem_busy
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Akash Goel <akash.goel@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-13-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:40 +01:00
Chris Wilson
033d549b81 drm/i915: Remove (struct_mutex) locking for wait-ioctl
With a bit of care (and leniency) we can iterate over the object and
wait for previous rendering to complete with judicial use of atomic
reference counting. The ABI requires us to ensure that an active object
is eventually flushed (like the busy-ioctl) which is guaranteed by our
management of requests (i.e. everything that is submitted to hardware is
flushed in the same request). All we have to do is ensure that we can
detect when the requests are complete for reporting when the object is
idle (without triggering ETIME), locklessly - this is handled by
i915_gem_active_wait_unlocked().

The impact of this is actually quite small - the return to userspace
following the wait was already lockless and so we don't see much gain in
latency improvement upon completing the wait. What we do achieve here is
completing an already finished wait without hitting the struct_mutex,
our hold is quite short and so we are typically just a victim of
contention rather than a cause - but it is still one less contention
point!

v2: Break up a long line.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-12-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:40 +01:00
Chris Wilson
258a5edee0 drm/i915: Do a nonblocking wait first in pread/pwrite
If we try and read or write to an active request, we first must wait
upon the GPU completing that request. Let's do that without holding the
mutex (and so allow someone else to access the GPU whilst we wait). Upon
completion, we will acquire the mutex and only then start the operation
(i.e. we do not rely on state from before the initial wait).

v2: Repaint the goto labels
v3: Move the tracepoints back to the start of the ioctls

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-11-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:39 +01:00
Chris Wilson
3b4e896f14 drm/i915: Remove unused no-shrinker-steal
After removing the user of this wart, we can remove the wart entirely.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-10-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:39 +01:00
Chris Wilson
f3f6184c5f drm/i915: Tidy generation of the GTT mmap offset
If we make the observation that mmap-offsets are only released when we
free an object, we can then deduce that the shrinker only creates free
space in the mmap arena indirectly by flushing the request list and
freeing expired objects. If we combine this with the lockless
vma-manager and lockless idling, we can avoid taking our big struct_mutex
until we need to actually free the requests.

One side-effect is that we defer the madvise checking until we need the
pages (i.e. the fault handler). This brings us into line with the other
delayed checks (and madvise in general).

v2: s/ret/err/ and use if (!err) rather than if (ret == 0)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-9-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:38 +01:00
Chris Wilson
5cba5be6b6 drm/i915/shrinker: Wait before acquiring struct_mutex under oom
We can now wait for the GPU (all engines) to become idle without
requiring the struct_mutex. Inside the shrinker, we need to currently
take the struct_mutex in order to purge objects and to purge the objects
we need the GPU to be idle - causing a stall whilst we hold the
struct_mutex. We can hide most of that stall by performing the wait
before taking the struct_mutex and only doing essential waits for
new rendering on objects to be freed.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-8-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:38 +01:00
Chris Wilson
307dc25bf6 drm/i915: Simplify do_idling() (Ironlake vt-d w/a)
Now that we pass along the expected interruptible nature for the
wait-for-idle, we do not need to modify the global
i915->mm.interruptible for this single call. (Only the immediate call to
i915_gem_wait_for_idle() takes the interruptible status as the other
action, dma_map_sg(), is independent of i915.ko)

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-7-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:37 +01:00
Chris Wilson
dcff85c844 drm/i915: Enable i915_gem_wait_for_idle() without holding struct_mutex
The principal motivation for this was to try and eliminate the
struct_mutex from i915_gem_suspend - but we still need to hold the mutex
current for the i915_gem_context_lost(). (The issue there is that there
may be an indirect lockdep cycle between cpu_hotplug (i.e. suspend) and
struct_mutex via the stop_machine().) For the moment, enabling last
request tracking for the engine, allows us to do busyness checking and
waiting without requiring the struct_mutex - which is useful in its own
right.

As a side-effect of having a robust means for tracking engine busyness,
we can replace our other busyness heuristic, that of comparing against
the last submitted seqno. For paranoid reasons, we have a semi-ordered
check of that seqno inside the hangchecker, which we can now improve to
an ordered check of the engine's busyness (removing a locked xchg in the
process).

v2: Pass along "bool interruptible" as being unlocked we cannot rely on
i915->mm.interruptible being stable or even under our control.
v3: Replace check Ironlake i915_gpu_busy() with the common precalculated value

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1470388464-28458-6-git-send-email-chris@chris-wilson.co.uk
2016-08-05 10:54:37 +01:00