On 28/03/2020 01:16, Ashutosh Dixit wrote:
It is wrong to block the user thread in the next poll when OA data is
already available which could not fit in the user buffer provided in
the previous read. In several cases the exact user buffer size is not
known. Blocking user space in poll can lead t
Reading or writing those fields should only happen under
stream->oa_buffer.ptr_lock.
Signed-off-by: Lionel Landwerlin
Fixes: d1df41eb72ef ("drm/i915/perf: rework aging tail workaround")
---
drivers/gpu/drm/i915/i915_perf.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git
The plain negative-reloc tests do no execute anything on the GPU and so
cannot determine if the GPU would fallover, they only exercise the
kernel's placement which is uniform across the engines. We should also
cover the engines with perhaps MI_STORE_DWORD, but for the moment the
solitary exercise o
Convert the per-engine tests into a dynamic subtest.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_parallel.c| 28 ++-
tests/intel-ci/fast-feedback.testlist | 4 +---
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/tests/i915/gem_exec_paral
Convert the per-engine tests into a dynamic subtest.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_capture.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/tests/i915/gem_exec_capture.c b/tests/i915/gem_exec_capture.c
index fe2c4bd12..bc13d8632 10
Convert the per-engine tests into a dynamic subtest.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_async.c | 37 -
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/tests/i915/gem_exec_async.c b/tests/i915/gem_exec_async.c
index 623493963..
== Series Details ==
Series: drm/i915/perf: don't read head/tail pointers outside critical section
URL : https://patchwork.freedesktop.org/series/75220/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
97a65e4f417f drm/i915/perf: don't read head/tail pointers outside critical
sec
On TypeC ports if a sink deasserts/reasserts its HPD signal, generating
a hotplug interrupt without the sink getting unplugged/replugged from
the connector, there can be an up to 3 seconds delay until the AUX
channel gets functional. To avoid detection failures this delay causes
retry the detection
On TypeC connectors we need to retry the detection after hotplug events
for a longer time, so add a retry counter to support this. The next
patch will add detection retries on TypeC ports needing this.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 +++
..
== Series Details ==
Series: drm/i915/perf: don't read head/tail pointers outside critical section
URL : https://patchwork.freedesktop.org/series/75220/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8212 -> Patchwork_17124
Quoting Lionel Landwerlin (2020-03-30 10:14:11)
> Reading or writing those fields should only happen under
> stream->oa_buffer.ptr_lock.
Writing, yes. Reading as a pair, sure. There are other ways you can
ensure that the tail/head are read as one, but fair enough.
> Signed-off-by: Lionel Landwerl
== Series Details ==
Series: drm/i915/perf: don't read head/tail pointers outside critical section
URL : https://patchwork.freedesktop.org/series/75220/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8212_full -> Patchwork_17124_full
Add some extra information into trace_ports to help with reviewing
correctness.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 30 +
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/drivers/gp
There might be many reasons why we failed to successfully
load and authenticate HuC firmware, but today we only use
single error in case of no HuC hardware. Add some more
error codes for most common cases (disabled, not installed,
corrupted or mismatched firmware).
Signed-off-by: Michal Wajdeczko
We report HuC status in debugfs using register read, but
we missed that on Gen11+ HuC uses different register.
Use correct one.
While here, correct placement of the colon.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/uc/intel_huc.c |
Allow a bit of leniency for the CPU scheduler to be distracted while we
flush the tasklet and so ensure that we always check the status of the
request once more before timing out.
v2: Wait until the HW acked the submit, and we do any secondary actions
for the submit (e.g. timeslices)
Signed-off-b
Quoting Michal Wajdeczko (2020-03-30 12:33:38)
> We report HuC status in debugfs using register read, but
> we missed that on Gen11+ HuC uses different register.
> Use correct one.
>
> While here, correct placement of the colon.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Daniele Ceraolo Spurio
>
From: Oliver Barta
The check was always succeeding even in case of a mismatch due to the
HDCP_STATUS_ENC bit being set. Make sure both bits are actually set.
Signed-off-by: Oliver Barta
Fixes: 2320175feb74 ("drm/i915: Implement HDCP for HDMI")
---
[v2] rebased on top of latest changes
driver
We need to calculate cdclk after watermarks/ddb has been calculated
as with recent hw CDCLK needs to be adjusted accordingly to DBuf
requirements, which is not possible with current code organization.
Setting CDCLK according to DBuf BW requirements and not just rejecting
if it doesn't satisfy BW r
We need to calculate cdclk after watermarks/ddb has been calculated
as with recent hw CDCLK needs to be adjusted accordingly to DBuf
requirements, which is not possible with current code organization.
Setting CDCLK according to DBuf BW requirements and not just rejecting
if it doesn't satisfy BW r
According to BSpec max BW per slice is calculated using formula
Max BW = CDCLK * 64. Currently when calculating min CDCLK we
account only per plane requirements, however in order to avoid
FIFO underruns we need to estimate accumulated BW consumed by
all planes(ddb entries basically) residing on tha
No need to bump up CDCLK now, as it is now correctly
calculated, accounting for DBuf BW as BSpec says.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 12
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/
We quite often need now to iterate only particular dbuf slices
in mask, whether they are active or related to particular crtc.
Let's make our life a bit easier and use a macro for that.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_display.h | 7 +++
driver
In Gen11+ whenever we might exceed DBuf bandwidth we might need to
recalculate CDCLK which DBuf bandwidth is scaled with.
Total Dbuf bw used might change based on particular plane needs.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
1 file c
Quoting Michal Wajdeczko (2020-03-30 12:33:02)
> There might be many reasons why we failed to successfully
> load and authenticate HuC firmware, but today we only use
> single error in case of no HuC hardware. Add some more
> error codes for most common cases (disabled, not installed,
> corrupted o
== Series Details ==
Series: series starting with [1/2] drm/i915: Add a retry counter for hotplug
detect retries
URL : https://patchwork.freedesktop.org/series/75224/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8213 -> Patchwork_17125
===
Upon a GPU reset, we copy the default context image over top of the
guilty image. This will rollback the CTX_TIMESTAMP register to before
our value of ce->runtime.last. Reset both back to 0 so that we do not
encounter an underflow on the next schedule out after resume.
This should not be a huge is
Hi all, for all = rcu, cpuhotplug and perf maintainers
We've hit an interesting new lockdep splat in our drm/i915 CI:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17096/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-rgb101010-draw-mmap-gtt.html#dmesg-warnings861
Summarizing away the drive
== Series Details ==
Series: drm/i915/execlists: Include priority info in trace_ports
URL : https://patchwork.freedesktop.org/series/75229/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8213 -> Patchwork_17126
Summary
-
On 27/03/2020 12:40, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-27 10:32:07)
We want to enable performance monitoring on multiple contexts to cover
the Iris use case of using 2 GEM contexts (3D & compute).
So start by breaking the OA configuration BO which contains global &
per cont
On 27/03/2020 12:42, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-27 10:32:06)
Hi all,
i915/perf has currently support for single context filtering. This
allows mesa to read the content of the OA buffer and cut out any
unrelated context running in a middle of a query.
Iris currently
On 27/03/2020 13:22, Chris Wilson wrote:
We wish that the scheduler emit the context modification commands prior
to enabling the oa_config, for which we must explicitly inform it of the
ordering constraints. This is especially important as we now wait for
the final oa_config setup to be completed
Quoting Lionel Landwerlin (2020-03-30 14:14:18)
> On 27/03/2020 12:42, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-03-27 10:32:06)
> >> Hi all,
> >>
> >> i915/perf has currently support for single context filtering. This
> >> allows mesa to read the content of the OA buffer and cut out
Use a separate array allocation for the execbuf vma, so that we can
track their lifetime independently from the copy of the user arguments.
With luck, this has a secondary benefit of splitting the malloc size to
within reason and avoid vmalloc. The downside is that we might require
two separate vma
On 30/03/2020 13:16, Chris Wilson wrote:
Allow a bit of leniency for the CPU scheduler to be distracted while we
flush the tasklet and so ensure that we always check the status of the
request once more before timing out.
v2: Wait until the HW acked the submit, and we do any secondary actions
for
On Mon, 30 Mar 2020 at 13:17, Chris Wilson wrote:
>
> Allow a bit of leniency for the CPU scheduler to be distracted while we
> flush the tasklet and so ensure that we always check the status of the
> request once more before timing out.
>
> v2: Wait until the HW acked the submit, and we do any se
Quoting Matthew Auld (2020-03-30 14:48:52)
> On Mon, 30 Mar 2020 at 13:17, Chris Wilson wrote:
> >
> > Allow a bit of leniency for the CPU scheduler to be distracted while we
> > flush the tasklet and so ensure that we always check the status of the
> > request once more before timing out.
> >
> >
On Mon, Mar 30, 2020 at 03:00:35PM +0200, Daniel Vetter wrote:
> Hi all, for all = rcu, cpuhotplug and perf maintainers
>
> We've hit an interesting new lockdep splat in our drm/i915 CI:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17096/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-r
On 30.03.2020 14:28, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2020-03-30 12:33:02)
>> There might be many reasons why we failed to successfully
>> load and authenticate HuC firmware, but today we only use
>> single error in case of no HuC hardware. Add some more
>> error codes for most co
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This fin
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get call
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Maarten Lankhorst
---
.../gpu/d
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
drivers/g
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rend
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/g
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..e35e8d0b6938 100644
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
We inadvertently create a dependency on mmap_sem with a whole chain.
This breaks any user who wants to take a lock and call rcu_barrier(),
while also taking that lock inside mmap_sem:
<4> [604.892532] ==
<4> [604.892534] WARNING: possible circul
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten La
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: M
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
Quoting Michal Wajdeczko (2020-03-30 15:02:53)
>
>
> On 30.03.2020 14:28, Chris Wilson wrote:
> > There's nothing else between us loading the fw and the huc rejecting
> > it?
> >
> > FIRMWARE_FAIL? That's set as the opposite of FIRMWARE_TRANSFERRED in
> > that we failed to upload the image to th
There's no prandom_u32_state_max, so we're using reciprocal_scale()
here directly.
(Also add a missing "const" to drivers/gpu/drm/i915/selftests/scatterist.c)
Signed-off-by: George Spelvin
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: Davidlohr B
Hello,
because of the current pandemic situation the usage of my laptop has
changed. It is now running at home 24/7 with a monitor attached to it
and after about 12 days running a somewhat older kernel (5.2), it
stopped working.
After a reboot I found some information in the syslog that I attach
It's not safe to just grab the FPU willy nilly without first checking to
see if it's available. This patch adds the usual call to may_use_simd()
and falls back to boring memcpy if it's not available.
Signed-off-by: Jason A. Donenfeld
---
drivers/gpu/drm/i915/i915_memcpy.c | 12
1 fi
Dirk Gouders writes:
> Some additional information:
>
> I tried to get more information by using netconsole with kernel
> 5.6.0-rc7+. After some time, the system stopped to respond and I
> checked the messages sent to the remote machine. Unfortunately they
> gave no other information than the l
Some additional information:
I tried to get more information by using netconsole with kernel
5.6.0-rc7+. After some time, the system stopped to respond and I
checked the messages sent to the remote machine. Unfortunately they
gave no other information than the local logfile.
Dirk
Dirk Gouders
On Mon, Mar 30, 2020 at 03:00:35PM +0200, Daniel Vetter wrote:
> Hi all, for all = rcu, cpuhotplug and perf maintainers
>
> We've hit an interesting new lockdep splat in our drm/i915 CI:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17096/shard-tglb7/igt@kms_frontbuffer_track...@fbcpsr-r
Probaility has a useful range of 0 to 100.
Verbose has a useful range of 0 to 2.
Reduce them both from unsigned long to unsigned char. Since there
was already a hole they can fit into, this saves 16 bytes.
There's one consequential fix required: i915 selftests set the
probability to 999 for some
== Series Details ==
Series: drm/i915/huc: Add more errors for I915_PARAM_HUC_STATUS
URL : https://patchwork.freedesktop.org/series/75230/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8213 -> Patchwork_17127
Summary
--
We inadvertently create a dependency on mmap_sem with a whole chain.
This breaks any user who wants to take a lock and call rcu_barrier(),
while also taking that lock inside mmap_sem:
<4> [604.892532] ==
<4> [604.892534] WARNING: possible circul
As a preparation step for full object locking and wait/wound handling
during pin and object mapping, ensure that we always pass the ww context
in i915_gem_execbuffer.c to i915_vma_pin, use lockdep to ensure this
happens.
This also requires changing the order of eb_parse slightly, to ensure
we pass
Some i915 selftests still use i915_vma_lock() as inner lock, and
intel_context_create_request() intel_timeline->mutex as outer lock.
Fortunately for selftests this is not an issue, they should be fixed
but we can move ahead and cleanify lockdep now.
Signed-off-by: Maarten Lankhorst
---
drivers/g
This reverts commit 7dc8f1143778 ("drm/i915/gem: Drop relocation
slowpath"). We need the slowpath relocation for taking ww-mutex
inside the page fault handler, and we will take this mutex when
pinning all objects.
Cc: Chris Wilson
Cc: Matthew Auld
Signed-off-by: Maarten Lankhorst
---
.../gpu/d
We want to lock all gem objects, including the engine context objects,
rework the throttling to ensure that we can do this. Now we only throttle
once, but can take eb_pin_engine while acquiring objects. This means we
will have to drop the lock to wait. If we don't have to throttle we can
still take
This is required if we want to pass a ww context in intel_context_pin
and gen6_ppgtt_pin().
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 55 ++-
.../drm/i915/gem/selftests/i915_gem_context.c | 22 +++-
2 files changed, 48 insertions(+),
Instead of using intel_context_create_request(), use intel_context_pin()
and i915_create_request directly.
Now all those calls are gone outside of selftests. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 43 ++---
1 file changed, 29 insert
We want to get rid of intel_context_pin(), convert
intel_context_create_request() first. :)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_context.c | 20 +++-
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 51 +++-
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index b39c24dae64e..e35e8d0b6938 100644
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/intel_renderstate.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 9 -
drivers/gpu/drm/i915/i915_vma.h | 1 +
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rend
We want to introduce backoff logic, but we need to lock the
pool object as well for command parsing. Because of this, we
will need backoff logic for the engine pool obj, move the batch
validation up slightly to eb_lookup_vmas, and the actual command
parsing in a separate function which can get call
We have the ordering of timeline->mutex vs resv_lock wrong,
convert the i915_pin_vma and intel_context_pin as well to
future-proof this.
We may need to do future changes to do this more transaction-like,
and only get down to a single i915_gem_ww_ctx, but for now this
should work.
Signed-off-by: M
Now that we changed execbuf submission slightly to allow us to do all
pinning in one place, we can now simply add ww versions on top of
struct_mutex. All we have to do is a separate path for -EDEADLK
handling, which needs to unpin all gem bo's before dropping the lock,
then starting over.
This fin
Make sure vma_lock is not used as inner lock when kernel context is used,
and add ww handling where appropriate.
Signed-off-by: Maarten Lankhorst
---
.../i915/gem/selftests/i915_gem_coherency.c | 26 ++--
.../drm/i915/gem/selftests/i915_gem_mman.c| 41 ++-
drivers/g
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix that up.
Signed-off-by: Maarten Lankhorst
---
This is the last part outside of selftests that still don't use the
correct lock ordering of timeline->mutex vs resv_lock.
With gem fixed, there are a few places that still get locking wrong:
- gvt/scheduler.c
- i915_perf.c
- Most if not all selftests.
Changes since v1:
- Add intel_engine_pm_get/
i915_gem_ww_ctx is used to lock all gem bo's for pinning and memory
eviction. We don't use it yet, but lets start adding the definition
first.
To use it, we have to pass a non-NULL ww to gem_object_lock, and don't
unlock directly. It is done in i915_gem_ww_ctx_fini.
Changes since v1:
- Change ww_
Instead of doing everything inside of pin_mutex, we move all pinning
outside. Because i915_active has its own reference counting and
pinning is also having the same issues vs mutexes, we make sure
everything is pinned first, so the pinning in i915_active only needs
to bump refcounts. This allows us
We want to start using ww locking in intel_context_pin, for this
we need to lock multiple objects, and the single i915_gem_object_lock
is not enough.
Convert to using ww-waiting, and make sure we always pin intel_context_state,
even if we don't have a renderstate object.
Signed-off-by: Maarten La
This function does not use intel_context_create_request, so it has
to use the same locking order as normal code. This is required to
shut up lockdep in selftests.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
1 file changed, 12 insertions(+), 3
Those arguments are already set as eb.file and eb.args, so kill off
the extra arguments. This will allow us to move eb_pin_engine() to
after we reserved all BO's.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 17 +++--
1 file changed, 7 inserti
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 65 --
drivers/gpu/drm/i915/gem/i915_gem_object.h | 1 +
2 files changed, 49 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i
On 30.03.2020 16:12, Chris Wilson wrote:
> Quoting Michal Wajdeczko (2020-03-30 15:02:53)
>>
>>
>> On 30.03.2020 14:28, Chris Wilson wrote:
>>> There's nothing else between us loading the fw and the huc rejecting
>>> it?
>>>
>>> FIRMWARE_FAIL? That's set as the opposite of FIRMWARE_TRANSFERRED i
Replace the TGL/ICL specific platform checks with a more generic check
using INTEL_GEN(). Fixes bug with broken audio after S3 resume on JSL
platforms.
An initial version of state save and restore of AUD_FREQ_CNTRL register
was added for subset of platforms in commit 87c1694533c9
("drm/i915: save
On Fri, Mar 27, 2020 at 02:34:11PM -0700, José Roberto de Souza wrote:
> DDI ports have its encoders initialized with INTEL_OUTPUT_DDI type and
> later eDP ports that have the type changed to INTEL_OUTPUT_EDP.
> But for all other DDI ports it can drive HDMI or DP depending on what
> user connects t
The DDI IO power well must not be enabled for a TypeC port in TBT mode,
ensure this during driver loading/system resume.
This gets rid of error messages like
[drm] *ERROR* power well DDI E TC2 IO state mismatch (refcount 1/enabled 0)
and avoids leaking the power ref when disabling the output.
Cc
On Mon, Mar 30, 2020 at 03:23:50PM +0300, Stanislav Lisovskiy wrote:
> We need to calculate cdclk after watermarks/ddb has been calculated
> as with recent hw CDCLK needs to be adjusted accordingly to DBuf
> requirements, which is not possible with current code organization.
>
> Setting CDCLK acco
On Mon, 30 Mar 2020 at 12:32, Chris Wilson wrote:
>
> Add some extra information into trace_ports to help with reviewing
> correctness.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
Reviewed-by: Matthew Auld
___
Intel-gfx m
On Mon, 30 Mar 2020 03:09:20 -0700, Chris Wilson wrote:
>
> Quoting Lionel Landwerlin (2020-03-30 10:14:11)
> > Reading or writing those fields should only happen under
> > stream->oa_buffer.ptr_lock.
>
> Writing, yes. Reading as a pair, sure. There are other ways you can
> ensure that the tail/hea
On Mon, Mar 30, 2020 at 03:23:52PM +0300, Stanislav Lisovskiy wrote:
> We quite often need now to iterate only particular dbuf slices
> in mask, whether they are active or related to particular crtc.
>
> Let's make our life a bit easier and use a macro for that.
>
> Signed-off-by: Stanislav Lisov
1 - 100 of 204 matches
Mail list logo
