Ander Conselvan de Oliveira [Thu, 2 Mar 2017 12:58:52 +0000 (14:58 +0200)]
drm/i915: Pass intel_crtc to intel_lpt_pch_enable()
The function intel_lpt_pch_enable() needs an intel_crtc so pass that
instead of the generic crtc type.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302125857.14665-3-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Thu, 2 Mar 2017 12:58:51 +0000 (14:58 +0200)]
drm/i915: Pass intel_crtc to fdi_link_train() hooks
The implementation of the fdi_link_train() hooks need an intel_crtc so
just pass that instead of the generic crtc type.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302125857.14665-2-ander.conselvan.de.oliveira@intel.com
Chris Wilson [Fri, 3 Mar 2017 09:00:56 +0000 (09:00 +0000)]
drm/i915: Differentiate between hangcheck waiting for timer or scheduler
Check timer_pending() as well as work_pending() to see if the timer for
the hangcheck has already expired and the work is pending execution on
some list somewhere.
v2: Use a more compact if-chain
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170303090056.19973-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Chris Wilson [Thu, 2 Mar 2017 12:25:25 +0000 (12:25 +0000)]
drm/i915: Drop spinlocks around adding to the client request list
Adding to the tail of the client request list as the only other user is
in the throttle ioctl that iterates forwards over the list. It only
needs protection against deletion of a request as it reads it, it simply
won't see a new request added to the end of the list, or it would be too
early and rejected. We can further reduce the number of spinlocks
required when throttling by removing stale requests from the client_list
as we throttle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302122525.19675-1-chris@chris-wilson.co.uk
Ville Syrjälä [Mon, 20 Feb 2017 14:04:43 +0000 (16:04 +0200)]
drm/i915: Do .init_clock_gating() earlier to avoid it clobbering watermarks
Currently ILK-BDW explicitly disable LP1+ watermarks from their
.init_clock_gating() hooks. Unfortunately that hook gets called way too
late since by that time we've already initialized all the watermark
state tracking which then gets out of sync with the hardware state.
We may eventually want to consider killing off the explicit LP1+
disable from .init_clock_gating(). In the meantime however, we can
avoid the problem by reordering the init sequence such that
intel_modeset_init_hw()->intel_init_clock_gating() gets called
prior to the hardware state takeover.
I suppose prior to the two stage watermark programming we were
magically saved by something that forced the watermarks to be
reprogrammed fully after .init_clock_gating() got called. But
now that no longer happens.
Note that the diff might look a bit odd as it kills off one
call of intel_update_cdclk(), but that's fine because
intel_modeset_init_hw() does the exact same thing. Previously
we just did it twice.
Actually even this new init sequence is pretty bogus as
.init_clock_gating() really should be called before any gem
hardware init since it can configure various clock gating
workarounds and whatnot that affect the GT side as well. Also
intel_modeset_init() really should get split up into better
defined init stages. Another "fun" detail is that
intel_modeset_gem_init() is where RPS/RC6 gets configured.
Why that is done from the display code is beyond me. I've
decided to leave all this be for now, and just try to fix
the init sequence enough for watermarks to work.
Cc: stable@vger.kernel.org
Cc: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Cc: David Purton <dcpurton@marshwiggle.net>
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reported-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Reported-by: David Purton <dcpurton@marshwiggle.net>
Tested-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96645
Fixes:
ed4a6a7ca853 ("drm/i915: Add two-stage ILK-style watermark programming (v11)")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170220140443.30891-1-ville.syrjala@linux.intel.com
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Chris Wilson [Thu, 2 Mar 2017 15:15:44 +0000 (15:15 +0000)]
drm/i915: Include power-management state in gpu error dump
Useful for double checking that the device is powered up when it hung,
include both the status of the power management and our rpm wakelock.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302151544.16915-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Chris Wilson [Thu, 2 Mar 2017 15:03:56 +0000 (15:03 +0000)]
drm/i915: Include GT/seqno activity in engine/hangcheck debugfs
Whilst investigating some mysterious failures with hangcheck not running
during gem_busy/basic-hang-default, the question is why did we decide to
cancel the retire_work (which queues the hangcheck)? That decision is
based around GT activity, so include that information in the debug
report.
v2: Include the GT awake status in the error state
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302150356.9713-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Chris Wilson [Thu, 2 Mar 2017 14:53:23 +0000 (14:53 +0000)]
drm/i915/guc: Disable irq for __i915_guc_submit wq_lock
__i915_guc_submit may be, despite my assertion, called from outside of
an irq-safe spinlock so we need to use a full spin_lock_irqsave and not
cheat using a spin_lock. (The initial notify callback from the completed
fence is called before the spinlock is taken to wake up all waiters and
call their callbacks.)
[ 48.166581] kernel BUG at drivers/gpu/drm/i915/i915_guc_submission.c:527!
[ 48.166617] invalid opcode: 0000 [#1] PREEMPT SMP
[ 48.166644] Modules linked in: i915 prime_numbers x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel mei_me mei i2c_i801 netconsole i2c_hid [last unloaded: i915]
[ 48.166733] CPU: 2 PID: 5 Comm: kworker/u8:0 Tainted: G U 4.10.0nightly-170302-guc_scrub+ #19
[ 48.166778] Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0054.2016.0930.1102 09/30/2016
[ 48.166835] Workqueue: i915 __intel_autoenable_gt_powersave [i915]
[ 48.166865] task:
ffff88084ab7cf40 task.stack:
ffffc90000064000
[ 48.166921] RIP: 0010:__i915_guc_submit+0x1e6/0x2a0 [i915]
[ 48.166953] RSP: 0018:
ffffc90000067c80 EFLAGS:
00010202
[ 48.166979] RAX:
0000000000000202 RBX:
ffff8808465e0c68 RCX:
0000000000000201
[ 48.167016] RDX:
0000000080000201 RSI:
ffff88084ab7d798 RDI:
ffff88082b8a8040
[ 48.167054] RBP:
ffffc90000067cd8 R08:
0000000000000001 R09:
0000000000000000
[ 48.167085] R10:
0000000000000000 R11:
0000000000000000 R12:
ffff88082b8a8148
[ 48.167126] R13:
0000000000000000 R14:
ffff88082f440000 R15:
ffff88082e85e660
[ 48.167156] FS:
0000000000000000(0000) GS:
ffff88086ed00000(0000) knlGS:
0000000000000000
[ 48.167195] CS: 0010 DS: 0000 ES: 0000 CR0:
0000000080050033
[ 48.167226] CR2:
000055862ffcdc2c CR3:
0000000001e0f000 CR4:
00000000003406e0
[ 48.167257] Call Trace:
[ 48.168112] ? trace_hardirqs_on+0xd/0x10
[ 48.168966] ? _raw_spin_unlock_irqrestore+0x4a/0x80
[ 48.169831] i915_guc_submit+0x1a/0x20 [i915]
[ 48.170680] submit_notify+0x89/0xc0 [i915]
[ 48.171512] __i915_sw_fence_complete+0x175/0x220 [i915]
[ 48.172340] i915_sw_fence_complete+0x2a/0x50 [i915]
[ 48.173158] i915_sw_fence_commit+0x21/0x30 [i915]
[ 48.173968] __i915_add_request+0x238/0x530 [i915]
[ 48.174764] __intel_autoenable_gt_powersave+0x8b/0xb0 [i915]
[ 48.175549] process_one_work+0x218/0x690
[ 48.176318] ? process_one_work+0x197/0x690
[ 48.177183] worker_thread+0x4e/0x4a0
[ 48.178039] kthread+0x10c/0x140
[ 48.178878] ? process_one_work+0x690/0x690
[ 48.179718] ? kthread_create_on_node+0x40/0x40
[ 48.180568] ret_from_fork+0x31/0x40
[ 48.181423] Code: 02 00 00 43 89 84 ae 50 11 00 00 e8 75 01 62 e1 48 83 c4 30 5b 41 5c 41 5d 41 5e 41 5f 5d c3 48 c1 e0 20 48 09 c2 49 89 d0 eb 82 <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 49 c1 e8 20 44 89 43 34 4a
[ 48.183336] RIP: __i915_guc_submit+0x1e6/0x2a0 [i915] RSP:
ffffc90000067c80
Reported-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Fixes:
349ab9192cc3 ("drm/i915/guc: Make wq_lock irq-safe")
Fixes:
67b807a89230 ("drm/i915: Delay disabling the user interrupt for breadcrumbs")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302145323.12886-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Tested-by: Arkadiusz Hiler <arkadiusz.hiler@intel.com>
Chris Wilson [Thu, 2 Mar 2017 13:28:01 +0000 (13:28 +0000)]
drm/i915: s/assert_spin_locked/lockdep_assert_held/
assert_spin_locked() becomes an unconditionally compiled BUG_ON(),
adding debug code right into the heart of critical routines like
interrupt handlers.
text data bss dec hex
1296480 19944 2272
1318696 141f28 before (lockdep disabled)
1295984 19944 2272
1318200 141d38 after
1336261 21139 3208
1360608 14c2e0 before (lockdep enabled)
1339920 21139 3208
1364267 14d12b after
Small saving for release; hopefully more instructive in debug.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302132801.599-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Thu, 2 Mar 2017 11:51:30 +0000 (11:51 +0000)]
drm/i915: Assert that fence->lock is held in an irq-safe manner
Everytime we take the fence->lock (aka request->lock), we must do so
with irqs disabled since it may be used from within an hardirq context.
As sometimes we are taking the lock in a nested manner, assert that the
caller did disable the irqs for us.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302115130.28434-1-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Ville Syrjälä [Fri, 17 Feb 2017 15:01:59 +0000 (17:01 +0200)]
drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW
In order to make cursor updates actually safe wrt. watermark programming
we have to clear the legacy_cursor_update flag in the atomic state. That
will cause the regular atomic update path to do the necessary vblank
wait after the plane update if needed, otherwise the vblank wait would
be skipped and we'd feed the optimal watermarks to the hardware before
the plane update has actually happened.
To make the slow vs. fast path determination in
intel_legacy_cursor_update() a little simpler we can ignore the actual
visibility of the plane (which can only get computed once we've already
chosen out path) and instead we simply check whether the fb is being
set or cleared by the user. This means a fully clipped but logically
visible cursor will be considered visible as far as watermark
programming is concerned. We can do that for the cursor since it's a
fixed size plane and the clipped size doesn't play a role in the
watermark computation.
This should fix underruns that can occur when the cursor gets
enable/disabled or the size gets changed. Hopefully it's good enough
that only pure cursor movement and flips go through unthrottled.
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Uwe Kleine-König <uwe@kleine-koenig.org>
Reported-by: Uwe Kleine-König <uwe@kleine-koenig.org>
Fixes:
f79f26921ee1 ("drm/i915: Add a cursor hack to allow converting legacy page flip to atomic, v3.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170217150159.11683-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Rafael Ristovski <rafael.ristovski@gmail.com>
Madhav Chauhan [Wed, 1 Mar 2017 18:31:22 +0000 (00:01 +0530)]
drm/i915/glk: Fix DSI enable I/O sequence
One of the if statement covers the next line in enable I/O sequence.
This patch correct the same by adding error message.
Fixes:
4644848369c0 ("drm/i915/glk: Add MIPIIO Enable/disable sequence")
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488393082-30660-1-git-send-email-madhav.chauhan@intel.com
Anusha Srivatsa [Wed, 1 Mar 2017 19:58:55 +0000 (11:58 -0800)]
i915/HuC: Add an extra check for platforms that do not have HUC
Return silently without producing much noise on platforms
that have a HuC but the firmware is absent.
Cc: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@itel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488398335-13121-1-git-send-email-anusha.srivatsa@intel.com
Chris Wilson [Thu, 2 Mar 2017 07:41:57 +0000 (07:41 +0000)]
drm/i915: Restore the invalid access without RPM warning
A long time ago we turned off the warning as it was too painful, we had
too much broken code. Turn it back on now as we are mostly clean and
need to prevent returning to such orangeness.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302074157.21631-2-chris@chris-wilson.co.uk
Reviewed-by: Imre Deak <imre.deak@intel.com>
Chris Wilson [Thu, 2 Mar 2017 08:30:29 +0000 (08:30 +0000)]
drm/i915: Hold rpm during GEM suspend in driver unload/suspend
i915_gem_suspend() tries to access the device to ensure it is idle and
all writes from the device are flushed to memory. It assumed is already
held the runtime pm wakeref, but we should explicitly acquire it for our
access to be safe.
[ 619.926287] WARNING: CPU: 3 PID: 9353 at drivers/gpu/drm/i915/intel_drv.h:1750 gen6_write32+0x23e/0x2a0 [i915]
[ 619.926300] RPM wakelock ref not held during HW access
[ 619.926311] Modules linked in: vgem x86_pkg_temp_thermal intel_powerclamp snd_hda_codec_hdmi snd_hda_codec_generic snd_hda_codec coretemp snd_hwdep crct10dif_pclmul snd_hda_core crc32_pclmul snd_pcm mei_me mei lpc_ich ghash_clmulni_intel i915(-) sdhci_pci sdhci mmc_core e1000e ptp pps_core prime_numbers [last unloaded: snd_hda_intel]
[ 619.926578] CPU: 3 PID: 9353 Comm: drv_module_relo Tainted: G U 4.10.0-CI-Trybot_609+ #1
[ 619.926585] Hardware name: LENOVO 42962WU/42962WU, BIOS 8DET56WW (1.26 ) 12/01/2011
[ 619.926592] Call Trace:
[ 619.926609] dump_stack+0x67/0x92
[ 619.926625] __warn+0xc6/0xe0
[ 619.926640] warn_slowpath_fmt+0x4a/0x50
[ 619.926726] gen6_write32+0x23e/0x2a0 [i915]
[ 619.926801] gen6_mm_switch+0x38/0x70 [i915]
[ 619.926871] i915_switch_context+0xec/0xa10 [i915]
[ 619.926942] i915_gem_switch_to_kernel_context+0x13c/0x2b0 [i915]
[ 619.927019] i915_gem_suspend+0x2b/0x180 [i915]
[ 619.927079] i915_driver_unload+0x22/0x200 [i915]
[ 619.927093] ? __this_cpu_preempt_check+0x13/0x20
[ 619.927105] ? trace_hardirqs_on_caller+0xe7/0x200
[ 619.927118] ? trace_hardirqs_on+0xd/0x10
[ 619.927128] ? _raw_spin_unlock_irqrestore+0x3d/0x60
[ 619.927192] i915_pci_remove+0x14/0x20 [i915]
[ 619.927205] pci_device_remove+0x34/0xb0
[ 619.927219] device_release_driver_internal+0x158/0x210
[ 619.927234] driver_detach+0x3b/0x80
[ 619.927245] bus_remove_driver+0x53/0xd0
[ 619.927256] driver_unregister+0x27/0x50
[ 619.927267] pci_unregister_driver+0x25/0xa0
[ 619.927351] i915_exit+0x1a/0xb1a [i915]
[ 619.927362] SyS_delete_module+0x193/0x1e0
[ 619.927378] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 619.927386] RIP: 0033:0x7f82b46c5d37
[ 619.927393] RSP: 002b:
00007ffdb6f610d8 EFLAGS:
00000246 ORIG_RAX:
00000000000000b0
[ 619.927408] RAX:
ffffffffffffffda RBX:
ffffffff81481ff3 RCX:
00007f82b46c5d37
[ 619.927415] RDX:
0000000000000001 RSI:
0000000000000800 RDI:
000000000224f558
[ 619.927422] RBP:
ffffc90001187f88 R08:
0000000000000000 R09:
00007ffdb6f61100
[ 619.927428] R10:
000000000224f4e0 R11:
0000000000000246 R12:
0000000000000000
[ 619.927435] R13:
00007ffdb6f612b0 R14:
0000000000000000 R15:
0000000000000000
[ 619.927451] ? __this_cpu_preempt_check+0x13/0x20
or
[ 641.646590] WARNING: CPU: 1 PID: 8913 at drivers/gpu/drm/i915/intel_drv.h:1750 intel_runtime_pm_get_noresume+0x8b/0x90 [i915]
[ 641.646595] RPM wakelock ref not held during HW access
[ 641.646600] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_codec snd_hwdep crct10dif_pclmul snd_hda_core crc32_pclmul ghash_clmulni_intel snd_pcm mei_me mei i915(-) r8169 mii prime_numbers i2c_hid [last unloaded: snd_hda_intel]
[ 641.646825] CPU: 1 PID: 8913 Comm: drv_module_relo Tainted: G U 4.10.0-CI-Trybot_609+ #1
[ 641.646836] Hardware name: TOSHIBA SATELLITE P50-C/06F4 , BIOS 1.20 10/08/2015
[ 641.646843] Call Trace:
[ 641.646857] dump_stack+0x67/0x92
[ 641.646869] __warn+0xc6/0xe0
[ 641.646880] warn_slowpath_fmt+0x4a/0x50
[ 641.646893] ? __this_cpu_preempt_check+0x13/0x20
[ 641.646904] ? trace_hardirqs_on_caller+0xe7/0x200
[ 641.646957] intel_runtime_pm_get_noresume+0x8b/0x90 [i915]
[ 641.647022] __i915_add_request+0x423/0x540 [i915]
[ 641.647080] i915_gem_switch_to_kernel_context+0x148/0x2b0 [i915]
[ 641.647145] i915_gem_suspend+0x2b/0x180 [i915]
[ 641.647189] i915_driver_unload+0x22/0x200 [i915]
[ 641.647200] ? __this_cpu_preempt_check+0x13/0x20
[ 641.647210] ? trace_hardirqs_on_caller+0xe7/0x200
[ 641.647220] ? trace_hardirqs_on+0xd/0x10
[ 641.647231] ? _raw_spin_unlock_irqrestore+0x3d/0x60
[ 641.647276] i915_pci_remove+0x14/0x20 [i915]
[ 641.647293] pci_device_remove+0x34/0xb0
[ 641.647307] device_release_driver_internal+0x158/0x210
[ 641.647321] driver_detach+0x3b/0x80
[ 641.647330] bus_remove_driver+0x53/0xd0
[ 641.647338] driver_unregister+0x27/0x50
[ 641.647348] pci_unregister_driver+0x25/0xa0
[ 641.647415] i915_exit+0x1a/0xb1a [i915]
[ 641.647429] SyS_delete_module+0x193/0x1e0
[ 641.647444] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 641.647453] RIP: 0033:0x7fc622bd2d37
[ 641.647463] RSP: 002b:
00007ffff8ffb5c8 EFLAGS:
00000246 ORIG_RAX:
00000000000000b0
[ 641.647475] RAX:
ffffffffffffffda RBX:
ffffffff81481ff3 RCX:
00007fc622bd2d37
[ 641.647480] RDX:
0000000000000001 RSI:
0000000000000800 RDI:
0000000000d49118
[ 641.647485] RBP:
ffffc90000997f88 R08:
0000000000000000 R09:
00007ffff8ffb5f0
[ 641.647491] R10:
0000000000d490a0 R11:
0000000000000246 R12:
0000000000000000
[ 641.647498] R13:
00007ffff8ffb7a0 R14:
0000000000000000 R15:
0000000000000000
[ 641.647510] ? __this_cpu_preempt_check+0x13/0x20
v2: Keep holding rpm until the end to cover i915_gem_sanitize() as well.
Fixes:
5ab57c702069 ("drm/i915: Flush logical context image out to memory upon suspend")
Fixes:
1c777c5d1dc ("drm/i915/hsw: Fix GPU hang during resume from S3-devices state")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170302083029.19576-1-chris@chris-wilson.co.uk
Reviewed-by: Imre Deak <imre.deak@intel.com>
Cc: <stable@vger.kernel.org> # v4.9+
Ander Conselvan de Oliveira [Wed, 1 Mar 2017 14:13:11 +0000 (16:13 +0200)]
drm/i915: Enable DDI IO power domains in the DP MST path
Commit
62b695662a24 ("drm/i915: Only enable DDI IO power domains after
enabling DPLL") changed how the DDI IO power domains get enabled, but
neglected the need to enable those domains when enabling a DP connector
with MST enabled, leading to
Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
Fixes:
62b695662a24 ("drm/i915: Only enable DDI IO power domains after enabling DPLL")
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301141318.3607-2-ander.conselvan.de.oliveira@intel.com
Chris Wilson [Wed, 1 Mar 2017 12:11:31 +0000 (12:11 +0000)]
drm/i915: Move w/a LRI debug message from context-init to driver load
The spam of every context initialisation saying the same thing is annoying
me! Move the information to the setup of the engine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301121131.11588-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Wed, 1 Mar 2017 15:41:28 +0000 (15:41 +0000)]
drm/i915: Prevent concurrent tiling/framebuffer modifications
Reintroduce a lock around tiling vs framebuffer creation to prevent
modification of the obj->tiling_and_stride whilst the framebuffer is
being created. Rather than use struct_mutex once again, use the
per-object lock - this will also be required in future to prevent
changing the tiling whilst submitting rendering.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes:
24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating the framebuffer")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301154128.2841-2-chris@chris-wilson.co.uk
Chris Wilson [Wed, 1 Mar 2017 15:41:27 +0000 (15:41 +0000)]
drm/i915: Fix all intel_framebuffer_init failures to take the error path
No more direct return -EINVAL as we have to unwind the
obj->framebuffer_references.
Fixes:
24dbf51a5517 ("drm/i915: struct_mutex is not required for allocating the framebuffer")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170301154128.2841-1-chris@chris-wilson.co.uk
Hans de Goede [Wed, 1 Mar 2017 13:15:06 +0000 (15:15 +0200)]
drm/i915/dsi: Skip delays for v3 VBTs in vid-mode
For v3 VBTs in vid-mode the delays are part of the VBT sequences, so
we should not also delay ourselves otherwise we get double delays.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-11-git-send-email-jani.nikula@intel.com
Hans de Goede [Wed, 1 Mar 2017 13:15:05 +0000 (15:15 +0200)]
drm/i915/dsi: Call MIPI_SEQ_TEAR_ON and DISPLAY_ON for cmd-mode (untested)
According to the spec we should call MIPI_SEQ_TEAR_ON and DISPLAY_ON
on enable for cmd-mode, just like we already call their counterparts
on disable. Note: untested, my panel is a vid-mode panel.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-10-git-send-email-jani.nikula@intel.com
Hans de Goede [Wed, 1 Mar 2017 13:15:04 +0000 (15:15 +0200)]
drm/i915/dsi: Execute MIPI_SEQ_TEAR_OFF from intel_dsi_post_disable
For v3+ VBTs we should call MIPI_SEQ_TEAR_OFF before MIPI_SEQ_DISPLAY_OFF,
v2 VBTs do not have MIPI_SEQ_TEAR_OFF so there this is a nop.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-9-git-send-email-jani.nikula@intel.com
Hans de Goede [Wed, 1 Mar 2017 13:15:03 +0000 (15:15 +0200)]
drm/i915/dsi: Document always using v3 SHUTDOWN / MIPI_SEQ_DISPLAY_OFF order
According to the spec for v2 VBTs we should call MIPI_SEQ_DISPLAY_OFF
before sending SHUTDOWN, where as for v3 VBTs we should send SHUTDOWN
first.
Since the v2 order has known issues, we use the v3 order everywhere,
add a comment documenting this.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-8-git-send-email-jani.nikula@intel.com
Hans de Goede [Wed, 1 Mar 2017 13:15:02 +0000 (15:15 +0200)]
drm/i915/dsi: Group MIPI_SEQ_BACKLIGHT_ON/OFF with panel_[en|dis]able_backlight
Execute the MIPI_SEQ_BACKLIGHT_ON/OFF VBT sequences at the same time as
we call intel_panel_enable_backlight() / intel_panel_disable_backlight().
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-7-git-send-email-jani.nikula@intel.com
Hans de Goede [Wed, 1 Mar 2017 13:15:01 +0000 (15:15 +0200)]
drm/i915/dsi: Execute MIPI_SEQ_DEASSERT_RESET before calling device_ready()
Execute MIPI_SEQ_DEASSERT_RESET before putting the device in ready
state (LP-11), this is the sequence in which things should be done
according to the spec.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-6-git-send-email-jani.nikula@intel.com
Hans de Goede [Wed, 1 Mar 2017 13:15:00 +0000 (15:15 +0200)]
drm/i915/dsi: Group DPOunit clock gate workaround with PLL enable
Move the DPOunit clock gate workaround to directly after the PLL enable.
The exact location of the workaround does not matter and there are 2
reasons to group it with the PLL enable:
1) This moves it out of the middle of the init sequence from the spec,
making it easier to follow the init sequence / compare it to the spec
2) It is grouped with the pll disable call in intel_dsi_post_disable,
so for consistency it should be grouped with the pll enable in
intel_dsi_pre_enable
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-5-git-send-email-jani.nikula@intel.com
Hans de Goede [Wed, 1 Mar 2017 13:14:59 +0000 (15:14 +0200)]
drm/i915/dsi: Move MIPI_SEQ_POWER_ON/OFF calls together with pmic gpio calls
Now that we are no longer bound to the drm_panel_ callbacks, call
MIPI_SEQ_POWER_ON/OFF at the proper place.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-4-git-send-email-jani.nikula@intel.com
Hans de Goede [Wed, 1 Mar 2017 13:14:58 +0000 (15:14 +0200)]
drm/i915/dsi: Drop bogus MIPI_SEQ_ASSERT_RESET before POWER_ON
intel_dsi_post_disable(), which does the MIPI_SEQ_ASSERT_RESET,
will always be called at some point before intel_dsi_pre_enable()
making the MIPI_SEQ_ASSERT_RESET in intel_dsi_pre_enable() redundant.
In addition, calling MIPI_SEQ_ASSERT_RESET in the enable path goes
against the VBT spec.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-3-git-send-email-jani.nikula@intel.com
Hans de Goede [Wed, 1 Mar 2017 13:14:57 +0000 (15:14 +0200)]
drm/i915/dsi: Document the panel enable / disable sequences from the spec
Document the DSI panel enable / disable sequences from the spec,
for easy comparison between the code and the spec.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488374106-4949-2-git-send-email-jani.nikula@intel.com
Jani Nikula [Tue, 28 Feb 2017 11:11:43 +0000 (13:11 +0200)]
drm/i915: use BUILD_BUG_ON to ensure platform name has been set up
Leave the runtime check in place in case the platform variable itself
comes from bogus sources.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488280303-9323-1-git-send-email-jani.nikula@intel.com
Imre Deak [Fri, 24 Feb 2017 14:32:10 +0000 (16:32 +0200)]
drm/i915/gen9: Increase PCODE request timeout to 50ms
After
commit
2c7d0602c815277f7cb7c932b091288710d8aba7
Author: Imre Deak <imre.deak@intel.com>
Date: Mon Dec 5 18:27:37 2016 +0200
drm/i915/gen9: Fix PCODE polling during CDCLK change notification
there is still one report of the CDCLK-change request timing out on a
KBL machine, see the Reference link. On that machine the maximum time
the request took to succeed was 34ms, so increase the timeout to 50ms.
v2:
- Change timeout from 100 to 50 ms to maintain the current 50 ms limit
for atomic waits in the driver. (Chris, Tvrtko)
Reference: https://bugs.freedesktop.org/show_bug.cgi?id=99345
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1487946730-17162-1-git-send-email-imre.deak@intel.com
Deepak M [Wed, 1 Mar 2017 07:21:33 +0000 (12:51 +0530)]
drm/i915/glk: Add MIPIIO Enable/disable sequence
v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Jani's Review comment for aligning code to platforms and added
wrapper functions.
v4: Corrected enable/disable seuqence as per BSPEC
v5: Corrected waiting twice for same bit (Review comments: Jani)
v6: Rebased to Han's patches(dsi restructuring code)
Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1488352893-29916-2-git-send-email-madhav.chauhan@intel.com
Chris Wilson [Tue, 28 Feb 2017 14:55:19 +0000 (14:55 +0000)]
drm/i915: Tighten mmio arrays for MIPI_PORT
drivers/gpu/drm/i915/intel_dsi.c: In function ‘intel_dsi_prepare’:
drivers/gpu/drm/i915/intel_dsi.c:1308:1: error: the frame size of 2488 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
which is caused by the compiling expanding every _MIPI_PORT into an
on-stack array of u32[3] at every callsite. Not sure why only one
machine/compiler appears susceptible, but with a minor tweak to _MIPI_PORT
we can defer the error until later.
This is a partial revert of commit
ce64645d86ac ("drm/i915: use variadic
macros and arrays to choose port/pipe based registers") for a particular
bad offender.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228145519.18012-1-chris@chris-wilson.co.uk
Acked-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Tue, 28 Feb 2017 11:28:03 +0000 (11:28 +0000)]
drm/i915/guc: Reorder __i915_guc_submit to reduce spinlock holdtime
A couple of operations, the flushes and the tracepoint, do not require
serialisation by client->wq_lock, so move them before we take it.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228112803.11646-3-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Tue, 28 Feb 2017 11:28:02 +0000 (11:28 +0000)]
drm/i915/guc: Make wq_lock irq-safe
Following the use of dma_fence_signal() from within our interrupt
handler, we need to make guc->wq_lock also irq-safe. This was done
previously as part of the guc scheduler patch (which also started
mixing our fences with the interrupt handler), but is now required to
fix the current guc submission backend.
v4: Document that __i915_guc_submit is always under an irq disabled
section
v5: Move wq_rsvd adjustment to its own function
Fixes:
67b807a89230 ("drm/i915: Delay disabling the user interrupt for breadcrumbs")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228112803.11646-2-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Hans de Goede [Tue, 28 Feb 2017 09:26:21 +0000 (11:26 +0200)]
drm/i915/dsi: VLV/CHT Only wait for LP00 on MIPI PORT A
On some devices only MIPI PORT C is used, in this case checking the
MIPI PORT A CTRL AFE_LATCHOUT bit (there is no such bit for PORT C
on VLV/CHT) will result in false positive "DSI LP not going Low" errors
as this checks the PORT A clk status.
In case both ports are used we have already checked the AFE_LATCHOUT
bit when going through the for_each_dsi_port() loop for PORT A and
checking the same bit again for PORT C is a no-op.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97061
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/242e4438bf29ebffc66eaa182f22b9d60d304bc2.1488273823.git.jani.nikula@intel.com
Hans de Goede [Tue, 28 Feb 2017 09:26:20 +0000 (11:26 +0200)]
drm/i915/dsi: Make intel_dsi_enable/disable directly exec VBT sequences
The drm_panel_enable/disable and drm_panel_prepare/unprepare calls are
not fine grained enough to abstract all the different steps we need to
take (and VBT sequences we need to exec) properly. So simply remove the
panel _enable/disable and prepare/unprepare callbacks and instead
export intel_dsi_exec_vbt_sequence() from intel_dsi_panel_vbt.c
and call that from intel_dsi_enable/disable().
No functional changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/b4ca5185d4788d92df2ed60837a24b8962a8e8ba.1488273823.git.jani.nikula@intel.com
Hans de Goede [Tue, 28 Feb 2017 09:26:19 +0000 (11:26 +0200)]
drm/i915/dsi: Move intel_dsi_clear_device_ready()
Move the intel_dsi_clear_device_ready() function to higher up in
intel_dsi.c this pairs it with intel_dsi_device_ready(); and pairs
intel_dsi_*enable* with intel_dsi_*disable without
intel_dsi_clear_device_ready() sitting in the middle of them.
This commit purely moves code around, it does not make any
changes what-so-ever.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/f971d18ea6d350890447860aeb541dba072a6e47.1488273823.git.jani.nikula@intel.com
Hans de Goede [Tue, 28 Feb 2017 09:26:18 +0000 (11:26 +0200)]
drm/i915/dsi: Add intel_dsi_unprepare() helper
The enable path has an intel_dsi_prepare() helper which prepares various
registers for the mode-set. Move the code undoing this to a new
intel_dsi_unprepare() helper function for better symmetry between the
enable and disable paths. No functional changes.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/cc0baaf04ea74a20031b4b5bb128591dcfa78406.1488273823.git.jani.nikula@intel.com
Hans de Goede [Tue, 28 Feb 2017 09:26:17 +0000 (11:26 +0200)]
drm/i915/dsi: Merge intel_dsi_disable/enable into their respective callers
intel_dsi_disable/enable only have one caller, merge them into their
respective callers.
Change msleep(2) into usleep_range(2000, 5000) to make checkpatch happy,
otherwise no functional changes.
The main advantage of this change is that it makes it easier to
follow all the steps of the panel enable / disable sequence when
reading the code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/d7249612e6d2e9639ecd1d8d106ca37d5794f2a4.1488273823.git.jani.nikula@intel.com
Hans de Goede [Tue, 28 Feb 2017 09:26:16 +0000 (11:26 +0200)]
drm/i915/dsi: Move calling of wait_for_dsi_fifo_empty to mipi_exec_send_packet
Instead of calling wait_for_dsi_fifo_empty on all dsi ports after calling
a drm_panel_foo helper which calls VBT sequences, move it to the VBT
mipi_exec_send_packet helper, which is the one VBT instruction which
actually puts data in the fifo.
This results in a nice cleanup making it clearer what all the steps on
intel_dsi_enable / disable are and this also makes the VBT code properly
wait till a command has actually been send before executing the next
steps (typically a delay) in the VBT sequence.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/289977b5699e252fea5c211d1d1645f9e79cca79.1488273823.git.jani.nikula@intel.com
Chris Wilson [Tue, 28 Feb 2017 08:50:18 +0000 (08:50 +0000)]
drm/i915: Consolidate reporting of "missed breadcrumbs"
Move the setting of gpu_error->missed_irq_ring bit to a common function
so that we can get the debug logging for either path.
v2: Add %pF caller
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170228085018.3225-1-chris@chris-wilson.co.uk
Madhav Chauhan [Fri, 17 Feb 2017 12:43:35 +0000 (18:13 +0530)]
drm/i915/glk: Validate only DSI PORT A PLL divider
As per BSPEC, GLK supports MIPI DSI 8X clk only on PORT A.
Therefore only for PORT A PLL divider value should be validated.
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-8-git-send-email-madhav.chauhan@intel.com
Deepak M [Fri, 17 Feb 2017 12:43:34 +0000 (18:13 +0530)]
drm/i915/glk: Program txesc clock divider for GLK
v2: Addressed Jani's Review comments(renamed bit field macros)
Txesc clock divider is calculated and programmed
for geminilake platform.
Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-7-git-send-email-madhav.chauhan@intel.com
Deepak M [Fri, 17 Feb 2017 12:43:33 +0000 (18:13 +0530)]
drm/i915i/glk: Program MIPI_CLOCK_CTRL only for BXT
Register MIPI_CLOCK_CTRL is applicable only
for BXT platform. Future platform have other
registers to program the escape clock dividers.
Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-6-git-send-email-madhav.chauhan@intel.com
Deepak M [Fri, 17 Feb 2017 12:43:32 +0000 (18:13 +0530)]
drm/i915/glk: Add DSI PLL divider range for glk
PLL divider range for GLK is different than that of
BXT, hence adding the GLK range check in this patch.
v2: Code restructure using min and max ratio variables (Ander)
v3: Code changes to avoid "maybe-uninitialized" warning (Jani)
Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-5-git-send-email-madhav.chauhan@intel.com
Deepak M [Fri, 17 Feb 2017 12:43:30 +0000 (18:13 +0530)]
drm/i915/glk: Program new MIPI DSI PHY registers for GLK
Program the clk lane and tlpx time count registers
to configure DSI PHY.
v2: Addressed Jani's Review comments(renamed bit field macros)
v3: Program clk lane timing reg same as dphy param reg.
v4: Removed "line over 80 character" warning
Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-3-git-send-email-madhav.chauhan@intel.com
Deepak M [Fri, 17 Feb 2017 12:43:29 +0000 (18:13 +0530)]
drm/i915/glk: Program dphy param reg for GLK
For GEMINILAKE, dphy param reg values are programmed in terms
of HS byte clock count while for older platforms in terms of
HS ddr clk count.
v2: Added comments to clarify ddr clock count calculation
v3: Use multiplier variable instead of IS_GEMINILAKE()
check everywhere (Jani)
Signed-off-by: Deepak M <m.deepak@intel.com>
Signed-off-by: Madhav Chauhan <madhav.chauhan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487335415-14766-2-git-send-email-madhav.chauhan@intel.com
Chris Wilson [Mon, 27 Feb 2017 20:58:50 +0000 (20:58 +0000)]
drm/i915: Delay disabling the user interrupt for breadcrumbs
A significant cost in setting up a wait is the overhead of enabling the
interrupt. As we disable the interrupt whenever the queue of waiters is
empty, if we are frequently waiting on alternating batches, we end up
re-enabling the interrupt on a frequent basis. We do want to disable the
interrupt during normal operations as under high load it may add several
thousand interrupts/s - we have been known in the past to occupy whole
cores with our interrupt handler after accidentally leaving user
interrupts enabled. As a compromise, leave the interrupt enabled until
the next IRQ, or the system is idle. This gives a small window for a
waiter to keep the interrupt active and not be delayed by having to
re-enable the interrupt.
v2: Restore hangcheck/missed-irq detection for continuations
v3: Be more careful restoring the hangcheck timer after reset
v4: Be more careful restoring the fake irq after reset (if required!)
v5: Redo changes to intel_engine_wakeup()
v6: Factor out __intel_engine_wakeup()
v7: Improve commentary for declaring a missed wakeup
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-4-chris@chris-wilson.co.uk
Chris Wilson [Mon, 27 Feb 2017 20:58:49 +0000 (20:58 +0000)]
drm/i915: Defer enabling hangcheck to the first fake breadcrumb interrupt
By deferring hangcheck to the fake breadcrumb interrupt, we can simply
the enabling procedure slightly - as by enabling the fake, we then
enable the hangcheck. By always enabling the hangcheck from each fake
interrupt (it will be a no-op for an already queued hangcheck), it will
make restoring the breadcrumbs after a reset simpler in the next patch.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-3-chris@chris-wilson.co.uk
Chris Wilson [Mon, 27 Feb 2017 20:58:48 +0000 (20:58 +0000)]
drm/i915: Signal first fence from irq handler if complete
As execlists and other non-semaphore multi-engine devices coordinate
between engines using interrupts, we can shave off a few 10s of
microsecond of scheduling latency by doing the fence signaling from the
interrupt as opposed to a RT kthread. (Realistically the delay adds
about 1% to an individual cross-engine workload.) We only signal the
first fence in order to limit the amount of work we move into the
interrupt handler. We also have to remember that our breadcrumbs may be
unordered with respect to the interrupt and so we still require the
waiter process to perform some heavyweight coherency fixups, as well as
traversing the tree of waiters.
v2: No need for early exit in irq handler - it breaks the flow between
patches and prevents the tracepoint
v3: Restore rcu hold across irq signaling of request
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 27 Feb 2017 20:58:47 +0000 (20:58 +0000)]
drm/i915: Report both waiters and success from intel_engine_wakeup()
The two users of the return value from intel_engine_wakeup() are
expecting different results. In the breadcrumbs hangcheck, we are using
it to determine whether wake_up_process() detected the waiter was
currently running (and if so we presume that it hasn't yet missed the
interrupt). However, in the fake_irq path, we are using the return value
as a check as to whether there are any waiters, and so we may
incorrectly stop the fake-irq if that waiter was currently running.
To handle the two different needs, return both bits of information! We
uninline it from the irq path in preparation for the next patch which
makes the irq hotpath special and relegates intel_engine_wakeup() to the
slow fixup paths.
v2: s/ret/result/
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227205850.2828-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 23 Feb 2017 14:10:20 +0000 (14:10 +0000)]
drm/i915: Distinguish between timeout and error in sideband transactions
After initiating a sideband transaction, we only want to wait for the
transaction to become idle. If, as we are, we wait for both the busy
and error flag to clear, if an error is raised we just spin until the
timeout. Once the hw is idle, we can then check to see if the hw flagged
an error, and report it distinctly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223141020.13250-1-chris@chris-wilson.co.uk
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Chris Wilson [Mon, 27 Feb 2017 13:59:13 +0000 (13:59 +0000)]
drm/i915: Reduce context alignment
No hardware was ever shipped that needed more than 4096 byte alignment
and future hardware will not use this legacy path. So reduce the
alignment to make it easier and quicker to launch workloads.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227135913.8056-3-chris@chris-wilson.co.uk
Chris Wilson [Mon, 27 Feb 2017 13:59:12 +0000 (13:59 +0000)]
drm/i915: Remove redundant TLB invalidate on switching ppgtt
We are required to reload the TLBs around ppgtt switches. However, we
already do an unconditional TLB invalidate before every batch and a flush
afterwards, so this condition is already satisfied without extra flushes
around the LRI instructions.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227135913.8056-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 27 Feb 2017 13:59:11 +0000 (13:59 +0000)]
drm/i915: Remove redundant TLB invalidate on switching contexts
We are required to reload the TLBs around context switches
(MI_SET_CONTEXT specifically) and the recommendation is do that before
the MI_SET_CONTEXT so that it is serialised with the switch and not
forgotten:
[DevSNB] If Flush TLB invalidation Mode is enabled it’s the driver’s
responsibility to invalidate the TLBs at least once after the previous
context switch after any GTT mappings changed (including new GTT entries).
This can be done by a pipeline PIPE_CONTROL with TLB inv bit set
immediately before MI_SET_CONTEXT.
However, we already do an unconditional TLB invalidate before every
batch so this condition is satifisfied.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227135913.8056-1-chris@chris-wilson.co.uk
Mika Kuoppala [Wed, 15 Feb 2017 13:52:59 +0000 (15:52 +0200)]
drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3
Certain Baytrails, namely the 4 cpu core variants, have been
plaqued by spurious system hangs, mostly occurring with light loads.
Multiple bisects by various people point to a commit which changes the
reclocking strategy for Baytrail to follow its bigger brethen:
commit
8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail")
There is also a review comment attached to this commit from Deepak S
on avoiding punit access on Cherryview and thus it was excluded on
common reclocking path. By taking the same approach and omitting
the punit access by not tweaking the thresholds when the hardware
has been asked to move into different frequency, considerable gains
in stability have been observed.
With J1900 box, light render/video load would end up in system hang
in usually less than 12 hours. With this patch applied, the cumulative
uptime has now been 34 days without issues. To provoke system hang,
light loads on both render and bsd engines in parallel have been used:
glxgears >/dev/null 2>/dev/null &
mpv --vo=vaapi --hwdec=vaapi --loop=inf vid.mp4
So far, author has not witnessed system hang with above load
and this patch applied. Reports from the tenacious people at
kernel bugzilla are also promising.
Considering that the punit access frequency with this patch is
considerably less, there is a possibility that this will push
the, still unknown, root cause past the triggering point on most loads.
But as we now can reliably reproduce the hang independently,
we can reduce the pain that users are having and use a
static thresholds until a root cause is found.
v3: don't break debugfs and simplification (Chris Wilson)
References: https://bugzilla.kernel.org/show_bug.cgi?id=109051
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: fritsch@xbmc.org
Cc: miku@iki.fi
Cc: Ezequiel Garcia <ezequiel@vanguardiasur.com.ar>
CC: Michal Feix <michal@feix.cz>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Deepak S <deepak.s@linux.intel.com>
Cc: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.2+
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487166779-26945-1-git-send-email-mika.kuoppala@intel.com
Chris Wilson [Mon, 27 Feb 2017 12:26:54 +0000 (12:26 +0000)]
drm/i915: Remove the vma from the drm_mm if binding fails
As we track whether a vma has been inserted into the drm_mm using the
vma->flags, if we fail to bind the vma into the GTT we do not update
those bits and will attempt to reinsert the vma into the drm_mm on
future passes. To prevent that, we want to unwind i915_vma_insert() if
we fail in our attempt to bind.
Fixes:
59bfa1248e22 ("drm/i915: Start passing around i915_vma from execbuffer")
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: <stable@vger.kernel.org> # v4.9+
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227122654.27651-3-chris@chris-wilson.co.uk
Chris Wilson [Mon, 27 Feb 2017 12:26:53 +0000 (12:26 +0000)]
drm/i915: Unwind vma->pages allocation upon failure
If we fail to allocate the ppgtt range after allocating the pages for
the vma, we should unwind the local allocation before reporting back the
failure.
Fixes:
ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227122654.27651-2-chris@chris-wilson.co.uk
Chris Wilson [Mon, 27 Feb 2017 12:26:52 +0000 (12:26 +0000)]
drm/i915: Only unwind the local pgtable layer if empty
Only if we allocated the layer and the lower level failed should we
remove this layer when unwinding. Otherwise we ignore the overlapping
entries by overwriting the old layer with scratch.
Fixes:
c5d092a4293f ("drm/i915: Remove bitmap tracking for used-pml4")
Fixes:
e2b763caa6eb ("drm/i915: Remove bitmap tracking for used-pdpes")
Reported-by: Matthew Auld <matthew.william.auld@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99947
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Tested-by: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227122654.27651-1-chris@chris-wilson.co.uk
Kelvin Gardiner [Fri, 24 Feb 2017 19:15:24 +0000 (11:15 -0800)]
drm/i915/bdw: Do not write the replay bit of the ring mode register
The replay bit of the ring mode register is not a valid bit for Gen8+.
Do not write to this bit.
Signed-off-by: Kelvin Gardiner <kelvin.gardiner@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
[Joonas: Fixed commit message line to be under 72 chars]
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487963724-4824-1-git-send-email-kelvin.gardiner@intel.com
Michał Winiarski [Mon, 27 Feb 2017 11:22:56 +0000 (12:22 +0100)]
drm/i915/skl: Add missing SKL ID
Used by production device:
Intel(R) Iris(TM) Graphics P555
Cc: <stable@vger.kernel.org>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170227112256.20060-1-michal.winiarski@intel.com
Daniel Vetter [Mon, 27 Feb 2017 08:30:11 +0000 (09:30 +0100)]
Merge airlied/drm-next into drm-misc-next
Backmerge the main pull request to sync up with all the newly landed
drivers. Otherwise we'll have chaos even before 4.12 started in
earnest.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Ander Conselvan de Oliveira [Fri, 24 Feb 2017 14:19:59 +0000 (16:19 +0200)]
drm/i915: Only enable DDI IO power domains after enabling DPLL
According to bspec, the DDI IO power domains should be enabled after
enabling the DPLL and mapping it to the DDI. The current order doesn't
seem to create problems with Skylake and Kabylake, but causes enable
timeouts in Geminilake.
v2: Rebase.
- Take power domain references before sanitizing encoders. (Imre)
- Add comment to get_encoder_power_domains() defition. (Ander)
v3: Don't put the domain if called with HSW/BDW's analog encoder. (CI)
v4: Put IO power domain before unmapping DPLL. (Imre)
- Change return type of intel_ddi_get_power_domains() to u64. (Imre)
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> # v1
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224141959.5955-1-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Wed, 22 Feb 2017 06:34:30 +0000 (08:34 +0200)]
drm/i915/glk: Don't enable DDI IO power domains during init
In Geminilake, the DDI IO power domains can't be enabled before a DPLL
is running and mapped to the appropriate DDI. At least on Geminilake,
attempting to enable those during init will lead to a timeout.
The failure to enable the power domain also causes issues with the state
verifier during resume from suspend. After all the init power domains
are enabled, the call to intel_power_domains_sync_hw() from the resume
path will cause the hw_enabled field on the respective power wells to be
false while the usage count remains above zero. Further attempts to
enable the power domain caused by a modeset will simply update the usage
count without doing anything else. When the state verifier attempts to
read the state of a DDI encoder, intel_display_power_get_if_enabled()
returns false, leading to the following WARN:
WARNING: CPU: 3 PID: 1743 at drivers/gpu/drm/i915/intel_display.c:7001 verify_connector_state.isra.80+0x26c/0x2b0 [i915]
attached crtc is active, but connector isn't
Modules linked in: i915(E) tun ip6t_rpfilter ip6t_REJECT nf_reject_ipv6 xt_conntrack ebtable_broute bridge stp llc ebtable_nat ip6table_mangle ip6table_security ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_raw iptable_mangle iptable_security iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_raw ebtable_filter ebtables ip6table_filter ip6_tables x86_pkg_temp_thermal coretemp kvm_intel kvm i2c_algo_bit drm_kms_helper irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel drm shpchp tpm_tis tpm_tis_core tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc crc32c_intel serio_raw [last unloaded: i915]
CPU: 3 PID: 1743 Comm: kworker/u8:22 Tainted: G W E 4.10.0-rc3ander+ #300
Hardware name: Intel Corp. Geminilake/GLK RVP1 DDR4 (05), BIOS GELKRVPA.X64.0023.B40.
1611302145 11/30/2016
Workqueue: events_unbound async_run_entry_fn
Call Trace:
dump_stack+0x86/0xc3
__warn+0xcb/0xf0
warn_slowpath_fmt+0x5f/0x80
verify_connector_state.isra.80+0x26c/0x2b0 [i915]
intel_atomic_commit_tail+0x520/0x1000 [i915]
? remove_wait_queue+0x70/0x70
intel_atomic_commit+0x3f8/0x520 [i915]
? intel_runtime_pm_put+0x6e/0xa0 [i915]
drm_atomic_commit+0x4b/0x50 [drm]
__intel_display_resume+0x72/0xc0 [i915]
intel_display_resume+0x107/0x150 [i915]
i915_drm_resume+0xe0/0x180 [i915]
i915_pm_restore+0x1e/0x30 [i915]
i915_pm_resume+0xe/0x10 [i915]
pci_pm_resume+0x64/0xa0
dpm_run_callback+0xa1/0x2a0
? pci_pm_thaw+0x90/0x90
device_resume+0xe3/0x200
async_resume+0x1d/0x50
async_run_entry_fn+0x39/0x170
process_one_work+0x212/0x670
? process_one_work+0x197/0x670
worker_thread+0x4e/0x490
kthread+0x101/0x140
? process_one_work+0x670/0x670
? kthread_create_on_node+0x60/0x60
ret_from_fork+0x2a/0x40
Cc: David Weinehall <david.weinehall@linux.intel.com>
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-6-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Wed, 22 Feb 2017 06:34:29 +0000 (08:34 +0200)]
drm/i915/glk: Implement WaDDIIOTimeout
Implement WaDDIIOTimeout to avoid a timeout when enabling the DDI IO
power domains.
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-5-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Fri, 24 Feb 2017 14:18:45 +0000 (16:18 +0200)]
drm/i915: Check encoder type in enc_to_dig_port()
Don't allow conversion from arbitraty encoder types to a digital port.
Calling enc_to_dig_port() with the wrong encoder may seem far fetched,
but certain paths of the ddi code may be called with hasell's analog
encoder and the conversion is wrong for DP mst encoders too, so safe
guard against it.
v2: Warn if encoder type is unknown and device is not DDI. (Imre)
v3: Remove stray hunk from rebase error. (Ander)
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224141845.5836-1-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Wed, 22 Feb 2017 06:34:27 +0000 (08:34 +0200)]
drm/i915: Store encoder power domain in struct intel_encoder
The encoder power domain is obviously tied to the encoder, so store it
in struct intel_encoder. This avoids some indirection.
v2: Rebase
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-3-ander.conselvan.de.oliveira@intel.com
Ander Conselvan de Oliveira [Wed, 22 Feb 2017 06:34:26 +0000 (08:34 +0200)]
drm/i915: Store aux power domain in intel_dp
The aux power domain only makes sense in the DP code. Storing it in
struct intel_dp avoids some indirection.
v2: Rebase
Signed-off-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170222063431.10060-2-ander.conselvan.de.oliveira@intel.com
Chris Wilson [Sat, 25 Feb 2017 18:11:22 +0000 (18:11 +0000)]
drm/i915: Advance start address on crossing PML (48b ppgtt) boundary
When advancing onto the next 4th level page table entry, we need to
reset our indices to 0. Currently we restart from the original address
which means we start with an offset into the next PML table.
Fixes:
894ccebee2b0 ("drm/i915: Micro-optimise gen8_ppgtt_insert_entries()")
Reported-by: Matthew Auld <matthew.william.auld@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99948
Testcase: igt/drv_selftest/live_gtt
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Tested-by: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170225181122.4788-4-chris@chris-wilson.co.uk
Chris Wilson [Sat, 25 Feb 2017 18:11:21 +0000 (18:11 +0000)]
drm/i915: Sanity check the vma->node prior to binding into the GTT
We rely on the VMA being allocated inside the drm_mm and for its allotted
node being large enough to accommodate all the vma->pages.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170225181122.4788-3-chris@chris-wilson.co.uk
Chris Wilson [Sat, 25 Feb 2017 18:11:20 +0000 (18:11 +0000)]
drm/i915: Assert we do not overflow 4lvl page directories
Before looking up the page directory entry, check we are still within
bounds.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170225181122.4788-2-chris@chris-wilson.co.uk
Chris Wilson [Sat, 25 Feb 2017 18:11:19 +0000 (18:11 +0000)]
drm/i915: Assert all sg are initialised in fake_dma_object for selftests
Double check that we allocated the right amount of scatterlist elements
for our obj->size.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170225181122.4788-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 24 Feb 2017 19:33:15 +0000 (19:33 +0000)]
drm/i915: Timeout lowlevel_hole GTT selftest early
Check for a timeout in the lowlevel_hole GTT before we allocate state
for that pass, as our cleanup phase stops on the iteration before the
timeout.
References: https://bugs.freedesktop.org/show_bug.cgi?id=99947
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224193315.21072-1-chris@chris-wilson.co.uk
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Kenneth Graunke [Wed, 15 Feb 2017 09:34:46 +0000 (01:34 -0800)]
drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.
This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0
(indicating the optional feature is not supported), and makes execbuf
always return -EINVAL if the flags are used.
Apparently, no userspace ever shipped which used this optional feature:
I checked the git history of Mesa, xf86-video-intel, libva, and Beignet,
and there were zero commits showing a use of these flags. Kernel commit
72bfa19c8deb4 apparently introduced the feature prematurely. According
to Chris, the intention was to use this in cairo-drm, but "the use was
broken for gen6", so I don't think it ever happened.
'relative_constants_mode' has always been tracked per-device, but this
has actually been wrong ever since hardware contexts were introduced, as
the INSTPM register is saved (and automatically restored) as part of the
render ring context. The software per-device value could therefore get
out of sync with the hardware per-context value. This meant that using
them is actually unsafe: a client which tried to use them could damage
the state of other clients, causing the GPU to interpret their BO
offsets as absolute pointers, leading to bogus memory reads.
These flags were also never ported to execlist mode, making them no-ops
on Gen9+ (which requires execlists), and Gen8 in the default mode.
On Gen8+, userspace can write these registers directly, achieving the
same effect. On Gen6-7.5, it likely makes sense to extend the command
parser to support them. I don't think anyone wants this on Gen4-5.
Based on a patch by Dave Gordon.
v3: Return -ENODEV for the getparam, as this is what we do for other
obsolete features. Suggested by Chris Wilson.
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=92448
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170215093446.21291-1-kenneth@whitecape.org
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Imre Deak [Wed, 22 Feb 2017 15:10:52 +0000 (17:10 +0200)]
drm/i915/lspcon: Switch back to PCON mode after output replug
At least a ParadTech PS175 LSPCON chip/firmware uses long instead of
short pulses to signal output unplug/plug events. This is contrary to
how branch devices normally work which use short HPD signaling. This
chip will also switch to LS mode after an unplug event, which could be
the consequence of the long HPD signaling semantics and an effort to
save power automatically. Because of this we'll fail to do AUX and
detect the output after a replug event.
To fix this make sure we are in PCON mode during connector detection.
v2:
- Switch the mode in the proper spot.
Cc: raptorteak@gmail.com
Cc: Shashank Sharma <shashank.sharma@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98912
Reported-and-tested-by: raptorteak@gmail.com
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1487776252-6288-1-git-send-email-imre.deak@intel.com
Chris Wilson [Thu, 23 Feb 2017 14:50:31 +0000 (14:50 +0000)]
drm/i915/execlists: Detect an out-of-order context switch
We require that the request is completed before the context is switched
away.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223145031.26210-1-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Ville Syrjälä [Thu, 23 Feb 2017 17:49:01 +0000 (19:49 +0200)]
drm/i915: Introduce intel_ddi_dp_voltage_max()
Rather than sprinkling ideas of how big the DDI buf translation tables
are somewhere in intel_dp.c, let's concentrate it all in intel_ddi.c
where the actual tables are defined. To that end we introduce
intel_ddi_dp_voltage_max() which will actually look at the proper
translation table to determine what is the maximum voltage swing level
supported.
v2: Mask out the preemphasis bits from the return value of
intel_ddi_dp_voltage_max()
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223174901.26749-1-ville.syrjala@linux.intel.com
Ville Syrjälä [Thu, 23 Feb 2017 17:35:06 +0000 (19:35 +0200)]
drm/i915: Refactor translate_signal_level()
Convert the big switch statement in translate_signal_level() into a neat
table. The table also serves as documentation for the translation
tables. We'll also have other uses for this table later on.
v2: Remove superfluous space (David)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223173507.17600-2-ville.syrjala@linux.intel.com
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Ville Syrjälä [Thu, 23 Feb 2017 17:35:05 +0000 (19:35 +0200)]
drm/i915: Refactor code to select the DDI buf translation table
Split the code to select the correct translation table into DP,
eDP and FDI specific helpers. This reduces the clutter in
intel_prepare_dp_ddi_buffers(), and we'll have other uses for some
of these new helper functions later on.
v2: Fix typo in commit message (David)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223173507.17600-1-ville.syrjala@linux.intel.com
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Chris Wilson [Fri, 24 Feb 2017 11:43:06 +0000 (11:43 +0000)]
drm/i915/fbdev: Stop repeating tile configuration on stagnation
If we cease making progress in finding matching outputs for a tiled
configuration, stop looping over the remaining unconfigured outputs.
v2: Use conn_seq (instead of pass) to only apply tile configuration on
first pass.
Fixes:
b0ee9e7fa5b4 ("drm/fb: add support for tiled monitor configurations. (v2)")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Sean Paul <seanpaul@chromium.org>
Cc: <stable@vger.kernel.org> # v3.19+
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170224114306.4400-1-chris@chris-wilson.co.uk
Dave Airlie [Fri, 24 Feb 2017 02:11:21 +0000 (12:11 +1000)]
lib/Kconfig: make PRIME_NUMBERS not user selectable.
Linus doesn't like it user selectable, so kill it until
someone needs it for something else.
Signed-off-by: Dave Airlie <airlied@redhat.com>
Noralf Trønnes [Thu, 23 Feb 2017 13:29:57 +0000 (14:29 +0100)]
drm/tinydrm: helpers: Properly fix backlight dependency
BACKLIGHT_CLASS_DEVICE was selected in the last version of the
tinydrm patchset to fix the backlight dependency, but the
ifdef CONFIG_BACKLIGHT_CLASS_DEVICE was forgotten. Fix that.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Noralf Trønnes [Thu, 23 Feb 2017 13:29:56 +0000 (14:29 +0100)]
drm/tinydrm: mipi-dbi: Fix field width specifier warning
This warning is seen on 64-bit builds in functions:
'mipi_dbi_typec1_command':
'mipi_dbi_typec3_command_read':
'mipi_dbi_typec3_command':
>> drivers/gpu/drm/tinydrm/mipi-dbi.c:65:20: warning: field width specifier '*' expects argument of type 'int', but argument 5 has type 'size_t {aka long unsigned int}' [-Wformat=]
DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, len, data); \
^
include/drm/drmP.h:228:40: note: in definition of macro 'DRM_DEBUG_DRIVER'
drm_printk(KERN_DEBUG, DRM_UT_DRIVER, fmt, ##__VA_ARGS__)
^~~
>> drivers/gpu/drm/tinydrm/mipi-dbi.c:671:2: note: in expansion of macro 'MIPI_DBI_DEBUG_COMMAND'
MIPI_DBI_DEBUG_COMMAND(cmd, parameters, num);
^~~~~~~~~~~~~~~~~~~~~~
Fix by casting 'len' to int in the macro MIPI_DBI_DEBUG_COMMAND().
There is no chance of overflow.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Noralf Trønnes [Thu, 23 Feb 2017 13:29:55 +0000 (14:29 +0100)]
drm/tinydrm: mipi-dbi: Silence: ‘cmd’ may be used uninitialized
Fix this warning:
drivers/gpu/drm/tinydrm/mipi-dbi.c: In function ‘mipi_dbi_debugfs_command_write’:
drivers/gpu/drm/tinydrm/mipi-dbi.c:905:8: warning: ‘cmd’ may be used uninitialized in this function [-Wmaybe-uninitialized]
ret = mipi_dbi_command_buf(mipi, cmd, parameters, i);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cmd can't be used uninitialized, but to satisfy the compiler,
initialize it to zero.
Signed-off-by: Noralf Trønnes <noralf@tronnes.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Chris Wilson [Thu, 23 Feb 2017 12:20:37 +0000 (12:20 +0000)]
drm/i915: Suppress fbc suggestion to increase stolen if disabled
If the reserved region of memory has not been setup (most probably
because it has been limited by hardware or virtualisation), don't tell
the user to try and increase the amount of memory reserved for graphics.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223122037.16174-1-chris@chris-wilson.co.uk
eviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Dave Airlie [Thu, 23 Feb 2017 22:35:23 +0000 (08:35 +1000)]
Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux into drm-next
Some ttm/amd fixes.
* 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux:
drm/amd/powerplay: fix PSI feature on Polars12.
drm/amdgpu: refuse to reserve io mem for split VRAM buffers
drm/ttm: fix use-after-free races in vm fault handling
drm/amd/amdgpu: post card if there is real hw resetting performed
Dave Airlie [Thu, 23 Feb 2017 22:29:03 +0000 (08:29 +1000)]
Merge tag 'drm/panel/for-4.11-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/panel: Changes for v4.11-rc1
This set contains a couple of cleanups as well as support for a few more
simple panels.
* tag 'drm/panel/for-4.11-rc1' of git://anongit.freedesktop.org/tegra/linux:
drm/panel: simple: Specify bus width and flags for EDT displays
drm/panel: simple: Add Netron DY
E231732
of: Add vendor prefix for Netron DY
drm/panel: simple: Add support for Tianma TM070JDHG30
of: Add vendor prefix for Tianma Micro-electronics
drm/panel: simple: Add support BOE NV101WXMN51
dt-bindings: display: Add BOE NV101WXMN51 panel binding
drm/panel: Constify device node argument to of_drm_find_panel()
Dave Airlie [Thu, 23 Feb 2017 22:26:48 +0000 (08:26 +1000)]
Merge tag 'drm/tegra/for-4.11-rc1' of git://anongit.freedesktop.org/tegra/linux into drm-next
drm/tegra: Changes for v4.11-rc1
Just a single change that hooks up the Tegra DRM parent device to the
correct device tree node.
* tag 'drm/tegra/for-4.11-rc1' of git://anongit.freedesktop.org/tegra/linux:
gpu: host1x: Set OF node for new host1x devices
Chris Wilson [Thu, 23 Feb 2017 07:44:22 +0000 (07:44 +0000)]
drm/i915: Remove one level of indention from wait-for-execute
Now that the code is getting simpler, we can reduce the indentation when
waiting for the global_seqno.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-17-chris@chris-wilson.co.uk
Chris Wilson [Thu, 23 Feb 2017 07:44:21 +0000 (07:44 +0000)]
drm/i915: Immediately process a reset before starting waiting
As we handoff the GPU reset to the waiter, we need to check we don't
miss a wakeup if it has already been sent prior to us starting the wait.
v2: Tweak checking for reset to be clear to the need before sleeping
after changing the task state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-16-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Thu, 23 Feb 2017 07:44:20 +0000 (07:44 +0000)]
drm/i915: Refactor direct GPU reset from request waiters
Combine the common code for the pair of waiters into a single function.
v2: Rename reset_request to wait_request_check_and_reset
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-15-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Thu, 23 Feb 2017 07:44:19 +0000 (07:44 +0000)]
drm/i915: Replace reset_wait_queue with default_wake_function
If we change the wait_queue_t from using the autoremove_wake_function to
the default_wake_function, we no longer have to restore the wait_queue_t
entry on the wait_queue_head_t list after being woken up by it, as we
are unusual in sleeping multiple times on the same wait_queue_t.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-14-chris@chris-wilson.co.uk
Chris Wilson [Thu, 23 Feb 2017 07:44:18 +0000 (07:44 +0000)]
drm/i915: Exercise request cancellation using a mock selftest
Add a mock selftest to preempt a request and check that we cancel it,
requeue the request and then complete its execution.
v2: Error leaks no more.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-13-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Thu, 23 Feb 2017 07:44:17 +0000 (07:44 +0000)]
drm/i915: Remove the preempted request from the execution queue
After the request is cancelled, we then need to remove it from the
global execution timeline and return it to the context timeline, the
inverse of submit_request().
v2: Move manipulation of struct intel_wait to helpers
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-12-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Thu, 23 Feb 2017 07:44:16 +0000 (07:44 +0000)]
drm/i915: Allow a request to be cancelled
If we preempt a request and remove it from the execution queue, we need
to undo its global seqno and restart any waiters.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-11-chris@chris-wilson.co.uk
Chris Wilson [Thu, 23 Feb 2017 07:44:15 +0000 (07:44 +0000)]
drm/i915: Take a reference whilst processing the signaler request
The plan in the near-future is to allow requests to be removed from the
signaler. We can no longer then rely on holding a reference to the
request for the duration it is in the signaling tree, and instead must
obtain a reference to the request for the current operation using RCU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-10-chris@chris-wilson.co.uk
Chris Wilson [Thu, 23 Feb 2017 07:44:14 +0000 (07:44 +0000)]
drm/i915: Protect the request->global_seqno with the engine->timeline lock
A request is assigned a global seqno only when it is on the hardware
execution queue. The global seqno can be used to maintain a list of
requests on the same engine in retirement order, for example for
constructing a priority queue for waiting. Prior to its execution, or
if it is subsequently removed in the event of preemption, its global
seqno is zero. As both insertion and removal from the execution queue
may operate in IRQ context, it is not guarded by the usual struct_mutex
BKL. Instead those relying on the global seqno must be prepared for its
value to change between reads. Only when the request is complete can
the global seqno be stable (due to the memory barriers on submitting
the commands to the hardware to write the breadcrumb, if the HWS shows
that it has passed the global seqno and the global seqno is unchanged
after the read, it is indeed complete).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-9-chris@chris-wilson.co.uk
Chris Wilson [Thu, 23 Feb 2017 07:44:13 +0000 (07:44 +0000)]
drm/i915: Deconstruct execute fence
On reflection, we are only using the execute fence as a waitqueue on the
global_seqno and not using it for dependency tracking between fences
(unlike the submit and dma fences). By only treating it as a waitqueue,
we can then treat it similar to the other waitqueues during submit,
making the code simpler.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-8-chris@chris-wilson.co.uk
Chris Wilson [Thu, 23 Feb 2017 07:44:12 +0000 (07:44 +0000)]
drm/i915: Inline __i915_gem_request_wait_for_execute()
It had only one callsite and existed to keep the code clearer. Now
having shared the wait-on-error between phases and with plans to change
the wait-for-execute in the next few patches, remove the out of line
wait loop and move it into the main body of i915_wait_request.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170223074422.4125-7-chris@chris-wilson.co.uk
projects / GitHub / LineageOS / android_kernel_motorola_exynos9610.git / log