[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [RFC,1/2] drm/i915/dmc: Add soc stepping to intel_step
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915/dmc: Add soc stepping to
intel_step
URL : https://patchwork.freedesktop.org/series/92039/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10290_full -> Patchwork_20490_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20490_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-async-flip}:
- shard-skl: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-skl1/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-0-async-flip.html
Known issues
Here are the changes found in Patchwork_20490_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@blit-noreloc-purge-cache-random:
- shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271]) +168 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-snb6/igt@api_intel...@blit-noreloc-purge-cache-random.html
* igt@feature_discovery@psr2:
- shard-iclb: [PASS][3] -> [SKIP][4] ([i915#658])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10290/shard-iclb2/igt@feature_discov...@psr2.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-iclb4/igt@feature_discov...@psr2.html
* igt@gem_ctx_persistence@legacy-engines-mixed:
- shard-snb: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#1099]) +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-mixed.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#2846])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10290/shard-glk4/igt@gem_exec_f...@basic-deadline.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-glk6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-kbl: [PASS][8] -> [FAIL][9] ([i915#2842]) +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10290/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-kbl2/igt@gem_exec_fair@basic-none-s...@rcs0.html
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10290/shard-glk5/igt@gem_exec_fair@basic-none-s...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-glk3/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- shard-apl: [PASS][12] -> [FAIL][13] ([i915#2842])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10290/shard-apl8/igt@gem_exec_fair@basic-n...@vcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-apl8/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-iclb: [PASS][14] -> [FAIL][15] ([i915#2842]) +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10290/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-iclb7/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-iclb: [PASS][16] -> [FAIL][17] ([i915#2849])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10290/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-iclb3/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_exec_reloc@basic-wide-active@rcs0:
- shard-snb: NOTRUN -> [FAIL][18] ([i915#3633]) +2 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-snb2/igt@gem_exec_reloc@basic-wide-act...@rcs0.html
* igt@gem_mmap_gtt@cpuset-big-copy-odd:
- shard-iclb: [PASS][19] -> [FAIL][20] ([i915#307])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10290/shard-iclb8/igt@gem_mmap_...@cpuset-big-copy-odd.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy-odd.html
* igt@gem_render_copy@y-tiled-mc-ccs-to-y-tiled-ccs:
- shard-iclb: NOTRUN -> [SKIP][21] ([i915#768])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/shard-iclb1/igt@gem_render_c...@y-tiled-mc-ccs-to-y-tiled-ccs.html
* igt@gem_userptr_blits@input-checking:
- shard-apl: NOTRUN -> [DMESG-WARN][22] ([i915#3002])
[22]:
Re: [Intel-gfx] [PATCH V2] drm/i915/ehl: Update MOCS table for EHL
On Mon, Jun 21, 2021 at 06:26:22PM +0530, Tejas Upadhyay wrote:
From: Matt Roper
These extra EHL entries were not behaving as expected without proper
flushing implemented in kernel.
Commit a679f58d0510 ("drm/i915: Flush pages on acquisition")
introduces proper flushing to make it work as expected.
Hence adding those EHL entries back.
Changes since V1:
- commit message modified with Commit - Joonas
Cc: Francisco Jerez
Cc: Jon Bloomfield
Cc: Lucas De Marchi
Cc:
Signed-off-by: Matt Roper
Fixes: 046091758b50 ("Revert "drm/i915/ehl: Update MOCS table for EHL"")
This story here is weird as we reverted something going to
v5.4 due to something missing, but that something was already in the
tree since v5.1. So it seems the revert shouldn't had been done in the
first place? What am I reading wrong here?
For any gt/gem patches, we need to Cc dri-devel, done now.
Also, it seems your client is suppressing the Cc you added in the body,
so you are actually not sending anything to stable, or to the people
added there.
Link:
https://patchwork.freedesktop.org/patch/msgid/20191112224757.25116-1-matthew.d.ro...@intel.com
---
drivers/gpu/drm/i915/gt/intel_mocs.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 17848807f111..7d9ef0210805 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -194,6 +194,14 @@ static const struct drm_i915_mocs_entry
broxton_mocs_table[] = {
MOCS_ENTRY(15, \
LE_3_WB | LE_TC_1_LLC | LE_LRUM(2) | LE_AOM(1), \
L3_3_WB), \
+ /* Bypass LLC - Uncached (EHL+) */ \
+ MOCS_ENTRY(16, \
+ LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
+ L3_1_UC), \
+ /* Bypass LLC - L3 (Read-Only) (EHL+) */ \
+ MOCS_ENTRY(17, \
+ LE_1_UC | LE_TC_1_LLC | LE_SCF(1), \
+ L3_3_WB), \
For the change itself: it matches bspec 34007.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
/* Self-Snoop - L3 + LLC */ \
MOCS_ENTRY(18, \
LE_3_WB | LE_TC_1_LLC | LE_LRUM(3) | LE_SSE(3), \
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for GuC submission / DRM scheduler integration plan + new uAPI
== Series Details ==
Series: GuC submission / DRM scheduler integration plan + new uAPI
URL : https://patchwork.freedesktop.org/series/92028/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10289_full -> Patchwork_20489_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20489_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20489_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20489_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rps@waitboost:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-glk1/igt@i915_pm_...@waitboost.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-glk5/igt@i915_pm_...@waitboost.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs}:
- {shard-rkl}:[PASS][3] -> [FAIL][4] +5 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-rkl-5/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs.html
* {igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs}:
- {shard-rkl}:[SKIP][5] -> [FAIL][6] +7 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-rkl-2/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs.html
* {igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs}:
- {shard-rkl}:[FAIL][7] -> [SKIP][8] +5 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-1/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-rkl-6/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* {igt@kms_ccs@pipe-d-ccs-on-another-bo-y_tiled_gen12_mc_ccs}:
- {shard-rkl}:[SKIP][9] ([i915#533]) -> [FAIL][10] +6 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_ccs@pipe-d-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-rkl-2/igt@kms_ccs@pipe-d-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html
* igt@kms_content_protection@dp-mst-type-0:
- {shard-rkl}:[SKIP][11] ([i915#3116]) -> [SKIP][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_content_protect...@dp-mst-type-0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-rkl-1/igt@kms_content_protect...@dp-mst-type-0.html
* igt@kms_cursor_crc@pipe-a-cursor-512x170-random:
- {shard-rkl}:[SKIP][13] ([fdo#109279] / [i915#3359]) -> [SKIP][14]
+2 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_cursor_...@pipe-a-cursor-512x170-random.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-rkl-1/igt@kms_cursor_...@pipe-a-cursor-512x170-random.html
* igt@kms_cursor_crc@pipe-c-cursor-32x10-onscreen:
- {shard-rkl}:[SKIP][15] ([i915#3359]) -> [SKIP][16] +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_cursor_...@pipe-c-cursor-32x10-onscreen.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-rkl-5/igt@kms_cursor_...@pipe-c-cursor-32x10-onscreen.html
* igt@kms_cursor_crc@pipe-c-cursor-32x32-onscreen:
- {shard-rkl}:[SKIP][17] ([i915#3319]) -> [SKIP][18] +2 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_cursor_...@pipe-c-cursor-32x32-onscreen.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-rkl-2/igt@kms_cursor_...@pipe-c-cursor-32x32-onscreen.html
* igt@kms_cursor_crc@pipe-c-cursor-dpms:
- {shard-rkl}:[SKIP][19] ([fdo#112022]) -> [SKIP][20] +6 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-5/igt@kms_cursor_...@pipe-c-cursor-dpms.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/shard-rkl-1/igt@kms_cursor_...@pipe-c-cursor-dpms.html
* igt@kms_draw_crc@draw-method-xrgb-blt-xtiled:
- {shard-rkl}:[PASS][21] -> [SKIP][22] +36 similar
Re: [Intel-gfx] [PATCH 11/47] drm/i915/guc: Implement GuC submission tasklet
On Tue, Jun 29, 2021 at 03:04:56PM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Implement GuC submission tasklet for new interface. The new GuC
> > interface uses H2G to submit contexts to the GuC. Since H2G use a single
> > channel, a single tasklet submits is used for the submission path.
> Re-word? 'a single tasklet submits is used...' doesn't make sense.
>
Will do.
> > Also the per engine interrupt handler has been updated to disable the
> > rescheduling of the physical engine tasklet, when using GuC scheduling,
> > as the physical engine tasklet is no longer used.
> >
> > In this patch the field, guc_id, has been added to intel_context and is
> > not assigned. Patches later in the series will assign this value.
> >
> > Cc: John Harrison
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 +
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 231 +-
> > 3 files changed, 127 insertions(+), 117 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > index ed8c447a7346..bb6fef7eae52 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > @@ -136,6 +136,15 @@ struct intel_context {
> > struct intel_sseu sseu;
> > u8 wa_bb_page; /* if set, page num reserved for context workarounds */
> > +
> > + /* GuC scheduling state that does not require a lock. */
> Maybe 'GuC scheduling state flags that do not require a lock'? Otherwise it
> just looks like a counter or something.
>
Sure.
> > + atomic_t guc_sched_state_no_lock;
> > +
> > + /*
> > +* GuC lrc descriptor ID - Not assigned in this patch but future patches
> Not a blocker but s/lrc/LRC/ would keep Michal happy ;). Although presumably
> this comment is at least being amended by later patches in the series.
>
Will fix.
> > +* in the series will.
> > +*/
> > + u16 guc_id;
> > };
> > #endif /* __INTEL_CONTEXT_TYPES__ */
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > index 2313d9fc087b..9ba8219475b2 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> > @@ -30,6 +30,10 @@ struct intel_guc {
> > struct intel_guc_log log;
> > struct intel_guc_ct ct;
> > + /* Global engine used to submit requests to GuC */
> > + struct i915_sched_engine *sched_engine;
> > + struct i915_request *stalled_request;
> > +
> > /* intel_guc_recv interrupt related state */
> > spinlock_t irq_lock;
> > unsigned int msg_enabled_mask;
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 23a94a896a0b..ee933efbf0ff 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -60,6 +60,31 @@
> > #define GUC_REQUEST_SIZE 64 /* bytes */
> > +/*
> > + * Below is a set of functions which control the GuC scheduling state
> > which do
> > + * not require a lock as all state transitions are mutually exclusive.
> > i.e. It
> > + * is not possible for the context pinning code and submission, for the
> > same
> > + * context, to be executing simultaneously. We still need an atomic as it
> > is
> > + * possible for some of the bits to changing at the same time though.
> > + */
> > +#define SCHED_STATE_NO_LOCK_ENABLEDBIT(0)
> > +static inline bool context_enabled(struct intel_context *ce)
> > +{
> > + return (atomic_read(>guc_sched_state_no_lock) &
> > + SCHED_STATE_NO_LOCK_ENABLED);
> > +}
> > +
> > +static inline void set_context_enabled(struct intel_context *ce)
> > +{
> > + atomic_or(SCHED_STATE_NO_LOCK_ENABLED, >guc_sched_state_no_lock);
> > +}
> > +
> > +static inline void clr_context_enabled(struct intel_context *ce)
> > +{
> > + atomic_and((u32)~SCHED_STATE_NO_LOCK_ENABLED,
> > + >guc_sched_state_no_lock);
> > +}
> > +
> > static inline struct i915_priolist *to_priolist(struct rb_node *rb)
> > {
> > return rb_entry(rb, struct i915_priolist, node);
> > @@ -122,37 +147,29 @@ static inline void set_lrc_desc_registered(struct
> > intel_guc *guc, u32 id,
> > xa_store_irq(>context_lookup, id, ce, GFP_ATOMIC);
> > }
> > -static void guc_add_request(struct intel_guc *guc, struct i915_request *rq)
> > +static int guc_add_request(struct intel_guc *guc, struct i915_request *rq)
> > {
> > - /* Leaving stub as this function will be used in future patches */
> > -}
> > + int err;
> > + struct intel_context *ce = rq->context;
> > + u32 action[3];
> > + int len = 0;
> > + bool enabled = context_enabled(ce);
> > -/*
> > - * When we're doing submissions using regular execlists backend, writing to
> > -
Re: [Intel-gfx] [PATCH 08/47] drm/i915/guc: Add new GuC interface defines and structures
On Tue, Jun 29, 2021 at 02:11:00PM -0700, John Harrison wrote:
> On 6/24/2021 00:04, Matthew Brost wrote:
> > Add new GuC interface defines and structures while maintaining old ones
> > in parallel.
> >
> > Cc: John Harrison
> > Signed-off-by: Matthew Brost
> I think there was some difference of opinion over whether these additions
> should be squashed in to the specific patches that first use them. However,
> on the grounds that such is basically a patch-only style comment and doesn't
> change the final product plus, we need to get this stuff merged efficiently
> and not spend forever rebasing and refactoring...
>
Agree this doesn't need to be squashed as it doesn't break anything and
also this all dead code anyways until we enable submission at the end of
the series.
Matt
> Reviewed-by: John Harrison
>
>
> > ---
> > .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 14 +++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 41 +++
> > 2 files changed, 55 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > index 2d6198e63ebe..57e18babdf4b 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
> > @@ -124,10 +124,24 @@ enum intel_guc_action {
> > INTEL_GUC_ACTION_FORCE_LOG_BUFFER_FLUSH = 0x302,
> > INTEL_GUC_ACTION_ENTER_S_STATE = 0x501,
> > INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
> > + INTEL_GUC_ACTION_GLOBAL_SCHED_POLICY_CHANGE = 0x506,
> > + INTEL_GUC_ACTION_SCHED_CONTEXT = 0x1000,
> > + INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_SET = 0x1001,
> > + INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
> > + INTEL_GUC_ACTION_SCHED_ENGINE_MODE_SET = 0x1003,
> > + INTEL_GUC_ACTION_SCHED_ENGINE_MODE_DONE = 0x1004,
> > + INTEL_GUC_ACTION_SET_CONTEXT_PRIORITY = 0x1005,
> > + INTEL_GUC_ACTION_SET_CONTEXT_EXECUTION_QUANTUM = 0x1006,
> > + INTEL_GUC_ACTION_SET_CONTEXT_PREEMPTION_TIMEOUT = 0x1007,
> > + INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION = 0x1008,
> > + INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
> > INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
> > INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
> > + INTEL_GUC_ACTION_REGISTER_CONTEXT = 0x4502,
> > + INTEL_GUC_ACTION_DEREGISTER_CONTEXT = 0x4503,
> > INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
> > INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
> > + INTEL_GUC_ACTION_DEREGISTER_CONTEXT_DONE = 0x4600,
> > INTEL_GUC_ACTION_LIMIT
> > };
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > index 617ec601648d..28245a217a39 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> > @@ -17,6 +17,9 @@
> > #include "abi/guc_communication_ctb_abi.h"
> > #include "abi/guc_messages_abi.h"
> > +#define GUC_CONTEXT_DISABLE0
> > +#define GUC_CONTEXT_ENABLE 1
> > +
> > #define GUC_CLIENT_PRIORITY_KMD_HIGH 0
> > #define GUC_CLIENT_PRIORITY_HIGH 1
> > #define GUC_CLIENT_PRIORITY_KMD_NORMAL2
> > @@ -26,6 +29,9 @@
> > #define GUC_MAX_STAGE_DESCRIPTORS 1024
> > #define GUC_INVALID_STAGE_IDGUC_MAX_STAGE_DESCRIPTORS
> > +#define GUC_MAX_LRC_DESCRIPTORS65535
> > +#defineGUC_INVALID_LRC_ID GUC_MAX_LRC_DESCRIPTORS
> > +
> > #define GUC_RENDER_ENGINE 0
> > #define GUC_VIDEO_ENGINE 1
> > #define GUC_BLITTER_ENGINE2
> > @@ -237,6 +243,41 @@ struct guc_stage_desc {
> > u64 desc_private;
> > } __packed;
> > +#define CONTEXT_REGISTRATION_FLAG_KMD BIT(0)
> > +
> > +#define CONTEXT_POLICY_DEFAULT_EXECUTION_QUANTUM_US 100
> > +#define CONTEXT_POLICY_DEFAULT_PREEMPTION_TIME_US 50
> > +
> > +/* Preempt to idle on quantum expiry */
> > +#define CONTEXT_POLICY_FLAG_PREEMPT_TO_IDLEBIT(0)
> > +
> > +/*
> > + * GuC Context registration descriptor.
> > + * FIXME: This is only required to exist during context registration.
> > + * The current 1:1 between guc_lrc_desc and LRCs for the lifetime of the
> > LRC
> > + * is not required.
> > + */
> > +struct guc_lrc_desc {
> > + u32 hw_context_desc;
> > + u32 slpm_perf_mode_hint;/* SPLC v1 only */
> > + u32 slpm_freq_hint;
> > + u32 engine_submit_mask; /* In logical space */
> > + u8 engine_class;
> > + u8 reserved0[3];
> > + u32 priority;
> > + u32 process_desc;
> > + u32 wq_addr;
> > + u32 wq_size;
> > + u32 context_flags; /* CONTEXT_REGISTRATION_* */
> > + /* Time for one workload to execute. (in micro seconds) */
> > + u32 execution_quantum;
> > + /* Time to wait for a preemption request to complete before issuing a
> > +* reset. (in micro seconds). */
> > + u32 preemption_timeout;
> > + u32 policy_flags; /*
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [RFC,1/2] drm/i915/dmc: Add soc stepping to intel_step
== Series Details == Series: series starting with [RFC,1/2] drm/i915/dmc: Add soc stepping to intel_step URL : https://patchwork.freedesktop.org/series/92039/ State : success == Summary == CI Bug Log - changes from CI_DRM_10290 -> Patchwork_20490 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/index.html Known issues Here are the changes found in Patchwork_20490 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-glk-dsi: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/fi-glk-dsi/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][2] -> [INCOMPLETE][3] ([i915#2782]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10290/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@dp-crc-fast: - fi-bsw-nick:NOTRUN -> [SKIP][4] ([fdo#109271] / [fdo#111827]) +8 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/fi-bsw-nick/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-glk-dsi: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/fi-glk-dsi/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-glk-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#533]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/fi-glk-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_page_flip: - fi-glk-dsi: NOTRUN -> [SKIP][7] ([fdo#109271]) +28 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/fi-glk-dsi/igt@kms_psr@primary_page_flip.html * igt@prime_vgem@basic-fence-flip: - fi-bsw-nick:NOTRUN -> [SKIP][8] ([fdo#109271]) +63 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/fi-bsw-nick/igt@prime_v...@basic-fence-flip.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#533]: https://gitlab.freedesktop.org/drm/intel/issues/533 Participating hosts (40 -> 33) -- Additional (2): fi-glk-dsi fi-bsw-nick Missing(9): fi-ilk-m540 fi-tgl-dsi fi-hsw-4200u fi-tgl-1115g4 fi-bsw-cyan fi-ctg-p8600 fi-dg1-1 fi-tgl-y fi-bdw-samus Build changes - * Linux: CI_DRM_10290 -> Patchwork_20490 CI-20190529: 20190529 CI_DRM_10290: 0038051f0b6f810a94d2c54d36ad44ee2592ad7f @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6122: 5aac555494a8aaa455b46e11a2961f3bef9d4f54 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20490: 9ab5d8facd046b5c53d654728619f6b10e79f106 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 9ab5d8facd04 drm/i915/dmc: Modify stepping/substepping table 15f341baff60 drm/i915/dmc: Add soc stepping to intel_step == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20490/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/3] drm: protect drm_master pointers in drm_lease.c
Hi Desmond,
Couple of small suggestions, with those the series is:
Reviewed-by: Emil Velikov
On Tue, 29 Jun 2021 at 04:38, Desmond Cheong Zhi Xi
wrote:
> @@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
> struct drm_master *master;
> bool ret;
>
> - if (!file_priv || !file_priv->master || !file_priv->master->lessor)
> + if (!file_priv)
> return true;
>
> - master = file_priv->master;
> + master = drm_file_get_master(file_priv);
> + if (master == NULL)
> + return true;
> + if (!master->lessor) {
> + drm_master_put();
> + return true;
Let's add a "ret = true; goto unlock;" here, so we can have a single
drm_master_put() in the function.
Nearly all code paths touched by this patch already follow this approach.
> @@ -154,10 +170,16 @@ uint32_t drm_lease_filter_crtcs(struct drm_file
> *file_priv, uint32_t crtcs_in)
> int count_in, count_out;
> uint32_t crtcs_out = 0;
>
> - if (!file_priv || !file_priv->master || !file_priv->master->lessor)
> + if (!file_priv)
> return crtcs_in;
>
> - master = file_priv->master;
> + master = drm_file_get_master(file_priv);
> + if (master == NULL)
> + return crtcs_in;
> + if (!master->lessor) {
> + drm_master_put();
> + return crtcs_in;
Ditto
Thanks
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [RFC,1/2] drm/i915/dmc: Add soc stepping to intel_step
== Series Details == Series: series starting with [RFC,1/2] drm/i915/dmc: Add soc stepping to intel_step URL : https://patchwork.freedesktop.org/series/92039/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1893:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/display/intel_dmc.c:269:22: warning: symbol 'soc' was not declared. Should it be static? +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [RFC,1/2] drm/i915/dmc: Add soc stepping to intel_step
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915/dmc: Add soc stepping to
intel_step
URL : https://patchwork.freedesktop.org/series/92039/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
15f341baff60 drm/i915/dmc: Add soc stepping to intel_step
9ab5d8facd04 drm/i915/dmc: Modify stepping/substepping table
-:27: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#27: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:274:
+{
+
-:28: ERROR:SWITCH_CASE_INDENT_LEVEL: switch and case should be at the same
indent
#28: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:275:
+ switch (step.soc_step) {
+ case STEP_A0:
[...]
+ case STEP_A2:
[...]
+ case STEP_B0:
[...]
+ case STEP_B1:
[...]
+ case STEP_B2:
[...]
+ case STEP_B10:
[...]
+ case STEP_C0:
[...]
+ case STEP_D0:
[...]
+ case STEP_D1:
[...]
+ case STEP_E0:
[...]
+ case STEP_F0:
[...]
+ case STEP_G0:
[...]
+ case STEP_H0:
[...]
+ case STEP_H5:
[...]
+ case STEP_J0:
[...]
+ case STEP_J1:
[...]
+ case STEP_K0:
[...]
+ case STEP_P0:
[...]
+ case STEP_L0:
[...]
+ case STEP_Q0:
[...]
+ case STEP_R0:
[...]
+ case STEP_Y0:
[...]
+ default:
-:146: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#146: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:396:
+ return INTEL_REVID(dev_priv) < size ? si +
INTEL_REVID(dev_priv) : _stepping_info;
total: 1 errors, 1 warnings, 1 checks, 133 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC 2/2] drm/i915/dmc: Modify stepping/substepping table
Grab the stepping info from RUNTIME_INFO(dev_priv)->step
on the dmc side to grab the right blob.
Adding the helper intel_get_soc_info() that has SOC stepping
lookup table.
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 113 ++-
1 file changed, 109 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index f8789d4543bf..1b2e01adac48 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -266,14 +266,119 @@ static const struct stepping_info icl_stepping_info[] = {
};
static const struct stepping_info no_stepping_info = { '*', '*' };
+struct stepping_info *soc;
+
+static struct stepping_info *
+intel_get_soc_stepping(struct intel_step_info step)
+{
+
+ switch (step.soc_step) {
+ case STEP_A0:
+ soc->stepping = 'A';
+ soc->substepping = '0';
+ break;
+ case STEP_A2:
+ soc->stepping = 'A';
+ soc->substepping = '2';
+ break;
+ case STEP_B0:
+ soc->stepping = 'B';
+ soc->substepping = '0';
+ break;
+ case STEP_B1:
+ soc->stepping = 'B';
+ soc->substepping = '1';
+ break;
+ case STEP_B2:
+ soc->stepping = 'B';
+ soc->substepping = '2';
+ break;
+ case STEP_B10:
+ soc->stepping = 'B';
+ soc->substepping = 'A';
+ break;
+ case STEP_C0:
+ soc->stepping = 'C';
+ soc->substepping = '0';
+ break;
+ case STEP_D0:
+ soc->stepping = 'D';
+ soc->substepping = '0';
+ break;
+ case STEP_D1:
+ soc->stepping = 'D';
+ soc->substepping = '1';
+ break;
+ case STEP_E0:
+ soc->stepping = 'E';
+ soc->substepping = '0';
+ break;
+ case STEP_F0:
+ soc->stepping = 'F';
+ soc->substepping = '0';
+ break;
+ case STEP_G0:
+ soc->stepping = 'G';
+ soc->substepping = '0';
+ break;
+ case STEP_H0:
+ soc->stepping = 'H';
+ soc->substepping = '0';
+ break;
+ case STEP_H5:
+ soc->stepping = 'H';
+ soc->substepping = '5';
+ break;
+ case STEP_J0:
+ soc->stepping = 'J';
+ soc->substepping = '0';
+ break;
+ case STEP_J1:
+ soc->stepping = 'J';
+ soc->substepping = '1';
+ break;
+ case STEP_K0:
+ soc->stepping = 'K';
+ soc->substepping = '0';
+ break;
+ case STEP_P0:
+ soc->stepping = 'L';
+ soc->substepping = '0';
+ break;
+ case STEP_L0:
+ soc->stepping = 'P';
+ soc->substepping = '0';
+ break;
+ case STEP_Q0:
+ soc->stepping = 'Q';
+ soc->substepping = '0';
+ break;
+ case STEP_R0:
+ soc->stepping = 'R';
+ soc->substepping = '0';
+ break;
+ case STEP_Y0:
+ soc->stepping = 'Y';
+ soc->substepping = '0';
+ break;
+ default:
+ soc->stepping = '*';
+ soc->substepping = '*';
+ break;
+ }
+ return soc;
+}
static const struct stepping_info *
intel_get_stepping_info(struct drm_i915_private *dev_priv)
{
const struct stepping_info *si;
+ struct intel_step_info step = RUNTIME_INFO(dev_priv)->step;
unsigned int size;
- if (IS_ICELAKE(dev_priv)) {
+ if (DISPLAY_VER(dev_priv) >= 12) {
+ si = intel_get_soc_stepping(step);
+ } else if (IS_ICELAKE(dev_priv)) {
size = ARRAY_SIZE(icl_stepping_info);
si = icl_stepping_info;
} else if
[Intel-gfx] [RFC 1/2] drm/i915/dmc: Add soc stepping to intel_step
DMC firmware looks for SOC stepping to load specific firmware.
While we maintained a separate lookup table, lets consolidate
SOC steppings with gt and display steppings.
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/intel_step.c | 46 +++
drivers/gpu/drm/i915/intel_step.h | 13 +
2 files changed, 36 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_step.c
b/drivers/gpu/drm/i915/intel_step.c
index ba9479a67521..bc139c7e3e37 100644
--- a/drivers/gpu/drm/i915/intel_step.c
+++ b/drivers/gpu/drm/i915/intel_step.c
@@ -16,42 +16,42 @@
/* FIXME: what about REVID_E0 */
static const struct intel_step_info kbl_revids[] = {
- [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
- [1] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
- [2] = { .gt_step = STEP_C0, .display_step = STEP_B0 },
- [3] = { .gt_step = STEP_D0, .display_step = STEP_B0 },
- [4] = { .gt_step = STEP_F0, .display_step = STEP_C0 },
- [5] = { .gt_step = STEP_C0, .display_step = STEP_B1 },
- [6] = { .gt_step = STEP_D1, .display_step = STEP_B1 },
- [7] = { .gt_step = STEP_G0, .display_step = STEP_C0 },
+ [0] = { .gt_step = STEP_A0, .display_step = STEP_A0, .soc_step =
STEP_G0 },
+ [1] = { .gt_step = STEP_B0, .display_step = STEP_B0, .soc_step =
STEP_A0 },
+ [2] = { .gt_step = STEP_C0, .display_step = STEP_B0, .soc_step =
STEP_H0 },
+ [3] = { .gt_step = STEP_D0, .display_step = STEP_B0, .soc_step =
STEP_J0 },
+ [4] = { .gt_step = STEP_F0, .display_step = STEP_C0, .soc_step =
STEP_B0 },
+ [5] = { .gt_step = STEP_C0, .display_step = STEP_B1, .soc_step =
STEP_H5 },
+ [6] = { .gt_step = STEP_D1, .display_step = STEP_B1, .soc_step =
STEP_J1 },
+ [7] = { .gt_step = STEP_G0, .display_step = STEP_C0, .soc_step =
STEP_Y0 },
};
static const struct intel_step_info tgl_uy_revid_step_tbl[] = {
- [0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
- [1] = { .gt_step = STEP_B0, .display_step = STEP_C0 },
- [2] = { .gt_step = STEP_B1, .display_step = STEP_C0 },
- [3] = { .gt_step = STEP_C0, .display_step = STEP_D0 },
+ [0] = { .gt_step = STEP_A0, .display_step = STEP_A0, .soc_step =
STEP_A0 },
+ [1] = { .gt_step = STEP_B0, .display_step = STEP_C0, .soc_step =
STEP_B2 },
+ [2] = { .gt_step = STEP_B1, .display_step = STEP_C0, .soc_step =
STEP_B10 },
+ [3] = { .gt_step = STEP_C0, .display_step = STEP_D0, .soc_step =
STEP_C0 },
};
/* Same GT stepping between tgl_uy_revids and tgl_revids don't mean the same
HW */
static const struct intel_step_info tgl_revid_step_tbl[] = {
- [0] = { .gt_step = STEP_A0, .display_step = STEP_B0 },
- [1] = { .gt_step = STEP_B0, .display_step = STEP_D0 },
+ [0] = { .gt_step = STEP_A0, .display_step = STEP_B0, .soc_step =
STEP_P0 },
+ [1] = { .gt_step = STEP_B0, .display_step = STEP_D0, .soc_step =
STEP_R0 },
};
static const struct intel_step_info adls_revid_step_tbl[] = {
- [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
- [0x1] = { .gt_step = STEP_A0, .display_step = STEP_A2 },
- [0x4] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
- [0x8] = { .gt_step = STEP_C0, .display_step = STEP_B0 },
- [0xC] = { .gt_step = STEP_D0, .display_step = STEP_C0 },
+ [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0, .soc_step =
STEP_A0 },
+ [0x1] = { .gt_step = STEP_A0, .display_step = STEP_A2, .soc_step =
STEP_A2 },
+ [0x4] = { .gt_step = STEP_B0, .display_step = STEP_B0, .soc_step =
STEP_B0 },
+ [0x8] = { .gt_step = STEP_C0, .display_step = STEP_B0, .soc_step =
STEP_G0 },
+ [0xC] = { .gt_step = STEP_D0, .display_step = STEP_C0, .soc_step =
STEP_H0 },
};
static const struct intel_step_info adlp_revid_step_tbl[] = {
- [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0 },
- [0x4] = { .gt_step = STEP_B0, .display_step = STEP_B0 },
- [0x8] = { .gt_step = STEP_C0, .display_step = STEP_C0 },
- [0xC] = { .gt_step = STEP_C0, .display_step = STEP_D0 },
+ [0x0] = { .gt_step = STEP_A0, .display_step = STEP_A0, .soc_step =
STEP_J0 },
+ [0x4] = { .gt_step = STEP_B0, .display_step = STEP_B0, .soc_step =
STEP_Q0 },
+ [0x8] = { .gt_step = STEP_C0, .display_step = STEP_C0, .soc_step =
STEP_K0 },
+ [0xC] = { .gt_step = STEP_C0, .display_step = STEP_D0, .soc_step =
STEP_L0 },
};
void intel_step_init(struct drm_i915_private *i915)
diff --git a/drivers/gpu/drm/i915/intel_step.h
b/drivers/gpu/drm/i915/intel_step.h
index 958a8bb5d677..2b0b0aaffe27 100644
--- a/drivers/gpu/drm/i915/intel_step.h
+++ b/drivers/gpu/drm/i915/intel_step.h
@@ -13,6 +13,7 @@ struct drm_i915_private;
struct intel_step_info {
u8 gt_step;
u8 display_step;
+ u8 soc_step;
};
/*
@@ -25,12 +26,24 @@ enum intel_step {
STEP_A2,
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Introduce a migrate interface (rev5)
== Series Details ==
Series: drm/i915/gem: Introduce a migrate interface (rev5)
URL : https://patchwork.freedesktop.org/series/91890/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10289_full -> Patchwork_20488_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20488_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs}:
- {shard-rkl}:[PASS][1] -> [FAIL][2] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-2/igt@kms_ccs@pipe-a-bad-rotation-90-y_tiled_gen12_rc_ccs.html
* {igt@kms_ccs@pipe-b-crc-primary-rotation-180-yf_tiled_ccs}:
- {shard-rkl}:[FAIL][3] -> [SKIP][4] +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-2/igt@kms_ccs@pipe-b-crc-primary-rotation-180-yf_tiled_ccs.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-6/igt@kms_ccs@pipe-b-crc-primary-rotation-180-yf_tiled_ccs.html
* {igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs}:
- {shard-rkl}:[SKIP][5] -> [FAIL][6] +7 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-2/igt@kms_ccs@pipe-c-bad-rotation-90-yf_tiled_ccs.html
* {igt@kms_ccs@pipe-d-ccs-on-another-bo-y_tiled_ccs}:
- {shard-rkl}:[SKIP][7] ([i915#533]) -> [FAIL][8] +4 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_ccs@pipe-d-ccs-on-another-bo-y_tiled_ccs.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-2/igt@kms_ccs@pipe-d-ccs-on-another-bo-y_tiled_ccs.html
* igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding:
- {shard-rkl}:[SKIP][9] ([fdo#112022]) -> [SKIP][10] +8 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-5/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-1/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html
* igt@kms_cursor_crc@pipe-b-cursor-512x512-onscreen:
- {shard-rkl}:[SKIP][11] ([fdo#109279] / [i915#3359]) -> [SKIP][12]
+2 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_cursor_...@pipe-b-cursor-512x512-onscreen.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-1/igt@kms_cursor_...@pipe-b-cursor-512x512-onscreen.html
* igt@kms_cursor_crc@pipe-c-cursor-32x10-onscreen:
- {shard-rkl}:[SKIP][13] ([i915#3359]) -> [SKIP][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_cursor_...@pipe-c-cursor-32x10-onscreen.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-2/igt@kms_cursor_...@pipe-c-cursor-32x10-onscreen.html
* igt@kms_draw_crc@draw-method-rgb565-mmap-cpu-ytiled:
- {shard-rkl}:[SKIP][15] ([fdo#111314]) -> [SKIP][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-2/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-ytiled.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-1/igt@kms_draw_...@draw-method-rgb565-mmap-cpu-ytiled.html
* igt@kms_draw_crc@draw-method-xrgb-blt-xtiled:
- {shard-rkl}:[PASS][17] -> [SKIP][18] +29 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_draw_...@draw-method-xrgb-blt-xtiled.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-2/igt@kms_draw_...@draw-method-xrgb-blt-xtiled.html
* igt@kms_flip@flip-vs-rmfb:
- {shard-rkl}:NOTRUN -> [SKIP][19] +1 similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-1/igt@kms_f...@flip-vs-rmfb.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-16bpp-ytile:
- {shard-rkl}:[SKIP][20] -> [INCOMPLETE][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@kms_flip_scaled_...@flip-64bpp-ytile-to-16bpp-ytile.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/shard-rkl-1/igt@kms_flip_scaled_...@flip-64bpp-ytile-to-16bpp-ytile.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-indfb-fliptrack-mmap-gtt:
- {shard-rkl}:[SKIP][22] ([fdo#111825]) -> [SKIP][23]
[22]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: address potential UAF bugs with drm_master ptrs (rev2)
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs (rev2)
URL : https://patchwork.freedesktop.org/series/91969/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10289_full -> Patchwork_20487_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20487_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20487_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20487_full:
### IGT changes ###
Possible regressions
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-cpu:
- shard-snb: [PASS][1] -> [DMESG-WARN][2] +4 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-snb6/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-cpu.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-snb2/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-cpu.html
- shard-tglb: [PASS][3] -> [DMESG-WARN][4] +5 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-tglb7/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-cpu.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-tglb7/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-cpu.html
* igt@kms_vblank@pipe-b-ts-continuation-dpms-rpm:
- shard-iclb: [PASS][5] -> [DMESG-WARN][6] +6 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-iclb4/igt@kms_vbl...@pipe-b-ts-continuation-dpms-rpm.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-iclb8/igt@kms_vbl...@pipe-b-ts-continuation-dpms-rpm.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs}:
- shard-tglb: [PASS][7] -> [DMESG-WARN][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-tglb6/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-tglb7/igt@kms_ccs@pipe-a-ccs-on-another-bo-y_tiled_gen12_rc_ccs.html
* {igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs}:
- shard-iclb: [PASS][9] -> [DMESG-WARN][10] +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-iclb3/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-iclb4/igt@kms_ccs@pipe-b-bad-pixel-format-y_tiled_ccs.html
* igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-cpu:
- {shard-rkl}:[SKIP][11] -> [DMESG-WARN][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-1/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-cpu.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-6/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-cpu.html
* igt@runner@aborted:
- {shard-rkl}:([FAIL][13], [FAIL][14], [FAIL][15]) ([i915#3002]) ->
([FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21],
[FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27],
[FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33],
[FAIL][34], [FAIL][35], [FAIL][36], [FAIL][37], [FAIL][38]) ([i915#1602])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-5/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-6/igt@run...@aborted.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/shard-rkl-2/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-1/igt@run...@aborted.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-1/igt@run...@aborted.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-1/igt@run...@aborted.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-1/igt@run...@aborted.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-1/igt@run...@aborted.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-1/igt@run...@aborted.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-2/igt@run...@aborted.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-2/igt@run...@aborted.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/shard-rkl-2/igt@run...@aborted.html
[25]:
Re: [Intel-gfx] [PATCH] drm/i915/display/tgl: Implement Wa_14013120569
On Mon, 2021-06-28 at 16:50 -0700, Madhumitha Tolakanahalli Pradeep wrote:
> PCH display HPD IRQ is not detected with default filter value.
> So, PP_CONTROL is manually reprogrammed.
>
> Signed-off-by: Madhumitha Tolakanahalli Pradeep
>
> ---
> .../gpu/drm/i915/display/intel_display_power.c | 8
> drivers/gpu/drm/i915/display/intel_hotplug.c | 16
> 2 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 285380079aab..e44323cc76f5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -6385,8 +6385,16 @@ static void intel_power_domains_verify_state(struct
> drm_i915_private *i915)
>
> void intel_display_power_suspend_late(struct drm_i915_private *i915)
> {
> +struct drm_i915_private *dev_priv = i915;
> +u32 val;
> if (DISPLAY_VER(i915) >= 11 || IS_GEMINILAKE(i915) ||
> IS_BROXTON(i915)) {
> + val = intel_de_read(dev_priv, PP_CONTROL(0));
> + /* Wa_14013120569:tgl */
> + if (IS_TIGERLAKE(i915)) {
> + val &= ~PANEL_POWER_ON;
> + intel_de_write(dev_priv, PP_CONTROL(0), val);
> + }
Code style is all wrong, please fix it and run "dim checkpatch" to validate it
before sending patches.
Also PP_CONTROL(0) don't point to the same register that the workaround is
talking about, between generations register address change that might be
the case for this one.
This satisfy the "before going into sleep to allow CS entry" but it do not
restore the workaround after waking up from suspend.
Also you could improve the code, you are reading the register even for
platforms that don't need the wa, also check intel_de_rmw() it is better suited
to this case.
> bxt_enable_dc9(i915);
> /* Tweaked Wa_14010685332:icp,jsp,mcc */
> if (INTEL_PCH_TYPE(i915) >= PCH_ICP && INTEL_PCH_TYPE(i915) <=
> PCH_MCC)
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index 47c85ac97c87..8e3f84100daf 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -26,6 +26,7 @@
> #include "i915_drv.h"
> #include "intel_display_types.h"
> #include "intel_hotplug.h"
> +#include "intel_de.h"
>
> /**
> * DOC: Hotplug
> @@ -266,7 +267,9 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
> struct intel_connector *connector)
> {
> struct drm_device *dev = connector->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> enum drm_connector_status old_status;
> + u32 val;
> u64 old_epoch_counter;
> bool ret = false;
>
> @@ -288,6 +291,19 @@ intel_encoder_hotplug(struct intel_encoder *encoder,
>
> drm_get_connector_status_name(connector->base.status),
> old_epoch_counter,
> connector->base.epoch_counter);
> +
> + /* Wa_14013120569:tgl */
> + if (IS_TIGERLAKE(dev_priv)) {
> + val = intel_de_read(dev_priv, PP_CONTROL(0));
> + if (connector->base.status ==
> connector_status_connected) {
> + val |= PANEL_POWER_ON;
> + intel_de_write(dev_priv, PP_CONTROL(0), val);
> + }
> + else if (connector->base.status ==
> connector_status_disconnected) {
> + val &= ~PANEL_POWER_ON;
> + intel_de_write(dev_priv, PP_CONTROL(0), val);
> + }
> + }
Not sure if this is the best place but anyways it is missing handle the case
were tigerlake boots with the external display connected.
No hotplug will happen and workaround will never be enabled.
> return INTEL_HOTPLUG_CHANGED;
> }
> return INTEL_HOTPLUG_UNCHANGED;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/47] drm/i915/guc: Add bypass tasklet submission path to GuC
On 6/24/2021 00:04, Matthew Brost wrote:
Add bypass tasklet submission path to GuC. The tasklet is only used if H2G
channel has backpresure.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index ee933efbf0ff..38aff83ee9fa 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -172,6 +172,12 @@ static int guc_add_request(struct intel_guc *guc, struct
i915_request *rq)
return err;
}
+static inline void guc_set_lrc_tail(struct i915_request *rq)
+{
+ rq->context->lrc_reg_state[CTX_RING_TAIL] =
+ intel_ring_set_tail(rq->ring, rq->tail);
+}
+
static inline int rq_prio(const struct i915_request *rq)
{
return rq->sched.attr.priority;
@@ -215,8 +221,7 @@ static int guc_dequeue_one_context(struct intel_guc *guc)
}
done:
if (submit) {
- last->context->lrc_reg_state[CTX_RING_TAIL] =
- intel_ring_set_tail(last->ring, last->tail);
+ guc_set_lrc_tail(last);
resubmit:
/*
* We only check for -EBUSY here even though it is possible for
@@ -496,20 +501,36 @@ static inline void queue_request(struct i915_sched_engine
*sched_engine,
set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
}
+static int guc_bypass_tasklet_submit(struct intel_guc *guc,
+struct i915_request *rq)
+{
+ int ret;
+
+ __i915_request_submit(rq);
+
+ trace_i915_request_in(rq, 0);
+
+ guc_set_lrc_tail(rq);
+ ret = guc_add_request(guc, rq);
+ if (ret == -EBUSY)
+ guc->stalled_request = rq;
+
+ return ret;
+}
+
static void guc_submit_request(struct i915_request *rq)
{
struct i915_sched_engine *sched_engine = rq->engine->sched_engine;
+ struct intel_guc *guc = >engine->gt->uc.guc;
unsigned long flags;
/* Will be called from irq-context when using foreign fences. */
spin_lock_irqsave(_engine->lock, flags);
- queue_request(sched_engine, rq, rq_prio(rq));
-
- GEM_BUG_ON(i915_sched_engine_is_empty(sched_engine));
- GEM_BUG_ON(list_empty(>sched.link));
-
- tasklet_hi_schedule(_engine->tasklet);
+ if (guc->stalled_request || !i915_sched_engine_is_empty(sched_engine))
+ queue_request(sched_engine, rq, rq_prio(rq));
+ else if (guc_bypass_tasklet_submit(guc, rq) == -EBUSY)
+ tasklet_hi_schedule(_engine->tasklet);
spin_unlock_irqrestore(_engine->lock, flags);
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/47] drm/i915/guc: Implement GuC submission tasklet
On 6/24/2021 00:04, Matthew Brost wrote:
Implement GuC submission tasklet for new interface. The new GuC
interface uses H2G to submit contexts to the GuC. Since H2G use a single
channel, a single tasklet submits is used for the submission path.
Re-word? 'a single tasklet submits is used...' doesn't make sense.
Also the per engine interrupt handler has been updated to disable the
rescheduling of the physical engine tasklet, when using GuC scheduling,
as the physical engine tasklet is no longer used.
In this patch the field, guc_id, has been added to intel_context and is
not assigned. Patches later in the series will assign this value.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 9 +
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 4 +
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 231 +-
3 files changed, 127 insertions(+), 117 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index ed8c447a7346..bb6fef7eae52 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -136,6 +136,15 @@ struct intel_context {
struct intel_sseu sseu;
u8 wa_bb_page; /* if set, page num reserved for context workarounds */
+
+ /* GuC scheduling state that does not require a lock. */
Maybe 'GuC scheduling state flags that do not require a lock'? Otherwise
it just looks like a counter or something.
+ atomic_t guc_sched_state_no_lock;
+
+ /*
+* GuC lrc descriptor ID - Not assigned in this patch but future patches
Not a blocker but s/lrc/LRC/ would keep Michal happy ;). Although
presumably this comment is at least being amended by later patches in
the series.
+* in the series will.
+*/
+ u16 guc_id;
};
#endif /* __INTEL_CONTEXT_TYPES__ */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 2313d9fc087b..9ba8219475b2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -30,6 +30,10 @@ struct intel_guc {
struct intel_guc_log log;
struct intel_guc_ct ct;
+ /* Global engine used to submit requests to GuC */
+ struct i915_sched_engine *sched_engine;
+ struct i915_request *stalled_request;
+
/* intel_guc_recv interrupt related state */
spinlock_t irq_lock;
unsigned int msg_enabled_mask;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 23a94a896a0b..ee933efbf0ff 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -60,6 +60,31 @@
#define GUC_REQUEST_SIZE 64 /* bytes */
+/*
+ * Below is a set of functions which control the GuC scheduling state which do
+ * not require a lock as all state transitions are mutually exclusive. i.e. It
+ * is not possible for the context pinning code and submission, for the same
+ * context, to be executing simultaneously. We still need an atomic as it is
+ * possible for some of the bits to changing at the same time though.
+ */
+#define SCHED_STATE_NO_LOCK_ENABLEDBIT(0)
+static inline bool context_enabled(struct intel_context *ce)
+{
+ return (atomic_read(>guc_sched_state_no_lock) &
+ SCHED_STATE_NO_LOCK_ENABLED);
+}
+
+static inline void set_context_enabled(struct intel_context *ce)
+{
+ atomic_or(SCHED_STATE_NO_LOCK_ENABLED, >guc_sched_state_no_lock);
+}
+
+static inline void clr_context_enabled(struct intel_context *ce)
+{
+ atomic_and((u32)~SCHED_STATE_NO_LOCK_ENABLED,
+ >guc_sched_state_no_lock);
+}
+
static inline struct i915_priolist *to_priolist(struct rb_node *rb)
{
return rb_entry(rb, struct i915_priolist, node);
@@ -122,37 +147,29 @@ static inline void set_lrc_desc_registered(struct
intel_guc *guc, u32 id,
xa_store_irq(>context_lookup, id, ce, GFP_ATOMIC);
}
-static void guc_add_request(struct intel_guc *guc, struct i915_request *rq)
+static int guc_add_request(struct intel_guc *guc, struct i915_request *rq)
{
- /* Leaving stub as this function will be used in future patches */
-}
+ int err;
+ struct intel_context *ce = rq->context;
+ u32 action[3];
+ int len = 0;
+ bool enabled = context_enabled(ce);
-/*
- * When we're doing submissions using regular execlists backend, writing to
- * ELSP from CPU side is enough to make sure that writes to ringbuffer pages
- * pinned in mappable aperture portion of GGTT are visible to command streamer.
- * Writes done by GuC on our behalf are not guaranteeing such ordering,
- * therefore, to ensure the flush, we're issuing a POSTING READ.
- */
-static void flush_ggtt_writes(struct i915_vma *vma)
-{
- if
Re: [Intel-gfx] [PATCH i-g-t v2] gem_watchdog: Skip test if default request expiry is not compiled in
On Mon, 24 May 2021 07:38:01 -0700, Tvrtko Ursulin wrote:
>
> From: Tvrtko Ursulin
>
> Test incorrectly assumes no modparam means default expiry, while in
> reality no modparam means old kernel / de-selected feature in which
> case test should skip.
>
> v2:
> * New line. (Petri)
Reviewed-by: Ashutosh Dixit
> Signed-off-by: Tvrtko Ursulin
> ---
> tests/i915/gem_watchdog.c | 16 +++-
> 1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/tests/i915/gem_watchdog.c b/tests/i915/gem_watchdog.c
> index 8f9fb17750fb..67fddac74bc1 100644
> --- a/tests/i915/gem_watchdog.c
> +++ b/tests/i915/gem_watchdog.c
> @@ -630,6 +630,7 @@ igt_main
>
> igt_fixture {
> struct drm_i915_query_item item;
> + const unsigned int timeout = 1;
> char *tmp;
>
> i915 = drm_open_driver_master(DRIVER_INTEL);
> @@ -639,16 +640,13 @@ igt_main
> igt_require_gem(i915);
>
> tmp = __igt_params_get(i915, "request_timeout_ms");
> - if (tmp) {
> - const unsigned int timeout = 1;
> + igt_skip_on_f(!tmp || !atoi(tmp),
> + "Request expiry not supported!\n");
> + free(tmp);
>
> - igt_params_save_and_set(i915, "request_timeout_ms",
> - "%u", timeout * 1000);
> - default_timeout_wait_s = timeout * 5;
> - free(tmp);
> - } else {
> - default_timeout_wait_s = 12;
> - }
> + igt_params_save_and_set(i915, "request_timeout_ms", "%u",
> + timeout * 1000);
> + default_timeout_wait_s = timeout * 5;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] PR for new GuC v62.0.3 and HuC v7.9.3 binaries
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 up to f4d897acd200190350a5f2148316c51c6c57bc9b: firmware/i915/guc: Add HuC v7.9.3 for TGL & DG1 (2021-06-29 14:20:03 -0700) John Harrison (3): firmware/i915/guc: Add GuC v62.0.0 for all platforms firmware/i915/guc: Add GuC v62.0.3 for ADL-P firmware/i915/guc: Add HuC v7.9.3 for TGL & DG1 WHENCE | 38 +- i915/adlp_guc_62.0.3.bin | Bin 0 -> 336704 bytes i915/bxt_guc_62.0.0.bin | Bin 0 -> 199616 bytes i915/cml_guc_62.0.0.bin | Bin 0 -> 200448 bytes i915/dg1_guc_62.0.0.bin | Bin 0 -> 315648 bytes i915/dg1_huc_7.9.3.bin | Bin 0 -> 589888 bytes i915/ehl_guc_62.0.0.bin | Bin 0 -> 327488 bytes i915/glk_guc_62.0.0.bin | Bin 0 -> 20 bytes i915/icl_guc_62.0.0.bin | Bin 0 -> 327488 bytes i915/kbl_guc_62.0.0.bin | Bin 0 -> 200448 bytes i915/skl_guc_62.0.0.bin | Bin 0 -> 199552 bytes i915/tgl_guc_62.0.0.bin | Bin 0 -> 326016 bytes i915/tgl_huc_7.9.3.bin | Bin 0 -> 589888 bytes 13 files changed, 37 insertions(+), 1 deletion(-) create mode 100644 i915/adlp_guc_62.0.3.bin create mode 100644 i915/bxt_guc_62.0.0.bin create mode 100644 i915/cml_guc_62.0.0.bin create mode 100644 i915/dg1_guc_62.0.0.bin create mode 100644 i915/dg1_huc_7.9.3.bin create mode 100644 i915/ehl_guc_62.0.0.bin create mode 100644 i915/glk_guc_62.0.0.bin create mode 100644 i915/icl_guc_62.0.0.bin create mode 100644 i915/kbl_guc_62.0.0.bin create mode 100644 i915/skl_guc_62.0.0.bin create mode 100644 i915/tgl_guc_62.0.0.bin create mode 100644 i915/tgl_huc_7.9.3.bin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/47] drm/i915/guc: Add lrc descriptor context lookup array
On 6/25/2021 10:26, Matthew Brost wrote:
On Fri, Jun 25, 2021 at 03:17:51PM +0200, Michal Wajdeczko wrote:
On 24.06.2021 09:04, Matthew Brost wrote:
Add lrc descriptor context lookup array which can resolve the
intel_context from the lrc descriptor index. In addition to lookup, it
can determine in the lrc descriptor context is currently registered with
the GuC by checking if an entry for a descriptor index is present.
Future patches in the series will make use of this array.
s/lrc/LRC
I guess? lrc and LRC are used interchangeably throughout the current
code base.
It is an abbreviation so LRC is technically the correct version for a
comment. The fact that other existing comments are incorrect is not a
valid reason to perpetuate a mistake :). Might as well fix it if you are
going to repost the patch anyway for any other reason, but I would not
call it a blocking issue.
Also, 'can determine in the' should be 'can determine if the'. Again,
not exactly a blocking issue but should be fixed.
Cc: John Harrison
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 5 +++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 32 +--
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index b28fa54214f2..2313d9fc087b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -6,6 +6,8 @@
#ifndef _INTEL_GUC_H_
#define _INTEL_GUC_H_
+#include "linux/xarray.h"
#include
Yep.
+
#include "intel_uncore.h"
#include "intel_guc_fw.h"
#include "intel_guc_fwif.h"
@@ -46,6 +48,9 @@ struct intel_guc {
struct i915_vma *lrc_desc_pool;
void *lrc_desc_pool_vaddr;
+ /* guc_id to intel_context lookup */
+ struct xarray context_lookup;
+
/* Control params for fw initialization */
u32 params[GUC_CTL_MAX_DWORDS];
btw, IIRC there was idea to move most struct definitions to
intel_guc_types.h, is this still a plan ?
I don't ever recall discussing this but we can certainly do this. For
what it is worth we do introduce intel_guc_submission_types.h a bit
later. I'll make a note about intel_guc_types.h though.
Matt
Yeah, my only recollection was about the submission types header. Are
there sufficient non-submission fields in the GuC structure to warrant a
general GuC types header?
With the commit message tweaks and #include fix mentioned above, it
looks good to me.
Reviewed-by: John Harrison
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index a366890fb840..23a94a896a0b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -65,8 +65,6 @@ static inline struct i915_priolist *to_priolist(struct
rb_node *rb)
return rb_entry(rb, struct i915_priolist, node);
}
-/* Future patches will use this function */
-__attribute__ ((unused))
static struct guc_lrc_desc *__get_lrc_desc(struct intel_guc *guc, u32 index)
{
struct guc_lrc_desc *base = guc->lrc_desc_pool_vaddr;
@@ -76,6 +74,15 @@ static struct guc_lrc_desc *__get_lrc_desc(struct intel_guc
*guc, u32 index)
return [index];
}
+static inline struct intel_context *__get_context(struct intel_guc *guc, u32 id)
+{
+ struct intel_context *ce = xa_load(>context_lookup, id);
+
+ GEM_BUG_ON(id >= GUC_MAX_LRC_DESCRIPTORS);
+
+ return ce;
+}
+
static int guc_lrc_desc_pool_create(struct intel_guc *guc)
{
u32 size;
@@ -96,6 +103,25 @@ static void guc_lrc_desc_pool_destroy(struct intel_guc *guc)
i915_vma_unpin_and_release(>lrc_desc_pool, I915_VMA_RELEASE_MAP);
}
+static inline void reset_lrc_desc(struct intel_guc *guc, u32 id)
+{
+ struct guc_lrc_desc *desc = __get_lrc_desc(guc, id);
+
+ memset(desc, 0, sizeof(*desc));
+ xa_erase_irq(>context_lookup, id);
+}
+
+static inline bool lrc_desc_registered(struct intel_guc *guc, u32 id)
+{
+ return __get_context(guc, id);
+}
+
+static inline void set_lrc_desc_registered(struct intel_guc *guc, u32 id,
+ struct intel_context *ce)
+{
+ xa_store_irq(>context_lookup, id, ce, GFP_ATOMIC);
+}
+
static void guc_add_request(struct intel_guc *guc, struct i915_request *rq)
{
/* Leaving stub as this function will be used in future patches */
@@ -400,6 +426,8 @@ int intel_guc_submission_init(struct intel_guc *guc)
*/
GEM_BUG_ON(!guc->lrc_desc_pool);
+ xa_init_flags(>context_lookup, XA_FLAGS_LOCK_IRQ);
+
return 0;
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/47] drm/i915/guc: Add new GuC interface defines and structures
On 6/24/2021 00:04, Matthew Brost wrote:
Add new GuC interface defines and structures while maintaining old ones
in parallel.
Cc: John Harrison
Signed-off-by: Matthew Brost
I think there was some difference of opinion over whether these
additions should be squashed in to the specific patches that first use
them. However, on the grounds that such is basically a patch-only style
comment and doesn't change the final product plus, we need to get this
stuff merged efficiently and not spend forever rebasing and refactoring...
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 14 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 41 +++
2 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 2d6198e63ebe..57e18babdf4b 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -124,10 +124,24 @@ enum intel_guc_action {
INTEL_GUC_ACTION_FORCE_LOG_BUFFER_FLUSH = 0x302,
INTEL_GUC_ACTION_ENTER_S_STATE = 0x501,
INTEL_GUC_ACTION_EXIT_S_STATE = 0x502,
+ INTEL_GUC_ACTION_GLOBAL_SCHED_POLICY_CHANGE = 0x506,
+ INTEL_GUC_ACTION_SCHED_CONTEXT = 0x1000,
+ INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_SET = 0x1001,
+ INTEL_GUC_ACTION_SCHED_CONTEXT_MODE_DONE = 0x1002,
+ INTEL_GUC_ACTION_SCHED_ENGINE_MODE_SET = 0x1003,
+ INTEL_GUC_ACTION_SCHED_ENGINE_MODE_DONE = 0x1004,
+ INTEL_GUC_ACTION_SET_CONTEXT_PRIORITY = 0x1005,
+ INTEL_GUC_ACTION_SET_CONTEXT_EXECUTION_QUANTUM = 0x1006,
+ INTEL_GUC_ACTION_SET_CONTEXT_PREEMPTION_TIMEOUT = 0x1007,
+ INTEL_GUC_ACTION_CONTEXT_RESET_NOTIFICATION = 0x1008,
+ INTEL_GUC_ACTION_ENGINE_FAILURE_NOTIFICATION = 0x1009,
INTEL_GUC_ACTION_SLPC_REQUEST = 0x3003,
INTEL_GUC_ACTION_AUTHENTICATE_HUC = 0x4000,
+ INTEL_GUC_ACTION_REGISTER_CONTEXT = 0x4502,
+ INTEL_GUC_ACTION_DEREGISTER_CONTEXT = 0x4503,
INTEL_GUC_ACTION_REGISTER_COMMAND_TRANSPORT_BUFFER = 0x4505,
INTEL_GUC_ACTION_DEREGISTER_COMMAND_TRANSPORT_BUFFER = 0x4506,
+ INTEL_GUC_ACTION_DEREGISTER_CONTEXT_DONE = 0x4600,
INTEL_GUC_ACTION_LIMIT
};
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 617ec601648d..28245a217a39 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -17,6 +17,9 @@
#include "abi/guc_communication_ctb_abi.h"
#include "abi/guc_messages_abi.h"
+#define GUC_CONTEXT_DISABLE 0
+#define GUC_CONTEXT_ENABLE 1
+
#define GUC_CLIENT_PRIORITY_KMD_HIGH 0
#define GUC_CLIENT_PRIORITY_HIGH 1
#define GUC_CLIENT_PRIORITY_KMD_NORMAL2
@@ -26,6 +29,9 @@
#define GUC_MAX_STAGE_DESCRIPTORS 1024
#define GUC_INVALID_STAGE_IDGUC_MAX_STAGE_DESCRIPTORS
+#define GUC_MAX_LRC_DESCRIPTORS 65535
+#defineGUC_INVALID_LRC_ID GUC_MAX_LRC_DESCRIPTORS
+
#define GUC_RENDER_ENGINE 0
#define GUC_VIDEO_ENGINE 1
#define GUC_BLITTER_ENGINE2
@@ -237,6 +243,41 @@ struct guc_stage_desc {
u64 desc_private;
} __packed;
+#define CONTEXT_REGISTRATION_FLAG_KMD BIT(0)
+
+#define CONTEXT_POLICY_DEFAULT_EXECUTION_QUANTUM_US 100
+#define CONTEXT_POLICY_DEFAULT_PREEMPTION_TIME_US 50
+
+/* Preempt to idle on quantum expiry */
+#define CONTEXT_POLICY_FLAG_PREEMPT_TO_IDLEBIT(0)
+
+/*
+ * GuC Context registration descriptor.
+ * FIXME: This is only required to exist during context registration.
+ * The current 1:1 between guc_lrc_desc and LRCs for the lifetime of the LRC
+ * is not required.
+ */
+struct guc_lrc_desc {
+ u32 hw_context_desc;
+ u32 slpm_perf_mode_hint;/* SPLC v1 only */
+ u32 slpm_freq_hint;
+ u32 engine_submit_mask; /* In logical space */
+ u8 engine_class;
+ u8 reserved0[3];
+ u32 priority;
+ u32 process_desc;
+ u32 wq_addr;
+ u32 wq_size;
+ u32 context_flags; /* CONTEXT_REGISTRATION_* */
+ /* Time for one workload to execute. (in micro seconds) */
+ u32 execution_quantum;
+ /* Time to wait for a preemption request to complete before issuing a
+* reset. (in micro seconds). */
+ u32 preemption_timeout;
+ u32 policy_flags; /* CONTEXT_POLICY_* */
+ u32 reserved1[19];
+} __packed;
+
#define GUC_POWER_UNSPECIFIED 0
#define GUC_POWER_D0 1
#define GUC_POWER_D1 2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for GuC submission / DRM scheduler integration plan + new uAPI
== Series Details == Series: GuC submission / DRM scheduler integration plan + new uAPI URL : https://patchwork.freedesktop.org/series/92028/ State : success == Summary == CI Bug Log - changes from CI_DRM_10289 -> Patchwork_20489 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/index.html Known issues Here are the changes found in Patchwork_20489 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +23 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][2] ([fdo#109271]) +17 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][3] ([i915#2283]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][4] -> [FAIL][5] ([i915#1372]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html Possible fixes * igt@i915_selftest@live@hugepages: - fi-snb-2600:[INCOMPLETE][6] -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-snb-2600/igt@i915_selftest@l...@hugepages.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/fi-snb-2600/igt@i915_selftest@l...@hugepages.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7500u: [DMESG-FAIL][8] ([i915#165]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 Participating hosts (42 -> 37) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_10289 -> Patchwork_20489 CI-20190529: 20190529 CI_DRM_10289: b9081c2437cee8e573eeafcd19c816cc7e10f19d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6121: a63ceb48e6c3e733d04156b32fba3b4f4d5ad794 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20489: 16b33a940e2989e992e71b1812606efb1464ad2b @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 16b33a940e29 drm/doc/rfc: i915 new parallel submission uAPI plan 9534ae8c12da drm/doc/rfc: i915 GuC submission / DRM scheduler == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20489/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for GuC submission / DRM scheduler integration plan + new uAPI
== Series Details == Series: GuC submission / DRM scheduler integration plan + new uAPI URL : https://patchwork.freedesktop.org/series/92028/ State : warning == Summary == $ dim checkpatch origin/drm-tip 9534ae8c12da drm/doc/rfc: i915 GuC submission / DRM scheduler -:44: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #44: new file mode 100644 -:49: WARNING:SPDX_LICENSE_TAG: Missing or malformed SPDX-License-Identifier tag in line 1 #49: FILE: Documentation/gpu/rfc/i915_scheduler.rst:1: += total: 0 errors, 2 warnings, 0 checks, 98 lines checked 16b33a940e29 drm/doc/rfc: i915 new parallel submission uAPI plan -:45: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #45: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 184 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/aperture: Pass DRM driver structure instead of driver name
LGTM
Acked-by: Nirmoy Das
On 6/29/2021 3:58 PM, Thomas Zimmermann wrote:
Print the name of the DRM driver when taking over fbdev devices. Makes
the output to dmesg more consistent. Note that the driver name is only
used for printing a string to the kernel log. No UAPI is affected by this
change.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/armada/armada_drv.c | 2 +-
drivers/gpu/drm/ast/ast_drv.c | 2 +-
drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
drivers/gpu/drm/drm_aperture.c| 19 ---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/meson/meson_drv.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
drivers/gpu/drm/tegra/drm.c | 2 +-
drivers/gpu/drm/tiny/cirrus.c | 2 +-
drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +-
drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/drm_aperture.h| 14 +-
23 files changed, 43 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6f30c525caac..accf9c1b967a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1278,7 +1278,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
#endif
/* Get rid of things like offb */
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
"amdgpudrmfb");
+ ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
_kms_driver);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/armada/armada_drv.c b/drivers/gpu/drm/armada/armada_drv.c
index dab0a1f0983b..31925ae3ab72 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -95,7 +95,7 @@ static int armada_drm_bind(struct device *dev)
}
/* Remove early framebuffers */
- ret = drm_aperture_remove_framebuffers(false, "armada-drm-fb");
+ ret = drm_aperture_remove_framebuffers(false, _drm_driver);
if (ret) {
dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n",
__func__, ret);
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 5aa452b4efe6..86d5cd7b6318 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -100,7 +100,7 @@ static int ast_remove_conflicting_framebuffers(struct
pci_dev *pdev)
primary = pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW;
#endif
- return drm_aperture_remove_conflicting_framebuffers(base, size, primary, "astdrmfb");
+ return drm_aperture_remove_conflicting_framebuffers(base, size, primary,
_driver);
}
static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index c828cadbabff..0d232b44ecd7 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -110,7 +110,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
return -ENOMEM;
}
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev, "bochsdrmfb");
+ ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
_driver);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
index 9335d9d6cf9a..9ac39cf11694 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -33,6 +33,10 @@
*
* .. code-block:: c
*
+ * static const struct drm_driver example_driver = {
+ * ...
+ * };
+ *
*static int remove_conflicting_framebuffers(struct pci_dev *pdev)
*{
*bool primary = false;
@@ -46,7 +50,7 @@
*#endif
*
*return drm_aperture_remove_conflicting_framebuffers(base, size,
primary,
- * "example
driver");
+ *
_driver);
*}
*
*static int probe(struct pci_dev *pdev)
@@ -274,7 +278,7 @@ static void drm_aperture_detach_drivers(resource_size_t
base, resource_size_t si
* @base: the
[Intel-gfx] [PATCH 0/2] GuC submission / DRM scheduler integration plan + new uAPI
Subject and patches say it all. v2: Address comments, patches have details of changes v3: Address comments, patches have details of changes v4: Address comments, patches have details of changes v5: Fix checkpatch and docs warnings Signed-off-by: Matthew Brost Matthew Brost (2): drm/doc/rfc: i915 GuC submission / DRM scheduler drm/doc/rfc: i915 new parallel submission uAPI plan Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 +++ Documentation/gpu/rfc/i915_scheduler.rst | 148 ++ Documentation/gpu/rfc/index.rst | 4 + 3 files changed, 274 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst -- 2.28.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/doc/rfc: i915 GuC submission / DRM scheduler
Add entry for i915 GuC submission / DRM scheduler integration plan. Follow up patch with details of new parallel submission uAPI to come. v2: (Daniel Vetter) - Expand explaination of why bonding isn't supported for GuC submission - CC some of the DRM scheduler maintainers - Add priority inheritance / boosting use case - Add reasoning for removing in order assumptions (Daniel Stone) - Add links to priority spec v4: (Tvrtko) - Add TODOs section (Daniel Vetter) - Pull in 1 line from following patch v5: (Checkpatch) - Fix typos Cc: Christian König Cc: Luben Tuikov Cc: Alex Deucher Cc: Steven Price Cc: Jon Bloomfield Cc: Dave Airlie Cc: Daniel Vetter Cc: Jason Ekstrand Cc: dri-de...@lists.freedesktop.org Signed-off-by: Matthew Brost Reviewed-by: Daniel Vetter Acked-by: Dave Airlie --- Documentation/gpu/rfc/i915_scheduler.rst | 91 Documentation/gpu/rfc/index.rst | 4 ++ 2 files changed, 95 insertions(+) create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst diff --git a/Documentation/gpu/rfc/i915_scheduler.rst b/Documentation/gpu/rfc/i915_scheduler.rst new file mode 100644 index ..7acd386a6b49 --- /dev/null +++ b/Documentation/gpu/rfc/i915_scheduler.rst @@ -0,0 +1,91 @@ += +I915 GuC Submission/DRM Scheduler Section += + +Upstream plan += +For upstream the overall plan for landing GuC submission and integrating the +i915 with the DRM scheduler is: + +* Merge basic GuC submission + * Basic submission support for all gen11+ platforms + * Not enabled by default on any current platforms but can be enabled via + modparam enable_guc + * Lots of rework will need to be done to integrate with DRM scheduler so + no need to nit pick everything in the code, it just should be + functional, no major coding style / layering errors, and not regress + execlists + * Update IGTs / selftests as needed to work with GuC submission + * Enable CI on supported platforms for a baseline + * Rework / get CI heathly for GuC submission in place as needed +* Merge new parallel submission uAPI + * Bonding uAPI completely incompatible with GuC submission, plus it has + severe design issues in general, which is why we want to retire it no + matter what + * New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step + which configures a slot with N contexts + * After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to + a slot in a single execbuf IOCTL and the batches run on the GPU in + paralllel + * Initially only for GuC submission but execlists can be supported if + needed +* Convert the i915 to use the DRM scheduler + * GuC submission backend fully integrated with DRM scheduler + * All request queues removed from backend (e.g. all backpressure + handled in DRM scheduler) + * Resets / cancels hook in DRM scheduler + * Watchdog hooks into DRM scheduler + * Lots of complexity of the GuC backend can be pulled out once + integrated with DRM scheduler (e.g. state machine gets + simplier, locking gets simplier, etc...) + * Execlists backend will minimum required to hook in the DRM scheduler + * Legacy interface + * Features like timeslicing / preemption / virtual engines would + be difficult to integrate with the DRM scheduler and these + features are not required for GuC submission as the GuC does + these things for us + * ROI low on fully integrating into DRM scheduler + * Fully integrating would add lots of complexity to DRM + scheduler + * Port i915 priority inheritance / boosting feature in DRM scheduler + * Used for i915 page flip, may be useful to other DRM drivers as + well + * Will be an optional feature in the DRM scheduler + * Remove in-order completion assumptions from DRM scheduler + * Even when using the DRM scheduler the backends will handle + preemption, timeslicing, etc... so it is possible for jobs to + finish out of order + * Pull out i915 priority levels and use DRM priority levels + * Optimize DRM scheduler as needed + +TODOs for GuC submission upstream += + +* Need an update to GuC firmware / i915 to enable error state capture +* Open source tool to decode GuC logs +* Public GuC spec + +New uAPI for basic GuC submission += +No major changes are required to the uAPI for basic GuC submission. The only +change is a new scheduler attribute: I915_SCHEDULER_CAP_STATIC_PRIORITY_MAP.
[Intel-gfx] [PATCH 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
Add entry for i915 new parallel submission uAPI plan.
v2:
(Daniel Vetter):
- Expand logical order explaination
- Add dummy header
- Only allow N BBs in execbuf IOCTL
- Configure parallel submission per slot not per gem context
v3:
(Marcin Ślusarz):
- Lot's of typos / bad english fixed
(Tvrtko Ursulin):
- Consistent pseudo code, clean up wording in descriptions
v4:
(Daniel Vetter)
- Drop flags
- Add kernel doc
- Reword a few things / fix typos
(Tvrtko)
- Reword a few things / fix typos
v5:
(Checkpatch)
- Fix typos
(Docs)
- Fix warning
Cc: Tvrtko Ursulin
Cc: Tony Ye
CC: Carl Zhang
Cc: Daniel Vetter
Cc: Jason Ekstrand
Signed-off-by: Matthew Brost
Acked-by: Daniel Vetter
Acked-by: Tony Ye
---
Documentation/gpu/rfc/i915_parallel_execbuf.h | 122 ++
Documentation/gpu/rfc/i915_scheduler.rst | 59 -
2 files changed, 180 insertions(+), 1 deletion(-)
create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
b/Documentation/gpu/rfc/i915_parallel_execbuf.h
new file mode 100644
index ..8cbe2c4e0172
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
@@ -0,0 +1,122 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2021 Intel Corporation
+ */
+
+#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
i915_context_engines_parallel_submit */
+
+/**
+ * struct drm_i915_context_engines_parallel_submit - Configure engine for
+ * parallel submission.
+ *
+ * Setup a slot in the context engine map to allow multiple BBs to be submitted
+ * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the
GPU
+ * in parallel. Multiple hardware contexts are created internally in the i915
+ * run these BBs. Once a slot is configured for N BBs only N BBs can be
+ * submitted in each execbuf IOCTL and this is implicit behavior e.g. The user
+ * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL knows how
+ * many BBs there are based on the slot's configuration. The N BBs are the last
+ * N buffer objects or first N if I915_EXEC_BATCH_FIRST is set.
+ *
+ * The default placement behavior is to create implicit bonds between each
+ * context if each context maps to more than 1 physical engine (e.g. context is
+ * a virtual engine). Also we only allow contexts of same engine class and
these
+ * contexts must be in logically contiguous order. Examples of the placement
+ * behavior described below. Lastly, the default is to not allow BBs to
+ * preempted mid BB rather insert coordinated preemption on all hardware
+ * contexts between each set of BBs. Flags may be added in the future to change
+ * both of these default behaviors.
+ *
+ * Returns -EINVAL if hardware context placement configuration is invalid or if
+ * the placement configuration isn't supported on the platform / submission
+ * interface.
+ * Returns -ENODEV if extension isn't supported on the platform / submission
+ * interface.
+ *
+ * .. code-block:: none
+ *
+ * Example 1 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=1,
+ * engines=CS[0],CS[1])
+ *
+ * Results in the following valid placement:
+ * CS[0], CS[1]
+ *
+ * Example 2 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ * engines=CS[0],CS[2],CS[1],CS[3])
+ *
+ * Results in the following valid placements:
+ * CS[0], CS[1]
+ * CS[2], CS[3]
+ *
+ * This can also be thought of as 2 virtual engines described by 2-D array
+ * in the engines the field with bonds placed between each index of the
+ * virtual engines. e.g. CS[0] is bonded to CS[1], CS[2] is bonded to
+ * CS[3].
+ * VE[0] = CS[0], CS[2]
+ * VE[1] = CS[1], CS[3]
+ *
+ * Example 3 pseudo code:
+ * CS[X] = generic engine of same class, logical instance X
+ * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
+ * set_engines(INVALID)
+ * set_parallel(engine_index=0, width=2, num_siblings=2,
+ * engines=CS[0],CS[1],CS[1],CS[3])
+ *
+ * Results in the following valid and invalid placements:
+ * CS[0], CS[1]
+ * CS[1], CS[3] - Not logical contiguous, return -EINVAL
+ */
+struct drm_i915_context_engines_parallel_submit {
+ /**
+* @base: base user extension.
+*/
+ struct i915_user_extension base;
+
+ /**
+* @engine_index: slot for parallel engine
+*/
+ __u16 engine_index;
+
+ /**
+* @width: number of contexts per parallel engine
+*/
+ __u16 width;
+
+
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave and Daniel, Here goes drm-intel-next-fixes-2021-06-29: The biggest fix is the restoration of mmap ioctl for gen12 integrated parts which lack was breaking ADL-P with media stack. Besides that a small selftest fix and a theoretical overflow on i915->pipe_to_crtc_mapping. Thanks, Rodrigo. The following changes since commit 1bd8a7dc28c1c410f1ceefae1f2a97c06d1a67c2: Merge tag 'exynos-drm-next-for-v5.14' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next (2021-06-11 14:19:12 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2021-06-29 for you to fetch changes up to c90c4c6574f3feaf2203b5671db1907a1e15c653: drm/i915: Reinstate the mmap ioctl for some platforms (2021-06-28 07:43:56 -0400) The biggest fix is the restoration of mmap ioctl for gen12 integrated parts which lack was breaking ADL-P with media stack. Besides that a small selftest fix and a theoretical overflow on i915->pipe_to_crtc_mapping. Chris Wilson (1): drm/i915/selftests: Reorder tasklet_disable vs local_bh_disable Jani Nikula (1): drm/i915/dsc: abstract helpers to get bigjoiner primary/secondary crtc Thomas Hellström (1): drm/i915: Reinstate the mmap ioctl for some platforms drivers/gpu/drm/i915/display/intel_display.c | 7 ++- drivers/gpu/drm/i915/display/intel_display_types.h | 8 drivers/gpu/drm/i915/display/intel_vdsc.c | 40 +++- drivers/gpu/drm/i915/display/intel_vdsc.h | 1 + drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 +-- drivers/gpu/drm/i915/gt/selftest_execlists.c | 55 +- 6 files changed, 76 insertions(+), 42 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Introduce a migrate interface (rev5)
== Series Details == Series: drm/i915/gem: Introduce a migrate interface (rev5) URL : https://patchwork.freedesktop.org/series/91890/ State : success == Summary == CI Bug Log - changes from CI_DRM_10289 -> Patchwork_20488 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/index.html New tests - New tests have been introduced between CI_DRM_10289 and Patchwork_20488: ### New IGT tests (1) ### * igt@i915_selftest@live@gem_migrate: - Statuses : 33 pass(s) - Exec time: [0.41, 5.40] s Known issues Here are the changes found in Patchwork_20488 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_basic@semaphore: - fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271]) +23 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/fi-bdw-5557u/igt@amdgpu/amd_ba...@semaphore.html * igt@core_hotunplug@unbind-rebind: - fi-bdw-5557u: NOTRUN -> [WARN][2] ([i915#2283]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/fi-bdw-5557u/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@hangcheck: - fi-snb-2600:NOTRUN -> [INCOMPLETE][3] ([i915#2782]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [PASS][4] -> [FAIL][5] ([i915#1372]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html Possible fixes * igt@i915_selftest@live@hugepages: - fi-snb-2600:[INCOMPLETE][6] -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-snb-2600/igt@i915_selftest@l...@hugepages.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/fi-snb-2600/igt@i915_selftest@l...@hugepages.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7500u: [DMESG-FAIL][8] ([i915#165]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#2283]: https://gitlab.freedesktop.org/drm/intel/issues/2283 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 Participating hosts (42 -> 37) -- Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600 fi-bdw-samus Build changes - * Linux: CI_DRM_10289 -> Patchwork_20488 CI-20190529: 20190529 CI_DRM_10289: b9081c2437cee8e573eeafcd19c816cc7e10f19d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6121: a63ceb48e6c3e733d04156b32fba3b4f4d5ad794 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20488: 94b313f6c0d29c7be21a8bb730b0de3ea3620b52 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 94b313f6c0d2 drm/i915/display: Migrate objects to LMEM if possible for display 7f6ae4d61ef2 drm/i915/gem: Introduce a selftest for the gem object migrate functionality e12a3001cec3 drm/i915/gem: Implement object migration == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20488/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/3] drm/i915/gem: Implement object migration
On Tue, 29 Jun 2021 at 16:50, Daniel Vetter wrote:
>
> On Tue, Jun 29, 2021 at 05:12:01PM +0200, Thomas Hellström wrote:
> > Introduce an interface to migrate objects between regions.
> > This is primarily intended to migrate objects to LMEM for display and
> > to SYSTEM for dma-buf, but might be reused in one form or another for
> > performance-based migration.
> >
> > v2:
> > - Verify that the memory region given as an id really exists.
> > (Reported by Matthew Auld)
> > - Call i915_gem_object_{init,release}_memory_region() when switching region
> > to handle also switching region lists. (Reported by Matthew Auld)
> > v3:
> > - Fix i915_gem_object_can_migrate() to return true if object is already in
> > the correct region, even if the object ops doesn't have a migrate()
> > callback.
> > - Update typo in commit message.
> > - Fix kerneldoc of i915_gem_object_wait_migration().
> > v4:
> > - Improve documentation (Suggested by Mattew Auld and Michael Ruhl)
> > - Always assume TTM migration hits a TTM move and unsets the pages through
> > move_notify. (Reported by Matthew Auld)
> > - Add a dma_fence_might_wait() annotation to
> > i915_gem_object_wait_migration() (Suggested by Daniel Vetter)
> > v5:
> > - Re-add might_sleep() instead of __dma_fence_might_wait(), Sent
> > v4 with the wrong version, didn't compile and __dma_fence_might_wait()
> > is not exported.
> > - Added an R-B.
>
> Bummer, I missed that.
>
> Matt, want to create an exported dma_fence_might_wait() which combines
> __dma_fence_might_wait() with might_sleep()? As a follow-up patch I think
> that'd be nice, we'll have a bunch of places that often don't sleep,
> except when we start to hit resource contention, so this helper might be
> useful.
Sure, I'll take a look.
> -Daniel
>
> >
> > Reported-by: kernel test robot
> > Signed-off-by: Thomas Hellström
> > Reviewed-by: Michael J. Ruhl
> > Reviewed-by: Matthew Auld
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_object.c| 112 ++
> > drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 ++
> > .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 77 ++--
> > drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19 +++
> > 5 files changed, 217 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index 07e8ff9a8aae..225b77fb4314 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -513,6 +513,118 @@ bool i915_gem_object_has_iomem(const struct
> > drm_i915_gem_object *obj)
> > return obj->mem_flags & I915_BO_FLAG_IOMEM;
> > }
> >
> > +/**
> > + * i915_gem_object_can_migrate - Whether an object likely can be migrated
> > + *
> > + * @obj: The object to migrate
> > + * @id: The region intended to migrate to
> > + *
> > + * Check whether the object backend supports migration to the
> > + * given region. Note that pinning may affect the ability to migrate as
> > + * returned by this function.
> > + *
> > + * This function is primarily intended as a helper for checking the
> > + * possibility to migrate objects and might be slightly less permissive
> > + * than i915_gem_object_migrate() when it comes to objects with the
> > + * I915_BO_ALLOC_USER flag set.
> > + *
> > + * Return: true if migration is possible, false otherwise.
> > + */
> > +bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
> > + enum intel_region_id id)
> > +{
> > + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> > + unsigned int num_allowed = obj->mm.n_placements;
> > + struct intel_memory_region *mr;
> > + unsigned int i;
> > +
> > + GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
> > + GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
> > +
> > + mr = i915->mm.regions[id];
> > + if (!mr)
> > + return false;
> > +
> > + if (obj->mm.region == mr)
> > + return true;
> > +
> > + if (!i915_gem_object_evictable(obj))
> > + return false;
> > +
> > + if (!obj->ops->migrate)
> > + return false;
> > +
> > + if (!(obj->flags & I915_BO_ALLOC_USER))
> > + return true;
> > +
> > + if (num_allowed == 0)
> > + return false;
> > +
> > + for (i = 0; i < num_allowed; ++i) {
> > + if (mr == obj->mm.placements[i])
> > + return true;
> > + }
> > +
> > + return false;
> > +}
> > +
> > +/**
> > + * i915_gem_object_migrate - Migrate an object to the desired region id
> > + * @obj: The object to migrate.
> > + * @ww: An optional struct i915_gem_ww_ctx. If NULL, the backend may
> > + * not be successful in evicting other objects to make room for this
> > object.
> > + * @id: The region id to migrate to.
> > + *
> > + * Attempt to migrate the object to the desired memory region. The
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gem: Introduce a migrate interface (rev5)
== Series Details == Series: drm/i915/gem: Introduce a migrate interface (rev5) URL : https://patchwork.freedesktop.org/series/91890/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +drivers/gpu/drm/i915/selftests/i915_syncmap.c:80:54: warning: dubious: x | !y ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Introduce a migrate interface (rev5)
== Series Details == Series: drm/i915/gem: Introduce a migrate interface (rev5) URL : https://patchwork.freedesktop.org/series/91890/ State : warning == Summary == $ dim checkpatch origin/drm-tip e12a3001cec3 drm/i915/gem: Implement object migration 7f6ae4d61ef2 drm/i915/gem: Introduce a selftest for the gem object migrate functionality -:39: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #39: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 272 lines checked 94b313f6c0d2 drm/i915/display: Migrate objects to LMEM if possible for display ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/aperture: Pass DRM driver structure instead of driver name
== Series Details == Series: drm/aperture: Pass DRM driver structure instead of driver name URL : https://patchwork.freedesktop.org/series/92015/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10287_full -> Patchwork_20486_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20486_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20486_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20486_full: ### IGT changes ### Possible regressions * igt@gem_mmap_gtt@basic-small-bo-tiledy: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-iclb8/igt@gem_mmap_...@basic-small-bo-tiledy.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-iclb3/igt@gem_mmap_...@basic-small-bo-tiledy.html Warnings * igt@runner@aborted: - shard-iclb: ([FAIL][3], [FAIL][4], [FAIL][5]) ([i915#3002]) -> ([FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11]) ([i915#1814] / [i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-iclb3/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-iclb3/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-iclb8/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-iclb4/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-iclb6/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-iclb1/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-iclb6/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-iclb6/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-iclb1/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_20486_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1099]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][13] -> [TIMEOUT][14] ([i915#2369] / [i915#3063]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-tglb6/igt@gem_...@unwedge-stress.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-tglb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][17] -> [FAIL][18] ([i915#2842]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([i915#180]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-kbl3/igt@gem_exec_susp...@basic-s3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-kbl1/igt@gem_exec_susp...@basic-s3.html * igt@gem_mmap_gtt@cpuset-basic-small-copy-xy: - shard-skl: [PASS][21] -> [FAIL][22] ([i915#307]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-skl9/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-skl2/igt@gem_mmap_...@cpuset-basic-small-copy-xy.html * igt@gem_mmap_gtt@cpuset-big-copy-xy: - shard-iclb: [PASS][23] -> [FAIL][24] ([i915#307]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/shard-iclb1/igt@gem_mmap_...@cpuset-big-copy-xy.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy-xy.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][25] ([i915#2658]) [25]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: address potential UAF bugs with drm_master ptrs (rev2)
== Series Details ==
Series: drm: address potential UAF bugs with drm_master ptrs (rev2)
URL : https://patchwork.freedesktop.org/series/91969/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10289 -> Patchwork_20487
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20487:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-dg1-1}: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-dg1-1/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_20487 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-cml-s: [PASS][2] -> [DMESG-WARN][3] ([i915#3660])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-cml-s/igt@debugfs_test@read_all_entries.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-cml-s/igt@debugfs_test@read_all_entries.html
- fi-elk-e7500: [PASS][4] -> [DMESG-WARN][5] ([i915#3660])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-elk-e7500/igt@debugfs_test@read_all_entries.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-elk-e7500/igt@debugfs_test@read_all_entries.html
- fi-glk-dsi: [PASS][6] -> [DMESG-WARN][7] ([i915#3660])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-glk-dsi/igt@debugfs_test@read_all_entries.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-glk-dsi/igt@debugfs_test@read_all_entries.html
- fi-ivb-3770:[PASS][8] -> [DMESG-WARN][9] ([i915#3660])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-ivb-3770/igt@debugfs_test@read_all_entries.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-ivb-3770/igt@debugfs_test@read_all_entries.html
- fi-snb-2600:[PASS][10] -> [DMESG-WARN][11] ([i915#3660])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-snb-2600/igt@debugfs_test@read_all_entries.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-snb-2600/igt@debugfs_test@read_all_entries.html
- fi-tgl-y: [PASS][12] -> [DMESG-WARN][13] ([i915#3660])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-tgl-y/igt@debugfs_test@read_all_entries.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-tgl-y/igt@debugfs_test@read_all_entries.html
- fi-kbl-guc: [PASS][14] -> [DMESG-WARN][15] ([i915#262] /
[i915#3660])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-kbl-guc/igt@debugfs_test@read_all_entries.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-kbl-guc/igt@debugfs_test@read_all_entries.html
- fi-bdw-gvtdvm: [PASS][16] -> [DMESG-WARN][17] ([i915#3660])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-bdw-gvtdvm/igt@debugfs_test@read_all_entries.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-bdw-gvtdvm/igt@debugfs_test@read_all_entries.html
- fi-bsw-kefka: [PASS][18] -> [DMESG-WARN][19] ([i915#3660])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-bsw-kefka/igt@debugfs_test@read_all_entries.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-bsw-kefka/igt@debugfs_test@read_all_entries.html
- fi-kbl-7500u: [PASS][20] -> [DMESG-WARN][21] ([i915#262] /
[i915#3660])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-kbl-7500u/igt@debugfs_test@read_all_entries.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-kbl-7500u/igt@debugfs_test@read_all_entries.html
- fi-bwr-2160:[PASS][22] -> [DMESG-WARN][23] ([i915#3660])
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-bwr-2160/igt@debugfs_test@read_all_entries.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-bwr-2160/igt@debugfs_test@read_all_entries.html
- fi-bdw-5557u: [PASS][24] -> [DMESG-WARN][25] ([i915#3660])
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-bdw-5557u/igt@debugfs_test@read_all_entries.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20487/fi-bdw-5557u/igt@debugfs_test@read_all_entries.html
- fi-kbl-r: [PASS][26] -> [DMESG-WARN][27] ([i915#262] /
[i915#3660])
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10289/fi-kbl-r/igt@debugfs_test@read_all_entries.html
[27]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm: address potential UAF bugs with drm_master ptrs (rev2)
== Series Details == Series: drm: address potential UAF bugs with drm_master ptrs (rev2) URL : https://patchwork.freedesktop.org/series/91969/ State : warning == Summary == $ dim checkpatch origin/drm-tip 74cef89ae027 drm: avoid circular locks in drm_mode_getconnector cb2470da87f5 drm: add a locked version of drm_is_current_master 5c1685ef444e drm: protect drm_master pointers in drm_lease.c -:94: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!master" #94: FILE: drivers/gpu/drm/drm_lease.c:116: + if (master == NULL) -:113: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!master" #113: FILE: drivers/gpu/drm/drm_lease.c:144: + if (master == NULL) -:136: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!master" #136: FILE: drivers/gpu/drm/drm_lease.c:177: + if (master == NULL) total: 0 errors, 0 warnings, 3 checks, 269 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/aperture: Pass DRM driver structure instead of driver name
Hi, On 29/06/2021 15:58, Thomas Zimmermann wrote: > Print the name of the DRM driver when taking over fbdev devices. Makes > the output to dmesg more consistent. Note that the driver name is only > used for printing a string to the kernel log. No UAPI is affected by this > change. > > Signed-off-by: Thomas Zimmermann > --- ... > drivers/gpu/drm/meson/meson_drv.c | 2 +- Acked-by: Neil Armstrong ... > > diff --git a/drivers/gpu/drm/meson/meson_drv.c > b/drivers/gpu/drm/meson/meson_drv.c > index a7388bf7c838..3d0ccc7eef1b 100644 > --- a/drivers/gpu/drm/meson/meson_drv.c > +++ b/drivers/gpu/drm/meson/meson_drv.c > @@ -285,7 +285,7 @@ static int meson_drv_bind_master(struct device *dev, bool > has_components) >* Remove early framebuffers (ie. simplefb). The framebuffer can be >* located anywhere in RAM >*/ > - ret = drm_aperture_remove_framebuffers(false, "meson-drm-fb"); > + ret = drm_aperture_remove_framebuffers(false, _driver); > if (ret) > goto free_drm; > ... ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop all references to DRM IRQ midlayer
On Tue, Jun 29, 2021 at 6:11 PM Ville Syrjälä
wrote:
>
> On Fri, Jun 25, 2021 at 10:47:40AM +0200, Thomas Zimmermann wrote:
> > Remove all references to DRM's IRQ midlayer.
> >
> > The code in xcs_resume() probably didn't work as intended. It uses
> > struct drm_device.irq, which is allocated to 0, but never initialized
> > by i915 to the device's interrupt number.
> >
> > Signed-off-by: Thomas Zimmermann
> > Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume,
> > again")
> > Cc: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Daniel Vetter
> > Cc: Rodrigo Vivi
> > Cc: Joonas Lahtinen
> > Cc: Maarten Lankhorst
> > Cc: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/gt/intel_ring_submission.c | 3 ++-
> > drivers/gpu/drm/i915/i915_drv.c | 1 -
> > drivers/gpu/drm/i915/i915_irq.c | 1 -
> > 3 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > index 5d42a12ef3d6..d893aaaed74f 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> > @@ -180,12 +180,13 @@ static bool stop_ring(struct intel_engine_cs *engine)
> > static int xcs_resume(struct intel_engine_cs *engine)
> > {
> > struct intel_ring *ring = engine->legacy.ring;
> > + struct pci_dev *pdev = to_pci_dev(engine->i915->drm.dev);
> >
> > ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",
> >ring->head, ring->tail);
> >
> > /* Double check the ring is empty & disabled before we resume */
> > - synchronize_hardirq(engine->i915->drm.irq);
> > + synchronize_hardirq(pdev->irq);
>
> We have intel_synchronize_irq() to hide all these mundane details.
> Might want to add a matching intel_synchronize_hardirq().
Hm I wonder whether we shouldn't just use the normal synchronize_irq()
here. We don't have a threaded irq handler, and this should be called
from process context. intel-gfx-ci will catch if I'm wrong :-)
-Daniel
>
> > if (!stop_ring(engine))
> > goto err;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index 850b499c71c8..73de45472f60 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -42,7 +42,6 @@
> > #include
> > #include
> > #include
> > -#include
> > #include
> > #include
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index a11bdb667241..eef616d96f12 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -33,7 +33,6 @@
> > #include
> >
> > #include
> > -#include
> >
> > #include "display/intel_de.h"
> > #include "display/intel_display_types.h"
> >
> > base-commit: 8c1323b422f8473421682ba783b5949ddd89a3f4
> > prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
> > prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
> > --
> > 2.32.0
>
> --
> Ville Syrjälä
> Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Drop all references to DRM IRQ midlayer
On Fri, Jun 25, 2021 at 10:47:40AM +0200, Thomas Zimmermann wrote:
> Remove all references to DRM's IRQ midlayer.
>
> The code in xcs_resume() probably didn't work as intended. It uses
> struct drm_device.irq, which is allocated to 0, but never initialized
> by i915 to the device's interrupt number.
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 536f77b1caa0 ("drm/i915/gt: Call stop_ring() from ring resume, again")
> Cc: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Daniel Vetter
> Cc: Rodrigo Vivi
> Cc: Joonas Lahtinen
> Cc: Maarten Lankhorst
> Cc: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gt/intel_ring_submission.c | 3 ++-
> drivers/gpu/drm/i915/i915_drv.c | 1 -
> drivers/gpu/drm/i915/i915_irq.c | 1 -
> 3 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> index 5d42a12ef3d6..d893aaaed74f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ring_submission.c
> @@ -180,12 +180,13 @@ static bool stop_ring(struct intel_engine_cs *engine)
> static int xcs_resume(struct intel_engine_cs *engine)
> {
> struct intel_ring *ring = engine->legacy.ring;
> + struct pci_dev *pdev = to_pci_dev(engine->i915->drm.dev);
>
> ENGINE_TRACE(engine, "ring:{HEAD:%04x, TAIL:%04x}\n",
>ring->head, ring->tail);
>
> /* Double check the ring is empty & disabled before we resume */
> - synchronize_hardirq(engine->i915->drm.irq);
> + synchronize_hardirq(pdev->irq);
We have intel_synchronize_irq() to hide all these mundane details.
Might want to add a matching intel_synchronize_hardirq().
> if (!stop_ring(engine))
> goto err;
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 850b499c71c8..73de45472f60 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -42,7 +42,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index a11bdb667241..eef616d96f12 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -33,7 +33,6 @@
> #include
>
> #include
> -#include
>
> #include "display/intel_de.h"
> #include "display/intel_display_types.h"
>
> base-commit: 8c1323b422f8473421682ba783b5949ddd89a3f4
> prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d
> prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24
> --
> 2.32.0
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/3] drm: protect drm_master pointers in drm_lease.c
On Tue, Jun 29, 2021 at 11:37:06AM +0800, Desmond Cheong Zhi Xi wrote:
> Currently, direct copies of drm_file->master pointers should be
> protected by drm_device.master_mutex when being dereferenced. This is
> because drm_file->master is not invariant for the lifetime of
> drm_file. If drm_file is not the creator of master, then
> drm_file->is_master is false, and a call to drm_setmaster_ioctl will
> invoke drm_new_set_master, which then allocates a new master for
> drm_file and puts the old master.
>
> Thus, without holding drm_device.master_mutex, the old value of
> drm_file->master could be freed while it is being used by another
> concurrent process.
>
> In drm_lease.c, there are multiple instances where drm_file->master is
> accessed and dereferenced while drm_device.master_mutex is not
> held. This makes drm_lease.c vulnerable to use-after-free bugs.
>
> We address this issue in 3 ways:
>
> 1. Clarify in the kerneldoc that drm_file->master is protected by
> drm_device.master_mutex.
>
> 2. Add a new drm_file_get_master() function that calls drm_master_get
> on drm_file->master while holding on to drm_device.master_mutex. Since
> drm_master_get increments the reference count of master, this
> prevents master from being freed until we unreference it with
> drm_master_put.
>
> 3. In each case where drm_file->master is directly accessed and
> eventually dereferenced in drm_lease.c, we wrap the access in a call
> to the new drm_file_get_master function, then unreference the master
> pointer once we are done using it.
>
> Reported-by: Daniel Vetter
> Signed-off-by: Desmond Cheong Zhi Xi
Series looks very nice, let's see what intel-gfx-ci says. You should get a
mail, but results are also here:
https://patchwork.freedesktop.org/series/91969/#rev2
One tiny comment below.
> ---
> drivers/gpu/drm/drm_auth.c | 25
> drivers/gpu/drm/drm_lease.c | 77 +++--
> include/drm/drm_auth.h | 1 +
> include/drm/drm_file.h | 15 ++--
> 4 files changed, 95 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index ab1863c5a5a0..c36a0b72be26 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -384,6 +384,31 @@ struct drm_master *drm_master_get(struct drm_master
> *master)
> }
> EXPORT_SYMBOL(drm_master_get);
>
> +/**
> + * drm_file_get_master - reference _file.master of @file_priv
> + * @file_priv: DRM file private
> + *
> + * Increments the reference count of @file_priv's _file.master and
> returns
> + * the _file.master. If @file_priv has no _file.master, returns NULL.
> + *
> + * Master pointers returned from this function should be unreferenced using
> + * drm_master_put().
> + */
> +struct drm_master *drm_file_get_master(struct drm_file *file_priv)
> +{
> + struct drm_master *master = NULL;
> +
> + mutex_lock(_priv->minor->dev->master_mutex);
> + if (!file_priv->master)
> + goto unlock;
> + master = drm_master_get(file_priv->master);
> +
> +unlock:
> + mutex_unlock(_priv->minor->dev->master_mutex);
> + return master;
> +}
> +EXPORT_SYMBOL(drm_file_get_master);
> +
> static void drm_master_destroy(struct kref *kref)
> {
> struct drm_master *master = container_of(kref, struct drm_master,
> refcount);
> diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
> index 00fb433bcef1..cdcc87fa9685 100644
> --- a/drivers/gpu/drm/drm_lease.c
> +++ b/drivers/gpu/drm/drm_lease.c
> @@ -106,10 +106,19 @@ static bool _drm_has_leased(struct drm_master *master,
> int id)
> */
> bool _drm_lease_held(struct drm_file *file_priv, int id)
> {
> - if (!file_priv || !file_priv->master)
> + bool ret;
> + struct drm_master *master;
> +
> + if (!file_priv)
> return true;
>
> - return _drm_lease_held_master(file_priv->master, id);
> + master = drm_file_get_master(file_priv);
> + if (master == NULL)
> + return true;
> + ret = _drm_lease_held_master(master, id);
> + drm_master_put();
> +
> + return ret;
> }
>
> /**
> @@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
> struct drm_master *master;
> bool ret;
>
> - if (!file_priv || !file_priv->master || !file_priv->master->lessor)
> + if (!file_priv)
> return true;
>
> - master = file_priv->master;
> + master = drm_file_get_master(file_priv);
> + if (master == NULL)
> + return true;
> + if (!master->lessor) {
> + drm_master_put();
> + return true;
> + }
> mutex_lock(>dev->mode_config.idr_mutex);
> ret = _drm_lease_held_master(master, id);
> mutex_unlock(>dev->mode_config.idr_mutex);
> + drm_master_put();
> return ret;
> }
>
> @@ -154,10 +170,16 @@ uint32_t drm_lease_filter_crtcs(struct drm_file
> *file_priv, uint32_t crtcs_in)
> int count_in,
Re: [Intel-gfx] [PATCH] drm/aperture: Pass DRM driver structure instead of driver name
On Tue, Jun 29, 2021 at 9:58 PM Thomas Zimmermann wrote: > > Print the name of the DRM driver when taking over fbdev devices. Makes > the output to dmesg more consistent. Note that the driver name is only > used for printing a string to the kernel log. No UAPI is affected by this > change. > > Signed-off-by: Thomas Zimmermann > --- > drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +- Acked-by: Chen-Yu Tsai ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/display: replace boilerplate code with helper macros
On Sat, Jun 26, 2021 at 03:32:27AM -0400, Hamza Mahfooz wrote:
> As per commit 22be87401289 ("drm: TODO: Add DRM_MODESET_LOCK_ALL*
> conversion to todo.rst"),
> drm_modeset_lock_all()/drm_modeset_unlock_all() and boilerplate code
> surrounding instances of drm_modeset_lock_all_ctx() with a local acquire
> context should be replaced with the relevant helper macros.
>
> Signed-off-by: Hamza Mahfooz
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 20 +++-
> 1 file changed, 7 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 64e9107d70f7..e8cb2881d2b4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include "drm/drm_modeset_lock.h"
> #include
> #include
> #include
> @@ -11836,6 +11837,7 @@ int intel_modeset_init_nogem(struct drm_i915_private
> *i915)
> struct drm_device *dev = >drm;
> enum pipe pipe;
> struct intel_crtc *crtc;
> + struct drm_modeset_acquire_ctx ctx;
> int ret;
>
> intel_init_pm(i915);
> @@ -11884,9 +11886,9 @@ int intel_modeset_init_nogem(struct drm_i915_private
> *i915)
> intel_vga_disable(i915);
> intel_setup_outputs(i915);
>
> - drm_modeset_lock_all(dev);
> + DRM_MODESET_LOCK_ALL_BEGIN(dev, ctx, 0, ret);
> intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
> - drm_modeset_unlock_all(dev);
> + DRM_MODESET_LOCK_ALL_END(dev, ctx, ret);
That looks wrong. You're using a private ctx here, but still
passing dev->mode_config.acquire_ctx to the lower level stuff.
Also DRM_MODESET_LOCK_ALL_{BEGIN,END}() do not seem to be
equivalent to drm_modeset_{lock,unlock}_all() when it comes to
mode_config.mutex. So would need a proper review whether we
actually need that lock or not.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 1/3] drm/i915/gem: Implement object migration
On Tue, Jun 29, 2021 at 05:12:01PM +0200, Thomas Hellström wrote:
> Introduce an interface to migrate objects between regions.
> This is primarily intended to migrate objects to LMEM for display and
> to SYSTEM for dma-buf, but might be reused in one form or another for
> performance-based migration.
>
> v2:
> - Verify that the memory region given as an id really exists.
> (Reported by Matthew Auld)
> - Call i915_gem_object_{init,release}_memory_region() when switching region
> to handle also switching region lists. (Reported by Matthew Auld)
> v3:
> - Fix i915_gem_object_can_migrate() to return true if object is already in
> the correct region, even if the object ops doesn't have a migrate()
> callback.
> - Update typo in commit message.
> - Fix kerneldoc of i915_gem_object_wait_migration().
> v4:
> - Improve documentation (Suggested by Mattew Auld and Michael Ruhl)
> - Always assume TTM migration hits a TTM move and unsets the pages through
> move_notify. (Reported by Matthew Auld)
> - Add a dma_fence_might_wait() annotation to
> i915_gem_object_wait_migration() (Suggested by Daniel Vetter)
> v5:
> - Re-add might_sleep() instead of __dma_fence_might_wait(), Sent
> v4 with the wrong version, didn't compile and __dma_fence_might_wait()
> is not exported.
> - Added an R-B.
Bummer, I missed that.
Matt, want to create an exported dma_fence_might_wait() which combines
__dma_fence_might_wait() with might_sleep()? As a follow-up patch I think
that'd be nice, we'll have a bunch of places that often don't sleep,
except when we start to hit resource contention, so this helper might be
useful.
-Daniel
>
> Reported-by: kernel test robot
> Signed-off-by: Thomas Hellström
> Reviewed-by: Michael J. Ruhl
> Reviewed-by: Matthew Auld
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 112 ++
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 ++
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 77 ++--
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19 +++
> 5 files changed, 217 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 07e8ff9a8aae..225b77fb4314 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -513,6 +513,118 @@ bool i915_gem_object_has_iomem(const struct
> drm_i915_gem_object *obj)
> return obj->mem_flags & I915_BO_FLAG_IOMEM;
> }
>
> +/**
> + * i915_gem_object_can_migrate - Whether an object likely can be migrated
> + *
> + * @obj: The object to migrate
> + * @id: The region intended to migrate to
> + *
> + * Check whether the object backend supports migration to the
> + * given region. Note that pinning may affect the ability to migrate as
> + * returned by this function.
> + *
> + * This function is primarily intended as a helper for checking the
> + * possibility to migrate objects and might be slightly less permissive
> + * than i915_gem_object_migrate() when it comes to objects with the
> + * I915_BO_ALLOC_USER flag set.
> + *
> + * Return: true if migration is possible, false otherwise.
> + */
> +bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
> + enum intel_region_id id)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + unsigned int num_allowed = obj->mm.n_placements;
> + struct intel_memory_region *mr;
> + unsigned int i;
> +
> + GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
> + GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
> +
> + mr = i915->mm.regions[id];
> + if (!mr)
> + return false;
> +
> + if (obj->mm.region == mr)
> + return true;
> +
> + if (!i915_gem_object_evictable(obj))
> + return false;
> +
> + if (!obj->ops->migrate)
> + return false;
> +
> + if (!(obj->flags & I915_BO_ALLOC_USER))
> + return true;
> +
> + if (num_allowed == 0)
> + return false;
> +
> + for (i = 0; i < num_allowed; ++i) {
> + if (mr == obj->mm.placements[i])
> + return true;
> + }
> +
> + return false;
> +}
> +
> +/**
> + * i915_gem_object_migrate - Migrate an object to the desired region id
> + * @obj: The object to migrate.
> + * @ww: An optional struct i915_gem_ww_ctx. If NULL, the backend may
> + * not be successful in evicting other objects to make room for this object.
> + * @id: The region id to migrate to.
> + *
> + * Attempt to migrate the object to the desired memory region. The
> + * object backend must support migration and the object may not be
> + * pinned, (explicitly pinned pages or pinned vmas). The object must
> + * be locked.
> + * On successful completion, the object will have pages pointing to
> + * memory in the new region, but an async migration task may not have
> + * completed yet,
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/aperture: Pass DRM driver structure instead of driver name
== Series Details ==
Series: drm/aperture: Pass DRM driver structure instead of driver name
URL : https://patchwork.freedesktop.org/series/92015/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10287 -> Patchwork_20486
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/index.html
Known issues
Here are the changes found in Patchwork_20486 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-gfx:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +11 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-kbl-soraka/igt@amdgpu/amd_ba...@cs-gfx.html
* igt@amdgpu/amd_basic@semaphore:
- fi-icl-y: NOTRUN -> [SKIP][2] ([fdo#109315]) +17 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-icl-y/igt@amdgpu/amd_ba...@semaphore.html
* igt@gem_huc_copy@huc-copy:
- fi-icl-y: NOTRUN -> [SKIP][3] ([i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-icl-y/igt@gem_huc_c...@huc-copy.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [PASS][4] -> [FAIL][5] ([i915#3449])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- fi-icl-y: NOTRUN -> [SKIP][6] ([fdo#109284] / [fdo#111827]) +8
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-icl-y/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-y: NOTRUN -> [SKIP][7] ([fdo#109285])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-icl-y/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-icl-y: NOTRUN -> [SKIP][8] ([fdo#109278])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-icl-y/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
* igt@kms_psr@primary_mmap_gtt:
- fi-icl-y: NOTRUN -> [SKIP][9] ([fdo#110189]) +3 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-icl-y/igt@kms_psr@primary_mmap_gtt.html
* igt@prime_vgem@basic-userptr:
- fi-icl-y: NOTRUN -> [SKIP][10] ([i915#3301])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-icl-y/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- {fi-tgl-1115g4}:[FAIL][11] ([i915#1888]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10287/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/fi-tgl-1115g4/igt@gem_exec_susp...@basic-s3.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109284]: https://bugs.freedesktop.org/show_bug.cgi?id=109284
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1888]: https://gitlab.freedesktop.org/drm/intel/issues/1888
[i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3449]: https://gitlab.freedesktop.org/drm/intel/issues/3449
Participating hosts (41 -> 37)
--
Additional (1): fi-icl-y
Missing(5): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-ctg-p8600
fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10287 -> Patchwork_20486
CI-20190529: 20190529
CI_DRM_10287: b6886aad3645be843b71bc508110ab7f974fd41d @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6121: a63ceb48e6c3e733d04156b32fba3b4f4d5ad794 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20486: bdaa421adb1693aae2d9a3e9f8e0aa2d740b65c6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
bdaa421adb16 drm/aperture: Pass DRM driver structure instead of driver name
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20486/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/jsl: Remove require_force_probe protection
On Tue, Jun 29, 2021 at 11:17:55AM -0400, Rodrigo Vivi wrote:
> On Tue, Jun 29, 2021 at 04:23:56PM +0530, Tejas Upadhyay wrote:
> > Removing force probe protection from JSL platform. Did
> > not observe warnings, errors, flickering or any visual
> > defects while doing ordinary tasks like browsing and
> > editing documents in a two monitor setup.
> >
> > For more info drm-tip idle run results :
> > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?
> >
> > Cc: Chris Wilson
> > Signed-off-by: Tejas Upadhyay
>
> Reviewed-by: Rodrigo Vivi
and pushed
thanks for the patch
>
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index f1f43192f9fb..bc3c14ce92f7 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -853,7 +853,6 @@ static const struct intel_device_info ehl_info = {
> > static const struct intel_device_info jsl_info = {
> > GEN11_FEATURES,
> > PLATFORM(INTEL_JASPERLAKE),
> > - .require_force_probe = 1,
> > .platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0),
> > .ppgtt_size = 36,
> > };
> > --
> > 2.31.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
On Tue, Jun 29, 2021 at 11:18:09AM -0400, Rodrigo Vivi wrote:
> On Tue, Jun 29, 2021 at 04:19:54PM +0530, Tejas Upadhyay wrote:
> > Removing force probe protection from EHL platform. Did
> > not observe warnings, errors, flickering or any visual
> > defects while doing ordinary tasks like browsing and
> > editing documents in a two monitor setup.
> >
> > For more info drm-tip idle run results :
> > https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?
> >
> > Cc: Chris Wilson
> > Signed-off-by: Tejas Upadhyay
>
> Reviewed-by: Rodrigo Vivi
and pushed...
thanks for the patch
>
> > ---
> > drivers/gpu/drm/i915/i915_pci.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index f1f43192f9fb..7d472611a190 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -845,7 +845,6 @@ static const struct intel_device_info icl_info = {
> > static const struct intel_device_info ehl_info = {
> > GEN11_FEATURES,
> > PLATFORM(INTEL_ELKHARTLAKE),
> > - .require_force_probe = 1,
> > .platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0),
> > .ppgtt_size = 36,
> > };
> > --
> > 2.31.1
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/jsl: Remove require_force_probe protection
On Tue, Jun 29, 2021 at 04:23:56PM +0530, Tejas Upadhyay wrote:
> Removing force probe protection from JSL platform. Did
> not observe warnings, errors, flickering or any visual
> defects while doing ordinary tasks like browsing and
> editing documents in a two monitor setup.
>
> For more info drm-tip idle run results :
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?
>
> Cc: Chris Wilson
> Signed-off-by: Tejas Upadhyay
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f1f43192f9fb..bc3c14ce92f7 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -853,7 +853,6 @@ static const struct intel_device_info ehl_info = {
> static const struct intel_device_info jsl_info = {
> GEN11_FEATURES,
> PLATFORM(INTEL_JASPERLAKE),
> - .require_force_probe = 1,
> .platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0),
> .ppgtt_size = 36,
> };
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
On Tue, Jun 29, 2021 at 04:19:54PM +0530, Tejas Upadhyay wrote:
> Removing force probe protection from EHL platform. Did
> not observe warnings, errors, flickering or any visual
> defects while doing ordinary tasks like browsing and
> editing documents in a two monitor setup.
>
> For more info drm-tip idle run results :
> https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?
>
> Cc: Chris Wilson
> Signed-off-by: Tejas Upadhyay
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index f1f43192f9fb..7d472611a190 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -845,7 +845,6 @@ static const struct intel_device_info icl_info = {
> static const struct intel_device_info ehl_info = {
> GEN11_FEATURES,
> PLATFORM(INTEL_ELKHARTLAKE),
> - .require_force_probe = 1,
> .platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0),
> .ppgtt_size = 36,
> };
> --
> 2.31.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 3/3] drm/i915/display: Migrate objects to LMEM if possible for display
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 21
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 --
4 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index eec6c9e9cda7..026c28c612f0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1331,6 +1331,9 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
ret = i915_gem_object_lock(obj, );
if (!ret && phys_cursor)
ret = i915_gem_object_attach_phys(obj, alignment);
+ else if (!ret && HAS_LMEM(dev_priv))
+ ret = i915_gem_object_migrate(obj, , INTEL_REGION_LMEM);
+ /* TODO: Do we need to sync when migration becomes async? */
if (!ret)
ret = i915_gem_object_pin_pages(obj);
if (ret)
@@ -11778,7 +11781,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
/* object is backed with LMEM for discrete */
i915 = to_i915(obj->base.dev);
- if (HAS_LMEM(i915) && !i915_gem_object_validates_to_lmem(obj)) {
+ if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj,
INTEL_REGION_LMEM)) {
/* object is "remote", not in local memory */
i915_gem_object_put(obj);
return ERR_PTR(-EREMOTE);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 073822100da7..7d1400b13429 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -375,7 +375,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
struct i915_vma *vma;
int ret;
- /* Frame buffer must be in LMEM (no migration yet) */
+ /* Frame buffer must be in LMEM */
if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj))
return ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 41d5182cd367..be1d122574af 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -23,27 +23,6 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
return io_mapping_map_wc(>mm.region->iomap, offset, size);
}
-/**
- * i915_gem_object_validates_to_lmem - Whether the object is resident in
- * lmem when pages are present.
- * @obj: The object to check.
- *
- * Migratable objects residency may change from under us if the object is
- * not pinned or locked. This function is intended to be used to check whether
- * the object can only reside in lmem when pages are present.
- *
- * Return: Whether the object is always resident in lmem when pages are
- * present.
- */
-bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj)
-{
- struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
-
- return !i915_gem_object_migratable(obj) &&
- mr && (mr->type == INTEL_MEMORY_LOCAL ||
- mr->type == INTEL_MEMORY_STOLEN_LOCAL);
-}
-
/**
* i915_gem_object_is_lmem - Whether the object is resident in
* lmem
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 8cbd7a5334e2..d423d8cac4f2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -597,8 +597,6 @@ bool i915_gem_object_evictable(struct drm_i915_gem_object
*obj);
bool i915_gem_object_migratable(struct drm_i915_gem_object *obj);
-bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj);
-
int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
struct i915_gem_ww_ctx *ww,
enum intel_region_id id);
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 2/3] drm/i915/gem: Introduce a selftest for the gem object migrate functionality
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
v4:
- Initialize buffers and check contents after migration
(Suggested by Matthew Auld)
- Perform async migration (if implemented) in the igt_lmem_pages_migrate
test
- Test also migration to the current region.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Matthew Auld
Reviewed-by: Michael J. Ruhl #v3
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
.../drm/i915/gem/selftests/i915_gem_migrate.c | 258 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
3 files changed, 260 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 225b77fb4314..547cc9dad90d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -665,6 +665,7 @@ static const struct drm_gem_object_funcs
i915_gem_object_funcs = {
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/huge_gem_object.c"
#include "selftests/huge_pages.c"
+#include "selftests/i915_gem_migrate.c"
#include "selftests/i915_gem_object.c"
#include "selftests/i915_gem_coherency.c"
#endif
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
new file mode 100644
index ..ced6e3a814a2
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020-2021 Intel Corporation
+ */
+
+#include "gt/intel_migrate.h"
+
+static int igt_fill_check_buffer(struct drm_i915_gem_object *obj,
+bool fill)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ unsigned int i, count = obj->base.size / sizeof(u32);
+ enum i915_map_type map_type =
+ i915_coherent_map_type(i915, obj, false);
+ u32 *cur;
+ int err = 0;
+
+ assert_object_held(obj);
+ cur = i915_gem_object_pin_map(obj, map_type);
+ if (IS_ERR(cur))
+ return PTR_ERR(cur);
+
+ if (fill)
+ for (i = 0; i < count; ++i)
+ *cur++ = i;
+ else
+ for (i = 0; i < count; ++i)
+ if (*cur++ != i) {
+ pr_err("Object content mismatch at location %d
of %d\n", i, count);
+ err = -EINVAL;
+ break;
+ }
+
+ i915_gem_object_unpin_map(obj);
+
+ return err;
+}
+
+static int igt_create_migrate(struct intel_gt *gt, enum intel_region_id src,
+ enum intel_region_id dst)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_memory_region *src_mr = i915->mm.regions[src];
+ struct drm_i915_gem_object *obj;
+ struct i915_gem_ww_ctx ww;
+ int err = 0;
+
+ GEM_BUG_ON(!src_mr);
+
+ /* Switch object backing-store on create */
+ obj = i915_gem_object_create_region(src_mr, PAGE_SIZE, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ for_i915_gem_ww(, err, true) {
+ err = i915_gem_object_lock(obj, );
+ if (err)
+ continue;
+
+ err = igt_fill_check_buffer(obj, true);
+ if (err)
+ continue;
+
+ if (!i915_gem_object_can_migrate(obj, dst)) {
+ err = -EINVAL;
+ continue;
+ }
+
+ err = i915_gem_object_migrate(obj, , dst);
+ if (err)
+ continue;
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ continue;
+
+ if (i915_gem_object_can_migrate(obj, src))
+ err = -EINVAL;
+
+ i915_gem_object_unpin_pages(obj);
+ err = i915_gem_object_wait_migration(obj, true);
+ if (err)
+ continue;
+
+ err = igt_fill_check_buffer(obj, false);
+ }
+ i915_gem_object_put(obj);
+
+ return err;
+}
+
+static int igt_smem_create_migrate(void *arg)
+{
+ return igt_create_migrate(arg, INTEL_REGION_LMEM, INTEL_REGION_SMEM);
+}
+
+static int igt_lmem_create_migrate(void *arg)
+{
+ return igt_create_migrate(arg, INTEL_REGION_SMEM, INTEL_REGION_LMEM);
+}
+
+static int igt_same_create_migrate(void *arg)
+{
+ return igt_create_migrate(arg, INTEL_REGION_LMEM, INTEL_REGION_LMEM);
+}
+
+static int lmem_pages_migrate_one(struct i915_gem_ww_ctx *ww,
+ struct drm_i915_gem_object *obj)
+{
+ int err;
+
+ err =
[Intel-gfx] [PATCH v5 1/3] drm/i915/gem: Implement object migration
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performance-based migration.
v2:
- Verify that the memory region given as an id really exists.
(Reported by Matthew Auld)
- Call i915_gem_object_{init,release}_memory_region() when switching region
to handle also switching region lists. (Reported by Matthew Auld)
v3:
- Fix i915_gem_object_can_migrate() to return true if object is already in
the correct region, even if the object ops doesn't have a migrate()
callback.
- Update typo in commit message.
- Fix kerneldoc of i915_gem_object_wait_migration().
v4:
- Improve documentation (Suggested by Mattew Auld and Michael Ruhl)
- Always assume TTM migration hits a TTM move and unsets the pages through
move_notify. (Reported by Matthew Auld)
- Add a dma_fence_might_wait() annotation to
i915_gem_object_wait_migration() (Suggested by Daniel Vetter)
v5:
- Re-add might_sleep() instead of __dma_fence_might_wait(), Sent
v4 with the wrong version, didn't compile and __dma_fence_might_wait()
is not exported.
- Added an R-B.
Reported-by: kernel test robot
Signed-off-by: Thomas Hellström
Reviewed-by: Michael J. Ruhl
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 112 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 77 ++--
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19 +++
5 files changed, 217 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 07e8ff9a8aae..225b77fb4314 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -513,6 +513,118 @@ bool i915_gem_object_has_iomem(const struct
drm_i915_gem_object *obj)
return obj->mem_flags & I915_BO_FLAG_IOMEM;
}
+/**
+ * i915_gem_object_can_migrate - Whether an object likely can be migrated
+ *
+ * @obj: The object to migrate
+ * @id: The region intended to migrate to
+ *
+ * Check whether the object backend supports migration to the
+ * given region. Note that pinning may affect the ability to migrate as
+ * returned by this function.
+ *
+ * This function is primarily intended as a helper for checking the
+ * possibility to migrate objects and might be slightly less permissive
+ * than i915_gem_object_migrate() when it comes to objects with the
+ * I915_BO_ALLOC_USER flag set.
+ *
+ * Return: true if migration is possible, false otherwise.
+ */
+bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
+enum intel_region_id id)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ unsigned int num_allowed = obj->mm.n_placements;
+ struct intel_memory_region *mr;
+ unsigned int i;
+
+ GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
+ GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
+
+ mr = i915->mm.regions[id];
+ if (!mr)
+ return false;
+
+ if (obj->mm.region == mr)
+ return true;
+
+ if (!i915_gem_object_evictable(obj))
+ return false;
+
+ if (!obj->ops->migrate)
+ return false;
+
+ if (!(obj->flags & I915_BO_ALLOC_USER))
+ return true;
+
+ if (num_allowed == 0)
+ return false;
+
+ for (i = 0; i < num_allowed; ++i) {
+ if (mr == obj->mm.placements[i])
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * i915_gem_object_migrate - Migrate an object to the desired region id
+ * @obj: The object to migrate.
+ * @ww: An optional struct i915_gem_ww_ctx. If NULL, the backend may
+ * not be successful in evicting other objects to make room for this object.
+ * @id: The region id to migrate to.
+ *
+ * Attempt to migrate the object to the desired memory region. The
+ * object backend must support migration and the object may not be
+ * pinned, (explicitly pinned pages or pinned vmas). The object must
+ * be locked.
+ * On successful completion, the object will have pages pointing to
+ * memory in the new region, but an async migration task may not have
+ * completed yet, and to accomplish that, i915_gem_object_wait_migration()
+ * must be called.
+ *
+ * This function is a bit more permissive than i915_gem_object_can_migrate()
+ * to allow for migrating objects where the caller knows exactly what is
+ * happening. For example within selftests. More specifically this
+ * function allows migrating I915_BO_ALLOC_USER objects to regions
+ * that are not in the list of allowable regions.
+ *
+ * Note: the @ww parameter is not used yet, but included to make sure
+ * callers put some effort into obtaining a valid ww ctx if one is
+ * available.
+ *
[Intel-gfx] [PATCH v5 0/3] drm/i915/gem: Introduce a migrate interface
We want to be able to explicitly migrate objects between gem memory regions, initially for display and dma-buf, but there might be more use-cases coming up. Introduce a gem migrate interface, add a selftest and use it for display fb pinning and dma-buf mapping. This series should make accelerated desktop work on DG1 with DG1-enabled OpenGL. v2: - Address review comments by Matthew Auld on patch 1/5. More details on the patch commit message. - Address a dma-buf locking issue pointed out by Michael Ruhl, and add a selftest to catch that issue moving forward. - Rebase the dma-buf migration patch on the above-mentioned fix. v3: - Fix i915_gem_object_can_migrate() to return true if object is already in the correct region, even if the object ops doesn't have a migrate() callback. - Update typo in commit message. v4: - Ditch dma-buf patches for now. - Improve documentation (Suggested by Mattew Auld and Michael Ruhl) - Always assume TTM migration hits a TTM move and unsets the pages through move_notify. (Reported by Matthew Auld) - Add a dma_fence_might_wait() annotation to i915_gem_object_wait_migration() (Suggested by Daniel Vetter) - Selftest updates (See specifics on that patch). - Added R-Bs v5: - Re-add might_sleep() annotation to i915_gem_object_wait_migration() - Added R-B. Matthew Auld (1): drm/i915/gem: Introduce a selftest for the gem object migrate functionality Thomas Hellström (2): drm/i915/gem: Implement object migration drm/i915/display: Migrate objects to LMEM if possible for display drivers/gpu/drm/i915/display/intel_display.c | 5 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 21 -- drivers/gpu/drm/i915/gem/i915_gem_object.c| 113 drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 77 +- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19 ++ .../drm/i915/gem/selftests/i915_gem_migrate.c | 258 ++ .../drm/i915/selftests/i915_live_selftests.h | 1 + 10 files changed, 481 insertions(+), 36 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/aperture: Pass DRM driver structure instead of driver name
== Series Details == Series: drm/aperture: Pass DRM driver structure instead of driver name URL : https://patchwork.freedesktop.org/series/92015/ State : warning == Summary == $ dim checkpatch origin/drm-tip bdaa421adb16 drm/aperture: Pass DRM driver structure instead of driver name -:310: WARNING:OBSOLETE: drivers/gpu/drm/tiny/cirrus.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. -:313: WARNING:OBSOLETE: drivers/gpu/drm/tiny/cirrus.c is marked as 'obsolete' in the MAINTAINERS hierarchy. No unnecessary modifications please. total: 0 errors, 2 warnings, 0 checks, 281 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable
On Tue, 29 Jun 2021, venkata.sai.patn...@intel.com wrote:
> From: Anusha Srivatsa
>
> DSC can be supported per DP connector. 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.
>
> force_dsc_bpp is written through this debugfs
> node to force DSC BPP to all accepted values
This commit message only describes the "what". It's nice and helpful to
summarize the code changes.
But the key question the commit message must answer is "why". Why are
you doing this? Why do we need this?
This looks like it complicates code that is already complicated to add a
debugfs. There needs to be a justification if it isn't obvious.
A couple of comments inline.
>
> Cc: Vandita Kulkarni
> Cc: Navare Manasi D
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Patnana Venkata Sai
> ---
> .../drm/i915/display/intel_display_debugfs.c | 103 +-
> .../drm/i915/display/intel_display_types.h| 1 +
> 2 files changed, 103 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index af9e58619667d..6dc223227eeaa 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2389,6 +2389,100 @@ static const struct file_operations
> i915_dsc_fec_support_fops = {
> .write = i915_dsc_fec_support_write
> };
>
> +static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct drm_device *dev = connector->dev;
> + struct drm_crtc *crtc;
> + struct intel_dp *intel_dp;
> + struct drm_modeset_acquire_ctx ctx;
> + struct intel_crtc_state *crtc_state = NULL;
> + int ret = 0;
> + bool try_again = false;
> +
> + drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> +
> + do {
> + try_again = false;
> + ret = drm_modeset_lock(>mode_config.connection_mutex,
> +);
> + if (ret) {
> + ret = -EINTR;
> + break;
> + }
> + crtc = connector->state->crtc;
> + if (connector->status != connector_status_connected || !crtc) {
> + ret = -ENODEV;
> + break;
> + }
> + ret = drm_modeset_lock(>mutex, );
> + if (ret == -EDEADLK) {
> + ret = drm_modeset_backoff();
> + if (!ret) {
> + try_again = true;
> + continue;
> + }
> + break;
> + } else if (ret) {
> + break;
> + }
> + intel_dp = intel_attached_dp(to_intel_connector(connector));
> + crtc_state = to_intel_crtc_state(crtc->state);
> + seq_printf(m, "Input_BPP: %d\n", crtc_state->pipe_bpp);
> + seq_printf(m, "Compressed_BPP: %d\n",
> + crtc_state->dsc.compressed_bpp);
> + } while (try_again);
> +
> + drm_modeset_drop_locks();
> + drm_modeset_acquire_fini();
> +
> + return ret;
Looks like copy-paste from i915_dsc_fec_support_show() which already
makes me cringe. We can't keep accumulating this kind of code in
debugfs.
> +}
> +
> +static ssize_t i915_dsc_bpp_support_write(struct file *file,
> + const char __user *ubuf,
> + size_t len, loff_t *offp)
> +{
> + int dsc_bpp = 0;
> + int ret;
> + struct drm_connector *connector =
> + ((struct seq_file *)file->private_data)->private;
> + struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + if (len == 0)
> + return 0;
> +
> + drm_dbg(>drm,
> + "Copied %zu bytes from user to force BPP\n", len);
Just no. Again, copy-paste from the fec stuff that we shouldn't have to
begin with.
> +
> + ret = kstrtoint_from_user(ubuf, len, 0, _bpp);
> +
> + intel_dp->force_dsc_bpp = dsc_bpp;
> + if (ret < 0)
> + return ret;
Check the errors before using the data!
Also, how are you prepared for fractional bpp?
> +
> + *offp += len;
> + return len;
> +}
> +
> +static int i915_dsc_bpp_support_open(struct inode *inode,
> +struct file *file)
> +{
> + return single_open(file, i915_dsc_bpp_support_show,
> +inode->i_private);
> +}
> +
> +static const struct file_operations i915_dsc_bpp_support_fops = {
> + .owner = THIS_MODULE,
> + .open =
[Intel-gfx] [PATCH v5 3/3] drm: protect drm_master pointers in drm_lease.c
Currently, direct copies of drm_file->master pointers should be
protected by drm_device.master_mutex when being dereferenced. This is
because drm_file->master is not invariant for the lifetime of
drm_file. If drm_file is not the creator of master, then
drm_file->is_master is false, and a call to drm_setmaster_ioctl will
invoke drm_new_set_master, which then allocates a new master for
drm_file and puts the old master.
Thus, without holding drm_device.master_mutex, the old value of
drm_file->master could be freed while it is being used by another
concurrent process.
In drm_lease.c, there are multiple instances where drm_file->master is
accessed and dereferenced while drm_device.master_mutex is not
held. This makes drm_lease.c vulnerable to use-after-free bugs.
We address this issue in 3 ways:
1. Clarify in the kerneldoc that drm_file->master is protected by
drm_device.master_mutex.
2. Add a new drm_file_get_master() function that calls drm_master_get
on drm_file->master while holding on to drm_device.master_mutex. Since
drm_master_get increments the reference count of master, this
prevents master from being freed until we unreference it with
drm_master_put.
3. In each case where drm_file->master is directly accessed and
eventually dereferenced in drm_lease.c, we wrap the access in a call
to the new drm_file_get_master function, then unreference the master
pointer once we are done using it.
Reported-by: Daniel Vetter
Signed-off-by: Desmond Cheong Zhi Xi
---
drivers/gpu/drm/drm_auth.c | 25
drivers/gpu/drm/drm_lease.c | 77 +++--
include/drm/drm_auth.h | 1 +
include/drm/drm_file.h | 15 ++--
4 files changed, 95 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index ab1863c5a5a0..c36a0b72be26 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -384,6 +384,31 @@ struct drm_master *drm_master_get(struct drm_master
*master)
}
EXPORT_SYMBOL(drm_master_get);
+/**
+ * drm_file_get_master - reference _file.master of @file_priv
+ * @file_priv: DRM file private
+ *
+ * Increments the reference count of @file_priv's _file.master and returns
+ * the _file.master. If @file_priv has no _file.master, returns NULL.
+ *
+ * Master pointers returned from this function should be unreferenced using
+ * drm_master_put().
+ */
+struct drm_master *drm_file_get_master(struct drm_file *file_priv)
+{
+ struct drm_master *master = NULL;
+
+ mutex_lock(_priv->minor->dev->master_mutex);
+ if (!file_priv->master)
+ goto unlock;
+ master = drm_master_get(file_priv->master);
+
+unlock:
+ mutex_unlock(_priv->minor->dev->master_mutex);
+ return master;
+}
+EXPORT_SYMBOL(drm_file_get_master);
+
static void drm_master_destroy(struct kref *kref)
{
struct drm_master *master = container_of(kref, struct drm_master,
refcount);
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 00fb433bcef1..cdcc87fa9685 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -106,10 +106,19 @@ static bool _drm_has_leased(struct drm_master *master,
int id)
*/
bool _drm_lease_held(struct drm_file *file_priv, int id)
{
- if (!file_priv || !file_priv->master)
+ bool ret;
+ struct drm_master *master;
+
+ if (!file_priv)
return true;
- return _drm_lease_held_master(file_priv->master, id);
+ master = drm_file_get_master(file_priv);
+ if (master == NULL)
+ return true;
+ ret = _drm_lease_held_master(master, id);
+ drm_master_put();
+
+ return ret;
}
/**
@@ -128,13 +137,20 @@ bool drm_lease_held(struct drm_file *file_priv, int id)
struct drm_master *master;
bool ret;
- if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+ if (!file_priv)
return true;
- master = file_priv->master;
+ master = drm_file_get_master(file_priv);
+ if (master == NULL)
+ return true;
+ if (!master->lessor) {
+ drm_master_put();
+ return true;
+ }
mutex_lock(>dev->mode_config.idr_mutex);
ret = _drm_lease_held_master(master, id);
mutex_unlock(>dev->mode_config.idr_mutex);
+ drm_master_put();
return ret;
}
@@ -154,10 +170,16 @@ uint32_t drm_lease_filter_crtcs(struct drm_file
*file_priv, uint32_t crtcs_in)
int count_in, count_out;
uint32_t crtcs_out = 0;
- if (!file_priv || !file_priv->master || !file_priv->master->lessor)
+ if (!file_priv)
return crtcs_in;
- master = file_priv->master;
+ master = drm_file_get_master(file_priv);
+ if (master == NULL)
+ return crtcs_in;
+ if (!master->lessor) {
+ drm_master_put();
+ return crtcs_in;
+ }
dev =
[Intel-gfx] [PATCH v5 2/3] drm: add a locked version of drm_is_current_master
While checking the master status of the DRM file in
drm_is_current_master(), the device's master mutex should be
held. Without the mutex, the pointer fpriv->master may be freed
concurrently by another process calling drm_setmaster_ioctl(). This
could lead to use-after-free errors when the pointer is subsequently
dereferenced in drm_lease_owner().
The callers of drm_is_current_master() from drm_auth.c hold the
device's master mutex, but external callers do not. Hence, we implement
drm_is_current_master_locked() to be used within drm_auth.c, and
modify drm_is_current_master() to grab the device's master mutex
before checking the master status.
Reported-by: Daniel Vetter
Signed-off-by: Desmond Cheong Zhi Xi
---
drivers/gpu/drm/drm_auth.c | 51 --
1 file changed, 32 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index f00e5abdbbf4..ab1863c5a5a0 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -61,6 +61,35 @@
* trusted clients.
*/
+static bool drm_is_current_master_locked(struct drm_file *fpriv)
+{
+ lockdep_assert_held_once(>minor->dev->master_mutex);
+
+ return fpriv->is_master && drm_lease_owner(fpriv->master) ==
fpriv->minor->dev->master;
+}
+
+/**
+ * drm_is_current_master - checks whether @priv is the current master
+ * @fpriv: DRM file private
+ *
+ * Checks whether @fpriv is current master on its device. This decides whether
a
+ * client is allowed to run DRM_MASTER IOCTLs.
+ *
+ * Most of the modern IOCTL which require DRM_MASTER are for kernel modesetting
+ * - the current master is assumed to own the non-shareable display hardware.
+ */
+bool drm_is_current_master(struct drm_file *fpriv)
+{
+ bool ret;
+
+ mutex_lock(>minor->dev->master_mutex);
+ ret = drm_is_current_master_locked(fpriv);
+ mutex_unlock(>minor->dev->master_mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_is_current_master);
+
int drm_getmagic(struct drm_device *dev, void *data, struct drm_file
*file_priv)
{
struct drm_auth *auth = data;
@@ -223,7 +252,7 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
if (ret)
goto out_unlock;
- if (drm_is_current_master(file_priv))
+ if (drm_is_current_master_locked(file_priv))
goto out_unlock;
if (dev->master) {
@@ -272,7 +301,7 @@ int drm_dropmaster_ioctl(struct drm_device *dev, void *data,
if (ret)
goto out_unlock;
- if (!drm_is_current_master(file_priv)) {
+ if (!drm_is_current_master_locked(file_priv)) {
ret = -EINVAL;
goto out_unlock;
}
@@ -321,7 +350,7 @@ void drm_master_release(struct drm_file *file_priv)
if (file_priv->magic)
idr_remove(_priv->master->magic_map, file_priv->magic);
- if (!drm_is_current_master(file_priv))
+ if (!drm_is_current_master_locked(file_priv))
goto out;
drm_legacy_lock_master_cleanup(dev, master);
@@ -342,22 +371,6 @@ void drm_master_release(struct drm_file *file_priv)
mutex_unlock(>master_mutex);
}
-/**
- * drm_is_current_master - checks whether @priv is the current master
- * @fpriv: DRM file private
- *
- * Checks whether @fpriv is current master on its device. This decides whether
a
- * client is allowed to run DRM_MASTER IOCTLs.
- *
- * Most of the modern IOCTL which require DRM_MASTER are for kernel modesetting
- * - the current master is assumed to own the non-shareable display hardware.
- */
-bool drm_is_current_master(struct drm_file *fpriv)
-{
- return fpriv->is_master && drm_lease_owner(fpriv->master) ==
fpriv->minor->dev->master;
-}
-EXPORT_SYMBOL(drm_is_current_master);
-
/**
* drm_master_get - reference a master pointer
* @master: drm_master
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 0/3] drm: address potential UAF bugs with drm_master ptrs
This patch series addresses potential use-after-free errors when dereferencing pointers to struct drm_master. These were identified after one such bug was caught by Syzbot in drm_getunique(): https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 The series is broken up into three patches: 1. Move a call to drm_is_current_master() out from a section locked by >mode_config.mutex in drm_mode_getconnector(). This patch does not apply to stable. 2. Implement a locked version of drm_is_current_master() function that's used within drm_auth.c. 3. Identify areas in drm_lease.c where pointers to struct drm_master are dereferenced, and ensure that the master pointers are not freed during use. Changes in v4 -> v5: - Patch 1: Add patch 1 to the series. The changes in patch 1 do not apply to stable because they apply to new changes in the drm-misc-next branch. This patch moves the call to drm_is_current_master in drm_mode_getconnector out from the section locked by >mode_config.mutex. Additionally, added a missing semicolon to the patch, caught by the intel-gfx CI. - Patch 2: Move changes to drm_connector.c into patch 1. Changes in v3 -> v4: - Patch 2: Move the call to drm_is_current_master in drm_mode_getconnector out from the section locked by >mode_config.mutex. As suggested by Daniel Vetter. This avoids a circular lock lock dependency as reported here https://patchwork.freedesktop.org/patch/440406/ Additionally, inside drm_is_current_master, instead of grabbing >master->dev->master_mutex, we grab >minor->dev->master_mutex to avoid dereferencing a null ptr if fpriv->master is not set. - Patch 3: Modify kerneldoc formatting. Additionally, add a file_priv->master NULL check inside drm_file_get_master, and handle the NULL result accordingly in drm_lease.c. As suggested by Daniel Vetter. Changes in v2 -> v3: - Patch 2: Move the definition of drm_is_current_master and the _locked version higher up in drm_auth.c to avoid needing a forward declaration of drm_is_current_master_locked. As suggested by Daniel Vetter. - Patch 3: Instead of leaking drm_device.master_mutex into drm_lease.c to protect drm_master pointers, add a new drm_file_get_master() function that returns drm_file->master while increasing its reference count, to prevent drm_file->master from being freed. As suggested by Daniel Vetter. Changes in v1 -> v2: - Patch 3: Move the lock and assignment before the DRM_DEBUG_LEASE in drm_mode_get_lease_ioctl, as suggested by Emil Velikov. Desmond Cheong Zhi Xi (3): drm: avoid circular locks in drm_mode_getconnector drm: add a locked version of drm_is_current_master drm: protect drm_master pointers in drm_lease.c drivers/gpu/drm/drm_auth.c | 76 drivers/gpu/drm/drm_connector.c | 5 ++- drivers/gpu/drm/drm_lease.c | 77 - include/drm/drm_auth.h | 1 + include/drm/drm_file.h | 15 +-- 5 files changed, 131 insertions(+), 43 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/3] drm: avoid circular locks in drm_mode_getconnector
In preparation for a future patch to take a lock on
drm_device.master_mutex inside drm_is_current_master(), we first move
the call to drm_is_current_master() in drm_mode_getconnector out from the
section locked by >mode_config.mutex. This avoids creating a
circular lock dependency.
Failing to avoid this lock dependency produces the following lockdep
splat:
==
WARNING: possible circular locking dependency detected
5.13.0-rc7-CI-CI_DRM_10254+ #1 Not tainted
--
kms_frontbuffer/1087 is trying to acquire lock:
88810dcd01a8 (>master_mutex){+.+.}-{3:3}, at:
drm_is_current_master+0x1b/0x40
but task is already holding lock:
88810dcd0488 (>mode_config.mutex){+.+.}-{3:3}, at:
drm_mode_getconnector+0x1c6/0x4a0
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (>mode_config.mutex){+.+.}-{3:3}:
__mutex_lock+0xab/0x970
drm_client_modeset_probe+0x22e/0xca0
__drm_fb_helper_initial_config_and_unlock+0x42/0x540
intel_fbdev_initial_config+0xf/0x20 [i915]
async_run_entry_fn+0x28/0x130
process_one_work+0x26d/0x5c0
worker_thread+0x37/0x380
kthread+0x144/0x170
ret_from_fork+0x1f/0x30
-> #1 (>modeset_mutex){+.+.}-{3:3}:
__mutex_lock+0xab/0x970
drm_client_modeset_commit_locked+0x1c/0x180
drm_client_modeset_commit+0x1c/0x40
__drm_fb_helper_restore_fbdev_mode_unlocked+0x88/0xb0
drm_fb_helper_set_par+0x34/0x40
intel_fbdev_set_par+0x11/0x40 [i915]
fbcon_init+0x270/0x4f0
visual_init+0xc6/0x130
do_bind_con_driver+0x1e5/0x2d0
do_take_over_console+0x10e/0x180
do_fbcon_takeover+0x53/0xb0
register_framebuffer+0x22d/0x310
__drm_fb_helper_initial_config_and_unlock+0x36c/0x540
intel_fbdev_initial_config+0xf/0x20 [i915]
async_run_entry_fn+0x28/0x130
process_one_work+0x26d/0x5c0
worker_thread+0x37/0x380
kthread+0x144/0x170
ret_from_fork+0x1f/0x30
-> #0 (>master_mutex){+.+.}-{3:3}:
__lock_acquire+0x151e/0x2590
lock_acquire+0xd1/0x3d0
__mutex_lock+0xab/0x970
drm_is_current_master+0x1b/0x40
drm_mode_getconnector+0x37e/0x4a0
drm_ioctl_kernel+0xa8/0xf0
drm_ioctl+0x1e8/0x390
__x64_sys_ioctl+0x6a/0xa0
do_syscall_64+0x39/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
other info that might help us debug this:
Chain exists of: >master_mutex --> >modeset_mutex -->
>mode_config.mutex
Possible unsafe locking scenario:
CPU0CPU1
lock(>mode_config.mutex);
lock(>modeset_mutex);
lock(>mode_config.mutex);
lock(>master_mutex);
*** DEADLOCK ***
1 lock held by kms_frontbuffer/1087:
#0: 88810dcd0488 (>mode_config.mutex){+.+.}-{3:3}, at:
drm_mode_getconnector+0x1c6/0x4a0
stack backtrace:
CPU: 7 PID: 1087 Comm: kms_frontbuffer Not tainted 5.13.0-rc7-CI-CI_DRM_10254+
#1
Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM
PD RVP TLC, BIOS ICLSFWR1.R00.3234.A01.1906141750 06/14/2019
Call Trace:
dump_stack+0x7f/0xad
check_noncircular+0x12e/0x150
__lock_acquire+0x151e/0x2590
lock_acquire+0xd1/0x3d0
__mutex_lock+0xab/0x970
drm_is_current_master+0x1b/0x40
drm_mode_getconnector+0x37e/0x4a0
drm_ioctl_kernel+0xa8/0xf0
drm_ioctl+0x1e8/0x390
__x64_sys_ioctl+0x6a/0xa0
do_syscall_64+0x39/0xb0
entry_SYSCALL_64_after_hwframe+0x44/0xae
Reported-by: Daniel Vetter
Signed-off-by: Desmond Cheong Zhi Xi
---
drivers/gpu/drm/drm_connector.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..2ba257b1ae20 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2414,6 +2414,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
struct drm_mode_modeinfo u_mode;
struct drm_mode_modeinfo __user *mode_ptr;
uint32_t __user *encoder_ptr;
+ bool is_current_master;
if (!drm_core_check_feature(dev, DRIVER_MODESET))
return -EOPNOTSUPP;
@@ -2444,9 +2445,11 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
out_resp->connector_type = connector->connector_type;
out_resp->connector_type_id = connector->connector_type_id;
+ is_current_master = drm_is_current_master(file_priv);
+
mutex_lock(>mode_config.mutex);
if (out_resp->count_modes == 0) {
- if (drm_is_current_master(file_priv))
+ if (is_current_master)
connector->funcs->fill_modes(connector,
dev->mode_config.max_width,
[Intel-gfx] [PATCH] drm/aperture: Pass DRM driver structure instead of driver name
Print the name of the DRM driver when taking over fbdev devices. Makes
the output to dmesg more consistent. Note that the driver name is only
used for printing a string to the kernel log. No UAPI is affected by this
change.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +-
drivers/gpu/drm/armada/armada_drv.c | 2 +-
drivers/gpu/drm/ast/ast_drv.c | 2 +-
drivers/gpu/drm/bochs/bochs_drv.c | 2 +-
drivers/gpu/drm/drm_aperture.c| 19 ---
.../gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 2 +-
drivers/gpu/drm/hyperv/hyperv_drm_drv.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.c | 2 +-
drivers/gpu/drm/meson/meson_drv.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
drivers/gpu/drm/msm/msm_fbdev.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.c | 2 +-
drivers/gpu/drm/radeon/radeon_drv.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
drivers/gpu/drm/sun4i/sun4i_drv.c | 2 +-
drivers/gpu/drm/tegra/drm.c | 2 +-
drivers/gpu/drm/tiny/cirrus.c | 2 +-
drivers/gpu/drm/vboxvideo/vbox_drv.c | 2 +-
drivers/gpu/drm/vc4/vc4_drv.c | 2 +-
drivers/gpu/drm/virtio/virtgpu_drv.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
include/drm/drm_aperture.h| 14 +-
23 files changed, 43 insertions(+), 34 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6f30c525caac..accf9c1b967a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -1278,7 +1278,7 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
#endif
/* Get rid of things like offb */
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
"amdgpudrmfb");
+ ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
_kms_driver);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/armada/armada_drv.c
b/drivers/gpu/drm/armada/armada_drv.c
index dab0a1f0983b..31925ae3ab72 100644
--- a/drivers/gpu/drm/armada/armada_drv.c
+++ b/drivers/gpu/drm/armada/armada_drv.c
@@ -95,7 +95,7 @@ static int armada_drm_bind(struct device *dev)
}
/* Remove early framebuffers */
- ret = drm_aperture_remove_framebuffers(false, "armada-drm-fb");
+ ret = drm_aperture_remove_framebuffers(false, _drm_driver);
if (ret) {
dev_err(dev, "[" DRM_NAME ":%s] can't kick out simple-fb: %d\n",
__func__, ret);
diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c
index 5aa452b4efe6..86d5cd7b6318 100644
--- a/drivers/gpu/drm/ast/ast_drv.c
+++ b/drivers/gpu/drm/ast/ast_drv.c
@@ -100,7 +100,7 @@ static int ast_remove_conflicting_framebuffers(struct
pci_dev *pdev)
primary = pdev->resource[PCI_ROM_RESOURCE].flags &
IORESOURCE_ROM_SHADOW;
#endif
- return drm_aperture_remove_conflicting_framebuffers(base, size,
primary, "astdrmfb");
+ return drm_aperture_remove_conflicting_framebuffers(base, size,
primary, _driver);
}
static int ast_pci_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
diff --git a/drivers/gpu/drm/bochs/bochs_drv.c
b/drivers/gpu/drm/bochs/bochs_drv.c
index c828cadbabff..0d232b44ecd7 100644
--- a/drivers/gpu/drm/bochs/bochs_drv.c
+++ b/drivers/gpu/drm/bochs/bochs_drv.c
@@ -110,7 +110,7 @@ static int bochs_pci_probe(struct pci_dev *pdev,
return -ENOMEM;
}
- ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
"bochsdrmfb");
+ ret = drm_aperture_remove_conflicting_pci_framebuffers(pdev,
_driver);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/drm_aperture.c b/drivers/gpu/drm/drm_aperture.c
index 9335d9d6cf9a..9ac39cf11694 100644
--- a/drivers/gpu/drm/drm_aperture.c
+++ b/drivers/gpu/drm/drm_aperture.c
@@ -33,6 +33,10 @@
*
* .. code-block:: c
*
+ * static const struct drm_driver example_driver = {
+ * ...
+ * };
+ *
* static int remove_conflicting_framebuffers(struct pci_dev *pdev)
* {
* bool primary = false;
@@ -46,7 +50,7 @@
* #endif
*
* return drm_aperture_remove_conflicting_framebuffers(base, size,
primary,
- * "example
driver");
+ *
_driver);
* }
*
* static int probe(struct pci_dev *pdev)
@@ -274,7 +278,7 @@ static void drm_aperture_detach_drivers(resource_size_t
base, resource_size_t si
* @base: the aperture's base address in physical memory
* @size: aperture size in bytes
* @primary: also kick vga16fb
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/jsl: Remove require_force_probe protection (rev2)
== Series Details == Series: drm/i915/jsl: Remove require_force_probe protection (rev2) URL : https://patchwork.freedesktop.org/series/82710/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10285_full -> Patchwork_20484_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20484_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20484_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20484_full: ### IGT changes ### Possible regressions * igt@gem_flink_race@flink_close: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-tglb2/igt@gem_flink_race@flink_close.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-tglb6/igt@gem_flink_race@flink_close.html Known issues Here are the changes found in Patchwork_20484_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-apl8/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_eio@in-flight-1us: - shard-skl: [PASS][5] -> [TIMEOUT][6] ([i915#3063]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-skl10/igt@gem_...@in-flight-1us.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-skl9/igt@gem_...@in-flight-1us.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][7] ([i915#2846]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-apl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-iclb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html - shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-tglb3/igt@gem_exec_fair@basic-none-sh...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-tglb5/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][12] -> [FAIL][13] ([i915#2842]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs0: - shard-kbl: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-kbl3/igt@gem_exec_fair@basic-p...@vcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2190]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-apl3/igt@gem_huc_c...@huc-copy.html - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2190]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-kbl1/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy-xy: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#307]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-glk7/igt@gem_mmap_...@big-copy-xy.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-glk9/igt@gem_mmap_...@big-copy-xy.html * igt@gem_mmap_gtt@cpuset-big-copy: - shard-iclb: [PASS][20] -> [FAIL][21] ([i915#2428]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-iclb5/igt@gem_mmap_...@cpuset-big-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][22] ([i915#2658]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/shard-apl8/igt@gem_pwr...@basic-exhaustion.html *
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/ehl: Remove require_force_probe protection (rev2)
== Series Details == Series: drm/i915/ehl: Remove require_force_probe protection (rev2) URL : https://patchwork.freedesktop.org/series/82413/ State : success == Summary == CI Bug Log - changes from CI_DRM_10285_full -> Patchwork_20483_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20483_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-queued: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-queued.html * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][2] ([i915#2846]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-apl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-kbl: [PASS][3] -> [FAIL][4] ([i915#2842]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-kbl4/igt@gem_exec_fair@basic-none-r...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-kbl7/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-iclb: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-iclb4/igt@gem_exec_fair@basic-none-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-iclb1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-iclb2/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-apl3/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#307]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-glk7/igt@gem_mmap_...@big-copy.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-glk9/igt@gem_mmap_...@big-copy.html * igt@gem_mmap_gtt@cpuset-medium-copy-odd: - shard-iclb: [PASS][11] -> [FAIL][12] ([i915#2428]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-iclb1/igt@gem_mmap_...@cpuset-medium-copy-odd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-iclb5/igt@gem_mmap_...@cpuset-medium-copy-odd.html * igt@gem_pread@exhaustion: - shard-kbl: NOTRUN -> [WARN][13] ([i915#2658]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-kbl6/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@input-checking: - shard-kbl: NOTRUN -> [DMESG-WARN][14] ([i915#3002]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-kbl6/igt@gem_userptr_bl...@input-checking.html * igt@gen9_exec_parse@batch-invalid-length: - shard-snb: NOTRUN -> [SKIP][15] ([fdo#109271]) +190 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-snb6/igt@gen9_exec_pa...@batch-invalid-length.html * igt@kms_big_fb@linear-32bpp-rotate-0: - shard-iclb: [PASS][16] -> [DMESG-WARN][17] ([i915#3621]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-iclb2/igt@kms_big...@linear-32bpp-rotate-0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-iclb1/igt@kms_big...@linear-32bpp-rotate-0.html * igt@kms_chamelium@hdmi-hpd-storm: - shard-kbl: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +10 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-kbl2/igt@kms_chamel...@hdmi-hpd-storm.html * igt@kms_chamelium@vga-hpd-for-each-pipe: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [fdo#111827]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-skl1/igt@kms_chamel...@vga-hpd-for-each-pipe.html * igt@kms_chamelium@vga-hpd-without-ddc: - shard-snb: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111827]) +10 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-snb5/igt@kms_chamel...@vga-hpd-without-ddc.html * igt@kms_color_chamelium@pipe-c-ctm-0-5: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +14 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/shard-apl3/igt@kms_color_chamel...@pipe-c-ctm-0-5.html * igt@kms_content_protection@atomic: - shard-kbl: NOTRUN ->
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/jsl: Remove require_force_probe protection (rev2)
== Series Details ==
Series: drm/i915/jsl: Remove require_force_probe protection (rev2)
URL : https://patchwork.freedesktop.org/series/82710/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10285 -> Patchwork_20484
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_20484:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@gt_pm:
- {fi-jsl-1}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/fi-jsl-1/igt@i915_selftest@live@gt_pm.html
Known issues
Here are the changes found in Patchwork_20484 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@requests:
- fi-kbl-soraka: [PASS][3] -> [INCOMPLETE][4] ([i915#2782])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][5] ([i915#1436] / [i915#3363])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/fi-kbl-soraka/igt@run...@aborted.html
Possible fixes
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][6] ([i915#1372]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
Participating hosts (40 -> 37)
--
Missing(3): fi-bsw-cyan fi-bdw-samus fi-hsw-4200u
Build changes
-
* Linux: CI_DRM_10285 -> Patchwork_20484
CI-20190529: 20190529
CI_DRM_10285: e65a658751fc5d3be5b0f4bcc4731e66ca1a537a @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6121: a63ceb48e6c3e733d04156b32fba3b4f4d5ad794 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20484: f8bf4617df26d0ee85966ad8a37b7aac1305d2fa @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f8bf4617df26 drm/i915/jsl: Remove require_force_probe protection
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20484/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/gem: Introduce a migrate interface (rev4)
== Series Details == Series: drm/i915/gem: Introduce a migrate interface (rev4) URL : https://patchwork.freedesktop.org/series/91890/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gem/i915_gem_wait.o drivers/gpu/drm/i915/gem/i915_gem_wait.c: In function ‘i915_gem_object_wait_migration’: drivers/gpu/drm/i915/gem/i915_gem_wait.c:308:2: error: implicit declaration of function ‘dma_fence_might_wait’; did you mean ‘dma_fence_wait’? [-Werror=implicit-function-declaration] dma_fence_might_wait(); ^~~~ dma_fence_wait cc1: all warnings being treated as errors scripts/Makefile.build:272: recipe for target 'drivers/gpu/drm/i915/gem/i915_gem_wait.o' failed make[4]: *** [drivers/gpu/drm/i915/gem/i915_gem_wait.o] Error 1 scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:515: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:515: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1847: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/3] drm/i915/gem: Implement object migration
On Tue, 29 Jun 2021 at 12:37, Thomas Hellström
wrote:
>
> Introduce an interface to migrate objects between regions.
> This is primarily intended to migrate objects to LMEM for display and
> to SYSTEM for dma-buf, but might be reused in one form or another for
> performance-based migration.
>
> v2:
> - Verify that the memory region given as an id really exists.
> (Reported by Matthew Auld)
> - Call i915_gem_object_{init,release}_memory_region() when switching region
> to handle also switching region lists. (Reported by Matthew Auld)
> v3:
> - Fix i915_gem_object_can_migrate() to return true if object is already in
> the correct region, even if the object ops doesn't have a migrate()
> callback.
> - Update typo in commit message.
> - Fix kerneldoc of i915_gem_object_wait_migration().
> v4:
> - Improve documentation (Suggested by Mattew Auld and Michael Ruhl)
> - Always assume TTM migration hits a TTM move and unsets the pages through
> move_notify. (Reported by Matthew Auld)
> - Add a dma_fence_might_wait() annotation to
> i915_gem_object_wait_migration() (Suggested by Daniel Vetter)
>
> Reported-by: kernel test robot
> Signed-off-by: Thomas Hellström
> Reviewed-by: Michael J. Ruhl
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/ehl: Remove require_force_probe protection (rev2)
== Series Details == Series: drm/i915/ehl: Remove require_force_probe protection (rev2) URL : https://patchwork.freedesktop.org/series/82413/ State : success == Summary == CI Bug Log - changes from CI_DRM_10285 -> Patchwork_20483 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/index.html Known issues Here are the changes found in Patchwork_20483 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [FAIL][1] ([i915#1372]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 Participating hosts (40 -> 37) -- Missing(3): fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * Linux: CI_DRM_10285 -> Patchwork_20483 CI-20190529: 20190529 CI_DRM_10285: e65a658751fc5d3be5b0f4bcc4731e66ca1a537a @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6121: a63ceb48e6c3e733d04156b32fba3b4f4d5ad794 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20483: 3c0a30438d88faf3ddc92454d1c6610962d6e263 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3c0a30438d88 drm/i915/ehl: Remove require_force_probe protection == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20483/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/xelpd: Enabling dithering after the CC1
Cc: Ville and Daniel for archeology...
On Fri, 11 Jun 2021, Nischal Varide wrote:
> If the panel is 12bpc then Dithering is not enabled in the Legacy
> dithering block , instead its Enabled after the C1 CC1 pipe post
> color space conversion.For a 6bpc pannel Dithering is enabled in
> Legacy block.
Currently, we only ever enable dithering for 6 bpc displays. See commit
e8fa4270536d ("drm/i915: Only dither on 6bpc panels"). This is decided
at the end of intel_modeset_pipe_config().
The big question here is if we want to expand the use of dithering. I
guess we could be able to reduce banding if we did?
> Signed-off-by: Nischal Varide
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 7 +++
> drivers/gpu/drm/i915/display/intel_display.c | 11 ++-
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 3 files changed, 18 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
> b/drivers/gpu/drm/i915/display/intel_color.c
> index dab892d2251b..c7af583200c4 100644
> --- a/drivers/gpu/drm/i915/display/intel_color.c
> +++ b/drivers/gpu/drm/i915/display/intel_color.c
> @@ -1574,6 +1574,7 @@ static int glk_color_check(struct intel_crtc_state
> *crtc_state)
> static u32 icl_gamma_mode(const struct intel_crtc_state *crtc_state)
> {
> u32 gamma_mode = 0;
> + struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
>
> if (crtc_state->hw.degamma_lut)
> gamma_mode |= PRE_CSC_GAMMA_ENABLE;
> @@ -1588,6 +1589,12 @@ static u32 icl_gamma_mode(const struct
> intel_crtc_state *crtc_state)
> else
> gamma_mode |= GAMMA_MODE_MODE_12BIT_MULTI_SEGMENTED;
>
> + if (DISPLAY_VER(i915) >= 13) {
> + if (!crtc_state->dither_force_disable &&
> + (crtc_state->pipe_bpp == 36))
> + gamma_mode |= POST_CC1_DITHER_ENABLE;
> + }
This enables dithering independent of crtc_state->dither. That doesn't
seem like a good idea. I think the decision should be made at the end of
intel_modeset_pipe_config().
if (DISPLAY_VER(i915) >= 13 && crtc_state->dither &&
crtc_state->pipe_bpp == 36)
gamma_mode |= POST_CC1_DITHER_ENABLE;
Obviously, as we currently only enable dithering for 6 bpc, this would
become a nop if it looked at crtc_state->dither and pipe_bpp only.
> +
> return gamma_mode;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 362bff9beb5c..3a7feb246745 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5762,7 +5762,16 @@ static void bdw_set_pipemisc(const struct
> intel_crtc_state *crtc_state)
> break;
> }
>
> - if (crtc_state->dither)
> + /*
> + * If 12bpc panel then, Enables dithering after the CC1 pipe
> + * post color space conversion and not here for display_ver
> + * greater than or equal to thirteen.
> + */
> +
> + if (crtc_state->dither && (crtc_state->pipe_bpp != 36))
> + val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
> +
> + if (crtc_state->dither && (crtc_state->pipe_bpp == 36) &&
> (DISPLAY_VER(dev_priv) < 13))
> val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
This is what you're trying to say:
/* 12 bpc dithering is done at post CSC gamma for display 13+ */
if (crtc_state->dither &&
(crtc_state->pipe_bpp != 36 || DISPLAY_VER(dev_priv) < 13))
val |= PIPEMISC_DITHER_ENABLE | PIPEMISC_DITHER_TYPE_SP;
Again, this is a nop until we decide to use dithering more.
>
> if (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e915ec034c98..33dba13fa94d 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -7743,6 +7743,7 @@ enum {
> #define GAMMA_MODE(pipe) _MMIO_PIPE(pipe, _GAMMA_MODE_A, _GAMMA_MODE_B)
> #define PRE_CSC_GAMMA_ENABLE(1 << 31)
> #define POST_CSC_GAMMA_ENABLE (1 << 30)
> +#define POST_CC1_DITHER_ENABLE (1 << 26)
> #define GAMMA_MODE_MODE_MASK(3 << 0)
> #define GAMMA_MODE_MODE_8BIT(0 << 0)
> #define GAMMA_MODE_MODE_10BIT (1 << 0)
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
Am 29.06.21 um 13:17 schrieb Pekka Paalanen: > On Tue, 29 Jun 2021 08:12:54 + > Simon Ser wrote: > >> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen >> wrote: >> >>> yes, I think this makes sense, even if it is a property that one can't >>> tell for sure what it does before hand. >>> >>> Using a pair of properties, preference and active, to ask for something >>> and then check what actually worked is good for reducing the >>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit" >>> test different KMS configurations. Userspace has a better chance of >>> finding a configuration that is possible. >>> >>> OTOH, this has the problem than in UI one cannot tell the user in >>> advance which options are truly possible. Given that KMS properties are >>> rarely completely independent, and in this case known to depend on >>> several other KMS properties, I think it is good enough to know after >>> the fact. >>> >>> If a driver does not use what userspace prefers, there is no way to >>> understand why, or what else to change to make it happen. That problem >>> exists anyway, because TEST_ONLY commits do not give useful feedback >>> but only a yes/no. >> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one >> property at a time), user-space can discover which property makes the atomic >> commit fail. > That works if the properties are independent of each other. Color > range, color format, bpc and more may all be interconnected, > allowing only certain combinations to work. > > If all these properties have "auto" setting too, then it would be > possible to probe each property individually, but that still does not > tell which combinations are valid. > > If you probe towards a certain configuration by setting the properties > one by one, then depending on the order you pick the properties, you > may come to a different conclusion on which property breaks the > configuration. My mind crossed another point that must be considered: When plugin in a Monitor a list of possible Resolutions+Framerate combinations is created for xrandr and other userspace (I guess by atomic checks? but I don't know). During this drm properties are already considered, which is no problem atm because as far as i can tell there is currently no drm property that would make a certain Resolutions+Framerate combination unreachable that would be possible with everything on default. However for example forcing YCbCr420 encoding would limit the available resolutions (my screen for example only supports YCbCr420 on 4k@60 and @50Hz and on no other resolution or frequency (native is 2560x1440@144Hz). So would a "force color format" that does not get resetted on repluging/reenabling a monitor break the output, for example, of an not updated xrandr, unaware of this new property? >> I'm not a fan of this "preference" property approach. The only way to find >> out >> whether it's possible to change the color format is to perform a user-visible >> change (with a regular atomic commit) and check whether it worked >> after-the-fact. This is unlike all other existing KMS properties. > I agree. FWIW, "max bpc" exists already. > >> I'd much rather see a more general approach to fix this combinatorial >> explosion >> than to add special-cases like this. > What would you suggest? > > Maybe all properties should have an "auto" value in addition to the > explicit no-negotiation values where at all possible? > > That might help probing each property individually with TEST_ONLY > commits, but it says nothing about combinations. > > A feedback list perhaps? TEST_ONLY commit somehow returning a list of > property/value tuples indicating what value the "auto" valued > properties actually get? > > What should a kernel driver optimize for when determining "auto" values? > > > Thanks, > pq > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 3/3] drm/i915/display: Migrate objects to LMEM if possible for display
Objects intended to be used as display framebuffers must reside in
LMEM for discrete. If they happen to not do that, migrate them to
LMEM before pinning.
Signed-off-by: Thomas Hellström
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/display/intel_display.c | 5 -
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 21
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 --
4 files changed, 5 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index eec6c9e9cda7..026c28c612f0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1331,6 +1331,9 @@ intel_pin_and_fence_fb_obj(struct drm_framebuffer *fb,
ret = i915_gem_object_lock(obj, );
if (!ret && phys_cursor)
ret = i915_gem_object_attach_phys(obj, alignment);
+ else if (!ret && HAS_LMEM(dev_priv))
+ ret = i915_gem_object_migrate(obj, , INTEL_REGION_LMEM);
+ /* TODO: Do we need to sync when migration becomes async? */
if (!ret)
ret = i915_gem_object_pin_pages(obj);
if (ret)
@@ -11778,7 +11781,7 @@ intel_user_framebuffer_create(struct drm_device *dev,
/* object is backed with LMEM for discrete */
i915 = to_i915(obj->base.dev);
- if (HAS_LMEM(i915) && !i915_gem_object_validates_to_lmem(obj)) {
+ if (HAS_LMEM(i915) && !i915_gem_object_can_migrate(obj,
INTEL_REGION_LMEM)) {
/* object is "remote", not in local memory */
i915_gem_object_put(obj);
return ERR_PTR(-EREMOTE);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 073822100da7..7d1400b13429 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -375,7 +375,7 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
struct i915_vma *vma;
int ret;
- /* Frame buffer must be in LMEM (no migration yet) */
+ /* Frame buffer must be in LMEM */
if (HAS_LMEM(i915) && !i915_gem_object_is_lmem(obj))
return ERR_PTR(-EINVAL);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 41d5182cd367..be1d122574af 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -23,27 +23,6 @@ i915_gem_object_lmem_io_map(struct drm_i915_gem_object *obj,
return io_mapping_map_wc(>mm.region->iomap, offset, size);
}
-/**
- * i915_gem_object_validates_to_lmem - Whether the object is resident in
- * lmem when pages are present.
- * @obj: The object to check.
- *
- * Migratable objects residency may change from under us if the object is
- * not pinned or locked. This function is intended to be used to check whether
- * the object can only reside in lmem when pages are present.
- *
- * Return: Whether the object is always resident in lmem when pages are
- * present.
- */
-bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj)
-{
- struct intel_memory_region *mr = READ_ONCE(obj->mm.region);
-
- return !i915_gem_object_migratable(obj) &&
- mr && (mr->type == INTEL_MEMORY_LOCAL ||
- mr->type == INTEL_MEMORY_STOLEN_LOCAL);
-}
-
/**
* i915_gem_object_is_lmem - Whether the object is resident in
* lmem
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 8cbd7a5334e2..d423d8cac4f2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -597,8 +597,6 @@ bool i915_gem_object_evictable(struct drm_i915_gem_object
*obj);
bool i915_gem_object_migratable(struct drm_i915_gem_object *obj);
-bool i915_gem_object_validates_to_lmem(struct drm_i915_gem_object *obj);
-
int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
struct i915_gem_ww_ctx *ww,
enum intel_region_id id);
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
Am 29.06.21 um 13:17 schrieb Pekka Paalanen: > On Tue, 29 Jun 2021 08:12:54 + > Simon Ser wrote: > >> On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen >> wrote: >> >>> yes, I think this makes sense, even if it is a property that one can't >>> tell for sure what it does before hand. >>> >>> Using a pair of properties, preference and active, to ask for something >>> and then check what actually worked is good for reducing the >>> combinatorial explosion caused by needing to "atomic TEST_ONLY commit" >>> test different KMS configurations. Userspace has a better chance of >>> finding a configuration that is possible. >>> >>> OTOH, this has the problem than in UI one cannot tell the user in >>> advance which options are truly possible. Given that KMS properties are >>> rarely completely independent, and in this case known to depend on >>> several other KMS properties, I think it is good enough to know after >>> the fact. >>> >>> If a driver does not use what userspace prefers, there is no way to >>> understand why, or what else to change to make it happen. That problem >>> exists anyway, because TEST_ONLY commits do not give useful feedback >>> but only a yes/no. >> By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one >> property at a time), user-space can discover which property makes the atomic >> commit fail. > That works if the properties are independent of each other. Color > range, color format, bpc and more may all be interconnected, > allowing only certain combinations to work. > > If all these properties have "auto" setting too, then it would be > possible to probe each property individually, but that still does not > tell which combinations are valid. > > If you probe towards a certain configuration by setting the properties > one by one, then depending on the order you pick the properties, you > may come to a different conclusion on which property breaks the > configuration. My mind crossed another point that must be considered: When plugin in a Monitor a list of possible Resolutions+Framerate combinations is created for xrandr and other userspace (I guess by atomic checks? but I don't know). During this drm properties are already considered, which is no problem atm because as far as i can tell there is currently no drm property that would make a certain Resolutions+Framerate combination unreachable that would be possible with everything on default. However for example forcing YCbCr420 encoding would limit the available resolutions (my screen for example only supports YCbCr420 on 4k@60 and @50Hz and on no other resolution or frequency (native is 2560x1440@144Hz). So would a "force color format" that does not get resetted on repluging/reenabling a monitor break the output, for example, of an not updated xrandr, unaware of this new property? > >> I'm not a fan of this "preference" property approach. The only way to find >> out >> whether it's possible to change the color format is to perform a user-visible >> change (with a regular atomic commit) and check whether it worked >> after-the-fact. This is unlike all other existing KMS properties. > I agree. FWIW, "max bpc" exists already. > >> I'd much rather see a more general approach to fix this combinatorial >> explosion >> than to add special-cases like this. > What would you suggest? > > Maybe all properties should have an "auto" value in addition to the > explicit no-negotiation values where at all possible? > > That might help probing each property individually with TEST_ONLY > commits, but it says nothing about combinations. > > A feedback list perhaps? TEST_ONLY commit somehow returning a list of > property/value tuples indicating what value the "auto" valued > properties actually get? > > What should a kernel driver optimize for when determining "auto" values? > > > Thanks, > pq > > ___ > amd-gfx mailing list > amd-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/amd-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 2/3] drm/i915/gem: Introduce a selftest for the gem object migrate functionality
From: Matthew Auld
A selftest for the gem object migrate functionality. Slightly adapted
from the original by Matthew to the new interface and new fill blit
code.
v4:
- Initialize buffers and check contents after migration
(Suggested by Matthew Auld)
- Perform async migration (if implemented) in the igt_lmem_pages_migrate
test
- Test also migration to the current region.
Co-developed-by: Thomas Hellström
Signed-off-by: Thomas Hellström
Signed-off-by: Matthew Auld
Reviewed-by: Michael J. Ruhl #v3
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 1 +
.../drm/i915/gem/selftests/i915_gem_migrate.c | 258 ++
.../drm/i915/selftests/i915_live_selftests.h | 1 +
3 files changed, 260 insertions(+)
create mode 100644 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 225b77fb4314..547cc9dad90d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -665,6 +665,7 @@ static const struct drm_gem_object_funcs
i915_gem_object_funcs = {
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftests/huge_gem_object.c"
#include "selftests/huge_pages.c"
+#include "selftests/i915_gem_migrate.c"
#include "selftests/i915_gem_object.c"
#include "selftests/i915_gem_coherency.c"
#endif
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
new file mode 100644
index ..ced6e3a814a2
--- /dev/null
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c
@@ -0,0 +1,258 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020-2021 Intel Corporation
+ */
+
+#include "gt/intel_migrate.h"
+
+static int igt_fill_check_buffer(struct drm_i915_gem_object *obj,
+bool fill)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ unsigned int i, count = obj->base.size / sizeof(u32);
+ enum i915_map_type map_type =
+ i915_coherent_map_type(i915, obj, false);
+ u32 *cur;
+ int err = 0;
+
+ assert_object_held(obj);
+ cur = i915_gem_object_pin_map(obj, map_type);
+ if (IS_ERR(cur))
+ return PTR_ERR(cur);
+
+ if (fill)
+ for (i = 0; i < count; ++i)
+ *cur++ = i;
+ else
+ for (i = 0; i < count; ++i)
+ if (*cur++ != i) {
+ pr_err("Object content mismatch at location %d
of %d\n", i, count);
+ err = -EINVAL;
+ break;
+ }
+
+ i915_gem_object_unpin_map(obj);
+
+ return err;
+}
+
+static int igt_create_migrate(struct intel_gt *gt, enum intel_region_id src,
+ enum intel_region_id dst)
+{
+ struct drm_i915_private *i915 = gt->i915;
+ struct intel_memory_region *src_mr = i915->mm.regions[src];
+ struct drm_i915_gem_object *obj;
+ struct i915_gem_ww_ctx ww;
+ int err = 0;
+
+ GEM_BUG_ON(!src_mr);
+
+ /* Switch object backing-store on create */
+ obj = i915_gem_object_create_region(src_mr, PAGE_SIZE, 0);
+ if (IS_ERR(obj))
+ return PTR_ERR(obj);
+
+ for_i915_gem_ww(, err, true) {
+ err = i915_gem_object_lock(obj, );
+ if (err)
+ continue;
+
+ err = igt_fill_check_buffer(obj, true);
+ if (err)
+ continue;
+
+ if (!i915_gem_object_can_migrate(obj, dst)) {
+ err = -EINVAL;
+ continue;
+ }
+
+ err = i915_gem_object_migrate(obj, , dst);
+ if (err)
+ continue;
+
+ err = i915_gem_object_pin_pages(obj);
+ if (err)
+ continue;
+
+ if (i915_gem_object_can_migrate(obj, src))
+ err = -EINVAL;
+
+ i915_gem_object_unpin_pages(obj);
+ err = i915_gem_object_wait_migration(obj, true);
+ if (err)
+ continue;
+
+ err = igt_fill_check_buffer(obj, false);
+ }
+ i915_gem_object_put(obj);
+
+ return err;
+}
+
+static int igt_smem_create_migrate(void *arg)
+{
+ return igt_create_migrate(arg, INTEL_REGION_LMEM, INTEL_REGION_SMEM);
+}
+
+static int igt_lmem_create_migrate(void *arg)
+{
+ return igt_create_migrate(arg, INTEL_REGION_SMEM, INTEL_REGION_LMEM);
+}
+
+static int igt_same_create_migrate(void *arg)
+{
+ return igt_create_migrate(arg, INTEL_REGION_LMEM, INTEL_REGION_LMEM);
+}
+
+static int lmem_pages_migrate_one(struct i915_gem_ww_ctx *ww,
+ struct drm_i915_gem_object *obj)
+{
+ int err;
+
+ err =
[Intel-gfx] [PATCH v4 1/3] drm/i915/gem: Implement object migration
Introduce an interface to migrate objects between regions.
This is primarily intended to migrate objects to LMEM for display and
to SYSTEM for dma-buf, but might be reused in one form or another for
performance-based migration.
v2:
- Verify that the memory region given as an id really exists.
(Reported by Matthew Auld)
- Call i915_gem_object_{init,release}_memory_region() when switching region
to handle also switching region lists. (Reported by Matthew Auld)
v3:
- Fix i915_gem_object_can_migrate() to return true if object is already in
the correct region, even if the object ops doesn't have a migrate()
callback.
- Update typo in commit message.
- Fix kerneldoc of i915_gem_object_wait_migration().
v4:
- Improve documentation (Suggested by Mattew Auld and Michael Ruhl)
- Always assume TTM migration hits a TTM move and unsets the pages through
move_notify. (Reported by Matthew Auld)
- Add a dma_fence_might_wait() annotation to
i915_gem_object_wait_migration() (Suggested by Daniel Vetter)
Reported-by: kernel test robot
Signed-off-by: Thomas Hellström
Reviewed-by: Michael J. Ruhl
---
drivers/gpu/drm/i915/gem/i915_gem_object.c| 112 ++
drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 ++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 77 ++--
drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19 +++
5 files changed, 217 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 07e8ff9a8aae..225b77fb4314 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -513,6 +513,118 @@ bool i915_gem_object_has_iomem(const struct
drm_i915_gem_object *obj)
return obj->mem_flags & I915_BO_FLAG_IOMEM;
}
+/**
+ * i915_gem_object_can_migrate - Whether an object likely can be migrated
+ *
+ * @obj: The object to migrate
+ * @id: The region intended to migrate to
+ *
+ * Check whether the object backend supports migration to the
+ * given region. Note that pinning may affect the ability to migrate as
+ * returned by this function.
+ *
+ * This function is primarily intended as a helper for checking the
+ * possibility to migrate objects and might be slightly less permissive
+ * than i915_gem_object_migrate() when it comes to objects with the
+ * I915_BO_ALLOC_USER flag set.
+ *
+ * Return: true if migration is possible, false otherwise.
+ */
+bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
+enum intel_region_id id)
+{
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ unsigned int num_allowed = obj->mm.n_placements;
+ struct intel_memory_region *mr;
+ unsigned int i;
+
+ GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
+ GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
+
+ mr = i915->mm.regions[id];
+ if (!mr)
+ return false;
+
+ if (obj->mm.region == mr)
+ return true;
+
+ if (!i915_gem_object_evictable(obj))
+ return false;
+
+ if (!obj->ops->migrate)
+ return false;
+
+ if (!(obj->flags & I915_BO_ALLOC_USER))
+ return true;
+
+ if (num_allowed == 0)
+ return false;
+
+ for (i = 0; i < num_allowed; ++i) {
+ if (mr == obj->mm.placements[i])
+ return true;
+ }
+
+ return false;
+}
+
+/**
+ * i915_gem_object_migrate - Migrate an object to the desired region id
+ * @obj: The object to migrate.
+ * @ww: An optional struct i915_gem_ww_ctx. If NULL, the backend may
+ * not be successful in evicting other objects to make room for this object.
+ * @id: The region id to migrate to.
+ *
+ * Attempt to migrate the object to the desired memory region. The
+ * object backend must support migration and the object may not be
+ * pinned, (explicitly pinned pages or pinned vmas). The object must
+ * be locked.
+ * On successful completion, the object will have pages pointing to
+ * memory in the new region, but an async migration task may not have
+ * completed yet, and to accomplish that, i915_gem_object_wait_migration()
+ * must be called.
+ *
+ * This function is a bit more permissive than i915_gem_object_can_migrate()
+ * to allow for migrating objects where the caller knows exactly what is
+ * happening. For example within selftests. More specifically this
+ * function allows migrating I915_BO_ALLOC_USER objects to regions
+ * that are not in the list of allowable regions.
+ *
+ * Note: the @ww parameter is not used yet, but included to make sure
+ * callers put some effort into obtaining a valid ww ctx if one is
+ * available.
+ *
+ * Return: 0 on success. Negative error code on failure. In particular may
+ * return -ENXIO on lack of region space, -EDEADLK for deadlock avoidance
+ * if @ww is set, -EINTR or -ERESTARTSYS if signal
[Intel-gfx] [PATCH v4 0/3] drm/i915/gem: Introduce a migrate interface
We want to be able to explicitly migrate objects between gem memory regions, initially for display and dma-buf, but there might be more use-cases coming up. Introduce a gem migrate interface, add a selftest and use it for display fb pinning and dma-buf mapping. This series should make accelerated desktop work on DG1 with DG1-enabled OpenGL. v2: - Address review comments by Matthew Auld on patch 1/5. More details on the patch commit message. - Address a dma-buf locking issue pointed out by Michael Ruhl, and add a selftest to catch that issue moving forward. - Rebase the dma-buf migration patch on the above-mentioned fix. v3: - Fix i915_gem_object_can_migrate() to return true if object is already in the correct region, even if the object ops doesn't have a migrate() callback. - Update typo in commit message. v4: - Ditch dma-buf patches for now. - Improve documentation (Suggested by Mattew Auld and Michael Ruhl) - Always assume TTM migration hits a TTM move and unsets the pages through move_notify. (Reported by Matthew Auld) - Add a dma_fence_might_wait() annotation to i915_gem_object_wait_migration() (Suggested by Daniel Vetter) - Selftest updates (See specifics on that patch). - Added R-Bs Matthew Auld (1): drm/i915/gem: Introduce a selftest for the gem object migrate functionality Thomas Hellström (2): drm/i915/gem: Implement object migration drm/i915/display: Migrate objects to LMEM if possible for display drivers/gpu/drm/i915/display/intel_display.c | 5 +- drivers/gpu/drm/i915/gem/i915_gem_domain.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 21 -- drivers/gpu/drm/i915/gem/i915_gem_object.c| 113 drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +- .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 + drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 77 +- drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19 ++ .../drm/i915/gem/selftests/i915_gem_migrate.c | 258 ++ .../drm/i915/selftests/i915_live_selftests.h | 1 + 10 files changed, 481 insertions(+), 36 deletions(-) create mode 100644 drivers/gpu/drm/i915/gem/selftests/i915_gem_migrate.c -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
On Tue, 29 Jun 2021 08:12:54 + Simon Ser wrote: > On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen > wrote: > > > yes, I think this makes sense, even if it is a property that one can't > > tell for sure what it does before hand. > > > > Using a pair of properties, preference and active, to ask for something > > and then check what actually worked is good for reducing the > > combinatorial explosion caused by needing to "atomic TEST_ONLY commit" > > test different KMS configurations. Userspace has a better chance of > > finding a configuration that is possible. > > > > OTOH, this has the problem than in UI one cannot tell the user in > > advance which options are truly possible. Given that KMS properties are > > rarely completely independent, and in this case known to depend on > > several other KMS properties, I think it is good enough to know after > > the fact. > > > > If a driver does not use what userspace prefers, there is no way to > > understand why, or what else to change to make it happen. That problem > > exists anyway, because TEST_ONLY commits do not give useful feedback > > but only a yes/no. > > By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one > property at a time), user-space can discover which property makes the atomic > commit fail. That works if the properties are independent of each other. Color range, color format, bpc and more may all be interconnected, allowing only certain combinations to work. If all these properties have "auto" setting too, then it would be possible to probe each property individually, but that still does not tell which combinations are valid. If you probe towards a certain configuration by setting the properties one by one, then depending on the order you pick the properties, you may come to a different conclusion on which property breaks the configuration. > I'm not a fan of this "preference" property approach. The only way to find out > whether it's possible to change the color format is to perform a user-visible > change (with a regular atomic commit) and check whether it worked > after-the-fact. This is unlike all other existing KMS properties. I agree. FWIW, "max bpc" exists already. > I'd much rather see a more general approach to fix this combinatorial > explosion > than to add special-cases like this. What would you suggest? Maybe all properties should have an "auto" value in addition to the explicit no-negotiation values where at all possible? That might help probing each property individually with TEST_ONLY commits, but it says nothing about combinations. A feedback list perhaps? TEST_ONLY commit somehow returning a list of property/value tuples indicating what value the "auto" valued properties actually get? What should a kernel driver optimize for when determining "auto" values? Thanks, pq pgpfbFvx4TeQP.pgp Description: OpenPGP digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/jsl: Remove require_force_probe protection
Removing force probe protection from JSL platform. Did
not observe warnings, errors, flickering or any visual
defects while doing ordinary tasks like browsing and
editing documents in a two monitor setup.
For more info drm-tip idle run results :
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?
Cc: Chris Wilson
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f1f43192f9fb..bc3c14ce92f7 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -853,7 +853,6 @@ static const struct intel_device_info ehl_info = {
static const struct intel_device_info jsl_info = {
GEN11_FEATURES,
PLATFORM(INTEL_JASPERLAKE),
- .require_force_probe = 1,
.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0),
.ppgtt_size = 36,
};
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 03/17] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
Am 28.06.21 um 19:03 schrieb Werner Sembach:
> Am 18.06.21 um 11:11 schrieb Werner Sembach:
>> 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
>> best/highest color depth within the max bpc setting a user might not be
>> fully aware what his hardware is or isn't capable off. This is meant as a
>> quick way to double check the setup.
>>
>> In the future, automatic color calibration for screens might also depend on
>> this information being available.
>>
>> Signed-off-by: Werner Sembach
>> ---
>> drivers/gpu/drm/drm_connector.c | 51 +
>> include/drm/drm_connector.h | 8 ++
>> 2 files changed, 59 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_connector.c
>> b/drivers/gpu/drm/drm_connector.c
>> index da39e7ff6965..943f6b61053b 100644
>> --- a/drivers/gpu/drm/drm_connector.c
>> +++ b/drivers/gpu/drm/drm_connector.c
>> @@ -1197,6 +1197,14 @@ static const struct drm_prop_enum_list
>> dp_colorspaces[] = {
>> * drm_connector_attach_max_bpc_property() to create and attach the
>> * property to the connector during initialization.
>> *
>> + * active bpc:
>> + * This read-only range property tells userspace the pixel color bit depth
>> + * actually used by the hardware display engine on "the cable" on a
>> + * connector. The chosen value depends on hardware capabilities, both
>> + * display engine and connected monitor, and the "max bpc" property.
>> + * Drivers shall use drm_connector_attach_active_bpc_property() to install
>> + * this property.
>> + *
> Regarding "on the cable" and dithering: As far as I can tell, what the
> dithering option does, is setting a hardware
> register here:
>
> -
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4534
>
> -
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4571
>
> So dithering seems to be calculated by fixed purpose hardware/firmware
> outside of the driver?
>
> The Intel driver does not seem to set a target bpc/bpp for this hardware so I
> guess it defaults to 6 or 8 bpc?
Never mind it does. This switch-case does affect the dithering output:
https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/i915/display/intel_display.c#L4537
As found in this documentation p.548:
https://01.org/sites/default/files/documentation/intel-gfx-prm-osrc-lkf-vol02c-commandreference-registers-part2.pdf
So max bpc and active bpc are affecting/affected by the bpc after dithering.
>
> Similar things happen on amd. Here the output dither depth seems to be
> written to a fixed value however:
>
> -
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L828
>
> -
> https://elixir.bootlin.com/linux/v5.13/source/drivers/gpu/drm/amd/display/dc/dce/dce_transform.c#L769
>
> Does anyone know about a resource where I can read up on the used registers
> and what this hardware actually does?
Searching now for a similar register reference for AMD GPUs.
>
> My proposal for now: "max bpc" affects what happens before dither, so I would
> keep "active bpc" the same and add another
> drm property "dither active: true/false". No additional property to control
> dither, as amdgpu does have one already
> (which isn't always active?) and Intel driver does only seem prepared for
> dithering at 6bpc (albeit I don't know why to
> dither at 6bpc and what depth to dither to?).
>
>> * Connectors also have one standardized atomic property:
>> *
>> * CRTC_ID:
>> @@ -2152,6 +2160,49 @@ int drm_connector_attach_max_bpc_property(struct
>> drm_connector *connector,
>> }
>> EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
>>
>> +/**
>> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
>> + * @connector: connector to attach active bpc property on.
>> + * @min: The minimum bit depth supported by the connector.
>> + * @max: The maximum bit depth supported by the connector.
>> + *
>> + * This is used to check the applied bit depth on a connector.
>> + *
>> + * Returns:
>> + * Zero on success, negative errno on failure.
>> + */
>> +int drm_connector_attach_active_bpc_property(struct drm_connector
>> *connector, int min, int max)
>> +{
>> +struct drm_device *dev = connector->dev;
>> +struct drm_property *prop;
>> +
>> +if (!connector->active_bpc_property) {
>> +prop = drm_property_create_range(dev, DRM_MODE_PROP_IMMUTABLE,
>> "active bpc",
>> + min, max);
>> +if (!prop)
>> +return -ENOMEM;
>> +
>> +connector->active_bpc_property = prop;
>> +drm_object_attach_property(>base, prop, 0);
>> +}
>> +
>> +
[Intel-gfx] [PATCH] drm/i915/ehl: Remove require_force_probe protection
Removing force probe protection from EHL platform. Did
not observe warnings, errors, flickering or any visual
defects while doing ordinary tasks like browsing and
editing documents in a two monitor setup.
For more info drm-tip idle run results :
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip.html?
Cc: Chris Wilson
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f1f43192f9fb..7d472611a190 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -845,7 +845,6 @@ static const struct intel_device_info icl_info = {
static const struct intel_device_info ehl_info = {
GEN11_FEATURES,
PLATFORM(INTEL_ELKHARTLAKE),
- .require_force_probe = 1,
.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(VCS0) | BIT(VECS0),
.ppgtt_size = 36,
};
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 19/27] drm/stm: Don't set struct drm_device.irq_enabled
Hello Thomas, thanks for the patch. Tested-by: Yannick Fertre Best regards On 6/25/21 10:22 AM, Thomas Zimmermann wrote: The field drm_device.irq_enabled is only used by legacy drivers with userspace modesetting. Don't set it in stm. Signed-off-by: Thomas Zimmermann Reviewed-by: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/stm/ltdc.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c index 08b71248044d..e9c5a52f041a 100644 --- a/drivers/gpu/drm/stm/ltdc.c +++ b/drivers/gpu/drm/stm/ltdc.c @@ -1339,9 +1339,6 @@ int ltdc_load(struct drm_device *ddev) goto err; } - /* Allow usage of vblank without having to call drm_irq_install */ - ddev->irq_enabled = 1; - clk_disable_unprepare(ldev->pixel_clk); pinctrl_pm_select_sleep_state(ddev->dev); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 4/5] drm/i915/gem: Fix same-driver-another-instance dma-buf export
On 6/29/21 10:43 AM, Daniel Vetter wrote:
On Mon, Jun 28, 2021 at 07:45:31PM +, Ruhl, Michael J wrote:
-Original Message-
From: Thomas Hellström
Sent: Monday, June 28, 2021 10:46 AM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Cc: Auld, Matthew ;
maarten.lankho...@linux.intel.com; Thomas Hellström
; Ruhl; Ruhl, Michael J
Subject: [PATCH v3 4/5] drm/i915/gem: Fix same-driver-another-instance
dma-buf export
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to recursive locking.
Add a live selftest to catch this case, and as a workaround until
we fully support dynamic import and export, declare the exporter dynamic
by providing NOP pin() and unpin() functions. This means our map_dma_buf()
callback will *always* get called locked, and by pinning unconditionally
in i915_gem_map_dma_buf() we make sure we don't need to use the
move_notify() functionality which is not yet implemented.
An interesting abuse of the interface, but it seems reasonable (for now) to me.
Hm I'm not sure this is the best interface abuse, since if we combine this
with amdgpu it goes boom. Also I thought the dynamic stuff is optional (or
is that only for the importer).
I'm not sure what would go wrong here when combined with amdgpu? I
figure an amdgpu importer being dynamic, would expect to get notified
using move_notify() on move, but that never happens since the exported
bo is pinned. If it matters for interface abuse then I could add real
implementations of pin() and unpin(). But choosing to not evict a mapped
dma-buf must remain at the exporter's discretion and is not an interface
abuse IMO.
Could you point me to a case that would not work with this code?
What I discussed a bit with Maarten on irc is to essentially emulate the
rules of what a dynamic exporter would end up with with a non-dynamic
importer: pin/unpin the buffer at attach/detach time. We could fake this
in our attach/detach callbacks.
Yes, but that would only reimplement what's already in the dma-buf core?
Since we're about to add a real and correct implementation of this, that
sounds like a waste of time IMHO.
At least I don't think it's the locking changes that saves us here, but
the caching of the sgt list in attach/detach.
Yes that saves us for the case of a non-locking non-dynamic importer,
but for same-driver-another-instance, it's indeed the locking changes.
As long as we hand-roll that
we should be fine. So hand-rolling that feels like the best option to make
sure we're not making this worse, as long as we haven't fully validated
the true dynamic importer _and_ exporter case.
/Thomas
Cheers, Daniel
Reviewed-by: Michael J. Ruhl
Mike
Reported-by: Ruhl, Michael J
Cc: Ruhl, Michael J
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 ++-
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 81
++-
2 files changed, 108 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 616c3a2f1baf..1d1eeb167d28 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -12,6 +12,8 @@
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
+I915_SELFTEST_DECLARE(static bool force_different_devices;)
+
static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
{
return to_intel_bo(buf->priv);
@@ -25,7 +27,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
struct scatterlist *src, *dst;
int ret, i;
- ret = i915_gem_object_pin_pages_unlocked(obj);
+ assert_object_held(obj);
+
+ ret = i915_gem_object_pin_pages(obj);
if (ret)
goto err;
@@ -168,6 +172,26 @@ static int i915_gem_end_cpu_access(struct dma_buf
*dma_buf, enum dma_data_direct
return err;
}
+/*
+ * As a workaround until we fully support dynamic import and export,
+ * declare the exporter dynamic by providing NOP pin() and unpin()
functions.
+ * This means our i915_gem_map_dma_buf() callback will *always* get
called
+ * locked, and by pinning unconditionally in i915_gem_map_dma_buf() we
make
+ * sure we don't need to use the move_notify() functionality which is
+ * not yet implemented. Typically for the same-driver-another-instance case,
+ * i915_gem_map_dma_buf() will be called at importer attach time and the
+ * mapped sg_list will be cached by the dma-buf core for the
+ * duration of the attachment.
+ */
+static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
+{
+ return 0;
+}
+
+static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
+{
+}
+
static const struct dma_buf_ops i915_dmabuf_ops = {
Re: [Intel-gfx] [PATCH 1/4] Klock work Fix for NULL dereferencing in i915_gem_ttm.c
On 2021-06-28 at 20:08:26 +0530, Bommu Krishnaiah wrote: > Signed-off-by: Bommu Krishnaiah > Cc: Maarten Lankhorst > --- > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > index c39d982c4fa66..97093a9bfccc2 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c > @@ -590,6 +590,7 @@ static unsigned long i915_ttm_io_mem_pfn(struct > ttm_buffer_object *bo, > GEM_WARN_ON(bo->ttm); > > sg = __i915_gem_object_get_sg(obj, >ttm.get_io_page, page_offset, > , true, true); > + GEM_BUG_ON(!sg); IMHO this looks good to have as this is member of ttm_device_funcs. As i am not aware of the callers intentions and requirement check, i leave this to Maarten. Ram > > return ((base + sg_dma_address(sg)) >> PAGE_SHIFT) + ofs; > } > -- > 2.25.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] Klock work Fix for NULL dereferencing in i915_gem_mman.c
On 2021-06-28 at 20:08:27 +0530, Bommu Krishnaiah wrote:
> Signed-off-by: Bommu Krishnaiah
> Cc: Abdiel Janulgue
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index a90f796e85c03..cad33cd49ba95 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -961,6 +961,8 @@ int i915_gem_mmap(struct file *filp, struct
> vm_area_struct *vma)
>
> vma->vm_private_data = mmo;
>
> + GEM_BUG_ON(!mmo);
> +
This also looks false positive to me. As mmo is dereferenced only when
the if (!node->driver_private && !obj->ops->mmap_ops)
when node->driver_private is true but obj->ops->mmap_ops is not true
then mmo will be NULL. Which is already captured as GEM_BUG_ON(obj &&
!obj->ops->mmap_ops);
So we can ignore this too.
Ram
> switch (mmo->mmap_type) {
> case I915_MMAP_TYPE_WC:
> vma->vm_page_prot =
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/dsc: Set BPP in the kernel (rev2)
== Series Details ==
Series: drm/i915/display/dsc: Set BPP in the kernel (rev2)
URL : https://patchwork.freedesktop.org/series/91917/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10285_full -> Patchwork_20482_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20482_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20482_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20482_full:
### IGT changes ###
Possible regressions
* igt@kms_big_fb@y-tiled-64bpp-rotate-180:
- shard-glk: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-glk3/igt@kms_big...@y-tiled-64bpp-rotate-180.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-glk3/igt@kms_big...@y-tiled-64bpp-rotate-180.html
* {igt@kms_dp_dsc@dsc-15bpp-compression-xrgb} (NEW):
- shard-tglb: NOTRUN -> [SKIP][3] +14 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-tglb7/igt@kms_dp_...@dsc-15bpp-compression-xrgb.html
* {igt@kms_dp_dsc@dsc-22bpp-compression-xrgb} (NEW):
- shard-iclb: NOTRUN -> [SKIP][4] +15 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-iclb6/igt@kms_dp_...@dsc-22bpp-compression-xrgb.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- {shard-rkl-6}: NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_mmap_wc@set-cache-level:
- {shard-rkl-2}: NOTRUN -> [SKIP][6] +59 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-2/igt@gem_mmap...@set-cache-level.html
* igt@kms_busy@basic:
- {shard-rkl-5}: NOTRUN -> [SKIP][7] +49 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-5/igt@kms_b...@basic.html
* {igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs}:
- {shard-rkl-6}: NOTRUN -> [SKIP][8] +10 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-6/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_ccs.html
* {igt@kms_ccs@pipe-b-bad-pixel-format-yf_tiled_ccs}:
- {shard-rkl-1}: NOTRUN -> [FAIL][9] +49 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-1/igt@kms_ccs@pipe-b-bad-pixel-format-yf_tiled_ccs.html
* {igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_mc_ccs}:
- {shard-rkl-5}: NOTRUN -> [FAIL][10] +21 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-5/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html
* {igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_ccs}:
- {shard-rkl-2}: NOTRUN -> [FAIL][11] +31 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-2/igt@kms_ccs@pipe-d-crc-sprite-planes-basic-y_tiled_ccs.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs:
- {shard-rkl-1}: NOTRUN -> [INCOMPLETE][12] +1 similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-1/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-32bpp-ytilegen12rcccs.html
* igt@kms_flip_scaled_crc@flip-32bpp-ytile-to-64bpp-ytile:
- {shard-rkl-5}: NOTRUN -> [INCOMPLETE][13]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-5/igt@kms_flip_scaled_...@flip-32bpp-ytile-to-64bpp-ytile.html
* igt@kms_flip_scaled_crc@flip-64bpp-ytile-to-32bpp-ytilercccs:
- {shard-rkl-2}: NOTRUN -> [INCOMPLETE][14]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-2/igt@kms_flip_scaled_...@flip-64bpp-ytile-to-32bpp-ytilercccs.html
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-render:
- {shard-rkl-1}: NOTRUN -> [SKIP][15] +253 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-1/igt@kms_frontbuffer_track...@fbc-rgb101010-draw-render.html
* igt@runner@aborted:
- {shard-rkl-2}: [FAIL][16] ([i915#3002]) -> [FAIL][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/shard-rkl-2/igt@run...@aborted.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/shard-rkl-2/igt@run...@aborted.html
New tests
-
New tests have been introduced between CI_DRM_10285_full and
Patchwork_20482_full:
### New
Re: [Intel-gfx] [PATCH 4/4] Klock work Fix for uninitialized array intel_migrate.c
On 2021-06-28 at 20:08:29 +0530, Bommu Krishnaiah wrote:
> Signed-off-by: Bommu Krishnaiah
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_migrate.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> index 23c59ce66cee5..5df7b8af6fdb9 100644
> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> @@ -208,11 +208,15 @@ static struct intel_context *__migrate_engines(struct
> intel_gt *gt)
>
> count = 0;
> for (i = 0; i < ARRAY_SIZE(gt->engine_class[COPY_ENGINE_CLASS]); i++) {
> +
> engine = gt->engine_class[COPY_ENGINE_CLASS][i];
> if (engine_supports_migration(engine))
> engines[count++] = engine;
> }
>
> + if (count == 0)
> + return ERR_PTR(-ENXIO);
> +
> return intel_context_create(engines[random_index(count)]);
This Kclockwork warning/error is false positive.
As intel_migrate_copy->intel_migrate_create_context->__migrate_engines is called
after the checkfor valid m->context which is created for first copy engine.
So atleast one blitter is assured. hence we can ignore this Kclockwork
result.
Ram.
> }
>
> --
> 2.25.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 1/5] drm/i915/gem: Implement object migration
On Mon, Jun 28, 2021 at 04:46:22PM +0200, Thomas Hellström wrote:
> Introduce an interface to migrate objects between regions.
> This is primarily intended to migrate objects to LMEM for display and
> to SYSTEM for dma-buf, but might be reused in one form or another for
> performance-based migration.
>
> v2:
> - Verify that the memory region given as an id really exists.
> (Reported by Matthew Auld)
> - Call i915_gem_object_{init,release}_memory_region() when switching region
> to handle also switching region lists. (Reported by Matthew Auld)
> v3:
> - Fix i915_gem_object_can_migrate() to return true if object is already in
> the correct region, even if the object ops doesn't have a migrate()
> callback.
> - Update typo in commit message.
> - Fix kerneldoc of i915_gem_object_wait_migration().
>
> Reported-by: kernel test robot
> Signed-off-by: Thomas Hellström
Looks reasonable to me as the main interface. I'm a bit on the fence on
hiding everything behind obj->ops, since we're not going to have another
implementation of migrate than the ttm one. But also while everything is
in-flight it's probably good to at least try and maintain some boundaries,
for otherwise the messiness might become unmanageable
Acked-by: Daniel Vetter
But don't count this as real review :-)
One suggestion at the very bottom.
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 96 +++
> drivers/gpu/drm/i915/gem/i915_gem_object.h| 12 +++
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 9 ++
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 69 +
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 19
> 5 files changed, 188 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 07e8ff9a8aae..1c18be067b58 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -513,6 +513,102 @@ bool i915_gem_object_has_iomem(const struct
> drm_i915_gem_object *obj)
> return obj->mem_flags & I915_BO_FLAG_IOMEM;
> }
>
> +/**
> + * i915_gem_object_can_migrate - Whether an object likely can be migrated
> + *
> + * @obj: The object to migrate
> + * @id: The region intended to migrate to
> + *
> + * Check whether the object backend supports migration to the
> + * given region. Note that pinning may affect the ability to migrate.
> + *
> + * Return: true if migration is possible, false otherwise.
> + */
> +bool i915_gem_object_can_migrate(struct drm_i915_gem_object *obj,
> + enum intel_region_id id)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + unsigned int num_allowed = obj->mm.n_placements;
> + struct intel_memory_region *mr;
> + unsigned int i;
> +
> + GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
> + GEM_BUG_ON(obj->mm.madv != I915_MADV_WILLNEED);
> +
> + mr = i915->mm.regions[id];
> + if (!mr)
> + return false;
> +
> + if (obj->mm.region == mr)
> + return true;
> +
> + if (!i915_gem_object_evictable(obj))
> + return false;
> +
> + if (!obj->ops->migrate)
> + return false;
> +
> + if (!(obj->flags & I915_BO_ALLOC_USER))
> + return true;
> +
> + if (num_allowed == 0)
> + return false;
> +
> + for (i = 0; i < num_allowed; ++i) {
> + if (mr == obj->mm.placements[i])
> + return true;
> + }
> +
> + return false;
> +}
> +
> +/**
> + * i915_gem_object_migrate - Migrate an object to the desired region id
> + * @obj: The object to migrate.
> + * @ww: An optional struct i915_gem_ww_ctx. If NULL, the backend may
> + * not be successful in evicting other objects to make room for this object.
> + * @id: The region id to migrate to.
> + *
> + * Attempt to migrate the object to the desired memory region. The
> + * object backend must support migration and the object may not be
> + * pinned, (explicitly pinned pages or pinned vmas). The object must
> + * be locked.
> + * On successful completion, the object will have pages pointing to
> + * memory in the new region, but an async migration task may not have
> + * completed yet, and to accomplish that, i915_gem_object_wait_migration()
> + * must be called.
> + *
> + * Return: 0 on success. Negative error code on failure. In particular may
> + * return -ENXIO on lack of region space, -EDEADLK for deadlock avoidance
> + * if @ww is set, -EINTR or -ERESTARTSYS if signal pending, and
> + * -EBUSY if the object is pinned.
> + */
> +int i915_gem_object_migrate(struct drm_i915_gem_object *obj,
> + struct i915_gem_ww_ctx *ww,
> + enum intel_region_id id)
> +{
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct intel_memory_region *mr;
> +
> + GEM_BUG_ON(id >= INTEL_REGION_UNKNOWN);
> + GEM_BUG_ON(obj->mm.madv !=
Re: [Intel-gfx] [PATCH v3 4/5] drm/i915/gem: Fix same-driver-another-instance dma-buf export
On Mon, Jun 28, 2021 at 07:45:31PM +, Ruhl, Michael J wrote:
> >-Original Message-
> >From: Thomas Hellström
> >Sent: Monday, June 28, 2021 10:46 AM
> >To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> >Cc: Auld, Matthew ;
> >maarten.lankho...@linux.intel.com; Thomas Hellström
> >; Ruhl; Ruhl, Michael J
> >
> >Subject: [PATCH v3 4/5] drm/i915/gem: Fix same-driver-another-instance
> >dma-buf export
> >
> >If our exported dma-bufs are imported by another instance of our driver,
> >that instance will typically have the imported dma-bufs locked during
> >map_attachment(). But the exporter also locks the same reservation
> >object in the map_dma_buf() callback, which leads to recursive locking.
> >
> >Add a live selftest to catch this case, and as a workaround until
> >we fully support dynamic import and export, declare the exporter dynamic
> >by providing NOP pin() and unpin() functions. This means our map_dma_buf()
> >callback will *always* get called locked, and by pinning unconditionally
> >in i915_gem_map_dma_buf() we make sure we don't need to use the
> >move_notify() functionality which is not yet implemented.
>
> An interesting abuse of the interface, but it seems reasonable (for now) to
> me.
Hm I'm not sure this is the best interface abuse, since if we combine this
with amdgpu it goes boom. Also I thought the dynamic stuff is optional (or
is that only for the importer).
What I discussed a bit with Maarten on irc is to essentially emulate the
rules of what a dynamic exporter would end up with with a non-dynamic
importer: pin/unpin the buffer at attach/detach time. We could fake this
in our attach/detach callbacks.
At least I don't think it's the locking changes that saves us here, but
the caching of the sgt list in attach/detach. As long as we hand-roll that
we should be fine. So hand-rolling that feels like the best option to make
sure we're not making this worse, as long as we haven't fully validated
the true dynamic importer _and_ exporter case.
Cheers, Daniel
> Reviewed-by: Michael J. Ruhl
>
> Mike
>
> >Reported-by: Ruhl, Michael J
> >Cc: Ruhl, Michael J
> >Signed-off-by: Thomas Hellström
> >---
> > drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 31 ++-
> > .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 81
> >++-
> > 2 files changed, 108 insertions(+), 4 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> >b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> >index 616c3a2f1baf..1d1eeb167d28 100644
> >--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> >+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> >@@ -12,6 +12,8 @@
> > #include "i915_gem_object.h"
> > #include "i915_scatterlist.h"
> >
> >+I915_SELFTEST_DECLARE(static bool force_different_devices;)
> >+
> > static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
> > {
> > return to_intel_bo(buf->priv);
> >@@ -25,7 +27,9 @@ static struct sg_table *i915_gem_map_dma_buf(struct
> >dma_buf_attachment *attachme
> > struct scatterlist *src, *dst;
> > int ret, i;
> >
> >-ret = i915_gem_object_pin_pages_unlocked(obj);
> >+assert_object_held(obj);
> >+
> >+ret = i915_gem_object_pin_pages(obj);
> > if (ret)
> > goto err;
> >
> >@@ -168,6 +172,26 @@ static int i915_gem_end_cpu_access(struct dma_buf
> >*dma_buf, enum dma_data_direct
> > return err;
> > }
> >
> >+/*
> >+ * As a workaround until we fully support dynamic import and export,
> >+ * declare the exporter dynamic by providing NOP pin() and unpin()
> >functions.
> >+ * This means our i915_gem_map_dma_buf() callback will *always* get
> >called
> >+ * locked, and by pinning unconditionally in i915_gem_map_dma_buf() we
> >make
> >+ * sure we don't need to use the move_notify() functionality which is
> >+ * not yet implemented. Typically for the same-driver-another-instance case,
> >+ * i915_gem_map_dma_buf() will be called at importer attach time and the
> >+ * mapped sg_list will be cached by the dma-buf core for the
> >+ * duration of the attachment.
> >+ */
> >+static int i915_gem_dmabuf_pin(struct dma_buf_attachment *attach)
> >+{
> >+return 0;
> >+}
> >+
> >+static void i915_gem_dmabuf_unpin(struct dma_buf_attachment *attach)
> >+{
> >+}
> >+
> > static const struct dma_buf_ops i915_dmabuf_ops = {
> > .map_dma_buf = i915_gem_map_dma_buf,
> > .unmap_dma_buf = i915_gem_unmap_dma_buf,
> >@@ -177,6 +201,8 @@ static const struct dma_buf_ops i915_dmabuf_ops = {
> > .vunmap = i915_gem_dmabuf_vunmap,
> > .begin_cpu_access = i915_gem_begin_cpu_access,
> > .end_cpu_access = i915_gem_end_cpu_access,
> >+.pin = i915_gem_dmabuf_pin,
> >+.unpin = i915_gem_dmabuf_unpin,
> > };
> >
> > struct dma_buf *i915_gem_prime_export(struct drm_gem_object
> >*gem_obj, int flags)
> >@@ -241,7 +267,8 @@ struct drm_gem_object
> >*i915_gem_prime_import(struct drm_device *dev,
> > if (dma_buf->ops == _dmabuf_ops) {
> > obj =
Re: [Intel-gfx] [PATCH 0/4] The Following Patches are to Fix the Critical KclockWork Errors in i915_gem and gt
each patch's commit message is empty except for signed-off and cc. Please provide corresponding KclockWork Errors that is getting fixed. Ram. On 2021-06-28 at 20:08:25 +0530, Bommu Krishnaiah wrote: > Klock work Fix for NULL dereferencing in i915_gem_ttm.c > original issue statement "Pointer 'sg' returned from call to function > '__i915_gem_object_get_sg' at line 592 may be NULL and will be dereferenced > at line 594." > > Klock work Fix for NULL dereferencing in i915_gem_mman.c > original issue statement "Null pointer 'mmo' that comes from line 892 may be > dereferenced at line 964." > > Klock work Fix for possible memory leak in intel_execlists_submission.c > original issue statement “Possible memory leak. Dynamic memory stored in 've' > allocated through function 'kzalloc' at line 3721 can be lost at line 3850” > > Klock work Fix for uninitialized array intel_migrate.c > original issue statement "'engines' array elements might be used > uninitialized in this function." > > Bommu Krishnaiah (4): > Klock work Fix for NULL dereferencing in i915_gem_ttm.c > Klock work Fix for NULL dereferencing in i915_gem_mman.c > Klock work Fix for possible memory leak in > intel_execlists_submission.c > Klock work Fix for uninitialized array intel_migrate.c > > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 ++ > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 1 + > drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 1 + > drivers/gpu/drm/i915/gt/intel_migrate.c | 4 > 4 files changed, 8 insertions(+) > > -- > 2.25.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 12/17] drm/uAPI: Add "preferred color format" drm property as setting for userspace
On Tuesday, June 22nd, 2021 at 09:15, Pekka Paalanen wrote: > yes, I think this makes sense, even if it is a property that one can't > tell for sure what it does before hand. > > Using a pair of properties, preference and active, to ask for something > and then check what actually worked is good for reducing the > combinatorial explosion caused by needing to "atomic TEST_ONLY commit" > test different KMS configurations. Userspace has a better chance of > finding a configuration that is possible. > > OTOH, this has the problem than in UI one cannot tell the user in > advance which options are truly possible. Given that KMS properties are > rarely completely independent, and in this case known to depend on > several other KMS properties, I think it is good enough to know after > the fact. > > If a driver does not use what userspace prefers, there is no way to > understand why, or what else to change to make it happen. That problem > exists anyway, because TEST_ONLY commits do not give useful feedback > but only a yes/no. By submitting incremental atomic reqs with TEST_ONLY (i.e. only changing one property at a time), user-space can discover which property makes the atomic commit fail. I'm not a fan of this "preference" property approach. The only way to find out whether it's possible to change the color format is to perform a user-visible change (with a regular atomic commit) and check whether it worked after-the-fact. This is unlike all other existing KMS properties. I'd much rather see a more general approach to fix this combinatorial explosion than to add special-cases like this. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/dsc: Set BPP in the kernel (rev2)
== Series Details == Series: drm/i915/display/dsc: Set BPP in the kernel (rev2) URL : https://patchwork.freedesktop.org/series/91917/ State : success == Summary == CI Bug Log - changes from CI_DRM_10285 -> Patchwork_20482 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/index.html Known issues Here are the changes found in Patchwork_20482 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [FAIL][1] ([i915#1372]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10285/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 Participating hosts (40 -> 36) -- Missing(4): fi-kbl-soraka fi-bsw-cyan fi-bdw-samus fi-hsw-4200u Build changes - * IGT: IGT_6121 -> IGTPW_5962 * Linux: CI_DRM_10285 -> Patchwork_20482 CI-20190529: 20190529 CI_DRM_10285: e65a658751fc5d3be5b0f4bcc4731e66ca1a537a @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_5962: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5962/index.html IGT_6121: a63ceb48e6c3e733d04156b32fba3b4f4d5ad794 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20482: f9fdb098f2480a719e469ed1f7efa2392db8ec67 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f9fdb098f248 drm/i915/display/dsc: Set BPP in the kernel 8c10d57a92b5 drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20482/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display/dsc: Set BPP in the kernel (rev2)
== Series Details == Series: drm/i915/display/dsc: Set BPP in the kernel (rev2) URL : https://patchwork.freedesktop.org/series/91917/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1893:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/dsc: Set BPP in the kernel (rev2)
== Series Details ==
Series: drm/i915/display/dsc: Set BPP in the kernel (rev2)
URL : https://patchwork.freedesktop.org/series/91917/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
8c10d57a92b5 drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP
enable
-:71: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#71: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2433:
+ seq_printf(m, "Compressed_BPP: %d\n",
+ crtc_state->dsc.compressed_bpp);
-:81: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#81: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2443:
+static ssize_t i915_dsc_bpp_support_write(struct file *file,
+ const char __user *ubuf,
-:109: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#109: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2471:
+static int i915_dsc_bpp_support_open(struct inode *inode,
+ struct file *file)
-:138: WARNING:SYMBOLIC_PERMS: Symbolic permissions 'S_IRUGO' are not
preferred. Consider using octal permissions '0444'.
#138: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2530:
+ debugfs_create_file("i915_dsc_bpp_support", S_IRUGO,
total: 0 errors, 1 warnings, 3 checks, 124 lines checked
f9fdb098f248 drm/i915/display/dsc: Set BPP in the kernel
-:26: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#26: FILE: drivers/gpu/drm/i915/display/intel_dp.c:1246:
+ drm_dbg_kms(_priv->drm,
+ "DSC BPP forced to %d",
intel_dp->force_dsc_bpp);
-:31: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#31: FILE: drivers/gpu/drm/i915/display/intel_dp.c:1251:
+ min_t(u16,
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
+ pipe_config->pipe_bpp);
-:47: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#47: FILE: drivers/gpu/drm/i915/display/intel_dp.c:1284:
+ pipe_config->dsc.compressed_bpp = min_t(u16,
dsc_max_output_bpp >> 4,
total: 0 errors, 0 warnings, 3 checks, 43 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable
From: Anusha Srivatsa
DSC can be supported per DP connector. 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.
force_dsc_bpp is written through this debugfs
node to force DSC BPP to all accepted values
Cc: Vandita Kulkarni
Cc: Navare Manasi D
Signed-off-by: Anusha Srivatsa
Signed-off-by: Patnana Venkata Sai
---
.../drm/i915/display/intel_display_debugfs.c | 103 +-
.../drm/i915/display/intel_display_types.h| 1 +
2 files changed, 103 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index af9e58619667d..6dc223227eeaa 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2389,6 +2389,100 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct drm_device *dev = connector->dev;
+ struct drm_crtc *crtc;
+ struct intel_dp *intel_dp;
+ struct drm_modeset_acquire_ctx ctx;
+ struct intel_crtc_state *crtc_state = NULL;
+ int ret = 0;
+ bool try_again = false;
+
+ drm_modeset_acquire_init(, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
+
+ do {
+ try_again = false;
+ ret = drm_modeset_lock(>mode_config.connection_mutex,
+ );
+ if (ret) {
+ ret = -EINTR;
+ break;
+ }
+ crtc = connector->state->crtc;
+ if (connector->status != connector_status_connected || !crtc) {
+ ret = -ENODEV;
+ break;
+ }
+ ret = drm_modeset_lock(>mutex, );
+ if (ret == -EDEADLK) {
+ ret = drm_modeset_backoff();
+ if (!ret) {
+ try_again = true;
+ continue;
+ }
+ break;
+ } else if (ret) {
+ break;
+ }
+ intel_dp = intel_attached_dp(to_intel_connector(connector));
+ crtc_state = to_intel_crtc_state(crtc->state);
+ seq_printf(m, "Input_BPP: %d\n", crtc_state->pipe_bpp);
+ seq_printf(m, "Compressed_BPP: %d\n",
+ crtc_state->dsc.compressed_bpp);
+ } while (try_again);
+
+ drm_modeset_drop_locks();
+ drm_modeset_acquire_fini();
+
+ return ret;
+}
+
+static ssize_t i915_dsc_bpp_support_write(struct file *file,
+ const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ int dsc_bpp = 0;
+ int ret;
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+
+ if (len == 0)
+ return 0;
+
+ drm_dbg(>drm,
+ "Copied %zu bytes from user to force BPP\n", len);
+
+ ret = kstrtoint_from_user(ubuf, len, 0, _bpp);
+
+ intel_dp->force_dsc_bpp = dsc_bpp;
+ if (ret < 0)
+ return ret;
+
+ *offp += len;
+ return len;
+}
+
+static int i915_dsc_bpp_support_open(struct inode *inode,
+ struct file *file)
+{
+ return single_open(file, i915_dsc_bpp_support_show,
+ inode->i_private);
+}
+
+static const struct file_operations i915_dsc_bpp_support_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_dsc_bpp_support_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_dsc_bpp_support_write
+};
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2427,9 +2521,16 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
connector, _hdcp_sink_capability_fops);
}
- if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
!to_intel_connector(connector)->mst_port) || connector->connector_type ==
DRM_MODE_CONNECTOR_eDP))
+ if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
+ ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort
[Intel-gfx] [PATCH v2 2/2] drm/i915/display/dsc: Set BPP in the kernel
From: Anusha Srivatsa
Set compress BPP in kernel while connector DP or eDP
Cc: Vandita Kulkarni
Cc: Navare Manasi D
Signed-off-by: Anusha Srivatsa
Signed-off-by: Patnana Venkata Sai
---
drivers/gpu/drm/i915/display/intel_dp.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index f74f70691247b..08205923bff07 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1241,9 +1241,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
pipe_config->lane_count = limits->max_lane_count;
if (intel_dp_is_edp(intel_dp)) {
- pipe_config->dsc.compressed_bpp =
- min_t(u16,
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
- pipe_config->pipe_bpp);
+ if (intel_dp->force_dsc_bpp) {
+ drm_dbg_kms(_priv->drm,
+ "DSC BPP forced to %d",
intel_dp->force_dsc_bpp);
+ pipe_config->dsc.compressed_bpp =
intel_dp->force_dsc_bpp;
+ } else {
+ pipe_config->dsc.compressed_bpp =
+ min_t(u16,
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
+ pipe_config->pipe_bpp);
+ }
pipe_config->dsc.slice_count =
drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
true);
@@ -1269,9 +1275,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
"Compressed BPP/Slice Count not
supported\n");
return -EINVAL;
}
- pipe_config->dsc.compressed_bpp = min_t(u16,
+ if (intel_dp->force_dsc_bpp) {
+ drm_dbg_kms(_priv->drm,
+ "DSC BPP forced to %d\n",
intel_dp->force_dsc_bpp);
+ pipe_config->dsc.compressed_bpp =
intel_dp->force_dsc_bpp;
+ } else {
+ pipe_config->dsc.compressed_bpp = min_t(u16,
dsc_max_output_bpp >> 4,
pipe_config->pipe_bpp);
+ }
pipe_config->dsc.slice_count = dsc_dp_slice_count;
}
/*
@@ -1374,7 +1386,8 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
* Pipe joiner needs compression upto display12 due to BW limitation.
DG2
* onwards pipe joiner can be enabled without compression.
*/
- drm_dbg_kms(>drm, "Force DSC en = %d\n", intel_dp->force_dsc_en);
+ drm_dbg_kms(>drm, "Force DSC en = %d\n Force DSC BPP = %d\n",
+ intel_dp->force_dsc_en, intel_dp->force_dsc_bpp);
if (ret || intel_dp->force_dsc_en || (DISPLAY_VER(i915) < 13 &&
pipe_config->bigjoiner)) {
ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/2] drm/i915/display/dsc: Set BPP in the kernel
From: Patnana Venkata Sai DSC can be supported per DP connector. 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. force_dsc_bpp is written through this debugfs node to force DSC BPP to all accepted values Test-with: <20210622102454.8922-1-venkata.sai.patn...@intel.com> Anusha Srivatsa (2): drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable drm/i915/display/dsc: Set BPP in the kernel .../drm/i915/display/intel_display_debugfs.c | 103 +- .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 23 +++- 3 files changed, 121 insertions(+), 6 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
