summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915/i915_irq.c
AgeCommit message (Collapse)AuthorFilesLines
2018-10-01drm/i915: Avoid compiler warning for maybe unused gu_misc_iirChris Wilson1-21/+12
/kisskb/src/drivers/gpu/drm/i915/i915_irq.c: warning: 'gu_misc_iir' may be used uninitialized in this function [-Wuninitialized]: => 3120:10 Silence the compiler warning by ensuring that the local variable is initialised and removing the guard that is confusing the older gcc. Reported-by: Geert Uytterhoeven <geert@linux-m68k.org> Fixes: df0d28c185ad ("drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISC") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180926104718.17462-1-chris@chris-wilson.co.uk (cherry picked from commit 7a90938332d80faf973fbcffdf6e674e7b8f0914) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-08-06drm/i915: Interactive RPS modeChris Wilson1-2/+2
RPS provides a feedback loop where we use the load during the previous evaluation interval to decide whether to up or down clock the GPU frequency. Our responsiveness is split into 3 regimes, a high and low plateau with the intent to keep the gpu clocked high to cover occasional stalls under high load, and low despite occasional glitches under steady low load, and inbetween. However, we run into situations like kodi where we want to stay at low power (video decoding is done efficiently inside the fixed function HW and doesn't need high clocks even for high bitrate streams), but just occasionally the pipeline is more complex than a video decode and we need a smidgen of extra GPU power to present on time. In the high power regime, we sample at sub frame intervals with a bias to upclocking, and conversely at low power we sample over a few frames worth to provide what we consider to be the right levels of responsiveness respectively. At low power, we more or less expect to be kicked out to high power at the start of a busy sequence by waitboosting. Prior to commit e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active request") whenever we missed the frame or stalled, we would immediate go full throttle and upclock the GPU to max. But in commit e9af4ea2b9e7, we relaxed the waitboosting to only apply if the pipeline was deep to avoid over-committing resources for a near miss. Sadly though, a near miss is still a miss, and perceptible as jitter in the frame delivery. To try and prevent the near miss before having to resort to boosting after the fact, we use the pageflip queue as an indication that we are in an "interactive" regime and so should sample the load more frequently to provide power before the frame misses it vblank. This will make us more favorable to providing a small power increase (one or two bins) as required rather than going all the way to maximum and then having to work back down again. (We still keep the waitboosting mechanism around just in case a dramatic change in system load requires urgent uplocking, faster than we can provide in a few evaluation intervals.) v2: Reduce rps_set_interactive to a boolean parameter to avoid the confusion of what if they wanted a new power mode after pinning to a different mode (which to choose?) v3: Only reprogram RPS while the GT is awake, it will be set when we wake the GT, and while off warns about being used outside of rpm. v4: Fix deferred application of interactive mode v5: s/state/interactive/ v6: Group the mutex with its principle in a substruct Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107111 Fixes: e9af4ea2b9e7 ("drm/i915: Avoid waitboosting on the active request") 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: Radoslaw Szwichtenberg <radoslaw.szwichtenberg@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180731132629.3381-1-chris@chris-wilson.co.uk (cherry picked from commit 60548c554be2830d29d2533dad0ac8133347ee51) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-14drm/i915/execlists: Drop clear_gtiir() on GPU resetChris Wilson1-3/+3
With the new CSB processing code, we are not vulnerable to delayed delivery of a pre-reset interrupt as we use the CSB status pointers in the HWSP to decide if we need to parse any CSB events and no longer need to wait for the first post-reset interrupt to be assured that the CSB mmio registers are valid. The new icl code to clear registers has a nasty lock inversion: [ 57.409776] ====================================================== [ 57.409779] WARNING: possible circular locking dependency detected [ 57.409783] 4.18.0-rc4-CI-CI_DII_1137+ #1 Tainted: G U W [ 57.409785] ------------------------------------------------------ [ 57.409788] swapper/6/0 is trying to acquire lock: [ 57.409790] 000000004f304ee5 (&engine->timeline.lock/1){-.-.}, at: execlists_submit_request+0x2b/0x1a0 [i915] [ 57.409841] but task is already holding lock: [ 57.409844] 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915] [ 57.409869] which lock already depends on the new lock. [ 57.409872] the existing dependency chain (in reverse order) is: [ 57.409876] -> #2 (&(&rq->lock)->rlock#2){-.-.}: [ 57.409900] notify_ring+0x2b2/0x480 [i915] [ 57.409922] gen8_cs_irq_handler+0x39/0xa0 [i915] [ 57.409943] gen11_irq_handler+0x2f0/0x420 [i915] [ 57.409949] __handle_irq_event_percpu+0x42/0x370 [ 57.409952] handle_irq_event_percpu+0x2b/0x70 [ 57.409956] handle_irq_event+0x2f/0x50 [ 57.409959] handle_edge_irq+0xe7/0x190 [ 57.409964] handle_irq+0x67/0x160 [ 57.409967] do_IRQ+0x5e/0x120 [ 57.409971] ret_from_intr+0x0/0x1d [ 57.409974] _raw_spin_unlock_irqrestore+0x4e/0x60 [ 57.409979] tasklet_action_common.isra.5+0x47/0xb0 [ 57.409982] __do_softirq+0xd9/0x505 [ 57.409985] irq_exit+0xa9/0xc0 [ 57.409988] do_IRQ+0x9a/0x120 [ 57.409991] ret_from_intr+0x0/0x1d [ 57.409995] cpuidle_enter_state+0xac/0x360 [ 57.409999] do_idle+0x1f3/0x250 [ 57.410004] cpu_startup_entry+0x6a/0x70 [ 57.410010] start_secondary+0x19d/0x1f0 [ 57.410015] secondary_startup_64+0xa5/0xb0 [ 57.410018] -> #1 (&(&dev_priv->irq_lock)->rlock){-.-.}: [ 57.410081] clear_gtiir+0x30/0x200 [i915] [ 57.410116] execlists_reset+0x6e/0x2b0 [i915] [ 57.410140] i915_reset_engine+0x111/0x190 [i915] [ 57.410165] i915_handle_error+0x11a/0x4a0 [i915] [ 57.410198] i915_hangcheck_elapsed+0x378/0x530 [i915] [ 57.410204] process_one_work+0x248/0x6c0 [ 57.410207] worker_thread+0x37/0x380 [ 57.410211] kthread+0x119/0x130 [ 57.410215] ret_from_fork+0x3a/0x50 [ 57.410217] -> #0 (&engine->timeline.lock/1){-.-.}: [ 57.410224] _raw_spin_lock_irqsave+0x33/0x50 [ 57.410256] execlists_submit_request+0x2b/0x1a0 [i915] [ 57.410289] submit_notify+0x8d/0x124 [i915] [ 57.410314] __i915_sw_fence_complete+0x81/0x250 [i915] [ 57.410339] dma_i915_sw_fence_wake+0xd/0x20 [i915] [ 57.410344] dma_fence_signal_locked+0x79/0x200 [ 57.410368] notify_ring+0x2ba/0x480 [i915] [ 57.410392] gen8_cs_irq_handler+0x39/0xa0 [i915] [ 57.410416] gen11_irq_handler+0x2f0/0x420 [i915] [ 57.410421] __handle_irq_event_percpu+0x42/0x370 [ 57.410425] handle_irq_event_percpu+0x2b/0x70 [ 57.410428] handle_irq_event+0x2f/0x50 [ 57.410432] handle_edge_irq+0xe7/0x190 [ 57.410436] handle_irq+0x67/0x160 [ 57.410439] do_IRQ+0x5e/0x120 [ 57.410445] ret_from_intr+0x0/0x1d [ 57.410449] cpuidle_enter_state+0xac/0x360 [ 57.410453] do_idle+0x1f3/0x250 [ 57.410456] cpu_startup_entry+0x6a/0x70 [ 57.410460] start_secondary+0x19d/0x1f0 [ 57.410464] secondary_startup_64+0xa5/0xb0 [ 57.410466] other info that might help us debug this: [ 57.410471] Chain exists of: &engine->timeline.lock/1 --> &(&dev_priv->irq_lock)->rlock --> &(&rq->lock)->rlock#2 [ 57.410481] Possible unsafe locking scenario: [ 57.410485] CPU0 CPU1 [ 57.410487] ---- ---- [ 57.410490] lock(&(&rq->lock)->rlock#2); [ 57.410494] lock(&(&dev_priv->irq_lock)->rlock); [ 57.410498] lock(&(&rq->lock)->rlock#2); [ 57.410503] lock(&engine->timeline.lock/1); [ 57.410506] *** DEADLOCK *** [ 57.410511] 4 locks held by swapper/6/0: [ 57.410514] #0: 0000000074575789 (&(&dev_priv->irq_lock)->rlock){-.-.}, at: gen11_irq_handler+0x8a/0x420 [i915] [ 57.410542] #1: 000000009b29b30e (rcu_read_lock){....}, at: notify_ring+0x1a/0x480 [i915] [ 57.410573] #2: 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915] [ 57.410601] #3: 000000009b29b30e (rcu_read_lock){....}, at: submit_notify+0x35/0x124 [i915] [ 57.410635] stack backtrace: [ 57.410640] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G U W 4.18.0-rc4-CI-CI_DII_1137+ #1 [ 57.410644] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.2222.A01.1805300339 05/30/2018 [ 57.410650] Call Trace: [ 57.410652] <IRQ> [ 57.410657] dump_stack+0x67/0x9b [ 57.410662] print_circular_bug.isra.16+0x1c8/0x2b0 [ 57.410666] __lock_acquire+0x1897/0x1b50 [ 57.410671] ? lock_acquire+0xa6/0x210 [ 57.410674] lock_acquire+0xa6/0x210 [ 57.410706] ? execlists_submit_request+0x2b/0x1a0 [i915] [ 57.410711] _raw_spin_lock_irqsave+0x33/0x50 [ 57.410741] ? execlists_submit_request+0x2b/0x1a0 [i915] [ 57.410769] execlists_submit_request+0x2b/0x1a0 [i915] [ 57.410774] ? _raw_spin_unlock_irqrestore+0x39/0x60 [ 57.410804] submit_notify+0x8d/0x124 [i915] [ 57.410828] __i915_sw_fence_complete+0x81/0x250 [i915] [ 57.410854] dma_i915_sw_fence_wake+0xd/0x20 [i915] [ 57.410858] dma_fence_signal_locked+0x79/0x200 [ 57.410882] notify_ring+0x2ba/0x480 [i915] [ 57.410907] gen8_cs_irq_handler+0x39/0xa0 [i915] [ 57.410933] gen11_irq_handler+0x2f0/0x420 [i915] [ 57.410938] __handle_irq_event_percpu+0x42/0x370 [ 57.410943] handle_irq_event_percpu+0x2b/0x70 [ 57.410947] handle_irq_event+0x2f/0x50 [ 57.410951] handle_edge_irq+0xe7/0x190 [ 57.410955] handle_irq+0x67/0x160 [ 57.410958] do_IRQ+0x5e/0x120 [ 57.410962] common_interrupt+0xf/0xf [ 57.410965] </IRQ> [ 57.410969] RIP: 0010:cpuidle_enter_state+0xac/0x360 [ 57.410972] Code: 44 00 00 31 ff e8 84 93 91 ff 45 84 f6 74 12 9c 58 f6 c4 02 0f 85 31 02 00 00 31 ff e8 7d 30 98 ff e8 e8 0e 94 ff fb 4c 29 fb <48> ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7 ea b8 ff [ 57.411015] RSP: 0018:ffffc90000133e90 EFLAGS: 00000216 ORIG_RAX: ffffffffffffffdd [ 57.411023] RAX: ffff8804ae748040 RBX: 000000000002a97d RCX: 0000000000000000 [ 57.411029] RDX: 0000000000000046 RSI: ffffffff82141263 RDI: ffffffff820f05a7 [ 57.411035] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000 [ 57.411041] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8229f078 [ 57.411045] R13: ffff8804ab2adfa8 R14: 0000000000000000 R15: 0000000d5de092e3 [ 57.411052] do_idle+0x1f3/0x250 [ 57.411055] cpu_startup_entry+0x6a/0x70 [ 57.411059] start_secondary+0x19d/0x1f0 [ 57.411064] secondary_startup_64+0xa5/0xb0 The easiest remedy is to remove the defunct code. Fixes: ff047a87cfac ("drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11") References: fd8526e50902 ("drm/i915/execlists: Trust the CSB") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180713203529.1973-3-chris@chris-wilson.co.uk
2018-07-13drm/i915: Print the long_mask alongside the pin_maskVille Syrjälä1-2/+2
We're printing out which pins got a hotplug, so why not also print out which pins detected the long pulse as opposed to a short pulse. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-9-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-07-13drm/i915: Pass hpd_pin to long_pulse_detect()Ville Syrjälä1-50/+45
We're doing a pointless translation from hpd_pin to port simply for passing the thing to long_pulse_detect(). Let's pass the hpd_pin directly instead. This removes the assumption that the hpd_pin and port always match. The only other place where we make that assumption anymore is intel_hpd_pin_default() and that's fine as it's what determines the relationship between the two. If we ever get hardware where the hpd pins are wired in more interesting ways it should be trivial to handle from now on. This should also fix the IS_CNL_WITH_PORT_F() case as that mapped pin E back to port F and passed that to spt_port_hotplug2_long_detect() which would always return false for port F. Now that we pass in pin E directly it'll actually do the right thing. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Fixes: cf53902f48c3 ("drm/i915/cnl: Add HPD support for Port F.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-7-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-13drm/i915: s/int i/enum hpd_pin pin/Ville Syrjälä1-6/+6
Use the enum hpd_pin type when talking about HPD pins, and rename the variable from a very nondescript 'i' to 'pin', a name we already use in other parts of the code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-6-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-06drm/i915: Remove support for legacy debugfs crc interfaceMaarten Lankhorst1-57/+22
This interface is deprecated, and has been replaced by the upstream drm crc interface. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Tomi Sarvela <tomi.p.sarvela@intel.com> Cc: Petri Latvala <petri.latvala@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Acked-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628072303.14175-1-maarten.lankhorst@linux.intel.com
2018-07-04drm/i915: Unmask and enable master error interrupt on gen2/3Ville Syrjälä1-2/+6
For whatever reason we only unmask and enable the master error interrut on gen4. With the EIR handling fixed let's do that on gen2/3 as well. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-4-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2018-07-04drm/i915: Fix pre-ILK error interrupt ackVille Syrjälä1-9/+96
Adjust the EIR clearing to cope with the edge triggered IIR on i965/g4x. To guarantee an edge in the ISR master error bit we temporarily mask everything in EMR. As some of the EIR bits can't even be directly cleared we also borrow a trick from i915_clear_error_registers() and permanently mask any bit that remains high. No real thought given to how we might unmask them again once the cause for the error has been clered. I suppose on pre-g4x GPU reset will reinitialize EMR from scratch. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-3-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2018-07-04drm/i915: Fix hotplug irq ack on i965/g4xVille Syrjälä1-2/+30
Just like with PIPESTAT, the edge triggered IIR on i965/g4x also causes problems for hotplug interrupts. To make sure we don't get the IIR port interrupt bit stuck low with the ISR bit high we must force an edge in ISR. Unfortunately we can't borrow the PIPESTAT trick and toggle the enable bits in PORT_HOTPLUG_EN as that act itself generates hotplug interrupts. Instead we just have to loop until we've cleared PORT_HOTPLUG_STAT, or we just give up and WARN. v2: Don't frob with PORT_HOTPLUG_EN Cc: stable@vger.kernel.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614175625.1615-1-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2018-06-29drm/i915/execlists: Trust the CSBChris Wilson1-8/+3
Now that we use the CSB stored in the CPU friendly HWSP, we do not need to track interrupts for when the mmio CSB registers are valid and can just check where we read up to last from the cached HWSP. This means we can forgo the atomic bit tracking from interrupt, and in the next patch it means we can check the CSB at any time. v2: Change the splitting inside reset_prepare, we only want to lose testing the interrupt in this patch, the next patch requires the change in locking 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/20180628201211.13837-8-chris@chris-wilson.co.uk
2018-06-29drm/i915/execlists: Process one CSB update at a timeChris Wilson1-3/+4
In the next patch, we will process the CSB events directly from the submission path, rather than only after a CS interrupt. Hence, we will no longer have the need for a loop until the has-interrupt bit is clear, and in the meantime can remove that small optimisation. v2: Tvrtko pointed out it was safer to unconditionally kick the tasklet after each irq, when assuming that the tasklet is called for each 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/20180628201211.13837-4-chris@chris-wilson.co.uk
2018-06-29drm/i915: Drop posting reads to flush master interruptsChris Wilson1-8/+1
We do not need to do a posting read of our uncached mmio write to re-enable the master interrupt lines after handling an interrupt, so don't. This saves us a slow UC read before we can process the interrupt, most noticeable in execlists where any stalls imposes extra latency on GPU command execution. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180628201211.13837-1-chris@chris-wilson.co.uk
2018-06-28drm/i915: Only signal from interrupt when requestedChris Wilson1-2/+6
Avoid calling dma_fence_signal() from inside the interrupt if we haven't enabled signaling on the request. 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/20180627201304.15817-4-chris@chris-wilson.co.uk
2018-06-28drm/i915: Move the irq_counter inside the spinlockChris Wilson1-2/+2
Rather than have multiple locked instructions inside the notify_ring() irq handler, move them inside the spinlock and reduce their intrinsic locking. 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/20180627201304.15817-3-chris@chris-wilson.co.uk
2018-06-28drm/i915: Only trigger missed-seqno checking next to boundaryChris Wilson1-1/+2
If we have more interrupts pending (because we know there are more breadcrumb signals before the completion), then we do not need to trigger an irq_seqno_barrier or even wakeup the task on this interrupt as there will be another. To allow some margin of error (we are trying to work around incoherent seqno after all), we wakeup the breadcrumb before the target as well as on the target. 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/20180627201304.15817-2-chris@chris-wilson.co.uk
2018-06-28drm/i915: Reduce spinlock hold time during notify_ring() interruptChris Wilson1-11/+21
By taking advantage of the RCU protection of the task struct, we can find the appropriate signaler under the spinlock and then release the spinlock before waking the task and signaling the fence. 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/20180627201304.15817-1-chris@chris-wilson.co.uk
2018-06-28drm/i915/icp: Add Interrupt SupportAnusha Srivatsa1-2/+132
This patch addresses Interrupts from south display engine (SDE). ICP has two registers - SHOTPLUG_CTL_DDI and SHOTPLUG_CTL_TC. Introduce these registers and their intended values. Introduce icp_irq_handler(). The icp_irq_postinstall() takes care of enabling all PCH interrupt sources, to unmask them as needed with SDEIMR, as is done done by ibx_irq_pre_postinstall() for earlier platforms. We do not need to explicitly call the ibx_irq_pre_postinstall(). Also, while changing these, s/CPT/PPT/CPT-CNP comment. v2: - remove redundant register defines.(Lucas) - Change register names to be more consistent with previous platforms (Lucas) v3: -Reorder bit defines to a more appropriate location. Change the comments. Confirm in the commit message that icp_irq_postinstall() need not go to ibx_irq_pre_postinstall() and ibx_irq_postinstall() as in earlier platforms. (Paulo) Cc: Lucas De Marchi <lucas.de.marchi@gmail.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> [Paulo: coding style bikesheds and rebases]. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1530046343-30649-1-git-send-email-anusha.srivatsa@intel.com
2018-06-19drm/i915/icl: Handle hotplug interrupts for DP over TBTDhinakaran Pandiyan1-13/+36
This patch enables hotplug interrupts for DP over TBT output on TC ports. The TBT interrupts are enabled and handled irrespective of the actual output type which could be DP Alternate, DP over TBT, native DP or native HDMI. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-3-paulo.r.zanoni@intel.com
2018-06-19drm/i915/icl: Support for TC North Display interruptsDhinakaran Pandiyan1-3/+92
The hotplug interrupts for the ports can be routed to either North Display or South Display depending on the output mode. DP Alternate or DP over TBT outputs will have hotplug interrupts routed to the North Display while interrupts for legacy modes will be routed to the South Display in PCH. This patch adds hotplug interrupt handling support for DP Alternate mode. Cc: Jani Nikula <jani.nikula@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> [Paulo: coding style changes] Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-2-paulo.r.zanoni@intel.com
2018-06-19drm/i915/icl: GSE interrupt moves from DE_MISC to GU_MISCDhinakaran Pandiyan1-1/+45
The Graphics System Event(GSE) interrupt bit has a new location in the GU_MISC_INTERRUPT_{IIR, ISR, IMR, IER} registers. Since GSE was the only DE_MISC interrupt that was enabled, with this change we don't enable/handle any of DE_MISC interrupts for gen11. Credits to Paulo for pointing out the register change. v2: from DK raw_reg_[read/write], branch prediction hint and drop platform check (Mika) v3: From DK Early re-enable of master interrupt (Chris) Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> [Paulo: bikesheds and rebases] Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180616000530.5357-1-paulo.r.zanoni@intel.com
2018-06-14drm/i915: Fix PIPESTAT irq ack on i965/g4xVille Syrjälä1-2/+10
On i965/g4x IIR is edge triggered. So in order for IIR to notice that there is still a pending interrupt we have to force and edge in ISR. For the ISR/IIR pipe event bits we can do that by temporarily clearing all the PIPESTAT enable bits when we ack the status bits. This will force the ISR pipe event bit low, and it can then go back high when we restore the PIPESTAT enable bits. This avoids the following race: 1. stat = read(PIPESTAT) 2. an enabled PIPESTAT status bit goes high 3. write(PIPESTAT, enable|stat); 4. write(IIR, PIPE_EVENT) The end result is IIR==0 and ISR!=0. This can lead to nasty vblank wait/flip_done timeouts if another interrupt source doesn't trick us into looking at the PIPESTAT status bits despite the IIR PIPE_EVENT bit being low. Before i965 IIR was level triggered so this problem can't actually happen there. And curiously VLV/CHV went back to the level triggered scheme as well. But for simplicity we'll use the same i965/g4x compatible code for all platforms. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106033 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105225 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106030 Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611200258.27121-1-ville.syrjala@linux.intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
2018-06-13drm/i915/icl: DP_AUX_E is valid on ICL+James Ausmus1-0/+6
Add support for DP_AUX_E. Here we also introduce the bits for the AUX power well E, however ICL power well support is still not enabled yet, so the power well is not used. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: James Ausmus <james.ausmus@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180612002512.29783-2-paulo.r.zanoni@intel.com
2018-06-02drm/i915/icl: Extend AUX F interrupts to ICLDhinakaran Pandiyan1-2/+3
ICL has AUX F. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180522002558.29262-2-paulo.r.zanoni@intel.com
2018-04-25drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11Oscar Mateo1-3/+3
Interrupt handling in Gen11 is quite different from previous platforms. v2: Rebased (Michel) v3: Rebased with wiggle v4: Rebased, remove TODO warning correctly (Daniele) v5: Rebased, made gen11_gtiir const while at it (Michel) v6: Rebased v7: Adapt to the style currently in upstream Suggested-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/1524605995-22324-1-git-send-email-oscar.mateo@intel.com
2018-04-21drm/i915/psr: Control PSR interrupts via debugfsDhinakaran Pandiyan1-39/+12
Interrupts other than the one for AUX errors are required only for debug, so unmask them via debugfs when the user requests debug. User can make such a request with echo 1 > <DEBUG_FS>/dri/0/i915_edp_psr_debug There are no locks to serialize PSR debug enabling from irq_postinstall() and debugfs for simplicity. As irq_postinstall() is called only during module initialization/resume and IGT subtests aren't expected to modify PSR debug at those times, we should be safe. v2: Unroll loops (Ville) Avoid resetting error mask bits. v3: Unmask interrupts in postinstall() if debug was still enabled. Avoid RMW (Ville) v4: Avoid extra IMR write introduced in the previous version.(Jose) Style changes, renames (Jose). Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405013717.24254-1-dhinakaran.pandiyan@intel.com
2018-04-21drm/i915: Enable edp psr error interrupts on bdw+Ville Syrjälä1-13/+44
Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr on any transcoder in theory, though the we don't currenty enable PSR except on the EDP transcoder. v2: From DK * Rebased on drm-tip v3: Switched author to Ville based on IRC discussion. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180403212420.25007-2-dhinakaran.pandiyan@intel.com
2018-04-21drm/i915: Enable edp psr error interrupts on hswDaniel Vetter1-0/+34
The definitions for the error register should be valid on bdw/skl too, but there we haven't even enabled DE_MISC handling yet. Somewhat confusing the the moved register offset on bdw is only for the _CTL/_AUX register, and that _IIR/IMR stayed where they have been on bdw. v2: Fixes from Ville. v3: From DK * Rebased on drm-tip * Removed BDW IIR bit definition, looks like an unintentional change that should be in the following patch. v4: From DK * Don't mask REG_WRITE. References: bspec/11974 [SRD Interrupt Bit Definition DevHSW] Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405220023.9449-1-dhinakaran.pandiyan@intel.com
2018-04-07drm/i915: Pass the set of guilty engines to i915_reset()Chris Wilson1-4/+8
Currently, we rely on inspecting the hangcheck state from within the i915_reset() routines to determine which engines were guilty of the hang. This is problematic for cases where we want to run i915_handle_error() and call i915_reset() independently of hangcheck. Instead of relying on the indirect parameter passing, turn it into an explicit parameter providing the set of stalled engines which then are treated as guilty until proven innocent. While we are removing the implicit stalled parameter, also make the reason into an explicit parameter to i915_reset(). We still need a back-channel for i915_handle_error() to hand over the task to the locked waiter, but let's keep that its own channel rather than incriminate another. This leaves stalled/seqno as being private to hangcheck, with no more nefarious snooping by reset, be it whole-device or per-engine. \o/ The only real issue now is that this makes it crystal clear that we don't actually do any testing of hangcheck per se in drv_selftest/live_hangcheck, merely of resets! Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406220354.18911-2-chris@chris-wilson.co.uk
2018-04-06drm/i915/icl: Deal with GT INT DW correctlyOscar Mateo1-37/+73
BSpec says: "Second level interrupt events are stored in the GT INT DW. GT INT DW is a double buffered structure. A snapshot of events is taken when SW reads GT INT DW. From the time of read to the time of SW completely clearing GT INT DW (to indicate end of service), all incoming interrupts are logged in a secondary storage structure. this guarantees that the record of interrupts SW is servicing will not change while under service". We read GT INT DW in several places now: - The IRQ handler (banks 0 and 1) where, hopefully, it is completely cleared (operation now covered with the irq lock). - The 'reset' interrupts functions for RPS and GuC logs, where we clear the bit we are interested in and leave the others for the normal interrupt handler. - The 'enable' interrupts functions for RPS and GuC logs, as a measure of precaution. Here we could relax a bit and don't check GT INT DW at all or, if we do, at least we should clear the offending bit (which is what this patch does). Note that, if every bit is cleared on reading GT INT DW, the register won't be locked. Also note that, according to the BSpec, GT INT DW cannot be cleared without first servicing the Selector & Shared IIR registers. v2: - Remove some code duplication (Tvrtko) - Make sure GT_INTR_DW are protected by the irq spinlock, since it's a global resource (Tvrtko) v3: Optimize the spinlock (Tvrtko) v4: Rebase. v5: - take spinlock on outer scope to please sparse (Mika) - use raw_reg accessors (Mika) v6: omit the continue in looping banks (Michel) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v4) Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406093237.14548-1-mika.kuoppala@linux.intel.com
2018-04-06drm/i915/icl: Handle RPS interrupts correctly for Gen11Oscar Mateo1-11/+62
Using the new hierarchical interrupt infrastructure. v2: Rebase v3: Rebase v4: use class/instance handler (Mika) Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-3-mika.kuoppala@linux.intel.com
2018-04-06drm/i915/icl: Use hw engine class, instance to find irq handlerMika Kuoppala1-46/+53
Interrupt identity register we already read from hardware contains engine class and instance fields. Leverage these fields to find correct engine to handle the interrupt. v3: rebase on top of rps intr use correct class / instance limits (Michel) v4: split engine/other handling v5: empty iir is not err (Daniele, Michel) Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180406093145.14389-1-mika.kuoppala@linux.intel.com
2018-03-22drm/i915: Use full serialisation around engine->irq_postedChris Wilson1-4/+3
Using engine->irq_posted for execlists, we are not always serialised by the tasklet as we supposed. On the reset paths, the tasklet is disabled and ignored. Instead, we manipulate the engine->irq_posted directly to account for the reset, but if an interrupt fired before the reset and so wrote to engine->irq_posted, that write may not be flushed from the local CPU's cacheline until much later as the tasklet is already active and so does not generate a mb(). To correctly serialise the interrupt with reset, we need serialisation on the set_bit() itself. And at last Mika can be happy. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> CC: Michel Thierry <michel.thierry@intel.com> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Jeff McGee <jeff.mcgee@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180322073533.5313-3-chris@chris-wilson.co.uk
2018-03-20drm/i915: Add control flags to i915_handle_error()Chris Wilson1-23/+32
Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. v2: Pass msg down to i915_reset/i915_reset_engine so that we include the reason for the reset in the dev_notice(), superseding the earlier option to not print that notice. v3: Stash the reason inside the i915->gpu_error to handover to the direct reset from the blocking waiter. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jeff McGee <jeff.mcgee@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180320100449.1360-2-chris@chris-wilson.co.uk
2018-03-19drm/i915: Trim error mask to known enginesChris Wilson1-0/+1
For the convenience of userspace passing in an arbitrary reset mask, remove unknown engines from the set of engines that are to be reset. This means that we always follow a per-engine reset with a full-device reset when userspace writes -1 into debugfs/i915_wedged. Reported-by: Michał Winiarski <michal.winiarski@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316215001.12391-1-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com>
2018-03-10drm/i915/guc: Move GuC notification handling to separate functionMichal Wajdeczko1-31/+2
To allow future code reuse. While here, fix comment style. v2: Notifications are a separate thing - rename the handler (Sagar) Suggested-by: Oscar Mateo <oscar.mateo@intel.com> Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by: Michał Winiarski <michal.winiarski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Oscar Mateo <oscar.mateo@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> 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/20180308154707.21716-3-michal.winiarski@intel.com
2018-03-09drm/i915: Push irq_shift from gen8_cs_irq_handler() to callerChris Wilson1-22/+16
Originally we were inlining gen8_cs_irq_handler() and so expected the compiler to constant-fold away the irq_shift (so we had hardcoded it as opposed to use engine->irq_shift). However, we dropped the inline given the proliferation of gen8_cs_irq_handler()s. If we pull the shifting of the iir into the caller, we can shrink the code still further: add/remove: 0/0 grow/shrink: 0/3 up/down: 0/-34 (-34) Function old new delta gen8_cs_irq_handler 123 118 -5 gen8_gt_irq_handler 261 248 -13 gen11_irq_handler 722 706 -16 v2: Drop gen11_cs_irq_handler now that it is a simple stub around gen8_cs_irq_handler (Daniele) References: 5d3d69d5c119 ("drm/i915: Stop inlining the execlists IRQ handler") 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> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180309010808.11921-1-chris@chris-wilson.co.uk
2018-03-08drm/i915: Handle pipe CRC around enabling/disabling pipe.Maarten Lankhorst1-2/+2
This will get rid of the following error: [ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730311] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel crct10dif_pclmul snd_hda_codec crc32_pclmul snd_hwdep broadcom ghash_clmulni_intel snd_hda_core bcm_phy_lib snd_pcm tg3 lpc_ich mei_me mei prime_numbers [ 74.730353] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 4.16.0-rc2-CI-CI_DRM_3822+ #1 [ 74.730355] Hardware name: Dell Inc. XPS 8300 /0Y2MRG, BIOS A06 10/17/2011 [ 74.730359] RIP: 0010:drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730361] RSP: 0018:ffff88022fb03d10 EFLAGS: 00010086 [ 74.730365] RAX: ffffffffa0291d20 RBX: ffff88021a180000 RCX: 0000000000000001 [ 74.730367] RDX: ffffffff820e7db8 RSI: 0000000000000001 RDI: ffffffff82068cea [ 74.730369] RBP: ffff88022fb03d70 R08: 0000000000000000 R09: ffffffff815d26d0 [ 74.730371] R10: 0000000000000000 R11: ffffffffa0161ca0 R12: 0000000000000001 [ 74.730373] R13: ffff880212448008 R14: ffff880212448330 R15: 0000000000000000 [ 74.730376] FS: 0000000000000000(0000) GS:ffff88022fb00000(0000) knlGS:0000000000000000 [ 74.730378] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 74.730380] CR2: 000055edcbec9000 CR3: 0000000002210001 CR4: 00000000000606e0 [ 74.730382] Call Trace: [ 74.730385] <IRQ> [ 74.730397] drm_get_last_vbltimestamp+0x36/0x50 [ 74.730401] drm_update_vblank_count+0x64/0x240 [ 74.730409] drm_crtc_accurate_vblank_count+0x41/0x90 [ 74.730453] display_pipe_crc_irq_handler+0x176/0x220 [i915] [ 74.730497] i9xx_pipe_crc_irq_handler+0xfe/0x150 [i915] [ 74.730537] ironlake_irq_handler+0x618/0xa30 [i915] [ 74.730548] __handle_irq_event_percpu+0x3c/0x340 [ 74.730556] handle_irq_event_percpu+0x1b/0x50 [ 74.730561] handle_irq_event+0x2f/0x50 [ 74.730566] handle_edge_irq+0xe4/0x1b0 [ 74.730572] handle_irq+0x11/0x20 [ 74.730576] do_IRQ+0x5e/0x120 [ 74.730584] common_interrupt+0x84/0x84 [ 74.730586] </IRQ> [ 74.730591] RIP: 0010:cpuidle_enter_state+0xaa/0x350 [ 74.730593] RSP: 0018:ffffc9000008beb8 EFLAGS: 00000212 ORIG_RAX: ffffffffffffffde [ 74.730597] RAX: ffff880226b80040 RBX: 000000000031fc3e RCX: 0000000000000001 [ 74.730599] RDX: 0000000000000000 RSI: ffffffff8210fb59 RDI: ffffffff820c02e7 [ 74.730601] RBP: 0000000000000004 R08: 00000000000040af R09: 0000000000000018 [ 74.730603] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000004 [ 74.730606] R13: ffffe8ffffd00430 R14: 0000001166120bf4 R15: ffffffff82294460 [ 74.730621] ? cpuidle_enter_state+0xa6/0x350 [ 74.730629] do_idle+0x188/0x1d0 [ 74.730636] cpu_startup_entry+0x14/0x20 [ 74.730641] start_secondary+0x129/0x160 [ 74.730646] secondary_startup_64+0xa5/0xb0 [ 74.730660] Code: e1 48 c7 c2 b8 7d 0e 82 be 01 00 00 00 48 c7 c7 ea 8c 06 82 e8 64 ec ff ff 48 8b 83 c8 07 00 00 48 83 78 28 00 0f 84 e2 fe ff ff <0f> 0b 45 31 ed e9 db fe ff ff 41 b8 d3 4d 62 10 89 c8 6a 03 41 [ 74.730754] ---[ end trace 14b1345705b68565 ]--- Changes since v1: - Don't try to apply CRC workaround when enabling pipe, it should already be enabled. Changes since v2: - Make crc functions for !DEBUGFS case inline. - Pass intel_crtc to crc functions. - Add comments to callsites. Changes since v3: - Cache selected source to pipe_crc->source. - Set pipe_crc->skipped to MIN_INT during disable to close a race condition. Changes since v4: - Handle fallout from setting pipe_crc->source in irq handler. Cc: Marta Löfstedt <marta.lofstedt@intel.com> Reported-by: Marta Löfstedt <marta.lofstedt@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105185 Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180308120202.52446-1-maarten.lankhorst@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
2018-03-07drm/i915: Assert that the request is indeed complete when signaled from irqChris Wilson1-0/+1
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
2018-03-01drm/i915/icl: Interrupt handlingMika Kuoppala1-0/+235
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-02-21drm/i915: Rename drm_i915_gem_request to i915_requestChris Wilson1-4/+4
We want to de-emphasize the link between the request (dependency, execution and fence tracking) from GEM and so rename the struct from drm_i915_gem_request to i915_request. That is we may implement the GEM user interface on top of requests, but they are an abstraction for tracking execution rather than an implementation detail of GEM. (Since they are not tied to HW, we keep the i915 prefix as opposed to intel.) In short, the spatch: @@ @@ - struct drm_i915_gem_request + struct i915_request A corollary to contracting the type name, we also harmonise on using 'rq' shorthand for local variables where space if of the essence and repetition makes 'request' unwieldy. For globals and struct members, 'request' is still much preferred for its clarity. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180221095636.6649-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Acked-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2018-02-19drm/i915: Prune gen8_gt_irq_handlerChris Wilson1-30/+28
The compiler is not automatically caching the i915->regs address inside a register and emitting a load for every mmio access. For simple functions like gen8_gt_irq_handler that are already using the raw accessors, we can open-code them for substantial savings: add/remove: 0/0 grow/shrink: 0/2 up/down: 0/-83 (-83) Function old new delta gen8_gt_irq_handler 290 266 -24 gen8_gt_irq_ack 181 122 -59 Total: Before=954637, After=954554, chg -0.01% v2: Add raw_reg_read/raw_reg_write. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180219100926.16554-1-chris@chris-wilson.co.uk
2018-02-19drm/i915: Track GT interrupt handling using the master iirChris Wilson1-20/+31
Keep the master iir and use it to reduce the number of reads and writes to the GT iir array, i.e. only the bits marked as set by the master iir are valid inside GT iir array and will be handled during the interrupt. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180215073713.26985-1-chris@chris-wilson.co.uk
2018-02-15drm/i915: Estimate and update missed vblanks.Dhinakaran Pandiyan1-0/+12
The frame counter may have got reset between disabling and enabling vblank interrupts due to DMC putting the hardware to DC5/6 states if PSR was active. The frame counter could also have stalled if PSR was active in case there was no DMC. The frame counter resetting has a user visible impact of screen freezes. Make use of drm_vblank_restore() to compute missed vblanks for the duration in which vblank interrupts were disabled and update the vblank counter with this value as diff. There's no need to check if PSR was actually active in the interrupt disabled duration, so simplify the check to a feature check. Enabling vblank interrupts wakes up the hardware from DC5/6 and prevents it from going back again as long as the there are pending interrupts. So, we don't have to explicity disallow DC5/6 after enabling vblank interrupts to keep the counter running. This change is not applicable to CHV, as enabling interrupts does not prevent the hardware from activating PSR. v2: Added comments(Rodrigo) and rewrote commit message. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180203051302.9974-10-dhinakaran.pandiyan@intel.com
2018-02-02drm/i915: Remove spurious DRM_ERROR for cancelled interruptsChris Wilson1-26/+9
As we ourselves cancel interrupts during reset by clearing the GTIIR, it is possible for the master IIR to indicate a pending IRQ for which we have already cleared from the GTIIR. In this case, the DRM_ERROR are intended and should not be flagged as an error. 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: Ville Syrjälä <ville.syrjala@linux.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/20180202153448.23908-1-chris@chris-wilson.co.uk
2018-01-30drm/i915/cnl: Add HPD support for Port F.Rodrigo Vivi1-16/+19
On CNP boards that are using DDI F, bit 25 (SDE_PORTE_HOTPLUG_SPT) is representing the Digital Port F hotplug line when the Digital Port F hotplug detect input is enabled. v2: Reuse all existent structure instead of adding a new HPD_PORT_F pointing to pin of port E. v3: Use IS_CNL_WITH_PORT_F so we can start upstreaming this right now. If that SKU ever get a proper name we come back and update it. v4: Rebase on top of digital connected port using encoder instead of port. v5: Moved IS_CNL_WITH_PORT_F definition to the PCI IDs patch. Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-8-rodrigo.vivi@intel.com
2018-01-30drm/i915/cnl: Add AUX-F supportRodrigo Vivi1-0/+6
On some Cannonlake SKUs we have a dedicated Aux for port F, that is only the full split between port A and port E. There is still no Aux E for Port E, as in previous platforms, because port_E still means shared lanes with port A. v2: Rebase. v3: Add couple missed PORT_F cases on intel_dp. v4: Rebase and fix commit message. v5: Squash Imre's "drm/i915: Add missing AUX_F power well string" v6: Rebase on top of display headers rework. v7: s/IS_CANNONLAKE/IS_CNL_WITH_PORT_F (DK) v8: Fix Aux bits for Port F (DK) v9: Fix VBT definition of Port F (DK). v10: Squash power well addition to this patch to avoid warns as pointed by DK. v11: Clean up squashed commit message. (David) v12: Remove unnecessary handling for older platforms (DK) Adding AUX_F to PG2 following other existent ones. (DK) Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180129232223.766-2-rodrigo.vivi@intel.com
2018-01-24drm/i915/guc: Grab RPM wakelock while disabling GuC interruptsSagar Arun Kamble1-0/+6
Disabling GuC interrupts involves access to GuC IRQ control registers hence ensure device is RPM awake. v1-v2: old changelog 1: Add comment about need to synchronize flush work and log runtime destroy 2: Moved patch earlier in the series and removed comment about future work. (Tvrtko) v3: Added assert_rpm_wakelock_held() to gen9_*_guc_interrupts. (Chris) Signed-off-by: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@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/1516808821-3638-1-git-send-email-sagar.a.kamble@intel.com
2017-12-06drm/i915/guc: Introduce USES_GUC_xxx helper macrosMichal Wajdeczko1-1/+1
In the upcoming patch we will change the way how to recognize when GuC is in use. Using helper macros will minimize scope of that changes. While here, update dev_info message. Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@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/20171206135316.32556-3-michal.wajdeczko@intel.com
2017-11-30drm/i915: Tidy up signed/unsigned comparisonChris Wilson1-2/+2
drivers/gpu/drm/i915/i915_irq.c|3096 col 29| error: comparison between signed and unsigned integer expressions [-Werror=sign-compare] Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20171130125253.21405-1-chris@chris-wilson.co.uk Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
generated by cgit v1.2.3 (git 2.39.0) at 2025-03-09 11:01:29 +0300