== Series Details ==
Series: Steer multicast register workaround verification (rev2)
URL : https://patchwork.freedesktop.org/series/76792/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8408 -> Patchwork_17548
Summary
The multicast register ranges are slightly different for gen11 and gen12
than the table we have for gen8. This information never got updated in
the bspec, so this patch is based on a spreadsheet provided by the
hardware team while they work on getting the official documentation
updated.
We're seeing some CI errors indicating that a workaround did not apply
properly on EHL/JSL. The workaround in question is updating a multicast
register, the failures are only seen on specific CI machines, and the
failures only seem to happen on resets and such rather than on initial
driver load.
Reads of multicast registers give the value associated with
slice/subslice 0 by default unless we manually steer the reads to a
different slice/subslice. If slice/subslice 0 are fused off in hardware,
performing unsteered reads of multicast registers will return a value of
0 rather than the value
Steering of multicast registers for workarounds is needed on all
platforms gen10 and above. Move the wa_init_mcr() call to the
higher-level gt_init_workarounds() rather than re-calling it for each
individual platform.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_workarounds.c |
On Wed, Apr 29, 2020 at 01:10:26PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The MSG_FBC_REND_STATE register only exists on snb+. For older
I only find this register in the bspec for HSW+. Is the spec incomplete
or am I looking in the wrong place?
It's a bit hard to review these
On 5/1/20 11:20 AM, Jason Gunthorpe wrote:
From: Jason Gunthorpe
Presumably the intent here was that hmm_range_fault() could put the data
into some HW specific format and thus avoid some work. However, nothing
actually does that, and it isn't clear how anything actually could do that
as
On Wed, Apr 29, 2020 at 01:10:25PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current fence_y_offset calculation is broken. I think it more or
> less used to do the right thing, but then I changed the plane code
> to put the final x/y source offsets back into the src rectangle so
On Wed, Apr 29, 2020 at 06:29:21PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Consult the actual plane stride instead of the fb stride. The two
> will disagree when we remap the gtt. The plane stride is what the
> hw will be fed so that's what we should look at for the FBC
>
== Series Details ==
Series: drm/i915/icp: Add Wa_14010685332
URL : https://patchwork.freedesktop.org/series/76841/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8407_full -> Patchwork_17547_full
Summary
---
== Series Details ==
Series: drm/i915/icp: Add Wa_14010685332
URL : https://patchwork.freedesktop.org/series/76841/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8407 -> Patchwork_17547
Summary
---
**SUCCESS**
No
On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> Sometimes it's not okay to use SIMD registers, the conditions for which
> have changed subtly from kernel release to kernel release. Usually the
> pattern is to check for may_use_simd() and then fallback to using
> something
On Fri, May 1, 2020 at 4:42 AM Sebastian Andrzej Siewior
wrote:
>Reviewed-by: Sebastian Andrzej Siewior
Thanks.
>
> May I ask how large the memcpy can be? I'm asking in case it is large
> and an explicit rescheduling point might be needed.
Yea I was worried about that too. I'm not an i915
On Fri, May 1, 2020 at 12:07 PM Christoph Hellwig wrote:
>
> On Thu, Apr 30, 2020 at 04:10:16PM -0600, Jason A. Donenfeld wrote:
> > Sometimes it's not okay to use SIMD registers, the conditions for which
> > have changed subtly from kernel release to kernel release. Usually the
> > pattern is to
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gem: Use chained reloc batches
URL : https://patchwork.freedesktop.org/series/76837/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8407_full -> Patchwork_17546_full
Reviewed by: bob.j.paa...@intel.com
--
Bob Paauwe
bob.j.paa...@intel.com
IOTG / Platform Software Engineering
Intel Corp. Folsom, CA
(916) 356-6193
(530) 409-0831 (cell)
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, May 01, 2020 2:37 PM
> To:
We need to toggle a SDE chicken bit on and then off as the final
step when disabling interrupts in preparation for runtime suspend.
Bspec: 33450
Bspec: 8402
Cc: Bob Paauwe
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_irq.c | 8
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files
== Series Details ==
Series: Introduce Rocket Lake
URL : https://patchwork.freedesktop.org/series/76826/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8407_full -> Patchwork_17545_full
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915: check to see if SIMD registers are available before using SIMD
URL : https://patchwork.freedesktop.org/series/76825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8407_full -> Patchwork_17544_full
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gem: Use chained reloc batches
URL : https://patchwork.freedesktop.org/series/76837/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8407 -> Patchwork_17546
As we can now keep chaining together a relocation batch to process any
number of relocations, we can keep building that relocation batch for
all of the target vma. This avoiding emitting a new request into the
ring for each target, consuming precious ring space and a potential
stall.
v2:
The ring is a precious resource: we anticipate to only use a few hundred
bytes for a request, and only try to reserve that before we start. If we
go beyond our guess in building the request, then instead of waiting at
the start of execbuf before we hold any locks or other resources, we
may trigger
If at first we don't succeed, try try again.
Not all engines may support the MI ops we need to perform asynchronous
relocation patching, and so we end up falling back to a synchronous
operation that has a liability of blocking. However, Tvrtko pointed out
we don't need to use the same engine to
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gem: Use chained reloc batches
URL : https://patchwork.freedesktop.org/series/76821/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8406_full -> Patchwork_17542_full
== Series Details ==
Series: Introduce Rocket Lake
URL : https://patchwork.freedesktop.org/series/76826/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8407 -> Patchwork_17545
Summary
---
**SUCCESS**
No
Matt,
This patch used to have version information such "v7: Add missing pipe
mask". Why they are removed? For power on?
Otherwise
Acked-by: Caz Yokoyama
-caz
On Fri, 2020-05-01 at 10:07 -0700, Matt Roper wrote:
> Introduce the basic platform definition, macros, and PCI IDs.
>
> Bspec: 44501
>
== Series Details ==
Series: Introduce Rocket Lake
URL : https://patchwork.freedesktop.org/series/76826/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e0c54705a263 drm/i915/rkl: Add RKL platform info and PCI ids
-:34: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'p' - possible
== Series Details ==
Series: drm/i915: check to see if SIMD registers are available before using SIMD
URL : https://patchwork.freedesktop.org/series/76825/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8407 -> Patchwork_17544
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, May 1, 2020 10:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Srivatsa, Anusha
>
> Subject: [PATCH 04/23] drm/i915/rkl: Load DMC firmware for Rocket Lake
>
> Cc: Anusha Srivatsa
> Signed-off-by: Matt
== Series Details ==
Series: drm/i915: check to see if SIMD registers are available before using SIMD
URL : https://patchwork.freedesktop.org/series/76825/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
962131944f1f drm/i915: check to see if SIMD registers are available before
> -Original Message-
> From: Roper, Matthew D
> Sent: Friday, May 1, 2020 10:37 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; Srivatsa, Anusha
>
> Subject: [PATCH 03/23] drm/i915/rkl: Re-use TGL GuC/HuC firmware
>
> RKL uses the same GuC and HuC as TGL and should
From: Aditya Swarup
RKL doesn't have DSI outputs, so we shouldn't try to read out the DSI
transcoder registers.
Signed-off-by: Aditya Swarup
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
RKL uses the same GuC and HuC as TGL and should load the same firmwares.
Bspec: 50668
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
Rocket Lake has a third DPLL (called 'DPLL4') that must be used to
enable a third display. Unlike EHL's variant of DPLL4, the RKL variant
behaves the same as DPLL0/1. And despite its name, the DPLL4 registers
are offset as if it were DPLL2, so no extra offset handling is needed
either.
Bspec:
There are a couple places in our driver that loop over transcoders A..D
for gen11+; since RKL only has three pipes/transcoders, this can lead to
unclaimed register reads/writes. We should add checks for transcoder
existence where appropriate.
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
The pin mapping for the final two outputs varies according to which PCH
is present on the platform: with TGP the pins are remapped into the TC
range, whereas with CMP they stay in the traditional combo output range.
Bspec: 49181
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
RKL and TGL share some general gen12 workarounds, but each platform also
has its own platform-specific workarounds.
Cc: Matt Atwood
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_sprite.c | 5 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 88 +
2 files
RKL power wells are similar to TGL power wells, but have some important
differences:
* PG1 now has pipe A's VDSC (rather than sticking it in PG2)
* PG2 no longer exists
* DDI-C (aka TC-1) moves from PG1 -> PG3
* PG5 no longer exists due to the lack of a fourth pipe
Also note that what we
RKL uses DDI's A, B, TC1, and TC2 which need to map to combo PHY's A-D.
Bspec: 49181
Cc: Imre Deak
Cc: Aditya Swarup
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_display.c | 34
drivers/gpu/drm/i915/i915_reg.h | 4 ++-
From: José Roberto de Souza
RKL doesn't have PSR2 HW tracking, it was replaced by software/manual
tracking. The driver is required to track the areas that needs update
and program hardware to send selective updates.
So until the software tracking is implemented, PSR2 needs to be disabled
for
RKL uses the same BW_BUDDY programming table as TGL, but programs the
values into a single set BUDDY0 set of registers rather than the
BUDDY1/BUDDY2 sets used by TGL.
Bspec: 49218
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
.../drm/i915/display/intel_display_power.c| 44
If HTI (also sometimes called HDPORT) is enabled at startup, it may be
using some of the PHYs and DPLLs making them unavailable for general
usage. Let's read out the HDPORT_STATE register and avoid making use of
resources that HTI is already using.
Bspec: 49189
Bspec: 53707
Cc: Lucas De Marchi
From: Lucas De Marchi
RKL uses the DDI A, DDI B, DDI USBC1, DDI USBC2 from the DE point of
view, so all DDI/pipe/transcoder register use these indexes to refer to
them. Combo phy and IO functions follow another namespace that we keep
as "enum phy". The VBT in theory would use the DE point of
Introduce the basic platform definition, macros, and PCI IDs.
Bspec: 44501
Cc: Lucas De Marchi
Cc: Caz Yokoyama
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 8
drivers/gpu/drm/i915/i915_pci.c | 10 ++
Rocket Lake can pair with either TGP or CMP.
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pch.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pch.c b/drivers/gpu/drm/i915/intel_pch.c
index
Certain combo PHYs act as a compensation master to other PHYs and need
to be initialized with a special irefgen bit in the PORT_COMP_DW8
register. Previously PHY A was the only compensation master (for PHYs
B & C), but RKL adds a fourth PHY which is slaved to PHY C instead.
Bspec: 49291
Cc:
Note that the 192000 clock frequencies can be achieved with different
pairs of ratio+divider, which is something we haven't encountered
before. If any of those ratios were common with other legal cdclk
values, then it would mean we could avoid triggering full modesets if we
just needed to change
Since the number of platforms with this restriction are growing, let's
separate out the platform logic into a has_phy_misc() function.
Bspec: 50107
Signed-off-by: Matt Roper
---
.../gpu/drm/i915/display/intel_combo_phy.c| 30 +++
1 file changed, 17 insertions(+), 13
When Rocket Lake is paired with a TGP PCH, the last two outputs utilize
the TC1 and TC2 hpd pins, even though these are combo outputs.
Bspec: 49181
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
1 file changed, 6 insertions(+), 2
RKL only has five universal planes, plus a cursor. Since the
bottom-most universal plane is considered the primary plane, set the
number of sprites available on this platform to 4.
In general, the plane capabilities of the remaining planes stay the same
as TGL. However the NV12 Y-plane support
RKL uses a slightly different bit layout for the DPCLKA_CFGCR0 register.
Bspec: 50287
Cc: Aditya Swarup
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 18 +++---
drivers/gpu/drm/i915/display/intel_display.c | 15 ---
The RKL platform has different memory characteristics from past
platforms. Update the values used by our memory bandwidth calculations
accordingly.
Bspec: 53998
Cc: James Ausmus
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_bw.c | 10 +-
1 file changed, 9
Cc: Anusha Srivatsa
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_csr.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_csr.c
b/drivers/gpu/drm/i915/display/intel_csr.c
index 3112572cfb7d..319932b03e88 100644
Rocket Lake (RKL) is another gen12 platform, so the driver support is
mostly a straightforward evolution of our existing Tiger Lake support.
One area of this patch series that's a bit non-intuitive and warrants
some extra explanation is the output handling. All four of RKL's output
ports use
RKL re-uses the same stolen memory registers as TGL and ICL.
Bspec: 52055
Bspec: 49589
Bspec: 49636
Cc: Lucas De Marchi
Signed-off-by: Matt Roper
---
arch/x86/kernel/early-quirks.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/x86/kernel/early-quirks.c
Sometimes it's not okay to use SIMD registers, the conditions for which
have changed subtly from kernel release to kernel release. Usually the
pattern is to check for may_use_simd() and then fallback to using
something slower in the unlikely case SIMD registers aren't available.
So, this patch
== Series Details ==
Series: drm/i915: Implement vm_ops->access for gdb access into mmaps (rev4)
URL : https://patchwork.freedesktop.org/series/76783/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8406 -> Patchwork_17543
On Fri, May 01, 2020 at 09:01:42AM +0100, Tvrtko Ursulin wrote:
>
> Hi,
>
> On 01/05/2020 00:15, Matt Roper wrote:
> > We're seeing some CI errors indicating that a workaround did not apply
> > properly on EHL/JSL. The workaround in question is updating a multicast
> > register, the failures
== Series Details ==
Series: series starting with [CI,1/3] drm/i915/gem: Use chained reloc batches
URL : https://patchwork.freedesktop.org/series/76821/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8406 -> Patchwork_17542
On 30.04.2020 20:30, Daniel Vetter wrote:
> On Thu, Apr 30, 2020 at 5:38 PM Sean Paul wrote:
>>
>> On Wed, Apr 29, 2020 at 4:57 AM Jani Nikula
>> wrote:
>>>
>>> On Tue, 28 Apr 2020, Michal Orzel wrote:
As suggested by the TODO list for the kernel DRM subsystem, replace
the
== Series Details ==
Series: series starting with [1/3] drm/i915/gem: Use chained reloc batches
URL : https://patchwork.freedesktop.org/series/76818/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8405_full -> Patchwork_17541_full
== Series Details ==
Series: drm/i915/gt: Make timeslicing an explicit engine property
URL : https://patchwork.freedesktop.org/series/76817/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8405_full -> Patchwork_17540_full
Thanks
Mikhail Voldman
System Architect
Teledyne LeCroy, Protocol Solutions Group
2111 Big Timber Road
Elgin, IL 60123
email address: mikhail.vold...@teledyne.com
847-888-0450 x136
Send me a file securely
-Original Message-
From: Ramalingam C
Sent: Thursday, April 30, 2020
On Thu, 30 Apr 2020 at 20:51, Chris Wilson wrote:
>
> gdb uses ptrace() to peek and poke bytes of the target's address space.
> The kernel must implement an vm_ops->access() handler or else gdb will
> be unable to inspect the pointer and report it as out-of-bounds. Worse
> than useless as it
Quoting Matthew Auld (2020-05-01 15:58:29)
> On Thu, 30 Apr 2020 at 20:42, Chris Wilson wrote:
> > + ptrace(PTRACE_ATTACH, pid, NULL, NULL);
> > + for (int i = 0; i < OBJECT_SIZE / sizeof(long); i++) {
> > + long ret;
> > +
> > + ret =
On Thu, 30 Apr 2020 at 20:42, Chris Wilson wrote:
>
> gdb uses ptrace() to peek and poke bytes of the target's address space.
> The kernel must implement an vm_ops->access() handler or else gdb will
> be unable to inspect the pointer and report it as out-of-bounds. Worse
> than useless as it
gdb uses ptrace() to peek and poke bytes of the target's address space.
The driver must implement an vm_ops->access() handler or else gdb will
be unable to inspect the pointer and report it as out-of-bounds.
Worse than useless as it causes immediate suspicion of the valid GTT
pointer, distracting
On 01/05/2020 09:42, Chris Wilson wrote:
gdb uses ptrace() to peek and poke bytes of the target's address space.
The driver must implement an vm_ops->access() handler or else gdb will
be unable to inspect the pointer and report it as out-of-bounds.
Worse than useless as it causes immediate
The ring is a precious resource: we anticipate to only use a few hundred
bytes for a request, and only try to reserve that before we start. If we
go beyond our guess in building the request, then instead of waiting at
the start of execbuf before we hold any locks or other resources, we
may trigger
If at first we don't succeed, try try again.
Not all engines may support the MI ops we need to perform asynchronous
relocation patching, and so we end up falling back to a synchronous
operation that has a liability of blocking. However, Tvrtko pointed out
we don't need to use the same engine to
As we can now keep chaining together a relocation batch to process any
number of relocations, we can keep building that relocation batch for
all of the target vma. This avoiding emitting a new request into the
ring for each target, consuming precious ring space and a potential
stall.
v2:
== Series Details ==
Series: series starting with [1/3] drm/i915/gem: Use chained reloc batches
URL : https://patchwork.freedesktop.org/series/76818/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8405 -> Patchwork_17541
== Series Details ==
Series: series starting with [1/3] drm/i915/gem: Use chained reloc batches
URL : https://patchwork.freedesktop.org/series/76813/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8405_full -> Patchwork_17538_full
On 01/05/2020 13:22, Chris Wilson wrote:
In order to allow userspace to rely on timeslicing to reorder their
batches, we must support preemption of those user batches. Declare
timeslicing as an explicit property that is a combination of having the
kernel support and HW support.
Suggested-by:
On 01/05/2020 14:02, Chris Wilson wrote:
As we can now keep chaining together a relocation batch to process any
number of relocations, we can keep building that relocation batch for
all of the target vma. This avoiding emitting a new request into the
ring for each target, consuming precious
On 01/05/2020 14:02, Chris Wilson wrote:
The ring is a precious resource: we anticipate to only use a few hundred
bytes for a request, and only try to reserve that before we start. If we
go beyond our guess in building the request, then instead of waiting at
the start of execbuf before we hold
== Series Details ==
Series: drm/i915/gt: Make timeslicing an explicit engine property
URL : https://patchwork.freedesktop.org/series/76817/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8405 -> Patchwork_17540
Summary
If at first we don't succeed, try try again.
Not all engines may support the MI ops we need to perform asynchronous
relocation patching, and so we end up falling back to a synchronous
operation that has a liability of blocking. However, Tvrtko pointed out
we don't need to use the same engine to
The ring is a precious resource: we anticipate to only use a few hundred
bytes for a request, and only try to reserve that before we start. If we
go beyond our guess in building the request, then instead of waiting at
the start of execbuf before we hold any locks or other resources, we
may trigger
As we can now keep chaining together a relocation batch to process any
number of relocations, we can keep building that relocation batch for
all of the target vma. This avoiding emitting a new request into the
ring for each target, consuming precious ring space and a potential
stall.
v2:
== Series Details ==
Series: series starting with [01/24] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76816/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8405 -> Patchwork_17539
Quoting Tvrtko Ursulin (2020-05-01 13:47:36)
>
> On 01/05/2020 11:19, Chris Wilson wrote:
> If you are not worried about the context create dance on SNB, and it is
> limited to VCS, then neither am I.
In the short term, since it's limited to vcs on SNB so that means it is
just a plain kmalloc
On 01/05/2020 11:19, Chris Wilson wrote:
If at first we don't succeed, try try again.
No all engines may support the MI ops we need to perform asynchronous
relocation patching, and so we end up failing back to a synchronous
operation that has a liability of blocking. However, Tvrtko pointed
On 01/05/2020 11:18, Chris Wilson wrote:
As we can now keep chaining together a relocation batch to process any
number of relocations, we can keep building that relocation batch for
all of the target vma. This avoiding emitting a new request into the
ring for each target, consuming precious
Quoting Chris Wilson (2020-05-01 13:38:03)
> Quoting Tvrtko Ursulin (2020-05-01 13:33:14)
> >
> > On 01/05/2020 11:18, Chris Wilson wrote:
> > > +
> > > + err = 0;
> > > + if (rq->engine->emit_init_breadcrumb)
> > > + err = rq->engine->emit_init_breadcrumb(rq);
> > > + if
Quoting Tvrtko Ursulin (2020-05-01 13:33:14)
>
> On 01/05/2020 11:18, Chris Wilson wrote:
> > +
> > + err = 0;
> > + if (rq->engine->emit_init_breadcrumb)
> > + err = rq->engine->emit_init_breadcrumb(rq);
> > + if (!err)
> > + err =
On 01/05/2020 11:18, Chris Wilson wrote:
The ring is a precious resource: we anticipate to only use a few hundred
bytes for a request, and only try to reserve that before we start. If we
go beyond our guess in building the request, then instead of waiting at
the start of execbuf before we hold
== Series Details ==
Series: series starting with [01/24] perf/core: Only copy-to-user after
completely unlocking all locks, v3.
URL : https://patchwork.freedesktop.org/series/76816/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c7e83b1d5e8c perf/core: Only copy-to-user after
In order to allow userspace to rely on timeslicing to reorder their
batches, we must support preemption of those user batches. Declare
timeslicing as an explicit property that is a combination of having the
kernel support and HW support.
Suggested-by: Tvrtko Ursulin
Fixes: 8ee36e048c98
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 ++-
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
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
This reverts commit 0f1dd02295f35dcdcbaafcbcbbec0753884ab974.
This conflicts with the ww mutex handling, which needs to drop
the references after gpu submission anyway, because otherwise we
may risk unlocking a BO after first freeing it.
Signed-off-by: Maarten Lankhorst
---
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
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
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
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
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
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
---
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
---
1 - 100 of 128 matches
Mail list logo
