Puthikorn Voravootivat [Thu, 22 Jun 2017 19:03:39 +0000 (12:03 -0700)]
drm/i915: Add option to support dynamic backlight via DPCD
This patch adds option to enable dynamic backlight for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622190339.142671-4-puthik@chromium.org
Puthikorn Voravootivat [Thu, 22 Jun 2017 19:03:38 +0000 (12:03 -0700)]
drm/i915: Add heuristic to determine better way to adjust brightness
Add heuristic to decide that AUX or PWM pin should use for
backlight brightness adjustment and modify i915 param description
to have auto, force disable, and force enable.
The heuristic to determine that using AUX pin is better than using
PWM pin is that the panel support any of the feature list here.
- Regional backlight brightness adjustment
- Backlight PWM frequency set
- More than 8 bits resolution of brightness level
- Backlight enablement via AUX and not by BL_ENABLE pin
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622190339.142671-3-puthik@chromium.org
Puthikorn Voravootivat [Thu, 22 Jun 2017 19:03:37 +0000 (12:03 -0700)]
drm/i915: Set PWM divider to match desired frequency in vbt
Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to have
as many bits as possible for PWM duty cyle for granularity of
brightness adjustment while the frequency divisor is still
within 25% of the desired value.
Signed-off-by: Puthikorn Voravootivat <puthik@chromium.org>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622190339.142671-2-puthik@chromium.org
Ville Syrjälä [Wed, 21 Jun 2017 17:49:44 +0000 (20:49 +0300)]
drm/i915: Always use 9 bits of the LPC bridge device ID for PCH detection
Make the code less confusiong by always using the top 9 bits of the
LPC bridge device ID to detect the PCH type. We need to add a bit of
new code for WPT, and we need to adjust the KBP ID as well. All the
other pre-CNP IDs are fine as is.
The virtualization cases I think are fine. These P2X and P3X IDs
actually just look like the old PIIX4 and PIIX3 IDs to me. Not sure
why they're not called PIIX3/4 though. The qemu one has a comment
saying the full ID is 0x2918 which is fine with 9 bits.
v2: Keep the CNP ID as 0xa300 (DK)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621174944.23306-1-ville.syrjala@linux.intel.com
Ville Syrjälä [Tue, 20 Jun 2017 13:03:09 +0000 (16:03 +0300)]
drm/i915: Clean up some expressions
Write the '!(SNB||IVB)' checks in the CPT/PPT detections
as '!SNB && !IVB' to make it less messy looking, and clear out
some useless parens the from the virtualization PCH detection case.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620130310.13245-5-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 20 Jun 2017 13:03:08 +0000 (16:03 +0300)]
drm/i915: Document that PPT==CPT and WPT==LPT
For our purposes PPT is equivalent to CPT, and WPT is equivalent to
LPT. Document that fact.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620130310.13245-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 20 Jun 2017 13:03:07 +0000 (16:03 +0300)]
drm/i915: s/Couar/Cougar/
Fix a typo in the PCH type debug message.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620130310.13245-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Tue, 20 Jun 2017 13:03:06 +0000 (16:03 +0300)]
drm/i915: Use HAS_PCH_CPT() everywhere
We have a few cases comparing pch_type directly. Let's just replace
them with HAS_PCH_CPT() since CPT/PPT is what they're looking for.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620130310.13245-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Matthew Auld [Thu, 22 Jun 2017 09:58:36 +0000 (10:58 +0100)]
drm/i915: pass the vma to insert_entries
The vma already contains most of the information we need for insertion.
But also in preparation for supporting huge gtt pages, it would be
useful to know the details of the vma, such that we can we can easily
determine the page sizes we are allowed to use when inserting into the
48b PPGTT. This is especially true for 64K where we can't just
arbitrarily use it, since we require aligning/padding the vm space to
2M, which sometimes we can't enforce in the upper levels.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622095836.6800-1-matthew.auld@intel.com
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Thu, 22 Jun 2017 10:47:22 +0000 (11:47 +0100)]
drm/i915: Clear execbuf's vma backpointer upon release
commit
2889caa92321 ("drm/i915: Eliminate lots of iterations over the
execobjects array") jiggled around the error handling and replace a test
that we cleaned up properly after ourselves with an assertion. That
assertion failed because in the release function (moments after the
assertion) we were indeed forgetting to mark the vma as cleared. The
consequence was when testing an invalid relocation address, we would try
to release the vma twice (following the couple of attempts to verify the
address) and on the second release notice that the first release was
incomplete.
Testcase: igt/gem_reloc_overflow/invalid-address
Fixes:
2889caa92321 ("drm/i915: Eliminate lots of iterations over the execobjects array")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170622104722.2583-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Wed, 21 Jun 2017 12:48:04 +0000 (13:48 +0100)]
drm/i915: Cancel pending execlist tasklet upon wedging
Highly unlikely, but if the stop_machine() did suspend the tasklet, we
want to make sure that when it wakes it finds there is nothing to do.
Otherwise, it will loudly complain that the ELSP port tracking no longer
matches the hardware, and we will be mightly confused.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621124804.4529-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Sat, 17 Jun 2017 11:57:44 +0000 (12:57 +0100)]
drm/i915: Hold struct_mutex for per-file stats in debugfs/i915_gem_object
As we walk the obj->vma_list in per_file_stats(), we need to hold
struct_mutex to prevent alteration of that list.
Fixes:
1d2ac403ae3b ("drm: Protect dev->filelist with its own mutex")
Fixes:
c84455b4bacc ("drm/i915: Move debug only per-request pid tracking from request to ctx")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101460
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170617115744.4452-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Tue, 20 Jun 2017 12:43:21 +0000 (13:43 +0100)]
drm/i915: Assert the vma's active tracking is clear before free
In looking at a use-after-free on Baytrail, it looks like the VMA's
activity tracking is suspect. Add some asserts to catch freeing the VMA
before we have decoupled all of its i915_gem_active trackers.
References: https://bugs.freedesktop.org/show_bug.cgi?id=101511
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-3-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Chris Wilson [Tue, 20 Jun 2017 12:43:19 +0000 (13:43 +0100)]
drm/i915: Retire the VMA's fence tracker before unbinding
Since we may track unfenced access (GPU access to the vma that
explicitly requires no fence), vma->last_fence may be set without any
attached fence (vma->fence) and so will not be flushed when we call
i915_vma_put_fence(). Since we stopped doing a full retire of the
activity trackers for unbind, we need to explicitly retire each tracker.
Fixes:
b0decaf75bd9 ("drm/i915: Track active vma requests")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Nicholas Piggin [Wed, 21 Jun 2017 06:34:20 +0000 (16:34 +1000)]
drm/i915: select CRC32
kbuild test robot found a build failure when building with thin
archives:
http://marc.info/?l=linux-kbuild&m=
149802285009737&w=2
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/20170621063420.24913-1-npiggin@gmail.com
Chris Wilson [Tue, 20 Jun 2017 12:43:20 +0000 (13:43 +0100)]
drm/i915: Pass the right flags to i915_vma_move_to_active()
i915_vma_move_to_active() takes the execobject flags and not a boolean!
Instead of passing EXEC_OBJECT_WRITE we passed true [i.e.
EXEC_OBJECT_NEEDS_FENCE] causing us to start tracking the
vma->last_fence access and since we forgot to clear that on unbinding,
we caused a use-after-free.
[ 321.263854] BUG: KASAN: use-after-free in i915_gem_request_retire+0x1728/0x1740 [i915]
[ 321.264001] Read of size 8 at addr
ffff880100fc67d8 by task gem_exec_reloc/2868
[ 321.264181] CPU: 0 PID: 2868 Comm: gem_exec_reloc Not tainted 4.12.0-rc6-CI-Custom_2759+ #1
[ 321.264195] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F6 02/17/2015
[ 321.264208] Call Trace:
[ 321.264234] dump_stack+0x67/0x99
[ 321.264260] print_address_description+0x77/0x290
[ 321.264437] ? i915_gem_request_retire+0x1728/0x1740 [i915]
[ 321.264459] kasan_report+0x269/0x350
[ 321.264487] __asan_report_load8_noabort+0x14/0x20
[ 321.264660] i915_gem_request_retire+0x1728/0x1740 [i915]
[ 321.264841] ? intel_ring_context_pin+0x131/0x690 [i915]
[ 321.265021] i915_gem_request_alloc+0x2c6/0x1220 [i915]
[ 321.265044] ? _raw_spin_unlock_irqrestore+0x3d/0x60
[ 321.265226] i915_gem_do_execbuffer+0xac0/0x2a20 [i915]
[ 321.265250] ? __lock_acquire+0xceb/0x5450
[ 321.265269] ? entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 321.265291] ? kvmalloc_node+0x6b/0x80
[ 321.265310] ? kvmalloc_node+0x6b/0x80
[ 321.265489] ? eb_relocate_slow+0xbe0/0xbe0 [i915]
[ 321.265520] ? ___slab_alloc.constprop.28+0x2ab/0x3d0
[ 321.265549] ? debug_check_no_locks_freed+0x280/0x280
[ 321.265591] ? __might_fault+0xc6/0x1b0
[ 321.265782] i915_gem_execbuffer2+0x14a/0x3f0 [i915]
[ 321.265815] drm_ioctl+0x4ba/0xaa0
[ 321.265986] ? i915_gem_execbuffer+0xde0/0xde0 [i915]
[ 321.266017] ? drm_getunique+0x270/0x270
[ 321.266068] do_vfs_ioctl+0x17f/0xfa0
[ 321.266091] ? __fget+0x1ba/0x330
[ 321.266112] ? lock_acquire+0x390/0x390
[ 321.266133] ? ioctl_preallocate+0x1d0/0x1d0
[ 321.266164] ? __fget+0x1db/0x330
[ 321.266194] ? __fget_light+0x79/0x1f0
[ 321.266219] SyS_ioctl+0x3c/0x70
[ 321.266247] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 321.266265] RIP: 0033:0x7fcede207357
[ 321.266279] RSP: 002b:
00007ffef0effe58 EFLAGS:
00000246 ORIG_RAX:
0000000000000010
[ 321.266307] RAX:
ffffffffffffffda RBX:
0000000000000002 RCX:
00007fcede207357
[ 321.266321] RDX:
00007ffef0effef0 RSI:
0000000040406469 RDI:
0000000000000004
[ 321.266335] RBP:
ffffffff812097c6 R08:
0000000000000008 R09:
0000000000000000
[ 321.266349] R10:
0000000000000008 R11:
0000000000000246 R12:
ffff880116bcff98
[ 321.266363] R13:
ffffffff81cb7cb3 R14:
ffff880116bcff70 R15:
0000000000000000
[ 321.266385] ? __this_cpu_preempt_check+0x13/0x20
[ 321.266406] ? trace_hardirqs_off_caller+0x1d6/0x2c0
[ 321.266487] Allocated by task 2868:
[ 321.266568] save_stack_trace+0x16/0x20
[ 321.266586] kasan_kmalloc+0xee/0x180
[ 321.266602] kasan_slab_alloc+0x12/0x20
[ 321.266620] kmem_cache_alloc+0xc7/0x2e0
[ 321.266795] i915_vma_instance+0x28c/0x1540 [i915]
[ 321.266964] eb_lookup_vmas+0x5a7/0x2250 [i915]
[ 321.267130] i915_gem_do_execbuffer+0x69a/0x2a20 [i915]
[ 321.267296] i915_gem_execbuffer2+0x14a/0x3f0 [i915]
[ 321.267315] drm_ioctl+0x4ba/0xaa0
[ 321.267333] do_vfs_ioctl+0x17f/0xfa0
[ 321.267350] SyS_ioctl+0x3c/0x70
[ 321.267369] entry_SYSCALL_64_fastpath+0x1c/0xb1
[ 321.267428] Freed by task 177:
[ 321.267502] save_stack_trace+0x16/0x20
[ 321.267521] kasan_slab_free+0xad/0x180
[ 321.267539] kmem_cache_free+0xc5/0x340
[ 321.267710] i915_vma_unbind+0x666/0x10a0 [i915]
[ 321.267880] i915_vma_close+0x23a/0x2f0 [i915]
[ 321.268048] __i915_gem_free_objects+0x17d/0xc70 [i915]
[ 321.268215] __i915_gem_free_work+0x49/0x70 [i915]
[ 321.268234] process_one_work+0x66f/0x1410
[ 321.268252] worker_thread+0xe1/0xe90
[ 321.268269] kthread+0x304/0x410
[ 321.268285] ret_from_fork+0x27/0x40
[ 321.268346] The buggy address belongs to the object at
ffff880100fc6640
which belongs to the cache i915_vma of size 656
[ 321.268550] The buggy address is located 408 bytes inside of
656-byte region [
ffff880100fc6640,
ffff880100fc68d0)
[ 321.268741] The buggy address belongs to the page:
[ 321.268837] page:
ffffea000403f000 count:1 mapcount:0 mapping: (null) index:0xffff880100fc5980 compound_mapcount: 0
[ 321.269045] flags: 0x8000000000008100(slab|head)
[ 321.269147] raw:
8000000000008100 0000000000000000 ffff880100fc5980 00000001001e001d
[ 321.269312] raw:
ffffea0004038e20 ffff880116b46240 ffff88011646c640 0000000000000000
[ 321.269484] page dumped because: kasan: bad access detected
[ 321.269665] Memory state around the buggy address:
[ 321.269778]
ffff880100fc6680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 321.269949]
ffff880100fc6700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 321.270115] >
ffff880100fc6780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 321.270279] ^
[ 321.270410]
ffff880100fc6800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 321.270576]
ffff880100fc6880: fb fb fb fb fb fb fb fb fb fb fc fc fc fc fc fc
[ 321.270740] ==================================================================
[ 321.270903] Disabling lock debugging due to kernel taint
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101511
Fixes:
7dd4f6729f92 ("drm/i915: Async GPU relocation processing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620124321.1108-2-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Michel Thierry [Tue, 20 Jun 2017 09:57:51 +0000 (10:57 +0100)]
drm/i915: Enable Engine reset and recovery support
This feature is made available only from Gen8, for previous gen devices
driver uses legacy full gpu reset.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-10-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-10-chris@chris-wilson.co.uk
Michel Thierry [Tue, 20 Jun 2017 09:57:50 +0000 (10:57 +0100)]
drm/i915/selftests: reset engine self tests
Check that we can reset specific engines, also check the fallback to
full reset if something didn't work.
v2: rebase.
v3: use RESET_ENGINE_IN_PROGRESS flag.
v4: use I915_RESET_ENGINE flag.
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-12-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-9-chris@chris-wilson.co.uk
Michel Thierry [Tue, 20 Jun 2017 09:57:49 +0000 (10:57 +0100)]
drm/i915: Export per-engine reset count info to debugfs
A new variable is added to export the reset counts to debugfs, this
includes full gpu reset and engine reset count. This is useful for tests
where they are expected to trigger reset; these counts are checked before
and after the test to ensure the same.
v2: Include reset engine count in i915_engine_info too (Chris).
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-8-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-8-chris@chris-wilson.co.uk
Michel Thierry [Tue, 20 Jun 2017 09:57:48 +0000 (10:57 +0100)]
drm/i915: Add engine reset count to error state
Driver maintains count of how many times a given engine is reset, useful to
capture this in error state also. It gives an idea of how engine is coping
up with the workloads it is executing before this error state.
A follow-up patch will provide this information in debugfs.
v2: s/engine_reset/reset_engine/ (Chris)
Define count as unsigned int (Tvrtko)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-7-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-7-chris@chris-wilson.co.uk
Michel Thierry [Tue, 20 Jun 2017 09:57:47 +0000 (10:57 +0100)]
drm/i915: Add support for per engine reset recovery
This change implements support for per-engine reset as an initial, less
intrusive hang recovery option to be attempted before falling back to the
legacy full GPU reset recovery mode if necessary. This is only supported
from Gen8 onwards.
Hangchecker determines which engines are hung and invokes error handler to
recover from it. Error handler schedules recovery for each of those engines
that are hung. The recovery procedure is as follows,
- identifies the request that caused the hang and it is dropped
- force engine to idle: this is done by issuing a reset request
- reset the engine
- re-init the engine to resume submissions.
If engine reset fails then we fall back to heavy weight full gpu reset
which resets all engines and reinitiazes complete state of HW and SW.
v2: Rebase.
v3: s/*engine_reset*/*reset_engine*/; freeze engine and irqs before
calling i915_gem_reset_engine (Chris).
v4: Rebase, modify i915_gem_reset_prepare to use a ring mask and
reuse the function for reset_engine.
v5: intel_reset_engine_start/cancel instead of request/unrequest_reset.
v6: Clean up reset_engine function to not require mutex, i.e. no need to call
revoke/restore_fences and _retire_requests (Chris).
v7: Remove leftovers from v5, i.e. no need to disable irq, hold
forcewake or wakeup the handoff bit (Chris).
v8: engine_retire_requests should be (and it was) static; explain that
we have to re-init the engine after reset, which is why the init_hw call
is needed; check reset-in-progress flag (Chris).
v9: Rebase, include code to pass the active request to gem_reset_engine
(as it is already done in full reset). Remove unnecessary
intel_reset_engine_start/cancel, these are executed as part of the
reset.
v10: Rebase, use the right I915_RESET_ENGINE flag.
v11: Fixup to call reset_finish_engine even on error.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-6-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-6-chris@chris-wilson.co.uk
Michel Thierry [Tue, 20 Jun 2017 09:57:46 +0000 (10:57 +0100)]
drm/i915: Modify error handler for per engine hang recovery
This is a preparatory patch which modifies error handler to do per engine
hang recovery. The actual patch which implements this sequence follows
later in the series. The aim is to prepare existing recovery function to
adapt to this new function where applicable (which fails at this point
because core implementation is lacking) and continue recovery using legacy
full gpu reset.
A helper function is also added to query the availability of engine
reset. A subsequent patch will add the capability to query which type
of reset is present (engine -> full -> no-reset) via the get-param
ioctl.
It has been decided that the error events that are used to notify user of
reset will only be sent in case if full chip reset. In case of just
single (or multiple) engine resets, userspace won't be notified by these
events.
Note that this implementation of engine reset is for i915 directly
submitting to the ELSP, where the driver manages the hang detection,
recovery and resubmission. With GuC submission these tasks are shared
between driver and firmware; i915 will still responsible for detecting a
hang, and when it does it will have to request GuC to reset that Engine and
remind the firmware about the outstanding submissions. This will be
added in different patch.
v2: rebase, advertise engine reset availability in platform definition,
add note about GuC submission.
v3: s/*engine_reset*/*reset_engine*/. (Chris)
Handle reset as 2 level resets, by first going to engine only and fall
backing to full/chip reset as needed, i.e. reset_engine will need the
struct_mutex.
v4: Pass the engine mask to i915_reset. (Chris)
v5: Rebase, update selftests.
v6: Rebase, prepare for mutex-less reset engine.
v7: Pass reset_engine mask as a function parameter, and iterate over the
engine mask for reset_engine. (Chris)
v8: Use i915.reset >=2 in has_reset_engine; remove redundant reset
logging; add a reset-engine-in-progress flag to prevent concurrent
resets, and avoid dual purposing of reset-backoff. (Chris)
v9: Support reset of different engines in parallel (Chris)
v10: Handle reset-engine flag locking better (Chris)
v11: Squash in reporting of per-engine-reset availability.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Ian Lister <ian.lister@intel.com>
Signed-off-by: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-4-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-5-chris@chris-wilson.co.uk
Michel Thierry [Tue, 20 Jun 2017 09:57:45 +0000 (10:57 +0100)]
drm/i915: Update i915.reset to handle engine resets
In preparation for engine reset work update this parameter to handle more
than one type of reset. Default at the moment is still full gpu reset.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Arun Siluvery <arun.siluvery@linux.intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-3-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-4-chris@chris-wilson.co.uk
Michel Thierry [Tue, 20 Jun 2017 09:57:44 +0000 (10:57 +0100)]
drm/i915: Look for active requests earlier in the reset path
And store the active request so that we only search for it once.
v2: Check for request completion inside _prepare_engine, don't use
ECANCELED, remove unnecessary null checks (Chris).
v3: Capture active requests during reset_prepare and store it the
engine hangcheck obj.
v4: Rename commit, change i915_gem_reset_request to just confirm the
active_request is still incomplete, instead of engine_stalled (Chris).
v5: With style; pass the active request to gem_reset_engine, keep single
return in reset_prepare_engine (Chris).
v6: Moved before reset-engine code appears (Chris)
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v5)
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615201828.23144-2-michel.thierry@intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-3-chris@chris-wilson.co.uk
Chris Wilson [Tue, 20 Jun 2017 09:57:43 +0000 (10:57 +0100)]
drm/i915: Wait for concurrent global resets to complete
If we enter i915_handle_error() a second time and a global reset is
already in progress, we can simply wait for completion of the first
reset. Currently we exit early prior to the actual reset being
performed -- the worst of both worlds!
v2: Plug into the existing reset_queue, and remember that kselftests is
playing games with I915_RESET_BACKOFF to prevent hangcheck from screwing
up.
v3: Rename to i915_reset_device to fit in better with i915_reset_engine
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170620095751.13127-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 20 Jun 2017 11:05:47 +0000 (12:05 +0100)]
drm/i915: Enable rcu-only context lookups
Whilst the contents of the context is still protected by the big
struct_mutex, this is not much of an improvement. It is just one tiny
step towards reducing our BKL.
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/20170620110547.15947-3-chris@chris-wilson.co.uk
Chris Wilson [Tue, 20 Jun 2017 11:05:46 +0000 (12:05 +0100)]
drm/i915: Allow contexts to be unreferenced locklessly
If we move the actual cleanup of the context to a worker, we can allow
the final free to be called from any context and avoid undue latency in
the caller.
v2: Negotiate handling the delayed contexts free by flushing the
workqueue before calling i915_gem_context_fini() and performing the final
free of the kernel context directly
v3: Flush deferred frees before new context allocations
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/20170620110547.15947-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 20 Jun 2017 11:05:45 +0000 (12:05 +0100)]
drm/i915: Group all the global context information together
Create a substruct to hold all the global context state under
drm_i915_private.
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/20170620110547.15947-1-chris@chris-wilson.co.uk
Tvrtko Ursulin [Mon, 19 Jun 2017 10:59:17 +0000 (11:59 +0100)]
drm/i915: Do not re-calculate num_rings locally
Since
bb8f0f5abdd7 ("drm/i915: Split intel_engine allocation
and initialisation") intel_info->num_rings is set early in the
load sequence and so available to be used direclty in the 2nd
load phase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/20170616130339.23015-1-tvrtko.ursulin@linux.intel.com
Tvrtko Ursulin [Fri, 16 Jun 2017 13:03:38 +0000 (14:03 +0100)]
drm/i915: Simplify intel_engines_init
We do not want to carry on over missing constructors and don't
need a duplicated engine mask checking which is already done
in the setup phase.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Rodrigo Vivi [Mon, 19 Jun 2017 18:39:32 +0000 (11:39 -0700)]
drm/i915/cnl: Fix RMW on ddi vswing sequence.
Paulo noticed that we were missing few bits clear
before writing values back to the register on
these RMW MMIO operations.
v2: Remove "POST_" from CURSOR_COEFF_MASK. (Paulo).
v3: Remove unnecessary braces. (Jani).
Fixes:
cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.")
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497897572-22520-1-git-send-email-rodrigo.vivi@intel.com
Ville Syrjälä [Thu, 15 Jun 2017 17:12:52 +0000 (20:12 +0300)]
drm/i915: Make intel_digital_port_connected() work for any port
Add the missing port A handling to intel_digital_port_connected()
and also separate SPT from the CPT/LPT code a bit.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615171252.11921-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Daniel Vetter [Mon, 19 Jun 2017 07:31:38 +0000 (09:31 +0200)]
drm/i915: Update DRIVER_DATE to
20170619
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Rodrigo Vivi [Fri, 16 Jun 2017 22:49:58 +0000 (15:49 -0700)]
drm/i915/cfl: Introduce Coffee Lake workarounds.
Coffee Lake inherit most of Kabylake production
workarounds.
v2: Fix typo on commit message and remove
WaDisableKillLogic and GEN9_DISABLE_OCL_OOB_SUPPRESS_LOGIC,
since as Mika pointed out they shouldn't be here for cfl
according to BSpec.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497653398-15722-1-git-send-email-rodrigo.vivi@intel.com
Dhinakaran Pandiyan [Fri, 16 Jun 2017 19:36:14 +0000 (12:36 -0700)]
drm/i915: Store 9 bits of PCI Device ID for platforms with a LP PCH
Although we use 9 bits of Device ID for identifying PCH, only 8 bits are
stored in dev_priv->pch_id. This makes HAS_PCH_CNP_LP() and
HAS_PCH_SPT_LP() incorrect. Fix this by storing all the 9 bits for the
platforms with LP PCH.
v2: Drop PCH_LPT_LP change (Imre)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Fixes: commit
ec7e0bb35f8d ("drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH")
Reported-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497641774-29104-1-git-send-email-dhinakaran.pandiyan@intel.com
Chris Wilson [Fri, 16 Jun 2017 14:05:25 +0000 (15:05 +0100)]
drm/i915: Stash a pointer to the obj's resv in the vma
During execbuf, a mandatory step is that we add this request (this
fence) to each object's reservation_object. Inside execbuf, we track the
vma, and to add the fence to the reservation_object then means having to
first chase the obj, incurring another cache miss. We can reduce the
number of cache misses by stashing a pointer to the reservation_object
in the vma itself.
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/20170616140525.6394-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 16 Jun 2017 14:05:24 +0000 (15:05 +0100)]
drm/i915: Async GPU relocation processing
If the user requires patching of their batch or auxiliary buffers, we
currently make the alterations on the cpu. If they are active on the GPU
at the time, we wait under the struct_mutex for them to finish executing
before we rewrite the contents. This happens if shared relocation trees
are used between different contexts with separate address space (and the
buffers then have different addresses in each), the 3D state will need
to be adjusted between execution on each context. However, we don't need
to use the CPU to do the relocation patching, as we could queue commands
to the GPU to perform it and use fences to serialise the operation with
the current activity and future - so the operation on the GPU appears
just as atomic as performing it immediately. Performing the relocation
rewrites on the GPU is not free, in terms of pure throughput, the number
of relocations/s is about halved - but more importantly so is the time
under the struct_mutex.
v2: Break out the request/batch allocation for clearer error flow.
v3: A few asserts to ensure rq ordering is maintained
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 16 Jun 2017 14:05:23 +0000 (15:05 +0100)]
drm/i915: Allow execbuffer to use the first object as the batch
Currently, the last object in the execlist is the always the batch.
However, when building the batch buffer we often know the batch object
first and if we can use the first slot in the execlist we can emit
relocation instructions relative to it immediately and avoid a separate
pass to adjust the relocations to point to the last execlist slot.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 16 Jun 2017 14:05:22 +0000 (15:05 +0100)]
drm/i915: Wait upon userptr get-user-pages within execbuffer
This simply hides the EAGAIN caused by userptr when userspace causes
resource contention. However, it is quite beneficial with highly
contended userptr users as we avoid repeating the setup costs and
kernel-user context switches.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Chris Wilson [Fri, 16 Jun 2017 14:05:21 +0000 (15:05 +0100)]
drm/i915: First try the previous execbuffer location
When choosing a slot for an execbuffer, we ideally want to use the same
address as last time (so that we don't have to rebind it) and the same
address as expected by the user (so that we don't have to fixup any
relocations pointing to it). If we first try to bind the incoming
execbuffer->offset from the user, or the currently bound offset that
should hopefully achieve the goal of avoiding the rebind cost and the
relocation penalty. However, if the object is not currently bound there
we don't want to arbitrarily unbind an object in our chosen position and
so choose to rebind/relocate the incoming object instead. After we
report the new position back to the user, on the next pass the
relocations should have settled down.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtien@linux.intel.com>
Chris Wilson [Fri, 16 Jun 2017 14:05:20 +0000 (15:05 +0100)]
drm/i915: Store a persistent reference for an object in the execbuffer cache
If we take a reference to the object/vma when it is first used in an
execbuf, we can keep that reference until the object's file-local handle
is closed. Thereby saving a frequent ref/unref pair.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 16 Jun 2017 14:05:19 +0000 (15:05 +0100)]
drm/i915: Eliminate lots of iterations over the execobjects array
The major scaling bottleneck in execbuffer is the processing of the
execobjects. Creating an auxiliary list is inefficient when compared to
using the execobject array we already have allocated.
Reservation is then split into phases. As we lookup up the VMA, we
try and bind it back into active location. Only if that fails, do we add
it to the unbound list for phase 2. In phase 2, we try and add all those
objects that could not fit into their previous location, with fallback
to retrying all objects and evicting the VM in case of severe
fragmentation. (This is the same as before, except that phase 1 is now
done inline with looking up the VMA to avoid an iteration over the
execobject array. In the ideal case, we eliminate the separate reservation
phase). During the reservation phase, we only evict from the VM between
passes (rather than currently as we try to fit every new VMA). In
testing with Unreal Engine's Atlantis demo which stresses the eviction
logic on gen7 class hardware, this speed up the framerate by a factor of
2.
The second loop amalgamation is between move_to_gpu and move_to_active.
As we always submit the request, even if incomplete, we can use the
current request to track active VMA as we perform the flushes and
synchronisation required.
The next big advancement is to avoid copying back to the user any
execobjects and relocations that are not changed.
v2: Add a Theory of Operation spiel.
v3: Fall back to slow relocations in preparation for flushing userptrs.
v4: Document struct members, factor out eb_validate_vma(), add a few
more comments to explain some magic and hide other magic behind macros.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 16 Jun 2017 14:05:18 +0000 (15:05 +0100)]
drm/i915: Disable EXEC_OBJECT_ASYNC when doing relocations
If we write a relocation into the buffer, we require our own implicit
synchronisation added after the start of the execbuf, outside of the
user's control. As we may end up clflushing, or doing the patch itself
on the GPU, asynchronously we need to look at the implicit serialisation
on obj->resv and hence need to disable EXEC_OBJECT_ASYNC for this
object.
If the user does trigger a stall for relocations, we make sure the stall
is complete enough so that the batch is not submitted before we complete
those relocations.
Fixes:
77ae9957897d ("drm/i915: Enable userspace to opt-out of implicit fencing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jason Ekstrand <jason@jlekstrand.net>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 16 Jun 2017 14:05:17 +0000 (15:05 +0100)]
drm/i915: Pass vma to relocate entry
We can simplify our tracking of pending writes in an execbuf to the
single bit in the vma->exec_entry->flags, but that requires the
relocation function knowing the object's vma. Pass it along.
Note we have only been using a single bit to track flushing since
commit
cc889e0f6ce6a63c62db17d702ecfed86d58083f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Wed Jun 13 20:45:19 2012 +0200
drm/i915: disable flushing_list/gpu_write_list
unconditionally flushed all render caches before the breadcrumb and
commit
6ac42f4148bc27e5ffd18a9ab0eac57f58822af4
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Sat Jul 21 12:25:01 2012 +0200
drm/i915: Replace the complex flushing logic with simple invalidate/flush all
did away with the explicit GPU domain tracking. This was then codified
into the ABI with NO_RELOC in
commit
ed5982e6ce5f106abcbf071f80730db344a6da42
Author: Daniel Vetter <daniel.vetter@ffwll.ch> # Oi! Patch stealer!
Date: Thu Jan 17 22:23:36 2013 +0100
drm/i915: Allow userspace to hint that the relocations were known
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 16 Jun 2017 14:05:16 +0000 (15:05 +0100)]
drm/i915: Store a direct lookup from object handle to vma
The advent of full-ppgtt lead to an extra indirection between the object
and its binding. That extra indirection has a noticeable impact on how
fast we can convert from the user handles to our internal vma for
execbuffer. In order to bypass the extra indirection, we use a
resizable hashtable to jump from the object to the per-ctx vma.
rhashtable was considered but we don't need the online resizing feature
and the extra complexity proved to undermine its usefulness. Instead, we
simply reallocate the hastable on demand in a background task and
serialize it before iterating.
In non-full-ppgtt modes, multiple files and multiple contexts can share
the same vma. This leads to having multiple possible handle->vma links,
so we only use the first to establish the fast path. The majority of
buffers are not shared and so we should still be able to realise
speedups with multiple clients.
v2: Prettier names, more magic.
v3: Many style tweaks, most notably hiding the misuse of execobj[].rsvd2
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 16 Jun 2017 13:28:49 +0000 (14:28 +0100)]
drm/i915: Fix retrieval of hangcheck stats
The default context is always supported (as it contains the global
hangcheck stats) and the contexts for hangcheck are not limited
to any ring.
This was dropped in 2013 because it was supposed to have been included
with Ben's full-ppgtt patch set. It never landed and the bug remains.
References: https://bugs.freedesktop.org/show_bug.cgi?id=65845
Link: http://patchwork.freedesktop.org/patch/msgid/1372175222-27622-1-git-send-email-mika.kuoppala@intel.com
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/20170616132849.29597-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 16 Jun 2017 10:54:55 +0000 (11:54 +0100)]
drm/i915: Store i915_gem_object_is_coherent() as a bit next to cache-dirty
For ease of use (i.e. avoiding a few checks and function calls), store
the object's cache coherency next to the cache is dirty bit.
Specifically this patch aims to reduce the frequency of no-op calls to
i915_gem_object_clflush() to counter-act the increase of such calls for
GPU only objects in the previous patch.
v2: Replace cache_dirty & ~cache_coherent with cache_dirty &&
!cache_coherent as gcc generates much better code for the latter
(Tvrtko)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dongwon Kim <dongwon.kim@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Tested-by: Dongwon Kim <dongwon.kim@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170616105455.16977-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Thu, 15 Jun 2017 12:38:49 +0000 (13:38 +0100)]
drm/i915: Mark CPU cache as dirty on every transition for CPU writes
Currently, we only mark the CPU cache as dirty if we skip a clflush.
This leads to some confusion where we have to ask if the object is in
the write domain or missed a clflush. If we always mark the cache as
dirty, this becomes a much simply question to answer.
The goal remains to do as few clflushes as required and to do them as
late as possible, in the hope of deferring the work to a kthread and not
block the caller (e.g. execbuf, flips).
v2: Always call clflush before GPU execution when the cache_dirty flag
is set. This may cause some extra work on llc systems that migrate dirty
buffers back and forth - but we do try to limit that by only setting
cache_dirty at the end of the gpu sequence.
v3: Always mark the cache as dirty upon a level change, as we need to
invalidate any stale cachelines due to external writes.
Reported-by: Dongwon Kim <dongwon.kim@intel.com>
Fixes:
a6a7cc4b7db6 ("drm/i915: Always flush the dirty CPU cache when pinning the scanout")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Dongwon Kim <dongwon.kim@intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Tested-by: Dongwon Kim <dongwon.kim@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170615123850.26843-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Chris Wilson [Fri, 16 Jun 2017 12:35:08 +0000 (13:35 +0100)]
drm/i915: Make i915_vma_destroy() static
i915_vma_destroy() is now not used outside of i915_vma.c so we can
remove the export and make the function static.
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/20170616123508.12673-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Ville Syrjälä [Thu, 15 Jun 2017 17:23:08 +0000 (20:23 +0300)]
drm/i915: Actually attach the tv_format property to the SDVO connector
Attach the tv_format property to the SDVO connector instead of passing
a '0' in place of the pointer to the property. This got broken when
the SDVO connector properties were converted to atomic.
We can thank sparse for catching this:
drivers/gpu/drm/i915/intel_sdvo.c:2742:75: warning: Using plain integer as NULL pointer
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Fixes:
630d30a4ee27 ("drm/i915: Convert intel_sdvo connector properties to atomic.")
Link: http://patchwork.freedesktop.org/patch/msgid/20170615172308.10121-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Jani Nikula [Fri, 16 Jun 2017 07:03:00 +0000 (10:03 +0300)]
Merge tag 'gvt-next-2017-06-08' of https://github.com/01org/gvt-linux into drm-intel-next-queued
gvt-next-2017-06-08
First gvt-next pull for 4.13:
- optimization for per-VM mmio save/restore (Changbin)
- optimization for mmio hash table (Changbin)
- scheduler optimization with event (Ping)
- vGPU reset refinement (Fred)
- other misc refactor and cleanups, etc.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170608093547.bjgs436e3iokrzdm@zhen-hp.sh.intel.com
Rodrigo Vivi [Tue, 13 Jun 2017 17:52:30 +0000 (10:52 -0700)]
Revert "drm/i915/skl: New ddb allocation algorithm"
This reverts commit
bb9d85f6e9de8fef5236c076530eab67a2f2431b.
New ddb allocation algorithm is a show stopper on my SKL system.
Besides not be able to get external DP 4k@60 (through USB type C),
It fully hang my screen when unplugging the USB type C.
Bugzilla: https://patchwork.freedesktop.org/patch/161571/
Fixes:
bb9d85f6e9de ("drm/i915/skl: New ddb allocation algorithm")
Cc: Mahesh Kumar <mahesh1.kumar@intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497376350-3400-1-git-send-email-rodrigo.vivi@intel.com
Madhav Chauhan [Tue, 13 Jun 2017 07:48:15 +0000 (13:18 +0530)]
drm/i915/glk: Add cold boot sequence for GLK DSI
As per BSEPC, if device ready bit is '0' in enable IO sequence
then its a cold boot/reset scenario eg: S3/S4 resume. If cold boot
scenario detected in enable IO, then prepare port immediately.
In normal boot scenario, prepare port after glk_dsi_device_ready().
Without cold boot sequence enabled, features like S3/S4 doesn't work.
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/1497340095-5877-2-git-send-email-madhav.chauhan@intel.com
Madhav Chauhan [Tue, 13 Jun 2017 07:48:14 +0000 (13:18 +0530)]
drm/i915/glk: Split GLK DSI device ready functionality
This patch divides glk_dsi_device_ready() function into
two part. First part will program LP wake and MIPI DSI mode
to MIPI_CTRL reg using newly defined function glk_dsi_enable_io().
glk_dsi_enable_io() will be called from intel_dsi_pre_enable.
Second part will do remaining device ready activities using
the existing function glk_dsi_device_ready().
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/1497340095-5877-1-git-send-email-madhav.chauhan@intel.com
Dhinakaran Pandiyan [Tue, 13 Jun 2017 20:03:59 +0000 (13:03 -0700)]
drm/i915: Don't enable backlight at setup time.
Maarten and Ville noticed that we are enabling backlight via DP aux very
early in the modeset_init path via the intel_dp_aux_setup_backlight()
function, since commit
e7156c833903 ("drm/i915: Add Backlight Control using
DPCD for eDP connectors (v9)"). Looks like all we need to do during
_setup_backlight() is read the current brightness state instead of
modifying it.
v2: Rewrote commit message.
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Yetunde Adebisi <yetundex.adebisi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Tested-by: Puthikorn Voravootivat <puthik@chromium.org>
Fixes:
e7156c833903 ("drm/i915: Add Backlight Control using DPCD for eDP connectors (v9)")
Link: http://patchwork.freedesktop.org/patch/msgid/1497384239-2965-1-git-send-email-dhinakaran.pandiyan@intel.com
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Colin Ian King [Tue, 13 Jun 2017 13:47:51 +0000 (14:47 +0100)]
drm/i915/cnl: make function cnl_ddi_dp_set_dpll_hw_state static
The function cnl_ddi_dp_set_dpll_hw_state does not need to be in global
scope, so make it static.
Cleans up sparse warning:
"symbol 'cnl_ddi_dp_set_dpll_hw_state' was not declared. Should it
be static?"
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170613134751.29196-1-colin.king@canonical.com
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Ville Syrjälä [Thu, 1 Jun 2017 14:36:19 +0000 (17:36 +0300)]
drm/i915: Remove pipe A quirk remnants
With 830 the only thing needing pipe quirks, we can just drop the quirk
defines and replace the checks with IS_I830() checks.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-8-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Ville Syrjälä [Thu, 1 Jun 2017 14:36:18 +0000 (17:36 +0300)]
drm/i915: Drop pipe A quirk for Thinkapd T60
The pipe A force quirk shouldn't needed except on 830. So let's nuke it
for the IBM Thinkpad T60 945 machines. This quirk pre-dates
KMS so it's usefulness is doubtful at best now.
The original bug report [1] describes the symptoms as "system hang on
closing T60 panel lid", and we already dropped a similar quirk for
another 945 machine in
commit
736a69ca8c99 ("drm/i915: Drop PIPE-A quirk for 945GSE HP Mini")
so I'm hopeful we can drop this one as well.
The quirk was added into xf86-video-intel in
commit
08903abe4dc0 ("Add pipe a force enable quirk for Lenovo T60")
[1] https://bugs.freedesktop.org/show_bug.cgi?id=16494
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-7-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Ville Syrjälä [Thu, 1 Jun 2017 14:36:17 +0000 (17:36 +0300)]
drm/i915: Drop pipe A quirk for Toshiba Protege R205-S209
The pipe A force quirk shouldn't needed except on 830. So let's nuke it
for the Toshiba Protege R-205/S-209 945 machines. This quirk pre-dates
KMS so it's usefulness is doubtful at best now.
Unfortunately the original bug report [1] isn't very helpful since it
doesn't describe the symptoms. And the commit message in xf86-video-intel
commit
ecdb5963ef68 ("Add pipe A force enable quirk for Toshiba Portege R205-S209")
is not much help either.
However, if we assume the problem was the typical "closing the lid
hangs the box" type of thing, we already nuked the quirk for another
945 machine in
commit
736a69ca8c99 ("drm/i915: Drop PIPE-A quirk for 945GSE HP Mini")
and so I hope we can drop this one as well.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=14944
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-6-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Ville Syrjälä [Thu, 1 Jun 2017 14:36:16 +0000 (17:36 +0300)]
drm/i915: Add i830 "pipes power well"
830 more or less requires both pipes and DPLLs to remain on as long
as either pipe is needed. However, when neither pipe is actually needed,
we can save a bit of power by turning everything off. To do that we add
a new "power well" that turns both pipes and DPLLs on and off in the
right order. Seems to save ~50mW on my Fujitsu-Siemens Lifebook S6010.
This also avoids having to abuse the load detection to force pipe A on
at init time. That was never very robust, and it only worked for one
pipe, whereas 830 really needs both pipes enabled. As a bonus the 830
pipe quirk is now a bit more isolated from the rest of the mode setting
infrastructure, which should mean that it's much less likely someone
will accidentally break it in the future. The extra cost is of course
slight code duplication, but that seems like a worthwile tradeoff here.
v2; s/BIT/BIT_ULL/
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-5-ville.syrjala@linux.intel.com
Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Ville Syrjälä [Thu, 1 Jun 2017 14:36:15 +0000 (17:36 +0300)]
drm/i915: Use a loop for the "three times for luck" DPLL procedure
The magic "enable the DPLL three times" sequence feels like it
deserves a loop.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Ville Syrjälä [Thu, 1 Jun 2017 14:36:14 +0000 (17:36 +0300)]
drm/i915: Plumb the correct acquire ctx into intel_crtc_disable_noatomic()
If intel_crtc_disable_noatomic() were to ever get called during resume
we'd end up deadlocking since resume has its own acqcuire_ctx but
intel_crtc_disable_noatomic() still tries to use the
mode_config.acquire_ctx. Pass down the correct acquire ctx from the top.
Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes:
e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-3-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Ville Syrjälä [Thu, 1 Jun 2017 14:36:13 +0000 (17:36 +0300)]
drm/i915: Fix deadlock witha the pipe A quirk during resume
Pass down the correct acquire context to the pipe A quirk load detect
hack during display resume. Avoids deadlocking the entire thing.
Cc: stable@vger.kernel.org
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes:
e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170601143619.27840-2-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Chris Wilson [Thu, 15 Jun 2017 08:14:35 +0000 (09:14 +0100)]
drm/i915: Split vma exec_link/evict_link
Currently the vma has one link member that is used for both holding its
place in the execbuf reservation list, and in any eviction list. This
dual property is quite tricky and error prone.
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/20170615081435.17699-3-chris@chris-wilson.co.uk
Chris Wilson [Thu, 15 Jun 2017 08:14:34 +0000 (09:14 +0100)]
drm/i915: Use vma->exec_entry as our double-entry placeholder
This has the benefit of not requiring us to manipulate the
vma->exec_link list when tearing down the execbuffer, and is a
marginally cheaper test to detect the user error.
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/20170615081435.17699-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 15 Jun 2017 08:14:33 +0000 (09:14 +0100)]
drm/i915: Amalgamate execbuffer parameter structures
Combine the two slightly overlapping parameter structures we pass around
the execbuffer routines into one.
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/20170615081435.17699-1-chris@chris-wilson.co.uk
Lionel Landwerlin [Tue, 13 Jun 2017 11:23:09 +0000 (12:23 +0100)]
drm/i915/perf: add GLK support
Add OA support for Geminilake (pretty much identical to Broxton), and
also add the associated OA configurations.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Link: http://patchwork.freedesktop.org/patch/msgid/20170613112309.4088-2-lionel.g.landwerlin@intel.com
Lionel Landwerlin [Tue, 13 Jun 2017 11:23:08 +0000 (12:23 +0100)]
drm/i915/perf: add KBL support
Add OA support for Kabylake (pretty much identical to Skylake), and
also add the associated OA configurations.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Lionel Landwerlin [Tue, 13 Jun 2017 11:23:07 +0000 (12:23 +0100)]
drm/i915: add KBL GT2/GT3 check macros
Add macros to detect GT2/GT3 skus so we can apply the proper OA
configuration later.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Robert Bragg [Tue, 13 Jun 2017 11:23:06 +0000 (12:23 +0100)]
drm/i915/perf: remove perf.hook_lock
In earlier iterations of the i915-perf driver we had a number of
callbacks/hooks from other parts of the i915 driver to e.g. notify us
when a legacy context was pinned and these could run asynchronously with
respect to the stream file operations and might also run in atomic
context.
dev_priv->perf.hook_lock had been for serialising access to state needed
within these callbacks, but as the code has evolved some of the hooks
have gone away or are implemented to avoid needing to lock any state.
The remaining use of this lock was actually redundant considering how
the gen7 oacontrol state used to be updated as part of a context pin
hook.
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Robert Bragg [Tue, 13 Jun 2017 11:23:05 +0000 (12:23 +0100)]
drm/i915/perf: per-gen timebase for checking sample freq
An oa_exponent_to_ns() utility and per-gen timebase constants where
recently removed when updating the tail pointer race condition WA, and
this restores those so we can update the _PROP_OA_EXPONENT validation
done in read_properties_unlocked() to not assume we have a 12.5MHz
timebase as we did for Haswell.
Accordingly the oa_sample_rate_hard_limit value that's referenced by
proc_dointvec_minmax defining the absolute limit for the OA sampling
frequency is now initialized to (timestamp_frequency / 2) instead of the
6.25MHz constant for Haswell.
v2:
Specify frequency of 19.2MHz for BXT (Ville)
Initialize oa_sample_rate_hard_limit per-gen too (Lionel)
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Robert Bragg [Tue, 13 Jun 2017 11:23:04 +0000 (12:23 +0100)]
drm/i915/perf: Add more OA configs for BDW, CHV, SKL + BXT
These are auto generated from an XML description of metric sets,
currently maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gputop-data -f Makefile.xml
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Robert Bragg [Tue, 13 Jun 2017 11:23:03 +0000 (12:23 +0100)]
drm/i915/perf: Add OA unit support for Gen 8+
Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all
share (more-or-less) the same OA unit design.
Of particular note in comparison to Haswell: some OA unit HW config
state has become per-context state and as a consequence it is somewhat
more complicated to manage synchronous state changes from the cpu while
there's no guarantee of what context (if any) is currently actively
running on the gpu.
The periodic sampling frequency which can be particularly useful for
system-wide analysis (as opposed to command stream synchronised
MI_REPORT_PERF_COUNT commands) is perhaps the most surprising state to
have become per-context save and restored (while the OABUFFER
destination is still a shared, system-wide resource).
This support for gen8+ takes care to consider a number of timing
challenges involved in synchronously updating per-context state
primarily by programming all config state from the cpu and updating all
current and saved contexts synchronously while the OA unit is still
disabled.
The driver intentionally avoids depending on command streamer
programming to update OA state considering the lack of synchronization
between the automatic loading of OACTXCONTROL state (that includes the
periodic sampling state and enable state) on context restore and the
parsing of any general purpose BB the driver can control. I.e. this
implementation is careful to avoid the possibility of a context restore
temporarily enabling any out-of-date periodic sampling state. In
addition to the risk of transiently-out-of-date state being loaded
automatically; there are also internal HW latencies involved in the
loading of MUX configurations which would be difficult to account for
from the command streamer (and we only want to enable the unit when once
the MUX configuration is complete).
Since the Gen8+ OA unit design no longer supports clock gating the unit
off for a single given context (which effectively stopped any progress
of counters while any other context was running) and instead supports
tagging OA reports with a context ID for filtering on the CPU, it means
we can no longer hide the system-wide progress of counters from a
non-privileged application only interested in metrics for its own
context. Although we could theoretically try and subtract the progress
of other contexts before forwarding reports via read() we aren't in a
position to filter reports captured via MI_REPORT_PERF_COUNT commands.
As a result, for Gen8+, we always require the
dev.i915.perf_stream_paranoid to be unset for any access to OA metrics
if not root.
v5: Drain submitted requests when enabling metric set to ensure no
lite-restore erases the context image we just updated (Lionel)
v6: In addition to drain, switch to kernel context & update all
context in place (Chris)
v7: Add missing mutex_unlock() if switching to kernel context fails
(Matthew)
v8: Simplify OA period/flex-eu-counters programming by using the
batchbuffer instead of modifying ctx-image (Lionel)
v9: Back to updating the context image (due to erroneous testing,
batchbuffer programming the OA unit doesn't actually work)
(Lionel)
Pin context before updating context image (Chris)
Drop MMIO programming now that we switch to a kernel context with
right values in initial context image (Chris)
v10: Just pin_map the contexts we want to modify or let the
configuration happen on first use (Chris)
v11: Update kernel context OA config through the batchbuffer rather
than on the fly ctx-image update (Lionel)
v12: Rework OA context registers update again by swithing away from
user contexts and reconfiguring the kernel context through the
batchbuffer and updating all the other contexts' context image.
Also take care to lock slice/subslice configuration when OA is
on. (Lionel)
v13: Request rpcs updates on all engine when updating the OA config
(Lionel)
v14: Drop any kind of rpcs management now that we monitor sseu
configuration changes in a later patch (Lionel)
Remove usleep after programming the NOA configs on Gen8+, this
doesn't seem to be needed (Lionel)
v15: Respect coding style for block comments (Chris)
v16: Add missing i915_add_request() in case we fail to emit OA
configuration (Matthew)
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com> \o/
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Robert Bragg [Tue, 13 Jun 2017 11:23:02 +0000 (12:23 +0100)]
drm/i915/perf: Add 'render basic' Gen8+ OA unit configs
Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic
render metrics on Broadwell, Cherryview, Skylake and Broxton. These are
auto generated from an XML description of metric sets, currently
maintained in gputop, ref:
https://github.com/rib/gputop
> gputop-data/oa-*.xml
> scripts/i915-perf-kernelgen.py
$ make -C gputop-data -f Makefile.xml WHITELIST=RenderBasic
v2: add newlines to debug messages + fix comment (Matthew Auld)
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Lionel Landwerlin [Tue, 13 Jun 2017 11:23:01 +0000 (12:23 +0100)]
drm/i915/perf: rework mux configurations queries
Gen8+ might have mux configurations per slices/subslices. Depending on
whether slices/subslices have been fused off, only part of the
configuration needs to be applied. This change reworks the mux
configurations query mechanism to allow more than one set of registers
to be programmed.
v2: s/n_mux_regs/n_mux_configs/ (Matthew)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Robert Bragg [Tue, 13 Jun 2017 11:23:00 +0000 (12:23 +0100)]
drm/i915: expose _SUBSLICE_MASK GETPARM
Assuming a uniform mask across all slices, this enables userspace to
determine the specific sub slices can be enabled. This information is
required, for example, to be able to analyse some OA counter reports
where the counter configuration depends on the HW sub slice
configuration.
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Robert Bragg [Tue, 13 Jun 2017 11:22:59 +0000 (12:22 +0100)]
drm/i915: expose _SLICE_MASK GETPARM
Enables userspace to determine the maximum number of slices that can
be enabled on the device and also know what specific slices can be
enabled. This information is required, for example, to be able to
analyse some OA counter reports where the counter configuration
depends on the HW slice configuration.
Signed-off-by: Robert Bragg <robert@sixbynine.org>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Chris Wilson [Thu, 18 May 2017 09:46:18 +0000 (10:46 +0100)]
drm/i915: Reinstate reservation_object zapping for batch_pool objects
I removed the zapping of the reservation_object->fence array of shared
fences prematurely. We don't yet have the code to zap that array when
retiring the object, and so currently it remains possible to continually
grow the shared array trapping requests when reusing the batch_pool
object across many timelines.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170518094638.5469-4-chris@chris-wilson.co.uk
Chris Wilson [Fri, 9 Jun 2017 11:03:49 +0000 (12:03 +0100)]
drm/i915: Spin for struct_mutex inside shrinker
Having resolved whether or not we would deadlock upon a call to
mutex_lock(&dev->struct_mutex), we can then spin for the contended
struct_mutex if we are not the owner. We cannot afford to simply block
and wait for the mutex, as the owner may itself be waiting for the
allocator -- i.e. a cyclic deadlock. This should significantly improve
the chance of running the shrinker for other processes whilst the GPU is
busy.
A more balanced approach would be to optimistically spin whilst the
mutex owner was on the cpu and there was an opportunity to acquire the
mutex for ourselves quickly. However, that requires support from
kernel/locking/ and a new mutex_spin_trylock() primitive.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170609110350.1767-4-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 9 Jun 2017 11:03:48 +0000 (12:03 +0100)]
drm/i915: Only restrict noreclaim in the early shrink passes
In our first pass, we do not want to use reclaim at all as we want to
solely reap the i915 buffer caches (its purgeable pages). But we don't
mind it initiates IO or pulls via the FS (but it shouldn't anyway as we
say no to reclaim!). Just drop the GFP_IO constraint for simplicity.
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/20170609110350.1767-3-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 9 Jun 2017 11:03:47 +0000 (12:03 +0100)]
drm/i915: Remove __GFP_NORETRY from our buffer allocator
I tried __GFP_NORETRY in the belief that __GFP_RECLAIM was effective. It
struggles with handling reclaim of our dirty buffers and relies on
reclaim via kswapd. As a result, a single pass of direct reclaim is
unreliable when i915 occupies the majority of available memory, and the
only means of effectively waiting on kswapd to amke progress is by not
setting the __GFP_NORETRY flag and lopping. That leaves us with the
dilemma of invoking the oomkiller instead of propagating the allocation
failure back to userspace where it can be handled more gracefully (one
hopes). In the future we may have __GFP_MAYFAIL to allow repeats up until
we genuinely run out of memory and the oomkiller would have been invoked.
Until then, let the oomkiller wreck havoc.
v2: Stop playing with side-effects of gfp flags and await __GFP_MAYFAIL
v3: Update comments that direct reclaim only appears to be ignoring our
dirty buffers!
Fixes:
24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
Testcase: igt/gem_tiled_swapping
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Michal Hocko <mhocko@suse.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170609110350.1767-2-chris@chris-wilson.co.uk
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Chris Wilson [Fri, 9 Jun 2017 11:03:46 +0000 (12:03 +0100)]
drm/i915: Encourage our shrinker more when our shmemfs allocations fails
Commit
24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than
incur the oom for gfx allocations") made the bold decision to try and
avoid the oomkiller by reporting -ENOMEM to userspace if our allocation
failed after attempting to free enough buffer objects. In short, it
appears we were giving up too easily (even before we start wondering if
one pass of reclaim is as strong as we would like). Part of the problem
is that if we only shrink just enough pages for our expected allocation,
the likelihood of those pages becoming available to us is less than 100%
To counter-act that we ask for twice the number of pages to be made
available. Furthermore, we allow the shrinker to pull pages from the
active list in later passes.
v2: Be a little more cautious in paging out gfx buffers, and leave that
to a more balanced approach from shrink_slab(). Important when combined
with "drm/i915: Start writeback from the shrinker" as anything shrunk is
immediately swapped out and so should be more conservative.
Fixes:
24f8e00a8a2e ("drm/i915: Prefer to report ENOMEM rather than incur the oom for gfx allocations")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170609110350.1767-1-chris@chris-wilson.co.uk
Rodrigo Vivi [Fri, 9 Jun 2017 22:02:50 +0000 (15:02 -0700)]
drm/i915/cfl: Basic DDI plumbing for Coffee Lake.
All here is pretty much like Kabylake.
Including CFL-U has to use same ddi translation table
as KBL-U for now.
v2: Include missed IS_COFFEELAKE on edp trans table. (DK)
Handle CFL-U with same translation table as KBL-U. (DK and
confirmed with HW engineers)
v3: Adding missed case for IS_CFL_ULT. (DK).
v4: Duh! Now with the real IS_CFL_ULT instead of KBL one. (DK)
Also use IS_GEN9_BC when possible. (DK)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497045770-21302-1-git-send-email-rodrigo.vivi@intel.com
Kahola, Mika [Fri, 9 Jun 2017 22:26:15 +0000 (15:26 -0700)]
drm/i915/cnl: Enable wrpll computation for CNL
Enable wrpll computation for Cannonlake platform to support
pll's required for HDMI output. The patch contains the following features
- compute Cannonlake port clock programming
dividers P, Q, and K.
- compute PLL parameters for Cannonlake. These parameters
set the values on DPLL registers.
- find the register values to program wrpll for Cannonlake.
The reference clock can be either 19.2MHz or 24MHz.
v2: rebase
v3: squash wrpll patches into one (Rodrigo)
v4: switch order of getting even dividers (Paulo)
update divider register values for PDiv and KDiv (Paulo)
update wrpll computation algorithm (Paulo)
v5: Remove ref clock division by 1000. (Rodrigo)
v6: Rodrigo rebasing on top of latest code.
Signed-off-by: Kahola, Mika <mika.kahola@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Clint Taylor <Clinton.A.Taylor@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-18-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:14 +0000 (15:26 -0700)]
drm/i915/cnl: LSPCON support is gen9+
There is no platform specific change needed for LSPCON
support on Cannonlake. So let's make it gen9+.
Cc: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-17-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:13 +0000 (15:26 -0700)]
drm/i915/cnl: Enable fifo underrun for Cannonlake.
Also in a way that reuse bdw+ for all next platforms.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-16-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:12 +0000 (15:26 -0700)]
drm/i915/cnl: Fix Cannonlake scaler mode programing.
As Geminilake scalers Cannonlake also don't need and don't have
the "high quality" mode programming.
Cc: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-15-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:11 +0000 (15:26 -0700)]
drm/i915: Use HAS_CSR instead of gen number on DMC load.
Since we have HAS_CSR tied to the platform definition
let's use this instead of checking per platform.
One less thing to worry when adding support to new platforms.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Animesh Manna<animesh.manna@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-14-git-send-email-rodrigo.vivi@intel.com
Anusha Srivatsa [Fri, 9 Jun 2017 22:26:10 +0000 (15:26 -0700)]
drm/i915/DMC/CNL: Load DMC on CNL
This patch loads the DMC on CNL.The firmware version
is 1.04.
v2: (Rodrigo) Remove MODULE_FIRMWARE.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Animesh Manna <animesh.manna@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-13-git-send-email-rodrigo.vivi@intel.com
Clint Taylor [Fri, 9 Jun 2017 22:26:09 +0000 (15:26 -0700)]
drm/i915/cnl: Enable loadgen_select bit for vswing sequence
vswing programming sequence step 2 requires the Loadgen_select bit to
be set in PORT_TX_DW4 lane reigsters per table defined by Bit rate and
lane width. Implemented the change that was marked as FIXME in the
driver.
v2: (Rodrigo) checkpatch fixes.
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-12-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:08 +0000 (15:26 -0700)]
drm/i915/cnl: Implement voltage swing sequence.
This is an important part of the DDI initalization as well as
for changing the voltage during DisplayPort link training.
This new sequence for Cannonlake is more like Broxton style
but still with different registers, different table and
different steps.
v2: Do not write to DW4_GRP to avoid overwrite individual loadgen.
Fix PORT_CL_DW5 SUS Clock Config set.
v3: As previous platforms use only eDP table if low voltage was
requested.
v4: fix Werror:maybe uninitialized (Paulo)
v5: Rebase on top of dw2_swing_sel changes
on previous patches.
v6: Using flexible SCALING_MODE_SEL(x).
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-11-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:07 +0000 (15:26 -0700)]
drm/i915/cnl: Add DDI Buffer translation tables for Cannonlake.
These tables are used on voltage wswing sequence initialization
on Cannonlake.
It is a complete new format now in use by the voltage swing team,
not following any other standard in use by any other platform.
Also the registers are different as well. So let's redefine
the translation table for Cannonlake.
The table is huge. So we minimized with the fields that are
different or might be different anytime soon. The common
values will be hardcoded on the voltage swing sequence.
v2: Merge the lower and the upper bits to match the spec table
and make review easier. This was possible with the good
idea for Manasi with a better way to handle it on the bit
macro definition presented on previous patch.
Credits-to: Manasi
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-10-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:06 +0000 (15:26 -0700)]
drm/i915/cnl: Add registers related to voltage swing sequences.
This are the registers and bits needed for the voltage swing
sequence on Cannonlake.
v2: Remove CL_DW5 that was wrongly defined.
v3: Use (1 << 1) instead of (1<<1) as Paulo suggested
Change DW2 swing sel upper and lower macros to do the
bit selection instead of definint a table that doesn't
match the spec. It is based on a Manasi version of it.
Credits-to: Manasi.
v4: Let SCALING_MODE_SEL flexible. (Manasi)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-9-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:05 +0000 (15:26 -0700)]
drm/i915: Add MMIO helper for 6 ports with different offsets.
Also new registers can have different mmio offsets
per different lane per port.
v2: Use _PICK as PORT3 instead of creating a new
macro with if per port.
v3: Use _PICK directly on MMIO_PORT6. While MMIO_PORT
isn't flexible enough let's continue with MMIO_PORT6
as we have MMIO_PORT3.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-8-git-send-email-rodrigo.vivi@intel.com
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:04 +0000 (15:26 -0700)]
drm/i915/cnl: Initialize PLLs
Although CNL follows PLL initialization more like Skylake
than Broxton we have a completely different initialization
sequence and registers used.
One big difference from SKL is that CDCLK PLL is now
exclusive (ADPLL) and for DDIs and MIPI we need to use
DFGPLLs 0, 1 or 2.
v2: Accept all Ander's suggestions and fixes:
- Registers and bits names prefix
- Group pll functions
- bits masks fixes
- remove read and modify on cfgcr1
- fix cfgcr0 setup
v3: Set SSC_ENABLE for DP.
Fix HDMI_MODE cfgcr0.
Avoid touch cfgcr0 on DP.
Add missed else on dpll_mgr definition so we use cnl one, not hsw.
v3: Centra freq should be always set to default and change bits
definitions to (1 << 1) instead of (1<<1). (by Paulo)
v4: Rebased.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Kahola, Mika <mika.kahola@intel.com>
Reviewed-by: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-7-git-send-email-rodrigo.vivi@intel.com
Kahola, Mika [Fri, 9 Jun 2017 22:26:03 +0000 (15:26 -0700)]
drm/i915: Configure DPLL's for Cannonlake
DPLL's are defined in DPCLKA_CFGCR0 register (0x6C200). Let's use these
definitions when computing dpll's for ddi ports.
v2: (Rodrigo) Remove register that was defined in another patch with
fixed name and more bits.
Signed-off-by: Kahola, Mika <mika.kahola@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ander Conselvan de Oliveira <conselvan2@gmail.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-6-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:02 +0000 (15:26 -0700)]
drm/i915/cnl: DDI - PLL mapping
One of the steps for PLL (un)initialization is to (un)map
the correspondent DDI that is actually using that PLL.
So, let's do this step following the places already stablished
and used so far, although spec put this as part of PLL
initialization sequences.
v2: Use proper prefix on bits names as suggested by Ander.
v3: Add missed "~". Without that the logic was inverted
so we were disabling interrupts.
Credits-to: Clinton
Credits-to: Art
v4: Spec is getting updated to do DDI -> PLL mapping
and clock on in 2 separated reg writes. (Paulo)
Also update bits definitions to use space
(1 << 1) instead of (1<<1). (Paulo)
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Art Runyan <arthur.j.runyan@intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Kahola, Mika <mika.kahola@intel.com>
Cc: Ander Conselvan De Oliveira <ander.conselvan.de.oliveira@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Kahola, Mika <mika.kahola@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-5-git-send-email-rodrigo.vivi@intel.com
Rodrigo Vivi [Fri, 9 Jun 2017 22:26:01 +0000 (15:26 -0700)]
drm/i915/cnl: Allow dynamic cdclk changes on CNL
All the low level cdclk bits are present, so let's add the required
hooks to reconfigure cdclk on the fly.
Cannonlake also needs to adjust the minimal pixel rate
as gen9 platforms. Specially for the Azalia audio case.
v2: Rebase due to cnl_sanitize_cdclk()
v3: Rebased by Rodrigo on top of Ville's cdclk rework.
v4: Rebase moving cnl_calc_cdclk up to follow same order
as previous platforms.
v2: Squash drm/i915/cnl: Adjust min pixel rate. to address
the current limitation where CDCLK cannot be set to 168MHz
if audio is used with 96MHz. (Imre)
v3: adjust some of the clock limits within
bdw_adjust_min_pipe_pixel_rate. (Ville/DK/Imre).
Fix commit message messed by squash.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Sanyog Kale <sanyog.r.kale@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-4-git-send-email-rodrigo.vivi@intel.com
Ville Syrjälä [Fri, 9 Jun 2017 22:26:00 +0000 (15:26 -0700)]
drm/i915/cnl: Implement CNL display init/unit sequence
Implement the CNL display init/uninit sequence as outlined in Bspec.
Quite similar to SKL/BXT. The main complicaiton is probably the extra
procmon setup we must do based on the process/voltage information we
can read out from some register.
v2: s/skl_dbuf/gen9_dbuf/ to follow upstream
bxt needed a cdclk sanitize step, so let's add it for cnl too
v3: s/CHICKEN_MISC_1/CHICKEN_MISC_2/ (Ander)
v4: Rebased by Rodrigo after Ville's cdclk rework
v5: Removed unecessary Aux IO forced enable/disable, Fix DW10 setup
Fix procpon Mask. (Credits-to Paulo and Clint)
Remove A0 workaround.
v6: Rebased on top of recent code (Rodrigo).
v7: Respect the order of sanitize_ after set_
(Done by Rodrigo, Requested by Ville)
v8: Commit message updated to matvh v5 changes besides
Remove unused DW8 and an extra blank line. (all noticed
by Imre).
v9: Remove __attribute__((unused)) added on latest version
of drm/i915/cnl: Implement .set_cdclk() for CNL.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-3-git-send-email-rodrigo.vivi@intel.com
Ville Syrjälä [Fri, 9 Jun 2017 22:25:59 +0000 (15:25 -0700)]
drm/i915/cnl: Implement .set_cdclk() for CNL
Add support for changing the cdclk frequency on CNL. Again, quite
similar to BXT, but there are some annoying differences which means
trying to share more code might not be feasible:
* PLL ratio now lives in the PLL enable register
* pcode came from SKL, not from BXT
We support three cdclk frequencies: 168,336,528 Mhz. The first two
use the same PLL frequency, the last one uses a different one meaning
we once again may need to toggle the PLL off and on when changing
cdclk.
v2: Rebased by Rodrigo on top of Ville's cdclk rework.
v3: Respect order of set_ bellow get_ (Ville)
v4: Added __attribute__((unused)) to avoid broken compilation with Werror.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1497047175-27250-2-git-send-email-rodrigo.vivi@intel.com
projects / GitHub / LineageOS / android_kernel_motorola_exynos9610.git / log