> -Original Message-
> From: Sharma, Swati2
> Sent: Thursday, July 8, 2021 1:07 AM
> To: Shankar, Uma ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/display/xelpd: Fix incorrect color capability
> reporting
>
> Reviewed-by: Swati Sharma
Merged the change to
On Thu, Jul 08, 2021 at 04:18:20PM -0700, Anusha Srivatsa wrote:
> Add a helper to convert the step info to string.
> This is specifically useful when we want to load a specific
> firmware for a given stepping/substepping combination.
What if we use macros to generate the per-stepping code here
On Thu, Jul 08, 2021 at 04:18:19PM -0700, Anusha Srivatsa wrote:
> Switch BXT to use a revid->stepping table as we're trying to do on all
> platforms going forward.
>
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/intel_step.c | 12
> 1 file changed, 12 insertions(+)
== Series Details ==
Series: Get stepping info from RUNTIME_INFO->step
URL : https://patchwork.freedesktop.org/series/92346/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10320 -> Patchwork_20560
Summary
---
== Series Details ==
Series: Get stepping info from RUNTIME_INFO->step
URL : https://patchwork.freedesktop.org/series/92346/
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: Get stepping info from RUNTIME_INFO->step
URL : https://patchwork.freedesktop.org/series/92346/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c109c3b789aa drm/i915: Make pre-production detection use direct revid comparison
8ad43b5ade6f
== Series Details ==
Series: drm/sched dependency tracking and dma-resv fixes (rev2)
URL : https://patchwork.freedesktop.org/series/92333/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10320 -> Patchwork_20559
Summary
== Series Details ==
Series: drm/sched dependency tracking and dma-resv fixes (rev2)
URL : https://patchwork.freedesktop.org/series/92333/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
aa63f4780928 drm/sched: entity->rq selection cannot fail
-:52: WARNING:AVOID_BUG: Avoid
On Thu, Jul 01, 2021 at 01:24:26PM -0700, Matt Roper wrote:
> From: Animesh Manna
>
> In verify_mpllb_state() encoder is retrieved from best_encoder
> of connector_state. As there will be only one connector_state
> for bigjoiner and checking encoder may not be needed for
> bigjoiner-slave. This
== Series Details ==
Series: series starting with [1/7] drm/i915: Settle on "adl-x" in WA comments
URL : https://patchwork.freedesktop.org/series/92342/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10320 -> Patchwork_20558
== Series Details ==
Series: series starting with [1/7] drm/i915: Settle on "adl-x" in WA comments
URL : https://patchwork.freedesktop.org/series/92342/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: drm/i915/dg1: Compute MEM Bandwidth using MCHBAR (rev2)
URL : https://patchwork.freedesktop.org/series/92094/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10320 -> Patchwork_20557
Summary
Add a helper to convert the step info to string.
This is specifically useful when we want to load a specific
firmware for a given stepping/substepping combination.
Suggested-by: Jani Nikula
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_step.c | 58
From: Matt Roper
All of the Cannon Lake hardware that came out had graphics fused off,
and our userspace drivers have already dropped their support for the
platform; CNL-specific code in i915 that isn't inherited by subsequent
platforms is effectively dead code. Let's remove all of the
From: Matt Roper
Switch RKL to use a revid->stepping table as we're trying to do on all
platforms going forward.
Bspec: 44501
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_psr.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 8 ++--
With all platforms having the tepping info in intel_step.c,
it makes no sense to maintain a separate lookup table
in intel_dmc.c Let modify intel_Get_stepping_info()
to grab stepping info from the central location towards
which everything is moving.
Cc: Jani Nikula
Signed-off-by: Anusha Srivatsa
The changes are added on top of Matt's series:
https://patchwork.freedesktop.org/series/92299/
This series modifies the way we get stepping indo for DMC
to load the right firmware for the right stepping/substepping
combinations.
Since we have a lookup table for BXT in intel_dmc.c and BXT
From: Matt Roper
Switch JSL/EHL to use a revid->stepping table as we're trying to do on
all platforms going forward.
Bspec: 29153
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 2 +-
drivers/gpu/drm/i915/gt/intel_workarounds.c | 2 +-
Switch BXT to use a revid->stepping table as we're trying to do on all
platforms going forward.
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_step.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_step.c
From: Matt Roper
Switch DG1 to use a revid->stepping table as we're trying to do on all
platforms going forward.
This removes the last use of IS_REVID() and REVID_FOREVER, so remove
those now-unused macros as well to prevent their accidental use on
future platforms.
Bspec: 44463
Signed-off-by:
From: Matt Roper
Switch SKL to use a revid->stepping table as we're trying to do on all
platforms going forward. Also add some additional stepping definitions
for completeness, even if we don't have any workarounds tied to them.
Note that SKL has a case where a newer revision ID corresponds to
From: Matt Roper
Switch ICL to use a revid->stepping table as we're trying to do on all
platforms going forward. While we're at it, let's include some
additional steppings that have popped up, even if we don't yet have any
workarounds tied to those steppings (we probably need to audit our
From: Matt Roper
Although we're converting our workarounds to use a revid->stepping
lookup table, the function that detects pre-production hardware should
continue to compare against PCI revision ID values directly. These are
listed in the bspec as integers, so it's easier to confirm their
> -Original Message-
> From: Roper, Matthew D
> Sent: Thursday, July 8, 2021 4:05 PM
> To: Srivatsa, Anusha
> Cc: Jani Nikula ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 0/7] Minor revid/stepping and workaround cleanup
>
> On Thu, Jul 08, 2021 at 11:37:50AM -0700,
On Thu, Jul 08, 2021 at 11:37:50AM -0700, Srivatsa, Anusha wrote:
>
>
> > -Original Message-
> > From: Jani Nikula
> > Sent: Thursday, July 8, 2021 12:33 AM
> > To: Roper, Matthew D ; intel-
> > g...@lists.freedesktop.org
> > Cc: Srivatsa, Anusha
> > Subject: Re: [PATCH 0/7] Minor
On 2021-07-08 1:37 p.m., Daniel Vetter wrote:
It might be good enough on x86 with just READ_ONCE, but the write side
should then at least be WRITE_ONCE because x86 has total store order.
It's definitely not enough on arm.
Fix this proplery, which means
- explain the need for the barrier in
== Series Details ==
Series: CT changes required for GuC submission
URL : https://patchwork.freedesktop.org/series/92330/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10320 -> Patchwork_20556
Summary
---
== Series Details ==
Series: CT changes required for GuC submission
URL : https://patchwork.freedesktop.org/series/92330/
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: Set BPP in the kernel (rev2)
URL : https://patchwork.freedesktop.org/series/92312/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10320 -> Patchwork_20554
Summary
---
**SUCCESS**
No
== Series Details ==
Series: drm/i915/gem: ioctl clean-ups (rev8)
URL : https://patchwork.freedesktop.org/series/89443/
State : failure
== Summary ==
Applying: drm/i915: Drop I915_CONTEXT_PARAM_RINGSIZE
Using index info to reconstruct a base tree...
M drivers/gpu/drm/i915/Makefile
M
== Series Details ==
Series: Set BPP in the kernel (rev2)
URL : https://patchwork.freedesktop.org/series/92312/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
It might be good enough on x86 with just READ_ONCE, but the write side
should then at least be WRITE_ONCE because x86 has total store order.
It's definitely not enough on arm.
Fix this proplery, which means
- explain the need for the barrier in both places
- point at the other side in each
BSpec: 54370
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index
Alderlake-P PCODE is returning 4 memory channels while it has a
maximum of 2.
So adding this limit and printing a debug message but the real fix
will need to come from PCODE.
HSDES: 22013272110
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/intel_dram.c | 4
1 file changed,
From: Lucas De Marchi
Most of the places are using this format so lets consolidate it.
Signed-off-by: José Roberto de Souza
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 2 +-
drivers/gpu/drm/i915/display/intel_cursor.c| 2 +-
Alderlake-P have different values for MBUS DBOX A credits depending
if MBUS join is enabled or not.
BSpec: 50343
BSpec: 54369
Cc: Matt Atwood
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 16
1 file changed, 12 insertions(+), 4
This workaround is not needed for platforms with display 13.
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
This workaround is also applicable to xelpd display so extending it.
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_power.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Same bit was required for Wa_14012131227 in DG1 now it is also
required as Wa_1508744258 to TGL, RKL, DG1, ADL-S and ADL-P.
Cc: Gwan-gyeong Mun
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
== Series Details ==
Series: drm/i915/display/xelpd: Fix incorrect color capability reporting
URL : https://patchwork.freedesktop.org/series/92266/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10308_full -> Patchwork_20542_full
On Thu, Jul 8, 2021 at 8:56 PM Andrey Grodzovsky
wrote:
> On 2021-07-08 1:37 p.m., Daniel Vetter wrote:
> > It might be good enough on x86 with just READ_ONCE, but the write side
> > should then at least be WRITE_ONCE because x86 has total store order.
> >
> > It's definitely not enough on arm.
>
> -Original Message-
> From: Jani Nikula
> Sent: Thursday, July 8, 2021 12:33 AM
> To: Roper, Matthew D ; intel-
> g...@lists.freedesktop.org
> Cc: Srivatsa, Anusha
> Subject: Re: [PATCH 0/7] Minor revid/stepping and workaround cleanup
>
> On Wed, 07 Jul 2021, Matt Roper wrote:
> >
> -Original Message-
> From: Intel-gfx On Behalf Of
> Matt Roper
> Sent: Wednesday, July 7, 2021 10:38 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/7] drm/i915/skl: Use revid->stepping tables
>
> Switch SKL to use a revid->stepping table as we're trying to
> -Original Message-
> From: Intel-gfx On Behalf Of
> Matt Roper
> Sent: Wednesday, July 7, 2021 10:38 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/7] drm/i915: Make pre-production detection
> use direct revid comparison
>
> Although we're converting our
On Thu, Jul 08, 2021 at 10:48:05AM -0500, Jason Ekstrand wrote:
> 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
From: Clint Taylor
The PUNIT FW is currently returning 0 for all memory bandwidth
parameters. Read the values directly from MCHBAR offsets 0x5918 and
0x4000(4).
v2 (Lucas): tidy up checking for ret slightly
v3 (Lucas):
- Squash change to double the memory bandwidth based on
MCHBAR
The following changes since commit d79c26779d459063b8052b7fe0a48bce4e08d0d9:
amdgpu: update vcn firmware for green sardine for 21.20 (2021-06-29 07:26:03
-0400)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware guc_62.0_huc_7.9
for you to fetch changes
Specifically document the new/clarified rules around how the shared
fences do not have any ordering requirements against the exclusive
fence.
But also document all the things a bit better, given how central
struct dma_resv to dynamic buffer management the docs have been very
inadequat.
- Lots
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore
No longer used, the last user disappeared with
commit d07f0e59b2c762584478920cd2d11fba2980a94a
Author: Chris Wilson
Date: Fri Oct 28 13:58:44 2016 +0100
drm/i915: Move GEM activity tracking into a common struct reservation_object
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc:
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore
From: Christian König
Drivers also need to to sync to the exclusive fence when
a shared one is present.
Signed-off-by: Christian König
[danvet: Not that hard to compile-test on arm ...]
Signed-off-by: Daniel Vetter
Cc: Rob Clark
Cc: Sean Paul
Cc: linux-arm-...@vger.kernel.org
Cc:
There's only one exclusive slot, and we must not break the ordering.
Adding a new exclusive fence drops all previous fences from the
dma_resv. To avoid violating the signalling order we err on the side of
over-synchronizing by waiting for the existing fences, even if
userspace asked us to ignore
You really need to hold the reservation here or all kinds of funny
things can happen between grabbing the dependencies and inserting the
new fences.
Signed-off-by: Daniel Vetter
Cc: "Christian König"
Cc: Daniel Vetter
Cc: Luben Tuikov
Cc: Andrey Grodzovsky
Cc: Alex Deucher
Cc: Jack Zhang
This is essentially part of drm_sched_dependency_optimized(), which
only amdgpu seems to make use of. Use it a bit more.
This would mean that as-is amdgpu can't use the dependency helpers, at
least not with the current approach amdgpu has for deciding whether a
vm_flush is needed. Since amdgpu
Integrated into the scheduler now and all users converted over.
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc:
We need to pull the drm_sched_job_init much earlier, but that's very
minor surgery.
v2: Actually fix up cleanup paths by calling drm_sched_job_init, which
I wanted to to in the previous round (and did, for all other drivers).
Spotted by Lucas.
Signed-off-by: Daniel Vetter
Cc: Lucas Stach
Cc:
Prep work for using the scheduler dependency handling. We need to call
drm_sched_job_init earlier so we can use the new drm_sched_job_await*
functions for dependency handling here.
v2: Slightly better commit message and rebase to include the
drm_sched_job_arm() call (Emma).
v3: Cleanup jobs
Nothing special going on here.
Aside reviewing the code, it seems like drm_sched_job_arm() should be
moved into lima_sched_context_queue_task and put under some mutex
together with drm_sched_push_job(). See the kerneldoc for
drm_sched_push_job().
Signed-off-by: Daniel Vetter
Cc: Qiang Yu
Cc:
With the prep work out of the way this isn't tricky anymore.
Aside: The chaining of the various jobs is a bit awkward, with the
possibility of failure in bad places. I think with the
drm_sched_job_init/arm split and maybe preloading the
job->dependencies xarray this should be fixable.
Cc:
I found a few too many things that are tricky and not documented, so I
started typing.
I found a few more things that looked broken while typing, see the
varios FIXME in drm_sched_entity.
Also some of the usual logics:
- actually include sched_entity.c declarations, that was lost in the
move
Originally a job was only bound to the queue when we pushed this, but
now that's done in drm_sched_job_init, making that parameter entirely
redundant.
Remove it.
The same applies to the context parameter in
lima_sched_context_queue_task, simplify that too.
Reviewed-by: Steven Price (v1)
Just deletes some code that's now more shared.
Note that thanks to the split into drm_sched_job_init/arm we can now
easily pull the _init() part from under the submission lock way ahead
where we're adding the sync file in-fences as dependencies.
v2: Correctly clean up the partially set up job,
Instead of just a callback we can just glue in the gem helpers that
panfrost, v3d and lima currently use. There's really not that many
ways to skin this cat.
On the naming bikeshed: The idea for using _await_ to denote adding
dependencies to a job comes from i915, where that's used quite
It might be good enough on x86 with just READ_ONCE, but the write side
should then at least be WRITE_ONCE because x86 has total store order.
It's definitely not enough on arm.
Fix this proplery, which means
- explain the need for the barrier in both places
- point at the other side in each
If it does, someone managed to set up a sched_entity without
schedulers, which is just a driver bug.
We BUG_ON() here because in the next patch drm_sched_job_init() will
be split up, with drm_sched_job_arm() never failing. And that's the
part where the rq selection will end up in.
Note that if
This is a very confusingly named function, because not just does it
init an object, it arms it and provides a point of no return for
pushing a job into the scheduler. It would be nice if that's a bit
clearer in the interface.
But the real reason is that I want to push the dependency tracking
Hil all,
I figured I'll combine the two series, they build on top of each another
anyway. Changes:
- drop broken i915 patch (Matt)
- typos and improvements in the dma-resv patch
- bunch of fixes to the drm_sched_job_init/arm split (Melissa, Christian)
- threw a drm_sched_entity doc patch on top
On Tue, Jul 06, 2021 at 12:14:16PM -0700, Nathan Chancellor wrote:
> On 7/6/2021 10:06 AM, Will Deacon wrote:
> > On Tue, Jul 06, 2021 at 04:39:11PM +0100, Robin Murphy wrote:
> > > On 2021-07-06 15:05, Christoph Hellwig wrote:
> > > > On Tue, Jul 06, 2021 at 03:01:04PM +0100, Robin Murphy wrote:
> -Original Message-
> From: Nikula, Jani
> Sent: Thursday, July 8, 2021 9:53 PM
> To: Kulkarni, Vandita ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [v7 3/3] drm/i915/display/dsc: Force dsc BPP
>
> On Thu, 08 Jul 2021, "Kulkarni, Vandita" wrote:
> >> -Original
On Thu, 08 Jul 2021, "Kulkarni, Vandita" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Thursday, July 8, 2021 6:44 PM
>> To: Kulkarni, Vandita ; intel-
>> g...@lists.freedesktop.org
>> Cc: Kulkarni, Vandita
>> Subject: Re: [v7 3/3] drm/i915/display/dsc: Force dsc BPP
>>
As part of enabling GuC submission discussed in [1], [2], and [3] we
need optimize and update the CT code as this is now in the critical
path of submission. This series includes the patches to do that which is
the first 7 patches from [3]. The patches should have addressed all the
feedback in [3]
With the introduction of non-blocking CTBs more than one CTB can be in
flight at a time. Increasing the size of the CTBs should reduce how
often software hits the case where no space is available in the CTB
buffer.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely
In upcoming patch we will allow more CTB requests to be sent in
parallel to the GuC for processing, so we shouldn't assume any more
that GuC will always reply without 10ms.
Use bigger value hardcoded value of 1s instead.
v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option
v3:
(Daniel Vetter)
Add non blocking CTB send function, intel_guc_send_nb. GuC submission
will send CTBs in the critical path and does not need to wait for these
CTBs to complete before moving on, hence the need for this new function.
The non-blocking CTB now must have a flow control mechanism to ensure
the buffer
Implement a stall timer which fails H2G CTBs once a period of time
with no forward progress is reached to prevent deadlock.
v2:
(Michal)
- Improve error message in ct_deadlock()
- Set broken when ct_deadlock() returns true
- Return -EPIPE on ct_deadlock()
v3:
(Michal)
- Add ms to stall
Improve the error message when a unsolicited CT response is received by
printing fence that couldn't be found, the last fence, and all requests
with a response outstanding.
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 +++---
From: John Harrison
Add several module failure load inject points in the CT buffer creation
code path.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8
1 file changed, 8 insertions(+)
diff
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
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.
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
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 ++--
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
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
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
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 +++
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 |
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
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
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
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
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
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
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
1 - 100 of 146 matches
Mail list logo
