== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev2)
URL : https://patchwork.freedesktop.org/series/92789/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10442_full -> Patchwork_20767_full
Summary
---
On Tue, Aug 03, 2021 at 10:47:10AM -0500, Jason Ekstrand wrote:
> Both are
>
> Reviewed-by: Jason Ekstrand
CI is happy, I guess you got all the igt changes indeed. Both pushed
thanks for reviewing.
-Daniel
>
> On Tue, Aug 3, 2021 at 7:49 AM Daniel Vetter wrote:
> >
> > It's already removed, t
On Mon, Aug 02, 2021 at 04:35:51PM +0300, Imre Deak wrote:
> Atm the EFI FB driver gets a runtime PM reference for the associated GFX
> PCI device during driver probing and releases it only when removing the
> driver.
>
> When fbcon switches to the FB provided by the PCI device's driver (for
> ins
== Series Details ==
Series: drm/i915: fix i915_globals_exit() section mismatch error
URL : https://patchwork.freedesktop.org/series/93398/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10445 -> Patchwork_20770
Summary
On Wed, Aug 4, 2021 at 3:41 PM Randy Dunlap wrote:
>
> Fix modpost Section mismatch error in i915_globals_exit().
> Since both an __init function and an __exit function can call
> i915_globals_exit(), any function that i915_globals_exit() calls
> should not be marked as __init or __exit. I.e., it
On Wed, Aug 04, 2021 at 01:36:37PM -0700, Lucas De Marchi wrote:
> On Thu, Jul 29, 2021 at 10:00:00AM -0700, Matt Roper wrote:
> > From: Stuart Summers
> >
> > Starting in XeHP, the concept of slice has been removed in favor of
> > DSS (Dual-Subslice) masks for various workload types. These workl
Fix modpost Section mismatch error in i915_globals_exit().
Since both an __init function and an __exit function can call
i915_globals_exit(), any function that i915_globals_exit() calls
should not be marked as __init or __exit. I.e., it needs to be
available for either of them.
WARNING: modpost: v
On Thu, Jul 29, 2021 at 10:00:00AM -0700, Matt Roper wrote:
From: Stuart Summers
Starting in XeHP, the concept of slice has been removed in favor of
DSS (Dual-Subslice) masks for various workload types. These workloads have
been divided into those enabled for geometry and those enabled for comp
On Thu, Jul 29, 2021 at 09:59:59AM -0700, Matt Roper wrote:
Due to the removal of legacy slices and the transition to a
gslice/cslice/mslice/etc. design, we'll internally store all DSS under
"slice0."
Signed-off-by: Matt Roper
Reviewed-by: Caz Yokoyama
---
drivers/gpu/drm/i915/gt/intel_sseu.c
On Thu, Jul 29, 2021 at 09:59:55AM -0700, Matt Roper wrote:
Although DG2_G10 platforms will always have all SQIDI's present and
don't need steering for registers in a SQIDI MMIO range, this isn't true
for DG2_G11 platforms; only SQIDI's 2 and 3 can be used on those.
We handle SQIDI ranges a bit
On Thu, Jul 29, 2021 at 09:59:54AM -0700, Matt Roper wrote:
DG2's replicated register ranges are almost the same at XeHP SDV with
the exception of one LNCF sub-range that switches to gslice steering.
We can re-use the XeHP SDV mslice steering table and just provide a
DG2-specific LNCF steering ta
On Thu, Jul 29, 2021 at 09:59:52AM -0700, Matt Roper wrote:
Define and initialize the MMIO ranges for which XeHP SDV requires MSLICE
and LNCF steering.
Bspec: 66534
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: Matt Roper
Reviewed-by: Lucas De Marchi
Lucas De Marchi
---
On Thu, Jul 29, 2021 at 09:59:51AM -0700, Matt Roper wrote:
From: Daniele Ceraolo Spurio
Xe_HP is more modular than its predecessors and as a consequence it has
more types of replicated registers. As with l3bank regions on previous
platforms, we may need to explicitly re-steer accesses to thes
On Mon, Aug 02, 2021 at 10:11:18PM -0700, Matthew Brost wrote:
> From: Venkata Sandeep Dhanalakota
>
> Defining vma on stack can cause stack overflow, if
> vma gets populated with new fields.
>
> Cc: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
> Signed-off-by: Venkata Sandeep Dhanalakota
> Si
Hi Dave and Daniel,
Here goes drm-intel-fixes-2021-08-04:
- Call i915_globals_exit if pci_register_device fails (Jason)
- Correct SFC_DONE register offset (Matt)
Thanks,
Rodrigo.
The following changes since commit c500bee1c5b2f1d59b1081ac879d73268ab0ff17:
Linux 5.14-rc4 (2021-08-01 17:04:17
Hi Dave and Daniel,
here's the weekly PR for drm-misc-fixes. I cherry-picked the vmwgfx
fix from drm-misc-next-fixes where it accidentally landed first.
Best regards
Thomas
drm-misc-fixes-2021-08-04:
Short summary of fixes pull:
* kmb: DMA fix; Add macros for driver date/version
* vmwgfx: Fix
== Series Details ==
Series: drm/i915/dp: Use max params for older panels
URL : https://patchwork.freedesktop.org/series/93390/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10445 -> Patchwork_20769
Summary
---
**SUC
== Series Details ==
Series: drm/i915/dp: Use max params for older panels
URL : https://patchwork.freedesktop.org/series/93390/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5f019446c196 drm/i915/dp: Use max params for older panels
-:6: ERROR:GIT_COMMIT_ID: Please use git commi
Users reported that after commit 2bbd6dba84d4 ("drm/i915: Try to use
fast+narrow link on eDP again and fall back to the old max strategy on
failure"), the screen starts to have wobbly effect.
Commit a5c936add6a2 ("drm/i915/dp: Use slow and wide link training for
everything") doesn't help either, t
== Series Details ==
Series: remove rcu support from i915_address_space (rev3)
URL : https://patchwork.freedesktop.org/series/93314/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10445 -> Patchwork_20768
Summary
---
== Series Details ==
Series: remove rcu support from i915_address_space (rev3)
URL : https://patchwork.freedesktop.org/series/93314/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-drivers/gpu/drm
== Series Details ==
Series: remove rcu support from i915_address_space (rev3)
URL : https://patchwork.freedesktop.org/series/93314/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
caf6e7f302eb drm/i915: Drop code to handle set-vm races from execbuf
-:17: WARNING:COMMIT_LOG_LONG_
On Wed, Aug 4, 2021 at 10:00 AM Thomas Hellström
wrote:
>
> Hi,
>
> On 7/22/21 11:59 AM, Matthew Auld wrote:
> > On Thu, 22 Jul 2021 at 10:49, Matthew Auld
> > wrote:
> >> On Wed, 21 Jul 2021 at 21:11, Jason Ekstrand wrote:
> >>> On Mon, Jul 19, 2021 at 8:35 AM Matthew Auld
> >>> wrote:
>
It's been invariant since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
this just completes the deed. I've tried to split out prep work for
more
Since
commit ccbc1b97948ab671335e950271e39766729736c3
Author: Jason Ekstrand
Date: Thu Jul 8 10:48:30 2021 -0500
drm/i915/gem: Don't allow changing the VM on running contexts (v4)
the gem_ctx->vm can't change anymore. Plus we always set the
intel_context->vm, so might as well use the help
The full audit is quite a bit of work:
- i915_dpt has very simple lifetime (somehow we create a display pagetable vm
per object, so its _very_ simple, there's only ever a single vma in there),
and uses i915_vm_close(), which internally does a i915_vm_put(). No rcu.
Aside: wtf is i915_dpt do
We don't need the absolute speed of rcu for this. And
i915_address_space in general dont need rcu protection anywhere else,
after we've made gem contexts and engines a lot more immutable.
Note that this semantically reverts
commit aabbe344dc3ca5f7d8263a02608ba6179e8a4499
Author: Chris Wilson
Dat
There's quite a fundamental difference between userspace contexts, and
kernel contexts. Latter all share intel_gt->vm, former get their vm
from gem_ctx->vm (on full ppgtt at least).
By splitting context creation for userspace from kernel-internal ones
we can make this all a bit more strict and WAR
Consolidates the "which is the vm my execbuf runs in" code a bit. We
do some get/put which isn't really required, but all the other users
want the refcounting, and I figured doing a function just for this
getparam to avoid 2 atomis is a bit much.
Signed-off-by: Daniel Vetter
Cc: Jon Bloomfield
C
The important part isn't so much that this does an rcu lookup - that's
more an implementation detail, which will also be removed.
The thing that makes this different from other functions is that it's
gettting you the vm that batchbuffers will run in for that gem
context, which is either a full ppg
And use it anywhere we have open-coded checks for ctx->vm that really
only check for full ppgtt.
Plus for paranoia add a GEM_BUG_ON that checks it's really only set
when we have full ppgtt, just in case. gem_context->vm is different
since it's NULL in ggtt mode, unlike intel_context->vm or gt->vm,
Changing the vm from a finalized gem ctx is no longer possible, which
means we don't have to check for that anymore.
I was pondering whether to keep the check as a WARN_ON, but things go
boom real bad real fast if the vm of a vma is wrong. Plus we'd need to
also get the ggtt vm for !full-ppgtt pla
Hi all,
Next round with some fixes:
- missed a conversion, 0day spotted it running sparse
- missed virtual engines in the last patch, intel-gfx-ci spotted that too
(except it was mostly filtered out by a bogus cibuglog entry, so took a
while to realize what's going on).
Old version:
https://
== Series Details ==
Series: series starting with [1/2] drm/i915: Disable gpu relocations
URL : https://patchwork.freedesktop.org/series/93340/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10442_full -> Patchwork_20765_full
Hi,
On 7/22/21 11:59 AM, Matthew Auld wrote:
On Thu, 22 Jul 2021 at 10:49, Matthew Auld
wrote:
On Wed, 21 Jul 2021 at 21:11, Jason Ekstrand wrote:
On Mon, Jul 19, 2021 at 8:35 AM Matthew Auld
wrote:
On Fri, 16 Jul 2021 at 20:49, Jason Ekstrand wrote:
On Fri, Jul 16, 2021 at 1:45 PM Matth
35 matches
Mail list logo
