Changbin Du
ede9d0cfcb
drm/i915/gvt: Rework shadow graphic memory management code
...
This is a big one and the GVT shadow graphic memory management code is
heavily refined. The new code is more straightforward with less code.
The struct intel_vgpu_mm is restructured to be clearly defined, use
accurate names and some of the original fields are removed which are
really redundant.
Now we only manage ppgtt mm object with mm->ppgtt_mm.lru_list. No need
to mix ppgtt and ggtt together, since one vGPU only has one ggtt object.
v4: Don't invoke ppgtt_free_all_shadow_page before intel_vgpu_destroy_all_ppgtt_mm.
v3: Add GVT_RING_CTX_NR_PDPS to avoid confusing about the PDPs.
v2: Split some changes into small standalone patches.
Signed-off-by: Changbin Du <changbin.du@intel.com >
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com >
2018-03-06 13:19:13 +08:00
Chris Wilson
88d3dfb6a6
drm/i915: Suspend submission tasklets around wedging
...
After staring hard at sequences like
[ 28.199013] systemd-1 2..s. 26062228us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
[ 28.199095] systemd-1 2..s. 26062229us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000, active=0x1
[ 28.199177] systemd-1 2..s. 26062230us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
[ 28.199258] systemd-1 2..s. 26062231us : execlists_submission_tasklet: rcs0 completed ctx=0
[ 28.199340] gem_eio-829 1..s1 26066853us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0
[ 28.199421] <idle>-0 2..s. 26066863us : execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
[ 28.199503] <idle>-0 2..s. 26066865us : execlists_submission_tasklet: rcs0 csb[2]: status=0x00000001:0x00000000, active=0x1
[ 28.199585] gem_eio-829 1..s1 26067077us : execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0
[ 28.199667] gem_eio-829 1..s1 26067078us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0
[ 28.199749] <idle>-0 2..s. 26067084us : execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
[ 28.199830] <idle>-0 2..s. 26067085us : execlists_submission_tasklet: rcs0 csb[3]: status=0x00008002:0x00000001, active=0x1
[ 28.199912] <idle>-0 2..s. 26067086us : execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
[ 28.199994] gem_eio-829 2..s. 28246084us : execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
[ 28.200096] gem_eio-829 2..s. 28246088us : execlists_submission_tasklet: rcs0 csb[4]: status=0x00000014:0x00000001, active=0x5
[ 28.200178] gem_eio-829 2..s. 28246089us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
[ 28.200260] gem_eio-829 2..s. 28246127us : execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
the conclusion is that the only place where the ports are reset to zero,
is from engine->cancel_requests called during i915_gem_set_wedged().
The race is horrible as it results from calling set-wedged on active HW
(the GPU reset failed) and as such we need to be careful as the HW state
changes beneath us. Fortunately, it's the same scary conditions as
affect normal reset, so we can reuse the same machinery to disable state
tracking as we clobber it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Michel Thierry <michel.thierry@intel.com >
Fixes: af7a8ffad9mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-chris@chris-wilson.co.uk
(cherry picked from commit 963ddd63c3rodrigo.vivi@intel.com >
2018-03-05 16:08:31 -08:00
Lionel Landwerlin
f616f2830c
drm/i915/perf: fix perf stream opening lock
...
We're seeing on CI that some contexts don't have the programmed OA
period timer that directs the OA unit on how often to write reports.
The issue is that we're not holding the drm lock from when we edit the
context images down to when we set the exclusive_stream variable. This
leaves a window for the deferred context allocation to call
i915_oa_init_reg_state() that will not program the expected OA timer
value, because we haven't set the exclusive_stream yet.
v2: Drop need_lock from gen8_configure_all_contexts() (Matt)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Fixes: 701f8231a2https://bugs.freedesktop.org/show_bug.cgi?id=102254
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103715
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103755
Link: https://patchwork.freedesktop.org/patch/msgid/20180301110613.1737-1-lionel.g.landwerlin@intel.com
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org > # v4.14+
(cherry picked from commit 41d3fdcd15rodrigo.vivi@intel.com >
2018-03-05 16:08:28 -08:00
Ville Syrjälä
81af63a4af
drm: Don't pass clip to drm_atomic_helper_check_plane_state()
...
Move the plane clip rectangle handling into
drm_atomic_helper_check_plane_state(). Drivers no longer
have to worry about such mundane details.
v2: Convert armada, rcar, and sun4i as well
v3: Resolve simple_kms_helper conflict
Cc: Liviu Dudau <liviu.dudau@arm.com >
Cc: Brian Starkey <brian.starkey@arm.com >
Cc: Mali DP Maintainers <malidp@foss.arm.com >
Cc: Daniel Vetter <daniel.vetter@intel.com >
Cc: Gustavo Padovan <gustavo@padovan.org >
Cc: Sean Paul <seanpaul@chromium.org >
Cc: Philipp Zabel <p.zabel@pengutronix.de >
Cc: CK Hu <ck.hu@mediatek.com >
Cc: Neil Armstrong <narmstrong@baylibre.com >
Cc: Rob Clark <robdclark@gmail.com >
Cc: Ben Skeggs <bskeggs@redhat.com >
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Cc: Sandy Huang <hjc@rock-chips.com >
Cc: "Heiko Stübner" <heiko@sntech.de >
Cc: Maxime Ripard <maxime.ripard@free-electrons.com >
Cc: Thierry Reding <thierry.reding@gmail.com >
Cc: VMware Graphics <linux-graphics-maintainer@vmware.com >
Cc: Sinclair Yeh <syeh@vmware.com >
Cc: Thomas Hellstrom <thellstrom@vmware.com >
Cc: Shawn Guo <shawnguo@kernel.org >
Cc: Archit Taneja <architt@codeaurora.org >
Cc: linux-amlogic@lists.infradead.org
Cc: linux-arm-msm@vger.kernel.org
Cc: freedreno@lists.freedesktop.org
Cc: nouveau@lists.freedesktop.org
Cc: linux-renesas-soc@vger.kernel.org
Cc: linux-tegra@vger.kernel.org
Cc: Russell King <rmk+kernel@armlinux.org.uk >
Suggested-by: Daniel Vetter <daniel@ffwll.ch >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Reviewed-by: Thierry Reding <treding@nvidia.com >
Reviewed-by: Archit Taneja <architt@codeaurora.org > #msm
Link: https://patchwork.freedesktop.org/patch/msgid/20180123170857.13818-5-ville.syrjala@linux.intel.com
Acked-by: Liviu Dudau <liviu.dudau@arm.com > #hdlcd,malidp
Acked-by: Philipp Zabel <p.zabel@pengutronix.de > #imx,mtk
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com >
Reviewed-by: Sinclair Yeh <syeh@vmware.com > #vmwgfx
Acked-by: Neil Armstrong <narmstrong@baylibre.com > #meson
Acked-by: Shawn Guo <shawnguo@kernel.org > #zte
2018-03-05 20:48:25 +02:00
Tvrtko Ursulin
d4ccceb055
drm/i915/icl: Ringbuffer interrupt handling
...
On Gen11 interrupt masks need to be clear to allow C6 entry.
We keep them all enabled knowing that we generate extra
interrupts.
v2: Rebase.
v3: Remove gen 11 extra check in logical_render_ring_init.
v4: Rebase fixes.
v5: Rebase/refactor.
v6: Rebase.
v7: Rebase.
v8: Update comment and commit message (Daniele)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180302161501.28594-1-mika.kuoppala@linux.intel.com
2018-03-05 16:26:28 +02:00
Chris Wilson
7509702bd8
drm/i915: Unwind vma pinning for intel_pin_and_fence_fb_obj error path
...
If we fail to acquire a fence when we must, we must unwind before
reporting the error. Otherwise, we lose tracking of the vma pinning and
eventually hit a bug like
<3>[ 46.163202] i915_vma_unpin:333 GEM_BUG_ON(!i915_vma_is_pinned(vma))
<4>[ 46.163424] ------------[ cut here ]------------
<2>[ 46.163429] kernel BUG at drivers/gpu/drm/i915/i915_vma.h:333!
<4>[ 46.163444] invalid opcode: 0000 [#1 ] PREEMPT SMP KASAN PTI
<0>[ 46.163451] Dumping ftrace buffer:
<0>[ 46.163457] ---------------------------------
<0>[ 46.163630] <...>-84 1.... 46260767us : i915_gem_object_unpin_from_display_plane: i915_vma_unpin:333 GEM_BUG_ON(!i915_vma_is_pinned(vma))
<0>[ 46.163635] ---------------------------------
<4>[ 46.163638] Modules linked in: vgem i915 snd_hda_codec_analog snd_hda_codec_generic coretemp snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_pcm lpc_ich mei_me e1000e mei prime_numbers
<4>[ 46.163667] CPU: 1 PID: 84 Comm: kworker/u16:1 Tainted: G U 4.16.0-rc3-gc07ef2c77d14-kasan_18+ #1
<4>[ 46.163671] Hardware name: Dell Inc. OptiPlex 755 /0PU052, BIOS A08 02/19/2008
<4>[ 46.163743] Workqueue: events_unbound intel_atomic_commit_work [i915]
<4>[ 46.163809] RIP: 0010:i915_gem_object_unpin_from_display_plane+0x253/0x2f0 [i915]
<4>[ 46.163813] RSP: 0018:ffff8800624cfb48 EFLAGS: 00010286
<4>[ 46.163818] RAX: 000000000000000c RBX: ffff880064446c40 RCX: ffff8800653135b8
<4>[ 46.163822] RDX: dffffc0000000000 RSI: 0000000000000054 RDI: ffff8800651e30d0
<4>[ 46.163825] RBP: 00000000000003d0 R08: 0000000000000001 R09: ffff8800651e3158
<4>[ 46.163829] R10: 0000000000000000 R11: ffff8800651e30f0 R12: 0000000000000001
<4>[ 46.163832] R13: ffff880054c58620 R14: 0000000000000000 R15: dffffc0000000000
<4>[ 46.163836] FS: 0000000000000000(0000) GS:ffff880066040000(0000) knlGS:0000000000000000
<4>[ 46.163840] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[ 46.163843] CR2: 00007f1fc6fb0000 CR3: 00000000526fe000 CR4: 00000000000006e0
<4>[ 46.163846] Call Trace:
<4>[ 46.163918] intel_unpin_fb_vma+0xbd/0x300 [i915]
<4>[ 46.163990] intel_cleanup_plane_fb+0x99/0xc0 [i915]
<4>[ 46.163998] drm_atomic_helper_cleanup_planes+0x166/0x280
<4>[ 46.164071] intel_atomic_commit_tail+0x1594/0x33a0 [i915]
<4>[ 46.164081] ? process_one_work+0x66e/0x1460
<4>[ 46.164151] ? skl_update_crtcs+0x9c0/0x9c0 [i915]
<4>[ 46.164157] ? lock_acquire+0x13d/0x390
<4>[ 46.164161] ? lock_acquire+0x13d/0x390
<4>[ 46.164169] process_one_work+0x71a/0x1460
<4>[ 46.164175] ? __schedule+0x838/0x1e50
<4>[ 46.164182] ? pwq_dec_nr_in_flight+0x2b0/0x2b0
<4>[ 46.164188] ? _raw_spin_lock_irq+0xa/0x40
<4>[ 46.164194] worker_thread+0xdf/0xf60
<4>[ 46.164204] ? process_one_work+0x1460/0x1460
<4>[ 46.164209] kthread+0x2cf/0x3c0
<4>[ 46.164213] ? _kthread_create_on_node+0xa0/0xa0
<4>[ 46.164218] ret_from_fork+0x3a/0x50
<4>[ 46.164227] Code: e8 78 d9 cd e8 48 8b 35 cc 9e 47 00 49 c7 c0 c0 31 84 c0 b9 4d 01 00 00 48 c7 c2 e0 80 84 c0 48 c7 c7 0e bb 57 c0 e8 5d 4b df e8 <0f> 0b 48 c7 c1 c0 30 84 c0 ba 4e 01 00 00 48 c7 c6 e0 80 84 c0
<1>[ 46.164368] RIP: i915_gem_object_unpin_from_display_plane+0x253/0x2f0 [i915] RSP: ffff8800624cfb48
Fixes: 85798ac9b3chris@chris-wilson.co.uk >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180305103312.29492-1-chris@chris-wilson.co.uk
2018-03-05 12:15:28 +00:00
Mahesh Kumar
3d2011cfa4
drm/i915/icl: remove port A/E lane sharing limitation.
...
Platforms before Gen11 were sharing lanes between port-A & port-E.
This limitation is no more there.
Changes since V1:
- optimize the code (Shashank/Jani)
- create helper function to get max lanes (ville)
Changes since V2:
- Include BIOS fail fix-up in same helper function (ville)
Changes since V3:
- remove confusing if/else (jani)
- group intel_encoder initialization
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180206060855.30026-1-mahesh1.kumar@intel.com
2018-03-05 12:27:19 +02:00
Joonas Lahtinen
1f267a572b
drm/i915: Update DRIVER_DATE to 20180305
...
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2018-03-05 11:56:15 +02:00
Michal Wajdeczko
7b026763cf
drm/i915/huc: Mark firmware as failed on auth failure
...
If we fail to authenticate HuC firmware, we should change
its load status to FAIL. While around, print HUC_STATUS
on firmware verification failure.
v2: keep the variables sorted by length (Chris)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Anusha Srivatsa <anusha.srivatsa@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/20180302133718.1260-1-michal.wajdeczko@intel.com
2018-03-02 23:11:13 +00:00
Michal Wajdeczko
7cfca4afd6
drm/i915/uc: Introduce intel_uc_suspend|resume
...
We want to use higher level 'uc' functions as the main entry points to
the GuC/HuC code to hide some details and keep code layered.
While here, move call to disable_guc_interrupts after sending suspend
action to the GuC to allow it work also with CTB as comm mechanism.
v2: update commit msg (Sagar)
Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180302111550.21328-1-michal.wajdeczko@intel.com
2018-03-02 23:11:12 +00:00
Chris Wilson
a3e3883646
drm/i915/execlists: Split spinlock from its irq disabling side-effect
...
During reset/wedging, we have to clean up the requests on the timeline
and flush the pending interrupt state. Currently, we are abusing the irq
disabling of the timeline spinlock to protect the irq state in
conjunction to the engine's timeline requests, but this is accidental
and conflates the spinlock with the irq state. A baffling state of
affairs for the reader.
Instead, explicitly disable irqs over the critical section, and separate
modifying the irq state from the timeline's requests.
Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Michel Thierry <michel.thierry@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180302143246.2579-4-chris@chris-wilson.co.uk
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
2018-03-02 23:11:12 +00:00
Chris Wilson
aebbc2d7b3
drm/i915/execlists: Move irq state manipulation inside irq disabled region
...
Although this state (execlists->active and engine->irq_posted) itself is
not protected by the engine->timeline spinlock, it does conveniently
ensure that irqs are disabled. We can use this to protect our
manipulation of the state and so ensure that the next IRQ to arrive sees
consistent state and (hopefully) ignores the reset engine.
Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Michel Thierry <michel.thierry@intel.com >
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180302131246.22036-1-chris@chris-wilson.co.uk
2018-03-02 23:11:11 +00:00
Chris Wilson
963ddd63c3
drm/i915: Suspend submission tasklets around wedging
...
After staring hard at sequences like
[ 28.199013] systemd-1 2..s. 26062228us : execlists_submission_tasklet: rcs0 cs-irq head=0 [0?], tail=1 [1?]
[ 28.199095] systemd-1 2..s. 26062229us : execlists_submission_tasklet: rcs0 csb[1]: status=0x00000018:0x00000000, active=0x1
[ 28.199177] systemd-1 2..s. 26062230us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.1, seqno=3, prio=-1024
[ 28.199258] systemd-1 2..s. 26062231us : execlists_submission_tasklet: rcs0 completed ctx=0
[ 28.199340] gem_eio-829 1..s1 26066853us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.1, seqno=1, prio=0
[ 28.199421] <idle>-0 2..s. 26066863us : execlists_submission_tasklet: rcs0 cs-irq head=1 [1?], tail=2 [2?]
[ 28.199503] <idle>-0 2..s. 26066865us : execlists_submission_tasklet: rcs0 csb[2]: status=0x00000001:0x00000000, active=0x1
[ 28.199585] gem_eio-829 1..s1 26067077us : execlists_submission_tasklet: rcs0 in[1]: ctx=3.1, seqno=2, prio=0
[ 28.199667] gem_eio-829 1..s1 26067078us : execlists_submission_tasklet: rcs0 in[0]: ctx=1.2, seqno=1, prio=0
[ 28.199749] <idle>-0 2..s. 26067084us : execlists_submission_tasklet: rcs0 cs-irq head=2 [2?], tail=3 [3?]
[ 28.199830] <idle>-0 2..s. 26067085us : execlists_submission_tasklet: rcs0 csb[3]: status=0x00008002:0x00000001, active=0x1
[ 28.199912] <idle>-0 2..s. 26067086us : execlists_submission_tasklet: rcs0 out[0]: ctx=1.2, seqno=1, prio=0
[ 28.199994] gem_eio-829 2..s. 28246084us : execlists_submission_tasklet: rcs0 cs-irq head=3 [3?], tail=4 [4?]
[ 28.200096] gem_eio-829 2..s. 28246088us : execlists_submission_tasklet: rcs0 csb[4]: status=0x00000014:0x00000001, active=0x5
[ 28.200178] gem_eio-829 2..s. 28246089us : execlists_submission_tasklet: rcs0 out[0]: ctx=0.0, seqno=0, prio=0
[ 28.200260] gem_eio-829 2..s. 28246127us : execlists_submission_tasklet: execlists_submission_tasklet:886 GEM_BUG_ON(buf[2 * head + 1] != port->context_id)
the conclusion is that the only place where the ports are reset to zero,
is from engine->cancel_requests called during i915_gem_set_wedged().
The race is horrible as it results from calling set-wedged on active HW
(the GPU reset failed) and as such we need to be careful as the HW state
changes beneath us. Fortunately, it's the same scary conditions as
affect normal reset, so we can reuse the same machinery to disable state
tracking as we clobber it.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104945
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Michel Thierry <michel.thierry@intel.com >
Fixes: af7a8ffad9mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180302113324.23189-2-chris@chris-wilson.co.uk
2018-03-02 23:11:11 +00:00
Ville Syrjälä
32078b727d
drm/i915: Deduplicate the code to fill the aux message header
...
We have two instances of the code to fill out the header for the aux
message. Pull it into a small helper.
v2: Rebase due to txbuf[] changes
Cc: Sean Paul <seanpaul@chromium.org >
Cc: Ramalingam C <ramalingam.c@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180222212802.4826-1-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com >
2018-03-02 18:26:52 +02:00
Ville Syrjälä
8159c796b6
drm/i915: Keep the AKSV details in intel_dp_hdcp_write_an_aksv()
...
Let's try to keep the details on the AKSV stuff concentrated
in one place. So move the control bit and +5 data size handling
there.
v2: Increase txbuf[] to include the payload which intel_dp_aux_xfer()
will still load into the registers even though the hardware
will ignore it
Cc: Sean Paul <seanpaul@chromium.org >
Cc: Ramalingam C <ramalingam.c@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180222212732.4665-1-ville.syrjala@linux.intel.com
Reviewed-by: Ramalingam C <ramalingam.c@intel.com >
2018-03-02 18:26:52 +02:00
Ville Syrjälä
f760626518
drm/i915: s/intel_dp_aux_ch/intel_dp_aux_xfer/
...
Rename intel_dp_aux_ch() to intel_dp_aux_xfer() to better convey
what it actually does.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180222181036.15251-6-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk > #irc
2018-03-02 18:26:52 +02:00
Imre Deak
fee0fddc1d
drm/i915/gen9, gen10: Disable FBC on planes with a misaligned Y-offset
...
Enabling FBC on a plane having a Y-offset that isn't divisible by 4 may
cause pipe FIFO underruns and flickers, so disable FBC on such a config.
I tried the followings to work around the issue:
- enable each HW work around in ILK_DPFC_CHICKEN
- disable each compression algorithm in ILK_DPFC_CONTROL
- disable low-power watermarks
None of the above got rid of the problem. I haven't found this issue in
the Bspec/WA database either.
Besides the igt testcase below (yet to be merged) an easy way to
reproduce the issue is to enable a plane with FBC and a plane Y-offset
not aligned to 4 and then just enable/disable FBC in a loop, keeping the
plane enabled.
I could trigger the problem on BXT/GLK/SKL/CNL, so assume for now that it's
only present on GEN9 and GEN10.
v2: (Ville)
- Run the test/apply the WA on CNL as well.
- Use IS_GEN() instead of INTEL_GEN().
- Fix spelling.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Testcase: igt/kms_plane/plane-clipping-pipe-A-planes
Signed-off-by: Imre Deak <imre.deak@intel.com >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180301134457.13974-1-imre.deak@intel.com
2018-03-02 17:33:19 +02:00
Ville Syrjälä
c8624ede3e
drm/i915: Add support for the YCbCr COLOR_RANGE property
...
Add support for the COLOR_RANGE property on planes. This property
selects whether the input YCbCr data is to treated as limited range
or full range.
On most platforms this is a matter of setting the "YUV range correction
disable" bit, and on VLV/CHV we'll just have to program the color
correction logic to pass the data through unmodified.
v2: Rebase
Cc: Harry Wentland <harry.wentland@amd.com >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Daniel Stone <daniel@fooishbar.org >
Cc: Russell King - ARM Linux <linux@armlinux.org.uk >
Cc: Ilia Mirkin <imirkin@alum.mit.edu >
Cc: Hans Verkuil <hverkuil@xs4all.nl >
Cc: Uma Shankar <uma.shankar@intel.com >
Cc: Shashank Sharma <shashank.sharma@intel.com >
Cc: Jyri Sarha <jsarha@ti.com >
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-9-ville.syrjala@linux.intel.com
2018-03-02 14:49:10 +02:00
Ville Syrjälä
23b280890a
drm/i915: Change the COLOR_ENCODING prop default value to BT.709
...
Bring us forward from the stone age and switch our default YCbCr->RGB
conversion matrix to BT.709 from BT.601. I would expect most matrial
to be BT.709 these days.
Cc: Harry Wentland <harry.wentland@amd.com >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Daniel Stone <daniel@fooishbar.org >
Cc: Russell King - ARM Linux <linux@armlinux.org.uk >
Cc: Ilia Mirkin <imirkin@alum.mit.edu >
Cc: Hans Verkuil <hverkuil@xs4all.nl >
Cc: Uma Shankar <uma.shankar@intel.com >
Cc: Shashank Sharma <shashank.sharma@intel.com >
Cc: Jyri Sarha <jsarha@ti.com >
Acked-by: Shashank Sharma <shashank.sharma@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-8-ville.syrjala@linux.intel.com
2018-03-02 14:48:23 +02:00
Ville Syrjälä
b0f5c0badc
drm/i915: Add support for the YCbCr COLOR_ENCODING property
...
Add support for the COLOR_ENCODING plane property which selects
the matrix coefficients used for the YCbCr->RGB conversion. Our
hardware can generally handle BT.601 and BT.709.
CHV pipe B sprites have a fully programmable matrix, so in theory
we could handle anything, but it doesn't seem all that useful to
expose anything beyond BT.601 and BT.709 at this time.
GLK can supposedly do BT.2020, but let's leave enabling that for
the future as well.
v2: Rename bit defines to match the spec more closely (Shashank)
Cc: Harry Wentland <harry.wentland@amd.com >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Daniel Stone <daniel@fooishbar.org >
Cc: Russell King - ARM Linux <linux@armlinux.org.uk >
Cc: Ilia Mirkin <imirkin@alum.mit.edu >
Cc: Hans Verkuil <hverkuil@xs4all.nl >
Cc: Uma Shankar <uma.shankar@intel.com >
Cc: Shashank Sharma <shashank.sharma@intel.com >
Cc: Jyri Sarha <jsarha@ti.com >
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-7-ville.syrjala@linux.intel.com
2018-03-02 14:46:18 +02:00
Ville Syrjälä
38f24f21ae
drm/i915: Fix plane YCbCr->RGB conversion for GLK
...
On GLK the plane CSC controls moved into the COLOR_CTL register.
Update the code to progam the YCbCr->RGB CSC mode correctly when
faced with an YCbCr framebuffer.
The spec is rather confusing as it calls the mode "YUV601 to RGB709".
I'm going to assume that just means it's going to use the YCbCr->RGB
matrix as specified in BT.601 and doesn't actually change the gamut.
Cc: Harry Wentland <harry.wentland@amd.com >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Daniel Stone <daniel@fooishbar.org >
Cc: Russell King - ARM Linux <linux@armlinux.org.uk >
Cc: Ilia Mirkin <imirkin@alum.mit.edu >
Cc: Hans Verkuil <hverkuil@xs4all.nl >
Cc: Uma Shankar <uma.shankar@intel.com >
Cc: Shashank Sharma <shashank.sharma@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-6-ville.syrjala@linux.intel.com
Reviewed-by: Imre Deak <imre.deak@intel.com >
2018-03-02 14:44:27 +02:00
Ville Syrjälä
5deae91911
drm/i915: Correctly handle limited range YCbCr data on VLV/CHV
...
Turns out the VLV/CHV fixed function sprite CSC expects full range
data as input. We've been feeding it limited range data to it all
along. To expand the data out to full range we'll use the color
correction registers (brightness, contrast, and saturation).
On CHV pipe B we were actually doing the right thing already because we
progammed the custom CSC matrix to do expect limited range input. Now
that well pre-expand the data out with the color correction unit, we
need to change the CSC matrix to operate with full range input instead.
This should make the sprite output of the other pipes match the sprite
output of pipe B reasonably well. Looking at the resulting pipe CRCs,
there can be a slight difference in the output, but as I don't know
the formula used by the fixed function CSC of the other pipes, I don't
think it's worth the effort to try to match the output exactly. It
might not even be possible due to difference in internal precision etc.
One slight caveat here is that the color correction registers are single
bufferred, so we should really be updating them during vblank, but we
still don't have a mechanism for that, so just toss in another FIXME.
v2: Rebase
v3: s/bri/brightness/ s/con/contrast/ (Shashank)
v4: Clarify the constants and math (Shashank)
Cc: Harry Wentland <harry.wentland@amd.com >
Cc: Daniel Vetter <daniel@ffwll.ch >
Cc: Daniel Stone <daniel@fooishbar.org >
Cc: Russell King - ARM Linux <linux@armlinux.org.uk >
Cc: Ilia Mirkin <imirkin@alum.mit.edu >
Cc: Hans Verkuil <hverkuil@xs4all.nl >
Cc: Shashank Sharma <shashank.sharma@intel.com >
Cc: Uma Shankar <uma.shankar@intel.com >
Cc: Jyri Sarha <jsarha@ti.com >
Cc: "Tang, Jun" <jun.tang@intel.com >
Reported-by: "Tang, Jun" <jun.tang@intel.com >
Cc: stable@vger.kernel.org
Fixes: 7f1f3851feshashank.sharma@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180214192327.3250-5-ville.syrjala@linux.intel.com
2018-03-02 14:42:27 +02:00
Tvrtko Ursulin
c27557ab56
drm/i915: Wedged engine mask makes more sense in hex
...
In decimal its just a weird big number, while in hex can actually log
which engines were requested to be wedged.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Reviewed-by: Michel Thierry <michel.thierry@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180228171844.20006-1-tvrtko.ursulin@linux.intel.com
2018-03-02 11:56:47 +00:00
Sagar Arun Kamble
57312eaacd
drm/i915/uc: Make GuC/HuC fw fetch and loading functions/file structure symmetric
...
GuC load function is named intel_guc_fw_upload() and HuC load function is
named intel_huc_init_hw(). Make them consistent intel_*_fw_upload. Also
move HuC fw loading functions and declarations to separate files
intel_huc_fw.c|h like GuC.
While at this, do below changes
1. Update kernel-doc comment for intel_*_fw_upload() functions
2. s/huc_ucode_xfer/huc_fw_xfer
3. Introduce intel_huc_fw_init_early()
v2: Changed patch to update HuC functions instead of changing
guc_fw_upload and update file structure. (Michal Wajdeczko)
v3: Added SPDX License identifier to huc_fw.c|h. (Michal Wajdeczko)
Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com >
Cc: Michal Winiarski <michal.winiarski@intel.com >
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com >
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/1519922745-25441-1-git-send-email-sagar.a.kamble@intel.com
2018-03-02 09:04:45 +00:00
Maarten Lankhorst
8c58f73c48
drm/i915: Check for I915_MODE_FLAG_INHERITED before drm_atomic_helper_check_modeset
...
Moving the check upwards will mean we we no longer have to add planes
and connectors manually, because everything is handled correctly by
drm_atomic_helper_check_modeset() as intended.
[applied with whitespace changes to make sparse happy]
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com >
Cc: Lyude Paul <lyude@redhat.com >
Cc: Daniel Vetter <daniel.vetter@ffwll.ch >
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch >
Reviewed-by: Lyude Paul <lyude@redhat.com >
Signed-off-by: Lyude Paul <lyude@redhat.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180221092808.30060-1-maarten.lankhorst@linux.intel.com
2018-03-01 20:54:35 -05:00
Chris Wilson
ffed7bd236
drm/i915: Replace open-coded wait-for loop
...
Now that we can pass arbitrary commands into the base __wait_for()
macro, we can reimplement the open-coded wait-for inside
i915_gem_idle_work_handler() using the new macro. This means that instead
of using ktime, we now use jiffies, and benefit from the exponential sleep
backoff that allows a fast response if the HW settles quickly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180301103338.5380-1-chris@chris-wilson.co.uk
2018-03-01 17:42:58 +00:00
Lionel Landwerlin
41d3fdcd15
drm/i915/perf: fix perf stream opening lock
...
We're seeing on CI that some contexts don't have the programmed OA
period timer that directs the OA unit on how often to write reports.
The issue is that we're not holding the drm lock from when we edit the
context images down to when we set the exclusive_stream variable. This
leaves a window for the deferred context allocation to call
i915_oa_init_reg_state() that will not program the expected OA timer
value, because we haven't set the exclusive_stream yet.
v2: Drop need_lock from gen8_configure_all_contexts() (Matt)
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com >
Reviewed-by: Matthew Auld <matthew.auld@intel.com >
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Fixes: 701f8231a2https://bugs.freedesktop.org/show_bug.cgi?id=102254
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103715
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103755
Link: https://patchwork.freedesktop.org/patch/msgid/20180301110613.1737-1-lionel.g.landwerlin@intel.com
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org > # v4.14+
2018-03-01 14:32:37 +00:00
Mika Kuoppala
51951ae7ed
drm/i915/icl: Interrupt handling
...
v2: Rebase.
v3:
* Remove DPF, it has been removed from SKL+.
* Fix -internal rebase wrt. execlists interrupt handling.
v4: Rebase.
v5:
* Updated for POR changes. (Daniele Ceraolo Spurio)
* Merged with irq handling fixes by Daniele Ceraolo Spurio:
* Simplify the code by using gen8_cs_irq_handler.
* Fix interrupt handling for the upstream kernel.
v6:
* Remove early bringup debug messages (Tvrtko)
* Add NB about arbitrary spin wait timeout (Tvrtko)
v7 (from Paulo):
* Don't try to write RO bits to registers.
* Don't check for PCH types that don't exist. PCH interrupts are not
here yet.
v9:
* squashed in selector and shared register handling (Daniele)
* skip writing of irq if data is not valid (Daniele)
* use time_after32 (Chris)
* use I915_MAX_VCS and I915_MAX_VECS (Daniele)
* remove fake pm interrupt handling for later patch (Mika)
v10:
* Direct processing of banks. clear banks early (Chris)
* remove poll on valid bit, only clear valid bit (Mika)
* use raw accessors, better naming (Chris)
v11:
* adapt to raw_reg_[read|write]
* bring back polling the valid bit (Daniele)
v12:
* continue if unset intr_dw (Daniele)
* comment the usage of gen8_de_irq_handler bits (Daniele)
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Cc: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Oscar Mateo <oscar.mateo@intel.com >
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com >
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com >
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180228101153.7224-2-mika.kuoppala@linux.intel.com
2018-03-01 14:13:54 +02:00
Tvrtko Ursulin
022d3093a9
drm/i915/icl: Prepare for more rings
...
Gen11 will add more VCS and VECS rings so prepare the
infrastructure to support that.
Bspec: 7021
v2: Rebase.
v3: Rebase.
v4: Rebase.
v5: Rebase.
v6:
- Update for POR changes. (Daniele Ceraolo Spurio)
- Add provisional guc engine ids - to be checked and confirmed.
v7:
- Rebased.
- Added the new ring masks.
- Added the new HW ids.
v8:
- Introduce I915_MAX_VCS/VECS to avoid magic numbers (Michal)
v9: increase MAX_ENGINE_INSTANCE to 3
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com >
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com >
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com >
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com >
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180228101153.7224-1-mika.kuoppala@linux.intel.com
2018-03-01 14:13:47 +02:00
Joonas Lahtinen
bba73071b6
Merge drm-next into drm-intel-next-queued (this time for real)
...
To pull in the HDCP changes, especially wait_for changes to drm/i915
that Chris wants to build on top of.
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2018-03-01 11:14:24 +02:00
Manasi Navare
c71b53cc66
drm/i915/dp: Add HBR3 rate (8.1 Gbps) to dp_rates array
...
dp_rates[] array is a superset of all the link rates supported
by sink devices. DP 1.3 specification adds HBR3 (8.1Gbps) link rate
to the set of link rates supported by sink. This patch adds this rate
to dp_rates[] array that gets used to populate the sink_rates[]
array limited by max rate obtained from DP_MAX_LINK_RATE DPCD register.
v2:
* Rebased on top of Jani's localized rates patch
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/1519857110-26916-1-git-send-email-manasi.d.navare@intel.com
2018-03-01 09:21:18 +02:00
Dave Airlie
f073d78eeb
Merge tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
...
Driver Changes:
- Lift alpha_support protection from Cannonlake (Rodrigo)
* Meaning the driver should mostly work for the hardware we had
at our disposal when testing
* Used to be preliminary_hw_support
- Add missing Cannonlake PCI device ID of 0x5A4C (Rodrigo)
- Cannonlake port register fix (Mahesh)
- Fix Dell Venue 8 Pro black screen after modeset (Hans)
- Fix for always returning zero out-fence from execbuf (Daniele)
- Fix HDMI audio when no no relevant video output is active (Jani)
- Fix memleak of VBT data on driver_unload (Hans)
- Fix for KASAN found locking issue (Maarten)
- RCU barrier consolidation to improve igt/gem_sync/idle (Chris)
- Optimizations to IRQ handlers (Chris)
- vblank tracking improvements (64-bit resolution, PM) (Dhinakaran)
- Pipe select bit corrections (Ville)
- Reduce runtime computed device_info fields (Chris)
- Tune down some WARN_ONs to GEM_BUG_ON now that CI has good coverage (Chris)
- A bunch of kerneldoc warning fixes (Chris)
* tag 'drm-intel-next-2018-02-21' of git://anongit.freedesktop.org/drm/drm-intel: (113 commits)
drm/i915: Update DRIVER_DATE to 20180221
drm/i915/fbc: Use PLANE_HAS_FENCE to determine if the plane is fenced
drm/i915/fbdev: Use the PLANE_HAS_FENCE flags from the time of pinning
drm/i915: Move the policy for placement of the GGTT vma into the caller
drm/i915: Also check view->type for a normal GGTT view
drm/i915: Drop WaDoubleCursorLP3Latency:ivb
drm/i915: Set the primary plane pipe select bits on gen4
drm/i915: Don't set cursor pipe select bits on g4x+
drm/i915: Assert that we don't overflow frontbuffer tracking bits
drm/i915: Track number of pending freed objects
drm/i915/: Initialise trans_min for skl_compute_transition_wm()
drm/i915: Clear the in-use marker on execbuf failure
drm/i915: Prune gen8_gt_irq_handler
drm/i915: Track GT interrupt handling using the master iir
drm/i915: Remove WARN_ONCE for failing to pm_runtime_if_in_use
drm: intel_dpio_phy: fix kernel-doc comments at nested struct
drm/i915: Release connector iterator on a digital port conflict.
drm/i915/execlists: Remove too early assert
drm/i915: Assert that we always complete a submission to guc/execlists
drm: move read_domains and write_domain into i915
...
2018-03-01 14:07:22 +10:00
Jani Nikula
229675d5c0
drm/i915/dp: move link rate arrays where they're used
...
Localize link rate arrays by moving them to the functions where they're
used. Further clarify the distinction between source and sink
capabilities. Split pre and post Haswell arrays, and get rid of the
array size arithmetics. Use a direct rate value in the paranoia case of
no common rates find.
Cc: Manasi Navare <manasi.d.navare@intel.com >
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com >
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180227105911.4485-1-jani.nikula@intel.com
2018-02-28 23:04:40 +02:00
Tvrtko Ursulin
fa89782b4f
drm/i915: Make global seqno known in i915_gem_request_execute tracepoint
...
Commit fe49789fabtvrtko.ursulin@intel.com >
Fixes: fe49789fabchris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk >
Link: https://patchwork.freedesktop.org/patch/msgid/20180220104742.565-1-tvrtko.ursulin@linux.intel.com
(cherry picked from commit 158863fb50rodrigo.vivi@intel.com >
2018-02-28 11:10:48 -08:00
Chris Wilson
e659d14ed4
drm/i915: Clear the in-use marker on execbuf failure
...
If we fail to unbind the vma (due to a signal on an active buffer that
needs to be moved for the next execbuf), then we need to clear the
persistent tracking state we setup for this execbuf.
Fixes: c7c6e46f91chris@chris-wilson.co.uk >
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: <stable@vger.kernel.org > # v4.14+
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180219140144.24004-1-chris@chris-wilson.co.uk
(cherry picked from commit ed2f353232rodrigo.vivi@intel.com >
2018-02-28 11:10:43 -08:00
Mahesh Kumar
1b0008450f
drm/i915/cnl: Fix PORT_TX_DW5/7 register address
...
Register Address for CNL_PORT_DW5_LN0_D is 0x162E54, but current code is
defining it as 0x162ED4. Similarly for CNL_PORT_DW7_LN0_D register address
is defined 0x162EDC instead of 0x162E5C, fix it.
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com >
Fixes: 04416108ccrodrigo.vivi@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180215095643.3844-2-mahesh1.kumar@intel.com
(cherry picked from commit e103962611rodrigo.vivi@intel.com >
2018-02-28 11:10:37 -08:00
Jani Nikula
72a6d72c2c
drm/i915/audio: fix check for av_enc_map overflow
...
Turns out -1 >= ARRAY_SIZE() is always true. Move the bounds check where
we know pipe >= 0 and next to the array indexing where it makes most
sense.
Fixes: 9965db26ac0b7029b7e4stable@vger.kernel.org > # v4.10+
Cc: Mika Kahola <mika.kahola@intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Cc: Jani Nikula <jani.nikula@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Cc: intel-gfx@lists.freedesktop.org
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com >
Reviewed-by: Mika Kahola <mika.kahola@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180214173840.25360-1-jani.nikula@intel.com
(cherry picked from commit cdb3db8542rodrigo.vivi@intel.com >
2018-02-28 11:10:32 -08:00
Daniele Ceraolo Spurio
b1b13780ab
drm/i915: Fix rsvd2 mask when out-fence is returned
...
GENMASK_ULL wants the high bit of the mask first. The current value
cancels the in-fence when an out-fence is returned.
Fixes: fec0445caachris@chris-wilson.co.uk >
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@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/20180214191827.8465-1-daniele.ceraolospurio@intel.com
Cc: <stable@vger.kernel.org > # v4.12+
(cherry picked from commit b6a88e4a80rodrigo.vivi@intel.com >
2018-02-28 11:10:28 -08:00
Ville Syrjälä
449059a969
drm/i915: Consult aux_ch instead of port in ->get_aux_clock_divider()
...
While it seems totally unlikely that any system would mix a cpu/north
aux channel with a pch/south port (or vice versa) we should still
consult intel_dp->aux_ch rather than encoder->port when figuring out
which clock is actually used by the aux ch.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180222181036.15251-5-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk > #irc
2018-02-28 18:11:27 +02:00
Chris Wilson
367a35a6c6
drm/i915: Don't deref request->ctx inside unlocked print_request()
...
Although we protect the request itself, we don't lock inside
intel_engine_dump() and so the request maybe retired as we peek into it.
One consequence is that the request->ctx may be freed before we
dereference it, leading to a use-after-free. Replace the hw_id we are
peeking from inside request->ctx with the request->fence.context, with
which we can still track from which context the request originated
(although to tie to HW reports requires a little more legwork, but is
good enough to follow the GEM traces).
[52640.729670] general protection fault: 0000 [#2 ] SMP
[52640.729694] Dumping ftrace buffer:
[52640.729701] (ftrace buffer empty)
[52640.729705] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic x86_pkg_\
temp_thermal intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul snd_hda_intel snd_hda_codec snd_hwdep gha\
sh_clmulni_intel snd_hda_core snd_pcm mei_me mei i915 r8169 mii prime_numbers i2c_hid
[52640.729748] CPU: 2 PID: 4335 Comm: gem_exec_schedu Tainted: G UD W 4.16.0-rc3+ #7
[52640.729759] Hardware name: Acer Aspire E5-575G/Ironman_SK , BIOS V1.12 08/02/2016
[52640.729803] RIP: 0010:print_request+0x2b/0xb0 [i915]
[52640.729811] RSP: 0018:ffffc90001453c18 EFLAGS: 00010206
[52640.729820] RAX: 6b6b6b6b6b6b6b6b RBX: ffff8801e0292d40 RCX: 0000000000000006
[52640.729829] RDX: ffffc90001453c60 RSI: ffff8801e0292d40 RDI: 0000000000000003
[52640.729838] RBP: ffffc90001453d80 R08: 0000000000000000 R09: 0000000000000001
[52640.729847] R10: ffffc90001453bd0 R11: ffffc90001453c73 R12: ffffc90001453c60
[52640.729856] R13: ffffc90001453d80 R14: ffff8801d5a683c8 R15: ffff8801e0292d40
[52640.729866] FS: 00007f1ee50548c0(0000) GS:ffff8801e8200000(0000) knlGS:0000000000000000
[52640.729876] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[52640.729884] CR2: 00007f1ee5077000 CR3: 00000001d9411004 CR4: 00000000003606e0
[52640.729893] Call Trace:
[52640.729922] intel_engine_print_registers+0x623/0x890 [i915]
[52640.729948] intel_engine_dump+0x4a3/0x590 [i915]
[52640.729957] ? seq_printf+0x3a/0x50
[52640.729977] i915_engine_info+0xb8/0xe0 [i915]
[52640.729984] ? drm_mode_gamma_get_ioctl+0xf0/0xf0
[52640.729990] seq_read+0xd5/0x410
[52640.729997] full_proxy_read+0x4b/0x70
[52640.730004] __vfs_read+0x1e/0x120
[52640.730009] ? do_sys_open+0x134/0x220
[52640.730015] ? kmem_cache_free+0x174/0x2b0
[52640.730021] vfs_read+0xa1/0x150
[52640.730026] SyS_read+0x40/0xa0
[52640.730032] do_syscall_64+0x65/0x1a0
[52640.730038] entry_SYSCALL_64_after_hwframe+0x42/0xb7
Reported-by: Mika Kuoppala <mika.kuoppala@intel.com >
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@intel.com >
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180228094732.28462-1-chris@chris-wilson.co.uk
2018-02-28 14:16:42 +00:00
Ville Syrjälä
5857c0d425
drm/i915: Don't mangle the CTM on pre-HSW
...
On pre-HSW we have dedicated hardware for the RGB limited range
handling, and so we don't want to compress with the CSC matrix.
Toss in a FIXME about gamma LUT vs. limited range using the CSC.
Cc: Johnson Lin <johnson.lin@intel.com >
Cc: Uma Shankar <uma.shankar@intel.com >
Cc: Shashank Sharma <shashank.sharma@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180222214232.6064-4-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com >
2018-02-28 15:17:12 +02:00
Ville Syrjälä
c35e8a25df
drm/i915: Rename pipe CSC to use ilk_ prefix
...
The pipe CSC was introduced by ILK, so change everything related
to use ilk_ as the prefix.
Cc: Johnson Lin <johnson.lin@intel.com >
Cc: Uma Shankar <uma.shankar@intel.com >
Cc: Shashank Sharma <shashank.sharma@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180222214232.6064-3-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com >
2018-02-28 15:00:08 +02:00
Ville Syrjälä
db61d160b3
drm/i915: Remove the pointless 1:1 matrix copy
...
If we don't have to frob with the user provided ctm matrix there's
no point in copying it over. Just point at the user ctm directly.
Also the matrix gets fully populated by ctm_mult_by_limited() so
no need to zero initialize it.
Cc: Johnson Lin <johnson.lin@intel.com >
Cc: Uma Shankar <uma.shankar@intel.com >
Cc: Shashank Sharma <shashank.sharma@intel.com >
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180222214232.6064-2-ville.syrjala@linux.intel.com
Reviewed-by: Uma Shankar <uma.shankar@intel.com >
2018-02-28 14:58:23 +02:00
Joonas Lahtinen
f074037a2e
Merge drm-next into drm-intel-next-queued
...
To pull in the HDCP changes, especially wait_for changes to drm/i915
that Chris wants to build on top of.
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
2018-02-28 12:12:03 +02:00
Mustamin B Mustaffa
73c0fcac97
drm/i915: Enable VBT based BL control for DP
...
Currently, BXT_PP is hardcoded with value '0'.
It practically disabled eDP backlight on MRB (BXT) platform.
This patch will tell which BXT_PP registers (there are two set of
PP_CONTROL in the spec) to be used as defined in VBT (Video Bios Timing
table) and this will enabled eDP backlight controller on MRB (BXT)
platform.
v2:
- Remove unnecessary information in commit message.
- Assign vbt.backlight.controller to a backlight_controller variable and
return the variable value.
v3:
- Rebased to latest code base.
- updated commit title.
Signed-off-by: Mustamin B Mustaffa <mustamin.b.mustaffa@intel.com >
Signed-off-by: Jani Nikula <jani.nikula@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180227030734.37901-1-mustamin.b.mustaffa@intel.com
2018-02-28 11:37:45 +02:00
Chris Wilson
128326a10c
drm/i915: Repeat the GEM_BUG_ON message in the ftrace log
...
As the ftrace log is overflowing the pstore capture, we lose the last
gasps from dmesg which includes the GEM_BUG_ON function:line and condition
that failed. Vital information for tracking down the bug, so append it to
the frace log as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk >
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com >
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180227211816.5546-1-chris@chris-wilson.co.uk
2018-02-28 09:31:57 +00:00
Rodrigo Vivi
d66047e4a5
drm/i915/cnl: Add WaRsDisableCoarsePowerGating
...
Old Wa added now forever on CNL all steppings.
With CPU P states enabled along with RC6, dispatcher
hangs can happen.
Cc: Rafael Antognolli <rafael.antognolli@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Reviewed-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180222200535.9290-1-rodrigo.vivi@intel.com
2018-02-27 15:54:30 -08:00
Rodrigo Vivi
c4932d7956
drm/i915/psr: Don't avoid PSR when PSR2 conditions are not met.
...
We can still use PSR1 when PSR2 conditions are not met.
So, let's split the check in a way that we make sure has_psr
gets set independently of PSR2 criteria.
v2: Duh! Handle proper return to avoid breaking PSR2.
v3: (DK):
- better name for psr2 conditions check function
- Don't remove FIXME block and psr2.support check.
- Add a debug message to show us what PSR or PSR2 is
getting enabled now we have ways to enabled PSR on
PSR2 panels.
- s/PSR2 disabled/PSR2 not enabled
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180227212913.14083-2-rodrigo.vivi@intel.com
2018-02-27 15:54:17 -08:00
Rodrigo Vivi
8cef3e5c0d
drm/i915/psr2: Fix max resolution supported.
...
According to spec:
"PSR2 is supported for pipe active sizes up to
3640 pixels wide and 2304 lines tall."
BSpec: 7713
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180227212913.14083-1-rodrigo.vivi@intel.com
2018-02-27 15:54:12 -08:00
Dhinakaran Pandiyan
06d058e1a0
drm/i915/psr: Check for power state control capability.
...
eDP spec says - "If PSR/PSR2 is supported, the SET_POWER_CAPABLE bit in the
EDP_GENERAL_CAPABILITY_1 register (DPCD Address 00701h, bit d7) must be set
to 1."
Reject PSR on panels without this cap bit set as such panels cannot be
controlled via SET_POWER & SET_DP_PWR_VOLTAGE register and the DP source
needs to be able to do that for PSR.
Thanks to Nathan for debugging this.
Panel cap checks like this can be done just once, let's fix this
when PSR dpcd init movement lands.
Cc: Nathan D Ciobanu <nathan.d.ciobanu@intel.com >
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com >
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com >
Tested-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com >
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com >
Link: https://patchwork.freedesktop.org/patch/msgid/20180227032723.15474-1-dhinakaran.pandiyan@intel.com
2018-02-27 12:28:10 -08:00
