Re: [Intel-gfx] [PATCH 3/7] drm/i915/guc: Add GuC <-> kernel time stamp translation information
I have a question on below code. Everything else looked good. Will r-b as soon as we can close on below question ...alan On Wed, 2022-07-27 at 19:20 -0700, john.c.harri...@intel.com wrote: > From: John Harrison > > It is useful to be able to match GuC events to kernel events when > looking at the GuC log. That requires being able to convert GuC > timestamps to kernel time. So, when dumping error captures and/or GuC > logs, include a stamp in both time zones plus the clock frequency. > > Signed-off-by: John Harrison > --- a/drivers/gpu/drm/i915/i915_gpu_error.c > +++ b/drivers/gpu/drm/i915/i915_gpu_error.c > @@ -1675,6 +1678,13 @@ gt_record_uc(struct intel_gt_coredump *gt, >*/ > error_uc->guc_fw.path = kstrdup(uc->guc.fw.path, ALLOW_FAIL); > error_uc->huc_fw.path = kstrdup(uc->huc.fw.path, ALLOW_FAIL); > + > + /* > + * Save the GuC log and include a timestamp reference for converting the > + * log times to system times (in conjunction with the error->boottime > and > + * gt->clock_frequency fields saved elsewhere). > + */ > + error_uc->timestamp = intel_uncore_read(gt->_gt->uncore, > GUCPMTIMESTAMP); Alan:this register is in the GUC-SHIM domain and so unless i am mistaken u might need to ensure we hold a wakeref so that are getting a live value of the real timestamp register that this register is mirror-ing and not a stale snapshot. Or was this already done farther up the stack? Or are we doing the opposite - in which case we should ensure we drop al wakeref prior to this point. (which i am not sure is a reliable method since we wouldnt know what GuC ref was at). > error_uc->guc_log = create_vma_coredump(gt->_gt, uc->guc.log.vma, > "GuC log buffer", compress); >
[Intel-gfx] ✓ Fi.CI.BAT: success for i915/pmu: Wire GuC backend to per-client busyness (rev4)
== Series Details ==
Series: i915/pmu: Wire GuC backend to per-client busyness (rev4)
URL : https://patchwork.freedesktop.org/series/105085/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11970 -> Patchwork_105085v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v4/index.html
Participating hosts (43 -> 30)
--
Missing(13): fi-bdw-samus bat-dg1-6 bat-dg1-5 bat-dg2-8 fi-skl-guc
bat-adlm-1 bat-dg2-9 bat-adlp-6 bat-adlp-4 bat-rplp-1 bat-rpls-1 bat-rpls-2
bat-jsl-1
Known issues
Here are the changes found in Patchwork_105085v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][1] ([fdo#109271] / [fdo#111827])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v4/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6700k2: [DMESG-FAIL][2] ([i915#5334]) -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11970/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v4/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- {fi-ehl-2}: [INCOMPLETE][4] ([i915#5153] / [i915#6106]) ->
[PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11970/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v4/fi-ehl-2/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u: [INCOMPLETE][6] ([i915#146]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11970/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v4/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#5153]: https://gitlab.freedesktop.org/drm/intel/issues/5153
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6106]: https://gitlab.freedesktop.org/drm/intel/issues/6106
Build changes
-
* Linux: CI_DRM_11970 -> Patchwork_105085v4
CI-20190529: 20190529
CI_DRM_11970: 1d7aa8092dbbaef7c6a81903e0432f5b90da4d63 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6613: 209230467200f2fa63a6f71fe626470dd813 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_105085v4: 1d7aa8092dbbaef7c6a81903e0432f5b90da4d63 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
102ffd49f5bd i915/pmu: Wire GuC backend to per-client busyness
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_105085v4/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915/pmu: Wire GuC backend to per-client busyness (rev4)
== Series Details == Series: i915/pmu: Wire GuC backend to per-client busyness (rev4) URL : https://patchwork.freedesktop.org/series/105085/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only disable PMU on stop if not already closed
On Wed, Aug 03, 2022 at 11:03:25PM +, Stuart Summers wrote:
There can be a race in the PMU process teardown vs the
time when the driver is unbound in which the user attempts
to stop the PMU process, but the actual data structure
in the kernel is no longer available. Avoid this use-after-free
by skipping the PMU disable in i915_pmu_event_stop() when
the PMU has already been closed/unregistered by the driver.
Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")
Suggested-by: Tvrtko Ursulin
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_pmu.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 958b37123bf12..0d02f338118e4 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -760,9 +760,17 @@ static void i915_pmu_event_start(struct perf_event *event,
int flags)
static void i915_pmu_event_stop(struct perf_event *event, int flags)
{
+ struct drm_i915_private *i915 =
+ container_of(event->pmu, typeof(*i915), pmu.base);
+ struct i915_pmu *pmu = >pmu;
+
+ if (pmu->closed)
+ goto out;
+
if (flags & PERF_EF_UPDATE)
i915_pmu_event_read(event);
i915_pmu_disable(event);
+out:
event->hw.state = PERF_HES_STOPPED;
}
lgtm
Reviewed-by: Umesh Nerlige Ramappa
Thanks,
Umesh
--
2.25.1
[Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness
From: John Harrison
GuC provides engine_id and last_switch_in ticks for an active context in
the pphwsp. The context image provides a 32 bit total ticks which is the
accumulated by the context (a.k.a. context[CTX_TIMESTAMP]). This
information is used to calculate the context busyness as follows:
If the engine_id is valid, then busyness is the sum of accumulated total
ticks and active ticks. Active ticks is calculated with current gt time
as reference.
If engine_id is invalid, busyness is equal to accumulated total ticks.
Since KMD (CPU) retrieves busyness data from 2 sources - GPU and GuC, a
potential race was highlighted in an earlier review that can lead to
double accounting of busyness. While the solution to this is a wip,
busyness is still usable for platforms running GuC submission.
Remaining work: Enable and test context busyness for
virtual_parent_context_ops and virtual_child_context_ops.
v2: (Tvrtko)
- Use COPS_RUNTIME_ACTIVE_TOTAL
- Add code comment for the race
- Undo local variables initializations
v3:
- Add support for virtual engines based on
https://patchwork.freedesktop.org/series/105227/
v4:
- Update commit message with remaining work.
- Rebase
Signed-off-by: John Harrison
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_context.c | 12 +++-
drivers/gpu/drm/i915/gt/intel_context.h | 6 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 6 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 5 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 65 ++-
drivers/gpu/drm/i915/i915_drm_client.c| 6 +-
6 files changed, 89 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 654a092ed3d6..e2d70a9fdac0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -576,16 +576,24 @@ void intel_context_bind_parent_child(struct intel_context
*parent,
child->parallel.parent = parent;
}
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce)
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
{
u64 total, active;
+ if (ce->ops->update_stats)
+ ce->ops->update_stats(ce);
+
total = ce->stats.runtime.total;
if (ce->ops->flags & COPS_RUNTIME_CYCLES)
total *= ce->engine->gt->clock_period_ns;
active = READ_ONCE(ce->stats.active);
- if (active)
+ /*
+* When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the backend
+* already provides the total active time of the context, so skip this
+* calculation when this flag is set.
+*/
+ if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
active = intel_context_clock() - active;
return total + active;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 8e2d70630c49..3d1d7436c1a4 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -58,7 +58,7 @@ static inline bool intel_context_is_parent(struct
intel_context *ce)
return !!ce->parallel.number_children;
}
-static inline bool intel_context_is_pinned(struct intel_context *ce);
+static inline bool intel_context_is_pinned(const struct intel_context *ce);
static inline struct intel_context *
intel_context_to_parent(struct intel_context *ce)
@@ -118,7 +118,7 @@ static inline int intel_context_lock_pinned(struct
intel_context *ce)
* Returns: true if the context is currently pinned for use by the GPU.
*/
static inline bool
-intel_context_is_pinned(struct intel_context *ce)
+intel_context_is_pinned(const struct intel_context *ce)
{
return atomic_read(>pin_count);
}
@@ -362,7 +362,7 @@ intel_context_clear_nopreempt(struct intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, >flags);
}
-u64 intel_context_get_total_runtime_ns(const struct intel_context *ce);
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
static inline u64 intel_context_clock(void)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 04eacae1aca5..f7ff4c7d81c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -38,6 +38,9 @@ struct intel_context_ops {
#define COPS_RUNTIME_CYCLES_BIT 1
#define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT)
+#define COPS_RUNTIME_ACTIVE_TOTAL_BIT 2
+#define COPS_RUNTIME_ACTIVE_TOTAL BIT(COPS_RUNTIME_ACTIVE_TOTAL_BIT)
+
int (*alloc)(struct intel_context *ce);
void (*revoke)(struct intel_context *ce, struct i915_request *rq,
@@ -56,6 +59,8 @@ struct intel_context_ops {
void (*sched_disable)(struct intel_context *ce);
+ void (*update_stats)(struct intel_context *ce);
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/userptr: remove redundation assignment to variable ret
== Series Details ==
Series: drm/i915/userptr: remove redundation assignment to variable ret
URL : https://patchwork.freedesktop.org/series/106983/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11968_full -> Patchwork_106983v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106983v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106983v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (12 -> 12)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106983v1_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_schedule@deep@rcs0:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-iclb5/igt@gem_exec_schedule@d...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/shard-iclb4/igt@gem_exec_schedule@d...@rcs0.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ppgtt@blt-vs-render-ctxn:
- {shard-rkl}:NOTRUN -> [DMESG-FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/shard-rkl-5/igt@gem_pp...@blt-vs-render-ctxn.html
Known issues
Here are the changes found in Patchwork_106983v1_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
[PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13],
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19],
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25],
[PASS][26], [PASS][27], [PASS][28]) -> ([PASS][29], [PASS][30], [PASS][31],
[PASS][32], [PASS][33], [PASS][34], [FAIL][35], [PASS][36], [PASS][37],
[PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43],
[PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49],
[PASS][50], [PASS][51], [PASS][52], [PASS][53]) ([i915#4392])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk5/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk9/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk9/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk9/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk9/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk8/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk8/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk8/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk7/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk7/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk7/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk1/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk1/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk1/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk2/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk6/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk3/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk3/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk3/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk6/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk6/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk5/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/shard-glk5/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/shard-glk7/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/shard-glk9/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/shard-glk9/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/shard-glk9/boot.html
[33]:
Re: [Intel-gfx] [PATCH v3 3/3] drm/i915/gt: document TLB cache invalidation functions
Hi Mauro,
On 8/4/22 00:37, Mauro Carvalho Chehab wrote:
> Add a description for the TLB cache invalidation algorithm and for
> the related kAPI functions.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
>
> To avoid mailbombing on a large number of people, only mailing lists were C/C
> on the cover.
> See [PATCH v3 0/3] at:
> https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/
>
> Documentation/gpu/i915.rst | 7 ++
> drivers/gpu/drm/i915/gt/intel_tlb.c | 25
> drivers/gpu/drm/i915/gt/intel_tlb.h | 99 +
> 3 files changed, 131 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c
> b/drivers/gpu/drm/i915/gt/intel_tlb.c
> index af8cae979489..16b918ffe824 100644
> --- a/drivers/gpu/drm/i915/gt/intel_tlb.c
> +++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
> @@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
> }
>
> +/**
> + * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
> + * @gt: GT structure
In multiple places (here and below) it would be nice to know what a
GT structure is. I looked thru multiple C and header files yesterday
and didn't find any comments about it.
Just saying that @gt is a GT structure isn't very helpful, other
than making kernel-doc shut up.
> + * @seqno: sequence number
> + *
> + * Do a full TLB cache invalidation if the @seqno is bigger than the last
> + * full TLB cache invalidation.
> + *
> + * Note:
> + * The TLB cache invalidation logic depends on GEN-specific registers.
> + * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
> + */
> void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
> {
> intel_wakeref_t wakeref;
> @@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt,
> u32 seqno)
> }
> }
>
> +/**
> + * intel_gt_init_tlb - initialize TLB-specific vars
> + * @gt: GT structure
> + *
> + * TLB cache invalidation logic internally uses some resources that require
> + * initialization. Should be called before doing any TLB cache invalidation.
> + */
> void intel_gt_init_tlb(struct intel_gt *gt)
> {
> mutex_init(>tlb.invalidate_lock);
> seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
> }
>
> +/**
> + * intel_gt_fini_tlb - free TLB-specific vars
> + * @gt: GT structure
> + *
> + * Frees any resources needed by TLB cache invalidation logic.
> + */
> void intel_gt_fini_tlb(struct intel_gt *gt)
> {
> mutex_destroy(>tlb.invalidate_lock);
> diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h
> b/drivers/gpu/drm/i915/gt/intel_tlb.h
> index 46ce25bf5afe..2838c051f872 100644
> --- a/drivers/gpu/drm/i915/gt/intel_tlb.h
> +++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
> @@ -11,16 +11,115 @@
>
> #include "intel_gt_types.h"
>
> +/**
> + * DOC: TLB cache invalidation logic
> + *
...
> +
> void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno);
>
> void intel_gt_init_tlb(struct intel_gt *gt);
> void intel_gt_fini_tlb(struct intel_gt *gt);
>
> +/**
> + * intel_gt_tlb_seqno - Returns the current TLB invlidation sequence number
> + * @gt: GT structure
> + *
> + * There's no need to lock while calling it, as seqprop_sequence is
> thread-safe
> + */
> static inline u32 intel_gt_tlb_seqno(const struct intel_gt *gt)
> {
> return seqprop_sequence(>tlb.seqno);
> }
>
> +/**
> + * intel_gt_next_invalidate_tlb_full - Returns the next TLB full invalidation
> + * sequence number
> + * @gt: GT structure
> + *
> + * There's no need to lock while calling it, as seqprop_sequence is
> thread-safe
> + */
> static inline u32 intel_gt_next_invalidate_tlb_full(const struct intel_gt
> *gt)
> {
> return intel_gt_tlb_seqno(gt) | 1;
thanks.
--
~Randy
Re: [Intel-gfx] [PATCH] drm: Fix typo 'the the' in comment
On Thu, 2022-07-21 at 14:23 +0800, Slark Xiao wrote:
> Replace 'the the' with 'the' in the comment.
>
> Signed-off-by: Slark Xiao
Reviewed-by: Stuart Summers
> ---
> drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
> drivers/gpu/drm/i915/i915_irq.c | 2 +-
> drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
> b/drivers/gpu/drm/display/drm_dp_helper.c
> index e5bab236b3ae..32b295003f49 100644
> --- a/drivers/gpu/drm/display/drm_dp_helper.c
> +++ b/drivers/gpu/drm/display/drm_dp_helper.c
> @@ -1597,7 +1597,7 @@ static int drm_dp_aux_reply_duration(const
> struct drm_dp_aux_msg *msg)
>
> /*
> * Calculate the length of the i2c transfer in usec, assuming
> - * the i2c bus speed is as specified. Gives the the "worst"
> + * the i2c bus speed is as specified. Gives the "worst"
> * case estimate, ie. successful while as long as possible.
> * Doesn't account the "MOT" bit, and instead assumes each
> * message includes a START, ADDRESS and STOP. Neither does it
> diff --git a/drivers/gpu/drm/i915/i915_irq.c
> b/drivers/gpu/drm/i915/i915_irq.c
> index 73cebc6aa650..783a6ca41a61 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -65,7 +65,7 @@
>
> /*
> * Interrupt statistic for PMU. Increments the counter only if the
> - * interrupt originated from the the GPU so interrupts from a device
> which
> + * interrupt originated from the GPU so interrupts from a device
> which
> * shares the interrupt line are not accounted.
> */
> static inline void pmu_irq_stats(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> index 40ea41b0a5dd..4085822f619a 100644
> --- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> +++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
> @@ -231,7 +231,7 @@ struct nt35510_config {
>* bits 0..2 in the lower nibble controls HCK, the booster
> clock
>* frequency, the values are the same as for PCK in @bt1ctr.
>* bits 4..5 in the upper nibble controls BTH, the boosting
> - * amplification for the the step-up circuit.
> + * amplification for the step-up circuit.
>* 0 = AVDD + VDDB
>* 1 = AVDD - AVEE
>* 2 = AVDD - AVEE + VDDB
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only disable PMU on stop if not already closed
On Thu, 2022-08-04 at 09:46 +0100, Tvrtko Ursulin wrote:
> On 04/08/2022 00:03, Stuart Summers wrote:
> > There can be a race in the PMU process teardown vs the
> > time when the driver is unbound in which the user attempts
> > to stop the PMU process, but the actual data structure
> > in the kernel is no longer available. Avoid this use-after-free
> > by skipping the PMU disable in i915_pmu_event_stop() when
> > the PMU has already been closed/unregistered by the driver.
> >
> > Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")
> > Suggested-by: Tvrtko Ursulin
> > Signed-off-by: Stuart Summers
> > ---
> > drivers/gpu/drm/i915/i915_pmu.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_pmu.c
> > b/drivers/gpu/drm/i915/i915_pmu.c
> > index 958b37123bf12..0d02f338118e4 100644
> > --- a/drivers/gpu/drm/i915/i915_pmu.c
> > +++ b/drivers/gpu/drm/i915/i915_pmu.c
> > @@ -760,9 +760,17 @@ static void i915_pmu_event_start(struct
> > perf_event *event, int flags)
> >
> > static void i915_pmu_event_stop(struct perf_event *event, int
> > flags)
> > {
> > + struct drm_i915_private *i915 =
> > + container_of(event->pmu, typeof(*i915), pmu.base);
> > + struct i915_pmu *pmu = >pmu;
> > +
> > + if (pmu->closed)
> > + goto out;
> > +
> > if (flags & PERF_EF_UPDATE)
> > i915_pmu_event_read(event);
> > i915_pmu_disable(event);
> > +out:
> > event->hw.state = PERF_HES_STOPPED;
> > }
> >
>
> LGTM, although I am not sure who feels comfortable to r-b since we
> all
> kind of suggested the same fix. :)
>
> FWIW:
>
> Reviewed-by: Tvrtko Ursulin
Thanks Tvrtko! I'll track down another reviewer here as well to close
that out before merging.
Thanks,
Stuart
>
> Regards,
>
> Tvrtko
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix NPD in PMU during driver teardown
On Thu, 2022-08-04 at 09:42 +0100, Tvrtko Ursulin wrote:
> On 04/08/2022 00:03, Stuart Summers wrote:
> > In the driver teardown, we are unregistering the gt prior
> > to unregistering the PMU. This means there is a small window
> > of time in which the application can request metrics from the
> > PMU, some of which are calling into the uapi engines list,
> > while the engines are not available. In this case we can
> > see null pointer dereferences.
> >
> > Fix this ordering in both the driver load and unload sequences.
> >
> > v1: Actually address the driver load/unload ordering issue
> > v2: Remove the NULL checks since they shouldn't be necessary
> > now with the proper ordering
> >
> > Fixes: 42014f69bb235 ("drm/i915: Hook up GT power management")
>
> What happened in this commit to break it?
Hm.. well this was the patch that added the abstraction ordering issue,
i.e. gt_register/unregister. There isn't anything specifically broken
here since we don't actually access the gt structure underneath. My
assertion is that this patch should have taken the expansion of the gt
structure into consideration and added the correct ordering with
respect to the pmu.
Are you asking for the specific patch where things stopped working
functionally?
Thanks,
Stuart
>
> > Signed-off-by: Stuart Summers
> > ---
> > drivers/gpu/drm/i915/i915_driver.c | 11 ++-
> > 1 file changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index deb8a8b76965a..ee4dcb85d2060 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -717,7 +717,6 @@ static void i915_driver_register(struct
> > drm_i915_private *dev_priv)
> > struct drm_device *dev = _priv->drm;
> >
> > i915_gem_driver_register(dev_priv);
> > - i915_pmu_register(dev_priv);
> >
> > intel_vgpu_register(dev_priv);
> >
> > @@ -731,11 +730,12 @@ static void i915_driver_register(struct
> > drm_i915_private *dev_priv)
> > i915_debugfs_register(dev_priv);
> > i915_setup_sysfs(dev_priv);
> >
> > + intel_gt_driver_register(to_gt(dev_priv));
> > +
> > /* Depends on sysfs having been initialized */
> > + i915_pmu_register(dev_priv);
> > i915_perf_register(dev_priv);
> >
> > - intel_gt_driver_register(to_gt(dev_priv));
> > -
>
> There was a bit of a time distance since we originally discussed this
> so
> things kind of evaporated from my head. Or at least it feels like
> that.
> Today when I look at the code I don't understand why is this
> shuffle
> relevant.
>
> The sysfs comment does not really apply to pmu, but also if I look
> into
> intel_gt_driver_(un)register I did not spot what is the relevant
> part
> which interacts with the PMU.
>
> On register it is engine list first then PMU.
>
> On unregister it is PMU first, then engine list:
>
>i915_driver_remove
> i915_driver_unregister
>i915_pmu_unregister
> i915_gem_driver_remove
>clears uabi engines list
>
> Help please? :)
>
> Regards,
>
> Tvrtko
>
> > intel_display_driver_register(dev_priv);
> >
> > intel_power_domains_enable(dev_priv);
> > @@ -762,11 +762,12 @@ static void i915_driver_unregister(struct
> > drm_i915_private *dev_priv)
> >
> > intel_display_driver_unregister(dev_priv);
> >
> > - intel_gt_driver_unregister(to_gt(dev_priv));
> > -
> > i915_perf_unregister(dev_priv);
> > + /* GT should be available until PMU is gone */
> > i915_pmu_unregister(dev_priv);
> >
> > + intel_gt_driver_unregister(to_gt(dev_priv));
> > +
> > i915_teardown_sysfs(dev_priv);
> > drm_dev_unplug(_priv->drm);
> >
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave and Daniel, Here goes drm-intel-next-fixes-2022-08-04: - disable pci resize on 32-bit systems (Nirmoy) - don't leak the ccs state (Matt) - TLB invalidation fixes (Chris) Thanks, Rodrigo. The following changes since commit 2bc7ea71a73747a77e7f83bc085b0d2393235410: Merge tag 'topic/nouveau-misc-2022-07-27' of git://anongit.freedesktop.org/drm/drm into drm-next (2022-07-27 11:34:07 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2022-08-04 for you to fetch changes up to e57b9369e0c6f60155027e120fafd4b57e385b71: drm/i915/gt: Batch TLB invalidations (2022-08-01 09:48:06 -0400) - disable pci resize on 32-bit systems (Nirmoy) - don't leak the ccs state (Matt) - TLB invalidation fixes (Chris) Chris Wilson (4): drm/i915/gt: Ignore TLB invalidations on idle engines drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations drm/i915/gt: Skip TLB invalidations once wedged drm/i915/gt: Batch TLB invalidations Matthew Auld (1): drm/i915/ttm: don't leak the ccs state Nirmoy Das (1): drm/i915: disable pci resize on 32-bit machine drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 3 +- drivers/gpu/drm/i915/gem/i915_gem_pages.c| 25 +--- drivers/gpu/drm/i915/gt/intel_gt.c | 77 ++-- drivers/gpu/drm/i915/gt/intel_gt.h | 12 +++- drivers/gpu/drm/i915/gt/intel_gt_pm.h| 3 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 18 +- drivers/gpu/drm/i915/gt/intel_migrate.c | 23 ++- drivers/gpu/drm/i915/gt/intel_ppgtt.c| 8 ++- drivers/gpu/drm/i915/gt/intel_region_lmem.c | 4 ++ drivers/gpu/drm/i915/i915_vma.c | 33 +++--- drivers/gpu/drm/i915/i915_vma.h | 1 + drivers/gpu/drm/i915/i915_vma_resource.c | 5 +- drivers/gpu/drm/i915/i915_vma_resource.h | 6 +- 13 files changed, 177 insertions(+), 41 deletions(-)
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/userptr: remove redundation assignment to variable ret
== Series Details ==
Series: drm/i915/userptr: remove redundation assignment to variable ret
URL : https://patchwork.freedesktop.org/series/106983/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11968 -> Patchwork_106983v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/index.html
Participating hosts (42 -> 41)
--
Missing(1): bat-jsl-3
Known issues
Here are the changes found in Patchwork_106983v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6700k2: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/fi-skl-6700k2/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258: [PASS][3] -> [INCOMPLETE][4] ([i915#3303] /
[i915#4785])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[PASS][5] -> [DMESG-FAIL][6] ([i915#4528])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][8] -> [FAIL][9] ([i915#6298])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@runner@aborted:
- fi-hsw-g3258: NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#4312] /
[i915#6246])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/fi-hsw-g3258/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlm-1}: [DMESG-WARN][11] ([i915#2867]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][13] ([i915#4785]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11968/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.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#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4528]: https://gitlab.freedesktop.org/drm/intel/issues/4528
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6246]: https://gitlab.freedesktop.org/drm/intel/issues/6246
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
Build changes
-
* Linux: CI_DRM_11968 -> Patchwork_106983v1
CI-20190529: 20190529
CI_DRM_11968: 2e7128819e19793a625159b706e8cdc998cfd3be @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6613: 209230467200f2fa63a6f71fe626470dd813 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_106983v1: 2e7128819e19793a625159b706e8cdc998cfd3be @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
8bcb97ebcc95 drm/i915/userptr: remove redundation assignment to variable ret
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106983v1/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/userptr: remove redundation assignment to variable ret
== Series Details == Series: drm/i915/userptr: remove redundation assignment to variable ret URL : https://patchwork.freedesktop.org/series/106983/ State : warning == Summary == Error: dim checkpatch failed be49a3479605 drm/i915/userptr: remove redundation assignment to variable ret -:30: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Colin Ian King ' != 'Signed-off-by: Colin Ian King ' total: 0 errors, 1 warnings, 0 checks, 8 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: remove redundant pointer sseu
== Series Details ==
Series: drm/i915/gt: remove redundant pointer sseu
URL : https://patchwork.freedesktop.org/series/106982/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11967 -> Patchwork_106982v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106982v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106982v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/index.html
Participating hosts (42 -> 41)
--
Additional (1): fi-bsw-n3050
Missing(2): fi-hsw-4770 fi-bdw-samus
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106982v1:
### IGT changes ###
Possible regressions
* igt@core_hotunplug@unbind-rebind:
- fi-skl-6700k2: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11967/fi-skl-6700k2/igt@core_hotunp...@unbind-rebind.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/fi-skl-6700k2/igt@core_hotunp...@unbind-rebind.html
Known issues
Here are the changes found in Patchwork_106982v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_blits@basic:
- fi-bsw-n3050: NOTRUN -> [SKIP][3] ([fdo#109271]) +19 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/fi-bsw-n3050/igt@gem_tiled_bl...@basic.html
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][4] ([i915#4528])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-5: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] /
[i915#4957])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11967/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm: NOTRUN -> [INCOMPLETE][7] ([i915#4817])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-bsw-n3050: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/fi-bsw-n3050/igt@kms_chamel...@hdmi-edid-read.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][9] ([i915#2867]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11967/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-adlm-1}: [DMESG-WARN][11] ([i915#2867]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11967/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@execlists:
- fi-bdw-gvtdvm: [INCOMPLETE][13] ([i915#2940]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11967/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/fi-bdw-gvtdvm/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@guc:
- {bat-rpls-1}: [DMESG-WARN][15] ([i915#6471]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11967/bat-rpls-1/igt@i915_selftest@l...@guc.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/bat-rpls-1/igt@i915_selftest@l...@guc.html
* igt@i915_selftest@live@requests:
- {bat-rpls-1}: [DMESG-FAIL][17] ([i915#5087] / [i915#6257]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11967/bat-rpls-1/igt@i915_selftest@l...@requests.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/bat-rpls-1/igt@i915_selftest@l...@requests.html
- fi-pnv-d510:[DMESG-FAIL][19] ([i915#4528]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11967/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106982v1/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [FAIL][21] ([i915#6298]) ->
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Fix typo 'the the' in comment
== Series Details ==
Series: drm: Fix typo 'the the' in comment
URL : https://patchwork.freedesktop.org/series/106979/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11966_full -> Patchwork_106979v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106979v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106979v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106979v1_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
- shard-skl: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-skl4/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s3-without-i915:
- {shard-tglu}: NOTRUN -> [INCOMPLETE][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-tglu-1/igt@i915_susp...@basic-s3-without-i915.html
Known issues
Here are the changes found in Patchwork_106979v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_busy@close-race:
- shard-snb: [PASS][3] -> [TIMEOUT][4] ([i915#5748])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-snb7/igt@gem_b...@close-race.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-snb6/igt@gem_b...@close-race.html
* igt@gem_exec_balancer@parallel-out-fence:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#4525])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-iclb1/igt@gem_exec_balan...@parallel-out-fence.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-iclb3/igt@gem_exec_balan...@parallel-out-fence.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: NOTRUN -> [FAIL][7] ([i915#2846])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-glk1/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][8] -> [FAIL][9] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-apl4/igt@gem_exec_fair@basic-none-s...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-tglb5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-tglb7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) +3 similar
issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-kbl1/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#2842])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk7/igt@gem_exec_fair@basic-p...@vcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-glk2/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_11966/shard-iclb8/igt@gem_exec_fair@basic-throt...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html
* igt@gem_lmem_swapping@heavy-verify-multi-ccs:
- shard-glk: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#4613])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-glk1/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html
* igt@gem_lmem_swapping@heavy-verify-random-ccs:
- shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/shard-skl4/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html
* igt@gem_lmem_swapping@smem-oom:
- shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271] /
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: remove redundant pointer sseu
== Series Details == Series: drm/i915/gt: remove redundant pointer sseu URL : https://patchwork.freedesktop.org/series/106982/ State : warning == Summary == Error: dim checkpatch failed d471c966d875 drm/i915/gt: remove redundant pointer sseu -:33: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address mismatch: 'From: Colin Ian King ' != 'Signed-off-by: Colin Ian King ' total: 0 errors, 1 warnings, 0 checks, 14 lines checked
Re: [Intel-gfx] [PATCH] drm/i915/combo_phy: Add Workaround to avoid flicker with HBR3 eDP Panels
Thanks Imre, for the comments, please find my response inline: On 8/4/2022 9:14 PM, Imre Deak wrote: On Thu, Aug 04, 2022 at 03:59:11PM +0530, Ankit Nautiyal wrote: WA_14014367875 : When Display PHY is configured in continuous DCC calibration mode, the DCC (duty cycle correction) for the clock erroneously goes through a state where the DCC code is 0x00 when it is supposed to be transitioning from 0x10 to 0x0F. This glitch causes a distortion in the clock, which leads to a bit error. The issue is known to be causing flickering with eDP HBR3 panels. The work around configures the DCC in one-time-update mode. This mode updates the DCC code one time during training and then it does not change. This will prevent on-the-fly updates so that the glitch does not occur. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c b/drivers/gpu/drm/i915/display/intel_combo_phy.c index 64890f39c3cc..1b8bdc47671d 100644 --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c @@ -242,9 +242,10 @@ static bool icl_combo_phy_verify_state(struct drm_i915_private *dev_priv, ICL_PORT_TX_DW8_ODCC_CLK_SEL | ICL_PORT_TX_DW8_ODCC_CLK_DIV_SEL_DIV2); + /* WA_14014367875 Set DCC calibration mode to Read once*/ The usual format is 'Wa_:', so Wa_22012718247:... 'read once' is 'run once' afaics. Indeed. Will fix the format and the typo here. ret &= check_phy_reg(dev_priv, phy, ICL_PORT_PCS_DW1_LN(0, phy), DCC_MODE_SELECT_MASK, -DCC_MODE_SELECT_CONTINUOSLY); +~DCC_MODE_SELECT_MASK); I can see this WA listed only for ADL_P/N/S and TGL (and not for DG2/RKL Alright, so perhaps need to use Platform check. for instance). ~DCC_MODE_SELECT_MASK should be 0, maybe add a dcc_calibration_mode() that could be used below as well. Yes right, I did realize mask should have been 0. Will do the suggested changes. Could you file a ticket at https://gfxspecs.intel.com/Predator/Home/Index/49291 which specifies this programming explicitly for each platform, but is incorrect now wrt. the above WA? Makes sense, will file a bspec ticket. Regards, Ankit } ret &= icl_verify_procmon_ref_values(dev_priv, phy); @@ -366,8 +367,9 @@ static void icl_combo_phys_init(struct drm_i915_private *dev_priv) intel_de_write(dev_priv, ICL_PORT_TX_DW8_GRP(phy), val); val = intel_de_read(dev_priv, ICL_PORT_PCS_DW1_LN(0, phy)); + + /* WA_14014367875 Set DCC calibration mode to Read once*/ val &= ~DCC_MODE_SELECT_MASK; - val |= DCC_MODE_SELECT_CONTINUOSLY; intel_de_write(dev_priv, ICL_PORT_PCS_DW1_GRP(phy), val); } -- 2.25.1
[Intel-gfx] ✗ Fi.CI.BUILD: failure for cover-letter: Update vfio_pin/unpin_pages API
== Series Details == Series: cover-letter: Update vfio_pin/unpin_pages API URL : https://patchwork.freedesktop.org/series/106978/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/106978/revisions/1/mbox/ not applied Applying: vfio: Make vfio_unpin_pages() return void Using index info to reconstruct a base tree... M Documentation/driver-api/vfio-mediated-device.rst M drivers/gpu/drm/i915/gvt/kvmgt.c M drivers/vfio/vfio.c M drivers/vfio/vfio.h M drivers/vfio/vfio_iommu_type1.c M include/linux/vfio.h Falling back to patching base and 3-way merge... Auto-merging include/linux/vfio.h CONFLICT (content): Merge conflict in include/linux/vfio.h Auto-merging drivers/vfio/vfio_iommu_type1.c Auto-merging drivers/vfio/vfio.h Auto-merging drivers/vfio/vfio.c Auto-merging drivers/gpu/drm/i915/gvt/kvmgt.c Auto-merging Documentation/driver-api/vfio-mediated-device.rst error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 vfio: Make vfio_unpin_pages() return void When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Move all drivers to a common dma-buf locking convention
== Series Details == Series: Move all drivers to a common dma-buf locking convention URL : https://patchwork.freedesktop.org/series/106980/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/106980/revisions/1/mbox/ not applied Applying: dma-buf: Add _unlocked postfix to function names Using index info to reconstruct a base tree... M drivers/dma-buf/dma-buf.c M drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c M drivers/gpu/drm/armada/armada_gem.c A drivers/gpu/drm/drm_gem_cma_helper.c M drivers/gpu/drm/drm_gem_shmem_helper.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/drm_gem_shmem_helper.c Auto-merging drivers/gpu/drm/drm_gem_dma_helper.c CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_gem_dma_helper.c Auto-merging drivers/gpu/drm/armada/armada_gem.c Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c Auto-merging drivers/dma-buf/dma-buf.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 dma-buf: Add _unlocked postfix to function names When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH] drm/i915/combo_phy: Add Workaround to avoid flicker with HBR3 eDP Panels
On Thu, Aug 04, 2022 at 03:59:11PM +0530, Ankit Nautiyal wrote: > WA_14014367875 : When Display PHY is configured in continuous > DCC calibration mode, the DCC (duty cycle correction) for the clock > erroneously goes through a state where the DCC code is 0x00 when it is > supposed to be transitioning from 0x10 to 0x0F. This glitch causes a > distortion in the clock, which leads to a bit error. The issue is known > to be causing flickering with eDP HBR3 panels. > > The work around configures the DCC in one-time-update mode. > This mode updates the DCC code one time during training and then > it does not change. This will prevent on-the-fly updates so that the > glitch does not occur. > > Signed-off-by: Ankit Nautiyal > --- > drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c > b/drivers/gpu/drm/i915/display/intel_combo_phy.c > index 64890f39c3cc..1b8bdc47671d 100644 > --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c > +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c > @@ -242,9 +242,10 @@ static bool icl_combo_phy_verify_state(struct > drm_i915_private *dev_priv, >ICL_PORT_TX_DW8_ODCC_CLK_SEL | >ICL_PORT_TX_DW8_ODCC_CLK_DIV_SEL_DIV2); > > + /* WA_14014367875 Set DCC calibration mode to Read once*/ The usual format is 'Wa_:', so Wa_22012718247:... 'read once' is 'run once' afaics. > ret &= check_phy_reg(dev_priv, phy, ICL_PORT_PCS_DW1_LN(0, phy), >DCC_MODE_SELECT_MASK, > - DCC_MODE_SELECT_CONTINUOSLY); > + ~DCC_MODE_SELECT_MASK); I can see this WA listed only for ADL_P/N/S and TGL (and not for DG2/RKL for instance). ~DCC_MODE_SELECT_MASK should be 0, maybe add a dcc_calibration_mode() that could be used below as well. Could you file a ticket at https://gfxspecs.intel.com/Predator/Home/Index/49291 which specifies this programming explicitly for each platform, but is incorrect now wrt. the above WA? > } > > ret &= icl_verify_procmon_ref_values(dev_priv, phy); > @@ -366,8 +367,9 @@ static void icl_combo_phys_init(struct drm_i915_private > *dev_priv) > intel_de_write(dev_priv, ICL_PORT_TX_DW8_GRP(phy), val); > > val = intel_de_read(dev_priv, ICL_PORT_PCS_DW1_LN(0, > phy)); > + > + /* WA_14014367875 Set DCC calibration mode to Read > once*/ > val &= ~DCC_MODE_SELECT_MASK; > - val |= DCC_MODE_SELECT_CONTINUOSLY; > intel_de_write(dev_priv, ICL_PORT_PCS_DW1_GRP(phy), > val); > } > > -- > 2.25.1 >
Re: [Intel-gfx] [PATCH 8/8] drm/i915 : Add D3COLD OFF support
> -Original Message-
> From: Tangudu, Tilak
> Sent: Thursday, July 21, 2022 3:30 PM
> To: Ewins, Jon ; Belgaumkar, Vinay
> ; Roper, Matthew D
> ; Wilson, Chris P ;
> Nikula, Jani ; Gupta, saurabhg
> ; Vivi, Rodrigo ; Gupta,
> Anshuman ; Nilawar, Badal
> ; Tangudu, Tilak ; Deak,
> Imre ; Iddamsetty, Aravind
> ; intel-gfx@lists.freedesktop.org
> Subject: [PATCH 8/8] drm/i915 : Add D3COLD OFF support
>
> From: Tilak Tangudu
>
> Added lmem deep suspend/resume, which covers lmem eviction and added
> GT/GUC deep suspend/resume using i915_gem_backup_suspend,
> i915_gem_suspend_late and i915_gem_resume.
>
> Signed-off-by: Tilak Tangudu
> ---
> drivers/gpu/drm/i915/i915_driver.c | 74 --
> 1 file changed, 61 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 3697ecb2c138..608287bb27ea 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -1630,6 +1630,7 @@ static int intel_runtime_idle(struct device *kdev)
> static int intel_runtime_suspend(struct device *kdev) {
> struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> + struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> struct intel_runtime_pm *rpm = _priv->runtime_pm;
> int ret;
>
> @@ -1644,9 +1645,14 @@ static int intel_runtime_suspend(struct device *kdev)
>* We are safe here against re-faults, since the fault handler takes
>* an RPM reference.
>*/
> - i915_gem_runtime_suspend(dev_priv);
> -
> - intel_gt_runtime_suspend(to_gt(dev_priv));
> + if (rpm->d3_state == INTEL_D3COLD_OFF) {
> + i915_gem_backup_suspend(dev_priv);
> + i915_ggtt_suspend(to_gt(dev_priv)->ggtt);
> + i915_gem_suspend_late(dev_priv);
We should use the *runtime* naming convention rather then
system wide suspend naming convention here.
> + } else {
> + i915_gem_runtime_suspend(dev_priv);
> + intel_gt_runtime_suspend(to_gt(dev_priv));
> + }
>
> intel_runtime_pm_disable_interrupts(dev_priv);
>
> @@ -1691,14 +1697,18 @@ static int intel_runtime_suspend(struct device
> *kdev)
>*/
> intel_opregion_notify_adapter(dev_priv, PCI_D3hot);
> } else {
> - /*
> - * current versions of firmware which depend on this opregion
> - * notification have repurposed the D1 definition to mean
> - * "runtime suspended" vs. what you would normally expect
> (D3)
> - * to distinguish it from notifications that might be sent via
> - * the suspend path.
> - */
> - intel_opregion_notify_adapter(dev_priv, PCI_D1);
> + if (rpm->d3_state == INTEL_D3COLD_OFF) {
> + intel_opregion_suspend(dev_priv, PCI_D3cold);
Not needed.
> + } else {
> + /*
> + * current versions of firmware which depend on this
> opregion
> + * notification have repurposed the D1 definition to
> mean
> + * "runtime suspended" vs. what you would normally
> expect (D3)
> + * to distinguish it from notifications that might be
> sent
> via
> + * the suspend path.
> + */
> + intel_opregion_notify_adapter(dev_priv, PCI_D1);
I have also provided the comment on rev1, this is not
needed anymore.
This particular opregion is
deprecated.
> + }
> }
>
> assert_forcewakes_inactive(_priv->uncore);
> @@ -1706,6 +1716,12 @@ static int intel_runtime_suspend(struct device *kdev)
> if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
> intel_hpd_poll_enable(dev_priv);
>
> + if (rpm->d3_state == INTEL_D3COLD_OFF) {
> + i915_save_pci_state(pdev);
> + pci_disable_device(pdev);
> + pci_set_power_state(pdev, PCI_D3cold);
This is not needed, it can set max up to d3hot by config space
write.
PCI core set the device sate or , it is not required by driver.
I had provided the same comment on Rev1, please
try to address all the comment before floating
next revision.
Thanks,
Anshuman Gupta.
> + }
> +
> drm_dbg(_priv->drm, "Device suspended\n");
> return 0;
> }
> @@ -1713,6 +1729,7 @@ static int intel_runtime_suspend(struct device *kdev)
> static int intel_runtime_resume(struct device *kdev) {
> struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> + struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> struct intel_runtime_pm *rpm =
Re: [Intel-gfx] [PATCH 8/8] drm/i915 : Add D3COLD OFF support
On Thu, Jul 21, 2022 at 03:29:55PM +0530, tilak.tang...@intel.com wrote:
> [...]
> @@ -1706,6 +1716,12 @@ static int intel_runtime_suspend(struct device *kdev)
> if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
> intel_hpd_poll_enable(dev_priv);
>
> + if (rpm->d3_state == INTEL_D3COLD_OFF) {
> + i915_save_pci_state(pdev);
> + pci_disable_device(pdev);
> + pci_set_power_state(pdev, PCI_D3cold);
> + }
Could you add a code comment describing why the above is required? For
standard PCI devices pci_pm_runtime_suspend() should do this except for
calling pci_disable_device().
> +
> drm_dbg(_priv->drm, "Device suspended\n");
> return 0;
> }
> @@ -1713,6 +1729,7 @@ static int intel_runtime_suspend(struct device *kdev)
> static int intel_runtime_resume(struct device *kdev)
> {
> struct drm_i915_private *dev_priv = kdev_to_i915(kdev);
> + struct pci_dev *pdev = to_pci_dev(dev_priv->drm.dev);
> struct intel_runtime_pm *rpm = _priv->runtime_pm;
> int ret;
>
> @@ -1724,7 +1741,25 @@ static int intel_runtime_resume(struct device *kdev)
> drm_WARN_ON_ONCE(_priv->drm, atomic_read(>wakeref_count));
> disable_rpm_wakeref_asserts(rpm);
>
> - intel_opregion_notify_adapter(dev_priv, PCI_D0);
> + if (rpm->d3_state == INTEL_D3COLD_OFF) {
> + ret = pci_set_power_state(pdev, PCI_D0);
> + if (ret) {
> + drm_err(_priv->drm,
> + "failed to set PCI D0 power state (%d)\n", ret);
> + goto out;
> + }
> +
> + i915_load_pci_state(pdev);
> +
> + ret = pci_enable_device(pdev);
> + if (ret)
> + goto out;
> + pci_set_master(pdev);
> + intel_opregion_resume(dev_priv);
> + } else {
> + intel_opregion_notify_adapter(dev_priv, PCI_D0);
> + }
> +
> rpm->suspended = false;
> if (intel_uncore_unclaimed_mmio(_priv->uncore))
> drm_dbg(_priv->drm,
> @@ -1742,8 +1777,20 @@ static int intel_runtime_resume(struct device *kdev)
>* No point of rolling back things in case of an error, as the best
>* we can do is to hope that things will still work (and disable RPM).
>*/
> - intel_gt_runtime_resume(to_gt(dev_priv));
> + if (rpm->d3_state == INTEL_D3COLD_OFF) {
> + ret = i915_pcode_init(dev_priv);
> + if (ret)
> + goto out;
>
> + sanitize_gpu(dev_priv);
> + ret = i915_ggtt_enable_hw(dev_priv);
> + if (ret)
> + drm_err(_priv->drm, "failed to re-enable GGTT\n");
> + i915_ggtt_resume(to_gt(dev_priv)->ggtt);
> + i915_gem_resume(dev_priv);
> + } else {
> + intel_gt_runtime_resume(to_gt(dev_priv));
> + }
> /*
>* On VLV/CHV display interrupts are part of the display
>* power well, so hpd is reinitialized from there. For
> @@ -1756,6 +1803,7 @@ static int intel_runtime_resume(struct device *kdev)
>
> intel_enable_ipc(dev_priv);
>
> +out:
> enable_rpm_wakeref_asserts(rpm);
>
> if (ret)
> --
> 2.25.1
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Fix typo 'the the' in comment
== Series Details ==
Series: drm: Fix typo 'the the' in comment
URL : https://patchwork.freedesktop.org/series/106979/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11966 -> Patchwork_106979v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/index.html
Participating hosts (41 -> 41)
--
Additional (2): bat-rpls-1 bat-jsl-3
Missing(2): fi-kbl-soraka fi-rkl-11600
Known issues
Here are the changes found in Patchwork_106979v1 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-kbl-8809g: [FAIL][1] -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-kbl-8809g/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-kbl-8809g/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-8809g: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-kbl-8809g/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_backlight@basic-brightness:
- fi-kbl-8809g: NOTRUN -> [SKIP][5] ([fdo#109271]) +26 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-kbl-8809g/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][6] -> [INCOMPLETE][7] ([i915#4785])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-g3258: [PASS][8] -> [INCOMPLETE][9] ([i915#3303] /
[i915#4785])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][10] -> [DMESG-FAIL][11] ([i915#4528])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-kbl-8809g: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +8
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-kbl-8809g/igt@kms_chamel...@dp-hpd-fast.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][13] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-hsw-4770/igt@run...@aborted.html
- fi-hsw-g3258: NOTRUN -> [FAIL][14] ([fdo#109271] / [i915#4312] /
[i915#6246])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/fi-hsw-g3258/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][15] ([i915#2582]) -> [PASS][16] +4 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@fb...@read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/bat-rpls-2/igt@fb...@read.html
* igt@kms_frontbuffer_tracking@basic:
- {bat-rpls-2}: [SKIP][17] ([i915#1849]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
* igt@prime_vgem@basic-fence-flip:
- {bat-rpls-2}: [SKIP][19] ([fdo#109295] / [i915#1845] / [i915#3708])
-> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@prime_v...@basic-fence-flip.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106979v1/bat-rpls-2/igt@prime_v...@basic-fence-flip.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#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1155]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm: Fix typo 'the the' in comment
== Series Details == Series: drm: Fix typo 'the the' in comment URL : https://patchwork.freedesktop.org/series/106979/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2
Re: [Intel-gfx] [PATCH v4 1/2] vfio: Replace the DMA unmapping notifier with a callback
On Wed, 2022-07-20 at 17:04 -0600, Alex Williamson wrote: > On Wed, 20 Jul 2022 17:08:29 -0300 > Jason Gunthorpe wrote: > > > On Wed, Jul 20, 2022 at 01:41:13PM -0600, Alex Williamson wrote: > > > > > ie. we don't need the gfn, we only need the iova. > > > > Right, that makes sense > > > > > However then I start to wonder why we're passing in 1 for the > > > number of > > > pages because this previously notifier, now callback is called > > > for the > > > entire vfio_dma range when we find any pinned pages. > > > > Well, it is doing this because it only ever pins one page. > > Of course that page is not necessarily the page it unpins given the > contract misunderstanding below. > > > The drivers are confused about what the contract is. vfio is > > calling > > the notifier with the entire IOVA range that is being unmapped and > > the > > drivers are expecting to receive notifications only for the IOVA > > they > > have actually pinned. > > > > > Should ap and ccw implementations of .dma_unmap just be replaced > > > with a > > > BUG_ON(1)? > > > > The point of these callbacks is to halt concurrent DMA, and ccw > > does > > that today. > > ccw essentially only checks whether the starting iova of the unmap is > currently mapped. If not it does nothing, if it is it tries to reset > the device and unpin everything. Chances are the first iova is not > the > one pinned, so we don't end up removing the pinned page and type1 > will > eventually BUG_ON after a few tries. > > > It looks like AP is missing a call to ap_aqic(), so it is > > probably double wrong. > > Thankfully the type1 unpinning path can't be tricked into unpinning > something that wasn't pinned, so chances are the unpin call does > nothing, with a small risk that it unpins another driver's pinned > page, > which might not yet have been notified and could still be using the > page. In the end, if ap did have a page pinned in the range, we'll > hit > the same BUG_ON as above. > > > What I'd suggest is adding a WARN_ON that the dma->pfn_list is not > > empty and leave these functions alone. > > The BUG_ON still exists in type1. > > Eric, Matt, Tony, Halil, JasonH, any quick fixes here? ccw looks > like > it would be pretty straightforward to test against a range rather > than > a single iova. Agreed, ccw looks pretty easy. Should I send something to go before this series to make stable easier? (It's a trivial change in either direction, so either is fine to me.) Eric > > > Most likely AP should be fixed to call vfio_ap_irq_disable() and to > > check the q->saved_pfn against the IOVA. > > Right, the q->saved_iova, perhaps calling vfio_ap_irq_disable() on > finding a matching queue. > > > But I'm inclined to leave this as-is for this series given we are > > at > > rc7. > > On the grounds that it's no worse, maybe, but given the changes > around this code hopefully we can submit fixes patches to stable if > the > backport isn't obvious and the BUG_ON in type1 is reachable. Thanks, > > Alex >
[Intel-gfx] [PATCH v2 1/5] dma-buf: Add _unlocked postfix to function names
Add _unlocked postfix to the dma-buf API function names in a preparation
to move all non-dynamic dma-buf users over to the dynamic locking
specification. This patch only renames API functions, preparing drivers
to the common locking convention. Later on we will make the "unlocked"
functions to take the reservation lock.
Suggested-by: Christian König
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 76 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +-
drivers/gpu/drm/armada/armada_gem.c | 14 ++--
drivers/gpu/drm/drm_gem_cma_helper.c | 6 +-
drivers/gpu/drm/drm_gem_shmem_helper.c| 6 +-
drivers/gpu/drm/drm_prime.c | 12 +--
drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 6 +-
drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 12 +--
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 20 ++---
drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 +-
drivers/gpu/drm/tegra/gem.c | 27 +++
drivers/infiniband/core/umem_dmabuf.c | 11 +--
.../common/videobuf2/videobuf2-dma-contig.c | 15 ++--
.../media/common/videobuf2/videobuf2-dma-sg.c | 12 +--
.../common/videobuf2/videobuf2-vmalloc.c | 6 +-
.../platform/nvidia/tegra-vde/dmabuf-cache.c | 12 +--
drivers/misc/fastrpc.c| 12 +--
drivers/xen/gntdev-dmabuf.c | 14 ++--
include/linux/dma-buf.h | 34 +
21 files changed, 161 insertions(+), 152 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 44574fbe7482..d16237a6ffaa 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -795,7 +795,7 @@ static struct sg_table * __map_dma_buf(struct
dma_buf_attachment *attach,
}
/**
- * dma_buf_dynamic_attach - Add the device to dma_buf's attachments list
+ * dma_buf_dynamic_attach_unlocked - Add the device to dma_buf's attachments
list
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
* @importer_ops: [in]importer operations for the attachment
@@ -817,9 +817,9 @@ static struct sg_table * __map_dma_buf(struct
dma_buf_attachment *attach,
* indicated with the error code -EBUSY.
*/
struct dma_buf_attachment *
-dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct device *dev,
- const struct dma_buf_attach_ops *importer_ops,
- void *importer_priv)
+dma_buf_dynamic_attach_unlocked(struct dma_buf *dmabuf, struct device *dev,
+ const struct dma_buf_attach_ops *importer_ops,
+ void *importer_priv)
{
struct dma_buf_attachment *attach;
int ret;
@@ -892,25 +892,25 @@ dma_buf_dynamic_attach(struct dma_buf *dmabuf, struct
device *dev,
if (dma_buf_is_dynamic(attach->dmabuf))
dma_resv_unlock(attach->dmabuf->resv);
- dma_buf_detach(dmabuf, attach);
+ dma_buf_detach_unlocked(dmabuf, attach);
return ERR_PTR(ret);
}
-EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach, DMA_BUF);
+EXPORT_SYMBOL_NS_GPL(dma_buf_dynamic_attach_unlocked, DMA_BUF);
/**
- * dma_buf_attach - Wrapper for dma_buf_dynamic_attach
+ * dma_buf_attach_unlocked - Wrapper for dma_buf_dynamic_attach
* @dmabuf:[in]buffer to attach device to.
* @dev: [in]device to be attached.
*
- * Wrapper to call dma_buf_dynamic_attach() for drivers which still use a
static
- * mapping.
+ * Wrapper to call dma_buf_dynamic_attach_unlocked() for drivers which still
+ * use a static mapping.
*/
-struct dma_buf_attachment *dma_buf_attach(struct dma_buf *dmabuf,
- struct device *dev)
+struct dma_buf_attachment *dma_buf_attach_unlocked(struct dma_buf *dmabuf,
+ struct device *dev)
{
- return dma_buf_dynamic_attach(dmabuf, dev, NULL, NULL);
+ return dma_buf_dynamic_attach_unlocked(dmabuf, dev, NULL, NULL);
}
-EXPORT_SYMBOL_NS_GPL(dma_buf_attach, DMA_BUF);
+EXPORT_SYMBOL_NS_GPL(dma_buf_attach_unlocked, DMA_BUF);
static void __unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sg_table,
@@ -923,7 +923,7 @@ static void __unmap_dma_buf(struct dma_buf_attachment
*attach,
}
/**
- * dma_buf_detach - Remove the given attachment from dmabuf's attachments list
+ * dma_buf_detach_unlocked - Remove the given attachment from dmabuf's
attachments list
* @dmabuf:[in]buffer to detach from.
* @attach:[in]attachment to be detached; is free'd after this call.
*
@@ -931,7 +931,8 @@ static void __unmap_dma_buf(struct dma_buf_attachment
*attach,
*
* Optionally this calls _buf_ops.detach for device-specific detach.
*/
-void dma_buf_detach(struct
Re: [Intel-gfx] [PATCH 12/23] drm/i915/mtl: Fix rawclk for Meteorlake PCH
> MTL has a fixed rawclk of 38400Mhz. Register does not need to be > + * MTL always uses a 38.4 MHz rawclk. The bspec tells us Mismatch between commit message and comment. Probably 38400Mhz -> 38400kHz -caz On Mon, Aug 1, 2022 at 8:29 PM Matt Roper wrote: > On Wed, Jul 27, 2022 at 06:34:09PM -0700, Radhakrishna Sripada wrote: > > From: Clint Taylor > > > > MTL has a fixed rawclk of 38400Mhz. Register does not need to be > > reprogrammed. > > > > Bspec: 49304 > > > > Signed-off-by: Clint Taylor > > --- > > drivers/gpu/drm/i915/display/intel_cdclk.c | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c > b/drivers/gpu/drm/i915/display/intel_cdclk.c > > index 86a22c3766e5..390a198b0011 100644 > > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c > > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c > > @@ -3036,6 +3036,13 @@ u32 intel_read_rawclk(struct drm_i915_private > *dev_priv) > > > > if (INTEL_PCH_TYPE(dev_priv) >= PCH_DG1) > > freq = dg1_rawclk(dev_priv); > > + else if (INTEL_PCH_TYPE(dev_priv) >= PCH_MTP) > > + /* > > + * MTL always uses a 38.4 MHz rawclk. The bspec tells us > > Indentation isn't quite right here. > > Patch is also missing your s-o-b. > > With those fixed, > > Reviewed-by: Matt Roper > > > + * "RAWCLK_FREQ defaults to the values for 38.4 and does > > + * not need to be programmed." > > + */ > > + freq = 38400; > > else if (INTEL_PCH_TYPE(dev_priv) >= PCH_CNP) > > freq = cnp_rawclk(dev_priv); > > else if (HAS_PCH_SPLIT(dev_priv)) > > -- > > 2.25.1 > > > > -- > Matt Roper > Graphics Software Engineer > VTT-OSGC Platform Enablement > Intel Corporation > -- -caz, caz at caztech dot com, 503-six one zero - five six nine nine(m)
[Intel-gfx] [PATCH] drm/i915/userptr: remove redundation assignment to variable ret
Variable ret is assigned a value that is never read; it is either
being re-assigned during the following while-loop or after the loop.
The assignmnt is redundant and can be removed.
Cleans up clang scan build warning:
drivers/gpu/drm/i915/gem/i915_gem_userptr.c:295:11: warning: Although
the value stored to 'ret' is used in the enclosing expression, the
value is never actually read from 'ret' [deadcode.DeadStores]
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
index 8423df021b71..075aef875a07 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_userptr.c
@@ -292,7 +292,7 @@ int i915_gem_object_userptr_submit_init(struct
drm_i915_gem_object *obj)
if (!i915_gem_object_is_readonly(obj))
gup_flags |= FOLL_WRITE;
- pinned = ret = 0;
+ pinned = 0;
while (pinned < num_pages) {
ret = pin_user_pages_fast(obj->userptr.ptr + pinned * PAGE_SIZE,
num_pages - pinned, gup_flags,
--
2.35.3
[Intel-gfx] [PATCH v2 0/5] Move all drivers to a common dma-buf locking convention
Hello, This series moves all drivers to a dynamic dma-buf locking specification. >From now on all dma-buf importers are made responsible for holding dma-buf's reservation lock around all operations performed over dma-bufs in accordance to the locking specification. This allows us to utilize reservation lock more broadly around kernel without fearing of a potential deadlocks. This patchset passes all i915 selftests. It was also tested using VirtIO, Panfrost, Lima and Tegra drivers. I tested cases of display+GPU, display+V4L and GPU+V4L dma-buf sharing, which covers majority of kernel drivers since rest of the drivers share same or similar code paths. Changelog: v2: - Changed locking specification to avoid problems with a cross-driver ww locking, like was suggested by Christian König. Now the attach/detach callbacks are invoked without the held lock and exporter should take the lock. - Added "locking convention" documentation that explains which dma-buf functions and callbacks are locked/unlocked for importers and exporters, which was requested by Christian König. - Added ack from Tomasz Figa to the V4L patches that he gave to v1. Dmitry Osipenko (5): dma-buf: Add _unlocked postfix to function names drm/gem: Take reservation lock for vmap/vunmap operations dma-buf: Move all dma-bufs to dynamic locking specification media: videobuf2: Stop using internal dma-buf lock dma-buf: Remove internal lock Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-buf.c | 253 +- drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 +- drivers/gpu/drm/armada/armada_gem.c | 14 +- drivers/gpu/drm/drm_client.c | 4 +- drivers/gpu/drm/drm_gem.c | 24 ++ drivers/gpu/drm/drm_gem_cma_helper.c | 6 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +- drivers/gpu/drm/drm_gem_shmem_helper.c| 6 +- drivers/gpu/drm/drm_prime.c | 12 +- drivers/gpu/drm/etnaviv/etnaviv_gem_prime.c | 6 +- drivers/gpu/drm/exynos/exynos_drm_gem.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 14 +- .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 20 +- drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c | 8 +- drivers/gpu/drm/qxl/qxl_object.c | 17 +- drivers/gpu/drm/qxl/qxl_prime.c | 4 +- drivers/gpu/drm/tegra/gem.c | 27 +- drivers/infiniband/core/umem_dmabuf.c | 11 +- .../common/videobuf2/videobuf2-dma-contig.c | 26 +- .../media/common/videobuf2/videobuf2-dma-sg.c | 23 +- .../common/videobuf2/videobuf2-vmalloc.c | 17 +- .../platform/nvidia/tegra-vde/dmabuf-cache.c | 12 +- drivers/misc/fastrpc.c| 12 +- drivers/xen/gntdev-dmabuf.c | 14 +- include/drm/drm_gem.h | 3 + include/linux/dma-buf.h | 71 ++--- 28 files changed, 372 insertions(+), 254 deletions(-) -- 2.36.1
[Intel-gfx] [PATCH][next] drm/i915/gt: remove redundant pointer sseu
Pointer sseu is being assigned a value that is never read. The pointer is redundant and can be removed. Cleans up clang scan warning: drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c:300:2: warning: Value stored to 'sseu' is never read [deadcode.DeadStores] Signed-off-by: Colin Ian King --- drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c index 75257bd20ff0..c0578194ab16 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c @@ -286,7 +286,6 @@ guc_capture_alloc_steered_lists_xe_lpd(struct intel_guc *guc, const struct __guc_mmio_reg_descr_group *list; struct __guc_mmio_reg_descr_group *extlists; struct __guc_mmio_reg_descr *extarray; - struct sseu_dev_info *sseu; /* In XE_LPD we only have steered registers for the render-class */ list = guc_capture_get_one_list(lists, GUC_CAPTURE_LIST_INDEX_PF, @@ -297,7 +296,6 @@ guc_capture_alloc_steered_lists_xe_lpd(struct intel_guc *guc, num_steer_regs = ARRAY_SIZE(xe_extregs); - sseu = >info.sseu; for_each_ss_steering(iter, gt, slice, subslice) num_tot_regs += num_steer_regs; -- 2.35.3
Re: [Intel-gfx] [PATCH 15/23] drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox
On Wed, Jul 27, 2022 at 6:34 PM Radhakrishna Sripada <
radhakrishna.srip...@intel.com> wrote:
> From Meteorlake, Latency Level, SAGV bloack time are read from
> LATENCY_SAGV register instead of the GT driver pcode mailbox. DDR type
> and QGV information are also tob read from Mem SS registers.
>
> Bspec: 49324, 64636
>
> Cc: Matt Roper
> Original Author: Caz Yokoyama
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 49 +++--
> drivers/gpu/drm/i915/display/intel_bw.h | 9 +
> drivers/gpu/drm/i915/i915_reg.h | 16
> drivers/gpu/drm/i915/intel_dram.c | 41 -
> drivers/gpu/drm/i915/intel_pm.c | 8 +++-
> 5 files changed, 110 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 79269d2c476b..8bbf47da1716 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -15,11 +15,6 @@
> #include "intel_pcode.h"
> #include "intel_pm.h"
>
> -/* Parameters for Qclk Geyserville (QGV) */
> -struct intel_qgv_point {
> - u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
> -};
> -
> struct intel_psf_gv_point {
> u8 clk; /* clock in multiples of 16. MHz */
> };
> @@ -137,6 +132,42 @@ int icl_pcode_restrict_qgv_points(struct
> drm_i915_private *dev_priv,
> return 0;
> }
>
> +static int mtl_read_qgv_point_info(struct drm_i915_private *dev_priv,
>
No need to return value. i.e.
static void
mtl_read_qgv_point_info(struct drm_i915_private *dev_priv,
-caz
+ struct intel_qgv_point *sp, int point)
> +{
> + u32 val, val2;
> + u16 dclk;
> +
> + val = intel_uncore_read(_priv->uncore,
> + MTL_MEM_SS_INFO_QGV_POINT(point, 0));
> + val2 = intel_uncore_read(_priv->uncore,
> +MTL_MEM_SS_INFO_QGV_POINT(point, 1));
> + dclk = REG_FIELD_GET(MTL_DCLK_MASK, val);
> + sp->dclk = DIV_ROUND_UP((16667 * dclk) + 500, 1000);
> + sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val);
> + sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val);
> +
> + sp->t_rdpre = REG_FIELD_GET(MTL_TRDPRE_MASK, val2);
> + sp->t_ras = REG_FIELD_GET(MTL_TRAS_MASK, val2);
> +
> + sp->t_rc = sp->t_rp + sp->t_ras;
> +
> + return 0;
> +}
> +
> +int
> +intel_read_qgv_point_info(struct drm_i915_private *dev_priv,
> + struct intel_qgv_point *sp,
> + int point)
> +{
> + if (DISPLAY_VER(dev_priv) >= 14)
> + return mtl_read_qgv_point_info(dev_priv, sp, point);
> + else if (IS_DG1(dev_priv))
> + return dg1_mchbar_read_qgv_point_info(dev_priv, sp, point);
> + else
> + return icl_pcode_read_qgv_point_info(dev_priv, sp, point);
> +}
> +
> static int icl_get_qgv_points(struct drm_i915_private *dev_priv,
> struct intel_qgv_info *qi,
> bool is_y_tile)
> @@ -193,11 +224,7 @@ static int icl_get_qgv_points(struct drm_i915_private
> *dev_priv,
> for (i = 0; i < qi->num_points; i++) {
> struct intel_qgv_point *sp = >points[i];
>
> - if (IS_DG1(dev_priv))
> - ret = dg1_mchbar_read_qgv_point_info(dev_priv, sp,
> i);
> - else
> - ret = icl_pcode_read_qgv_point_info(dev_priv, sp,
> i);
> -
> + ret = intel_read_qgv_point_info(dev_priv, sp, i);
> if (ret)
> return ret;
>
> @@ -560,7 +587,7 @@ void intel_bw_init_hw(struct drm_i915_private
> *dev_priv)
>
> if (IS_DG2(dev_priv))
> dg2_get_bw_info(dev_priv);
> - else if (IS_ALDERLAKE_P(dev_priv))
> + else if (DISPLAY_VER(dev_priv) >= 13 || IS_ALDERLAKE_P(dev_priv))
> tgl_get_bw_info(dev_priv, _sa_info);
> else if (IS_ALDERLAKE_S(dev_priv))
> tgl_get_bw_info(dev_priv, _sa_info);
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index cb7ee3a24a58..b4c6665b0cf0 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -46,6 +46,11 @@ struct intel_bw_state {
> u8 num_active_planes[I915_MAX_PIPES];
> };
>
> +/* Parameters for Qclk Geyserville (QGV) */
> +struct intel_qgv_point {
> + u16 dclk, t_rp, t_rdpre, t_rc, t_ras, t_rcd;
> +};
> +
> #define to_intel_bw_state(x) container_of((x), struct intel_bw_state,
> base)
>
> struct intel_bw_state *
> @@ -69,4 +74,8 @@ int intel_bw_calc_min_cdclk(struct intel_atomic_state
> *state,
> int intel_bw_min_cdclk(struct drm_i915_private *i915,
>const struct intel_bw_state *bw_state);
>
> +int intel_read_qgv_point_info(struct
[Intel-gfx] [PATCH v2 4/5] media: videobuf2: Stop using internal dma-buf lock
All drivers that use dma-bufs have been moved to the updated locking
specification and now dma-buf reservation is guaranteed to be locked
by importers during the mapping operations. There is no need to take
the internal dma-buf lock anymore. Remove locking from the videobuf2
memory allocators.
Acked-by: Tomasz Figa
Signed-off-by: Dmitry Osipenko
---
drivers/media/common/videobuf2/videobuf2-dma-contig.c | 11 +--
drivers/media/common/videobuf2/videobuf2-dma-sg.c | 11 +--
drivers/media/common/videobuf2/videobuf2-vmalloc.c| 11 +--
3 files changed, 3 insertions(+), 30 deletions(-)
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
index de762dbdaf78..2c69bf0470e7 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-contig.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-contig.c
@@ -382,18 +382,12 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
{
struct vb2_dc_attachment *attach = db_attach->priv;
- /* stealing dmabuf mutex to serialize map/unmap operations */
- struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- mutex_lock(lock);
-
sgt = >sgt;
/* return previously mapped sg table */
- if (attach->dma_dir == dma_dir) {
- mutex_unlock(lock);
+ if (attach->dma_dir == dma_dir)
return sgt;
- }
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -409,14 +403,11 @@ static struct sg_table *vb2_dc_dmabuf_ops_map(
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir,
DMA_ATTR_SKIP_CPU_SYNC)) {
pr_err("failed to map scatterlist\n");
- mutex_unlock(lock);
return ERR_PTR(-EIO);
}
attach->dma_dir = dma_dir;
- mutex_unlock(lock);
-
return sgt;
}
diff --git a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
index 39e11600304a..e63e718c0bf7 100644
--- a/drivers/media/common/videobuf2/videobuf2-dma-sg.c
+++ b/drivers/media/common/videobuf2/videobuf2-dma-sg.c
@@ -424,18 +424,12 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
{
struct vb2_dma_sg_attachment *attach = db_attach->priv;
- /* stealing dmabuf mutex to serialize map/unmap operations */
- struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- mutex_lock(lock);
-
sgt = >sgt;
/* return previously mapped sg table */
- if (attach->dma_dir == dma_dir) {
- mutex_unlock(lock);
+ if (attach->dma_dir == dma_dir)
return sgt;
- }
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -446,14 +440,11 @@ static struct sg_table *vb2_dma_sg_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
- mutex_unlock(lock);
return ERR_PTR(-EIO);
}
attach->dma_dir = dma_dir;
- mutex_unlock(lock);
-
return sgt;
}
diff --git a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
index 7831bf545874..41db707e43a4 100644
--- a/drivers/media/common/videobuf2/videobuf2-vmalloc.c
+++ b/drivers/media/common/videobuf2/videobuf2-vmalloc.c
@@ -267,18 +267,12 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
struct dma_buf_attachment *db_attach, enum dma_data_direction dma_dir)
{
struct vb2_vmalloc_attachment *attach = db_attach->priv;
- /* stealing dmabuf mutex to serialize map/unmap operations */
- struct mutex *lock = _attach->dmabuf->lock;
struct sg_table *sgt;
- mutex_lock(lock);
-
sgt = >sgt;
/* return previously mapped sg table */
- if (attach->dma_dir == dma_dir) {
- mutex_unlock(lock);
+ if (attach->dma_dir == dma_dir)
return sgt;
- }
/* release any previous cache */
if (attach->dma_dir != DMA_NONE) {
@@ -289,14 +283,11 @@ static struct sg_table *vb2_vmalloc_dmabuf_ops_map(
/* mapping to the client with new direction */
if (dma_map_sgtable(db_attach->dev, sgt, dma_dir, 0)) {
pr_err("failed to map scatterlist\n");
- mutex_unlock(lock);
return ERR_PTR(-EIO);
}
attach->dma_dir = dma_dir;
- mutex_unlock(lock);
-
return sgt;
}
--
2.36.1
Re: [Intel-gfx] [PATCH v4 16/41] dyndbg: add drm.debug style bitmap support
On 7/20/22 11:32, Jim Cromie wrote:
> Add kernel_param_ops and callbacks to apply a class-map to a
> sysfs-node, which then can control classes defined in that class-map.
> This supports uses like:
>
> echo 0x3 > /sys/module/drm/parameters/debug
>
> IE add these:
>
> - int param_set_dyndbg_classes()
> - int param_get_dyndbg_classes()
> - struct kernel_param_ops param_ops_dyndbg_classes
>
> Following the model of kernel/params.c STANDARD_PARAM_DEFS, these are
> non-static and exported. This might be unnecessary here.
>
> get/set use an augmented kernel_param; the arg refs a new struct
> ddebug_classes_bitmap_param, initialized by DYNAMIC_DEBUG_CLASSBITS
> macro, which contains:
>
> BITS: a pointer to the user module's ulong holding the bits/state. By
> ref'g the client's bit-state _var, we coordinate with existing code
> (such as drm_debug_enabled) which uses the _var, so it works
> unchanged, even as the foundation is switched out underneath it..
> Using a ulong allows use of BIT() etc.
>
> FLAGS: dyndbg.flags toggled by changes to bitmap. Usually just "p".
>
> MAP: a pointer to struct ddebug_classes_map, which maps those
> class-names to .class_ids 0..N that the module is using. This
> class-map is declared & initialized by DEFINE_DYNDBG_CLASSMAP.
>
> map-type: add support here for DD_CLASS_DISJOINT, DD_CLASS_VERBOSE.
>
> These 2 class-types both expect an integer; _DISJOINT treats input
> like a bit-vector (ala drm.debug), and sets each bit accordingly.
>
> _VERBOSE treats input like a bit-pos:N, then sets bits(0..N)=1, and
> bits(N+1..max)=0. This applies (bit bits.
>
> cases DD_CLASS_SYMBOLIC, DD_CLASS_LEVELS are included for the complete
> picture, with commented out call to a following commit.
>
> NOTES:
>
> this now includes SYMBOLIC/LEVELS support, too tedious to keep
> separate thru all the tweaking.
>
> get-param undoes the bit-pos -> bitmap transform that set-param does
> on VERBOSE inputs, this gives the read-what-was-written property.
>
> _VERBOSE is overlay on _DISJOINT:
>
> verbose-maps still need class-names, even though theyre not usable at
> the sysfs interface (unlike with _SYMBOLIC/_LEVELS).
>
> - It must have a "V0" name,
>something below "V1" to turn "V1" off.
>__pr_debug_cls(V0,..) is printk, don't do that.
>
> - "class names" is required at the >control interface.
> - relative levels are not enforced at >control
>
> IOW this is possible, and maybe confusing:
>
> echo class V3 +p > control
> echo class V1 -p > control
>
> IMO thats ok, relative verbosity is an interface property.
>
> Signed-off-by: Jim Cromie
> ---
> . drop kp->mod->name as unneeded (build-dependent)
> ---
> include/linux/dynamic_debug.h | 18
> lib/dynamic_debug.c | 193 ++
> 2 files changed, 211 insertions(+)
>
> diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h
> index f57076e02767..b50bdd5c8184 100644
> --- a/include/linux/dynamic_debug.h
> +++ b/include/linux/dynamic_debug.h
> @@ -113,6 +113,12 @@ struct ddebug_class_map {
> #define NUM_TYPE_ARGS(eltype, ...) \
> (sizeof((eltype[]) {__VA_ARGS__}) / sizeof(eltype))
>
> +struct ddebug_classes_bitmap_param {
> + unsigned long *bits;
> + char flags[8];
> + const struct ddebug_class_map *map;
> +};
> +
> #if defined(CONFIG_DYNAMIC_DEBUG_CORE)
>
> int ddebug_add_module(struct _ddebug *tab, unsigned int num_debugs,
> @@ -274,6 +280,10 @@ void __dynamic_ibdev_dbg(struct _ddebug *descriptor,
> KERN_DEBUG, prefix_str, prefix_type, \
> rowsize, groupsize, buf, len, ascii)
>
> +struct kernel_param;
> +int param_set_dyndbg_classes(const char *instr, const struct kernel_param
> *kp);
> +int param_get_dyndbg_classes(char *buffer, const struct kernel_param *kp);
> +
> /* for test only, generally expect drm.debug style macro wrappers */
> #define __pr_debug_cls(cls, fmt, ...) do { \
> BUILD_BUG_ON_MSG(!__builtin_constant_p(cls),\
> @@ -322,6 +332,14 @@ static inline int ddebug_dyndbg_module_param_cb(char
> *param, char *val,
> rowsize, groupsize, buf, len, ascii); \
> } while (0)
>
> +struct kernel_param;
> +static inline int param_set_dyndbg_classes(const char *instr, const struct
> kernel_param *kp)
> +{ return 0; }
> +static inline int param_get_dyndbg_classes(char *buffer, const struct
> kernel_param *kp)
> +{ return 0; }
> +
> #endif /* !CONFIG_DYNAMIC_DEBUG_CORE */
>
> +extern const struct kernel_param_ops param_ops_dyndbg_classes;
> +
> #endif
> diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c
> index 4c27bbe5187e..dd27dc514aa3 100644
> --- a/lib/dynamic_debug.c
> +++ b/lib/dynamic_debug.c
> @@ -596,6 +596,199 @@ static int ddebug_exec_queries(char *query, const char
> *modname)
> return nfound;
> }
>
> +static int
[Intel-gfx] [PATCH v2 5/5] dma-buf: Remove internal lock
The internal dma-buf lock isn't needed anymore because the updated
locking specification claims that dma-buf reservation must be locked
by importers, and thus, the internal data is already protected by the
reservation lock. Remove the obsoleted internal lock.
Acked-by: Tomasz Figa
Signed-off-by: Dmitry Osipenko
---
drivers/dma-buf/dma-buf.c | 5 -
include/linux/dma-buf.h | 9 -
2 files changed, 14 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index bfdd551c7571..1d211ab400a1 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -656,7 +656,6 @@ struct dma_buf *dma_buf_export(const struct
dma_buf_export_info *exp_info)
dmabuf->file = file;
- mutex_init(>lock);
INIT_LIST_HEAD(>attachments);
mutex_lock(_list.lock);
@@ -1508,7 +1507,6 @@ int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct
iosys_map *map)
return -EINVAL;
dma_resv_lock(dmabuf->resv, NULL);
- mutex_lock(>lock);
if (dmabuf->vmapping_counter) {
dmabuf->vmapping_counter++;
BUG_ON(iosys_map_is_null(>vmap_ptr));
@@ -1528,7 +1526,6 @@ int dma_buf_vmap_unlocked(struct dma_buf *dmabuf, struct
iosys_map *map)
*map = dmabuf->vmap_ptr;
out_unlock:
- mutex_unlock(>lock);
dma_resv_unlock(dmabuf->resv);
return ret;
}
@@ -1549,13 +1546,11 @@ void dma_buf_vunmap_unlocked(struct dma_buf *dmabuf,
struct iosys_map *map)
BUG_ON(!iosys_map_is_equal(>vmap_ptr, map));
dma_resv_lock(dmabuf->resv, NULL);
- mutex_lock(>lock);
if (--dmabuf->vmapping_counter == 0) {
if (dmabuf->ops->vunmap)
dmabuf->ops->vunmap(dmabuf, map);
iosys_map_clear(>vmap_ptr);
}
- mutex_unlock(>lock);
dma_resv_unlock(dmabuf->resv);
}
EXPORT_SYMBOL_NS_GPL(dma_buf_vunmap_unlocked, DMA_BUF);
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index e7a6a8d28862..2f9fb7f3c835 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -326,15 +326,6 @@ struct dma_buf {
/** @ops: dma_buf_ops associated with this buffer object. */
const struct dma_buf_ops *ops;
- /**
-* @lock:
-*
-* Used internally to serialize list manipulation, attach/detach and
-* vmap/unmap. Note that in many cases this is superseeded by
-* dma_resv_lock() on @resv.
-*/
- struct mutex lock;
-
/**
* @vmapping_counter:
*
--
2.36.1
[Intel-gfx] [PATCH v2 3/5] dma-buf: Move all dma-bufs to dynamic locking specification
This patch moves the non-dynamic dma-buf users over to the dynamic locking specification. The strict locking convention prevents deadlock situation for dma-buf importers and exporters. Previously the "unlocked" versions of the dma-buf API functions weren't taking the reservation lock and this patch makes them to take the lock. Intel and AMD GPU drivers already were mapping imported dma-bufs under the held lock, hence the "locked" variant of the functions are added for them and the drivers are updated to use the "locked" versions. Signed-off-by: Dmitry Osipenko --- Documentation/driver-api/dma-buf.rst | 6 + drivers/dma-buf/dma-buf.c | 186 - drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 4 +- drivers/gpu/drm/drm_prime.c| 4 +- drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 8 +- include/linux/dma-buf.h| 28 ++-- 6 files changed, 179 insertions(+), 57 deletions(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 36a76cbe9095..622b8156d212 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -119,6 +119,12 @@ DMA Buffer ioctls .. kernel-doc:: include/uapi/linux/dma-buf.h +DMA-BUF locking convention +~ + +.. kernel-doc:: drivers/dma-buf/dma-buf.c + :doc: locking convention + Kernel Functions and Structures Reference ~ diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index d16237a6ffaa..bfdd551c7571 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -559,7 +559,7 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags) * 2. Userspace passes this file-descriptors to all drivers it wants this buffer *to share with: First the file descriptor is converted to a _buf using *dma_buf_get(). Then the buffer is attached to the device using - *dma_buf_attach(). + *dma_buf_attach_unlocked(). * *Up to this stage the exporter is still free to migrate or reallocate the *backing storage. @@ -569,8 +569,8 @@ static struct file *dma_buf_getfile(struct dma_buf *dmabuf, int flags) *dma_buf_map_attachment() and dma_buf_unmap_attachment(). * * 4. Once a driver is done with a shared buffer it needs to call - *dma_buf_detach() (after cleaning up any mappings) and then release the - *reference acquired with dma_buf_get() by calling dma_buf_put(). + *dma_buf_detach_unlocked() (after cleaning up any mappings) and then + *release the reference acquired with dma_buf_get() by calling dma_buf_put(). * * For the detailed semantics exporters are expected to implement see * _buf_ops. @@ -794,6 +794,63 @@ static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach, return sg_table; } +/** + * DOC: locking convention + * + * In order to avoid deadlock situations between dma-buf exports and importers, + * all dma-buf API users must follow the common dma-buf locking convention. + * + * Convention for importers + * + * 1. Importers must hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_pin() + * - dma_buf_unpin() + * - dma_buf_move_notify() + * - dma_buf_map_attachment_locked() + * - dma_buf_unmap_attachment_locked() + * + * 2. Importers must not hold the dma-buf reservation lock when calling these + *functions: + * + * - dma_buf_attach_unlocked() + * - dma_buf_dynamic_attach_unlocked() + * - dma_buf_detach_unlocked() + * - dma_buf_export( + * - dma_buf_fd() + * - dma_buf_get() + * - dma_buf_put() + * - dma_buf_begin_cpu_access() + * - dma_buf_end_cpu_access() + * - dma_buf_map_attachment_unlocked() + * - dma_buf_unmap_attachment_unlocked() + * - dma_buf_vmap_unlocked() + * - dma_buf_vunmap_unlocked() + * + * Convention for exporters + * + * 1. These _buf_ops callbacks are invoked with unlocked dma-buf + *reservation and exporter can take the lock: + * + * - _buf_ops.attach() + * - _buf_ops.detach() + * - _buf_ops.release() + * - _buf_ops.begin_cpu_access() + * - _buf_ops.end_cpu_access() + * + * 2. These _buf_ops callbacks are invoked with locked dma-buf + *reservation and exporter can't take the lock: + * + * - _buf_ops.pin() + * - _buf_ops.unpin() + * - _buf_ops.map_dma_buf() + * - _buf_ops.unmap_dma_buf() + * - _buf_ops.mmap() + * - _buf_ops.vmap() + * - _buf_ops.vunmap() + */ + /** * dma_buf_dynamic_attach_unlocked - Add the device to dma_buf's attachments list * @dmabuf:[in]buffer to attach device to. @@ -802,7 +859,7 @@ static struct sg_table * __map_dma_buf(struct dma_buf_attachment *attach, * @importer_priv: [in]importer private pointer for the attachment * * Returns struct dma_buf_attachment pointer for this
[Intel-gfx] [PATCH v2 2/5] drm/gem: Take reservation lock for vmap/vunmap operations
The new common dma-buf locking convention will require buffer importers
to hold the reservation lock around mapping operations. Make DRM GEM core
to take the lock around the vmapping operations and update QXL and i915
drivers to use the locked functions for the case where DRM core now holds
the lock. This patch prepares DRM core and drivers to transition to the
common dma-buf locking convention where vmapping of exported GEMs will
be done under the held reservation lock.
Signed-off-by: Dmitry Osipenko
---
drivers/gpu/drm/drm_client.c | 4 ++--
drivers/gpu/drm/drm_gem.c| 24
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 ++---
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 2 +-
drivers/gpu/drm/qxl/qxl_object.c | 17 +++---
drivers/gpu/drm/qxl/qxl_prime.c | 4 ++--
include/drm/drm_gem.h| 3 +++
8 files changed, 46 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
index af3b7395bf69..e9a1cd310352 100644
--- a/drivers/gpu/drm/drm_client.c
+++ b/drivers/gpu/drm/drm_client.c
@@ -323,7 +323,7 @@ drm_client_buffer_vmap(struct drm_client_buffer *buffer,
* fd_install step out of the driver backend hooks, to make that
* final step optional for internal users.
*/
- ret = drm_gem_vmap(buffer->gem, map);
+ ret = drm_gem_vmap_unlocked(buffer->gem, map);
if (ret)
return ret;
@@ -345,7 +345,7 @@ void drm_client_buffer_vunmap(struct drm_client_buffer
*buffer)
{
struct iosys_map *map = >map;
- drm_gem_vunmap(buffer->gem, map);
+ drm_gem_vunmap_unlocked(buffer->gem, map);
}
EXPORT_SYMBOL(drm_client_buffer_vunmap);
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index eb0c2d041f13..8b92846112ef 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -1171,6 +1171,8 @@ int drm_gem_vmap(struct drm_gem_object *obj, struct
iosys_map *map)
{
int ret;
+ dma_resv_assert_held(obj->resv);
+
if (!obj->funcs->vmap)
return -EOPNOTSUPP;
@@ -1186,6 +1188,8 @@ EXPORT_SYMBOL(drm_gem_vmap);
void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
{
+ dma_resv_assert_held(obj->resv);
+
if (iosys_map_is_null(map))
return;
@@ -1197,6 +1201,26 @@ void drm_gem_vunmap(struct drm_gem_object *obj, struct
iosys_map *map)
}
EXPORT_SYMBOL(drm_gem_vunmap);
+int drm_gem_vmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+ int ret;
+
+ dma_resv_lock(obj->resv, NULL);
+ ret = drm_gem_vmap(obj, map);
+ dma_resv_unlock(obj->resv);
+
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_vmap_unlocked);
+
+void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
+{
+ dma_resv_lock(obj->resv, NULL);
+ drm_gem_vunmap(obj, map);
+ dma_resv_unlock(obj->resv);
+}
+EXPORT_SYMBOL(drm_gem_vunmap_unlocked);
+
/**
* drm_gem_lock_reservations - Sets up the ww context and acquires
* the lock on an array of GEM objects.
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index 61339a9cd010..135cd4a96ea9 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -354,7 +354,7 @@ int drm_gem_fb_vmap(struct drm_framebuffer *fb, struct
iosys_map *map,
ret = -EINVAL;
goto err_drm_gem_vunmap;
}
- ret = drm_gem_vmap(obj, [i]);
+ ret = drm_gem_vmap_unlocked(obj, [i]);
if (ret)
goto err_drm_gem_vunmap;
}
@@ -376,7 +376,7 @@ int drm_gem_fb_vmap(struct drm_framebuffer *fb, struct
iosys_map *map,
obj = drm_gem_fb_get_obj(fb, i);
if (!obj)
continue;
- drm_gem_vunmap(obj, [i]);
+ drm_gem_vunmap_unlocked(obj, [i]);
}
return ret;
}
@@ -403,7 +403,7 @@ void drm_gem_fb_vunmap(struct drm_framebuffer *fb, struct
iosys_map *map)
continue;
if (iosys_map_is_null([i]))
continue;
- drm_gem_vunmap(obj, [i]);
+ drm_gem_vunmap_unlocked(obj, [i]);
}
}
EXPORT_SYMBOL(drm_gem_fb_vunmap);
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index b75ef1756873..1bd234fd21a5 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -678,7 +678,7 @@ int drm_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct
iosys_map *map)
{
struct drm_gem_object *obj = dma_buf->priv;
- return drm_gem_vmap(obj, map);
+ return drm_gem_vmap_unlocked(obj, map);
}
Re: [Intel-gfx] [PATCH v4 00/41] DYNDBG: opt-in class'd debug for modules, use in drm.
On 8/3/22 15:56, jim.cro...@gmail.com wrote: > On Wed, Jul 20, 2022 at 9:32 AM Jim Cromie wrote: >> > >> Hi Jason, Greg, DRM-folk, >> >> This adds 'typed' "class FOO" support to dynamic-debug, where 'typed' >> means either DISJOINT (like drm debug categories), or VERBOSE (like >> nouveau debug-levels). Use it in DRM modules: core, helpers, and in >> drivers i915, amdgpu, nouveau. >> > > This revision fell over, on a conflict with something in drm-MUMBLE > > Error: patch > https://urldefense.com/v3/__https://patchwork.freedesktop.org/api/1.0/series/106427/revisions/2/mbox/__;!!GjvTz_vk!UCPl5Uf32cDVwwysMTfaLwoGLWomargFXuR8HjBA3xsUOjxXHXC5hneAkP4iWK91yc-LjjJxWW89-51Z$ > > not applied > Applying: dyndbg: fix static_branch manipulation > Applying: dyndbg: fix module.dyndbg handling > Applying: dyndbg: show both old and new in change-info > Applying: dyndbg: reverse module walk in cat control > Applying: dyndbg: reverse module.callsite walk in cat control > Applying: dyndbg: use ESCAPE_SPACE for cat control > Applying: dyndbg: let query-modname override actual module name > Applying: dyndbg: add test_dynamic_debug module > Applying: dyndbg: drop EXPORTed dynamic_debug_exec_queries > > Jason, > those above are decent maintenance patches, particularly the drop export. > It would be nice to trim this unused api this cycle. Hi Jim, Agreed - I was thinking the same thing. Feel free to add Acked-by: Jason Baron to those first 9. > > Applying: dyndbg: add class_id to pr_debug callsites > Applying: dyndbg: add __pr_debug_cls for testing > Applying: dyndbg: add DECLARE_DYNDBG_CLASSMAP > Applying: kernel/module: add __dyndbg_classes section > Applying: dyndbg: add ddebug_attach_module_classes > Applying: dyndbg: validate class FOO by checking with module > Applying: dyndbg: add drm.debug style bitmap support > Applying: dyndbg: test DECLARE_DYNDBG_CLASSMAP, sysfs nodes > Applying: doc-dyndbg: describe "class CLASS_NAME" query support > Applying: doc-dyndbg: edit dynamic-debug-howto for brevity, audience > Applying: drm_print: condense enum drm_debug_category > Applying: drm: POC drm on dyndbg - use in core, 2 helpers, 3 drivers. > Applying: drm_print: interpose drm_*dbg with forwarding macros > Applying: drm_print: wrap drm_*_dbg in dyndbg descriptor factory macro > Using index info to reconstruct a base tree... > M drivers/gpu/drm/Kconfig > M drivers/gpu/drm/Makefile > Falling back to patching base and 3-way merge... > Auto-merging drivers/gpu/drm/Makefile > Auto-merging drivers/gpu/drm/Kconfig > CONFLICT (content): Merge conflict in drivers/gpu/drm/Kconfig > error: Failed to merge in the changes. > > > Before I resend, I should sort out that possible conflict > which tree is patchwork applied upon ? > > or was it just transient ? after 5.19 I rebased a copy onto drm-next/drm-next, > and there was nothing to fix - I will revisit presently.. Not sure, if it's a minor conflict maybe Greg KH can sort it when he pulls it in? If not yeah might be important to rebase first...Greg? Thanks, -Jason
Re: [Intel-gfx] [PATCH v4 12/41] dyndbg: add DECLARE_DYNDBG_CLASSMAP
On 7/20/22 11:32, Jim Cromie wrote: > DECLARE_DYNDBG_CLASSMAP lets modules declare a set of classnames, this > opt-in authorizes dyndbg to allow enabling of prdbgs by their class: > >:#> echo class DRM_UT_KMS +p > /proc/dynamic_debug/control > > This is just the setup; following commits deliver. > > The macro declares and initializes a static struct ddebug_class_map: > > - maps approved class-names to class_ids used in module, >by array order. forex: DRM_UT_* > - class-name vals allow validation of "class FOO" queries >using macro is opt-in > - enum class_map_type - determines interface, behavior > > Each module has its own .class_id space, and only known class-names > will be authorized for a manipulation. Only DRM stuff should know this: > > :#> echo class DRM_UT_CORE +p > control # across all modules > > pr_debugs (with default class_id) are still controllable as before. > > DECLARE_DYNDBG_CLASSMAP(_var, _maptype, _base, classes...) is:: > > _var: name of the static struct var. user passes to module_param_cb() >if they want a sysfs node. (ive only done it this way). > > _maptype: this is hard-coded to DD_CLASS_TYPE_DISJOINT for now. > > _base: usually 0, it allows splitting 31 classes into subranges, so > that multiple classes / sysfs-nodes can share the module's > class-id space. > > classes: list of class_name strings, these are mapped to class-ids > starting at _base. This class-names list must have a > corresponding ENUM, with SYMBOLS that match the literals, > and 1st enum val = _base. > > enum class_map_type has 4 values, on 2 factors:: > > - classes are disjoint/independent vs relative/xdisjoint is basis, verbosity by overlay. > > - input NUMBERS vs [+-]CLASS_NAMES >uints, ideally hex. vs +DRM_UT_CORE,-DRM_UT_KMS > Could the naming here directly reflect the 2 factors? At least for me I think it's more readable. So something like: > DD_CLASS_TYPE_DISJOINT: classes are separate, one per bit. >expecting hex input. basis for others. DD_CLASS_TYPE_DISJOINT_NUM > > DD_CLASS_TYPE_SYMBOLIC: input is a CSV of [+-]CLASS_NAMES, >classes are independent, like DISJOINT > DD_CLASS_TYPE_DISJOINT_NAME > DD_CLASS_TYPE_VERBOSE: input is numeric level, 0-N. >0 implies silence. use printk to break that. >relative levels applied on bitmaps. > DD_CLASS_TYPE_LEVEL_NUM > DD_CLASS_TYPE_LEVELS: input is a CSV of [+-]CLASS_NAMES, >names like: ERR,WARNING,NOTICE,INFO,DEBUG >avoiding EMERG,ALERT,CRIT,ERR - no point. > DD_CLASS_TYPE_LEVEL_NAME > NOTES: > > The macro places the initialized struct ddebug_class_map into the > __dyndbg_classes section. That draws a 'orphan' warning which we > handle in next commit. The struct attributes are necessary: > __aligned(8) stopped null-ptr derefs (why?), __used is needed by drm > drivers, which declare class-maps, but don't also declare a > sysfs-param, and thus dont ref the classmap; __used insures that the > linkage is made, then the class-map is found at load-time. > > While its possible to handle both NAMES and NUMBERS in the same > sys-interface, there is ambiguity to avoid, by disallowing them > together. Later, if ambiguities are resolved, 2 new enums can permit > both inputs, on verbose & independent types separately, and authors > can select the interface they like. > > RFC: > > My plan is to implement LEVELS in the callbacks, outside of > ddebug_exec_query(), which for simplicity will treat the CLASSES in > the map as disjoint. This should handle most situations. > > The callbacks can see map-type, and apply ++/-- loops (or bitops) to > force the relative meanings across the class-bitmap. > > That leaves 2 issues: > > 1. doing LEVELs in callbacks means that the native >control interface > doesn't enforce the LEVELS relationship, so you could confusingly have > V3 enabled, but V1 disabled. OTOH, the control iface already allows > infinite variety in the underlying callsites, despite the veneer of > uniformity suggested by the bitmap overlay, and LEVELS over that. > > 2. All dyndbg >control reduces to a query/command, includes +/-, which > is at-root a kernel patching operation with +/- semantics. And the > symbolic sys-node handling exposes it to the user: > > Consider whether these are/should-be 'exactly' the same: > ># force both 2 "half-duplex" relations >echo +V3,-V4 > /sys/module/test_dynamic_debug/p_VX > ># should these both do the same ? >echo +V3 > /sys/module/test_dynamic_debug/p_VX >echo -V4 > /sys/module/test_dynamic_debug/p_VX > > IOW, half relations are suggested by the +/-, and enum control of > individual behaviors leaves some room for this, especially wrt > handling [+-]SYMBOLIC inputs from the user. > > Signed-off-by: Jim Cromie > --- > include/linux/dynamic_debug.h | 55 +++ > 1 file changed, 55 insertions(+) > > diff --git
[Intel-gfx] [PATCH] drm: Fix typo 'the the' in comment
Replace 'the the' with 'the' in the comment.
Signed-off-by: Slark Xiao
---
drivers/gpu/drm/display/drm_dp_helper.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/panel/panel-novatek-nt35510.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_dp_helper.c
b/drivers/gpu/drm/display/drm_dp_helper.c
index e5bab236b3ae..32b295003f49 100644
--- a/drivers/gpu/drm/display/drm_dp_helper.c
+++ b/drivers/gpu/drm/display/drm_dp_helper.c
@@ -1597,7 +1597,7 @@ static int drm_dp_aux_reply_duration(const struct
drm_dp_aux_msg *msg)
/*
* Calculate the length of the i2c transfer in usec, assuming
- * the i2c bus speed is as specified. Gives the the "worst"
+ * the i2c bus speed is as specified. Gives the "worst"
* case estimate, ie. successful while as long as possible.
* Doesn't account the "MOT" bit, and instead assumes each
* message includes a START, ADDRESS and STOP. Neither does it
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa650..783a6ca41a61 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -65,7 +65,7 @@
/*
* Interrupt statistic for PMU. Increments the counter only if the
- * interrupt originated from the the GPU so interrupts from a device which
+ * interrupt originated from the GPU so interrupts from a device which
* shares the interrupt line are not accounted.
*/
static inline void pmu_irq_stats(struct drm_i915_private *i915,
diff --git a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
index 40ea41b0a5dd..4085822f619a 100644
--- a/drivers/gpu/drm/panel/panel-novatek-nt35510.c
+++ b/drivers/gpu/drm/panel/panel-novatek-nt35510.c
@@ -231,7 +231,7 @@ struct nt35510_config {
* bits 0..2 in the lower nibble controls HCK, the booster clock
* frequency, the values are the same as for PCK in @bt1ctr.
* bits 4..5 in the upper nibble controls BTH, the boosting
-* amplification for the the step-up circuit.
+* amplification for the step-up circuit.
* 0 = AVDD + VDDB
* 1 = AVDD - AVEE
* 2 = AVDD - AVEE + VDDB
--
2.25.1
Re: [Intel-gfx] [PATCH 00/23] Initial Meteorlake Support
On Thu, 04 Aug 2022, Jani Nikula wrote: > On Wed, 27 Jul 2022, Radhakrishna Sripada > wrote: >> The PCI Id's and platform definition are posted earlier. > > Please don't send patch series that aren't based on drm-tip or depend on > other patch series. Even if you've sent the PCI ID stuff earlier, > include all the dependencies in the series you post, to let the CI test > this, if only to check that it doesn't regress older platforms. I realize the build failure was something else, and the PCI IDs were *merged* already, not just posted. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/hdcp: register cleanup (rev2)
== Series Details ==
Series: drm/i915/hdcp: register cleanup (rev2)
URL : https://patchwork.freedesktop.org/series/106964/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11966 -> Patchwork_106964v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106964v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106964v2, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/index.html
Participating hosts (41 -> 41)
--
Additional (3): bat-rpls-1 bat-jsl-3 bat-dg2-8
Missing(3): fi-kbl-soraka fi-rkl-11600 bat-dg2-9
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106964v2:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
Known issues
Here are the changes found in Patchwork_106964v2 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-kbl-8809g: [FAIL][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-kbl-8809g/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-kbl-8809g/boot.html
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-kbl-guc: [PASS][5] -> [FAIL][6] ([i915#6253])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-kbl-guc/igt@debugfs_test@read_all_entries.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-kbl-guc/igt@debugfs_test@read_all_entries.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-8809g: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-kbl-8809g/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_backlight@basic-brightness:
- fi-kbl-8809g: NOTRUN -> [SKIP][9] ([fdo#109271]) +26 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-kbl-8809g/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gem:
- fi-pnv-d510:NOTRUN -> [DMESG-FAIL][10] ([i915#4528])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-pnv-d510/igt@i915_selftest@l...@gem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][11] -> [INCOMPLETE][12] ([i915#4785])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: [PASS][13] -> [DMESG-FAIL][14] ([i915#4494] /
[i915#4957])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-kbl-8809g: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-kbl-8809g/igt@kms_chamel...@dp-hpd-fast.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-2:
- fi-bdw-5557u: [PASS][16] -> [INCOMPLETE][17] ([i915#146])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-bdw-5557u/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-2.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-bdw-5557u/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-2.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][18] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v2/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][19] ([i915#2582]) -> [PASS][20] +4 similar
issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@fb...@read.html
[20]:
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed helper
On Thu, 2022-08-04 at 05:32 +, Tangudu, Tilak wrote:
>
>
> > -Original Message-
> > From: Vivi, Rodrigo
> > Sent: Thursday, August 4, 2022 2:01 AM
> > To: Tangudu, Tilak
> > Cc: Ewins, Jon ; Belgaumkar, Vinay
> > ; Roper, Matthew D
> > ; Wilson, Chris P
> > ;
> > Nikula, Jani ; Gupta, saurabhg
> > ; Gupta, Anshuman
> > ; Nilawar, Badal
> > ;
> > Deak, Imre ; Iddamsetty, Aravind
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed
> > helper
> >
> > On Thu, Jul 21, 2022 at 03:29:48PM +0530,
> > tilak.tang...@intel.com wrote:
> > > From: Tilak Tangudu
> > >
> > > Added is_intel_rpm_allowed function to query the runtime_pm
> > > status and
> > > disllow during suspending and resuming.
> >
> > >
> > > v2: Return -2 if runtime pm is not allowed in runtime_pm_get and
> > > skip
> > > wakeref release in runtime_pm_put if wakeref value is -2. - Jani
> > > N
> >
> > Should we have some defines instead of the -#s?
> Ok will address this.
> >
> > > Signed-off-by: Tilak Tangudu
> > > ---
> > > drivers/gpu/drm/i915/intel_runtime_pm.c | 23
> > ++-
> > > drivers/gpu/drm/i915/intel_runtime_pm.h | 1 +
> > > 2 files changed, 23 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > index 6ed5786bcd29..704beeeb560b 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > > @@ -113,7 +113,7 @@ static void
> > untrack_intel_runtime_pm_wakeref(struct intel_runtime_pm *rpm,
> > > unsigned long flags, n;
> > > bool found = false;
> > >
> > > - if (unlikely(stack == -1))
> > > + if (unlikely(stack == -1) || unlikely(stack == -2))
> > > return;
> > >
> > > spin_lock_irqsave(>debug.lock, flags); @@ -320,6
> > > +320,21
> > @@
> > > untrack_all_intel_runtime_pm_wakerefs(struct intel_runtime_pm
> > > *rpm) }
> > >
> > > #endif
> > > +static int intel_runtime_pm_status(struct intel_runtime_pm *rpm)
> > > {
> > > + return rpm->kdev->power.runtime_status; }
> > > +
> > > +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm)
> >
> > why not static?
> We need is_intel_rpm_allowed for rc6 helpers , the helpers use
> pm_runtime_get_sync,
> To avoid lock issue we need to use it here too.
>
> See this patch " drm/i915: Guard rc6 helpers with
> is_intel_rpm_allowed"
>
> >
> > > +{
> > > + int rpm_status;
> > > +
> > > + rpm_status = intel_runtime_pm_status(rpm);
> > > + if (rpm_status == RPM_RESUMING
> >
> > I don't have a good feeling about this. If we are resuming we
> > shouldn't grab
> > extra references... This seems a workaround for the lock mess.
> >
> > > > > rpm_status == RPM_SUSPENDING)
> >
> > and when we are suspending and we call this function is because we
> > need to
> > wake up, no?!
>
> As we have re-used i915_gem_backup_suspend, i915_gem_suspend_late
> and i915_gem_resume , These functions use runtime helpers, which in-
> turn call
> runtime suspend/resume callbacks and leads to deadlock.
> So, these helpers need to be avoided. we have added
> is_intel_rpm_allowed
> and disallowed rpm callbacks with above condition during suspending
> and resuming
> to avoid deadlock.
Why does these functions in suspend resume path are using the runtime
callbacks?
Can't we have a refactor on that area that allows the paths that we
need in a place where we are sure that device is not going to d3?
then we can have a clear infra?
> >
> > > + return false;
> > > + else
> > > + return true;
> > > +}
> > >
> > > static void
> > > intel_runtime_pm_acquire(struct intel_runtime_pm *rpm, bool
> > > wakelock)
> > > @@ -354,6 +369,9 @@ static intel_wakeref_t
> > __intel_runtime_pm_get(struct intel_runtime_pm *rpm,
> > > runtime_pm);
> > > int ret;
> > >
> > > + if (!is_intel_rpm_allowed(rpm))
> > > + return -2;
> > > +
> > > ret = pm_runtime_get_sync(rpm->kdev);
> > > drm_WARN_ONCE(>drm, ret < 0,
> > > "pm_runtime_get_sync() failed: %d\n", ret);
> > > @@ -490,6
> > +508,9
> > > @@ static void __intel_runtime_pm_put(struct intel_runtime_pm
> > > *rpm,
> > >
> > > untrack_intel_runtime_pm_wakeref(rpm, wref);
> > >
> > > + if (wref == -2)
> > > + return;
> > > +
> > > intel_runtime_pm_release(rpm, wakelock);
> > >
> > > pm_runtime_mark_last_busy(kdev);
> > > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h
> > > b/drivers/gpu/drm/i915/intel_runtime_pm.h
> > > index d9160e3ff4af..99418c3a934a 100644
> > > --- a/drivers/gpu/drm/i915/intel_runtime_pm.h
> > > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
> > > @@ -173,6 +173,7 @@ void intel_runtime_pm_init_early(struct
> > > intel_runtime_pm *rpm); void
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/6] drm/ttm: Add new callbacks to ttm res mgr
== Series Details ==
Series: series starting with [v4,1/6] drm/ttm: Add new callbacks to ttm res mgr
URL : https://patchwork.freedesktop.org/series/106961/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11966_full -> Patchwork_106961v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (10 -> 12)
--
Additional (2): shard-rkl shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106961v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s3-without-i915:
- {shard-tglu}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-tglu-4/igt@i915_susp...@basic-s3-without-i915.html
Known issues
Here are the changes found in Patchwork_106961v1_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][2], [PASS][3], [PASS][4], [PASS][5],
[PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
[PASS][25]) -> ([PASS][26], [FAIL][27], [PASS][28], [PASS][29], [PASS][30],
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
[PASS][49], [PASS][50]) ([i915#4392])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk1/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk1/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk1/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk1/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk2/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk2/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk3/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk3/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk3/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk5/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk5/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk6/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk6/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk7/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk7/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk7/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk8/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk8/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk8/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk9/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk9/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk9/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk1/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk1/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk2/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk2/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk2/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk3/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk3/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk3/boot.html
[36]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk5/boot.html
[37]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/shard-glk5/boot.html
[38]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hdcp: register cleanup (rev2)
== Series Details == Series: drm/i915/hdcp: register cleanup (rev2) URL : https://patchwork.freedesktop.org/series/106964/ State : warning == Summary == Error: dim checkpatch failed 99aa46795be6 drm/i915/hdcp: split out hdcp registers to a separate file Traceback (most recent call last): File "scripts/spdxcheck.py", line 11, in import git ModuleNotFoundError: No module named 'git' -:36: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #36: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 556 lines checked 67cfbcf96bc7 drm/i915/hdcp: replace BIT() with REG_BIT() in register definitions
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/combo_phy: Add Workaround to avoid flicker with HBR3 eDP Panels
== Series Details ==
Series: drm/i915/combo_phy: Add Workaround to avoid flicker with HBR3 eDP Panels
URL : https://patchwork.freedesktop.org/series/106967/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11966 -> Patchwork_106967v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106967v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106967v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/index.html
Participating hosts (41 -> 41)
--
Additional (2): bat-rpls-1 bat-jsl-3
Missing(2): fi-kbl-soraka fi-rkl-11600
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106967v1:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@basic-rte:
- fi-adl-ddr5:[PASS][1] -> [DMESG-WARN][2] +8 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-adl-ddr5/igt@i915_pm_...@basic-rte.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/fi-adl-ddr5/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- bat-adlp-4: [PASS][3] -> [DMESG-WARN][4] +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-adlp-4/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/bat-adlp-4/igt@i915_pm_...@module-reload.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-hdmi-a-1:
- fi-rkl-guc: [PASS][5] -> [DMESG-WARN][6] +7 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-rkl-guc/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/fi-rkl-guc/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-hdmi-a-1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@basic-rte:
- {bat-rplp-1}: [PASS][7] -> [DMESG-WARN][8] +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rplp-1/igt@i915_pm_...@basic-rte.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/bat-rplp-1/igt@i915_pm_...@basic-rte.html
- {bat-rpls-2}: [PASS][9] -> [DMESG-WARN][10] +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@i915_pm_...@basic-rte.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/bat-rpls-2/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- {bat-adlp-6}: [PASS][11] -> [DMESG-WARN][12] +8 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-adlp-6/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/bat-adlp-6/igt@i915_pm_...@module-reload.html
- {bat-adlm-1}: [PASS][13] -> [DMESG-WARN][14] +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-adlm-1/igt@i915_pm_...@module-reload.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/bat-adlm-1/igt@i915_pm_...@module-reload.html
- {bat-rpls-1}: NOTRUN -> [DMESG-WARN][15] +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/bat-rpls-1/igt@i915_pm_...@module-reload.html
Known issues
Here are the changes found in Patchwork_106967v1 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-kbl-8809g: [FAIL][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-kbl-8809g/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/fi-kbl-8809g/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2190])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-8809g: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#4613]) +3
similar issues
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/fi-kbl-8809g/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_backlight@basic-brightness:
- fi-kbl-8809g: NOTRUN -> [SKIP][20] ([fdo#109271]) +26 similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106967v1/fi-kbl-8809g/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6:
Re: [Intel-gfx] PR for new GuC v70.4.1 for DG2
On Mon, Aug 1, 2022 at 2:02 PM wrote: > > The following changes since commit 150864a4d73e8c448eb1e2c68e65f07635fe1a66: > > amdgpu partially revert "amdgpu: update beige goby to release 22.20" > (2022-07-25 14:16:04 -0400) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-firmware dg2_guc_v70.4.1 Pulled and pushed out. Thank you. josh > > for you to fetch changes up to a4235e0aa4d4753119fd81f582eef84addf3f4a1: > > i915: Add GuC v70.4.1 for DG2 (2022-07-27 18:03:49 -0700) > > > John Harrison (1): > i915: Add GuC v70.4.1 for DG2 > > WHENCE | 3 +++ > i915/dg2_guc_70.4.1.bin | Bin 0 -> 369600 bytes > 2 files changed, 3 insertions(+) > create mode 100644 i915/dg2_guc_70.4.1.bin
Re: [Intel-gfx] i915 Updates: DG2 DMC v2.07
On Fri, Jul 29, 2022 at 1:25 PM Tolakanahalli Pradeep, Madhumitha wrote: > > Kindly add the below changes to linux-firmware: > > The following changes since commit 150864a4d73e8c448eb1e2c68e65f07635fe1a66: > > amdgpu partially revert "amdgpu: update beige goby to release 22.20" > (2022-07- > 25 14:16:04 -0400) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-firmware dg2_dmc_2_07 Pulled and pushed out. josh > > for you to fetch changes up to 3ab394af47ab6b0139a3fa6a7b39564a4d18cb25: > > i915: Add DMC v2.07 for DG2 (2022-07-27 10:52:59 -0700) > > > Anusha Srivatsa (1): > i915: Add DMC v2.07 for DG2 > > WHENCE | 3 +++ > i915/dg2_dmc_ver2_07.bin | Bin 0 -> 22488 bytes > 2 files changed, 3 insertions(+) > create mode 100644 i915/dg2_dmc_ver2_07.bin > > -- > 2.37.1 > > Thanks! > - Madhumitha
[Intel-gfx] ✗ Fi.CI.IGT: failure for Enabling Pipewriteback (rev3)
== Series Details ==
Series: Enabling Pipewriteback (rev3)
URL : https://patchwork.freedesktop.org/series/106902/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11966_full -> Patchwork_106902v3_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106902v3_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106902v3_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 12)
--
Additional (2): shard-rkl shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106902v3_full:
### IGT changes ###
Possible regressions
* igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_gen12_rc_ccs_cc:
- shard-tglb: [PASS][1] -> [DMESG-WARN][2] +11 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-tglb5/igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-tglb1/igt@kms_ccs@pipe-b-bad-rotation-90-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_flip@blocking-absolute-wf_vblank@b-edp1:
- shard-tglb: [PASS][3] -> [DMESG-FAIL][4] +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-tglb5/igt@kms_flip@blocking-absolute-wf_vbl...@b-edp1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-tglb1/igt@kms_flip@blocking-absolute-wf_vbl...@b-edp1.html
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-tglb: [PASS][5] -> [TIMEOUT][6] +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-tglb3/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-max.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-tglb7/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-max.html
* igt@kms_rmfb@close-fd@pipe-b-edp-1:
- shard-tglb: [PASS][7] -> [INCOMPLETE][8] +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-tglb3/igt@kms_rmfb@close...@pipe-b-edp-1.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-tglb7/igt@kms_rmfb@close...@pipe-b-edp-1.html
Warnings
* igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scaling@pipe-b-edp-1:
- shard-tglb: [SKIP][9] ([i915#5176]) -> [INCOMPLETE][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-tglb5/igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scal...@pipe-b-edp-1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-tglb3/igt@kms_plane_scaling@plane-scaler-with-rotation-unity-scal...@pipe-b-edp-1.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@core_hotunplug@unbind-rebind:
- {shard-tglu}: NOTRUN -> [DMESG-WARN][11] +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-tglu-3/igt@core_hotunp...@unbind-rebind.html
* igt@gem_ppgtt@blt-vs-render-ctxn:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][12]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-rkl-5/igt@gem_pp...@blt-vs-render-ctxn.html
* igt@i915_suspend@basic-s3-without-i915:
- {shard-tglu}: NOTRUN -> [INCOMPLETE][13]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-tglu-1/igt@i915_susp...@basic-s3-without-i915.html
Known issues
Here are the changes found in Patchwork_106902v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][14] -> [FAIL][15] ([i915#6268])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-tglb1/igt@gem_ctx_e...@basic-nohangcheck.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-tglb2/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][16] -> [SKIP][17] ([i915#4525]) +2 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-iclb2/igt@gem_exec_balan...@parallel-contexts.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-iclb8/igt@gem_exec_balan...@parallel-contexts.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: NOTRUN -> [FAIL][18] ([i915#2846])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/shard-glk5/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-tglb: [PASS][19] ->
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/hdcp: register cleanup
== Series Details ==
Series: drm/i915/hdcp: register cleanup
URL : https://patchwork.freedesktop.org/series/106964/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11966 -> Patchwork_106964v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_106964v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_106964v1, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/index.html
Participating hosts (41 -> 40)
--
Additional (2): bat-rpls-1 bat-dg2-8
Missing(3): fi-kbl-soraka bat-adlm-1 fi-rkl-11600
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106964v1:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@guc_hang:
- fi-cfl-8109u: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-cfl-8109u/igt@i915_selftest@live@guc_hang.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/fi-cfl-8109u/igt@i915_selftest@live@guc_hang.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s3-without-i915:
- {bat-dg2-8}:NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html
Known issues
Here are the changes found in Patchwork_106964v1 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-kbl-8809g: [FAIL][4] -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-kbl-8809g/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/fi-kbl-8809g/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-8809g: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/fi-kbl-8809g/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_backlight@basic-brightness:
- fi-kbl-8809g: NOTRUN -> [SKIP][8] ([fdo#109271]) +26 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/fi-kbl-8809g/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-rte:
- fi-cfl-8109u: [PASS][9] -> [DMESG-WARN][10] ([i915#1888] /
[i915#62])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [PASS][11] -> [DMESG-FAIL][12] ([i915#62])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][13] -> [INCOMPLETE][14] ([i915#4418])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][15] -> [INCOMPLETE][16] ([i915#4785])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u: [PASS][17] -> [DMESG-WARN][18] ([i915#5904]) +29
similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106964v1/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8109u: [PASS][19] -> [DMESG-WARN][20] ([i915#5904] /
[i915#62])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
[20]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/hdcp: register cleanup
== Series Details == Series: drm/i915/hdcp: register cleanup URL : https://patchwork.freedesktop.org/series/106964/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/hdcp: register cleanup
== Series Details == Series: drm/i915/hdcp: register cleanup URL : https://patchwork.freedesktop.org/series/106964/ State : warning == Summary == Error: dim checkpatch failed ba366d332f4c drm/i915/hdcp: split out hdcp registers to a separate file Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:36: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #36: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 556 lines checked 41c107fcd634 drm/i915/hdcp: replace BIT() with REG_BIT() in register definitions
[Intel-gfx] [PATCH] drm/i915/combo_phy: Add Workaround to avoid flicker with HBR3 eDP Panels
WA_14014367875 : When Display PHY is configured in continuous DCC calibration mode, the DCC (duty cycle correction) for the clock erroneously goes through a state where the DCC code is 0x00 when it is supposed to be transitioning from 0x10 to 0x0F. This glitch causes a distortion in the clock, which leads to a bit error. The issue is known to be causing flickering with eDP HBR3 panels. The work around configures the DCC in one-time-update mode. This mode updates the DCC code one time during training and then it does not change. This will prevent on-the-fly updates so that the glitch does not occur. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_combo_phy.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c b/drivers/gpu/drm/i915/display/intel_combo_phy.c index 64890f39c3cc..1b8bdc47671d 100644 --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c @@ -242,9 +242,10 @@ static bool icl_combo_phy_verify_state(struct drm_i915_private *dev_priv, ICL_PORT_TX_DW8_ODCC_CLK_SEL | ICL_PORT_TX_DW8_ODCC_CLK_DIV_SEL_DIV2); + /* WA_14014367875 Set DCC calibration mode to Read once*/ ret &= check_phy_reg(dev_priv, phy, ICL_PORT_PCS_DW1_LN(0, phy), DCC_MODE_SELECT_MASK, -DCC_MODE_SELECT_CONTINUOSLY); +~DCC_MODE_SELECT_MASK); } ret &= icl_verify_procmon_ref_values(dev_priv, phy); @@ -366,8 +367,9 @@ static void icl_combo_phys_init(struct drm_i915_private *dev_priv) intel_de_write(dev_priv, ICL_PORT_TX_DW8_GRP(phy), val); val = intel_de_read(dev_priv, ICL_PORT_PCS_DW1_LN(0, phy)); + + /* WA_14014367875 Set DCC calibration mode to Read once*/ val &= ~DCC_MODE_SELECT_MASK; - val |= DCC_MODE_SELECT_CONTINUOSLY; intel_de_write(dev_priv, ICL_PORT_PCS_DW1_GRP(phy), val); } -- 2.25.1
[Intel-gfx] ✓ Fi.CI.IGT: success for Move TLB invalidation code for its own file and document it (rev4)
== Series Details ==
Series: Move TLB invalidation code for its own file and document it (rev4)
URL : https://patchwork.freedesktop.org/series/106805/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11966_full -> Patchwork_106805v4_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (10 -> 12)
--
Additional (2): shard-rkl shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106805v4_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ppgtt@blt-vs-render-ctx0:
- {shard-rkl}:NOTRUN -> [DMESG-FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-rkl-5/igt@gem_pp...@blt-vs-render-ctx0.html
Known issues
Here are the changes found in Patchwork_106805v4_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][2], [PASS][3], [PASS][4], [PASS][5],
[PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
[PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30],
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [FAIL][36],
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
[PASS][49], [PASS][50]) ([i915#4392])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk1/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk1/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk1/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk1/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk2/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk2/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk3/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk3/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk3/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk5/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk5/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk6/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk6/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk7/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk7/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk7/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk8/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk8/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk8/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk9/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk9/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk9/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk8/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk9/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk8/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk9/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk9/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk1/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk1/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk1/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk2/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk2/boot.html
[36]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk2/boot.html
[37]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk2/boot.html
[38]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/shard-glk2/boot.html
[Intel-gfx] [PATCH 2/2] drm/i915/hdcp: replace BIT() with REG_BIT() in register definitions
Registers contents are supposed to be defined using REG_BIT() to ensure they're u32 and the shift is within bounds. Signed-off-by: Jani Nikula --- .../gpu/drm/i915/display/intel_hdcp_regs.h| 90 +-- 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_regs.h b/drivers/gpu/drm/i915/display/intel_hdcp_regs.h index cbeab64e69d2..2a3733e8966c 100644 --- a/drivers/gpu/drm/i915/display/intel_hdcp_regs.h +++ b/drivers/gpu/drm/i915/display/intel_hdcp_regs.h @@ -10,30 +10,30 @@ /* HDCP Key Registers */ #define HDCP_KEY_CONF _MMIO(0x66c00) -#define HDCP_AKSV_SEND_TRIGGERBIT(31) -#define HDCP_CLEAR_KEYS_TRIGGER BIT(30) -#define HDCP_KEY_LOAD_TRIGGER BIT(8) +#define HDCP_AKSV_SEND_TRIGGERREG_BIT(31) +#define HDCP_CLEAR_KEYS_TRIGGER REG_BIT(30) +#define HDCP_KEY_LOAD_TRIGGER REG_BIT(8) #define HDCP_KEY_STATUS_MMIO(0x66c04) -#define HDCP_FUSE_IN_PROGRESS BIT(7) -#define HDCP_FUSE_ERROR BIT(6) -#define HDCP_FUSE_DONEBIT(5) -#define HDCP_KEY_LOAD_STATUS BIT(1) -#define HDCP_KEY_LOAD_DONEBIT(0) +#define HDCP_FUSE_IN_PROGRESS REG_BIT(7) +#define HDCP_FUSE_ERROR REG_BIT(6) +#define HDCP_FUSE_DONEREG_BIT(5) +#define HDCP_KEY_LOAD_STATUS REG_BIT(1) +#define HDCP_KEY_LOAD_DONEREG_BIT(0) #define HDCP_AKSV_LO _MMIO(0x66c10) #define HDCP_AKSV_HI _MMIO(0x66c14) /* HDCP Repeater Registers */ #define HDCP_REP_CTL _MMIO(0x66d00) -#define HDCP_TRANSA_REP_PRESENT BIT(31) -#define HDCP_TRANSB_REP_PRESENT BIT(30) -#define HDCP_TRANSC_REP_PRESENT BIT(29) -#define HDCP_TRANSD_REP_PRESENT BIT(28) -#define HDCP_DDIB_REP_PRESENT BIT(30) -#define HDCP_DDIA_REP_PRESENT BIT(29) -#define HDCP_DDIC_REP_PRESENT BIT(28) -#define HDCP_DDID_REP_PRESENT BIT(27) -#define HDCP_DDIF_REP_PRESENT BIT(26) -#define HDCP_DDIE_REP_PRESENT BIT(25) +#define HDCP_TRANSA_REP_PRESENT REG_BIT(31) +#define HDCP_TRANSB_REP_PRESENT REG_BIT(30) +#define HDCP_TRANSC_REP_PRESENT REG_BIT(29) +#define HDCP_TRANSD_REP_PRESENT REG_BIT(28) +#define HDCP_DDIB_REP_PRESENT REG_BIT(30) +#define HDCP_DDIA_REP_PRESENT REG_BIT(29) +#define HDCP_DDIC_REP_PRESENT REG_BIT(28) +#define HDCP_DDID_REP_PRESENT REG_BIT(27) +#define HDCP_DDIF_REP_PRESENT REG_BIT(26) +#define HDCP_DDIE_REP_PRESENT REG_BIT(25) #define HDCP_TRANSA_SHA1_M0 (1 << 20) #define HDCP_TRANSB_SHA1_M0 (2 << 20) #define HDCP_TRANSC_SHA1_M0 (3 << 20) @@ -44,10 +44,10 @@ #define HDCP_DDID_SHA1_M0 (4 << 20) #define HDCP_DDIF_SHA1_M0 (5 << 20) #define HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */ -#define HDCP_SHA1_BUSYBIT(16) -#define HDCP_SHA1_READY BIT(17) -#define HDCP_SHA1_COMPLETEBIT(18) -#define HDCP_SHA1_V_MATCH BIT(19) +#define HDCP_SHA1_BUSYREG_BIT(16) +#define HDCP_SHA1_READY REG_BIT(17) +#define HDCP_SHA1_COMPLETEREG_BIT(18) +#define HDCP_SHA1_V_MATCH REG_BIT(19) #define HDCP_SHA1_TEXT_32 (1 << 1) #define HDCP_SHA1_COMPLETE_HASH (2 << 1) #define HDCP_SHA1_TEXT_24 (4 << 1) @@ -86,8 +86,8 @@ TRANS_HDCP_CONF(trans) : \ PORT_HDCP_CONF(port)) -#define HDCP_CONF_CAPTURE_AN BIT(0) -#define HDCP_CONF_AUTH_AND_ENC(BIT(1) | BIT(0)) +#define HDCP_CONF_CAPTURE_AN REG_BIT(0) +#define HDCP_CONF_AUTH_AND_ENC(REG_BIT(1) | REG_BIT(0)) #define PORT_HDCP_ANINIT(port) _PORT_HDCP_AUTHENC(port, 0x4) #define _TRANSA_HDCP_ANINIT0x66404 #define _TRANSB_HDCP_ANINIT0x66504 @@ -163,16 +163,16 @@ TRANS_HDCP_STATUS(trans) : \ PORT_HDCP_STATUS(port)) -#define HDCP_STATUS_STREAM_A_ENC BIT(31) -#define HDCP_STATUS_STREAM_B_ENC BIT(30) -#define HDCP_STATUS_STREAM_C_ENC BIT(29) -#define HDCP_STATUS_STREAM_D_ENC BIT(28) -#define HDCP_STATUS_AUTH BIT(21) -#define HDCP_STATUS_ENC BIT(20) -#define HDCP_STATUS_RI_MATCH BIT(19) -#define HDCP_STATUS_R0_READY BIT(18) -#define HDCP_STATUS_AN_READY BIT(17) -#define HDCP_STATUS_CIPHERBIT(16) +#define HDCP_STATUS_STREAM_A_ENC REG_BIT(31) +#define HDCP_STATUS_STREAM_B_ENC REG_BIT(30) +#define HDCP_STATUS_STREAM_C_ENC REG_BIT(29) +#define
[Intel-gfx] [PATCH 1/2] drm/i915/hdcp: split out hdcp registers to a separate file
Reduce the bloat of i915_reg.h. The registers are also only needed in a
few places, no need to have them defined everywhere.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 1 +
drivers/gpu/drm/i915/display/intel_hdcp.c | 1 +
.../gpu/drm/i915/display/intel_hdcp_regs.h| 270 ++
drivers/gpu/drm/i915/display/intel_hdmi.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 259 -
5 files changed, 273 insertions(+), 259 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_regs.h
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index a7640dbcf00e..88689124c013 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -17,6 +17,7 @@
#include "intel_dp.h"
#include "intel_dp_hdcp.h"
#include "intel_hdcp.h"
+#include "intel_hdcp_regs.h"
static unsigned int transcoder_to_stream_enc_status(enum transcoder
cpu_transcoder)
{
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index 8ea66a2e1b09..c5e9e86bb4cb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -23,6 +23,7 @@
#include "intel_display_power_well.h"
#include "intel_display_types.h"
#include "intel_hdcp.h"
+#include "intel_hdcp_regs.h"
#include "intel_pcode.h"
#define KEY_LOAD_TRIES 5
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp_regs.h
b/drivers/gpu/drm/i915/display/intel_hdcp_regs.h
new file mode 100644
index ..cbeab64e69d2
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_hdcp_regs.h
@@ -0,0 +1,270 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef __INTEL_HDCP_REGS_H__
+#define __INTEL_HDCP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* HDCP Key Registers */
+#define HDCP_KEY_CONF _MMIO(0x66c00)
+#define HDCP_AKSV_SEND_TRIGGERBIT(31)
+#define HDCP_CLEAR_KEYS_TRIGGER BIT(30)
+#define HDCP_KEY_LOAD_TRIGGER BIT(8)
+#define HDCP_KEY_STATUS_MMIO(0x66c04)
+#define HDCP_FUSE_IN_PROGRESS BIT(7)
+#define HDCP_FUSE_ERROR BIT(6)
+#define HDCP_FUSE_DONEBIT(5)
+#define HDCP_KEY_LOAD_STATUS BIT(1)
+#define HDCP_KEY_LOAD_DONEBIT(0)
+#define HDCP_AKSV_LO _MMIO(0x66c10)
+#define HDCP_AKSV_HI _MMIO(0x66c14)
+
+/* HDCP Repeater Registers */
+#define HDCP_REP_CTL _MMIO(0x66d00)
+#define HDCP_TRANSA_REP_PRESENT BIT(31)
+#define HDCP_TRANSB_REP_PRESENT BIT(30)
+#define HDCP_TRANSC_REP_PRESENT BIT(29)
+#define HDCP_TRANSD_REP_PRESENT BIT(28)
+#define HDCP_DDIB_REP_PRESENT BIT(30)
+#define HDCP_DDIA_REP_PRESENT BIT(29)
+#define HDCP_DDIC_REP_PRESENT BIT(28)
+#define HDCP_DDID_REP_PRESENT BIT(27)
+#define HDCP_DDIF_REP_PRESENT BIT(26)
+#define HDCP_DDIE_REP_PRESENT BIT(25)
+#define HDCP_TRANSA_SHA1_M0 (1 << 20)
+#define HDCP_TRANSB_SHA1_M0 (2 << 20)
+#define HDCP_TRANSC_SHA1_M0 (3 << 20)
+#define HDCP_TRANSD_SHA1_M0 (4 << 20)
+#define HDCP_DDIB_SHA1_M0 (1 << 20)
+#define HDCP_DDIA_SHA1_M0 (2 << 20)
+#define HDCP_DDIC_SHA1_M0 (3 << 20)
+#define HDCP_DDID_SHA1_M0 (4 << 20)
+#define HDCP_DDIF_SHA1_M0 (5 << 20)
+#define HDCP_DDIE_SHA1_M0 (6 << 20) /* Bspec says 5? */
+#define HDCP_SHA1_BUSYBIT(16)
+#define HDCP_SHA1_READY BIT(17)
+#define HDCP_SHA1_COMPLETEBIT(18)
+#define HDCP_SHA1_V_MATCH BIT(19)
+#define HDCP_SHA1_TEXT_32 (1 << 1)
+#define HDCP_SHA1_COMPLETE_HASH (2 << 1)
+#define HDCP_SHA1_TEXT_24 (4 << 1)
+#define HDCP_SHA1_TEXT_16 (5 << 1)
+#define HDCP_SHA1_TEXT_8 (6 << 1)
+#define HDCP_SHA1_TEXT_0 (7 << 1)
+#define HDCP_SHA_V_PRIME_H0_MMIO(0x66d04)
+#define HDCP_SHA_V_PRIME_H1_MMIO(0x66d08)
+#define HDCP_SHA_V_PRIME_H2_MMIO(0x66d0C)
+#define HDCP_SHA_V_PRIME_H3_MMIO(0x66d10)
+#define HDCP_SHA_V_PRIME_H4_MMIO(0x66d14)
+#define HDCP_SHA_V_PRIME(h)_MMIO((0x66d04 + (h) * 4))
+#define HDCP_SHA_TEXT _MMIO(0x66d18)
+
+/* HDCP Auth Registers */
+#define _PORTA_HDCP_AUTHENC0x66800
+#define _PORTB_HDCP_AUTHENC0x66500
+#define _PORTC_HDCP_AUTHENC0x66600
+#define _PORTD_HDCP_AUTHENC0x66700
+#define _PORTE_HDCP_AUTHENC0x66A00
+#define _PORTF_HDCP_AUTHENC0x66900
+#define _PORT_HDCP_AUTHENC(port, x)_MMIO(_PICK(port, \
+ _PORTA_HDCP_AUTHENC, \
+
[Intel-gfx] [PATCH 0/2] drm/i915/hdcp: register cleanup
Posting some cleanups I had written earlier. Jani Nikula (2): drm/i915/hdcp: split out hdcp registers to a separate file drm/i915/hdcp: replace BIT() with REG_BIT() in register definitions drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 1 + drivers/gpu/drm/i915/display/intel_hdcp.c | 1 + .../gpu/drm/i915/display/intel_hdcp_regs.h| 270 ++ drivers/gpu/drm/i915/display/intel_hdmi.c | 1 + drivers/gpu/drm/i915/i915_reg.h | 259 - 5 files changed, 273 insertions(+), 259 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_hdcp_regs.h -- 2.30.2
Re: [Intel-gfx] [PATCH v3 2/3] drm/amdgpu_dm: Rely on split out luminance calculation function
On Tue, 19 Jul 2022, Jouni Högander wrote:
> Luminance range calculation was split out into drm_edid.c and is now
> part of edid parsing. Rely on values calculated during edid parsing and
> use these for caps->aux_max_input_signal and caps->aux_min_input_signal.
Harry, I'll merge patches 1 & 3 in this series through drm-misc-next,
because I think they're good to go, and fix stuff in i915.
Can I get your rb/ack to merge this patch as well, or do you want to
take this later via your tree?
BR,
Jani.
>
> v2: Use values calculated during edid parsing
>
> Cc: Roman Li
> Cc: Rodrigo Siqueira
> Cc: Harry Wentland
> Cc: Lyude Paul
> Cc: Mika Kahola
> Cc: Jani Nikula
> Cc: Manasi Navare
> Signed-off-by: Jouni Högander
> ---
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 35 +++
> 1 file changed, 4 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 3e83fed540e8..eb7abdeb8653 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -2903,15 +2903,12 @@ static struct drm_mode_config_helper_funcs
> amdgpu_dm_mode_config_helperfuncs = {
>
> static void update_connector_ext_caps(struct amdgpu_dm_connector *aconnector)
> {
> - u32 max_avg, min_cll, max, min, q, r;
> struct amdgpu_dm_backlight_caps *caps;
> struct amdgpu_display_manager *dm;
> struct drm_connector *conn_base;
> struct amdgpu_device *adev;
> struct dc_link *link = NULL;
> - static const u8 pre_computed_values[] = {
> - 50, 51, 52, 53, 55, 56, 57, 58, 59, 61, 62, 63, 65, 66, 68, 69,
> - 71, 72, 74, 75, 77, 79, 81, 82, 84, 86, 88, 90, 92, 94, 96, 98};
> + struct drm_luminance_range_info *luminance_range;
> int i;
>
> if (!aconnector || !aconnector->dc_link)
> @@ -2933,8 +2930,6 @@ static void update_connector_ext_caps(struct
> amdgpu_dm_connector *aconnector)
> caps = >backlight_caps[i];
> caps->ext_caps = >dc_link->dpcd_sink_ext_caps;
> caps->aux_support = false;
> - max_avg = conn_base->hdr_sink_metadata.hdmi_type1.max_fall;
> - min_cll = conn_base->hdr_sink_metadata.hdmi_type1.min_cll;
>
> if (caps->ext_caps->bits.oled == 1 /*||
> caps->ext_caps->bits.sdr_aux_backlight_control == 1 ||
> @@ -2946,31 +2941,9 @@ static void update_connector_ext_caps(struct
> amdgpu_dm_connector *aconnector)
> else if (amdgpu_backlight == 1)
> caps->aux_support = true;
>
> - /* From the specification (CTA-861-G), for calculating the maximum
> - * luminance we need to use:
> - * Luminance = 50*2**(CV/32)
> - * Where CV is a one-byte value.
> - * For calculating this expression we may need float point precision;
> - * to avoid this complexity level, we take advantage that CV is divided
> - * by a constant. From the Euclids division algorithm, we know that CV
> - * can be written as: CV = 32*q + r. Next, we replace CV in the
> - * Luminance expression and get 50*(2**q)*(2**(r/32)), hence we just
> - * need to pre-compute the value of r/32. For pre-computing the values
> - * We just used the following Ruby line:
> - * (0...32).each {|cv| puts (50*2**(cv/32.0)).round}
> - * The results of the above expressions can be verified at
> - * pre_computed_values.
> - */
> - q = max_avg >> 5;
> - r = max_avg % 32;
> - max = (1 << q) * pre_computed_values[r];
> -
> - // min luminance: maxLum * (CV/255)^2 / 100
> - q = DIV_ROUND_CLOSEST(min_cll, 255);
> - min = max * DIV_ROUND_CLOSEST((q * q), 100);
> -
> - caps->aux_max_input_signal = max;
> - caps->aux_min_input_signal = min;
> + luminance_range = _base->display_info.luminance_range;
> + caps->aux_min_input_signal = luminance_range->min_luminance;
> + caps->aux_max_input_signal = luminance_range->max_luminance;
> }
>
> void amdgpu_dm_update_connector_after_detect(
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/6] drm/ttm: Add new callbacks to ttm res mgr
== Series Details ==
Series: series starting with [v4,1/6] drm/ttm: Add new callbacks to ttm res mgr
URL : https://patchwork.freedesktop.org/series/106961/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11966 -> Patchwork_106961v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/index.html
Participating hosts (41 -> 40)
--
Additional (4): bat-rpls-1 bat-dg2-10 bat-jsl-3 bat-dg2-8
Missing(5): fi-kbl-soraka fi-rkl-11600 bat-dg1-5 bat-dg2-9 bat-jsl-1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106961v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-10}: NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/bat-dg2-10/igt@gem_huc_c...@huc-copy.html
* igt@i915_pm_rpm@module-reload:
- {bat-dg2-10}: NOTRUN -> [DMESG-WARN][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/bat-dg2-10/igt@i915_pm_...@module-reload.html
* igt@i915_suspend@basic-s3-without-i915:
- {bat-dg2-8}:NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/bat-dg2-8/igt@i915_susp...@basic-s3-without-i915.html
Known issues
Here are the changes found in Patchwork_106961v1 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-kbl-8809g: [FAIL][4] -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-kbl-8809g/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/fi-kbl-8809g/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-8809g: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/fi-kbl-8809g/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_backlight@basic-brightness:
- fi-kbl-8809g: NOTRUN -> [SKIP][8] ([fdo#109271]) +26 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/fi-kbl-8809g/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][9] -> [DMESG-FAIL][10] ([i915#4494] /
[i915#4957])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][11] -> [DMESG-FAIL][12] ([i915#4528])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-kbl-8809g: NOTRUN -> [SKIP][13] ([fdo#109271] / [fdo#111827]) +8
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/fi-kbl-8809g/igt@kms_chamel...@dp-hpd-fast.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][14] ([i915#2582]) -> [PASS][15] +4 similar
issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@fb...@read.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/bat-rpls-2/igt@fb...@read.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][16] ([i915#2867]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}: [WARN][18] ([i915#5998]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@i915_pm_...@module-reload.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106961v1/bat-rpls-2/igt@i915_pm_...@module-reload.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [FAIL][20] ([i915#6298]) -> [PASS][21]
[20]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v4,1/6] drm/ttm: Add new callbacks to ttm res mgr
== Series Details == Series: series starting with [v4,1/6] drm/ttm: Add new callbacks to ttm res mgr URL : https://patchwork.freedesktop.org/series/106961/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 00/23] Initial Meteorlake Support
On Wed, 27 Jul 2022, Radhakrishna Sripada wrote: > The PCI Id's and platform definition are posted earlier. Please don't send patch series that aren't based on drm-tip or depend on other patch series. Even if you've sent the PCI ID stuff earlier, include all the dependencies in the series you post, to let the CI test this, if only to check that it doesn't regress older platforms. BR, Jani. > This series adds handful of early enablement patches including > support for display power wells, VBT and AUX Channel mapping, > PCH and gmbus support, dbus, mbus, sagv and memory bandwidth support. > > This series also add the support for a new way to read Graphics, > Media and Display versions. > > Anusha Srivatsa (2): > drm/i915/mtl: Add CDCLK Support > drm/i915/dmc: MTL DMC debugfs entries > > Clint Taylor (1): > drm/i915/mtl: Fix rawclk for Meteorlake PCH > > Imre Deak (3): > drm/i915/mtl: Add VBT port and AUX_CH mapping > drm/i915/mtl: Add display power wells > drm/i915/mtl: Add DP AUX support on TypeC ports > > José Roberto de Souza (2): > drm/i915: Parse and set stepping for platforms with GMD > drm/i915/display/mtl: Extend MBUS programming > > Madhumitha Tolakanahalli Pradeep (2): > drm/i915/dmc: Load DMC on MTL > drm/i915/mtl: Update CHICKEN_TRANS* register addresses > > Matt Roper (4): > drm/i915: Read graphics/media/display arch version from hw > drm/i915/mtl: MMIO range is now 4MB > drm/i915/mtl: Don't mask off CCS according to DSS fusing > drm/i915/mtl: Define engine context layouts > > Radhakrishna Sripada (9): > drm/i915/mtl: Add PCH support > drm/i915/mtl: Add gmbus and gpio support > drm/i915/mtl: Add support for MTL in Display Init sequences > drm/i915/mtl: memory latency data from LATENCY_LPX_LPY for WM > drm/i915/mtl: Obtain SAGV values from MMIO instead of GT pcode mailbox > drm/i915/mtl: Update memory bandwidth parameters > drm/i915/mtl: Update MBUS_DBOX credits > drm/i915/mtl: DBUF handling is same as adlp > drm/i915/mtl: Do not update GV point, mask value > > drivers/gpu/drm/i915/display/intel_bios.c | 14 +- > drivers/gpu/drm/i915/display/intel_bw.c | 87 - > drivers/gpu/drm/i915/display/intel_bw.h | 9 + > drivers/gpu/drm/i915/display/intel_cdclk.c| 351 -- > drivers/gpu/drm/i915/display/intel_ddi.c | 2 +- > drivers/gpu/drm/i915/display/intel_display.c | 7 +- > .../drm/i915/display/intel_display_power.c| 5 +- > .../i915/display/intel_display_power_map.c| 115 +- > .../i915/display/intel_display_power_well.c | 43 +++ > .../i915/display/intel_display_power_well.h | 4 + > drivers/gpu/drm/i915/display/intel_dmc.c | 19 +- > drivers/gpu/drm/i915/display/intel_dp_aux.c | 53 ++- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +- > drivers/gpu/drm/i915/display/intel_gmbus.c| 17 + > drivers/gpu/drm/i915/display/intel_gmbus.h| 1 + > drivers/gpu/drm/i915/display/intel_psr.c | 6 +- > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 2 + > drivers/gpu/drm/i915/gt/intel_lrc.c | 47 ++- > drivers/gpu/drm/i915/i915_driver.c| 85 - > drivers/gpu/drm/i915/i915_drv.h | 18 +- > drivers/gpu/drm/i915/i915_pci.c | 1 + > drivers/gpu/drm/i915/i915_reg.h | 91 - > drivers/gpu/drm/i915/intel_device_info.c | 32 +- > drivers/gpu/drm/i915/intel_device_info.h | 14 + > drivers/gpu/drm/i915/intel_dram.c | 41 +- > drivers/gpu/drm/i915/intel_pch.c | 9 +- > drivers/gpu/drm/i915/intel_pch.h | 4 + > drivers/gpu/drm/i915/intel_pm.c | 180 ++--- > drivers/gpu/drm/i915/intel_step.c | 60 +++ > drivers/gpu/drm/i915/intel_uncore.c | 11 +- > .../gpu/drm/i915/selftests/mock_gem_device.c | 1 + > 32 files changed, 1178 insertions(+), 155 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for Enabling Pipewriteback (rev3)
== Series Details ==
Series: Enabling Pipewriteback (rev3)
URL : https://patchwork.freedesktop.org/series/106902/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11966 -> Patchwork_106902v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/index.html
Participating hosts (41 -> 40)
--
Additional (3): bat-rpls-1 fi-tgl-dsi bat-jsl-3
Missing(4): fi-kbl-soraka fi-hsw-4770 fi-rkl-11600 bat-dg1-5
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106902v3:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {fi-tgl-dsi}: NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-tgl-dsi/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_106902v3 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-kbl-8809g: [FAIL][2] -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-kbl-8809g/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-kbl-8809g/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-kbl-8809g: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-kbl-8809g/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_backlight@basic-brightness:
- fi-kbl-8809g: NOTRUN -> [SKIP][6] ([fdo#109271]) +26 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-kbl-8809g/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][7] -> [INCOMPLETE][8] ([i915#2940])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][9] -> [DMESG-FAIL][10] ([i915#4494] /
[i915#4957])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@requests:
- fi-blb-e6850: [PASS][11] -> [DMESG-FAIL][12] ([i915#4528])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-blb-e6850/igt@i915_selftest@l...@requests.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-blb-e6850/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-pnv-d510:NOTRUN -> [SKIP][13] ([fdo#109271])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-pnv-d510/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-kbl-8809g: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-kbl-8809g/igt@kms_chamel...@dp-hpd-fast.html
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN -> [FAIL][15] ([fdo#109271] / [i915#4312])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-bsw-kefka/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][16] ([i915#2582]) -> [PASS][17] +4 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@fb...@read.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/bat-rpls-2/igt@fb...@read.html
* igt@i915_selftest@live@requests:
- fi-pnv-d510:[DMESG-FAIL][18] ([i915#4528]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-pnv-d510/igt@i915_selftest@l...@requests.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106902v3/fi-pnv-d510/igt@i915_selftest@l...@requests.html
* igt@kms_frontbuffer_tracking@basic:
- {bat-rpls-2}: [SKIP][20] ([i915#1849]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@kms_frontbuffer_track...@basic.html
[21]:
Re: [Intel-gfx] [PATCH v5 1/7] drm: Move and add a few utility macros into drm util header
Hi Jani, > >> It moves overflows_type utility macro into drm util header from i915_utils > >> header. The overflows_type can be used to catch the truncation between data > >> types. And it adds safe_conversion() macro which performs a type conversion > >> (cast) of an source value into a new variable, checking that the > >> destination is large enough to hold the source value. > >> And it adds exact_type and exactly_pgoff_t macro to catch type mis-match > >> while compiling. > >> > >> v3: Add is_type_unsigned() macro (Mauro) > >> Modify overflows_type() macro to consider signed data types (Mauro) > >> Fix the problem that safe_conversion() macro always returns true > >> v4: Fix kernel-doc markups > >> > >> Signed-off-by: Gwan-gyeong Mun > >> Cc: Thomas Hellström > >> Cc: Matthew Auld > >> Cc: Nirmoy Das > >> Cc: Jani Nikula > >> Reviewed-by: Mauro Carvalho Chehab > >> --- > >> drivers/gpu/drm/i915/i915_utils.h | 5 +- > >> include/drm/drm_util.h| 77 +++ > >> 2 files changed, 78 insertions(+), 4 deletions(-) > > > > Jani and Mauro suggested to have this macro in > > include/drm/drm_util.h. > > I can't recall suggesting such a thing. The macros in question have > nothing specifically to do with i915 *or* drm. They are generic, and > should be in generic kernel headers. > > We must stop piling up generic and generally useful stuff in our own > headers. Yes, I agree with you and I think there was already such discussion whether to move this into generic kernel headers or in drm header. Gwan-gyeong, any thoughts or further plans to move this to a different place? It's been already three people (and I'm including myself here) recommending to have this in a different place. Andi > I thought I've been clear about this all along. Thanks, Jani! Andi
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enabling Pipewriteback (rev3)
== Series Details == Series: Enabling Pipewriteback (rev3) URL : https://patchwork.freedesktop.org/series/106902/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enabling Pipewriteback (rev3)
== Series Details ==
Series: Enabling Pipewriteback (rev3)
URL : https://patchwork.freedesktop.org/series/106902/
State : warning
== Summary ==
Error: dim checkpatch failed
10ad01a5c747 drm/i915: Define WD trancoder for i915
-:68: CHECK:LINE_SPACING: Please don't use multiple blank lines
#68: FILE: drivers/gpu/drm/i915/i915_reg.h:3840:
+
+
total: 0 errors, 0 warnings, 1 checks, 194 lines checked
d9a8b33b6197 drm/i915: Enabling WD Transcoder
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
-:115: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#115: FILE: drivers/gpu/drm/i915/display/intel_display.c:1560:
+static void intel_queue_writeback_job(struct intel_atomic_state *state,
+ struct intel_crtc *intel_crtc, struct intel_crtc_state
*crtc_state)
-:133: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#133: FILE: drivers/gpu/drm/i915/display/intel_display.c:1578:
+static void intel_find_writeback_connector(struct intel_atomic_state *state,
+ struct intel_crtc *intel_crtc, struct intel_crtc_state
*crtc_state)
-:246: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in
parentheses
#246: FILE: drivers/gpu/drm/i915/display/intel_display.h:484:
+#define for_each_connector_on_encoder(dev, __encoder, drm_connector) \
+ list_for_each_entry((drm_connector),
&(dev)->mode_config.connector_list, head) \
+ for_each_if(drm_connector->connector_type !=
DRM_MODE_CONNECTOR_WRITEBACK &&\
+ (to_intel_connector(drm_connector))->base.encoder ==
(__encoder))
-:246: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'drm_connector' - possible
side-effects?
#246: FILE: drivers/gpu/drm/i915/display/intel_display.h:484:
+#define for_each_connector_on_encoder(dev, __encoder, drm_connector) \
+ list_for_each_entry((drm_connector),
&(dev)->mode_config.connector_list, head) \
+ for_each_if(drm_connector->connector_type !=
DRM_MODE_CONNECTOR_WRITEBACK &&\
+ (to_intel_connector(drm_connector))->base.encoder ==
(__encoder))
-:350: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#350: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:2097:
+
+ }
-:494: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#494: FILE: drivers/gpu/drm/i915/display/intel_modeset_setup.c:573:
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s] hw state readout:
%s\n",
-:501: CHECK:LINE_SPACING: Please don't use multiple blank lines
#501: FILE: drivers/gpu/drm/i915/display/intel_modeset_setup.c:580:
+
+
-:565: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#565:
new file mode 100644
-:586: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#586: FILE: drivers/gpu/drm/i915/display/intel_wb_connector.h:17:
+void intel_wb_connector_attach_encoder(struct intel_wb_connector *connector,
+ struct intel_encoder *encoder);
-:650: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#650: FILE: drivers/gpu/drm/i915/display/intel_wd.c:55:
+ job = list_first_entry_or_null(_conn->job_queue,
+ struct drm_writeback_job,
-:653: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!job"
#653: FILE: drivers/gpu/drm/i915/display/intel_wd.c:58:
+ if (job == NULL) {
-:692: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#692: FILE: drivers/gpu/drm/i915/display/intel_wd.c:97:
+ DRM_ERROR("unsupported pixel format %x!\n",
+ pixel_format);
-:712: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#712: FILE: drivers/gpu/drm/i915/display/intel_wd.c:117:
+static u32 intel_wd_get_stride(const struct intel_crtc_state *crtc_state,
+ int format)
-:738: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#738: FILE: drivers/gpu/drm/i915/display/intel_wd.c:143:
+static int intel_wd_pin_fb(struct intel_wd *intel_wd,
+ struct drm_framebuffer *fb)
-:746: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#746: FILE: drivers/gpu/drm/i915/display/intel_wd.c:151:
+ vma = intel_pin_and_fence_fb_obj(fb, false, , false,
+ _wd->flags);
-:756: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#756: FILE: drivers/gpu/drm/i915/display/intel_wd.c:161:
+static void
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Only disable PMU on stop if not already closed
On 04/08/2022 00:03, Stuart Summers wrote:
There can be a race in the PMU process teardown vs the
time when the driver is unbound in which the user attempts
to stop the PMU process, but the actual data structure
in the kernel is no longer available. Avoid this use-after-free
by skipping the PMU disable in i915_pmu_event_stop() when
the PMU has already been closed/unregistered by the driver.
Fixes: b00bccb3f0bb ("drm/i915/pmu: Handle PCI unbind")
Suggested-by: Tvrtko Ursulin
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_pmu.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_pmu.c b/drivers/gpu/drm/i915/i915_pmu.c
index 958b37123bf12..0d02f338118e4 100644
--- a/drivers/gpu/drm/i915/i915_pmu.c
+++ b/drivers/gpu/drm/i915/i915_pmu.c
@@ -760,9 +760,17 @@ static void i915_pmu_event_start(struct perf_event *event,
int flags)
static void i915_pmu_event_stop(struct perf_event *event, int flags)
{
+ struct drm_i915_private *i915 =
+ container_of(event->pmu, typeof(*i915), pmu.base);
+ struct i915_pmu *pmu = >pmu;
+
+ if (pmu->closed)
+ goto out;
+
if (flags & PERF_EF_UPDATE)
i915_pmu_event_read(event);
i915_pmu_disable(event);
+out:
event->hw.state = PERF_HES_STOPPED;
}
LGTM, although I am not sure who feels comfortable to r-b since we all
kind of suggested the same fix. :)
FWIW:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix NPD in PMU during driver teardown
On 04/08/2022 00:03, Stuart Summers wrote:
In the driver teardown, we are unregistering the gt prior
to unregistering the PMU. This means there is a small window
of time in which the application can request metrics from the
PMU, some of which are calling into the uapi engines list,
while the engines are not available. In this case we can
see null pointer dereferences.
Fix this ordering in both the driver load and unload sequences.
v1: Actually address the driver load/unload ordering issue
v2: Remove the NULL checks since they shouldn't be necessary
now with the proper ordering
Fixes: 42014f69bb235 ("drm/i915: Hook up GT power management")
What happened in this commit to break it?
Signed-off-by: Stuart Summers
---
drivers/gpu/drm/i915/i915_driver.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76965a..ee4dcb85d2060 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -717,7 +717,6 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
struct drm_device *dev = _priv->drm;
i915_gem_driver_register(dev_priv);
- i915_pmu_register(dev_priv);
intel_vgpu_register(dev_priv);
@@ -731,11 +730,12 @@ static void i915_driver_register(struct drm_i915_private *dev_priv)
i915_debugfs_register(dev_priv);
i915_setup_sysfs(dev_priv);
+ intel_gt_driver_register(to_gt(dev_priv));
+
/* Depends on sysfs having been initialized */
+ i915_pmu_register(dev_priv);
i915_perf_register(dev_priv);
- intel_gt_driver_register(to_gt(dev_priv));
-
There was a bit of a time distance since we originally discussed this so
things kind of evaporated from my head. Or at least it feels like that.
Today when I look at the code I don't understand why is this shuffle
relevant.
The sysfs comment does not really apply to pmu, but also if I look into
intel_gt_driver_(un)register I did not spot what is the relevant part
which interacts with the PMU.
On register it is engine list first then PMU.
On unregister it is PMU first, then engine list:
i915_driver_remove
i915_driver_unregister
i915_pmu_unregister
i915_gem_driver_remove
clears uabi engines list
Help please? :)
Regards,
Tvrtko
intel_display_driver_register(dev_priv);
intel_power_domains_enable(dev_priv);
@@ -762,11 +762,12 @@ static void i915_driver_unregister(struct
drm_i915_private *dev_priv)
intel_display_driver_unregister(dev_priv);
- intel_gt_driver_unregister(to_gt(dev_priv));
-
i915_perf_unregister(dev_priv);
+ /* GT should be available until PMU is gone */
i915_pmu_unregister(dev_priv);
+ intel_gt_driver_unregister(to_gt(dev_priv));
+
i915_teardown_sysfs(dev_priv);
drm_dev_unplug(_priv->drm);
[Intel-gfx] ✓ Fi.CI.BAT: success for Move TLB invalidation code for its own file and document it (rev4)
== Series Details ==
Series: Move TLB invalidation code for its own file and document it (rev4)
URL : https://patchwork.freedesktop.org/series/106805/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11966 -> Patchwork_106805v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/index.html
Participating hosts (41 -> 39)
--
Additional (2): bat-rpls-1 bat-dg2-10
Missing(4): fi-kbl-soraka fi-rkl-11600 bat-jsl-1 bat-dg1-5
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_106805v4:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {bat-dg2-10}: NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/bat-dg2-10/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_106805v4 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-kbl-8809g: [FAIL][2] -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-kbl-8809g/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/fi-kbl-8809g/boot.html
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-kbl-8809g: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/fi-kbl-8809g/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-8809g: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/fi-kbl-8809g/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@gt_pm:
- bat-adlp-4: [PASS][6] -> [DMESG-FAIL][7] ([i915#3987])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-adlp-4/igt@i915_selftest@live@gt_pm.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/bat-adlp-4/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][8] -> [INCOMPLETE][9] ([i915#4785])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
- fi-hsw-g3258: [PASS][10] -> [INCOMPLETE][11] ([i915#3303] /
[i915#4785])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: [PASS][12] -> [DMESG-FAIL][13] ([i915#4494] /
[i915#4957])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-8809g: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/fi-kbl-8809g/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-kbl-8809g: NOTRUN -> [SKIP][15] ([fdo#109271]) +26 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/fi-kbl-8809g/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][16] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/fi-hsw-4770/igt@run...@aborted.html
- fi-hsw-g3258: NOTRUN -> [FAIL][17] ([fdo#109271] / [i915#4312] /
[i915#6246])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/fi-hsw-g3258/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][18] ([i915#2582]) -> [PASS][19] +4 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rpls-2/igt@fb...@read.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/bat-rpls-2/igt@fb...@read.html
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rplp-1}: [DMESG-WARN][20] ([i915#2867]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106805v4/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
*
[Intel-gfx] [PATCH v3 2/2] drm/i915: Enabling WD Transcoder
Adding support for writeback transcoder to start capturing frames using
interrupt mechanism
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_acpi.c | 1 +
drivers/gpu/drm/i915/display/intel_crtc.c | 3 +
.../drm/i915/display/intel_crtc_state_dump.c | 1 +
drivers/gpu/drm/i915/display/intel_ddi.c | 6 +
drivers/gpu/drm/i915/display/intel_display.c | 63 +-
drivers/gpu/drm/i915/display/intel_display.h | 15 +-
.../drm/i915/display/intel_display_debugfs.c | 14 +-
.../drm/i915/display/intel_display_types.h| 29 +
drivers/gpu/drm/i915/display/intel_dpll.c | 6 +
.../drm/i915/display/intel_modeset_setup.c| 67 +-
.../drm/i915/display/intel_modeset_verify.c | 18 +-
drivers/gpu/drm/i915/display/intel_opregion.c | 3 +
.../gpu/drm/i915/display/intel_wb_connector.h | 20 +
drivers/gpu/drm/i915/display/intel_wd.c | 733 ++
drivers/gpu/drm/i915/display/intel_wd.h | 76 ++
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_irq.c | 8 +-
drivers/gpu/drm/i915/i915_pci.c | 7 +-
19 files changed, 1046 insertions(+), 27 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c
create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..ec63ed16c250 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -302,6 +302,7 @@ i915-y += \
display/intel_tv.o \
display/intel_vdsc.o \
display/intel_vrr.o \
+ display/intel_wd.o \
display/vlv_dsi.o \
display/vlv_dsi_pll.o
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
b/drivers/gpu/drm/i915/display/intel_acpi.c
index e78430001f07..ae08db164f73 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -247,6 +247,7 @@ static u32 acpi_display_type(struct intel_connector
*connector)
case DRM_MODE_CONNECTOR_LVDS:
case DRM_MODE_CONNECTOR_eDP:
case DRM_MODE_CONNECTOR_DSI:
+ case DRM_MODE_CONNECTOR_WRITEBACK:
display_type = ACPI_DISPLAY_TYPE_INTERNAL_DIGITAL;
break;
case DRM_MODE_CONNECTOR_Unknown:
diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
b/drivers/gpu/drm/i915/display/intel_crtc.c
index 4442aa355f86..f9fa612ac991 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc.c
@@ -512,6 +512,9 @@ void intel_pipe_update_start(struct intel_crtc_state
*new_crtc_state)
if (min <= 0 || max <= 0)
goto irq_disable;
+ if (new_crtc_state->output_types & BIT(INTEL_OUTPUT_WD))
+ goto irq_disable;
+
if (drm_WARN_ON(_priv->drm, drm_crtc_vblank_get(>base)))
goto irq_disable;
diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
index e9212f69c360..f49630d95d6a 100644
--- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
+++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c
@@ -71,6 +71,7 @@ static const char * const output_type_str[] = {
OUTPUT_TYPE(DSI),
OUTPUT_TYPE(DDI),
OUTPUT_TYPE(DP_MST),
+ OUTPUT_TYPE(WD)
};
#undef OUTPUT_TYPE
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index a4c8493f3ce7..1360406ca531 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -1974,6 +1974,12 @@ void intel_ddi_sanitize_encoder_pll_mapping(struct
intel_encoder *encoder)
*/
if (encoder->type == INTEL_OUTPUT_DP_MST)
return;
+ /*
+* WD transcoder is a virtual encoder hence sanization
+* is not required for it
+*/
+ if (encoder->type == INTEL_OUTPUT_WD)
+ return;
if (!encoder->base.crtc && intel_encoder_is_dp(encoder)) {
u8 pipe_mask;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a0f84cbe974f..90b41b49e1d7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -116,6 +116,7 @@
#include "intel_sprite.h"
#include "intel_tc.h"
#include "intel_vga.h"
+#include "intel_wd.h"
#include "i9xx_plane.h"
#include "skl_scaler.h"
#include "skl_universal_plane.h"
@@ -1507,6 +1508,9 @@ static void intel_encoders_update_prepare(struct
intel_atomic_state *state)
struct intel_encoder *encoder;
struct intel_crtc *crtc;
+ if (connector->connector_type == DRM_MODE_CONNECTOR_WRITEBACK)
+ continue;
+
[Intel-gfx] [PATCH v3 1/2] drm/i915: Define WD trancoder for i915
Adding WD Types, WD transcoder to enum list and WD Transcoder offsets.
Adding i915 register definitions related to WD transcoder
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display.h | 6 +
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/i915_reg.h | 139 ++
3 files changed, 146 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index fa5371036239..4e9f22954a41 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -120,6 +120,8 @@ enum transcoder {
TRANSCODER_DSI_1,
TRANSCODER_DSI_A = TRANSCODER_DSI_0,/* legacy DSI */
TRANSCODER_DSI_C = TRANSCODER_DSI_1,/* legacy DSI */
+ TRANSCODER_WD_0,
+ TRANSCODER_WD_1,
I915_MAX_TRANSCODERS
};
@@ -141,6 +143,10 @@ static inline const char *transcoder_name(enum transcoder
transcoder)
return "DSI A";
case TRANSCODER_DSI_C:
return "DSI C";
+ case TRANSCODER_WD_0:
+ return "WD 0";
+ case TRANSCODER_WD_1:
+ return "WD 1";
default:
return "";
}
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 0da9b208d56e..0e94bd430bcb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -79,6 +79,7 @@ enum intel_output_type {
INTEL_OUTPUT_DSI = 9,
INTEL_OUTPUT_DDI = 10,
INTEL_OUTPUT_DP_MST = 11,
+ INTEL_OUTPUT_WD = 12,
};
enum hdmi_force_audio {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3168d7007e10..273f5c7cbd89 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2052,6 +2052,8 @@
#define TRANSCODER_EDP_OFFSET 0x6f000
#define TRANSCODER_DSI0_OFFSET 0x6b000
#define TRANSCODER_DSI1_OFFSET 0x6b800
+#define TRANSCODER_WD0_OFFSET 0x6e000
+#define TRANSCODER_WD1_OFFSET 0x6e800
#define HTOTAL(trans) _MMIO_TRANS2(trans, _HTOTAL_A)
#define HBLANK(trans) _MMIO_TRANS2(trans, _HBLANK_A)
@@ -3824,6 +3826,11 @@
#define PIPE_DSI0_OFFSET 0x7b000
#define PIPE_DSI1_OFFSET 0x7b800
+/* WD 0 and 1 */
+#define PIPE_WD0_OFFSET0x7e000
+#define PIPE_WD1_OFFSET0x7d000
+
+
#define PIPECONF(pipe) _MMIO_PIPE2(pipe, _PIPEACONF)
#define PIPEDSL(pipe) _MMIO_PIPE2(pipe, _PIPEADSL)
#define PIPEFRAME(pipe)_MMIO_PIPE2(pipe, _PIPEAFRAMEHIGH)
@@ -4488,6 +4495,10 @@
#define _PIPEDSI0CONF 0x7b008
#define _PIPEDSI1CONF 0x7b808
+/* WD 0 and 1 */
+#define _PIPEWD0CONF 0x7e008
+#define _PIPEWD1CONF 0x7d008
+
/* Sprite A control */
#define _DVSACNTR 0x72180
#define DVS_ENABLE REG_BIT(31)
@@ -5713,6 +5724,7 @@
#define GEN8_DE_MISC_IER _MMIO(0x4446c)
#define GEN8_DE_MISC_GSE (1 << 27)
#define GEN8_DE_EDP_PSR (1 << 19)
+#define GEN8_DE_MISC_WD0 (1 << 23)
#define GEN8_PCU_ISR _MMIO(0x444e0)
#define GEN8_PCU_IMR _MMIO(0x444e4)
@@ -8707,6 +8719,133 @@ enum skl_power_gate {
#define DSB_ENABLE (1 << 31)
#define DSB_STATUS (1 << 0)
+#define TGL_ROOT_DEVICE_ID 0x9A00
+#define TGL_ROOT_DEVICE_MASK 0xFF00
+#define TGL_ROOT_DEVICE_SKU_MASK 0xF
+#define TGL_ROOT_DEVICE_SKU_ULX0x2
+#define TGL_ROOT_DEVICE_SKU_ULT0x4
+
+/* Gen12 WD */
+#define _MMIO_WD(tc, wd0, wd1) _MMIO_TRANS((tc) - TRANSCODER_WD_0, \
+ wd0, wd1)
+
+#define WD_TRANS_ENABLE(1 << 31)
+#define WD_TRANS_DISABLE 0
+#define WD_TRANS_ACTIVE(1 << 30)
+
+/* WD transcoder control */
+#define _WD_TRANS_FUNC_CTL_0 0x6e400
+#define _WD_TRANS_FUNC_CTL_1 0x6ec00
+#define WD_TRANS_FUNC_CTL(tc) _MMIO_WD(tc,\
+ _WD_TRANS_FUNC_CTL_0,\
+ _WD_TRANS_FUNC_CTL_1)
+
+#define TRANS_WD_FUNC_ENABLE (1 << 31)
+#define WD_TRIGGERED_CAP_MODE_ENABLE (1 << 30)
+#define START_TRIGGER_FRAME(1 << 29)
+#define STOP_TRIGGER_FRAME (1 << 28)
+#define WD_CTL_POINTER_ETEH(0 << 18)
+#define WD_CTL_POINTER_ETDH(1 << 18)
+#define WD_CTL_POINTER_DTDH(2 << 18)
+#define WD_INPUT_SELECT_MASK (7 << 12)
+#define WD_INPUT_PIPE_A(0 << 12)
+#define WD_INPUT_PIPE_B(5 << 12)
+#define WD_INPUT_PIPE_C(6 << 12)
+#define WD_INPUT_PIPE_D(7 << 12)
+
+#define WD_PIX_FMT_MASK
[Intel-gfx] [PATCH v3 0/2] Enabling Pipewriteback
A patch series was floated in the drm mailing list which aimed to change the drm_connector and drm_encoder fields to pointer in the drm_connector_writeback structure, this received a huge pushback from the community but since i915 expects each connector present in the drm_device list to be a intel_connector but drm_writeback framework makes us have a connector which cannot be embedded in an intel_connector structure. [1] https://patchwork.kernel.org/project/dri-devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ [2] https://patchwork.kernel.org/project/dri-devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ Since no one had an issue with encoder field being changed into a pointer it was decided to break the connector and encoder pointer changes into two different series.The encoder field changes is currently being worked upon by Abhinav Kumar and the changes have been merged. [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 Going forward we use a drm_connector which is not embedded in intel_connector. We also create a intel_encoder to avoid changes to many iterators but no intel_connector. We also changed all iterators that go through connectors and add a check to only cast connectors which are not writeback connectors. v2--- changes to fix build errors. v3-- changes to fix BAT errors. Suraj Kandpal (2): drm/i915: Define WD trancoder for i915 drm/i915: Enabling WD Transcoder drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/display/intel_acpi.c | 1 + drivers/gpu/drm/i915/display/intel_crtc.c | 3 + .../drm/i915/display/intel_crtc_state_dump.c | 1 + drivers/gpu/drm/i915/display/intel_ddi.c | 6 + drivers/gpu/drm/i915/display/intel_display.c | 63 +- drivers/gpu/drm/i915/display/intel_display.h | 21 +- .../drm/i915/display/intel_display_debugfs.c | 14 +- .../drm/i915/display/intel_display_types.h| 30 + drivers/gpu/drm/i915/display/intel_dpll.c | 6 + .../drm/i915/display/intel_modeset_setup.c| 67 +- .../drm/i915/display/intel_modeset_verify.c | 18 +- drivers/gpu/drm/i915/display/intel_opregion.c | 3 + .../gpu/drm/i915/display/intel_wb_connector.h | 20 + drivers/gpu/drm/i915/display/intel_wd.c | 733 ++ drivers/gpu/drm/i915/display/intel_wd.h | 76 ++ drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_irq.c | 8 +- drivers/gpu/drm/i915/i915_pci.c | 7 +- drivers/gpu/drm/i915/i915_reg.h | 139 20 files changed, 1192 insertions(+), 27 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h -- 2.37.0
Re: [Intel-gfx] [PATCH v3 1/3] drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()
On 04/08/2022 08:37, Mauro Carvalho Chehab wrote:
WRITE_ONCE() should happen at the original var, not on a local
copy of it.
Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB invalidations")
Cc: stable I think, since the above one was. So both hit 5.21 (or 6.1)
together.
Regards,
Tvrtko
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 0/3] at:
https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 6 +++---
drivers/gpu/drm/i915/i915_vma.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 2da6c82a8bd2..6ee8d1127016 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -211,7 +211,7 @@ void ppgtt_unbind_vma(struct i915_address_space *vm,
vm->clear_range(vm, vma_res->start, vma_res->vma_size);
if (vma_res->tlb)
- vma_invalidate_tlb(vm, *vma_res->tlb);
+ vma_invalidate_tlb(vm, vma_res->tlb);
}
static unsigned long pd_count(u64 size, int shift)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 84a9ccbc5fc5..260371716490 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1308,7 +1308,7 @@ I915_SELFTEST_EXPORT int i915_vma_get_pages(struct
i915_vma *vma)
return err;
}
-void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb)
+void vma_invalidate_tlb(struct i915_address_space *vm, u32 *tlb)
{
/*
* Before we release the pages that were bound by this vma, we
@@ -1318,7 +1318,7 @@ void vma_invalidate_tlb(struct i915_address_space *vm,
u32 tlb)
* the most recent TLB invalidation seqno, and if we have not yet
* flushed the TLBs upon release, perform a full invalidation.
*/
- WRITE_ONCE(tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
+ WRITE_ONCE(*tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
}
static void __vma_put_pages(struct i915_vma *vma, unsigned int count)
@@ -1971,7 +1971,7 @@ struct dma_fence *__i915_vma_evict(struct i915_vma *vma,
bool async)
dma_fence_put(unbind_fence);
unbind_fence = NULL;
}
- vma_invalidate_tlb(vma->vm, vma->obj->mm.tlb);
+ vma_invalidate_tlb(vma->vm, >obj->mm.tlb);
}
/*
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 5048eed536da..33a58f605d75 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -213,7 +213,7 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
u64 size, u64 alignment, u64 flags);
void __i915_vma_set_map_and_fenceable(struct i915_vma *vma);
void i915_vma_revoke_mmap(struct i915_vma *vma);
-void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb);
+void vma_invalidate_tlb(struct i915_address_space *vm, u32 *tlb);
struct dma_fence *__i915_vma_evict(struct i915_vma *vma, bool async);
int __i915_vma_unbind(struct i915_vma *vma);
int __must_check i915_vma_unbind(struct i915_vma *vma);
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Move TLB invalidation code for its own file and document it (rev4)
== Series Details == Series: Move TLB invalidation code for its own file and document it (rev4) URL : https://patchwork.freedesktop.org/series/106805/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Move TLB invalidation code for its own file and document it (rev4)
== Series Details ==
Series: Move TLB invalidation code for its own file and document it (rev4)
URL : https://patchwork.freedesktop.org/series/106805/
State : warning
== Summary ==
Error: dim checkpatch failed
c884d515384d drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()
e78e81b032d5 drm/i915/gt: Move TLB invalidation to its own file
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 6, in
from ply import lex, yacc
ModuleNotFoundError: No module named 'ply'
-:281: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#281:
new file mode 100644
total: 0 errors, 1 warnings, 0 checks, 294 lines checked
03f39a09e961 drm/i915/gt: document TLB cache invalidation functions
-:103: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#103: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:31:
+ * ^Iwith_intel_gt_pm_if_awake(gt, wakeref) {$
-:104: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#104: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:32:
+ * ^I^Imutex_lock(>tlb.invalidate_lock);$
-:105: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#105: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:33:
+ * ^I^Iif (tlb_seqno_passed(gt, seqno))$
-:106: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#106: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:34:
+ * ^I^I^I^Igoto unlock;$
-:108: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#108: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:36:
+ * ^I^I// Some code to do TLB invalidation$
-:111: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#111: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:39:
+ * ^I^Iwrite_seqcount_invalidate(>tlb.seqno); // increment seqno$
-:112: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#112: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:40:
+ * ^I^Imutex_lock(>tlb.invalidate_lock);$
-:118: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#118: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:46:
+ * ^Iobj1$
-:119: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#119: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:47:
+ * ^Iobj2$
-:120: WARNING:SPACE_BEFORE_TAB: please, no space before tabs
#120: FILE: drivers/gpu/drm/i915/gt/intel_tlb.h:48:
+ * ^Iobj3$
total: 0 errors, 10 warnings, 0 checks, 171 lines checked
Re: [Intel-gfx] [PATCH 4/8] drm/i915: sanitize dc state in rpm resume
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Thursday, August 4, 2022 2:03 AM
> To: Tangudu, Tilak ; Srivatsa, Anusha
> ; Deak, Imre
> Cc: Ewins, Jon ; Belgaumkar, Vinay
> ; Roper, Matthew D
> ; Wilson, Chris P ;
> Nikula, Jani ; Gupta, saurabhg
> ; Gupta, Anshuman
> ; Nilawar, Badal ;
> Deak, Imre ; Iddamsetty, Aravind
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 4/8] drm/i915: sanitize dc state in rpm resume
>
> On Thu, Jul 21, 2022 at 03:29:51PM +0530, tilak.tang...@intel.com wrote:
> > From: Tilak Tangudu
> >
> > During runtime resume the display init sequence is called via
> > intel_display_power_resume() -> icl_display_core_init() which should
> > restore the display HW state. For restoring the DC9 enabled state in
> > DC_STATE_EN, gen9_sanitize_dc_state() should be called on the runtime
> > resume path too to avoid the
> >
> > [ 513.818190] i915 :03:00.0: [drm] *ERROR DC state mismatch (0x8
> > -> 0x0)*
> >
> > Signed-off-by: Tilak Tangudu
> Cc: Anusha Srivatsa
> Cc: Imre Deak
This is suggested by Imre in the JIRA,
In next patches I will add the below
Suggested-by: Imre Deak
>
> > ---
> > drivers/gpu/drm/i915/display/intel_display_power.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> > b/drivers/gpu/drm/i915/display/intel_display_power.c
> > index 589af257edeb..799f84d3eed6 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> > @@ -2229,6 +2229,7 @@ void intel_display_power_suspend(struct
> > drm_i915_private *i915) void intel_display_power_resume(struct
> > drm_i915_private *i915) {
> > if (DISPLAY_VER(i915) >= 11) {
> > + gen9_sanitize_dc_state(i915);
> > bxt_disable_dc9(i915);
> > icl_display_core_init(i915, true);
> > if (intel_dmc_has_payload(i915)) {
> > --
> > 2.25.1
> >
[Intel-gfx] [PATCH v3 1/3] drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb()
WRITE_ONCE() should happen at the original var, not on a local
copy of it.
Fixes: 5d36acb7198b ("drm/i915/gt: Batch TLB invalidations")
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 0/3] at:
https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/
drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 6 +++---
drivers/gpu/drm/i915/i915_vma.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 2da6c82a8bd2..6ee8d1127016 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -211,7 +211,7 @@ void ppgtt_unbind_vma(struct i915_address_space *vm,
vm->clear_range(vm, vma_res->start, vma_res->vma_size);
if (vma_res->tlb)
- vma_invalidate_tlb(vm, *vma_res->tlb);
+ vma_invalidate_tlb(vm, vma_res->tlb);
}
static unsigned long pd_count(u64 size, int shift)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 84a9ccbc5fc5..260371716490 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1308,7 +1308,7 @@ I915_SELFTEST_EXPORT int i915_vma_get_pages(struct
i915_vma *vma)
return err;
}
-void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb)
+void vma_invalidate_tlb(struct i915_address_space *vm, u32 *tlb)
{
/*
* Before we release the pages that were bound by this vma, we
@@ -1318,7 +1318,7 @@ void vma_invalidate_tlb(struct i915_address_space *vm,
u32 tlb)
* the most recent TLB invalidation seqno, and if we have not yet
* flushed the TLBs upon release, perform a full invalidation.
*/
- WRITE_ONCE(tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
+ WRITE_ONCE(*tlb, intel_gt_next_invalidate_tlb_full(vm->gt));
}
static void __vma_put_pages(struct i915_vma *vma, unsigned int count)
@@ -1971,7 +1971,7 @@ struct dma_fence *__i915_vma_evict(struct i915_vma *vma,
bool async)
dma_fence_put(unbind_fence);
unbind_fence = NULL;
}
- vma_invalidate_tlb(vma->vm, vma->obj->mm.tlb);
+ vma_invalidate_tlb(vma->vm, >obj->mm.tlb);
}
/*
diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h
index 5048eed536da..33a58f605d75 100644
--- a/drivers/gpu/drm/i915/i915_vma.h
+++ b/drivers/gpu/drm/i915/i915_vma.h
@@ -213,7 +213,7 @@ bool i915_vma_misplaced(const struct i915_vma *vma,
u64 size, u64 alignment, u64 flags);
void __i915_vma_set_map_and_fenceable(struct i915_vma *vma);
void i915_vma_revoke_mmap(struct i915_vma *vma);
-void vma_invalidate_tlb(struct i915_address_space *vm, u32 tlb);
+void vma_invalidate_tlb(struct i915_address_space *vm, u32 *tlb);
struct dma_fence *__i915_vma_evict(struct i915_vma *vma, bool async);
int __i915_vma_unbind(struct i915_vma *vma);
int __must_check i915_vma_unbind(struct i915_vma *vma);
--
2.37.1
[Intel-gfx] [PATCH v3 3/3] drm/i915/gt: document TLB cache invalidation functions
Add a description for the TLB cache invalidation algorithm and for
the related kAPI functions.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 0/3] at:
https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/
Documentation/gpu/i915.rst | 7 ++
drivers/gpu/drm/i915/gt/intel_tlb.c | 25
drivers/gpu/drm/i915/gt/intel_tlb.h | 99 +
3 files changed, 131 insertions(+)
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 4e59db1cfb00..46911fdd79e8 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -58,6 +58,13 @@ Intel GVT-g Host Support(vGPU device model)
.. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
:internal:
+TLB cache invalidation
+--
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.h
+
+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.c
+
Workarounds
---
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index af8cae979489..16b918ffe824 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
}
+/**
+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
+ * @gt: GT structure
+ * @seqno: sequence number
+ *
+ * Do a full TLB cache invalidation if the @seqno is bigger than the last
+ * full TLB cache invalidation.
+ *
+ * Note:
+ * The TLB cache invalidation logic depends on GEN-specific registers.
+ * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
+ */
void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
{
intel_wakeref_t wakeref;
@@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt,
u32 seqno)
}
}
+/**
+ * intel_gt_init_tlb - initialize TLB-specific vars
+ * @gt: GT structure
+ *
+ * TLB cache invalidation logic internally uses some resources that require
+ * initialization. Should be called before doing any TLB cache invalidation.
+ */
void intel_gt_init_tlb(struct intel_gt *gt)
{
mutex_init(>tlb.invalidate_lock);
seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
}
+/**
+ * intel_gt_fini_tlb - free TLB-specific vars
+ * @gt: GT structure
+ *
+ * Frees any resources needed by TLB cache invalidation logic.
+ */
void intel_gt_fini_tlb(struct intel_gt *gt)
{
mutex_destroy(>tlb.invalidate_lock);
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h
b/drivers/gpu/drm/i915/gt/intel_tlb.h
index 46ce25bf5afe..2838c051f872 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.h
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
@@ -11,16 +11,115 @@
#include "intel_gt_types.h"
+/**
+ * DOC: TLB cache invalidation logic
+ *
+ * The way the current algorithm works is that a struct drm_i915_gem_object can
+ * be created on any order. At unbind/evict time, the object is warranted that
+ * it won't be used anymore. So, a sequence number provided by
+ * intel_gt_next_invalidate_tlb_full() is stored on it. This can happen either
+ * at __vma_put_pages() - for VMA sync unbind, or at ppgtt_unbind_vma() - for
+ * VMA async VMA bind.
+ *
+ * At __i915_gem_object_unset_pages(), intel_gt_invalidate_tlb_full() is
called,
+ * where it checks if the sequence number of the object was already invalidated
+ * or not. If not, it flushes the TLB and increments the sequence number::
+ *
+ * void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
+ * {
+ * ...
+ * with_intel_gt_pm_if_awake(gt, wakeref) {
+ * mutex_lock(>tlb.invalidate_lock);
+ * if (tlb_seqno_passed(gt, seqno))
+ * goto unlock;
+ *
+ * // Some code to do TLB invalidation
+ * ...
+ *
+ * write_seqcount_invalidate(>tlb.seqno); // increment seqno
+ * mutex_lock(>tlb.invalidate_lock);
+ * }
+ *
+ * So, let's say the current seqno is 2 and 3 new objects were created,
+ * on this order::
+ *
+ * obj1
+ * obj2
+ * obj3
+ *
+ * They can be unbind/evict on a different order. At unbind/evict time,
+ * the mm.tlb will be stamped with the sequence number, using the number
+ * from the last TLB flush, plus 1.
+ *
+ * Different threads may be used on unbind/evict and/or unset pages.
+ * As the logic at intel_gt_invalidate_tlb_full() is protected by a mutex,
+ * for simplicity, let's consider just two threads:
+ *
+ *
+---+-+-+
+ * | sequence number | Thread 0| Thread 1
+
+ *
+===+=+=+
+ * | seqno=2 | |
|
+ * |
[Intel-gfx] [PATCH v3 2/3] drm/i915/gt: Move TLB invalidation to its own file
From: Chris Wilson
Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.
It also:
- Renames intel_gt_invalidate_tlb() to intel_gt_invalidate_tlb_full()
- Add intel_gt_init_tlb() and intel_gt_fini_tlb() abstracts.
Signed-off-by: Chris Wilson
Reviewed-by: Niranjana Vishwanathapura
Reviewed-by: Andi Shyti
Cc: Fei Yang
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 0/3] at:
https://lore.kernel.org/all/cover.1659598090.git.mche...@kernel.org/
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c| 168 +---
drivers/gpu/drm/i915/gt/intel_gt.h| 12 --
drivers/gpu/drm/i915/gt/intel_tlb.c | 183 ++
drivers/gpu/drm/i915/gt/intel_tlb.h | 29
drivers/gpu/drm/i915/i915_vma.c | 1 +
7 files changed, 219 insertions(+), 179 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..d3df9832d1f7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -126,6 +126,7 @@ gt-y += \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
+ gt/intel_tlb.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 8357dbdcab5c..1cd76cc5d9f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -7,7 +7,7 @@
#include
#include "gt/intel_gt.h"
-#include "gt/intel_gt_pm.h"
+#include "gt/intel_tlb.h"
#include "i915_drv.h"
#include "i915_gem_object.h"
@@ -199,7 +199,7 @@ static void flush_tlb_invalidate(struct drm_i915_gem_object
*obj)
if (!obj->mm.tlb)
return;
- intel_gt_invalidate_tlb(gt, obj->mm.tlb);
+ intel_gt_invalidate_tlb_full(gt, obj->mm.tlb);
obj->mm.tlb = 0;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f435e06125aa..18d82cd620bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -11,9 +11,7 @@
#include "pxp/intel_pxp.h"
#include "i915_drv.h"
-#include "i915_perf_oa_regs.h"
#include "intel_context.h"
-#include "intel_engine_pm.h"
#include "intel_engine_regs.h"
#include "intel_ggtt_gmch.h"
#include "intel_gt.h"
@@ -31,6 +29,7 @@
#include "intel_renderstate.h"
#include "intel_rps.h"
#include "intel_gt_sysfs.h"
+#include "intel_tlb.h"
#include "intel_uncore.h"
#include "shmem_utils.h"
@@ -48,8 +47,7 @@ static void __intel_gt_init_early(struct intel_gt *gt)
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
intel_gt_init_timelines(gt);
- mutex_init(>tlb.invalidate_lock);
- seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
+ intel_gt_init_tlb(gt);
intel_gt_pm_init_early(gt);
intel_uc_init_early(>uc);
@@ -770,7 +768,7 @@ void intel_gt_driver_late_release_all(struct
drm_i915_private *i915)
intel_gt_fini_requests(gt);
intel_gt_fini_reset(gt);
intel_gt_fini_timelines(gt);
- mutex_destroy(>tlb.invalidate_lock);
+ intel_gt_fini_tlb(gt);
intel_engines_free(gt);
}
}
@@ -881,163 +879,3 @@ void intel_gt_info_print(const struct intel_gt_info *info,
intel_sseu_dump(>sseu, p);
}
-
-struct reg_and_bit {
- i915_reg_t reg;
- u32 bit;
-};
-
-static struct reg_and_bit
-get_reg_and_bit(const struct intel_engine_cs *engine, const bool gen8,
- const i915_reg_t *regs, const unsigned int num)
-{
- const unsigned int class = engine->class;
- struct reg_and_bit rb = { };
-
- if (drm_WARN_ON_ONCE(>i915->drm,
-class >= num || !regs[class].reg))
- return rb;
-
- rb.reg = regs[class];
- if (gen8 && class == VIDEO_DECODE_CLASS)
- rb.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
- else
- rb.bit = engine->instance;
-
- rb.bit = BIT(rb.bit);
-
- return rb;
-}
-
-static void mmio_invalidate_full(struct intel_gt *gt)
-{
- static const i915_reg_t gen8_regs[] = {
- [RENDER_CLASS] = GEN8_RTCR,
- [VIDEO_DECODE_CLASS]= GEN8_M1TCR, /* , GEN8_M2TCR */
- [VIDEO_ENHANCEMENT_CLASS] = GEN8_VTCR,
- [COPY_ENGINE_CLASS] = GEN8_BTCR,
- };
- static const i915_reg_t gen12_regs[] = {
- [RENDER_CLASS] =
[Intel-gfx] [PATCH v3 0/3] Move TLB invalidation code for its own file and document it
There are more things to be added to TLB invalidation. Before doing that, move the code to its own file, and add the relevant documentation. Patch 1 fixes vma_invalidate_tlb() logic to make it update the right var; Patch 2 only moves the code and do some function renames. No functional change; Patch 3 adds documentation for the TLB invalidation algorithm and functions. --- v3: - Added a fix for an issue from the last TLB patch series; - included a better description about the changes on patch 2; - did some minor fixes at kernel-doc markups; v2: only patch 2 (kernel-doc) was modified: - The kernel-doc markups for TLB were added to i915.rst doc; - Some minor fixes at the texts; - Use a table instead of a literal block while explaining how the algorithm works. That should make easier to understand the logic, both in text form and after its conversion to HTML/PDF; - Remove mention for GuC, as this depends on a series that will be sent later. Chris Wilson (1): drm/i915/gt: Move TLB invalidation to its own file Mauro Carvalho Chehab (2): drm/i915: pass a pointer for tlb seqno at vma_invalidate_tlb() drm/i915/gt: document TLB cache invalidation functions Documentation/gpu/i915.rst| 7 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gem/i915_gem_pages.c | 4 +- drivers/gpu/drm/i915/gt/intel_gt.c| 168 + drivers/gpu/drm/i915/gt/intel_gt.h| 12 -- drivers/gpu/drm/i915/gt/intel_ppgtt.c | 2 +- drivers/gpu/drm/i915/gt/intel_tlb.c | 208 ++ drivers/gpu/drm/i915/gt/intel_tlb.h | 128 + drivers/gpu/drm/i915/i915_vma.c | 7 +- drivers/gpu/drm/i915/i915_vma.h | 2 +- 10 files changed, 355 insertions(+), 184 deletions(-) create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h -- 2.37.1
Re: [Intel-gfx] [PATCH] i915/pmu: Wire GuC backend to per-client busyness
On 04/08/2022 02:21, Umesh Nerlige Ramappa wrote:
On Tue, Aug 02, 2022 at 04:38:45PM -0700, Umesh Nerlige Ramappa wrote:
On Tue, Aug 02, 2022 at 09:41:38AM +0100, Tvrtko Ursulin wrote:
On 01/08/2022 20:02, Umesh Nerlige Ramappa wrote:
On Wed, Jul 27, 2022 at 09:48:18AM +0100, Tvrtko Ursulin wrote:
On 27/07/2022 07:01, Umesh Nerlige Ramappa wrote:
On Fri, Jun 17, 2022 at 09:00:06AM +0100, Tvrtko Ursulin wrote:
On 16/06/2022 23:13, Nerlige Ramappa, Umesh wrote:
From: John Harrison
GuC provides engine_id and last_switch_in ticks for an active
context in
the pphwsp. The context image provides a 32 bit total ticks
which is the
accumulated by the context (a.k.a. context[CTX_TIMESTAMP]). This
information is used to calculate the context busyness as follows:
If the engine_id is valid, then busyness is the sum of
accumulated total
ticks and active ticks. Active ticks is calculated with current
gt time
as reference.
If engine_id is invalid, busyness is equal to accumulated total
ticks.
Since KMD (CPU) retrieves busyness data from 2 sources - GPU and
GuC, a
potential race was highlighted in an earlier review that can
lead to
double accounting of busyness. While the solution to this is a wip,
busyness is still usable for platforms running GuC submission.
v2: (Tvrtko)
- Use COPS_RUNTIME_ACTIVE_TOTAL
- Add code comment for the race
- Undo local variables initializations
v3:
- Add support for virtual engines based on
https://patchwork.freedesktop.org/series/105227/
Signed-off-by: John Harrison
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_context.c | 12 +++-
drivers/gpu/drm/i915/gt/intel_context.h | 6 +-
drivers/gpu/drm/i915/gt/intel_context_types.h | 6 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 5 ++
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 65
++-
drivers/gpu/drm/i915/i915_drm_client.c | 6 +-
6 files changed, 89 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 4070cb5711d8..4a84146710e0 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -576,16 +576,24 @@ void
intel_context_bind_parent_child(struct intel_context *parent,
child->parallel.parent = parent;
}
-u64 intel_context_get_total_runtime_ns(const struct
intel_context *ce)
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce)
{
u64 total, active;
+ if (ce->ops->update_stats)
+ ce->ops->update_stats(ce);
+
total = ce->stats.runtime.total;
if (ce->ops->flags & COPS_RUNTIME_CYCLES)
total *= ce->engine->gt->clock_period_ns;
active = READ_ONCE(ce->stats.active);
- if (active)
+ /*
+ * When COPS_RUNTIME_ACTIVE_TOTAL is set for ce->cops, the
backend
+ * already provides the total active time of the context,
so skip this
+ * calculation when this flag is set.
+ */
+ if (active && !(ce->ops->flags & COPS_RUNTIME_ACTIVE_TOTAL))
active = intel_context_clock() - active;
return total + active;
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index b7d3214d2cdd..5fc7c19ab29b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -56,7 +56,7 @@ static inline bool
intel_context_is_parent(struct intel_context *ce)
return !!ce->parallel.number_children;
}
-static inline bool intel_context_is_pinned(struct intel_context
*ce);
+static inline bool intel_context_is_pinned(const struct
intel_context *ce);
static inline struct intel_context *
intel_context_to_parent(struct intel_context *ce)
@@ -116,7 +116,7 @@ static inline int
intel_context_lock_pinned(struct intel_context *ce)
* Returns: true if the context is currently pinned for use by
the GPU.
*/
static inline bool
-intel_context_is_pinned(struct intel_context *ce)
+intel_context_is_pinned(const struct intel_context *ce)
{
return atomic_read(>pin_count);
}
@@ -351,7 +351,7 @@ intel_context_clear_nopreempt(struct
intel_context *ce)
clear_bit(CONTEXT_NOPREEMPT, >flags);
}
-u64 intel_context_get_total_runtime_ns(const struct
intel_context *ce);
+u64 intel_context_get_total_runtime_ns(struct intel_context *ce);
u64 intel_context_get_avg_runtime_ns(struct intel_context *ce);
static inline u64 intel_context_clock(void)
diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
b/drivers/gpu/drm/i915/gt/intel_context_types.h
index 09f82545789f..797bb4242c18 100644
--- a/drivers/gpu/drm/i915/gt/intel_context_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
@@ -38,6 +38,9 @@ struct intel_context_ops {
#define COPS_RUNTIME_CYCLES_BIT 1
#define COPS_RUNTIME_CYCLES BIT(COPS_RUNTIME_CYCLES_BIT)
+#define COPS_RUNTIME_ACTIVE_TOTAL_BIT 2
+#define COPS_RUNTIME_ACTIVE_TOTAL
BIT(COPS_RUNTIME_ACTIVE_TOTAL_BIT)
+
int (*alloc)(struct
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/gt: document TLB cache invalidation functions
On Tue, 2 Aug 2022 15:30:44 -0700
Niranjana Vishwanathapura wrote:
> On Fri, Jul 29, 2022 at 09:03:55AM +0200, Mauro Carvalho Chehab wrote:
> >Add a description for the TLB cache invalidation algorithm and for
> >the related kAPI functions.
> >
> >Signed-off-by: Mauro Carvalho Chehab
> >---
> >
> >To avoid mailbombing on a large number of people, only mailing lists were
> >C/C on the cover.
> >See [PATCH v2 0/2] at:
> >https://lore.kernel.org/all/cover.1659077372.git.mche...@kernel.org/
> >
> > Documentation/gpu/i915.rst | 7 ++
> > drivers/gpu/drm/i915/gt/intel_tlb.c | 25 +++
> > drivers/gpu/drm/i915/gt/intel_tlb.h | 101
> > 3 files changed, 133 insertions(+)
> >
> >diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> >index 4e59db1cfb00..46911fdd79e8 100644
> >--- a/Documentation/gpu/i915.rst
> >+++ b/Documentation/gpu/i915.rst
> >@@ -58,6 +58,13 @@ Intel GVT-g Host Support(vGPU device model)
> > .. kernel-doc:: drivers/gpu/drm/i915/intel_gvt.c
> >:internal:
> >
> >+TLB cache invalidation
> >+--
> >+
> >+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.h
> >+
> >+.. kernel-doc:: drivers/gpu/drm/i915/gt/intel_tlb.c
> >+
> > Workarounds
> > ---
> >
> >diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c
> >b/drivers/gpu/drm/i915/gt/intel_tlb.c
> >index af8cae979489..4873b7ecc015 100644
> >--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
> >+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
> >@@ -145,6 +145,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
> > intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
> > }
> >
> >+/**
> >+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
> >+ * @gt: GT structure
> >+ * @seqno: sequence number
> >+ *
> >+ * Do a full TLB cache invalidation if the @seqno is bigger than the last
> >+ * full TLB cache invalidation.
> >+ *
> >+ * Note:
> >+ * The TLB cache invalidation logic depends on GEN-specific registers.
> >+ * It currently supports MMIO-based TLB flush for GEN8 to GEN12.
> >+ */
> > void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
> > {
> > intel_wakeref_t wakeref;
> >@@ -171,12 +183,25 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt,
> >u32 seqno)
> > }
> > }
> >
> >+/**
> >+ * intel_gt_init_tlb - initialize TLB-specific vars
> >+ * @gt: GT structure
> >+ *
> >+ * TLB cache invalidation logic internally uses some resources that require
> >+ * initialization. Should be called before doing any TLB cache invalidation.
> >+ */
> > void intel_gt_init_tlb(struct intel_gt *gt)
> > {
> > mutex_init(>tlb.invalidate_lock);
> > seqcount_mutex_init(>tlb.seqno, >tlb.invalidate_lock);
> > }
> >
> >+/**
> >+ * intel_gt_fini_tlb - initialize TLB-specific vars
>
> Free TLB-specific vars
OK.
>
> >+ * @gt: GT structure
> >+ *
> >+ * Frees any resources needed by TLB cache invalidation logic.
> >+ */
> > void intel_gt_fini_tlb(struct intel_gt *gt)
> > {
> > mutex_destroy(>tlb.invalidate_lock);
> >diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.h
> >b/drivers/gpu/drm/i915/gt/intel_tlb.h
> >index 46ce25bf5afe..dca70c33bd61 100644
> >--- a/drivers/gpu/drm/i915/gt/intel_tlb.h
> >+++ b/drivers/gpu/drm/i915/gt/intel_tlb.h
> >@@ -11,16 +11,117 @@
> >
> > #include "intel_gt_types.h"
> >
> >+/**
> >+ * DOC: TLB cache invalidation logic
> >+ *
> >+ * The way the current algorithm works is that a struct drm_i915_gem_object
> >can
> >+ * be created on any order. At unbind/evict time, the object is warranted
> >that
> >+ * it won't be used anymore. So, a sequence number provided by
> >+ * intel_gt_next_invalidate_tlb_full() is stored on it. This can happen
> >either
> >+ * at __vma_put_pages() - for VMA sync unbind, or at ppgtt_unbind_vma() -
> >for
> >+ * VMA async VMA bind.
> >+ *
> >+ * At __i915_gem_object_unset_pages(), intel_gt_invalidate_tlb_full() is
> >called,
> >+ * where it checks if the sequence number of the object was already
> >invalidated
> >+ * or not. If not, it flushes the TLB and increments the sequence number::
> >+ *
> >+ * void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
> >+ * {
> >+ * ...
> >+ * with_intel_gt_pm_if_awake(gt, wakeref) {
> >+ * mutex_lock(>tlb.invalidate_lock);
> >+ * if (tlb_seqno_passed(gt, seqno))
> >+ * goto unlock;
> >+ *
> >+ * // Some code to do TLB invalidation
> >+ * ...
> >+ *
> >+ * write_seqcount_invalidate(>tlb.seqno); // increment seqno
> >+ * mutex_lock(>tlb.invalidate_lock);
> >+ * }
> >+ *
> >+ * So, let's say the current seqno is 2 and 3 new objects were created,
> >+ * on this order::
> >+ *
> >+ * obj1
> >+ * obj2
> >+ * obj3
> >+ *
> >+ * They can be unbind/evict on a different order. At unbind/evict time,
> >+ * the mm.tlb will be stamped with the sequence number, using the number
> >+ * from the last TLB flush, plus 1.
>
> I am trying to get my head
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Fix NPD in PMU during driver teardown
== Series Details == Series: series starting with [1/2] drm/i915: Fix NPD in PMU during driver teardown URL : https://patchwork.freedesktop.org/series/106948/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11966_full -> Patchwork_106948v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_106948v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_106948v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 13) -- Additional (3): shard-rkl shard-dg1 shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_106948v1_full: ### IGT changes ### Possible regressions * igt@kms_cursor_crc@cursor-sliding@pipe-c-dp-1-64x64: - shard-kbl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-kbl4/igt@kms_cursor_crc@cursor-slid...@pipe-c-dp-1-64x64.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-kbl1/igt@kms_cursor_crc@cursor-slid...@pipe-c-dp-1-64x64.html * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions: - shard-skl: NOTRUN -> [INCOMPLETE][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-skl4/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html Known issues Here are the changes found in Patchwork_106948v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@parallel-contexts: - shard-iclb: [PASS][4] -> [SKIP][5] ([i915#4525]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-iclb2/igt@gem_exec_balan...@parallel-contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-iclb6/igt@gem_exec_balan...@parallel-contexts.html * igt@gem_exec_fair@basic-deadline: - shard-glk: NOTRUN -> [FAIL][6] ([i915#2846]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-glk7/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-glk8/igt@gem_exec_fair@basic-none-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-glk8/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-kbl1/igt@gem_exec_fair@basic-n...@vcs1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-kbl4/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][11] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_lmem_swapping@heavy-verify-multi-ccs: - shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-glk7/igt@gem_lmem_swapp...@heavy-verify-multi-ccs.html * igt@gem_lmem_swapping@heavy-verify-random-ccs: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-skl9/igt@gem_lmem_swapp...@heavy-verify-random-ccs.html * igt@gem_lmem_swapping@smem-oom: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-apl2/igt@gem_lmem_swapp...@smem-oom.html * igt@gem_softpin@evict-single-offset: - shard-tglb: [PASS][15] -> [FAIL][16] ([i915#4171]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-tglb7/igt@gem_soft...@evict-single-offset.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-tglb5/igt@gem_soft...@evict-single-offset.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#3323]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_106948v1/shard-apl6/igt@gem_userptr_bl...@dmabuf-sync.html * igt@i915_module_load@reload-with-fault-injection: - shard-snb: [PASS][18] -> [DMESG-WARN][19] ([i915#6201]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11966/shard-snb6/igt@i915_module_l...@reload-with-fault-injection.html [19]:
Re: [Intel-gfx] [PATCH 6/8] drm/i915/rpm: d3cold Policy
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Thursday, August 4, 2022 2:16 AM
> To: Tangudu, Tilak
> Cc: Ewins, Jon ; Belgaumkar, Vinay
> ; Roper, Matthew D
> ; Wilson, Chris P ;
> Nikula, Jani ; Gupta, saurabhg
> ; Gupta, Anshuman
> ; Nilawar, Badal ;
> Deak, Imre ; Iddamsetty, Aravind
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [PATCH 6/8] drm/i915/rpm: d3cold Policy
>
> On Thu, Jul 21, 2022 at 03:29:53PM +0530, tilak.tang...@intel.com wrote:
> > From: Tilak Tangudu
>
> This needs to be sorted out... or the patch split or use the
> Co-developed-by:...
>
> >
> > Add d3cold_sr_lmem_threshold modparam to choose between d3cold-off
> > zero watt and d3hot/d3cold-VRAM Self Refresh.
> > i915 requires to evict the lmem objects to smem in order to support
> > d3cold-Off. if platform does not supports vram_sr feature then fall
> > back to d3hot by disabling d3cold to avoid the rpm suspend/resume
> > latency.
> > Extend the d3cold_sr_lmem_threshold modparam to debugfs i915_params so
> > that, it can be used by igt test.
> >
> > If gfx root port is not capable of sending PME from d3cold or doesn't
> > have _PR3 power resources then only d3hot state can be supported.
> >
> > Adding intel_pm_prepare_targeted_d3_state() to choose the correct
> > target d3 state and cache it to intel_runtime_pm structure, it can be
> > used in rpm suspend/resume callback accordingly.
> >
> > v2: lmem->avail stopped tracking lmem usage since ttm is introduced,
> > so removed lmem->avail usage in policy.
> > FIXME here, lmem usage is not added, need to be added by using query
> > functions.
> > FIXME, Forcing the policy to enter D3COLD_OFF for validation purpose.
> >
> > Cc: Rodrigo Vivi
> > Signed-off-by: Anshuman Gupta
> > Signed-off-by: Tilak Tangudu
> > ---
> > drivers/gpu/drm/i915/i915_driver.c | 6 +
> > drivers/gpu/drm/i915/i915_params.c | 5
> > drivers/gpu/drm/i915/i915_params.h | 1 +
> > drivers/gpu/drm/i915/intel_pm.c | 35 +
> > drivers/gpu/drm/i915/intel_pm.h | 1 +
> > drivers/gpu/drm/i915/intel_runtime_pm.h | 7 +
> > 6 files changed, 55 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index 4c36554567fd..2b2e9563f149 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -1581,6 +1581,12 @@ static int intel_runtime_idle(struct device *kdev)
> > struct drm_i915_private *i915 = kdev_to_i915(kdev);
> > int ret = 1;
> >
> > + disable_rpm_wakeref_asserts(>runtime_pm);
> > + ret = intel_pm_prepare_targeted_d3_state(i915);
> > + if (!ret)
> > + ret = 1;
>
> why?
>
> > +
> > + enable_rpm_wakeref_asserts(>runtime_pm);
> > pm_runtime_mark_last_busy(kdev);
> > pm_runtime_autosuspend(kdev);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_params.c
> > b/drivers/gpu/drm/i915/i915_params.c
> > index 6fc475a5db61..4603f5c2ed77 100644
> > --- a/drivers/gpu/drm/i915/i915_params.c
> > +++ b/drivers/gpu/drm/i915/i915_params.c
> > @@ -197,6 +197,11 @@ i915_param_named(enable_gvt, bool, 0400,
> > "Enable support for Intel GVT-g graphics virtualization host
> > support(default:false)"); #endif
> >
> > +i915_param_named_unsafe(d3cold_sr_lmem_threshold, int, 0600,
> > + "Enable VRAM Self refresh when size of lmem is greater to this
> threshold. "
> > + "If VRAM Self Refresh is not available then fall back to d3cold. "
> > + "It helps to optimize the suspend/resume latecy. (default: 300mb)");
> > +
> > #if CONFIG_DRM_I915_REQUEST_TIMEOUT
> > i915_param_named_unsafe(request_timeout_ms, uint, 0600,
> > "Default request/fence/batch buffer expiration
> timeout."); diff
> > --git a/drivers/gpu/drm/i915/i915_params.h
> > b/drivers/gpu/drm/i915/i915_params.h
> > index 2733cb6cfe09..1a86711038da 100644
> > --- a/drivers/gpu/drm/i915/i915_params.h
> > +++ b/drivers/gpu/drm/i915/i915_params.h
> > @@ -75,6 +75,7 @@ struct drm_printer;
> > param(unsigned int, request_timeout_ms,
> CONFIG_DRM_I915_REQUEST_TIMEOUT,
> CONFIG_DRM_I915_REQUEST_TIMEOUT ? 0600 : 0) \
> > param(unsigned int, lmem_size, 0, 0400) \
> > param(unsigned int, lmem_bar_size, 0, 0400) \
> > + param(int, d3cold_sr_lmem_threshold, 300, 0600) \
> > /* leave bools at the end to not create holes */ \
> > param(bool, enable_hangcheck, true, 0600) \
> > param(bool, load_detect_test, false, 0600) \ diff --git
> > a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> > index f06babdb3a8c..20b0638ecd5c 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -8287,6 +8287,41 @@ void intel_pm_setup(struct drm_i915_private
> *dev_priv)
> > atomic_set(_priv->runtime_pm.wakeref_count, 0); }
> >
> > +int intel_pm_prepare_targeted_d3_state(struct drm_i915_private *i915)
> > +{
> > + struct intel_runtime_pm *rpm = >runtime_pm;
> > +
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed helper
> -Original Message-
> From: Tangudu, Tilak
> Sent: Thursday, July 21, 2022 3:30 PM
> To: Ewins, Jon ; Belgaumkar, Vinay
> ; Roper, Matthew D
> ; Wilson, Chris P ;
> Nikula, Jani ; Gupta, saurabhg
> ; Vivi, Rodrigo ; Gupta,
> Anshuman ; Nilawar, Badal
> ; Tangudu, Tilak ; Deak,
> Imre ; Iddamsetty, Aravind
> ; intel-gfx@lists.freedesktop.org
> Subject: [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed helper
>
> From: Tilak Tangudu
>
> Added is_intel_rpm_allowed function to query the runtime_pm status and
> disllow during suspending and resuming.
>
> v2: Return -2 if runtime pm is not allowed in runtime_pm_get and skip wakeref
> release in runtime_pm_put if wakeref value is -2. - Jani N
> Signed-off-by: Tilak Tangudu
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 23 ++-
> drivers/gpu/drm/i915/intel_runtime_pm.h | 1 +
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 6ed5786bcd29..704beeeb560b 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -113,7 +113,7 @@ static void untrack_intel_runtime_pm_wakeref(struct
> intel_runtime_pm *rpm,
> unsigned long flags, n;
> bool found = false;
>
> - if (unlikely(stack == -1))
> + if (unlikely(stack == -1) || unlikely(stack == -2))
> return;
>
> spin_lock_irqsave(>debug.lock, flags); @@ -320,6 +320,21 @@
> untrack_all_intel_runtime_pm_wakerefs(struct intel_runtime_pm *rpm) }
>
> #endif
> +static int intel_runtime_pm_status(struct intel_runtime_pm *rpm) {
> + return rpm->kdev->power.runtime_status; }
> +
> +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm) {
> + int rpm_status;
> +
> + rpm_status = intel_runtime_pm_status(rpm);
> + if (rpm_status == RPM_RESUMING || rpm_status ==
> RPM_SUSPENDING)
AFAIR I have commented on first patch, we may need dev->power.lock here.
It is racy to test kdev->power.runtime_status with PM core can change it any
time.
Please check the pm_runtime_status_suspended() kernel doc in
include/linux/pm_runtime.h
Thanks,
Anshuman Gupta.
> + return false;
> + else
> + return true;
> +}
>
> static void
> intel_runtime_pm_acquire(struct intel_runtime_pm *rpm, bool wakelock) @@ -
> 354,6 +369,9 @@ static intel_wakeref_t __intel_runtime_pm_get(struct
> intel_runtime_pm *rpm,
>runtime_pm);
> int ret;
>
> + if (!is_intel_rpm_allowed(rpm))
> + return -2;
> +
> ret = pm_runtime_get_sync(rpm->kdev);
> drm_WARN_ONCE(>drm, ret < 0,
> "pm_runtime_get_sync() failed: %d\n", ret); @@ -490,6
> +508,9 @@ static void __intel_runtime_pm_put(struct intel_runtime_pm *rpm,
>
> untrack_intel_runtime_pm_wakeref(rpm, wref);
>
> + if (wref == -2)
> + return;
> +
> intel_runtime_pm_release(rpm, wakelock);
>
> pm_runtime_mark_last_busy(kdev);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h
> b/drivers/gpu/drm/i915/intel_runtime_pm.h
> index d9160e3ff4af..99418c3a934a 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.h
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
> @@ -173,6 +173,7 @@ void intel_runtime_pm_init_early(struct
> intel_runtime_pm *rpm); void intel_runtime_pm_enable(struct
> intel_runtime_pm *rpm); void intel_runtime_pm_disable(struct
> intel_runtime_pm *rpm); void intel_runtime_pm_driver_release(struct
> intel_runtime_pm *rpm);
> +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm);
>
> intel_wakeref_t intel_runtime_pm_get(struct intel_runtime_pm *rpm);
> intel_wakeref_t intel_runtime_pm_get_if_in_use(struct intel_runtime_pm
> *rpm);
> --
> 2.25.1
