== Series Details ==
Series: drm/i915/dg2: Memory latency values from pcode must be doubled
URL : https://patchwork.freedesktop.org/series/93882/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10505_full -> Patchwork_20862_full
On 8/18/2021 11:16 PM, Matthew Brost wrote:
Move guc_blocked fence to struct guc_state as the lock which protects
the fence lives there.
s/ce->guc_blocked/ce->guc_state.blocked_fence/g
Could also call it just ce->guc_state.blocked, blocked_fence sounds to
me like the fence itself is
On 8/18/2021 11:16 PM, Matthew Brost wrote:
It isn't safe to scrub for missing G2H or continue with the reset until
all G2H processing is complete. Flush the G2H work queue during reset to
ensure it is done running.
Might be worth moving this patch closer to "drm/i915/guc: Process all
G2H
== Series Details ==
Series: drm/i915/dg2: Memory latency values from pcode must be doubled
URL : https://patchwork.freedesktop.org/series/93882/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10505 -> Patchwork_20862
On 8/18/2021 11:16 PM, Matthew Brost wrote:
Reset LRC descriptor if a context register returns -ENODEV as this means
we are mid-reset.
Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC interface")
Signed-off-by: Matthew Brost
Reviewed-by: Daniele Ceraolo Spurio
On 8/18/2021 11:16 PM, Matthew Brost wrote:
A context can get destroyed after cancelling a request so take a
reference to context when cancelling a request.
What's the exact race? AFAICS __i915_request_skip does not have a
context_put().
Daniele
Fixes: 62eaf0ae217d ("drm/i915/guc:
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev3)
URL : https://patchwork.freedesktop.org/series/92789/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10505 -> Patchwork_20861
Summary
---
== Series Details ==
Series: Parallel submission aka multi-bb execbuf (rev3)
URL : https://patchwork.freedesktop.org/series/92789/
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: Parallel submission aka multi-bb execbuf (rev3)
URL : https://patchwork.freedesktop.org/series/92789/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
77206ddfd7e8 drm/i915/guc: Squash Clean up GuC CI failures, simplify locking,
and kernel DOC
On Sat, Aug 21, 2021 at 01:20:04AM +0300, Ville Syrjälä wrote:
> On Wed, Aug 18, 2021 at 07:17:12PM +0300, Imre Deak wrote:
> > On Wed, Aug 18, 2021 at 06:09:43PM +0300, Lee, Shawn C wrote:
> > > On Tue, 2021-07-07, Lee Shawn C wrote:
> > > >On Tue, 2021-07-07, Almahallawy, Khaled
> > > >wrote:
The memory latency values returned by pcode on DG2 are in units of "2
usec" rather than 1 usec on all other platforms. I.e., we need to
double the value returned by pcode to obtain the true latency value.
The bspec wording here was a bit ambiguous as to whether it wanted us to
multiply or divide
For some users of multi-lrc, e.g. split frame, it isn't safe to preempt
mid BB. To safely enable preemption at the BB boundary, a handshake
between to parent and child is needed. This is implemented via custom
emit_bb_start & emit_fini_breadcrumb functions and enabled via by
default if a context
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly.
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create
parameters (v5)")
Signed-off-by: Matthew Brost
Cc:
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
Introduce 'set parallel submit' extension to connect UAPI to GuC
multi-lrc interface. Kernel doc in new uAPI should explain it all.
IGT: https://patchwork.freedesktop.org/patch/447008/?series=93071=1
media UMD: link to come
v2:
(Daniel Vetter)
- Add IGT link and placeholder for media UMD link
Allow multiple batch buffers to be submitted in a single execbuf IOCTL
after a context has been configured with the 'set_parallel' extension.
The number batches is implicit based on the contexts configuration.
This is implemented with a series of loops. First a loop is used to find
all the
Calling switch_to_kernel_context isn't needed if the engine PM reference
is taken while all contexts are pinned. By not calling
switch_to_kernel_context we save on issuing a request to the engine.
v2:
(Daniel Vetter)
- Add FIXME comment about pushing switch_to_kernel_context to backend
Assign contexts in parent-child relationship consecutive guc_ids. This
is accomplished by partitioning guc_id space between ones that need to
be consecutive (1/16 available guc_ids) and ones that do not (15/16 of
available guc_ids). The consecutive search is implemented via the bitmap
API.
This
Update parallel submit doc to point to i915_drm.h
Signed-off-by: Matthew Brost
---
Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 --
Documentation/gpu/rfc/i915_scheduler.rst | 4 +-
2 files changed, 2 insertions(+), 124 deletions(-)
delete mode 100644
Enable multi-bb execbuf by enabling the set_parallel extension.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index
The GuC must receive requests in the order submitted for contexts in a
parent-child relationship to function correctly. To ensure this, insert
a submit fence between the current request and last request submitted
for requests / contexts in a parent child relationship. This is
conceptually similar
Display the workqueue status in debugfs for GuC contexts that are in
parent-child relationship.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 51 ++-
1 file changed, 37 insertions(+), 14 deletions(-)
diff --git
In GuC parent-child contexts the parent context controls the scheduling,
ensure only the parent does the scheduling operations.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 24 ++-
1 file changed, 18 insertions(+), 6 deletions(-)
diff --git
Add very basic (single submission) multi-lrc selftest.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
.../drm/i915/gt/uc/selftest_guc_multi_lrc.c | 180 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
3 files changed, 182
If an error occurs in the front end when multi-lrc requests are getting
generated we need to skip these in the backend but we still need to
emit the breadcrumbs seqno. An issues arrises because with multi-lrc
breadcrumbs there is a handshake between the parent and children to make
forwad progress.
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Basically doing as little as possible to support this
interface for execlists - basically just passing submit fences between
each request generated and virtual engines are not allowed. This is on
par with what is
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of all the contexts in the multi-lrc submission, and updates
these values simultaneously. As such, the tasklet and bypass path have
been updated to
Update context and full GPU reset to work with multi-lrc. The idea is
parent context tracks all the active requests inflight for itself and
its' children. The parent context owns the reset replaying / canceling
requests as needed.
Signed-off-by: Matthew Brost
---
Introduce context parent-child relationship. Once this relationship is
created all pinning / unpinning operations are directed to the parent
context. The parent context is responsible for pinning all of its'
children and itself.
This is a precursor to the full GuC multi-lrc implementation but
Parallel contexts are perma-pinned by the upper layers which makes the
backend implementation rather simple. The parent pins the guc_id and
children increment the parent's pin count on pin to ensure all the
contexts are unpinned before we disable scheduling with the GuC / or
deregister the
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a scheduling of user context could be enabled.
v2:
(Daniel Vetter)
- Add might_lock annotations to pin / unpin function
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 3 ++
As discussed in [1] we are introducing a new parallel submission uAPI
for the i915 which allows more than 1 BB to be submitted in an execbuf
IOCTL. This is the implemenation for both GuC and execlists.
In addition to selftests in the series, an IGT is available implemented
in the first 4 patches
Sometimes it is desirable to queue work up for later if the GT PM isn't
held and run that work on next GT PM unpark.
Implemented with a list in the GT of all pending work, workqueues in
the list, a callback to add a workqueue to the list, and finally a
wakeref post_get callback that iterates /
Add multi-lrc context registration H2G. In addition a workqueue and
process descriptor are setup during multi-lrc context registration as
these data structures are needed for multi-lrc submission.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 12 ++
For testing purposes it may make sense to reduce the number of guc_ids
available to be allocated. Add debugfs support for setting the number of
guc_ids.
Signed-off-by: Matthew Brost
---
.../gpu/drm/i915/gt/uc/intel_guc_debugfs.c| 31 +++
Add logical engine mapping. This is required for split-frame, as
workloads need to be placed on engines in a logically contiguous manner.
v2:
(Daniel Vetter)
- Add kernel doc for new fields
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 60
Taking a PM reference to prevent intel_gt_wait_for_idle from short
circuiting while a deregister context H2G is in flight.
FIXME: Move locking / structure changes into different patch
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
Expose logical engine instance to user via query engine info IOCTL. This
is required for split-frame workloads as these needs to be placed on
engines in a logically contiguous order. The logical mapping can change
based on fusing. Rather than having user have knowledge of the fusing we
simply just
Number of available GuC contexts ids might be limited.
Stop referring in code to macro and use variable instead.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 15
https://patchwork.freedesktop.org/series/93704/
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context.c | 19 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 81 +-
.../drm/i915/gt/intel_execlists_submission.c | 4 -
drivers/gpu/drm/i915/gt/selftest_hangcheck.c |
On Wed, Aug 18, 2021 at 07:17:12PM +0300, Imre Deak wrote:
> On Wed, Aug 18, 2021 at 06:09:43PM +0300, Lee, Shawn C wrote:
> > On Tue, 2021-07-07, Lee Shawn C wrote:
> > >On Tue, 2021-07-07, Almahallawy, Khaled
> > >wrote:
> > >>I believe Imre's LT fallback:
> >
On Thu, Jul 29, 2021 at 12:39:10PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky
>
> Changelog:
> v3:
> * Rewrote to new API suggestion
> * Split for more patches
> v2: https://lore.kernel.org/lkml/cover.1626605893.git.leo...@nvidia.com
> * Changed implementation of first patch, based
On Thu, Aug 19, 2021 at 09:07:26PM +0300, Ville Syrjälä wrote:
> > ef79d62b5ce5 ("drm/i915: Encapsulate dbuf state handling harder")
> >
> > With that commit the display is not detected anymore, one commit
> > before that it still works. So this one seems to be broken.
> >
> > Ville, Stanislav,
On Fri, Aug 20, 2021 at 12:54:25PM -0300, Jason Gunthorpe wrote:
> On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
>
> > +/**
> > + * __sg_free_table - Free a previously mapped sg table
> > + * @table: The sg table header to use
> > + * @max_ents: The maximum number of
On Fri, Aug 20, 2021 at 04:17:24PM +0200, Christoph Hellwig wrote:
> On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote:
> > I'm working on below patch to resolve this. But I met a weird issue in
> > case when building i915 as module and also kvmgt module, it caused
> > busy wait on
On Thu, Jul 29, 2021 at 12:39:12PM +0300, Leon Romanovsky wrote:
> +/**
> + * __sg_free_table - Free a previously mapped sg table
> + * @table: The sg table header to use
> + * @max_ents:The maximum number of entries per single scatterlist
> + * @total_ents: The total number of
On Thu, Aug 19, 2021 at 1:22 AM Matthew Brost wrote:
>
> Propagating errors to dependent fences is wrong, don't do it. A selftest
> in the following exposed the propagating of an error to a dependent
> fence after an engine reset.
I feel like we could still have a bit of a better message. Maybe
On Fri, Aug 20, 2021 at 11:42:38AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > When unblocking a context, do not enable scheduling if the context is
> > banned, guc_id invalid, or not registered.
> >
> > Fixes: 62eaf0ae217d ("drm/i915/guc: Support
On 8/18/2021 11:16 PM, Matthew Brost wrote:
When unblocking a context, do not enable scheduling if the context is
banned, guc_id invalid, or not registered.
Fixes: 62eaf0ae217d ("drm/i915/guc: Support request cancellation")
Signed-off-by: Matthew Brost
Cc:
---
On Fri, Aug 20, 2021 at 11:31:56AM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/18/2021 11:16 PM, Matthew Brost wrote:
> > Kick tasklet after queuing a request so it submitted in a timely manner.
> >
> > Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for
> > new
On 8/18/2021 11:16 PM, Matthew Brost wrote:
Kick tasklet after queuing a request so it submitted in a timely manner.
Fixes: 3a4cdf1982f0 ("drm/i915/guc: Implement GuC context operations for new
inteface")
Is this actually a bug or just a performance issue? in the latter case I
don't
On Fri, Aug 20, 2021 at 7:00 PM Rodrigo Vivi wrote:
>
> On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote:
> > In
> >
> > commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
> > Author: Daniel Vetter
> > Date: Tue Aug 3 14:48:33 2021 +0200
> >
> > drm/i915: delete gpu reloc code
>
Hello drm-misc and drm-intel maintainers,
My "Add support for out-of-band hotplug notification" patchset:
https://patchwork.freedesktop.org/series/93763/
Is ready for merging now, as discussed on IRC I based this series
on top drm-tip and when trying to apply the i915 parts on top
of drm-misc
On Fri, Aug 20, 2021 at 03:52:59PM +0800, Kai-Heng Feng wrote:
> 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
On Fri, Aug 20, 2021 at 05:49:32PM +0200, Daniel Vetter wrote:
> In
>
> commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
> Author: Daniel Vetter
> Date: Tue Aug 3 14:48:33 2021 +0200
>
> drm/i915: delete gpu reloc code
it would be better with dim cite format...
do we need the Fixes: tag?
== Series Details ==
Series: drm/i915: Actually delete gpu reloc selftests
URL : https://patchwork.freedesktop.org/series/93872/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10502 -> Patchwork_20860
Summary
---
On Fri, Aug 13, 2021 at 04:01:06PM +0200, Thomas Hellström wrote:
>
> On 8/13/21 1:36 PM, Dan Carpenter wrote:
> > If the intel_engine_create_pinned_context() function returns an error
> > pointer, then dereferencing "ce" will Oops. Use "vm" instead of
> > "ce->vm".
> >
> > Fixes: cf586021642d
== Series Details ==
Series: drm/i915: Actually delete gpu reloc selftests
URL : https://patchwork.freedesktop.org/series/93872/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0b7e7b4e909d drm/i915: Actually delete gpu reloc selftests
-:11: ERROR:GIT_COMMIT_ID: Please use git
In
commit 8e02cceb1f1f4f254625e5338dd997ff61ab40d7
Author: Daniel Vetter
Date: Tue Aug 3 14:48:33 2021 +0200
drm/i915: delete gpu reloc code
I deleted the gpu relocation code and the selftest include and
enabling, but accidentally forgot about the selftest source code.
Fix this
On Thu, Aug 19, 2021 at 04:29:29PM +0800, Zhenyu Wang wrote:
> I'm working on below patch to resolve this. But I met a weird issue in
> case when building i915 as module and also kvmgt module, it caused
> busy wait on request_module("kvmgt") when boot, it doesn't happen if
> building i915 into
== Series Details ==
Series: drm/i915/dp: Use max params for panels < eDP 1.4 (rev2)
URL : https://patchwork.freedesktop.org/series/93794/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10502_full -> Patchwork_20858_full
== Series Details ==
Series: drm: update locking for modesetting
URL : https://patchwork.freedesktop.org/series/93864/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10502 -> Patchwork_20859
Summary
---
**FAILURE**
== Series Details ==
Series: drm: update locking for modesetting
URL : https://patchwork.freedesktop.org/series/93864/
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/dp: Use max params for panels < eDP 1.4 (rev2)
URL : https://patchwork.freedesktop.org/series/93794/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10502 -> Patchwork_20858
Summary
== Series Details ==
Series: drm/i915/dp: Use max params for panels < eDP 1.4 (rev2)
URL : https://patchwork.freedesktop.org/series/93794/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
eb2cf44956b2 drm/i915/dp: Use max params for panels < eDP 1.4
-:9: ERROR:GIT_COMMIT_ID:
Previously, master_lookup_lock was introduced in
commit 0b0860a3cf5e ("drm: serialize drm_file.master with a new
spinlock") to serialize accesses to drm_file.master. This then allowed
us to write drm_file_get_master in commit 56f0729a510f ("drm: protect
drm_master pointers in drm_lease.c").
The
In drm_client_modeset.c and drm_fb_helper.c,
drm_master_internal_{acquire,release} are used to avoid races with DRM
userspace. These functions hold onto drm_device.master_rwsem while
committing, and bail if there's already a master.
However, there are other places where modesetting rights can
In a future patch, a read lock on drm_device.master_rwsem is
held in the ioctl handler before the check for ioctl
permissions. However, this inverts the lock hierarchy of
drm_global_mutex --> master_rwsem.
To avoid this, we do some prep work to grab the drm_global_mutex
before checking for ioctl
drm_device.master_mutex currently protects the following:
- drm_device.master
- drm_file.master
- drm_file.was_master
- drm_file.is_master
- drm_master.unique
- drm_master.unique_len
- drm_master.magic_map
There is a clear separation between functions that read or change
these attributes. Hence,
drm_master_release can be called on a drm_file without a master, which
results in a null ptr dereference of file_priv->master->magic_map. The
three cases are:
1. Error path in drm_open_helper
drm_open():
drm_open_helper():
drm_master_open():
drm_new_set_master(); <--- returns
Hi,
Thanks for all the helpful feedback on the previous version.
Taking all the suggestions together, this series now converts
drm_device.master_mutex into master_rwsem, and also attempts to remove
drm_file.master_lookup_lock. There might still be lock inversions
lurking, so the output from
Op 19-08-2021 om 23:03 schreef Lucas De Marchi:
> This was added in commit 05e265841f7e ("drm/i915/dg1: add initial DG-1
> definitions") so we could continue to add support for DG1 without
> risk to expose a broken UAPI. Now that we added DG1 to the PCI ID list
> i915 may bind to, remove the
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,
On Thu, 19 Aug 2021, Ville Syrjälä wrote:
> On Wed, Aug 18, 2021 at 01:11:09PM +0300, Jani Nikula wrote:
>> There's no performance reason to have it as static inline; move it out
>> of intel_display_types.h to reduce clutter and dependency on i915_drv.h.
>>
>> Signed-off-by: Jani Nikula
>> ---
On Thu, 19 Aug 2021, Ville Syrjälä wrote:
> On Wed, Aug 18, 2021 at 09:10:48PM +0300, Jani Nikula wrote:
>> UHBR rates and 128b/132b channel encoding go hand in hand.
>>
>> Reviewed-by: Manasi Navare
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_dp_link_training.c
74 matches
Mail list logo
