- 07 Mar, 2018 3 commits
-
-
Oscar Mateo authored
Gen11 has up to 4 VCS and up to 2 VECS engines, this patch adds mmio base definitions for all of them. Bspec: 20944 Bspec: 7021 v2: Set the correct mmio_base in intel_engines_init_mmio; updating the base mmio values any later would cause incorrect reads in i915_gem_sanitize (Michel). Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Ceraolo Spurio, Daniele <daniele.ceraolospurio@intel.com> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180302161501.28594-2-mika.kuoppala@linux.intel.comSigned-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com>
-
Chris Wilson authored
After we call dma_fence_signal(), confirm that the request was indeed complete. 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/20180305104105.8296-1-chris@chris-wilson.co.uk
-
Maarten Lankhorst authored
If i915.enable_fbc is cleared at runtime, but FBC was previously enabled then we don't disable FBC until the next time the crtc is disabled. Make sure that if the module param is changed, we disable FBC in intel_fbc_post_update so we never have to worry about disabling. Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180305123608.20665-1-maarten.lankhorst@linux.intel.comReviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com>
-
- 06 Mar, 2018 15 commits
-
-
Ville Syrjälä authored
LSPCON likes to throw short HPDs during the enable seqeunce prior to the link being trained. These obviously result in the channel CR/EQ check failing and thus we schedule a pointless hotplug work to retrain the link. Avoid that by ignoring the bad CR/EQ status until we've actually initially trained the link. I've not actually investigated to see what LSPCON is trying to signal with the short pulse. But as long as it signals anything I think we're supposed to check the link status anyway, so I don't really see other good ways to solve this. I've not seen these short pulses being generated by normal DP sinks. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Ville Syrjälä authored
intel_dp->channel_eq_status is used in exactly one function, and we don't need it to persist between calls. So just go back to using a local variable instead. Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Doing link retraining from the short pulse handler is problematic since that might introduce deadlocks with MST sideband processing. Currently we don't retrain MST links from this code, but we want to change that. So better to move the entire thing to the hotplug work. We can utilize the new encoder->hotplug() hook for this. The only thing we leave in the short pulse handler is the link status check. That one still depends on the link parameters stored under intel_dp, so no locking around that but races should be mostly harmless as the actual retraining code will recheck the link state if we end up there by mistake. v2: Rebase due to ->post_hotplug() now being just ->hotplug() Check the connector type to figure out if we should do the HDMI thing or the DP think for DDI [pushed with whitespace changes for sparse] Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: -
Ville Syrjälä authored
The LG 4k TV I have doesn't deassert HPD when I turn the TV off, but when I turn it back on it will pulse the HPD line. By that time it has forgotten everything we told it about scrambling and the clock ratio. Hence if we want to get a picture out if it again we have to tell it whether we're currently sending scrambled data or not. Implement that via the encoder->hotplug() hook. v2: Force a full modeset to not follow the HDMI 2.0 spec more closely (Shashank) [pushed with whitespace fixes to make sparse happy] Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: -
Ville Syrjälä authored
Allow encoders to customize their hotplug processing by moving the intel_hpd_irq_event() code into an encoder hotplug vfunc. Currently only SDVO needs this to re-enable hotplug signalling in the SDVO chip. We'll use this same hook for DP/HDMI link management later. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Rodrigo Vivi authored
No functional change since WA is already applied. But since it has different names on different databases, let's document it here to avoid future confusion. Cc: Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180306012812.19779-1-rodrigo.vivi@intel.com
-
Rodrigo Vivi authored
No functional change. WA is already properly applied. but in different databases it has different names. Let's document all of them to avoid future confusion. Cc: Rafael Antognolli <rafael.antognolli@intel.com> Signed-off-by:
Rafael Antognolli <rafael.antognolli@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180306012000.18928-1-rodrigo.vivi@intel.com
-
Dhinakaran Pandiyan authored
In fact, apply the Cannonlake resolution check for all >= Gen-10 platforms to be safe. v3: Update GLK too. (Ville) Longer variable names. if-else in place of ternary operator. v2: Use local variables for resolution limits and print them (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Elio Martinez Monroy <elio.martinez.monroy@intel.com> Signed-off-by:Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
-
Chris Wilson authored
Previously, we would spin waiting for all waiters to wake up and notice their request had completed before we would reset the seqno upon wraparound. However, we can mark their waits as complete and wake them up directly using the existing machinery for handling the flushing of missed wakeups when idling. Suggested-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Since commit fd10e2ce ("drm/i915/breadcrumbs: Ignore unsubmitted signalers"), we cancel the signaler when retiring the request and so upon wraparound, where we wait for all requests to be retired, we no longer need to spin waiting for the signaling thread to release its references to the in-flight requests, and so we can assert that the signaler is idle. References: fd10e2ce ("drm/i915/breadcrumbs: Ignore unsubmitted signalers") Signed-off-by:
-
Chris Wilson authored
When parking the engines and their breadcrumbs, if we have waiters left then they missed their wakeup. Verify that each waiter's seqno did complete. Signed-off-by:
-
Chris Wilson authored
The goal here is to try and reduce the latency of signaling additional requests following the wakeup from interrupt by reducing the list of to-be-signaled requests from an rbtree to a sorted linked list. The original choice of using an rbtree was to facilitate random insertions of request into the signaler while maintaining a sorted list. However, if we assume that most new requests are added when they are submitted, we see those new requests in execution order making a insertion sort fast, and the reduction in overhead of each signaler iteration significant. Since commit 56299fb7 ("drm/i915: Signal first fence from irq handler if complete"), we signal most fences directly from notify_ring() in the interrupt handler greatly reducing the amount of work that actually needs to be done by the signaler kthread. All the thread is then required to do is operate as the bottom-half, cleaning up after the interrupt handler and preparing the next waiter. This includes signaling all later completed fences in a saturated system, but on a mostly idle system we only have to rebuild the wait rbtree in time for the next interrupt. With this de-emphasis of the signaler's role, we want to rejig it's datastructures to reduce the amount of work we require to both setup the signal tree and maintain it on every interrupt. References: 56299fb7 ("drm/i915: Signal first fence from irq handler if complete") Signed-off-by:
-
Daniele Ceraolo Spurio authored
error->device_info.has_guc, which we check in capture_uc_state, is set in capture_gen_state, so the latter needs to be performed first. v2: rebased Reported-by:
Vinay Belgaumkar <vinay.belgaumkar@intel.com> Fixes: 7d41ef34 (drm/i915: Add Guc/HuC firmware details to error state) Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Daniele Ceraolo Spurio authored
some of the static functions used from capture() have the "i915_" prefix while other don't; most of them take i915 as a parameter, but one of them derives it internally from error->i915. Let's be consistent by avoiding prefix for static functions and by getting i915 from error->i915. While at it, s/dev_priv/i915 in functions that don't perform register reads. v2: take i915 from error->i915 (Michal), s/dev_priv/i915, update commit message Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: -
Daniele Ceraolo Spurio authored
Leftover from Gen8 ringbuffer support removal Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
- 05 Mar, 2018 4 commits
-
-
Tvrtko Ursulin authored
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:
-
Chris Wilson authored
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: 85798ac9 ("drm/i915: Fail if we can't get a fence for gen2/3 tiled scanout") Signed-off-by:
-
Mahesh Kumar authored
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:
-
Joonas Lahtinen authored
Signed-off-by:
-
- 02 Mar, 2018 12 commits
-
-
Michal Wajdeczko authored
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:
-
Michal Wajdeczko authored
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:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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:
-
Chris Wilson authored
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=104945Signed-off-by:
-
Ville Syrjälä authored
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:
Ramalingam C <ramalingam.c@intel.com>
-
Ville Syrjälä authored
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ä authored
Rename intel_dp_aux_ch() to intel_dp_aux_xfer() to better convey what it actually does. Signed-off-by:
-
Imre Deak authored
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:
-
Tvrtko Ursulin authored
In decimal its just a weird big number, while in hex can actually log which engines were requested to be wedged. Signed-off-by:
-
Sagar Arun Kamble authored
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: -
Maarten Lankhorst authored
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:
Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by:
-
- 01 Mar, 2018 6 commits
-
-
Chris Wilson authored
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:
Mika Kuoppala <mika.kuoppala@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180301103338.5380-1-chris@chris-wilson.co.uk
-
Lionel Landwerlin authored
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:
-
Mika Kuoppala authored
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:Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
-
Tvrtko Ursulin authored
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:
-
Joonas Lahtinen authored
To pull in the HDCP changes, especially wait_for changes to drm/i915 that Chris wants to build on top of. Signed-off-by: -
Manasi Navare authored
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:
-
