| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
No functional change. Renaming the function to reflect the specific WA.
Suggested-by: Ville Syrjala <[email protected]>
Cc: Anusha Srivatsa <[email protected]>
Signed-off-by: Radhakrishna Sripada <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Currently we enable FEC even when DSC is no used. While that is
theoretically valid supposedly there isn't much of a benefit from
this. But more importantly we do not account for the FEC link
bandwidth overhead (2.4%) in the non-DSC link bandwidth computations.
So the code may think we have enough bandwidth when we in fact
do not.
Cc: [email protected]
Cc: Anusha Srivatsa <[email protected]>
Cc: Manasi Navare <[email protected]>
Fixes: 240999cf339f ("i915/dp/fec: Add fec_enable to the crtc state.")
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Manasi Navare <[email protected]>
|
|
As intel_runtime_pm_get/_put may be called from any blockable context,
we need to avoid allowing reclaim from our mallocs, as we need to
avoid tainting any mutexes held by the callers (as they may themselves
not allow for allocations as they are taken in the shrinker).
<4> [435.339331] WARNING: possible circular locking dependency detected
<4> [435.339364] 5.1.0-rc4-CI-Trybot_4116+ #1 Tainted: G U
<4> [435.339395] ------------------------------------------------------
<4> [435.339426] gem_caching/1334 is trying to acquire lock:
<4> [435.339456] 000000004505c39b (wakeref#3){+.+.}, at: intel_engine_pm_put+0x1b/0x40 [i915]
<4> [435.339788]
but task is already holding lock:
<4> [435.339819] 00000000ee77b4ed (fs_reclaim){+.+.}, at: fs_reclaim_acquire.part.24+0x0/0x30
<4> [435.339879]
which lock already depends on the new lock.
<4> [435.339918]
the existing dependency chain (in reverse order) is:
<4> [435.339952]
-> #1 (fs_reclaim){+.+.}:
<4> [435.339998] fs_reclaim_acquire.part.24+0x24/0x30
<4> [435.340035] kmem_cache_alloc_trace+0x2a/0x290
<4> [435.340311] __print_intel_runtime_pm_wakeref+0x24/0x160 [i915]
<4> [435.340590] untrack_intel_runtime_pm_wakeref+0x16e/0x1d0 [i915]
<4> [435.340869] intel_runtime_pm_put_unchecked+0xd/0x30 [i915]
<4> [435.341147] __intel_wakeref_put_once+0x22/0x40 [i915]
<4> [435.341508] i915_request_retire+0x477/0xaf0 [i915]
<4> [435.341871] ring_retire_requests+0x86/0x160 [i915]
<4> [435.342226] i915_retire_requests+0x58/0xc0 [i915]
<4> [435.342576] retire_work_handler+0x5b/0x70 [i915]
<4> [435.342615] process_one_work+0x245/0x610
<4> [435.342646] worker_thread+0x37/0x380
<4> [435.342679] kthread+0x119/0x130
<4> [435.342714] ret_from_fork+0x3a/0x50
<4> [435.342739]
-> #0 (wakeref#3){+.+.}:
<4> [435.342788] lock_acquire+0xa6/0x1c0
<4> [435.342822] __mutex_lock+0x8c/0x960
<4> [435.342853] atomic_dec_and_mutex_lock+0x33/0x50
<4> [435.343151] intel_engine_pm_put+0x1b/0x40 [i915]
<4> [435.343501] i915_request_retire+0x477/0xaf0 [i915]
<4> [435.343851] ring_retire_requests+0x86/0x160 [i915]
<4> [435.344202] i915_retire_requests+0x58/0xc0 [i915]
<4> [435.344543] i915_gem_shrink+0xd8/0x5b0 [i915]
<4> [435.344835] i915_drop_caches_set+0x17b/0x250 [i915]
<4> [435.344877] simple_attr_write+0xb0/0xd0
<4> [435.344911] full_proxy_write+0x51/0x80
<4> [435.344943] vfs_write+0xbd/0x1b0
<4> [435.344972] ksys_write+0x55/0xe0
<4> [435.345002] do_syscall_64+0x55/0x190
<4> [435.345040] entry_SYSCALL_64_after_hwframe+0x49/0xbe
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
During reset, we try and stop the active ring. This has the consequence
that we often clobber the RING registers within the context image. When
we find an active request, we update the context image to rerun that
request (if it was guilty, we replace the hanging user payload with
NOPs). However, we were ignoring an active context if the request had
completed, with the consequence that the next submission on that request
would start with RING_HEAD==0 and not the tail of the previous request,
causing all requests still in the ring to be rerun. Rare, but
occasionally seen within CI where we would spot that the context seqno
would reverse and complain that we were retiring an incomplete request.
<0> [412.390350] <idle>-0 3d.s2 408373352us : __i915_request_submit: rcs0 fence 1e95b:3640 -> current 3638
<0> [412.390350] <idle>-0 3d.s2 408373353us : __i915_request_submit: rcs0 fence 1e95b:3642 -> current 3638
<0> [412.390350] <idle>-0 3d.s2 408373354us : __i915_request_submit: rcs0 fence 1e95b:3644 -> current 3638
<0> [412.390350] <idle>-0 3d.s2 408373354us : __i915_request_submit: rcs0 fence 1e95b:3646 -> current 3638
<0> [412.390350] <idle>-0 3d.s2 408373356us : __execlists_submission_tasklet: rcs0 in[0]: ctx=2.1, fence 1e95b:3646 (current 3638), prio=4
<0> [412.390350] i915_sel-4613 0.... 408373374us : __i915_request_commit: rcs0 fence 1e95b:3648
<0> [412.390350] i915_sel-4613 0d..1 408373377us : process_csb: rcs0 cs-irq head=2, tail=3
<0> [412.390350] i915_sel-4613 0d..1 408373377us : process_csb: rcs0 csb[3]: status=0x00000001:0x00000000, active=0x1
<0> [412.390350] i915_sel-4613 0d..1 408373378us : __i915_request_submit: rcs0 fence 1e95b:3648 -> current 3638
<0> [412.390350] <idle>-0 3..s1 408373378us : execlists_submission_tasklet: rcs0 awake?=1, active=5
<0> [412.390350] i915_sel-4613 0d..1 408373379us : __execlists_submission_tasklet: rcs0 in[0]: ctx=2.2, fence 1e95b:3648 (current 3638), prio=4
<0> [412.390350] i915_sel-4613 0.... 408373381us : i915_reset_engine: rcs0 flags=4
<0> [412.390350] i915_sel-4613 0.... 408373382us : execlists_reset_prepare: rcs0: depth<-0
<0> [412.390350] <idle>-0 3d.s2 408373390us : process_csb: rcs0 cs-irq head=3, tail=4
<0> [412.390350] <idle>-0 3d.s2 408373390us : process_csb: rcs0 csb[4]: status=0x00008002:0x00000002, active=0x1
<0> [412.390350] <idle>-0 3d.s2 408373390us : process_csb: rcs0 out[0]: ctx=2.2, fence 1e95b:3648 (current 3640), prio=4
<0> [412.390350] i915_sel-4613 0.... 408373401us : intel_engine_stop_cs: rcs0
<0> [412.390350] i915_sel-4613 0d..1 408373402us : process_csb: rcs0 cs-irq head=4, tail=4
<0> [412.390350] i915_sel-4613 0.... 408373403us : intel_gpu_reset: engine_mask=1
<0> [412.390350] i915_sel-4613 0d..1 408373408us : execlists_cancel_port_requests: rcs0:port0 fence 1e95b:3648, (current 3648)
<0> [412.390350] i915_sel-4613 0.... 408373442us : intel_engine_cancel_stop_cs: rcs0
<0> [412.390350] i915_sel-4613 0.... 408373442us : execlists_reset_finish: rcs0: depth->0
<0> [412.390350] ksoftirq-26 3..s. 408373442us : execlists_submission_tasklet: rcs0 awake?=1, active=0
<0> [412.390350] ksoftirq-26 3d.s1 408373443us : process_csb: rcs0 cs-irq head=5, tail=5
<0> [412.390350] i915_sel-4613 0.... 408373475us : i915_request_retire: rcs0 fence 1e95b:3640, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373476us : i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3640, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373494us : __i915_request_commit: rcs0 fence 1e95b:3650
<0> [412.390350] i915_sel-4613 0d..1 408373496us : process_csb: rcs0 cs-irq head=5, tail=5
<0> [412.390350] i915_sel-4613 0d..1 408373496us : __i915_request_submit: rcs0 fence 1e95b:3650 -> current 3648
<0> [412.390350] i915_sel-4613 0d..1 408373498us : __execlists_submission_tasklet: rcs0 in[0]: ctx=2.1, fence 1e95b:3650 (current 3648), prio=6
<0> [412.390350] i915_sel-4613 0.... 408373500us : i915_request_retire_upto: rcs0 fence 1e95b:3648, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373500us : i915_request_retire: rcs0 fence 1e95b:3642, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373501us : i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3642, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373514us : i915_request_retire: rcs0 fence 1e95b:3644, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373515us : i915_request_retire: __retire_engine_request(rcs0) fence 1e95b:3644, current 3648
<0> [412.390350] i915_sel-4613 0.... 408373527us : i915_request_retire: rcs0 fence 1e95b:3646, current 3640
<0> [412.390350] <idle>-0 3..s1 408373569us : execlists_submission_tasklet: rcs0 awake?=1, active=1
<0> [412.390350] <idle>-0 3d.s2 408373569us : process_csb: rcs0 cs-irq head=5, tail=1
<0> [412.390350] <idle>-0 3d.s2 408373570us : process_csb: rcs0 csb[0]: status=0x00000001:0x00000000, active=0x1
<0> [412.390350] <idle>-0 3d.s2 408373570us : process_csb: rcs0 csb[1]: status=0x00000018:0x00000002, active=0x5
<0> [412.390350] <idle>-0 3d.s2 408373570us : process_csb: rcs0 out[0]: ctx=2.1, fence 1e95b:3650 (current 3650), prio=6
<0> [412.390350] <idle>-0 3d.s2 408373571us : process_csb: rcs0 completed ctx=2
<0> [412.390350] i915_sel-4613 0.... 408373621us : i915_request_retire: i915_request_retire:253 GEM_BUG_ON(!i915_request_completed(request))
v2: Fixup the cancellation path to drain the CSB and reset the pointers.
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Before causing guc and execlists to diverge further (breaking guc in the
process), take a copy of the current reset procedure and make it local to
the guc submission backend
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
On gen11 writing to read only ppgtt page causes a gpu hang.
This behaviour is different than with previous gen where
read only ppgtt access is supported. On those, the write
is just dropped without visible side effects.
Disable ro ppgtt support on gen11 until a solution can
be found to bring it into line with its predecessors.
References: HSDES#1807136187
References: https://bugzilla.freedesktop.org/show_bug.cgi?id=108569
Cc: Chris Wilson <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
As i915_requests are put into an RCU-freelist, they may get reused
before debugobjects notice them as being freed. On cleanup, explicitly
call i915_sw_fence_fini() so that the debugobject is properly tracked.
Reported-by: Mika Kuoppala <[email protected]>
Fixes: b7404c7ecb38 ("drm/i915: Bump ready tasks ahead of busywaits")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
No point in duplicating all this code when we can just
use a variable to hold the output bpp (the only thing
that differs between the two branches).
Cc: Anusha Srivatsa <[email protected]>
Cc: Manasi Navare <[email protected]>
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Manasi Navare <[email protected]>
|
|
6bpc is only legal for RGB and RAW pixel encodings. For the rest
the minimum is 8bpc. Set our lower limit accordingly.
Signed-off-by: Ville Syrjälä <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Reviewed-by: Dhinakaran Pandiyan <[email protected]>
|
|
Now when we can support variable csb fifo sizes, disable legacy mode.
By disabling legacy we hope to get better hw testing coverage by
assuming everyone else have switched over.
v2: rebase
References: https://bugs.freedesktop.org/show_bug.cgi?id=110338
Cc: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Cc: Kelvin Gardiner <[email protected]>
Cc: Paulo Zanoni <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Make csb entry count variable in preparation for larger
CSB status FIFO size found on gen11+ hardware.
v2: adapt to hwsp access only (Chris)
non continuous mmio (Daniele)
v3: entries (Chris), fix macro for checkpatch
v4: num_entries (Chris)
v5: consistency on num_entries
Cc: Daniele Ceraolo Spurio <[email protected]>
Cc: Chris Wilson <[email protected]>
Cc: Joonas Lahtinen <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
With gen11 the interrupt registers are shared between 2 engines,
with Engine1 instance being upper word and Engine0 instance being
lower. Annoyingly gen11 selected the pm interrupts to be in the
Engine1 instance.
Rectify the situation by shifting the access accordingly,
based on gen.
v2: comments, warn on overzealous rps_events
Bugzilla: https://bugzilla.freedesktop.org/show_bug.cgi?id=108059
Testcase: igt/i915_pm_rps@min-max-config-loaded
Cc: Chris Wilson <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There is no video turbo mode for gen11, so don't set it.
v2: inline (Chris)
v3: brackets (Chris)
Cc: Chris Wilson <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Enable media sampler powergate as recommended.
v2: use REG_BIT (Chris)
Cc: Chris Wilson <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
On gen11 the recommended rc6 threshold differs from previous
gens, apply it. Move the write to a correct spot in sequence.
v2: do write in 2b, fix bspec ref (Michal)
Bspec: 33149
Cc: Michal Wajdeczko <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Acked-by: Chris Wilson <[email protected]>
Reviewed-by: Michal Wajdeczko <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In order not to inflate gen9 rc6 enabling sequence with
gen11 specifics, use a separate function for it.
Signed-off-by: Mika Kuoppala <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Consider two tasks that are running in parallel on a pair of engines
(vcs0, vcs1), but then must complete on a shared engine (rcs0). To
maximise throughput, we want to run the first ready task on rcs0 (i.e.
the first task that completes on either of vcs0 or vcs1). When using
semaphores, however, we will instead queue onto rcs in submission order.
To resolve this incorrect ordering, we want to re-evaluate the priority
queue when each of the request is ready. Normally this happens because
we only insert into the priority queue requests that are ready, but with
semaphores we are inserting ahead of their readiness and to compensate
we penalize those tasks with reduced priority (so that tasks that do not
need to busywait should naturally be run first). However, given a series
of tasks that each use semaphores, the queue degrades into submission
fifo rather than readiness fifo, and so to counter this we give a small
boost to semaphore users as their dependent tasks are completed (and so
we no longer require any busywait prior to running the user task as they
are then ready themselves).
v2: Fixup irqsave for schedule_lock (Tvrtko)
Testcase: igt/gem_exec_schedule/semaphore-codependency
Signed-off-by: Chris Wilson <[email protected]>
Cc: Tvrtko Ursulin <[email protected]>
Cc: Dmitry Rogozhkin <[email protected]>
Cc: Dmitry Ermilov <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
On resume, we know that the only pinned contexts in danger of seeing
corruption are the kernel context, and so we do not need to walk the
list of all GEM contexts as we tracked them on each engine.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Currently we use force_dsc_enable to force DSC from IGT, but
we dont expose this value to userspace through debugfs.
This patch exposes this through the same dsc_fec_support
debugfs node per connector so that we can restore its value
back after the tests are completed.
Suggested-by: Imre Deak <[email protected]>
Cc: Imre Deak <[email protected]>
Cc: Lyude Paul <[email protected]>
Cc: Anusha Srivatsa <[email protected]>
Signed-off-by: Manasi Navare <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
There is a chance we can see spurious interrupts in live
now. We have more engines enabled and that with more elaborate
access patterns with pm and display, increases the chances
hardware just makes a social call, without anything to work on.
Remove the error as we have tests to actually probe if
we really miss interrupt, instead of getting spurious ones.
Note that now we do write to intr_dw even with a zero
value. This is considered advantegous as the write
is an ack that sw is done.
Cc: Chris Wilson <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Unlike previous gens, we already hold the irq_lock on
entering the rps handler so we can't use it as it is.
Make a gen11 specific rps interrupt handler without
locking.
v2: return early (Chris)
Cc: Chris Wilson <[email protected]>
Signed-off-by: Mika Kuoppala <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Commit 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast
and narrow") started to optize the eDP 1.4+ link config, both per spec
and as preparation for display stream compression support.
Sadly, we again face panels that flat out fail with parameters they
claim to support. Revert, and go back to the drawing board.
v2: Actually revert to max params instead of just wide-and-slow.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109959
Fixes: 7769db588384 ("drm/i915/dp: optimize eDP 1.4+ link config fast and narrow")
Cc: Ville Syrjälä <[email protected]>
Cc: Manasi Navare <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Cc: Matt Atwood <[email protected]>
Cc: "Lee, Shawn C" <[email protected]>
Cc: Dave Airlie <[email protected]>
Cc: [email protected]
Cc: <[email protected]> # v5.0+
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Manasi Navare <[email protected]>
Tested-by: Albert Astals Cid <[email protected]> # v5.0 backport
Tested-by: Emanuele Panigati <[email protected]> # v5.0 backport
Tested-by: Matteo Iervasi <[email protected]> # v5.0 backport
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Re-enable clock gating of DDI clocks.
v2: Fix the default ddi clk state for mipi-dsi (Imre)
Fixes: 1026bea00381 ("drm/i915/icl: Ungate DSI clocks")
Signed-off-by: Vandita Kulkarni <[email protected]>
Reviewed-by: Uma Shankar <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
IO enable sequencing needs ddi clocks enabled.
These clocks will be gated at a later point in
the enable sequence.
v2: Fix the commit header (Uma)
v3: Remove the redundant read (Ville)
Fixes: 949fc52af19e ("drm/i915/icl: add pll mapping for DSI")
Signed-off-by: Vandita Kulkarni <[email protected]>
Reviewed-by: Uma Shankar <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Circumvent the dance we currently perform to find the preempt_client and
lookup its HW context for this engine, as we know we have already pinned
the preempt_context on the engine.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
A couple of machines in the farm show quite frequent errors in the
powerwells not being released. Either there is an external agent
interferring with the powerwells, or the powerwell doesn't quite behave
as we anticipate -- either way, the test is not reliable enough to be
enabled by default in CI. It has served its immediate purpose in
providing coverage as we made tweaks to forcewake, so keep it available
for future testing.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110210
Signed-off-by: Chris Wilson <[email protected]>
Cc: Daniele Ceraolo Spurio <[email protected]>
Cc: Mika Kuoppala <[email protected]>
Reviewed-by: Daniele Ceraolo Spurio <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
This interlaced mode restriction applies to all gens, not only to
Haswell.
Also while at it updating the debug message to.
Cc: Dhinakaran Pandiyan <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Reviewed-by: Dhinakaran Pandiyan <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Even when driver is reloaded and hits this scenario the PSR mutex
should be initialized, otherwise reading PSR debugfs status will
execute mutex_lock() over a mutex that was not initialized.
Cc: Dhinakaran Pandiyan <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
PSR support for VLV and CHV was dropped in commit ce3508fd2a77
("drm/i915/psr: Nuke PSR support for VLV and CHV") so no need to keep
this registers around.
Cc: Dhinakaran Pandiyan <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Turn out it is not a DMC bug it is actually a HW one, so this
workaround will be needed for current gens, lets update the comment
and remove the FIXME.
BSpec: 7723
Cc: Dhinakaran Pandiyan <[email protected]>
Cc: Rodrigo Vivi <[email protected]>
Reviewed-by: Rodrigo Vivi <[email protected]>
Signed-off-by: José Roberto de Souza <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
The timeline is strictly ordered, so by inserting the timeline->barrier
request into the timeline->last_request it naturally provides the same
barrier. Consolidate the pair of barriers into one as they serve the
same purpose.
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
In order to avoid the malloc inside i915_globals_park() occurring
underneath a lock connected to the shrinker (thus causing circular
lockdeps warnings), move the rcu_worker to a global.
<4> [39.085073] ======================================================
<4> [39.085273] WARNING: possible circular locking dependency detected
<4> [39.085552] 5.1.0-rc3-CI-Trybot_4088+ #1 Tainted: G U
<4> [39.085752] ------------------------------------------------------
<4> [39.085949] kswapd0/32 is trying to acquire lock:
<4> [39.086121] 00000000004b5f91 (wakeref#3){+.+.}, at: intel_engine_pm_put+0x1b/0x40 [i915]
<4> [39.086493]
but task is already holding lock:
<4> [39.086682] 00000000dd009a9a (fs_reclaim){+.+.}, at: __fs_reclaim_acquire+0x0/0x30
<4> [39.086910]
which lock already depends on the new lock.
<4> [39.087139]
the existing dependency chain (in reverse order) is:
<4> [39.087356]
-> #2 (fs_reclaim){+.+.}:
<4> [39.087604] fs_reclaim_acquire.part.24+0x24/0x30
<4> [39.087785] kmem_cache_alloc_trace+0x2a/0x290
<4> [39.087998] i915_globals_park+0x22/0xa0 [i915]
<4> [39.088478] idle_work_handler+0x1df/0x220 [i915]
<4> [39.089016] process_one_work+0x245/0x610
<4> [39.089447] worker_thread+0x37/0x380
<4> [39.089956] kthread+0x119/0x130
<4> [39.090374] ret_from_fork+0x3a/0x50
<4> [39.090868]
-> #1 (wakeref#4){+.+.}:
<4> [39.091569] __mutex_lock+0x8c/0x960
<4> [39.092054] atomic_dec_and_mutex_lock+0x33/0x50
<4> [39.092521] intel_gt_pm_put+0x1b/0x40 [i915]
<4> [39.093047] intel_engine_park+0xeb/0x1d0 [i915]
<4> [39.093514] __intel_wakeref_put_once+0x10/0x30 [i915]
<4> [39.094062] i915_request_retire+0x477/0xaf0 [i915]
<4> [39.094547] ring_retire_requests+0x86/0x160 [i915]
<4> [39.095110] i915_retire_requests+0x58/0xc0 [i915]
<4> [39.095587] i915_gem_wait_for_idle.part.22+0xb2/0xf0 [i915]
<4> [39.096142] switch_to_kernel_context_sync+0x2a/0x70 [i915]
<4> [39.096633] i915_gem_init+0x59c/0x9c0 [i915]
<4> [39.097174] i915_driver_load+0xd96/0x1880 [i915]
<4> [39.097640] i915_pci_probe+0x29/0xa0 [i915]
<4> [39.098145] pci_device_probe+0xa1/0x120
<4> [39.098607] really_probe+0xf3/0x3e0
<4> [39.099031] driver_probe_device+0x10a/0x120
<4> [39.099599] device_driver_attach+0x4b/0x50
<4> [39.100033] __driver_attach+0x97/0x130
<4> [39.100525] bus_for_each_dev+0x74/0xc0
<4> [39.100954] bus_add_driver+0x13f/0x210
<4> [39.101441] driver_register+0x56/0xe0
<4> [39.101891] do_one_initcall+0x58/0x2e0
<4> [39.102319] do_init_module+0x56/0x1ea
<4> [39.102805] load_module+0x2701/0x29e0
<4> [39.103231] __se_sys_finit_module+0xd3/0xf0
<4> [39.103727] do_syscall_64+0x55/0x190
<4> [39.104153] entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4> [39.104736]
-> #0 (wakeref#3){+.+.}:
<4> [39.105437] lock_acquire+0xa6/0x1c0
<4> [39.105923] __mutex_lock+0x8c/0x960
<4> [39.106345] atomic_dec_and_mutex_lock+0x33/0x50
<4> [39.106897] intel_engine_pm_put+0x1b/0x40 [i915]
<4> [39.107375] i915_request_retire+0x477/0xaf0 [i915]
<4> [39.107930] ring_retire_requests+0x86/0x160 [i915]
<4> [39.108412] i915_retire_requests+0x58/0xc0 [i915]
<4> [39.108934] i915_gem_shrink+0xd8/0x5b0 [i915]
<4> [39.109431] i915_gem_shrinker_scan+0x59/0x130 [i915]
<4> [39.109884] do_shrink_slab+0x131/0x3e0
<4> [39.110380] shrink_slab+0x228/0x2c0
<4> [39.110810] shrink_node+0x177/0x460
<4> [39.111317] balance_pgdat+0x239/0x580
<4> [39.111743] kswapd+0x186/0x570
<4> [39.112221] kthread+0x119/0x130
<4> [39.112641] ret_from_fork+0x3a/0x50
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Replace the WARN with a simple if() + error message to squech the sparse
warning that entire wait_for() macro was being stringified:
drivers/gpu/drm/i915/intel_guc_submission.c:658:9: error: too long token expansion
Signed-off-by: Chris Wilson <[email protected]>
Reviewed-by: Tvrtko Ursulin <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
We can unconditionally release the power references during encoder
disabling. The references for each port used by the encoder are
guaranteed to be enabled at this point.
Cc: Vandita Kulkarni <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
Push getting the reference for the encoders' power domains into the
encoder get_power_domains() hook instead of doing this from the caller.
This way the encoder can store away the corresponding wakerefs.
This fixes the DSI encoder disabling, which didn't release these
power references it acquired during HW state readout.
Note that longtime ownership for the corresponding wakerefs can be thus
acquired / released in two ways. Nevertheless there is always only one
owner for them:
After HW readout (booting/system resume):
- encoder->get_power_domains() acquires
- encoder->disable*() releases
After a modeset (calling intel_atomic_commit()):
- encoder->enable*() acquires
- encoder->disable*() releases
* can be any of the encoder enable/disable hooks.
v2:
- Check that the DSI io_wakerefs are unset both during encoder HW
readout and enabling. (Chris)
Fixes: 0e6e0be4c9523 ("drm/i915: Markup paired operations on display power domains")
Cc: Vandita Kulkarni <[email protected]>
Cc: Chris Wilson <[email protected]>
Signed-off-by: Imre Deak <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
|
|
While transitioning to having better clarity between the modules, it's
desirable to have the function name prefixes reflect the
module. Functions in intel_foo.c should be prefixed intel_foo_.
Expose only one CDCLK init/uninit function from intel_cdclk.c instead of
one per platform. Obviously this adds one "unnecessary" if ladder within
the entry points. However it should be considered more of a CDCLK
implementation detail how this is done per platform, instead of exposing
the fact. In other words, abstract the CDCLK module better.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/f63ed6e129098a32c63735be6cffa4756e7947af.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/c128d7be3f621391e571e86b03f302f3ffd0ed2b.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/679c857a1933ee3d0706f978ab05ca880cd30a00.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/1ccf9000ad33b895aea06be41053a5b7bac8459e.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/5d54d02cf7b7bfe3f78ed60d28534c5726371af3.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/f44c21e3d154e47233ebef4267ce1a924fa38df7.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/b106b21ef11ff7fc34537b2c029a1332c8573fcc.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: revert intel_plane_destroy_state() movement within intel_atomic_plane.c
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/fd56c1cbba22b9f195ad944d79f7977423b2b533.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/357856c31e309f0af8eed0d800623a5253ff3a37.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/f86f9beed730eaad0bdcc18b18817b3d221e16e2.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/82d11bf634094f44a7469a096de3d3768314d6bc.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
v2: gen6_rps_reset_ei() is in i915_irq.c not intel_pm.c.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/adc6463b95eef3440fba9826793f7d1c5f3b0b4a.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/c9f02ae09123866bc55269175ab75e844ffbd6ac.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/8348620b32cb4438ccfb5f7bbe9a18ff6b7c48a0.1554461791.git.jani.nikula@intel.com
|
|
It used to be handy that we only had a couple of headers, but over time
intel_drv.h has become unwieldy. Extract declarations to a separate
header file corresponding to the implementation module, clarifying the
modularity of the driver.
Ensure the new header is self-contained, and do so with minimal further
includes, using forward declarations as needed. Include the new header
only where needed, and sort the modified include directives while at it
and as needed.
No functional changes.
Reviewed-by: Chris Wilson <[email protected]>
Acked-by: Joonas Lahtinen <[email protected]>
Signed-off-by: Jani Nikula <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/c507e15fef019541da5bb33f2fbe920a5ad2f3dc.1554461791.git.jani.nikula@intel.com
|