From: Patchwork
Sent: Wednesday, July 7, 2021 4:26 PM
To: Shankar, Uma
Cc: intel-gfx@lists.freedesktop.org
Subject: ✗ Fi.CI.BAT: failure for drm/i915/display/xelpd: Fix incorrect color
capability reporting
Patch Details
Series:
drm/i915/display/xelpd: Fix incorrect color capability reporting
46 bit addressing enables you to use 4 bits to support some
MKTME features, and 3 more bits for Optane support that uses
a subset of MTKME for persistent memory.
But GTT addressing sticking to 39 bit addressing, thus setting
dma_mask_size to 39 fixes below tests :
igt@i915_selftest@live@mman
igt@
On Thu, Mar 25, 2021 at 05:39:47PM +0530, Anshuman Gupta wrote:
> dispcnlunit1_cp_xosc_clkreq clock observed to be active on TGL-H platform
> despite Wa_14010685332 original sequence, thus blocks entry to deeper s0ix
> state.
>
> The Tweaked Wa_14010685332 sequence fixes this issue, therefore use
On Wed, 07 Jul 2021, Matt Roper wrote:
> PCI revision IDs don't always map to GT and display IP steppings in an
> intuitive/sensible way. On many of our recent platforms we've switched
> to using revid->stepping lookup tables with the infrastructure in
> intel_step.c to handle stepping lookups an
== Series Details ==
Series: series starting with [1/2] drm/i915: do not abbreviate version in
debugfs
URL : https://patchwork.freedesktop.org/series/92296/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10310_full -> Patchwork_20550_full
==
== Series Details ==
Series: drm/i915/adl_s: Fix dma_mask_size to 39 bit (rev3)
URL : https://patchwork.freedesktop.org/series/92262/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10311 -> Patchwork_20553
Summary
---
This is well after this has been merged, but only spotted this now.
In the future, please add something sensible to the subject lines
instead of just the platform and workaround number. I'm looking at a
shortlog with:
drm/i915/display/adl_p: Implement Wa_22012278275
drm/i915/display/
This is well after this has been merged, but only spotted this now.
In the future, please add something sensible to the subject lines
instead of just the platform and workaround number. I'm looking at a
shortlog with:
drm/i915/display/adl_p: Implement Wa_22012278275
drm/i915/display/
Adding Tomi as well.
Hi Tomi,
Can you please help report this failure, its unrelated to the change.
We want to merge this to unblock CI and remove unwanted aborts.
Thank & Regards,
Uma Shankar
From: Patchwork
mailto:patchw...@emeril.freedesktop.org>>
Sent: Wednesday, July 7, 2021 4:26 PM
To: Sh
On Thu, 8 Jul 2021 at 08:21, Tejas Upadhyay
wrote:
>
> 46 bit addressing enables you to use 4 bits to support some
> MKTME features, and 3 more bits for Optane support that uses
> a subset of MTKME for persistent memory.
>
> But GTT addressing sticking to 39 bit addressing, thus setting
> dma_mas
Hi Dave & Daniel -
I'll be out for a bit, so I'm sending the first batch of changes for
v5.15 early. Nothing unusual here, I just don't want to have a huge pile
waiting. :)
Rodrigo will cover me.
BR,
Jani.
drm-intel-next-2021-07-08:
drm/i915 changes for v5.15:
Features:
- Enable pipe DMC lo
This series add debugfs entry to force dsc bpp to
ceratin valid test value, for validation needs.
This series has been tested locally.
With the introduction of i915_dsc_bpp debugfs
the expectation is that whenever there is force_dsc_en
set, force_dsc_bpp should have a valid value for that
format wh
Though there is a write option available on fec_suport
debugfs file, so far it has been registering with read
permissions only.
Suggested-by: Jani Nikula
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
From: Patnana Venkata Sai
[What]:
This patch creates a per connector debugfs node to expose
the Input and Compressed BPP.
The same node can be used from userspace to force
DSC to a certain BPP(all accepted values).
[Why]:
Useful to verify all supported/requested compression bpp's
through IGT
v
Set DSC BPP to the value forced through
debugfs. It can go from bpc to bpp-1.
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_dp.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display
== Series Details ==
Series: Minor revid/stepping and workaround cleanup
URL : https://patchwork.freedesktop.org/series/92299/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10311_full -> Patchwork_20552_full
Summary
---
On Wed, 07 Jul 2021, Matt Roper wrote:
> The 'has_cdclk_crawl' field in our device info structure is a boolean
> flag and doesn't need a whole u8. Add it as another 1-bit feature flag
> and move it to the display section. While we're at it, replace the
> has_cdclk_crawl() function with a macro f
> -Original Message-
> From: Kulkarni, Vandita
> Sent: Thursday, July 8, 2021 3:56 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Kulkarni, Vandita
>
> Subject: [v7 0/3] Set BPP in the kernel
>
> This series adds debugfs entry to force dsc bpp to ceratin valid test value,
== Series Details ==
Series: drm/i915/adl_s: Fix dma_mask_size to 39 bit (rev3)
URL : https://patchwork.freedesktop.org/series/92262/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10311_full -> Patchwork_20553_full
Summary
If the regions query fails then the error will be encoded in the
item.length, while the ioctl will still return success.
Reported-by: Ville Syrjala
Signed-off-by: Matthew Auld
---
lib/i915/intel_memory_region.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/lib/i915/intel_memory_reg
We should be able to re-use this for other queries.
Signed-off-by: Matthew Auld
Cc: Ville Syrjala
---
tests/i915/i915_query.c | 46 -
1 file changed, 27 insertions(+), 19 deletions(-)
diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index 2
Ensure if we feed garbage into DRM_I915_QUERY_MEMORY_REGIONS it does
indeed fail as expected. Also add some asserts for the invariants with
the probed regions, for example we should always have at least system
memory.
Signed-off-by: Matthew Auld
Cc: Ville Syrjala
---
tests/i915/i915_query.c | 1
On Thu, 08 Jul 2021, Vandita Kulkarni wrote:
> Though there is a write option available on fec_suport
> debugfs file, so far it has been registering with read
> permissions only.
>
> Suggested-by: Jani Nikula
> Signed-off-by: Vandita Kulkarni
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/dr
On Thu, 08 Jul 2021, Vandita Kulkarni wrote:
> Set DSC BPP to the value forced through
> debugfs. It can go from bpc to bpp-1.
>
> Signed-off-by: Vandita Kulkarni
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 17 +
> 1 file changed, 17 insertions(+)
>
> diff --git a/drivers/g
On Thu, 08 Jul 2021, Vandita Kulkarni wrote:
> From: Patnana Venkata Sai
>
> [What]:
> This patch creates a per connector debugfs node to expose
> the Input and Compressed BPP.
>
> The same node can be used from userspace to force
> DSC to a certain BPP(all accepted values).
>
> [Why]:
> Useful t
On Thu, 08 Jul 2021, Jani Nikula wrote:
> On Thu, 08 Jul 2021, Vandita Kulkarni wrote:
>> Set DSC BPP to the value forced through
>> debugfs. It can go from bpc to bpp-1.
>>
>> Signed-off-by: Vandita Kulkarni
>> ---
>> drivers/gpu/drm/i915/display/intel_dp.c | 17 +
>> 1 file ch
On Thu, 08 Jul 2021, Jani Nikula wrote:
> On Thu, 08 Jul 2021, Vandita Kulkarni wrote:
>> From: Patnana Venkata Sai
>>
>> [What]:
>> This patch creates a per connector debugfs node to expose
>> the Input and Compressed BPP.
>>
>> The same node can be used from userspace to force
>> DSC to a cert
On 08.07.2021 01:25, Matthew Brost wrote:
> 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/
> -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
>
> On Thu, 08 Jul 2021, Jani Nikula wrote:
> > On Thu, 08 J
Set DSC BPP to the value forced through
debugfs. It can go from bpc to bpp-1.
v2: Use default dsc bpp when we are just
doing force_dsc_en, use default dsc bpp
for invalid force_dsc_bpp values. (Jani)
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/intel_dp.c | 17 ++
> -Original Message-
> From: Intel-gfx On Behalf Of
> Kulkarni, Vandita
> Sent: Thursday, July 8, 2021 3:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: Re: [Intel-gfx] [v7 0/3] Set BPP in the kernel
>
> > -Original Message-
> > From: Kulkarni, Vandit
== 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 -> Patchwork_20542
Summ
Re-reported.
From: Shankar, Uma
Sent: Thursday, July 8, 2021 2:15 AM
To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana
; Sarvela, Tomi P
Subject: RE: ✗ Fi.CI.BAT: failure for drm/i915/display/xelpd: Fix incorrect
color capability reporting
Adding Tomi as well.
Hi Tomi,
Can you plea
On Thu, Jul 08, 2021 at 06:47:06AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: Handle cdclk crawling flag in standard manner
> URL : https://patchwork.freedesktop.org/series/92294/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_10310_full -> P
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 A
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.
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 --git
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
bitstream
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 Bei
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
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 he
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 data
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
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 a/drivers/gpu
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 rea
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 orig
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 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 +++
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 a/drivers/g
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 other.
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 |
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 doi
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 +++
.../gpu/drm
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 ++--
drivers/g
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 f6e8aa38717
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 setting
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 removin
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 other.
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 ++--
.../gpu/drm/i9
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 t
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.
S
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
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 --g
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 +++---
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 is
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 t
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 necessary
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)
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
---
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] a
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
>>
>>
> -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 Message-
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:
>
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
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
helpe
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 commen
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 ha
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
extensive
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)
Signed-
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, no
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 he
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: Su
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: Melissa
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 under
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: Ru
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: linaro-mm-...@lists.linar
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 als
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
--
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 t
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: freedr...@l
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 th
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 th
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: "T
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 mor
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
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 Gear_typ
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 never-u
1 - 100 of 144 matches
Mail list logo
