Chris Wilson [Wed, 17 Apr 2019 13:25:07 +0000 (14:25 +0100)]
drm/i915: Avoid use-after-free in reporting create.size
We have to avoid chasing after a userspace race!
<3>[ 473.114328] BUG: KASAN: use-after-free in i915_gem_create+0x1d2/0x1f0 [i915]
<3>[ 473.114389] Read of size 8 at addr
ffff88815bf1d840 by task gem_flink_race/1541
<4>[ 473.114464] CPU: 1 PID: 1541 Comm: gem_flink_race Tainted: G U
5.1.0-rc4-g7d07e025e786-kasan_88+ #1
<4>[ 473.114469] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./J4205-ITX, BIOS P1.10 09/29/2016
<4>[ 473.114474] Call Trace:
<4>[ 473.114488] dump_stack+0x7c/0xbb
<4>[ 473.114612] ? i915_gem_create+0x1d2/0x1f0 [i915]
<4>[ 473.114621] print_address_description+0x65/0x270
<4>[ 473.114728] ? i915_gem_create+0x1d2/0x1f0 [i915]
<4>[ 473.114839] ? i915_gem_create+0x1d2/0x1f0 [i915]
<4>[ 473.114848] kasan_report+0x149/0x18d
<4>[ 473.114962] ? i915_gem_create+0x1d2/0x1f0 [i915]
<4>[ 473.115069] i915_gem_create+0x1d2/0x1f0 [i915]
<4>[ 473.115176] ? i915_gem_object_create.part.28+0x4b0/0x4b0 [i915]
<4>[ 473.115289] ? i915_gem_dumb_create+0x1a0/0x1a0 [i915]
<4>[ 473.115297] drm_ioctl_kernel+0x192/0x260
<4>[ 473.115306] ? drm_ioctl_permit+0x280/0x280
<4>[ 473.115326] drm_ioctl+0x67c/0x960
<4>[ 473.115438] ? i915_gem_dumb_create+0x1a0/0x1a0 [i915]
<4>[ 473.115448] ? drm_getstats+0x20/0x20
<4>[ 473.115459] ? __lock_acquire+0xa66/0x3fe0
<4>[ 473.115474] ? _raw_spin_unlock_irqrestore+0x39/0x60
<4>[ 473.115485] ? debug_object_active_state+0x2ea/0x4e0
<4>[ 473.115496] ? debug_show_all_locks+0x2d0/0x2d0
<4>[ 473.115513] do_vfs_ioctl+0x18d/0xfa0
<4>[ 473.115522] ? check_flags.part.27+0x440/0x440
<4>[ 473.115532] ? ioctl_preallocate+0x1a0/0x1a0
<4>[ 473.115547] ? __fget+0x2ac/0x410
<4>[ 473.115561] ? __ia32_sys_dup3+0xb0/0xb0
<4>[ 473.115569] ? rwlock_bug.part.0+0x90/0x90
<4>[ 473.115590] ksys_ioctl+0x35/0x70
<4>[ 473.115597] ? lockdep_hardirqs_off+0x1cb/0x2b0
<4>[ 473.115608] __x64_sys_ioctl+0x6a/0xb0
<4>[ 473.115614] ? lockdep_hardirqs_on+0x342/0x590
<4>[ 473.115623] do_syscall_64+0x97/0x400
<4>[ 473.115633] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 473.115641] RIP: 0033:0x7fce590d55d7
<4>[ 473.115649] Code: b3 66 90 48 8b 05 b1 48 2d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 81 48 2d 00 f7 d8 64 89 01 48
<4>[ 473.115655] RSP: 002b:
00007fce4d525ba8 EFLAGS:
00000246 ORIG_RAX:
0000000000000010
<4>[ 473.115662] RAX:
ffffffffffffffda RBX:
0000000000000000 RCX:
00007fce590d55d7
<4>[ 473.115667] RDX:
00007fce4d525c10 RSI:
00000000c010645b RDI:
0000000000000007
<4>[ 473.115672] RBP:
00007fce4d525c10 R08:
00007fce4d526700 R09:
00007fce4d526700
<4>[ 473.115677] R10:
0000000000000054 R11:
0000000000000246 R12:
00000000c010645b
<4>[ 473.115682] R13:
0000000000000007 R14:
0000000000000000 R15:
00007ffe0e4a7450
<3>[ 473.115731] Allocated by task 1541:
<4>[ 473.115766] kmem_cache_alloc+0xce/0x290
<4>[ 473.115895] i915_gem_object_create.part.28+0x1c/0x4b0 [i915]
<4>[ 473.116000] i915_gem_create+0xe3/0x1f0 [i915]
<4>[ 473.116008] drm_ioctl_kernel+0x192/0x260
<4>[ 473.116013] drm_ioctl+0x67c/0x960
<4>[ 473.116020] do_vfs_ioctl+0x18d/0xfa0
<4>[ 473.116026] ksys_ioctl+0x35/0x70
<4>[ 473.116032] __x64_sys_ioctl+0x6a/0xb0
<4>[ 473.116038] do_syscall_64+0x97/0x400
<4>[ 473.116044] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<3>[ 473.116071] Freed by task 1542:
<4>[ 473.116101] kmem_cache_free+0xb7/0x2f0
<4>[ 473.116205] __i915_gem_free_objects+0x7d4/0xe10 [i915]
<4>[ 473.116311] i915_gem_create_ioctl+0xaa/0xd0 [i915]
<4>[ 473.116318] drm_ioctl_kernel+0x192/0x260
<4>[ 473.116323] drm_ioctl+0x67c/0x960
<4>[ 473.116330] do_vfs_ioctl+0x18d/0xfa0
<4>[ 473.116335] ksys_ioctl+0x35/0x70
<4>[ 473.116341] __x64_sys_ioctl+0x6a/0xb0
<4>[ 473.116347] do_syscall_64+0x97/0x400
<4>[ 473.116354] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Testcase: igt/gem_flink_race/flink_close
Fixes: e163484afa8d ("drm/i915: Update size upon return from GEM_CREATE")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190417132507.27133-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 17 Apr 2019 07:56:29 +0000 (08:56 +0100)]
drm/i915: Make workaround verification *optional*
Sometimes the HW doesn't even play fair, and completely forgets about
register writes. Skip verifying known troublemakers.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108954
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: https://patchwork.freedesktop.org/patch/msgid/20190417075657.19456-4-chris@chris-wilson.co.uk
Chris Wilson [Wed, 17 Apr 2019 07:56:28 +0000 (08:56 +0100)]
drm/i915: Verify the engine workarounds stick on application
Read the engine workarounds back using the GPU after loading the initial
context state to verify that we are setting them correctly, and bail if
it fails.
v2: Break out the verification into its own loop
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: https://patchwork.freedesktop.org/patch/msgid/20190417075657.19456-3-chris@chris-wilson.co.uk
Chris Wilson [Wed, 17 Apr 2019 07:56:27 +0000 (08:56 +0100)]
drm/i915: Verify workarounds immediately after application
Immediately after writing the workaround, verify that it stuck in the
register.
References: https://bugs.freedesktop.org/show_bug.cgi?id=108954
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: https://patchwork.freedesktop.org/patch/msgid/20190417075657.19456-2-chris@chris-wilson.co.uk
Joonas Lahtinen [Wed, 17 Apr 2019 09:07:47 +0000 (12:07 +0300)]
drm/i915: Update DRIVER_DATE to
20190417
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Jani Nikula [Tue, 16 Apr 2019 08:28:52 +0000 (11:28 +0300)]
drm/i915/ehl: inherit icl cdclk init/uninit
The cdclk init/uninit code was changed by commit
93a643f29bcb
("drm/i915/cdclk: have only one init/uninit function") between the
versions of commit
39564ae86d51 ("drm/i915/ehl: Inherit Ice Lake
conditional code"). What got merged fails to do cdclk init/uninit on
ehl.
Fixes: 39564ae86d51 ("drm/i915/ehl: Inherit Ice Lake conditional code")
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Bob Paauwe <bob.j.paauwe@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416082852.18141-1-jani.nikula@intel.com
Chris Wilson [Fri, 12 Apr 2019 07:14:16 +0000 (08:14 +0100)]
drm/i915: Introduce struct class_instance for engines across the uAPI
SSEU reprogramming of the context introduced the notion of engine class
and instance for a forwards compatible method of describing any engine
beyond the old execbuf interface. We wish to adopt this class:instance
description for more interfaces, so pull it out into a separate type for
userspace convenience.
Fixes: e46c2e99f600 ("drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)")
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>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Cc: Andi Shyti <andi@etezian.org>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Tony Ye <tony.ye@intel.com>
Reviewed-by: Andi Shyti <andi@etezian.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190412071416.30097-1-chris@chris-wilson.co.uk
Paulo Zanoni [Wed, 10 Apr 2019 23:53:44 +0000 (16:53 -0700)]
drm/i915: fully convert the IRQ initialization macros to intel_uncore
Make them take the uncore argument from the caller instead of passing
the implicit &dev_priv->uncore directly. This will allow us to finally
pass something that's not dev_priv->uncore in the future, and gets rid
of the implicit variables in register macros.
v2: Rebase on top of the newer patches.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-6-paulo.r.zanoni@intel.com
Paulo Zanoni [Wed, 10 Apr 2019 23:53:43 +0000 (16:53 -0700)]
drm/i915: convert the IRQ initialization functions to intel_uncore
The IRQ initialization helpers are simple and self-contained. Continue
the transition started in the recent uncore rework to get us rid of
I915_READ/WRITE and the implicit dev_priv variables.
While the implicit dev_priv is removed from the IRQ initialization
helpers, we didn't get rid of them in the macro callers. Doing that
should be very simple now.
v2: Rebase on top of the new patches.
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-5-paulo.r.zanoni@intel.com
Paulo Zanoni [Wed, 10 Apr 2019 23:53:42 +0000 (16:53 -0700)]
drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers
This discussion started because we use token pasting in the
GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an
empty argument to those macros, making the code a little weird. The
original proposal was to just add a comment as the empty argument, but
Ville suggested we just add a prefix to the registers, and that indeed
sounds like a more elegant solution.
Now doing this is kinda against our rules for register naming since we
only add gens or platform names as register prefixes when the given
gen/platform changes a register that already existed before. On the
other hand, we have so many instances of IIR/IMR in comments that
adding a prefix would make the users of these register more easily
findable, in addition to make our token pasting macros actually
readable. So IMHO opening an exception here is worth it.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-4-paulo.r.zanoni@intel.com
Paulo Zanoni [Wed, 10 Apr 2019 23:53:41 +0000 (16:53 -0700)]
drm/i915: don't specify the IRQ register in the gen2 macros
Like the gen3+ macros, the gen2 versions of the IRQ initialization
macros take the register name in the 'type' argument. But gen2 only
has one set of registers, so there's really no need to specify the
type. This commit removes the type argument and uses the registers
directly instead of passing them through variables.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-3-paulo.r.zanoni@intel.com
Paulo Zanoni [Wed, 10 Apr 2019 23:53:40 +0000 (16:53 -0700)]
drm/i915: refactor the IRQ init/reset macros
The whole point of having macros here is for the token pasting
necessary to automatically have IMR, IIR and IER selected. We don't
really need or want all the inlining that happens as a consequence.
The good thing about the current code is that it works regardless of
the relative offsets between these registers (they change after gen4,
with the usual VLV/CHV exceptions).
One thing which we can do is to split the logic of what we do with
imr/ier/iir to functions separate from the macros that pick them.
That's what we do in this commit. This allows us to get rid of the
gen8 duplicates and also all the inlining:
add/remove: 2/0 grow/shrink: 0/21 up/down: 384/-5949 (-5565)
Function old new delta
gen3_irq_reset - 233 +233
gen3_irq_init - 151 +151
i8xx_irq_postinstall 459 442 -17
gen11_irq_postinstall 804 744 -60
ironlake_irq_postinstall 450 353 -97
vlv_display_irq_postinstall 348 245 -103
i965_irq_postinstall 378 272 -106
i915_irq_postinstall 333 227 -106
gen8_irq_power_well_post_enable 374 240 -134
ironlake_irq_reset 397 218 -179
vlv_display_irq_reset 616 433 -183
i965_irq_reset 374 180 -194
cherryview_irq_reset 379 185 -194
i915_irq_reset 407 209 -198
ibx_irq_reset 332 133 -199
gen5_gt_irq_postinstall 533 332 -201
gen8_irq_power_well_pre_disable 434 204 -230
gen8_gt_irq_postinstall 469 196 -273
gen8_de_irq_postinstall 1200 836 -364
gen5_gt_irq_reset 471 76 -395
gen8_gt_irq_reset 775 99 -676
gen8_irq_reset 1100 333 -767
gen11_irq_reset 1959 686 -1273
Total: Before=
2259222, After=
2253657, chg -0.25%
v2:
- Make checkpatch happy with a temporary which_ (Checkpatch).
- Reorder the arguments for the INIT macros (Ville).
- Correctly explain when the register offsets change in the commit
message (Ville).
- Use more line breaks in the macro calls to make the arguments look
a little more organized/readable.
- Update the bloat-o-meter output (minor change only).
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (v1)
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-2-paulo.r.zanoni@intel.com
Joonas Lahtinen [Tue, 16 Apr 2019 13:45:26 +0000 (16:45 +0300)]
Merge tag 'gvt-next-2019-04-16' of https://github.com/intel/gvt-linux into drm-intel-next-queued
gvt-next-2019-04-16
- Refine range of MCHBAR snapshot (Yakui)
- Refine out-of-sync page struct (Yakui)
- Remove unused vGPU sreg (Yan)
- Refind MMIO reg names (Xiaolin)
- Proper handling of sync/async flip (Colin)
- Proper handling of PIPE_CONTROL/MI_FLUSH_DW index mode (Xiaolin)
- EXCC reg mask fix (Colin)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190416084814.GH17995@zhen-hp.sh.intel.com
Chris Wilson [Fri, 12 Apr 2019 08:53:22 +0000 (09:53 +0100)]
drm/i915: Mark up ips for RCU protection
drivers/gpu/drm/i915/intel_pm.c:8352:9: error: incompatible types in comparison expression (different address spaces)
drivers/gpu/drm/i915/intel_pm.c:8359:9: error: incompatible types in comparison expression (different address spaces)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190412085410.10392-3-chris@chris-wilson.co.uk
Chris Wilson [Tue, 16 Apr 2019 08:52:18 +0000 (09:52 +0100)]
drm/i915: Drop bool return from breadcrumbs signaler
Since removal of the "missed interrupt detection" nobody used the result
of whether or not we signaled anybody during that invocation, so now
remove the return value.
References:
789659f4307a ("drm/i915: Drop fake breadcrumb irq")
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: https://patchwork.freedesktop.org/patch/msgid/20190416085218.431-1-chris@chris-wilson.co.uk
Colin Xu [Mon, 1 Apr 2019 06:13:53 +0000 (14:13 +0800)]
drm/i915/gvt: Fix incorrect mask of mmio 0x22028 in gen8/9 mmio list
According to GFX PRM on 01.org, bit 31:16 of mmio 0x22028 should be masks.
Fixes: 178657139307 ("drm/i915/gvt: vGPU context switch")
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Xiaolin Zhang [Wed, 3 Apr 2019 08:28:04 +0000 (16:28 +0800)]
drm/i915/gvt: addressed guest GPU hang with HWS index mode
with the introduce of "switch to use HWS indices rather than address",
guest GPU hang observed when running workloads which will update the
seqno to the real HW HWSP, not vitural GPU HWSP and then cause GPU hang.
this patch is to revoke index mode in PIPE_CTRL and MI_FLUSH_DW and
patch guest GPU HWSP address value to these commands.
Fixes: 54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than addresses")
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Xiaolin Zhang <xiaolin.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Zhenyu Wang [Tue, 16 Apr 2019 08:50:34 +0000 (16:50 +0800)]
Merge tag 'drm-intel-next-2019-04-04' into gvt-next
Merge back drm-intel-next for engine name definition refinement
and
54939ea0bd85 ("drm/i915: Switch to use HWS indices rather than addresses")
that would need gvt fixes to depend on.
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Manasi Navare [Mon, 15 Apr 2019 18:22:10 +0000 (11:22 -0700)]
drm/i915: Nuke drm_crtc_state and use intel_atomic_state instead
This is one of the patches to start replacing drm pointers
and use the intel_atomic_state and intel_crtc to derive
the necessary intel state variables required for the intel
modeset functions.
v3:
* Remove the unwanted newline (Ville)
v2:
* Flip the function arguments (Ville)
* Remove some remaining instances of drm pointers (Ville)
* Use old_crtc_state and new_crtc_state (Ville)
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190415182210.13347-1-manasi.d.navare@intel.com
Chris Wilson [Sat, 13 Apr 2019 12:58:20 +0000 (13:58 +0100)]
drm/i915/selftests: Skip live timeline/suspend tests if wedged
If the driver is wedged, we can not issue the requests to exercise the
timelines or the system across suspend, so skip the tests. live_hangcheck
is there to fail if we cannot recover.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190413125820.14112-4-chris@chris-wilson.co.uk
Chris Wilson [Fri, 12 Apr 2019 20:24:57 +0000 (21:24 +0100)]
drm/i915: Teach intel_workarounds to use uncore mmio access
Start weaning ourselves off the implicit I915_WRITE macro madness and
start using the explicit intel_uncore mmio access.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190412202458.10653-1-chris@chris-wilson.co.uk
Bob Paauwe [Fri, 12 Apr 2019 18:09:20 +0000 (11:09 -0700)]
drm/i915/ehl: Inherit Ice Lake conditional code
Most of the conditional code for ICELAKE also applies to ELKHARTLAKE
so use IS_GEN(dev_priv, 11) even for PM and Workarounds for now.
v2: - Rename commit (Jose)
- Include a wm workaround (Jose and Lucas)
- Include display core init (Jose and Lucas)
v3: Add a missing case of gen greater-than 11 (Jose)
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Bob Paauwe <bob.j.paauwe@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190412180920.22347-1-rodrigo.vivi@intel.com
Mika Kuoppala [Fri, 12 Apr 2019 16:53:53 +0000 (19:53 +0300)]
drm/i915: Handle catastrophic error on engine reset
If cat error is set, we need to clear it by acking it. Further,
if it is set, we must not do a normal request for reset.
v2: avoid goto (Chris)
v3: comment, error format, direct assign (Chris)
Bspec: 12567
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190412165353.16432-1-mika.kuoppala@linux.intel.com
Mika Kuoppala [Fri, 12 Apr 2019 16:53:35 +0000 (19:53 +0300)]
drm/i915: Shortcut readiness to reset check
If the engine says it is ready for reset, it is ready
so avoid further dancing and proceed.
v2: reg (Chris)
v3: request, ack, mask from following patch (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190412165335.16347-1-mika.kuoppala@linux.intel.com
Ville Syrjälä [Thu, 11 Apr 2019 14:33:49 +0000 (17:33 +0300)]
drm/i915: Suppress spurious combo PHY B warning
On ICL the DMC doesn't reinit combo PHY B so we should not warn
about its state being bogus during the display core uninit.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190411143349.17934-1-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com>
Ville Syrjälä [Thu, 11 Apr 2019 16:49:25 +0000 (19:49 +0300)]
drm/i915: Restore correct bxt_ddi_phy_calc_lane_lat_optim_mask() calculation
We are no longer calling bxt_ddi_phy_calc_lane_lat_optim_mask() when
intel{hdmi,dp}_compute_config() succeeds, and instead only call it
when those fail. This is fallout from the bool->int
.compute_config() conversion which failed to invert the return
value check before calling bxt_ddi_phy_calc_lane_lat_optim_mask().
Let's just replace it with an early bailout so that it's harder
to miss.
This restores the correct latency optim setting calculation
(which could fix some real failures), and avoids the
MISSING_CASE() from bxt_ddi_phy_calc_lane_lat_optim_mask()
after intel{hdmi,dp}_compute_config() has failed.
Cc: Lyude Paul <lyude@redhat.com>
Fixes: 204474a6b859 ("drm/i915: Pass down rc in intel_encoder->compute_config()")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109373
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190411164925.28491-1-ville.syrjala@linux.intel.com
Reviewed-by: Lyude Paul <lyude@redhat.com>
Chris Wilson [Fri, 12 Apr 2019 11:01:59 +0000 (12:01 +0100)]
drm/i915: Flush the CSB pointer reset
The HW resets it CSB tail pointer on resetting the engine. Most of the
time. In case it doesn't (and for system resume) we write the expected
value anyway. For extra paranoia, flush the write before we invalidate
the cacheline.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190412110159.10495-1-chris@chris-wilson.co.uk
Radhakrishna Sripada [Sat, 30 Mar 2019 01:19:20 +0000 (18:19 -0700)]
drm/i915: Fix the inconsistent RMW in WA 827
RMW is used only in the disable path. Using it in enable path
for consistency.
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190330011921.10397-2-radhakrishna.sripada@intel.com
Radhakrishna Sripada [Sat, 30 Mar 2019 01:19:19 +0000 (18:19 -0700)]
drm/i915: Rename skl_wa_clkgating to the actual WA
No functional change. Renaming the function to reflect the specific WA.
Suggested-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190330011921.10397-1-radhakrishna.sripada@intel.com
Ville Syrjälä [Tue, 26 Mar 2019 14:49:02 +0000 (16:49 +0200)]
drm/i915: Do not enable FEC without DSC
Currently we enable FEC even when DSC is no used. While that is
theoretically valid supposedly there isn't much of a benefit from
this. But more importantly we do not account for the FEC link
bandwidth overhead (2.4%) in the non-DSC link bandwidth computations.
So the code may think we have enough bandwidth when we in fact
do not.
Cc: stable@vger.kernel.org
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Fixes: 240999cf339f ("i915/dp/fec: Add fec_enable to the crtc state.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326144903.6617-1-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Chris Wilson [Tue, 9 Apr 2019 17:41:08 +0000 (18:41 +0100)]
drm/i915: Avoid reclaim taints from runtime-pm debug
As intel_runtime_pm_get/_put may be called from any blockable context,
we need to avoid allowing reclaim from our mallocs, as we need to
avoid tainting any mutexes held by the callers (as they may themselves
not allow for allocations as they are taken in the shrinker).
<4> [435.339331] WARNING: possible circular locking dependency detected
<4> [435.339364] 5.1.0-rc4-CI-Trybot_4116+ #1 Tainted: G U
<4> [435.339395] ------------------------------------------------------
<4> [435.339426] gem_caching/1334 is trying to acquire lock:
<4> [435.339456]
000000004505c39b (wakeref#3){+.+.}, at: intel_engine_pm_put+0x1b/0x40 [i915]
<4> [435.339788]
but task is already holding lock:
<4> [435.339819]
00000000ee77b4ed (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.24+0x0/0x30
<4> [435.339879]
which lock already depends on the new lock.
<4> [435.339918]
the existing dependency chain (in reverse order) is:
<4> [435.339952]
-> #1 (fs_reclaim){+.+.}:
<4> [435.339998] fs_reclaim_acquire.part.24+0x24/0x30
<4> [435.340035] kmem_cache_alloc_trace+0x2a/0x290
<4> [435.340311] __print_intel_runtime_pm_wakeref+0x24/0x160 [i915]
<4> [435.340590] untrack_intel_runtime_pm_wakeref+0x16e/0x1d0 [i915]
<4> [435.340869] intel_runtime_pm_put_unchecked+0xd/0x30 [i915]
<4> [435.341147] __intel_wakeref_put_once+0x22/0x40 [i915]
<4> [435.341508] i915_request_retire+0x477/0xaf0 [i915]
<4> [435.341871] ring_retire_requests+0x86/0x160 [i915]
<4> [435.342226] i915_retire_requests+0x58/0xc0 [i915]
<4> [435.342576] retire_work_handler+0x5b/0x70 [i915]
<4> [435.342615] process_one_work+0x245/0x610
<4> [435.342646] worker_thread+0x37/0x380
<4> [435.342679] kthread+0x119/0x130
<4> [435.342714] ret_from_fork+0x3a/0x50
<4> [435.342739]
-> #0 (wakeref#3){+.+.}:
<4> [435.342788] lock_acquire+0xa6/0x1c0
<4> [435.342822] __mutex_lock+0x8c/0x960
<4> [435.342853] atomic_dec_and_mutex_lock+0x33/0x50
<4> [435.343151] intel_engine_pm_put+0x1b/0x40 [i915]
<4> [435.343501] i915_request_retire+0x477/0xaf0 [i915]
<4> [435.343851] ring_retire_requests+0x86/0x160 [i915]
<4> [435.344202] i915_retire_requests+0x58/0xc0 [i915]
<4> [435.344543] i915_gem_shrink+0xd8/0x5b0 [i915]
<4> [435.344835] i915_drop_caches_set+0x17b/0x250 [i915]
<4> [435.344877] simple_attr_write+0xb0/0xd0
<4> [435.344911] full_proxy_write+0x51/0x80
<4> [435.344943] vfs_write+0xbd/0x1b0
<4> [435.344972] ksys_write+0x55/0xe0
<4> [435.345002] do_syscall_64+0x55/0x190
<4> [435.345040] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409174108.19396-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 11 Apr 2019 13:05:15 +0000 (14:05 +0100)]
drm/i915/execlists: Always reset the context's RING registers
During reset, we try and stop the active ring. This has the consequence
that we often clobber the RING registers within the context image. When
we find an active request, we update the context image to rerun that
request (if it was guilty, we replace the hanging user payload with
NOPs). However, we were ignoring an active context if the request had
completed, with the consequence that the next submission on that request
would start with RING_HEAD==0 and not the tail of the previous request,
causing all requests still in the ring to be rerun. Rare, but
occasionally seen within CI where we would spot that the context seqno
would reverse and complain that we were retiring an incomplete request.
<0> [412.390350] <idle>-0 3d.s2 408373352us : __i915_request_submit: rcs0 fence 1e95b:3640 -> current 3638
<0> [412.390350] <idle>-0 3d.s2 408373353us : __i915_request_submit: rcs0 fence 1e95b:3642 -> current 3638
<0> [412.390350] <idle>-0 3d.s2 408373354us : __i915_request_submit: rcs0 fence 1e95b:3644 -> current 3638
<0> [412.390350] <idle>-0 3d.s2 408373354us : __i915_request_submit: rcs0 fence 1e95b:3646 -> current 3638
<0> [412.390350] <idle>-0 3d.s2 408373356us : __execlists_submission_tasklet: rcs0 in[0]: ctx=2.1, fence 1e95b:3646 (current 3638), prio=4
<0> [412.390350] i915_sel-4613 0.... 408373374us : __i915_request_commit: rcs0 fence 1e95b:3648
<0> [412.390350] i915_sel-4613 0d..1 408373377us : process_csb: rcs0 cs-irq head=2, tail=3
<0> [412.390350] i915_sel-4613 0d..1 408373377us : process_csb: rcs0 csb[3]: status=0x00000001:0x00000000, active=0x1
<0> [412.390350] i915_sel-4613 0d..1 408373378us : __i915_request_submit: rcs0 fence 1e95b:3648 -> current 3638
<0> [412.390350] <idle>-0 3..s1 408373378us : execlists_submission_tasklet: rcs0 awake?=1, active=5
<0> [412.390350] i915_sel-4613 0d..1 408373379us : __execlists_submission_tasklet: rcs0 in[0]: ctx=2.2, fence 1e95b:3648 (current 3638), prio=4
<0> [412.390350] i915_sel-4613 0.... 408373381us : i915_reset_engine: rcs0 flags=4
<0> [412.390350] i915_sel-4613 0.... 408373382us : execlists_reset_prepare: rcs0: depth<-0
<0> [412.390350] <idle>-0 3d.s2 408373390us : process_csb: rcs0 cs-irq head=3, tail=4
<0> [412.390350] <idle>-0 3d.s2 408373390us : process_csb: rcs0 csb[4]: status=0x00008002:0x00000002, active=0x1
<0> [412.390350] <idle>-0 3d.s2 408373390us : process_csb: rcs0 out[0]: ctx=2.2, fence 1e95b:3648 (current 3640), prio=4
<0> [412.390350] i915_sel-4613 0.... 408373401us : intel_engine_stop_cs: rcs0
<0> [412.390350] i915_sel-4613 0d..1 408373402us : process_csb: rcs0 cs-irq head=4, tail=4
<0> [412.390350] i915_sel-4613 0.... 408373403us : intel_gpu_reset: engine_mask=1
<0> [412.390350] i915_sel-4613 0d..1 408373408us : execlists_cancel_port_requests: rcs0:port0 fence 1e95b:3648, (current 3648)
<0> [412.390350] i915_sel-4613 0.... 408373442us : intel_engine_cancel_stop_cs: rcs0
<0> [412.390350] i915_sel-4613 0.... 408373442us : execlists_reset_finish: rcs0: depth->0
<0> [412.390350] ksoftirq-26 3..s. 408373442us : execlists_submission_tasklet: rcs0 awake?=1, active=0
<0> [412.390350] ksoftirq-26 3d.s1 408373443us : process_csb: rcs0 cs-irq head=5, tail=5
<0> [412.390350] i915_sel-4613 0.... 408373475us : i915_request_retire: rcs0 fence 1e95b:3640, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373476us : i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3640, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373494us : __i915_request_commit: rcs0 fence 1e95b:3650
<0> [412.390350] i915_sel-4613 0d..1 408373496us : process_csb: rcs0 cs-irq head=5, tail=5
<0> [412.390350] i915_sel-4613 0d..1 408373496us : __i915_request_submit: rcs0 fence 1e95b:3650 -> current 3648
<0> [412.390350] i915_sel-4613 0d..1 408373498us : __execlists_submission_tasklet: rcs0 in[0]: ctx=2.1, fence 1e95b:3650 (current 3648), prio=6
<0> [412.390350] i915_sel-4613 0.... 408373500us : i915_request_retire_upto: rcs0 fence 1e95b:3648, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373500us : i915_request_retire: rcs0 fence 1e95b:3642, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373501us : i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3642, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373514us : i915_request_retire: rcs0 fence 1e95b:3644, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373515us : i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3644, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373527us : i915_request_retire: rcs0 fence 1e95b:3646, current 3640
<0> [412.390350] <idle>-0 3..s1 408373569us : execlists_submission_tasklet: rcs0 awake?=1, active=1
<0> [412.390350] <idle>-0 3d.s2 408373569us : process_csb: rcs0 cs-irq head=5, tail=1
<0> [412.390350] <idle>-0 3d.s2 408373570us : process_csb: rcs0 csb[0]: status=0x00000001:0x00000000, active=0x1
<0> [412.390350] <idle>-0 3d.s2 408373570us : process_csb: rcs0 csb[1]: status=0x00000018:0x00000002, active=0x5
<0> [412.390350] <idle>-0 3d.s2 408373570us : process_csb: rcs0 out[0]: ctx=2.1, fence 1e95b:3650 (current 3650), prio=6
<0> [412.390350] <idle>-0 3d.s2 408373571us : process_csb: rcs0 completed ctx=2
<0> [412.390350] i915_sel-4613 0.... 408373621us : i915_request_retire: i915_request_retire:253 GEM_BUG_ON(!i915_request_completed(request))
v2: Fixup the cancellation path to drain the CSB and reset the pointers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190411130515.20716-2-chris@chris-wilson.co.uk
Chris Wilson [Thu, 11 Apr 2019 13:05:14 +0000 (14:05 +0100)]
drm/i915/guc: Implement reset locally
Before causing guc and execlists to diverge further (breaking guc in the
process), take a copy of the current reset procedure and make it local to
the guc submission backend
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190411130515.20716-1-chris@chris-wilson.co.uk
Mika Kuoppala [Thu, 11 Apr 2019 08:30:34 +0000 (11:30 +0300)]
drm/i915: Disable read only ppgtt support for gen11
On gen11 writing to read only ppgtt page causes a gpu hang.
This behaviour is different than with previous gen where
read only ppgtt access is supported. On those, the write
is just dropped without visible side effects.
Disable ro ppgtt support on gen11 until a solution can
be found to bring it into line with its predecessors.
References: HSDES#
1807136187
References: https://bugzilla.freedesktop.org/show_bug.cgi?id=108569
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190411083034.28311-1-mika.kuoppala@linux.intel.com
Chris Wilson [Thu, 11 Apr 2019 12:24:45 +0000 (13:24 +0100)]
drm/i915: Call i915_sw_fence_fini on request cleanup
As i915_requests are put into an RCU-freelist, they may get reused
before debugobjects notice them as being freed. On cleanup, explicitly
call i915_sw_fence_fini() so that the debugobject is properly tracked.
Reported-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Fixes: b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of busywaits")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190411122445.20060-1-chris@chris-wilson.co.uk
Ville Syrjälä [Tue, 26 Mar 2019 14:49:03 +0000 (16:49 +0200)]
drm/i915: Clean up DSC vs. not bpp handling
No point in duplicating all this code when we can just
use a variable to hold the output bpp (the only thing
that differs between the two branches).
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.comk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326144903.6617-2-ville.syrjala@linux.intel.com
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Ville Syrjälä [Tue, 26 Mar 2019 14:25:56 +0000 (16:25 +0200)]
drm/i915: Set DP min_bpp to 8*3 for non-RGB output formats
6bpc is only legal for RGB and RAW pixel encodings. For the rest
the minimum is 8bpc. Set our lower limit accordingly.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190326142556.21176-6-ville.syrjala@linux.intel.com
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Mika Kuoppala [Fri, 5 Apr 2019 20:46:57 +0000 (21:46 +0100)]
drm/i915/icl: Switch to using 12 deep CSB status FIFO
Now when we can support variable csb fifo sizes, disable legacy mode.
By disabling legacy we hope to get better hw testing coverage by
assuming everyone else have switched over.
v2: rebase
References: https://bugs.freedesktop.org/show_bug.cgi?id=110338
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Kelvin Gardiner <kelvin.gardiner@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405204657.12887-2-chris@chris-wilson.co.uk
Mika Kuoppala [Fri, 5 Apr 2019 20:46:56 +0000 (21:46 +0100)]
drm/i915: Prepare for larger CSB status FIFO size
Make csb entry count variable in preparation for larger
CSB status FIFO size found on gen11+ hardware.
v2: adapt to hwsp access only (Chris)
non continuous mmio (Daniele)
v3: entries (Chris), fix macro for checkpatch
v4: num_entries (Chris)
v5: consistency on num_entries
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405204657.12887-1-chris@chris-wilson.co.uk
Mika Kuoppala [Wed, 10 Apr 2019 10:59:22 +0000 (13:59 +0300)]
drm/i915: Use Engine1 instance for gen11 pm interrupts
With gen11 the interrupt registers are shared between 2 engines,
with Engine1 instance being upper word and Engine0 instance being
lower. Annoyingly gen11 selected the pm interrupts to be in the
Engine1 instance.
Rectify the situation by shifting the access accordingly,
based on gen.
v2: comments, warn on overzealous rps_events
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=108059
Testcase: igt/i915_pm_rps@min-max-config-loaded
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410105923.18546-6-mika.kuoppala@linux.intel.com
Mika Kuoppala [Wed, 10 Apr 2019 13:24:36 +0000 (16:24 +0300)]
drm/i915/icl: Disable video turbo mode for rp control
There is no video turbo mode for gen11, so don't set it.
v2: inline (Chris)
v3: brackets (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410132436.23679-1-mika.kuoppala@linux.intel.com
Mika Kuoppala [Wed, 10 Apr 2019 10:59:19 +0000 (13:59 +0300)]
drm/i915/icl: Enable media sampler powergate
Enable media sampler powergate as recommended.
v2: use REG_BIT (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410105923.18546-3-mika.kuoppala@linux.intel.com
Mika Kuoppala [Wed, 10 Apr 2019 10:59:18 +0000 (13:59 +0300)]
drm/i915/icl: Apply a recommended rc6 threshold
On gen11 the recommended rc6 threshold differs from previous
gens, apply it. Move the write to a correct spot in sequence.
v2: do write in 2b, fix bspec ref (Michal)
Bspec: 33149
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410105923.18546-2-mika.kuoppala@linux.intel.com
Mika Kuoppala [Wed, 10 Apr 2019 10:59:17 +0000 (13:59 +0300)]
drm/i915: Use dedicated rc6 enabling sequence for gen11
In order not to inflate gen9 rc6 enabling sequence with
gen11 specifics, use a separate function for it.
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410105923.18546-1-mika.kuoppala@linux.intel.com
Chris Wilson [Tue, 9 Apr 2019 15:29:22 +0000 (16:29 +0100)]
drm/i915: Bump ready tasks ahead of busywaits
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Dmitry Ermilov <dmitry.ermilov@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190409152922.23894-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 10 Apr 2019 19:01:20 +0000 (20:01 +0100)]
drm/i915: Only reset the pinned kernel contexts on resume
On resume, we know that the only pinned contexts in danger of seeing
corruption are the kernel context, and so we do not need to walk the
list of all GEM contexts as we tracked them on each engine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410190120.830-1-chris@chris-wilson.co.uk
Manasi Navare [Fri, 5 Apr 2019 22:48:21 +0000 (15:48 -0700)]
drm/i915/dp: Expose force_dsc_enable through debugfs
Currently we use force_dsc_enable to force DSC from IGT, but
we dont expose this value to userspace through debugfs.
This patch exposes this through the same dsc_fec_support
debugfs node per connector so that we can restore its value
back after the tests are completed.
Suggested-by: Imre Deak <imre.deak@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Lyude Paul <lyude@redhat.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405224821.32435-1-manasi.d.navare@intel.com
Mika Kuoppala [Wed, 10 Apr 2019 13:21:24 +0000 (16:21 +0300)]
drm/i915/icl: Don't warn on spurious interrupts
There is a chance we can see spurious interrupts in live
now. We have more engines enabled and that with more elaborate
access patterns with pm and display, increases the chances
hardware just makes a social call, without anything to work on.
Remove the error as we have tests to actually probe if
we really miss interrupt, instead of getting spurious ones.
Note that now we do write to intr_dw even with a zero
value. This is considered advantegous as the write
is an ack that sw is done.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410132124.21795-2-mika.kuoppala@linux.intel.com
Mika Kuoppala [Wed, 10 Apr 2019 13:21:23 +0000 (16:21 +0300)]
drm/i915/icl: Handle rps interrupts without irq lock
Unlike previous gens, we already hold the irq_lock on
entering the rps handler so we can't use it as it is.
Make a gen11 specific rps interrupt handler without
locking.
v2: return early (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410132124.21795-1-mika.kuoppala@linux.intel.com
Takashi Iwai [Wed, 10 Apr 2019 11:03:22 +0000 (13:03 +0200)]
ALSA: hda: Fix racy display power access
snd_hdac_display_power() doesn't handle the concurrent calls carefully
enough, and it may lead to the doubly get_power or put_power calls,
when a runtime PM and an async work get called in racy way.
This patch addresses it by reusing the bus->lock mutex that has been
used for protecting the link state change in ext bus code, so that it
can protect against racy display state changes. The initialization of
bus->lock was moved from snd_hdac_ext_bus_init() to
snd_hdac_bus_init() as well accordingly.
Testcase: igt/i915_pm_rpm/module-reload #glk-dsi
Reported-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/s5h8swiunph.wl-tiwai@suse.de
Jani Nikula [Fri, 5 Apr 2019 07:52:20 +0000 (10:52 +0300)]
drm/i915/dp: revert back to max link rate and lane count on eDP
Commit
7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
and narrow") started to optize the eDP 1.4+ link config, both per spec
and as preparation for display stream compression support.
Sadly, we again face panels that flat out fail with parameters they
claim to support. Revert, and go back to the drawing board.
v2: Actually revert to max params instead of just wide-and-slow.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
Fixes: 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow")
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Matt Atwood <matthew.s.atwood@intel.com>
Cc: "Lee, Shawn C" <shawn.c.lee@intel.com>
Cc: Dave Airlie <airlied@gmail.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v5.0+
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Tested-by: Albert Astals Cid <aacid@kde.org> # v5.0 backport
Tested-by: Emanuele Panigati <ilpanich@gmail.com> # v5.0 backport
Tested-by: Matteo Iervasi <matteoiervasi@gmail.com> # v5.0 backport
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405075220.9815-1-jani.nikula@intel.com
Vandita Kulkarni [Mon, 25 Mar 2019 11:26:42 +0000 (16:56 +0530)]
drm/i915/icl: Fix port disable sequence for mipi-dsi
Re-enable clock gating of DDI clocks.
v2: Fix the default ddi clk state for mipi-dsi (Imre)
Fixes: 1026bea00381 ("drm/i915/icl: Ungate DSI clocks")
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1553513202-13863-2-git-send-email-vandita.kulkarni@intel.com
Vandita Kulkarni [Mon, 25 Mar 2019 11:26:41 +0000 (16:56 +0530)]
drm/i915/icl: Ungate ddi clocks before IO enable
IO enable sequencing needs ddi clocks enabled.
These clocks will be gated at a later point in
the enable sequence.
v2: Fix the commit header (Uma)
v3: Remove the redundant read (Ville)
Fixes: 949fc52af19e ("drm/i915/icl: add pll mapping for DSI")
Signed-off-by: Vandita Kulkarni <vandita.kulkarni@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1553513202-13863-1-git-send-email-vandita.kulkarni@intel.com
Chris Wilson [Mon, 8 Apr 2019 09:17:14 +0000 (10:17 +0100)]
drm/i915/guc: Replace preempt_client lookup with engine->preempt_context
Circumvent the dance we currently perform to find the preempt_client and
lookup its HW context for this engine, as we know we have already pinned
the preempt_context on the engine.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190408091728.20207-15-chris@chris-wilson.co.uk
Chris Wilson [Sun, 7 Apr 2019 19:26:49 +0000 (20:26 +0100)]
drm/i915/selftests: Mark live_forcewake_ops as unreliable
A couple of machines in the farm show quite frequent errors in the
powerwells not being released. Either there is an external agent
interferring with the powerwells, or the powerwell doesn't quite behave
as we anticipate -- either way, the test is not reliable enough to be
enabled by default in CI. It has served its immediate purpose in
providing coverage as we made tweaks to forcewake, so keep it available
for future testing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110210
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190407192649.14750-1-chris@chris-wilson.co.uk
José Roberto de Souza [Sat, 6 Apr 2019 00:51:12 +0000 (17:51 -0700)]
drm/i915/psr: Do not enable PSR in interlaced mode for all GENs
This interlaced mode restriction applies to all gens, not only to
Haswell.
Also while at it updating the debug message to.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-4-jose.souza@intel.com
José Roberto de Souza [Sat, 6 Apr 2019 00:51:11 +0000 (17:51 -0700)]
drm/i915/psr: Initialize PSR mutex even when sink is not reliable
Even when driver is reloaded and hits this scenario the PSR mutex
should be initialized, otherwise reading PSR debugfs status will
execute mutex_lock() over a mutex that was not initialized.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-3-jose.souza@intel.com
José Roberto de Souza [Sat, 6 Apr 2019 00:51:10 +0000 (17:51 -0700)]
drm/i915: Remove unused VLV/CHV PSR registers
PSR support for VLV and CHV was dropped in commit
ce3508fd2a77
("drm/i915/psr: Nuke PSR support for VLV and CHV") so no need to keep
this registers around.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-2-jose.souza@intel.com
José Roberto de Souza [Sat, 6 Apr 2019 00:51:09 +0000 (17:51 -0700)]
drm/i915/psr: Update PSR2 SU corruption workaround comment
Turn out it is not a DMC bug it is actually a HW one, so this
workaround will be needed for current gens, lets update the comment
and remove the FIXME.
BSpec: 7723
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406005112.27205-1-jose.souza@intel.com
Chris Wilson [Mon, 8 Apr 2019 09:17:03 +0000 (10:17 +0100)]
drm/i915: Consolidate the timeline->barrier
The timeline is strictly ordered, so by inserting the timeline->barrier
request into the timeline->last_request it naturally provides the same
barrier. Consolidate the pair of barriers into one as they serve the
same purpose.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190408091728.20207-4-chris@chris-wilson.co.uk
Chris Wilson [Mon, 8 Apr 2019 09:17:02 +0000 (10:17 +0100)]
drm/i915: Use static allocation for i915_globals_park()
In order to avoid the malloc inside i915_globals_park() occurring
underneath a lock connected to the shrinker (thus causing circular
lockdeps warnings), move the rcu_worker to a global.
<4> [39.085073] ======================================================
<4> [39.085273] WARNING: possible circular locking dependency detected
<4> [39.085552] 5.1.0-rc3-CI-Trybot_4088+ #1 Tainted: G U
<4> [39.085752] ------------------------------------------------------
<4> [39.085949] kswapd0/32 is trying to acquire lock:
<4> [39.086121]
00000000004b5f91 (wakeref#3){+.+.}, at: intel_engine_pm_put+0x1b/0x40 [i915]
<4> [39.086493]
but task is already holding lock:
<4> [39.086682]
00000000dd009a9a (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30
<4> [39.086910]
which lock already depends on the new lock.
<4> [39.087139]
the existing dependency chain (in reverse order) is:
<4> [39.087356]
-> #2 (fs_reclaim){+.+.}:
<4> [39.087604] fs_reclaim_acquire.part.24+0x24/0x30
<4> [39.087785] kmem_cache_alloc_trace+0x2a/0x290
<4> [39.087998] i915_globals_park+0x22/0xa0 [i915]
<4> [39.088478] idle_work_handler+0x1df/0x220 [i915]
<4> [39.089016] process_one_work+0x245/0x610
<4> [39.089447] worker_thread+0x37/0x380
<4> [39.089956] kthread+0x119/0x130
<4> [39.090374] ret_from_fork+0x3a/0x50
<4> [39.090868]
-> #1 (wakeref#4){+.+.}:
<4> [39.091569] __mutex_lock+0x8c/0x960
<4> [39.092054] atomic_dec_and_mutex_lock+0x33/0x50
<4> [39.092521] intel_gt_pm_put+0x1b/0x40 [i915]
<4> [39.093047] intel_engine_park+0xeb/0x1d0 [i915]
<4> [39.093514] __intel_wakeref_put_once+0x10/0x30 [i915]
<4> [39.094062] i915_request_retire+0x477/0xaf0 [i915]
<4> [39.094547] ring_retire_requests+0x86/0x160 [i915]
<4> [39.095110] i915_retire_requests+0x58/0xc0 [i915]
<4> [39.095587] i915_gem_wait_for_idle.part.22+0xb2/0xf0 [i915]
<4> [39.096142] switch_to_kernel_context_sync+0x2a/0x70 [i915]
<4> [39.096633] i915_gem_init+0x59c/0x9c0 [i915]
<4> [39.097174] i915_driver_load+0xd96/0x1880 [i915]
<4> [39.097640] i915_pci_probe+0x29/0xa0 [i915]
<4> [39.098145] pci_device_probe+0xa1/0x120
<4> [39.098607] really_probe+0xf3/0x3e0
<4> [39.099031] driver_probe_device+0x10a/0x120
<4> [39.099599] device_driver_attach+0x4b/0x50
<4> [39.100033] __driver_attach+0x97/0x130
<4> [39.100525] bus_for_each_dev+0x74/0xc0
<4> [39.100954] bus_add_driver+0x13f/0x210
<4> [39.101441] driver_register+0x56/0xe0
<4> [39.101891] do_one_initcall+0x58/0x2e0
<4> [39.102319] do_init_module+0x56/0x1ea
<4> [39.102805] load_module+0x2701/0x29e0
<4> [39.103231] __se_sys_finit_module+0xd3/0xf0
<4> [39.103727] do_syscall_64+0x55/0x190
<4> [39.104153] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [39.104736]
-> #0 (wakeref#3){+.+.}:
<4> [39.105437] lock_acquire+0xa6/0x1c0
<4> [39.105923] __mutex_lock+0x8c/0x960
<4> [39.106345] atomic_dec_and_mutex_lock+0x33/0x50
<4> [39.106897] intel_engine_pm_put+0x1b/0x40 [i915]
<4> [39.107375] i915_request_retire+0x477/0xaf0 [i915]
<4> [39.107930] ring_retire_requests+0x86/0x160 [i915]
<4> [39.108412] i915_retire_requests+0x58/0xc0 [i915]
<4> [39.108934] i915_gem_shrink+0xd8/0x5b0 [i915]
<4> [39.109431] i915_gem_shrinker_scan+0x59/0x130 [i915]
<4> [39.109884] do_shrink_slab+0x131/0x3e0
<4> [39.110380] shrink_slab+0x228/0x2c0
<4> [39.110810] shrink_node+0x177/0x460
<4> [39.111317] balance_pgdat+0x239/0x580
<4> [39.111743] kswapd+0x186/0x570
<4> [39.112221] kthread+0x119/0x130
<4> [39.112641] ret_from_fork+0x3a/0x50
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190408091728.20207-3-chris@chris-wilson.co.uk
Chris Wilson [Mon, 8 Apr 2019 09:17:01 +0000 (10:17 +0100)]
drm/i915/guc: Replace WARN with a DRM_ERROR
Replace the WARN with a simple if() + error message to squech the sparse
warning that entire wait_for() macro was being stringified:
drivers/gpu/drm/i915/intel_guc_submission.c:658:9: error: too long token expansion
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190408091728.20207-2-chris@chris-wilson.co.uk
Imre Deak [Fri, 5 Apr 2019 15:36:57 +0000 (18:36 +0300)]
drm/i915/icl: Simplify release of encoder power refs
We can unconditionally release the power references during encoder
disabling. The references for each port used by the encoder are
guaranteed to be enabled at this point.
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405153657.20921-2-imre.deak@intel.com
Imre Deak [Sun, 7 Apr 2019 12:46:55 +0000 (15:46 +0300)]
drm/i915: Get power refs in encoder->get_power_domains()
Push getting the reference for the encoders' power domains into the
encoder get_power_domains() hook instead of doing this from the caller.
This way the encoder can store away the corresponding wakerefs.
This fixes the DSI encoder disabling, which didn't release these
power references it acquired during HW state readout.
Note that longtime ownership for the corresponding wakerefs can be thus
acquired / released in two ways. Nevertheless there is always only one
owner for them:
After HW readout (booting/system resume):
- encoder->get_power_domains() acquires
- encoder->disable*() releases
After a modeset (calling intel_atomic_commit()):
- encoder->enable*() acquires
- encoder->disable*() releases
* can be any of the encoder enable/disable hooks.
v2:
- Check that the DSI io_wakerefs are unset both during encoder HW
readout and enabling. (Chris)
Fixes: 0e6e0be4c9523 ("drm/i915: Markup paired operations on display power domains")
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190407124655.31536-1-imre.deak@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:26 +0000 (14:00 +0300)]
drm/i915/cdclk: have only one init/uninit function
While transitioning to having better clarity between the modules, it's
desirable to have the function name prefixes reflect the
module. Functions in intel_foo.c should be prefixed intel_foo_.
Expose only one CDCLK init/uninit function from intel_cdclk.c instead of
one per platform. Obviously this adds one "unnecessary" if ladder within
the entry points. However it should be considered more of a CDCLK
implementation detail how this is done per platform, instead of exposing
the fact. In other words, abstract the CDCLK module better.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f63ed6e129098a32c63735be6cffa4756e7947af.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:25 +0000 (14:00 +0300)]
drm/i915: extract intel_cdclk.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c128d7be3f621391e571e86b03f302f3ffd0ed2b.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:24 +0000 (14:00 +0300)]
drm/i915: extract intel_sprite.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/679c857a1933ee3d0706f978ab05ca880cd30a00.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:23 +0000 (14:00 +0300)]
drm/i915: extract intel_dvo.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1ccf9000ad33b895aea06be41053a5b7bac8459e.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:22 +0000 (14:00 +0300)]
drm/i915: extract intel_lvds.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/5d54d02cf7b7bfe3f78ed60d28534c5726371af3.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:21 +0000 (14:00 +0300)]
drm/i915: extract intel_tv.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f44c21e3d154e47233ebef4267ce1a924fa38df7.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:20 +0000 (14:00 +0300)]
drm/i915: extract intel_pipe_crc.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b106b21ef11ff7fc34537b2c029a1332c8573fcc.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:19 +0000 (14:00 +0300)]
drm/i915: extract intel_atomic_plane.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: revert intel_plane_destroy_state() movement within intel_atomic_plane.c
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fd56c1cbba22b9f195ad944d79f7977423b2b533.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:18 +0000 (14:00 +0300)]
drm/i915: extract intel_hdmi.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/357856c31e309f0af8eed0d800623a5253ff3a37.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:17 +0000 (14:00 +0300)]
drm/i915: extract intel_dp.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/f86f9beed730eaad0bdcc18b18817b3d221e16e2.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:16 +0000 (14:00 +0300)]
drm/i915: extract intel_fbdev.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/82d11bf634094f44a7469a096de3d3768314d6bc.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:15 +0000 (14:00 +0300)]
drm/i915: extract intel_pm.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: gen6_rps_reset_ei() is in i915_irq.c not intel_pm.c.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/adc6463b95eef3440fba9826793f7d1c5f3b0b4a.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:14 +0000 (14:00 +0300)]
drm/i915: extract intel_panel.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c9f02ae09123866bc55269175ab75e844ffbd6ac.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:13 +0000 (14:00 +0300)]
drm/i915: extract intel_hdcp.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/8348620b32cb4438ccfb5f7bbe9a18ff6b7c48a0.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:12 +0000 (14:00 +0300)]
drm/i915: extract intel_sdvo.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c507e15fef019541da5bb33f2fbe920a5ad2f3dc.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:11 +0000 (14:00 +0300)]
drm/i915: extract intel_lspcon.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/b01cae3b5307d31c34de2321d6d2913f1cc39a12.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:10 +0000 (14:00 +0300)]
drm/i915: extract intel_color.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/fe5928586b4ca538cc4bc99212c5b699e891c75e.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:09 +0000 (14:00 +0300)]
drm/i915: extract intel_psr.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: Fix checkpatch whitespace complaint
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/7e776690bf139ccdd0306b30df08dc68e74603de.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:08 +0000 (14:00 +0300)]
drm/i915: extract intel_fbc.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: Remove stray newline (Chris)
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/db44ba199c86f24bfa9e490531eddf51cccd89da.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:07 +0000 (14:00 +0300)]
drm/i915: extract intel_csr.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: Add function argument names to fix checkpatch warning
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/44ceebca0206de9c40dc6794b660d84b8994f700.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:06 +0000 (14:00 +0300)]
drm/i915: extract intel_connector.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/4b8e9d1fa8f0f0420ecc65063bdb7d068c13086e.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:05 +0000 (14:00 +0300)]
drm/i915: extract intel_ddi.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/61d159117475a48a5db7bd7d652c198d4fa08d7b.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:04 +0000 (14:00 +0300)]
drm/i915: extract intel_crt.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/19c39bfcfb82f50c77382e8dea4fe1ad6cd043ed.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:03 +0000 (14:00 +0300)]
drm/i915: extract intel_audio.h from intel_drv.h
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/e0284c4d62effa5bad72ce034206c26e3aa02884.1554461791.git.jani.nikula@intel.com
Jani Nikula [Fri, 5 Apr 2019 11:00:02 +0000 (14:00 +0300)]
drm/i915: make intel_frontbuffer.h self-contained
This will be helpful in the follow-up work. No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/9a19d43987006e4249b335f3d843da43c998376c.1554461791.git.jani.nikula@intel.com
Ville Syrjälä [Fri, 5 Apr 2019 14:13:49 +0000 (17:13 +0300)]
drm/i915: Fix pipe_bpp readout for BXT/GLK DSI
The only bpc information in pipe registers for BXT/GLK DSI
is the PIPEMISC dither bpc. Let's try to use that to read
out pipe_bpp on these platforms. However, I'm not sure if
this will be correctly populated by the GOP since bspec
suggests it's only needed if dithering is actually enabled.
If not I guess we'll have to go one step further and
extract pipe_bpp from the DSI pixel format when dithering
is disabled.
Cc: Hans de Goede <hdegoede@redhat.com>
Fixes: ca0b04db14a5 ("drm/i915/dsi: Fix pipe_bpp for handling for 6 bpc pixel-formats")
References: https://bugs.freedesktop.org/show_bug.cgi?id=109516
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405141349.11950-1-ville.syrjala@linux.intel.com
Chris Wilson [Sat, 6 Apr 2019 08:03:41 +0000 (09:03 +0100)]
drm/i915: Track the temporary wakerefs used for hsw_get_pipe_config
Haswell+ require many power wells to probe the current HW display state.
Under the wakeref tracking scheme, we want each owner to store and
release the wakeref they use, so we can identify callers that have
leaked their wakeref. For hsw_get_pipe_config, this means we have to
keep the array of all wakerefs as it current acquires its power wells
piecemeal and releases them en masse.
By tracking these wakerefs, we should be able to eliminate a lot of
noise from the runtime-pm debug logs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406080341.2654-1-chris@chris-wilson.co.uk
Janusz Krzysztofik [Sat, 6 Apr 2019 10:40:34 +0000 (11:40 +0100)]
drm/i915: Mark GEM wedged right after marking device unplugged
As soon as a device is considered unplugged, not only prevent pending
users from accessing the device structures but also cancel all their
pending requests so all consumed resources can be cleaned up as soon
as possible.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20190406104034.31380-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 5 Apr 2019 20:24:19 +0000 (21:24 +0100)]
drm/i915: Convert i915_reset.c over to using uncore mmio
Currently i915_reset.c mixes calls to intel_uncore, pci and our old
style I915_READ mmio interfaces. Cast aside the old implicit macros,
and harmonise on using uncore throughout.
add/remove: 1/1 grow/shrink: 0/4 up/down: 65/-207 (-142)
Function old new delta
rmw_register - 65 +65
gen8_reset_engines 945 942 -3
g4x_do_reset 407 376 -31
intel_gpu_reset 545 509 -36
clear_register 63 - -63
i915_clear_error_registers 461 387 -74
A little bit of pointer dancing elimination works wonders.
v2: Roll up the helpers into intel_uncore for general use
With the helpers gcc was a little more eager to inline:
add/remove: 0/1 grow/shrink: 1/3 up/down: 99/-133 (-34)
Function old new delta
i915_clear_error_registers 461 560 +99
gen8_reset_engines 945 942 -3
g4x_do_reset 407 376 -31
intel_gpu_reset 545 509 -36
clear_register 63 - -63
Total: Before=
1544400, After=
1544366, chg -0.00%
Win some, lose some, gcc is gcc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405202419.3093-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 5 Apr 2019 18:15:50 +0000 (19:15 +0100)]
drm/i915: Make use of 'engine->uncore'
The engine has a direct link to the intel_uncore mmio handler, so make
use of it rather than going indirectly via &engine->i915->uncore.
v2: Update gen11_lock_sfc() to use engine->uncore as well
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405181550.7630-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 5 Apr 2019 12:38:31 +0000 (13:38 +0100)]
drm/i915: Make RING_PDP relative to engine->mmio_base
The PDP registers are an oddity inside the set of context saved
registers in that they take the engine as a parameter to the macro and
not the mmio_base as the others do. Make it accept the engine->mmio_base
for consistency in programming the context registers.
add/remove: 0/0 grow/shrink: 2/1 up/down: 3/-32 (-29)
Function old new delta
emit_ppgtt_update 324 326 +2
capture 5102 5103 +1
execlists_init_reg_state.isra 1128 1096 -32
And similar savings later!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405123831.9724-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 5 Apr 2019 11:14:30 +0000 (12:14 +0100)]
drm/i915/selftests: Fix plain use of integer 0 as NULL
Quelch a sparse warning:
drivers/gpu/drm/i915/gt/selftest_lrc.c:119:54: warning: Using plain integer as NULL pointer
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190405111430.18495-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 29 Mar 2019 13:40:24 +0000 (13:40 +0000)]
drm/i915/execlists: Enable coarse preemption boundaries for gen8
When we introduced preemption, we chose to keep it disabled for gen8 as
supporting preemption inside GPGPU user batches required various w/a in
userspace. Since then, the desire to preempt long queues of requests
between batches (e.g. within busywaiting semaphores) has grown. So allow
arbitration within the busywaits and between requests, but disable
arbitration within user batches so that we can preempt between requests
and not risk breaking GPGPU.
However, since this preemption is much coarser and doesn't interfere
with userspace, we decline to include it amongst the scheduler
capabilities. (This is also required for us to skip over the preemption
selftests that expect to be able to preempt user batches.)
Michal suggested that we could perhaps allow preemption inside gen8
userspace batches if we can satisfy ourselves that the default
preemption settings are viable with existing userspace (principally
OpenCL which already should carry any known workaround). We could then
merge the two code paths back into one, even dropping the artifical
has-preemption device feature flag.
Testcase: igt/gem_exec_scheduler/semaphore-user
References:
beecec901790 ("drm/i915/execlists: Preemption!")
Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchronisation on gen8+")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michal Winiarski <michal.winiarski@intel.com> #irc
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190329134024.5254-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 3 Apr 2019 08:21:32 +0000 (09:21 +0100)]
drm/i915: Use lockdep_pin_lock() over the construction of the request
During request construction, we take the timeline->mutex to ensure
exclusive access to the ringbuffer (for command emission) and the
timeline itself (for command ordering). The timeline->mutex should not
be dropped by callers until we release it in i915_request_add().
lockdep provides a pin/unpin lock facility to detect accidental unlocks
inside critical sections, so put it to use for request construction.
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: https://patchwork.freedesktop.org/patch/msgid/20190403082132.327-1-chris@chris-wilson.co.uk
Jani Nikula [Wed, 3 Apr 2019 13:52:36 +0000 (16:52 +0300)]
drm/i915: add Makefile magic for testing headers are self-contained
The below commits added dummy files to test that certain headers are
self-contained, i.e. compilable as standalone units:
39e2f501c1b4 ("drm/i915: Split struct intel_context definition to its own header")
3a891a626794 ("drm/i915: Move intel_engine_mask_t around for use by i915_request_types.h")
8b74594aa455 ("drm/i915: Split out i915_priolist_types into its own header")
The idea is fine, but the implementation is a bit tedious and
inflexible, and does not really scale well.
Implement the same in make using autogenerated dummy sources to include
the headers.
v2 by Chris:
- Use patsubst
- Add .gitignore
- Add clean-files for generated dummy sources
v3 by Jani:
- Fix make clean
- Add the tests to i915-y instead of extra-y
v4 by Jani:
- quiet_cmd whitespace fix
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190403135236.8398-1-jani.nikula@intel.com
Chris Wilson [Thu, 4 Apr 2019 07:33:57 +0000 (08:33 +0100)]
drm/i915: Fixup kerneldoc for intel_cdclk_needs_cd2x_update
drivers/gpu/drm/i915/intel_cdclk.c:2116: warning: Function parameter or member 'dev_priv' not described in 'intel_cdclk_needs_cd2x_update'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Abhay Kumar <abhay.kumar@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190404073357.18795-1-chris@chris-wilson.co.uk
projects / openwrt / staging / blogic.git / log