> -Original Message-
> From: Intel-gfx On Behalf Of Navare,
> Manasi
> Sent: Friday, November 13, 2020 1:15 AM
> To: Ville Syrjala
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 1/6] drm/i915: Move encoder->get_config to a
> new function
>
> On Thu, Nov 12, 20
> -Original Message-
> From: Intel-gfx On Behalf Of Navare,
> Manasi
> Sent: Friday, November 13, 2020 1:17 AM
> To: Ville Syrjala
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 2/6] drm/i915: Add a wrapper function around
> get_pipe_config
>
> On Thu, Nov 12,
We currently want to keep the interrupt enabled until the interrupt after
which we have no more work to do. This heuristic was broken by us
kicking the irq-work on adding a completed request without attaching a
signaler -- hence it appearing to the irq-worker that an interrupt had
fired when we wer
The issue with stale virtual breadcrumbs remain. Now we have the problem
that if the irq-signaler is still referencing the stale breadcrumb as we
transfer it to a new sibling, the list becomes spaghetti. This is a very
small window, but that doesn't stop it being hit infrequently. To
prevent the li
Lift the list iteration defines for traversing the signaler/waiter lists
into i915_scheduler.h for reuse.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 10 --
drivers/gpu/drm/i915/i915_scheduler_types.h | 10 ++
2 files changed, 10 insertions(+), 1
Allow us to validate mocs configurations after reset if we have either
engine or global reset.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_mocs.c | 40 +
1 file changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_
Inside schedule_out, we do extra work upon idling the context, such as
updating the runtime, kicking off retires, kicking virtual engines.
However, if we are in a series of processing single requests per
contexts, we may find ourselves scheduling out the context, only to
immediately schedule it bac
Use the wait_queue_entry.flags to denote the special fence behaviour
(flattening continuations along fence chains, and for propagating
errors) rather than trying to detect ordinary waiters by their
functions.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_sw_fence.c | 25 +
Include the active timelines for debugfs/i915_engine_info, so that we
can see which have unready requests inflight which are not shown
otherwise.
Suggested-by: Tvrtko Ursulin
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 79
drivers/gpu/drm/
The presumption was that some time would always elapse between recording
the start and the finish of a context switch. This turns out to be a
regular occurrence and emitting a debug statement superfluous.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 4
Currently we know that the timeline status page is at most a page in
size, and so we can preserve the lower 12bits of the offset when
relocating the status page in the GGTT. If we want to use a larger
object, such as the context state, we may not necessarily use a position
within the first page and
A quick test to verify that the backend accepts each type of timeline
and can use them to track and control request emission.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 93 +
1 file changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/i91
Since the introduction of preempt-to-busy, requests can complete in the
background, even while they are not on the engine->active.requests list.
As such, the engine->active.request list itself is not in strict
retirement order, and we have to scan the entire list while unwinding to
not miss any. Ho
Pull the repeated check for the last active request being completed to a
single spot, when deciding whether or not execlist preemption is
required.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ---
1 file changed, 4 insertions(+), 11 deletions(-)
diff --g
When pretty-printing the requests for debug, also show the status of any
semaphore waits as part of its runnable status.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/
Make b->signaled_requests a lockless-list so that we can manipulate it
outside of the b->irq_lock.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 34 ---
.../gpu/drm/i915/gt/intel_breadcrumbs_types.h | 2 +-
drivers/g
Relative timelines are relative to either the global or per-process
HWSP, and so we can replace the absolute addressing with store-index
variants for position invariance.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 110 +++
drivers/gpu/drm/i915/
Since preempt-to-busy, we may unsubmit a request while it is still on
the HW and completes asynchronously. That means it may be retired and in
the process destroy the virtual engine (as the user has closed their
context), but that engine may still be holding onto the unsubmitted
compelted request.
Extract i915_request_show for reuse in other request chain pretty
printers.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 47 ++-
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.h | 2 +-
drivers/gpu/dr
When we are not using semaphores with a context/engine, we can simply
reuse the same seqno location across wraps, but we still require each
timeline to have its own address. For LRC submission, each context is
prefixed by a per-process HWSP, which provides us with a unique location
for each context
Since schedule-in and schedule-out are now both always under the tasklet
bitlock, we can reduce the individual atomic operations to simple
instructions and worry less.
This notably eliminates the race observed with intel_context_inflight in
__engine_unpark().
Closes: https://gitlab.freedesktop.or
Move the register slow register write and readback from out of the
critical path for execlists submission and delay it until the following
worker, shaving off around 200us. Note that the same signal_irq_work() is
allowed to run concurrently on each CPU (but it will only be queued once,
once running
From: Tvrtko Ursulin
Include the signalers each request in the timeline is waiting on, as a
means to try and identify the cause of a stall. This can be quite
verbose, even as for now we only show each request in the timeline and
its immediate antecedents.
This generates output like:
Timeline 88
Rather than having special case code for opportunistically calling
process_csb() and performing a direct submit while holding the engine
spinlock for submitting the request, simply call the tasklet directly.
This allows us to retain the direct submission path, including the CS
draining to allow fas
In preparation for removing the has_initial_breadcrumb field, add a
helper function for the existing callers.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
drivers/gpu/drm/i915/gt/intel_ring_submission.c | 4 ++--
drivers/gpu/
Allow a brief period for continued access to a dead intel_context by
deferring the release of the struct until after an RCU grace period.
As we are using a dedicated slab cache for the contexts, we can defer
the release of the slab pages via RCU, with the caveat that individual
structs may be reuse
Rather than going back and forth between the rb_node entry and the
virtual_engine type, store the ve local and reuse it. As the
container_of conversion from rb_node to virtual_engine requires a
variable offset, performing that conversion just once shaves off a bit
of code.
v2: Keep a single virtua
Explicitly differentiate between the absolute and relative timelines,
and the global HWSP and ppHWSP relative offsets. When using a timeline
that is relative to a known status page, we can replace the absolute
addressing in the commands with indexed variants.
Signed-off-by: Chris Wilson
---
driv
As we funnel more and more contexts into the breadcrumbs on an engine,
the hold time of b->irq_lock grows. As we may then contend with the
b->irq_lock during request submission, this increases the burden upon
the engine->active.lock and so directly impacts both our execution
latency and client late
Once a virtual engine has been bound to a sibling, it will remain bound
until we finally schedule out the last active request. We can not rebind
the context to a new sibling while it is inflight as the context save
will conflict, hence we wait. As we cannot then use any other sibliing
while the con
Now that the tasklet completely controls scheduling of the requests, and
we postpone scheduling out the old requests, we can keep a hanging
virtual request bound to the engine on which it hung, and remove it from
te queue. On release, it will be returned to the same engine and remain
in its queue u
Let's only wait for the list iterator when decoupling the virtual
breadcrumb, as the signaling of all the requests may take a long time,
during which we do not want to keep the tasklet spinning.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 2 ++
drivers/gpu
Having recognised that we do not change the sibling until we schedule
out, we can then defer the decision to resubmit the virtual engine from
the unwind of the active queue to scheduling out of the virtual context.
This improves our resilence in virtual engine scheduling, and should
eliminate the r
The free_list and worker was introduced in commit 5f09a9c8ab6b ("drm/i915:
Allow contexts to be unreferenced locklessly"), but subsequently made
redundant by the removal of the last sleeping lock in commit 2935ed5339c4
("drm/i915: Remove logical HW ID"). As we can now free the GEM context
immediate
If while we are cancelling the breadcrumb signaling, we find that the
request is already completed, move it to the irq signaler and let it be
signaled.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 20
1 file changed, 16 insertions(+), 4 delet
Quoting Chris Wilson (2020-11-13 09:41:24)
> Currently we know that the timeline status page is at most a page in
> size, and so we can preserve the lower 12bits of the offset when
> relocating the status page in the GGTT. If we want to use a larger
> object, such as the context state, we may not n
== Series Details ==
Series: series starting with [01/33] drm/i915/gt: Include semaphore status in
print_request()
URL : https://patchwork.freedesktop.org/series/83798/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
36ccd48abff7 drm/i915/gt: Include semaphore status in print_re
== Series Details ==
Series: series starting with [01/33] drm/i915/gt: Include semaphore status in
print_request()
URL : https://patchwork.freedesktop.org/series/83798/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be
On 12/11/2020 19:44, Chris Wilson wrote:
Quoting Umesh Nerlige Ramappa (2020-10-10 01:21:03)
Switch the search and grow code of the _wa_add to use _wa_index and
_wa_list_grow.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 54 +++--
Quoting Tvrtko Ursulin (2020-11-13 10:40:07)
>
> On 12/11/2020 19:44, Chris Wilson wrote:
> > Quoting Umesh Nerlige Ramappa (2020-10-10 01:21:03)
> > An inherited problem, but I'm a little unnerved by the apparent leak of
> > wa->list here.
> >
> > Paging Tvrtko to see if he can remember if there
== Series Details ==
Series: series starting with [01/33] drm/i915/gt: Include semaphore status in
print_request()
URL : https://patchwork.freedesktop.org/series/83798/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9322 -> Patchwork_18897
=
To prevent new code with the old helpers being added, nuke the remaining
legacy reg accessors.
v2: Replace a few conversion patches with code removals as suggested by Chris.
BR,
Jani.
Jani Nikula (9):
drm/i915/debugfs: remove RPS autotuning details from
i915_rps_boost_info
drm/i915: remo
Good riddance! Remove the macros and their remaining references in
comments.
intel_uncore_read_fw() and intel_uncore_write_fw() should be used
instead.
Reviewed-by: Rodrigo Vivi
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 29 -
Another straggler with I915_READ() and I915_WRITE() uses gone.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_suspend.c | 33 +++--
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_suspend.c
b/
The i915_cache_sharing file is a debugfs interface for gen 6-7 with no
validation or user. Remove it.
This also removes the last I915_WRITE() use in i915_debugfs.c.
Suggested-by: Chris Wilson
Cc: Chris Wilson
Cc: Rodrigo Vivi
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/
Another straggler with I915_READ() uses gone.
Arguably some of these should use intel_de_read(), however not
all. Prioritize I915_READ() removal in general over migrating to the
pedantically correct replacement right away.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
drivers/gpu/dr
Let's try to not add new ones while we're phasing out I915_READ() and
I915_WRITE().
Fixes: 27a6bc802bd9 ("drm/i915/dg1: Initialize RAWCLK properly")
Reviewed-by: Rodrigo Vivi
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 4 ++--
1 file changed, 2 insertions(+), 2 d
The information is no longer relevant, so remove it. This also removes
the last users of I915_READ_FW()
Cc: Chris Wilson
Suggested-by: Chris Wilson
Reviewed-by: Chris Wilson
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_debugfs.c | 37 -
1 file changed,
Good riddance! Remove the macros and their remaining references in
comments.
The following functions should be used instead, depending on the use
case:
- intel_uncore_read(), intel_uncore_write(), intel_uncore_posting_read()
- intel_de_read(), intel_de_write(), intel_de_posting_read()
Reviewed-
Arguably some of these should use intel_de_read() or intel_de_write(),
however not all. Prioritize I915_READ() and I915_WRITE() removal in
general over migrating to the pedantically correct replacements right
away.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_irq.c | 336
From: Tvrtko Ursulin
I forgot to free the old list when growing past 16 entries.
Luckily, as much as I checked, none of the current platforms has more than
16 workarounds on a single list.
Signed-off-by: Tvrtko Ursulin
Fixes: 452420d22d5b ("drm/i915: Fuse per-context workaround handling with t
Arguably some of these should use intel_de_read() or intel_de_write(),
however not all. Prioritize I915_READ() and I915_WRITE() removal in
general over migrating to the pedantically correct replacements right
away.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_pm.c | 552
Quoting Tvrtko Ursulin (2020-11-13 13:25:10)
> From: Tvrtko Ursulin
>
> I forgot to free the old list when growing past 16 entries.
>
> Luckily, as much as I checked, none of the current platforms has more than
> 16 workarounds on a single list.
And I couldn't see any magics, such as the first
Include the active device name on the update screen.
Signed-off-by: Chris Wilson
---
tools/intel_gpu_top.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c
index 298defa4e..c16e80502 100644
--- a/tools/intel_gpu_top.c
+
On Thu, Nov 12, 2020 at 11:48:12AM -0800, Navare, Manasi wrote:
> On Thu, Nov 12, 2020 at 09:17:15PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > No reason to make the callers of intel_crtc_get_pipe_config()
> > populate hw.active. Let's do it in intel_crtc_get_pipe_config()
> > it
From: Tvrtko Ursulin
Adding a new device selection print type suitable for user-facing
use cases like intel_gpu_top -L and later lsgpu.
Instead of:
sys:/sys/devices/pci:00/:00:02.0/drm/card0
subsystem : drm
drm card: /dev/dri/card0
parent : sys:/sys/de
From: Tvrtko Ursulin
New default user frindly device listing mode which replaces:
sys:/sys/devices/pci:00/:00:02.0/drm/card0
subsystem : drm
drm card: /dev/dri/card0
parent : sys:/sys/devices/pci:00/:00:02.0
sys:/sys/devices/pci:00/:00:
From: Tvrtko Ursulin
In the previous patch we switched the lsgpu output to a short and user
friendly format but some users will need a shorthand for getting other
types of device selection filters than the defaut drm.
Add some command line switches to enable this:
$ lsgpu
card0
From: Tvrtko Ursulin
It is more obvious for the user to only shows filters for DRM master
nodes since those are the ones that intel_gpu_top monitors.
Signed-off-by: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/intel_gpu_to
On Thu, Nov 12, 2020 at 03:59:40PM +0200, Lisovskiy, Stanislav wrote:
> On Fri, Nov 06, 2020 at 07:30:40PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > In order to remove intel_atomic_crtc_state_for_each_plane_state()
> > from skl_crtc_can_enable_sagv() we can simply precompute whe
Avoid hard coding the expected PCI location, and refer to the pci device
used for the test device instead.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_endless.c | 3 ++-
tests/i915/gem_exec_latency.c | 3 ++-
tests/i915/gem_workarounds.c | 3 ++-
tests/i915/gen7_exec_parse.c | 3 ++-
4
On 13/11/2020 14:53, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
In the previous patch we switched the lsgpu output to a short and user
friendly format but some users will need a shorthand for getting other
types of device selection filters than the defaut drm.
Add some command line switches t
On Fri, Nov 06, 2020 at 07:30:42PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace skl_adjusted_plane_pixel_rate() with the generic
> intel_plane_pixel_rate(). The two should produce identical
> results.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_pm.c | 2
On Fri, Nov 06, 2020 at 07:30:41PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the relative data rate for planes in the crtc state
> so that we don't have to use
> intel_atomic_crtc_state_for_each_plane_state() to compute
> it even for the planes that are no part of the current st
From: Maarten Lankhorst
Small changes to intel_dp_mode_valid(), allow listing modes that
can only be supported in the bigjoiner configuration, which is
not supported yet.
v13:
* Allow bigjoiner if hdisplay >5120
v12:
* slice_count logic simplify (Ville)
* Fix unnecessary changes in downstream_mo
No functional changes, to align with previous cleanups pass
intel_atomic_state instead of drm_atomic_state.
Also pass this intel_atomic_state with crtc_state to
some of the atomic_check functions.
v2:
* Squash some changes from next patch (Ville)
Signed-off-by: Manasi Navare
Reviewed-by: Ville S
No functional changes here, just adds a from_crtc_state
as a prep for bigjoiner
v2:
* More prep with intel_atomic_state (Ville)
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 9 +
drivers/gpu/drm/i915/displa
On 10/30/20 5:37 AM, Ville Syrjälä wrote:
> On Thu, Oct 22, 2020 at 05:17:00PM -0700, Aditya Swarup wrote:
>> On 10/16/20 4:40 PM, Aditya Swarup wrote:
>>> On 9/24/20 11:51 AM, Ville Syrjala wrote:
From: Ville Syrjälä
Reduce this maintenance nightmare a bit by converting the plane
>
From: Tvrtko Ursulin
Adding a new device selection print type suitable for user-facing
use cases like intel_gpu_top -L and later lsgpu.
Instead of:
sys:/sys/devices/pci:00/:00:02.0/drm/card0
subsystem : drm
drm card: /dev/dri/card0
parent : sys:/sys/de
From: Tvrtko Ursulin
After devices are sorted post scanning, assing a card index to each so it
can be easily accessed if PCI filter for a card needs to be printed out.
Signed-off-by: Tvrtko Ursulin
Cc: Petri Latvala
Cc: Zbigniew Kempczyński
---
lib/igt_device_scan.c | 43
From: Tvrtko Ursulin
In the previous patch we switched the lsgpu output to a short and user
friendly format but some users will need a shorthand for getting other
types of device selection filters than the defaut drm.
Add some command line switches to enable this:
$ lsgpu
card0
From: Tvrtko Ursulin
It is more obvious for the user to only shows filters for DRM master
nodes since those are the ones that intel_gpu_top monitors.
v2:
* Filter prefix needs to be sys: when listing PCI devices.
Signed-off-by: Tvrtko Ursulin
---
tools/intel_gpu_top.c | 3 ++-
1 file changed
From: Tvrtko Ursulin
Please see individual path commit messages for details, but essentially I
implemented this:
$ sudo tools/lsgpu
card1 8086:4905drm:/dev/dri/card1
└─renderD129 drm:/dev/dri/renderD129
card0 8086:3E98drm:/dev/d
From: Tvrtko Ursulin
New default user frindly device listing mode which replaces:
sys:/sys/devices/pci:00/:00:02.0/drm/card0
subsystem : drm
drm card: /dev/dri/card0
parent : sys:/sys/devices/pci:00/:00:02.0
sys:/sys/devices/pci:00/:00:
As a stepping stone, increase the assumed 16 engines is enough for
everyone, to cover the current RING_MASK, the maximum number of engines
that can currently be selected during execbuf.
Signed-off-by: Chris Wilson
---
tests/i915/gem_busy.c | 2 +-
tests/i915/gem_ctx_create.c| 6 +++-
If we run out of ring space, or exceed the desired runtime, we wish to
stop the subtest. Put these checks together, so that we always keep the
requests flushed on completion.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/selftest_timeline.c | 12 +---
1 file changed, 5 insertio
OA reports can be triggered into the OA buffer by writing into the
OAREPORTTRIG registers. Whitelist the registers to allow non-privileged
user to trigger reports.
Whitelist registers only if perf_stream_paranoid is set to 0. In
i915_perf_open_ioctl, this setting is checked and the whitelist is
en
Switch the search and grow code of the _wa_add to use _wa_index and
_wa_list_grow.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 54 +++--
1 file changed, 17 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workar
Allow user to map the OA buffer and also trigger reports into it.
CI fixes:
v1: Fixes a memory corruption due to addition of OA whitelist on demand.
v2: Spinlock when applying whitelist
v3: Use uncore->lock. Do not check for wal->count when applying whitelist.
v4: Refresh and rerun with newly adde
Refactor intel_engine_apply_whitelist into locked and unlocked versions
so that a caller who already has the lock can apply whitelist.
v2: Fix sparse warning
v3: (Chris)
- Drop prefix and suffix for static function
- Use longest to shortest line ordering for variable declaration
Signed-off-by: Um
i915 used to support time based sampling mode which is good for overall
system monitoring, but is not enough for query mode used to measure a
single draw call or dispatch. Gen9-Gen11 are using current i915 perf
implementation for query, but Gen12+ requires a new approach for query
based on triggere
It is useful to have markers in the OA reports to identify triggered
reports. Whitelist some OA counters that can be used as markers.
A triggered report can be found faster if we can sample the HW tail and
head registers when the report was triggered. Whitelist OA buffer
specific registers.
v2:
-
From: Piotr Maciejewski
A clock gating switch can control if the performance monitoring and
observation logic is enaled or not. Ensure that we enable the clocks.
v2: Separate code from other patches (Lionel)
v3: Reset PMON enable when disabling perf to save power (Lionel)
v4: Use intel_uncore_rm
Applying OA whitelist dynamically also demands that we update the wal
list in sync with engine resume. The lock currently used to synchronize
this is engine->uncore->lock. To use this lock, make i915_wa_list aware
of the engine.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/in
On Fri, Nov 13, 2020 at 04:43:40PM +, Chris Wilson wrote:
As a stepping stone, increase the assumed 16 engines is enough for
everyone, to cover the current RING_MASK, the maximum number of engines
that can currently be selected during execbuf.
Signed-off-by: Chris Wilson
Reviewed-by: Umes
== Series Details ==
Series: drm/i915: Avoid memory leak with more than 16 workarounds on a list
URL : https://patchwork.freedesktop.org/series/83806/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9326 -> Patchwork_18898
Su
== Series Details ==
Series: drm/i915: nuke remaining legacy reg helpers (I915_READ/WRITE etc.)
(rev2)
URL : https://patchwork.freedesktop.org/series/83762/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
60a0c55dfe27 drm/i915/debugfs: remove RPS autotuning details from
i915_rp
== Series Details ==
Series: drm/i915: Eliminate intel_atomic_crtc_state_for_each_plane_state() from
skl+ wm code (rev2)
URL : https://patchwork.freedesktop.org/series/83589/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit wo
== Series Details ==
Series: drm/i915: nuke remaining legacy reg helpers (I915_READ/WRITE etc.)
(rev2)
URL : https://patchwork.freedesktop.org/series/83762/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_9326 -> Patchwork_18899
=
From: Ville Syrjälä
When doing the plane state copy from the UV plane to the Y plane
let's just copy the hw state directly instead of using the original
uapi state. The UV plane has already had its uapi state copied into
its hw state, so this extra detour via the uapi state for the Y plane
is poi
From: Ville Syrjälä
This should have everything we need to enable bigjoiner.
Got rid of the plane linking stuff, and fixed bunch of
issues all over. Smoke tested on tgl by hacking dsc+bigjoiner
on even when they shouldn't be needed/possible.
The wm stuff should be pretty much ready to merge but
From: Ville Syrjälä
Pass the whole intel_atomic_state to skl_build_pipe_wm()
and skl_allocate_pipe_ddb() so we can start to iterate
stuff containerd in the commit.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 24 +---
1 file changed, 13 insertions(+),
From: Ville Syrjälä
Replace skl_adjusted_plane_pixel_rate() with the generic
intel_plane_pixel_rate(). The two should produce identical
results.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 27 ++-
1 file changed, 2 insertions(+), 25 deletions(-)
From: Ville Syrjälä
Make sure both the bigjoiner "master" and "slave" plane are
in the state whenever either of them is in the state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 42
1 file changed, 42 insertions(+)
diff --git a/drivers/
From: Ville Syrjälä
Store the relative data rate for planes in the crtc state
so that we don't have to use
intel_atomic_crtc_state_for_each_plane_state() to compute
it even for the planes that are no part of the current state.
Should probably just nuke this stuff entirely an use the normal
plane
From: Manasi Navare
Enabling is done in a special sequence and so should plane updates
be. Ideally the end user never notices the second pipe is used.
This way ideally everything will be tear free, and updates are
really atomic as userspace expects it.
This uses generic modeset_enables() calls
From: Maarten Lankhorst
When the clock is higher than the dotclock, try with 2 pipes enabled.
If we can enable 2, then we will go into big joiner mode, and steal
the adjacent crtc.
This only links the crtc's in software, no hardware or plane
programming is done yet. Blobs are also copied fr
From: Ville Syrjälä
Document what each of the "raw" vs. "optimal" vs. "intermediate"
watermarks do.
Signed-off-by: Ville Syrjälä
---
.../drm/i915/display/intel_display_types.h| 48 ++-
1 file changed, 25 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/disp
From: Ville Syrjälä
intel_atomic_crtc_state_for_each_plane_state() peeks at the
plane's current state without holding the plane's mutex, trusting
that the crtc's mutex will protect it. In practice that does work
since our planes can't move between pipes, but it sets a bad
example. intel_atomic_cr
From: Ville Syrjälä
In order to remove intel_atomic_crtc_state_for_each_plane_state()
from skl_crtc_can_enable_sagv() we can simply precompute whether
each wm level can tolerate the SAGV block time latency or not.
This has the nice side benefit that we remove the duplicated
wm level latency calc
1 - 100 of 192 matches
Mail list logo
