== Series Details ==
Series: drm/i915/gem: ioctl clean-ups (rev6)
URL : https://patchwork.freedesktop.org/series/89443/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: drm/i915/gem: ioctl clean-ups (rev6)
URL : https://patchwork.freedesktop.org/series/89443/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
9bed855e16a0 drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
-:177: WARNING:FILE_PATH_CHANGES: added, moved or
Now that we have the whole engine set and VM at context creation time,
we can just assign those fields instead of creating first and handling
the VM and engines later. This lets us avoid creating useless VMs and
engine sets and lets us get rid of the complex VM setting code.
Signed-off-by: Jason
This instance now only happens during context creation so there's no way
we can race with a context close/destroy. We don't need to bother with
the RCU and can access the pointer directly.
Signed-off-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 +
1 file
We want to delete __assign_ppgtt and, generally, stop setting the VM
after context creation. This is the one place I could find in the
selftests where we set a VM after the fact.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
All the proto-context stuff for context creation exists to allow older
userspace drivers to set VMs and engine sets via SET_CONTEXT_PARAM.
Drivers need to update to use CONTEXT_CREATE_EXT_* for this going
forward. Force the issue by blocking the old mechanism on any future
hardware generations.
This better models where we want to go with contexts in general where
things like the VM and engine set are create parameters instead of being
set after the fact.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
.../drm/i915/gem/selftests/i915_gem_context.c | 4 ++--
This means that the proto-context needs to grow support for engine
configuration information as well as setparam logic. Fortunately, we'll
be deleting a lot of setparam logic on the primary context shortly so it
will hopefully balance out.
There's an extra bit of fun here when it comes to
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the
When the APIs were added to manage the engine set on a GEM context
directly from userspace, the questionable choice was made to allow
changing the engine set on a context at any time. This is horribly racy
and there's absolutely no reason why any userspace would want to do this
outside of trying
When the APIs were added to manage VMs more directly from userspace, the
questionable choice was made to allow changing out the VM on a context
at any time. This is horribly racy and there's absolutely no reason why
any userspace would want to do this outside of testing that exact race.
By
There's a big comment saying how useful it is but no one is using this
for anything anymore.
It was added in 2bfa996e031b ("drm/i915: Store owning file on the
i915_address_space") and used for debugfs at the time as well as telling
the difference between the global GTT and a PPGTT. In
We're about to start doing lazy context creation which means contexts
get created in i915_gem_context_lookup and we may start having more
errors than -ENOENT.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c| 12 ++--
What we really want to check is that size of the engines array, i.e.
args->size - sizeof(*user) is divisible by the element size, i.e.
sizeof(*user->engines) because that's what's required for computing the
array length right below the check. However, we're currently not doing
this and instead
This is the VM equivalent of i915_gem_context_lookup. It's only used
once in this patch but future patches will need to duplicate this lookup
code so it's better to have it in a helper.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c |
For now this is a no-op because everyone passes in a null SSEU but it
lets us get some of the error handling and selftest refactoring plumbed
through.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 41 +++
The current context uAPI allows for two methods of setting context
parameters: SET_CONTEXT_PARAM and CONTEXT_CREATE_EXT_SETPARAM. The
former is allowed to be called at any time while the later happens as
part of GEM_CONTEXT_CREATE. Currently, everything settable via one is
settable via the
Since free_engines works for partially constructed engine sets, we can
use the usual goto pattern.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git
In order to prevent kernel doc warnings, also fill out docs for any
missing fields and fix those that forgot the "@".
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
Documentation/gpu/i915.rst| 2 +
.../gpu/drm/i915/gem/i915_gem_context_types.h | 43
As far as I can tell, the only real reason for this is to avoid taking a
reference to the i915_gem_context. The cost of those two atomics
probably pales in comparison to the cost of the ioctl itself so we're
really not buying ourselves anything here. We're about to make context
lookup a tiny bit
With the proto-context stuff added later in this series, we end up
having to duplicate set_priority. This lets us avoid duplicating the
validation logic.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 42 +
1 file
There's no sense in allowing userspace to create more engines than it
can possibly access via execbuf.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
This was only ever used for FENCE_SUBMIT automatic engine selection
which was removed in the previous commit.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 3 +-
drivers/gpu/drm/i915/i915_request.c | 42
Even though FENCE_SUBMIT is only documented to wait until the request in
the in-fence starts instead of waiting until it completes, it has a bit
more magic than that. If FENCE_SUBMIT is used to submit something to a
balanced engine, we would wait to assign engines until the primary
request was
This adds a bunch of complexity which the media driver has never
actually used. The media driver does technically bond a balanced engine
to another engine but the balanced engine only has one engine in the
sibling set. This doesn't actually result in a virtual engine.
This functionality was
This has never been used by any userspace except IGT and provides no
real functionality beyond parroting back parameters userspace passed in
as part of context creation or via setparam. If the context is in
legacy mode (where you use I915_EXEC_RENDER and friends), it returns
success with zero
This API is entirely unnecessary and I'd love to get rid of it. If
userspace wants a single timeline across multiple contexts, they can
either use implicit synchronization or a syncobj, both of which existed
at the time this feature landed. The justification given at the time
was that it would
This API allows one context to grab bits out of another context upon
creation. It can be used as a short-cut for setparam(getparam()) for
things like I915_CONTEXT_PARAM_VM. However, it's never been used by any
real userspace. It's used by a few IGT tests and that's it. Since it
doesn't add any
Instead of handling it like a context param, unconditionally set it when
intel_contexts are created. For years we've had the idea of a watchdog
uAPI floating about. The aim was for media, so that they could set very
tight deadlines for their transcodes jobs, so that if you have a corrupt
None of the callbacks we use with it return an error code anymore; they
all return 0 unconditionally.
Signed-off-by: Jason Ekstrand
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 26 +++--
1 file changed, 8 insertions(+), 18 deletions(-)
diff
The idea behind this param is to support OpenCL drivers with relocations
because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
would confuse CL kernels. It was originally sent out as part of a patch
series including libdrm [1] and Beignet [2] support. However, the
libdrm and
Previously, we were storing the ring size in the ring pointer before it
was actually allocated. We would then guard setting the ring size on
checking for CONTEXT_ALLOC_BIT. This is error-prone at best and really
only saves us a few bytes on something that already burns at least 4K.
Instead, this
This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
ringsize on construction"). This API was originally added for OpenCL
but the compute-runtime PR has sat open for a year without action so we
can still pull it out if we want. I argue we should drop it for three
reasons:
1.
Overview:
-
This patch series attempts to clean up some of the IOCTL mess we've created
over the last few years. The most egregious bit being context mutability.
In summary, this series:
1. Drops two never-used context params: RINGSIZE and NO_ZEROMAP
2. Drops the entire CONTEXT_CLONE
== Series Details ==
Series: Introduce i915_sched_engine object (rev3)
URL : https://patchwork.freedesktop.org/series/90630/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10194_full -> Patchwork_20315_full
Summary
---
#endif /* _ABI_GUC_COMMUNICATION_MMIO_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index f147cb389a20..b773567cb080 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -376,29 +376,27 @@
== Series Details ==
Series: drm/i915/adl_p: Add initial ADL_P Workarounds (rev2)
URL : https://patchwork.freedesktop.org/series/91127/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10194_full -> Patchwork_20314_full
== Series Details ==
Series: Introduce i915_sched_engine object (rev3)
URL : https://patchwork.freedesktop.org/series/90630/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel:
== Series Details ==
Series: Introduce i915_sched_engine object (rev3)
URL : https://patchwork.freedesktop.org/series/90630/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10194 -> Patchwork_20315
Summary
---
== Series Details ==
Series: drm/i915: Flush buffer pools on driver remove
URL : https://patchwork.freedesktop.org/series/91177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10191_full -> Patchwork_20312_full
Summary
== Series Details ==
Series: drm/i915/adl_p: Add initial ADL_P Workarounds (rev2)
URL : https://patchwork.freedesktop.org/series/91127/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel:
== Series Details ==
Series: drm/i915/adl_p: Add initial ADL_P Workarounds (rev2)
URL : https://patchwork.freedesktop.org/series/91127/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10194 -> Patchwork_20314
Summary
---
On Tue, 2021-06-08 at 11:28 +0200, Thomas Hellström wrote:
> From: Chris Wilson
>
> If we pipeline the PTE updates and then do the copy of those pages
> within a single unpreemptible command packet, we can submit the
> copies
> and leave them to be scheduled without having to synchronously wait
== Series Details ==
Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev4)
URL : https://patchwork.freedesktop.org/series/90129/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10191_full -> Patchwork_20311_full
Summary
On Tue, 2021-06-08 at 17:18 +0100, Matthew Auld wrote:
> On Tue, 8 Jun 2021 at 10:29, Thomas Hellström
> wrote:
> >
> > From: Chris Wilson
> >
> > If we pipeline the PTE updates and then do the copy of those pages
> > within a single unpreemptible command packet, we can submit the
> > copies
>
== Series Details ==
Series: Add "activ bpc" and "active color format" drm property
URL : https://patchwork.freedesktop.org/series/91188/
State : failure
== Summary ==
Applying: drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc
Applying: drm/uAPI: Add "active bpc" as feedback
On Tue, 2021-06-08 at 18:17 +0100, Matthew Auld wrote:
> On Tue, 8 Jun 2021 at 10:29, Thomas Hellström
> wrote:
> >
> > Introduce a for_i915_gem_ww(){} utility to help make the code
> > around a ww transaction more readable.
> >
> > Signed-off-by: Thomas Hellström
> > ---
> >
Rather passing around an intel_engine_cs in the scheduling code, pass
around a i915_sched_engine.
v3:
(Jason Ekstrand)
Add READ_ONCE around rq->engine in lock_sched_engine
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
.../drm/i915/gt/intel_execlists_submission.c | 11 +++--
The submission tasklet operates on i915_sched_engine, thus it is the
correct place for it.
v3:
(Jason Ekstrand)
Change sched_engine->engine to a void* private data pointer
Add kernel doc
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine.h| 14 ---
Rather than touching execlist specific structures in the generic
scheduling code, add a callback function in the backend.
Signed-off-by: Matthew Brost
---
.../drm/i915/gt/intel_execlists_submission.c | 52
drivers/gpu/drm/i915/i915_scheduler.c | 62 +--
Rather than touching schedule state in the generic PM code, reset the
priolist allocation when empty in the submission code. Add a wrapper
function to do this and update the backends to call it in the correct
place.
v3:
(Jason Ekstrand)
Update patch commit message with a better description
Introduce i915_sched_engine object which is lower level data structure
that i915_scheduler / generic code can operate on without touching
execlist specific structures. This allows additional submission backends
to be added without breaking the layering.
This is a bit of detour to integrating the
As discussed in [1] we are breaking that large series into a several
smaller ones. This series is stand alone patch part of step #4 which has
no other dependencies or patches relevant to it.
v2:
(Daniel Vetter):
- Split into several smaller patches
- Add kernel doc for i915_sched_engine
Move active request tracking and its lock to i915_sched_engine. This
lock is also the submission lock so having it in the i915_sched_engine
is the correct place.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine.h| 2 -
The schedule function should be in the schedule object.
v3:
(Jason Ekstrand)
Add kernel doc
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
Add wrapper function around RB tree to determine if i915_sched_engine is
empty.
Signed-off-by: Matthew Brost
Reviewed-by: Jason Ekstrand
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
From: Clint Taylor
Most of the context WA are already implemented.
Adding adl_p platform tag to reflect so.
v2: adjust comments for clarity (MattR)
BSpec: 54369
Cc: Matt Roper
Cc: Aditya Swarup
Reviewed-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Anusha Srivatsa
This commit implements the "active color format" drm property for the Intel GPU
driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 20 +++-
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_dp_mst.c |
This commit implements the "active color format" drm property for the AMD GPU
driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 27 +--
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 1 +
2 files changed, 26 insertions(+), 2 deletions(-)
Add a new general drm property "active bpc" which can be used by graphic drivers
to report the applied bit depth per pixel back to userspace.
While "max bpc" can be used to change the color depth, there was no way to check
which one actually got used. While in theory the driver chooses the
This commit implements the "active bpc" drm property for the AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c| 4 +++-
2 files changed, 20 insertions(+), 2 deletions(-)
Add a new general drm property "active color format" which can be used by
graphic drivers to report the used color format back to userspace.
There was no way to check which color format got actually used on a given
monitor. To surely predict this, one must know the exact capabilities of the
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an
integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4
1 file changed, 4 insertions(+)
diff --git
This commits implements the "active bpc" drm property for the Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 14 ++
drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-
I started work on my proposal for better color handling in Linux display
drivers: https://lkml.org/lkml/2021/5/12/764
In this 2nd revision the first two read-only properties are now implemented for
amdgpu and i915. I post it here to collect collect some additional feedback, if
someone sees an
On Tue, 2021-06-08 at 14:08 +, Patchwork wrote:
Patch Details
Series: series starting with [v4,1/2] drm/i915/display: Introduce new
intel_psr_pause/resume function
URL:https://patchwork.freedesktop.org/series/91152/
State: success
Details:
Am 07.06.21 um 22:33 schrieb Werner Sembach:
Am 07.06.21 um 08:47 schrieb Werner Sembach:
Am 04.06.21 um 19:30 schrieb Ville Syrjälä:
On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote:
This commits implements the "active bpc" drm property for the Intel
GPU driver.
On Tue, 8 Jun 2021 at 10:29, Thomas Hellström
wrote:
>
> Introduce a for_i915_gem_ww(){} utility to help make the code
> around a ww transaction more readable.
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/i915_gem_ww.h | 31 +-
> 1 file changed,
On Tue, 8 Jun 2021 at 10:29, Thomas Hellström
wrote:
>
> As we're about to add more ww-related functionality,
> break out the dma_resv ww locking utilities to their own files
>
> Signed-off-by: Thomas Hellström
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
>
On Tue, 8 Jun 2021 at 10:29, Thomas Hellström
wrote:
>
> Since the ww transaction endpoint easily end up far out-of-scope of
> the objects on the ww object list, particularly for contending lock
> objects, make sure we reference objects on the list so they don't
> disappear under us.
>
> This
On Tue, Jun 8, 2021 at 6:38 AM Tejas Upadhyay
wrote:
>
> When pipe A is disabled and MIPI DSI is enabled on pipe B,
> the AMT KVMR feature will incorrectly see pipe A as enabled.
> Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave
> it set while DSI is enabled on pipe B. No impact to
On Tue, 8 Jun 2021 at 10:29, Thomas Hellström
wrote:
>
> From: Chris Wilson
>
> If we pipeline the PTE updates and then do the copy of those pages
> within a single unpreemptible command packet, we can submit the copies
> and leave them to be scheduled without having to synchronously wait
>
== Series Details ==
Series: drm/i915: Flush buffer pools on driver remove
URL : https://patchwork.freedesktop.org/series/91177/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10191 -> Patchwork_20312
Summary
---
== Series Details ==
Series: drm/i915: Flush buffer pools on driver remove
URL : https://patchwork.freedesktop.org/series/91177/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel:
In preparation for clean driver release, attempts to drain work queues
and release freed objects are taken at driver remove time. However, GT
buffer pools are now not flushed before the driver release phase.
Since unused objects may stay there for up to one second, some may
survive until driver
== Series Details ==
Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev4)
URL : https://patchwork.freedesktop.org/series/90129/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel:
== Series Details ==
Series: drm/i915/jsl: Add W/A 1409054076 for JSL (rev4)
URL : https://patchwork.freedesktop.org/series/90129/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10191 -> Patchwork_20311
Summary
---
== Series Details ==
Series: series starting with [v4,1/2] drm/i915/display: Introduce new
intel_psr_pause/resume function
URL : https://patchwork.freedesktop.org/series/91152/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10188_full -> Patchwork_20308_full
== Series Details ==
Series: Add back the buddy allocator (rev3)
URL : https://patchwork.freedesktop.org/series/91110/
State : failure
== Summary ==
Applying: drm/i915/ttm: add ttm_buddy_man
Applying: drm/i915/ttm: add i915_sg_from_buddy_resource
Applying: drm/i915/ttm: Calculate the object
This is a "v3" of the previous posted full conversion:
https://lore.kernel.org/r/0-v2-7667f42c9bad+935-vfio3_...@nvidia.com
Without the trailing patches that are running into complications:
- The CCW conversion has some complicated remarks
- AP is waiting for some locking stuff to get worked
Btw, you list of CCs is a mess as alsmost no one is CCed on the whole
list can can thus properly review it.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Looks good,
Reviewed-by: Christoph Hellwig
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
For some reason the vfio_mdev shim mdev_driver has its own module and
kconfig. As the next patch requires access to it from mdev.ko merge the
two modules together and remove VFIO_MDEV_DEVICE.
A later patch deletes this driver entirely.
Signed-off-by: Jason Gunthorpe
---
When pipe A is disabled and MIPI DSI is enabled on pipe B,
the AMT KVMR feature will incorrectly see pipe A as enabled.
Set 0x42080 bit 23=1 before enabling DSI on pipe B and leave
it set while DSI is enabled on pipe B. No impact to setting
it all the time.
Changes since V3:
- More
== Series Details ==
Series: drm/i915: DDI buf trans cleaup and fixes (rev4)
URL : https://patchwork.freedesktop.org/series/89311/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10188_full -> Patchwork_20306_full
Summary
== Series Details ==
Series: Prereqs for TTM accelerated migration
URL : https://patchwork.freedesktop.org/series/91155/
State : warning
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
CHK include/generated/compile.h
Kernel: arch/x86/boot/bzImage
== Series Details ==
Series: Prereqs for TTM accelerated migration
URL : https://patchwork.freedesktop.org/series/91155/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10190 -> Patchwork_20309
Summary
---
**FAILURE**
On Tue, 2021-06-08 at 12:02 +0100, Matthew Auld wrote:
> Now that ttm_resource_manager just returns a generic ttm_resource we
> don't need to reference the mm_node stuff anymore which mostly only
> makes sense for drm_mm_node. In the next few patches we want switch
> over
> to the ttm_buddy_man
== Series Details ==
Series: Prereqs for TTM accelerated migration
URL : https://patchwork.freedesktop.org/series/91155/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
2242ed7d4819 drm/i915: Reference objects on the ww object list
80e16d0ed0bd drm/i915: Break out dma_resv ww
Thank you so much Juha-Pekka.
Regards
Vidya
-Original Message-
From: Juha-Pekka Heikkila
Sent: Tuesday, June 8, 2021 5:21 PM
To: Srinivas, Vidya ; Modem, Bhanuprakash
; intel-gfx@lists.freedesktop.org;
igt-...@lists.freedesktop.org
Cc: Lin, Charlton
Subject: Re: [igt-dev]
On 8.6.2021 12.19, Srinivas, Vidya wrote:
Hello Juha-Pekka
Instead of wait for vblank, this also works
igt_pipe_crc_start-> igt_pipe_crc_get_current for small fb after commit -> then
igt_pipe_crc_get_current For big fb -> compare -> igt_pipe_crc_stop
Would this change be okay? Kindly suggest.
On Tue, Jun 08, 2021 at 11:04:11AM +0530, Tejas Upadhyay wrote:
> Let's reserve JSL stolen memory for graphics.
>
> JasperLake is a gen11 platform which is compatible with
> ICL/EHL changes.
>
> Required due to below reference patch:
>
> commit 24ea098b7c0d80b56d62a200608e0b029056baf6
>
Am 08.06.21 um 09:06 schrieb Felix Kuehling:
Am 2021-06-08 um 2:55 a.m. schrieb Christian König:
Hi Felix,
that should already be fixed in drm-tip as part of the merge of the
TTM changes.
No, the preempt_mgr doesn't exist in drm-misc-next. It does exist in
drm-next, but that doesn't seem to
== Series Details ==
Series: x86/gpu: add JasperLake to gen11 early quirks (rev6)
URL : https://patchwork.freedesktop.org/series/91082/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10188_full -> Patchwork_20305_full
> -Original Message-
> From: Borislav Petkov
> Sent: 08 June 2021 16:35
> To: Surendrakumar Upadhyay, TejaskumarX
>
> Cc: intel-gfx@lists.freedesktop.org; t...@linutronix.de; mi...@redhat.com;
> h...@zytor.com; x...@kernel.org; Souza, Jose
> Subject: Re: [PATCH V3] x86/gpu: add
Am 2021-06-08 um 2:55 a.m. schrieb Christian König:
> Hi Felix,
>
> that should already be fixed in drm-tip as part of the merge of the
> TTM changes.
No, the preempt_mgr doesn't exist in drm-misc-next. It does exist in
drm-next, but that doesn't seem to have the TTM changes yet.
Is there
We now have bo->page_alignment which perfectly describes what we need if
we have min page size restrictions for lmem. We can also drop the flag
here, since this is the default behaviour for all objects.
v2(Thomas):
- bo->page_alignment is in page units
Signed-off-by: Matthew Auld
Cc: Thomas
Move back to the buddy allocator for managing device local memory, and
restore the lost mock selftests. Keep around the range manager related
bits, since we likely need this for managing stolen at some point. For
stolen we also don't need to reserve anything so no need to support a
generic reserve
Now that ttm_resource_manager just returns a generic ttm_resource we
don't need to reference the mm_node stuff anymore which mostly only
makes sense for drm_mm_node. In the next few patches we want switch over
to the ttm_buddy_man which is just another type of ttm_resource so
reflect that in the
Currently we just ignore the I915_BO_ALLOC_CONTIGUOUS flag, which is
fine since everything is already contiguous with the ttm range manager.
However in the next patch we want to switch over to the ttm buddy
manager, where allocations are by default not contiguous.
v2(Thomas):
- Forward
1 - 100 of 200 matches
Mail list logo
