[Intel-gfx] [PATCH v2] drm/i915/xelpd: Calculate first_line_bpg_offset for DSC 1.1
This change is required for DSC 1.1 because the current calculation
is for DSC 1.2 and may get a calculated value which is not
recommended by DSC 1.1, for example, the calculated value at 8bpp
becomes 15, not the value of 12 recommened by DSC 1.1.
v2:
- change the if-condition from minor version 2 to 1.
- add comment about first_line_bpg_offset for DSC 1.1.
Cc: Ankit Nautiyal
Cc: Juha-Pekka Heikkil
Signed-off-by: William Tseng
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index bd9116d2cd76..beeb1c594559 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -72,11 +72,19 @@ calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
int qp_bpc_modifier = (bpc - 8) * 2;
u32 res, buf_i, bpp_i;
- if (vdsc_cfg->slice_height >= 8)
- vdsc_cfg->first_line_bpg_offset =
- 12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height -
8)), 100);
- else
- vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height -
1);
+ if (vdsc_cfg->dsc_version_minor == 1) {
+ /* The recommended and required Values from Table E-2 for
DSC1.1 */
+ if (bpp == 8)
+ rc->first_line_bpg_offset = 12;
+ else
+ rc->first_line_bpg_offset = 15;
+ } else {
+ if (vdsc_cfg->slice_height >= 8)
+ vdsc_cfg->first_line_bpg_offset =
+ 12 + DIV_ROUND_UP((9 * min(34,
vdsc_cfg->slice_height - 8)), 100);
+ else
+ vdsc_cfg->first_line_bpg_offset = 2 *
(vdsc_cfg->slice_height - 1);
+ }
/* Our hw supports only 444 modes as of today */
if (bpp >= 12)
--
2.34.1
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add ability for tracking buffer objects per client
On 27-07-2023 15:43, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> In order to show per client memory usage lets add some infrastructure
> which enables tracking buffer objects owned by clients.
>
> We add a per client list protected by a new per client lock and to support
> delayed destruction (post client exit) we make tracked objects hold
> references to the owning client.
>
> Also, object memory region teardown is moved to the existing RCU free
> callback to allow safe dereference from the fdinfo RCU read section.
This is same as the earlier series, which I had reviewed but forgot to
give r-b. sorry for the delay.
Reviewed-by: Aravind Iddamsetty
Thanks,
Aravind.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 13 +--
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 12 +++
> drivers/gpu/drm/i915/i915_drm_client.c| 36 +++
> drivers/gpu/drm/i915/i915_drm_client.h| 32 +
> 4 files changed, 90 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 97ac6fb37958..3dc4fbb67d2b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -105,6 +105,10 @@ void i915_gem_object_init(struct drm_i915_gem_object
> *obj,
>
> INIT_LIST_HEAD(&obj->mm.link);
>
> +#ifdef CONFIG_PROC_FS
> + INIT_LIST_HEAD(&obj->client_link);
> +#endif
> +
> INIT_LIST_HEAD(&obj->lut_list);
> spin_lock_init(&obj->lut_lock);
>
> @@ -292,6 +296,10 @@ void __i915_gem_free_object_rcu(struct rcu_head *head)
> container_of(head, typeof(*obj), rcu);
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
>
> + /* We need to keep this alive for RCU read access from fdinfo. */
> + if (obj->mm.n_placements > 1)
> + kfree(obj->mm.placements);
> +
> i915_gem_object_free(obj);
>
> GEM_BUG_ON(!atomic_read(&i915->mm.free_count));
> @@ -388,9 +396,6 @@ void __i915_gem_free_object(struct drm_i915_gem_object
> *obj)
> if (obj->ops->release)
> obj->ops->release(obj);
>
> - if (obj->mm.n_placements > 1)
> - kfree(obj->mm.placements);
> -
> if (obj->shares_resv_from)
> i915_vm_resv_put(obj->shares_resv_from);
>
> @@ -441,6 +446,8 @@ static void i915_gem_free_object(struct drm_gem_object
> *gem_obj)
>
> GEM_BUG_ON(i915_gem_object_is_framebuffer(obj));
>
> + i915_drm_client_remove_object(obj);
> +
> /*
>* Before we free the object, make sure any pure RCU-only
>* read-side critical sections are complete, e.g.
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> index e72c57716bee..8de2b91b3edf 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
> @@ -300,6 +300,18 @@ struct drm_i915_gem_object {
>*/
> struct i915_address_space *shares_resv_from;
>
> +#ifdef CONFIG_PROC_FS
> + /**
> + * @client: @i915_drm_client which created the object
> + */
> + struct i915_drm_client *client;
> +
> + /**
> + * @client_link: Link into @i915_drm_client.objects_list
> + */
> + struct list_head client_link;
> +#endif
> +
> union {
> struct rcu_head rcu;
> struct llist_node freed;
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index 2a44b3876cb5..2e5e69edc0f9 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -28,6 +28,10 @@ struct i915_drm_client *i915_drm_client_alloc(void)
> kref_init(&client->kref);
> spin_lock_init(&client->ctx_lock);
> INIT_LIST_HEAD(&client->ctx_list);
> +#ifdef CONFIG_PROC_FS
> + spin_lock_init(&client->objects_lock);
> + INIT_LIST_HEAD(&client->objects_list);
> +#endif
>
> return client;
> }
> @@ -108,4 +112,36 @@ void i915_drm_client_fdinfo(struct drm_printer *p,
> struct drm_file *file)
> for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> show_client_class(p, i915, file_priv->client, i);
> }
> +
> +void i915_drm_client_add_object(struct i915_drm_client *client,
> + struct drm_i915_gem_object *obj)
> +{
> + unsigned long flags;
> +
> + GEM_WARN_ON(obj->client);
> + GEM_WARN_ON(!list_empty(&obj->client_link));
> +
> + spin_lock_irqsave(&client->objects_lock, flags);
> + obj->client = i915_drm_client_get(client);
> + list_add_tail_rcu(&obj->client_link, &client->objects_list);
> + spin_unlock_irqrestore(&client->objects_lock, flags);
> +}
> +
> +bool i915_drm_client_remove_object(struct drm_i915_gem_object *obj)
> +{
> + struct i915_drm_client *client = fetch_and_zero(&obj->clien
Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement fdinfo memory stats printing
On 27-07-2023 15:43, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Use the newly added drm_print_memory_stats helper to show memory
> utilisation of our objects in drm/driver specific fdinfo output.
>
> To collect the stats we walk the per memory regions object lists
> and accumulate object size into the respective drm_memory_stats
> categories.
>
> Objects with multiple possible placements are reported in multiple
> regions for total and shared sizes, while other categories are
> counted only for the currently active region.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Aravind Iddamsetty
> Cc: Rob Clark > ---
> drivers/gpu/drm/i915/i915_drm_client.c | 85 ++
> 1 file changed, 85 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index a61356012df8..9e7a6075ee25 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -45,6 +45,89 @@ void __i915_drm_client_free(struct kref *kref)
> }
>
> #ifdef CONFIG_PROC_FS
> +static void
> +obj_meminfo(struct drm_i915_gem_object *obj,
> + struct drm_memory_stats stats[INTEL_REGION_UNKNOWN])
> +{
> + struct intel_memory_region *mr;
> + u64 sz = obj->base.size;
> + enum intel_region_id id;
> + unsigned int i;
> +
> + /* Attribute size and shared to all possible memory regions. */
> + for (i = 0; i < obj->mm.n_placements; i++) {
> + mr = obj->mm.placements[i];
> + id = mr->id;
> +
> + if (obj->base.handle_count > 1)
> + stats[id].shared += sz;
> + else
> + stats[id].private += sz;
> + }
> +
> + /* Attribute other categories to only the current region. */
> + mr = obj->mm.region;
> + if (mr)
> + id = mr->id;
> + else
> + id = INTEL_REGION_SMEM;
> +
> + if (!obj->mm.n_placements) {
I guess we do not expect to have n_placements set to public objects, is
that right?
Thanks,
Aravind.
> + if (obj->base.handle_count > 1)
> + stats[id].shared += sz;
> + else
> + stats[id].private += sz;
> + }
> +
> + if (i915_gem_object_has_pages(obj)) {
> + stats[id].resident += sz;
> +
> + if (!dma_resv_test_signaled(obj->base.resv,
> + dma_resv_usage_rw(true)))
> + stats[id].active += sz;
> + else if (i915_gem_object_is_shrinkable(obj) &&
> + obj->mm.madv == I915_MADV_DONTNEED)
> + stats[id].purgeable += sz;
> + }
> +}
> +
> +static void show_meminfo(struct drm_printer *p, struct drm_file *file)
> +{
> + struct drm_memory_stats stats[INTEL_REGION_UNKNOWN] = {};
> + struct drm_i915_file_private *fpriv = file->driver_priv;
> + struct i915_drm_client *client = fpriv->client;
> + struct drm_i915_private *i915 = fpriv->i915;
> + struct drm_i915_gem_object *obj;
> + struct intel_memory_region *mr;
> + struct list_head *pos;
> + unsigned int id;
> +
> + /* Public objects. */
> + spin_lock(&file->table_lock);
> + idr_for_each_entry(&file->object_idr, obj, id)
> + obj_meminfo(obj, stats);
> + spin_unlock(&file->table_lock);
> +
> + /* Internal objects. */
> + rcu_read_lock();
> + list_for_each_rcu(pos, &client->objects_list) {
> + obj = i915_gem_object_get_rcu(list_entry(pos, typeof(*obj),
> + client_link));
> + if (!obj)
> + continue;
> + obj_meminfo(obj, stats);
> + i915_gem_object_put(obj);
> + }
> + rcu_read_unlock();
> +
> + for_each_memory_region(mr, i915, id)
> + drm_print_memory_stats(p,
> +&stats[id],
> +DRM_GEM_OBJECT_RESIDENT |
> +DRM_GEM_OBJECT_PURGEABLE,
> +mr->name);
> +}
> +
> static const char * const uabi_class_names[] = {
> [I915_ENGINE_CLASS_RENDER] = "render",
> [I915_ENGINE_CLASS_COPY] = "copy",
> @@ -106,6 +189,8 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct
> drm_file *file)
>* **
>*/
>
> + show_meminfo(p, file);
> +
> if (GRAPHICS_VER(i915) < 8)
> return;
>
[Intel-gfx] ✓ Fi.CI.BAT: success for Resolve suspend-resume racing with GuC destroy-context-worker
== Series Details == Series: Resolve suspend-resume racing with GuC destroy-context-worker URL : https://patchwork.freedesktop.org/series/121916/ State : success == Summary == CI Bug Log - changes from CI_DRM_13463 -> Patchwork_121916v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/index.html Participating hosts (42 -> 40) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_121916v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-2: [PASS][1] -> [ABORT][2] ([i915#6687] / [i915#7978] / [i915#8668]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-8/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@i915_pm_rpm@basic-rte: - bat-rpls-1: [PASS][4] -> [FAIL][5] ([i915#7940]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rpls-1/igt@i915_pm_...@basic-rte.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-rpls-1/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-cfl-8109u: [PASS][6] -> [FAIL][7] ([i915#7940]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_pm_rps@basic-api: - bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#6621]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_mocs: - bat-mtlp-8: NOTRUN -> [DMESG-FAIL][9] ([i915#7059]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html - bat-mtlp-6: [PASS][10] -> [DMESG-FAIL][11] ([i915#7059]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][12] -> [ABORT][13] ([i915#4983] / [i915#7461] / [i915#8347] / [i915#8384]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rpls-1/igt@i915_selftest@l...@reset.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@i915_selftest@live@slpc: - bat-mtlp-8: NOTRUN -> [DMESG-WARN][14] ([i915#6367]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-8/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-mtlp-6: [PASS][15] -> [ABORT][16] ([i915#8802]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-mtlp-6/igt@i915_susp...@basic-s2idle-without-i915.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-6/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#6645]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#7828]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_flip@basic-flip-vs-wf_vblank@b-vga1: - fi-pnv-d510:[PASS][19] -> [FAIL][20] ([i915#2122]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vbl...@b-vga1.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/fi-pnv-d510/igt@kms_flip@basic-flip-vs-wf_vbl...@b-vga1.html * igt@prime_vgem@basic-fence-read: - bat-mtlp-8: NOTRUN -> [SKIP][21] ([i915#3708]) +2 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-8/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-gtt: - bat-mtlp-8: NOTRUN -> [SKIP][22] ([i915#3708] / [i915#4077]) +1 similar issue [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121916v1/bat-mtlp-8/igt@prime_v...@basic-gtt.html Possible fixes
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Resolve suspend-resume racing with GuC destroy-context-worker
== Series Details == Series: Resolve suspend-resume racing with GuC destroy-context-worker URL : https://patchwork.freedesktop.org/series/121916/ 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 v1 0/3] Resolve suspend-resume racing with GuC destroy-context-worker
On Wed, 2023-08-02 at 16:34 -0700, Teres Alexis, Alan Previn wrote: > This series is the result of debugging issues root caused to > races between the GuC's destroyed_worker_func being triggered vs > repeating suspend-resume cycles with concurrent delayed > fence signals for engine-freeing. > > The reproduction steps require that an app is created right before > the start of the suspend cycle where it creates a new gem > context and submits a tiny workload that would complete in the > middle of the suspend cycle. However this app uses dma-buffer > sharing or dma-fence with non-GPU objects or signals that > eventually triggers a FENCE_FREE via__i915_sw_fence_notify that > connects to engines_notify -> free_engines_rcu -> > intel_context_put -> kref_put(&ce->ref..) that queues the > worker after the GuCs CTB has been disabled (i.e. after > i915-gem's suspend-late flows). > As an FYI - in offline conversations with John and Daniele, we have agreed that at least the first two of the patches in this are necessary improvements but the last patch may remain open as further offline debug is continuing to pin down the src of the above fence-signal-flow. For now we are hoping to proceed with reviewing the first two patches and only look into the 3rd patch if there are system level fence signalling that truly can trigger this anomaly or if its just a straddling request somewhere within i915 that has appeared or hung at the wrong time which needs to be fixed. alan:snip
[Intel-gfx] [PATCH v1 1/3] drm/i915/guc: Flush context destruction worker at suspend
Suspend is not like reset, it can unroll, so we have to properly
flush pending context-guc-id deregistrations to complete before
we return from suspend calls.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +-
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 5 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 ++
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 +++
drivers/gpu/drm/i915/gt/uc/intel_uc.h | 1 +
5 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 5a942af0a14e..3162d859ed68 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -289,8 +289,10 @@ int intel_gt_resume(struct intel_gt *gt)
static void wait_for_suspend(struct intel_gt *gt)
{
- if (!intel_gt_pm_is_awake(gt))
+ if (!intel_gt_pm_is_awake(gt)) {
+ intel_uc_suspend_prepare(>->uc);
return;
+ }
if (intel_gt_wait_for_idle(gt, I915_GT_SUSPEND_IDLE_TIMEOUT) == -ETIME)
{
/*
@@ -299,6 +301,8 @@ static void wait_for_suspend(struct intel_gt *gt)
*/
intel_gt_set_wedged(gt);
intel_gt_retire_requests(gt);
+ } else {
+ intel_uc_suspend_prepare(>->uc);
}
intel_gt_pm_wait_for_idle(gt);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index a0e3ef1c65d2..dc7735a19a5a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1578,6 +1578,11 @@ static void guc_flush_submissions(struct intel_guc *guc)
spin_unlock_irqrestore(&sched_engine->lock, flags);
}
+void intel_guc_submission_suspend_prepare(struct intel_guc *guc)
+{
+ flush_work(&guc->submission_state.destroyed_worker);
+}
+
static void guc_flush_destroyed_contexts(struct intel_guc *guc);
void intel_guc_submission_reset_prepare(struct intel_guc *guc)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
index c57b29cdb1a6..7f0705ece74b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h
@@ -38,6 +38,8 @@ int intel_guc_wait_for_pending_msg(struct intel_guc *guc,
bool interruptible,
long timeout);
+void intel_guc_submission_suspend_prepare(struct intel_guc *guc);
+
static inline bool intel_guc_submission_is_supported(struct intel_guc *guc)
{
return guc->submission_supported;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 18250fb64bd8..468d7b397927 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -679,6 +679,13 @@ void intel_uc_runtime_suspend(struct intel_uc *uc)
guc_disable_communication(guc);
}
+void intel_uc_suspend_prepare(struct intel_uc *uc)
+{
+ struct intel_guc *guc = &uc->guc;
+
+ intel_guc_submission_suspend_prepare(guc);
+}
+
void intel_uc_suspend(struct intel_uc *uc)
{
struct intel_guc *guc = &uc->guc;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
index 014bb7d83689..036877a07261 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.h
@@ -49,6 +49,7 @@ void intel_uc_reset_prepare(struct intel_uc *uc);
void intel_uc_reset(struct intel_uc *uc, intel_engine_mask_t stalled);
void intel_uc_reset_finish(struct intel_uc *uc);
void intel_uc_cancel_requests(struct intel_uc *uc);
+void intel_uc_suspend_prepare(struct intel_uc *uc);
void intel_uc_suspend(struct intel_uc *uc);
void intel_uc_runtime_suspend(struct intel_uc *uc);
int intel_uc_resume(struct intel_uc *uc);
--
2.39.0
[Intel-gfx] [PATCH v1 2/3] drm/i915/guc: Close deregister-context race against CT-loss
If we are at the end of suspend or very early in resume
its possible an async fence signal could lead us to the
execution of the context destruction worker (after the
prior worker flush).
Even if checking that the CT is enabled before calling
destroyed_worker_func, guc_lrc_desc_unpin may still fail
because in corner cases, as we traverse the GuC's
context-destroy list, the CT could get disabled in the mid
of it right before calling the GuC's CT send function.
We've witnessed this race condition once every ~6000-8000
suspend-resume cycles while ensuring workloads that render
something onscreen is continuously started just before
we suspend (and the workload is small enough to complete
either very late in suspend or very early in resume).
In such a case, we need to unroll the unpin process because
guc-lrc-unpin takes a gt wakeref which only gets released in
the G2H IRQ reply that never comes through in this corner
case. That will cascade into a kernel hang later at the tail
end of suspend in this function:
intel_wakeref_wait_for_idle(>->wakeref)
(called by) - intel_gt_pm_wait_for_idle
(called by) - wait_for_suspend
Doing this unroll and keeping the context in the GuC's
destroy-list will allow the context to get picked up on
the next destroy worker invocation or purged as part of a
major GuC sanitization or reset flow.
While we fix this race condition, let's also ensure we
never allow the kernel to hang in intel_gt_pm_wait_for_idle
with a huge timeout and drm_warn.
Signed-off-by: Alan Previn
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 38 +--
1 file changed, 34 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index dc7735a19a5a..a7530ad7008d 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -235,6 +235,13 @@ set_context_destroyed(struct intel_context *ce)
ce->guc_state.sched_state |= SCHED_STATE_DESTROYED;
}
+static inline void
+clr_context_destroyed(struct intel_context *ce)
+{
+ lockdep_assert_held(&ce->guc_state.lock);
+ ce->guc_state.sched_state &= ~SCHED_STATE_DESTROYED;
+}
+
static inline bool context_pending_disable(struct intel_context *ce)
{
return ce->guc_state.sched_state & SCHED_STATE_PENDING_DISABLE;
@@ -3175,7 +3182,7 @@ static void guc_context_close(struct intel_context *ce)
spin_unlock_irqrestore(&ce->guc_state.lock, flags);
}
-static inline void guc_lrc_desc_unpin(struct intel_context *ce)
+static inline int guc_lrc_desc_unpin(struct intel_context *ce)
{
struct intel_guc *guc = ce_to_guc(ce);
struct intel_gt *gt = guc_to_gt(guc);
@@ -3199,10 +3206,20 @@ static inline void guc_lrc_desc_unpin(struct
intel_context *ce)
if (unlikely(disabled)) {
release_guc_id(guc, ce);
__guc_context_destroy(ce);
- return;
+ return 0;
}
- deregister_context(ce, ce->guc_id.id);
+ if (deregister_context(ce, ce->guc_id.id)) {
+ /* Seal race with concurrent suspend by unrolling */
+ spin_lock_irqsave(&ce->guc_state.lock, flags);
+ set_context_registered(ce);
+ clr_context_destroyed(ce);
+ intel_gt_pm_put(gt);
+ spin_unlock_irqrestore(&ce->guc_state.lock, flags);
+ return -ENODEV;
+ }
+
+ return 0;
}
static void __guc_context_destroy(struct intel_context *ce)
@@ -3270,7 +3287,20 @@ static void deregister_destroyed_contexts(struct
intel_guc *guc)
if (!ce)
break;
- guc_lrc_desc_unpin(ce);
+ if (guc_lrc_desc_unpin(ce)) {
+ /*
+* This means GuC's CT link severed mid-way which only
happens
+* in suspend-resume corner cases. In this case, put the
+* context back into the destroyed_contexts list which
will
+* get picked up on the next context deregistration
event or
+* purged in a GuC sanitization event
(reset/unload/wedged/...).
+*/
+ spin_lock_irqsave(&guc->submission_state.lock, flags);
+ list_add_tail(&ce->destroyed_link,
+
&guc->submission_state.destroyed_contexts);
+ spin_unlock_irqrestore(&guc->submission_state.lock,
flags);
+ }
+
}
}
--
2.39.0
[Intel-gfx] [PATCH v1 3/3] drm/i915/gt: Timeout when waiting for idle in suspending
When suspending, add a timeout when calling
intel_gt_pm_wait_for_idle else if we have a lost
G2H event that holds a wakeref (which would be
indicating of a bug elsewhere in the driver), we
get to complete the suspend-resume cycle, albeit
without all the lower power hw counters hitting
its targets, instead of hanging in the kernel.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 7 ++-
drivers/gpu/drm/i915/gt/intel_gt_pm.h | 7 ++-
drivers/gpu/drm/i915/intel_wakeref.c | 14 ++
drivers/gpu/drm/i915/intel_wakeref.h | 5 +++--
5 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index ee15486fed0d..090438eb8682 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -688,7 +688,7 @@ void intel_engines_release(struct intel_gt *gt)
if (!engine->release)
continue;
- intel_wakeref_wait_for_idle(&engine->wakeref);
+ intel_wakeref_wait_for_idle(&engine->wakeref, 0);
GEM_BUG_ON(intel_engine_pm_is_awake(engine));
engine->release(engine);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index 3162d859ed68..dfe77eb3efd1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -289,6 +289,8 @@ int intel_gt_resume(struct intel_gt *gt)
static void wait_for_suspend(struct intel_gt *gt)
{
+ int timeout_ms = CONFIG_DRM_I915_MAX_REQUEST_BUSYWAIT ? : 1;
+
if (!intel_gt_pm_is_awake(gt)) {
intel_uc_suspend_prepare(>->uc);
return;
@@ -305,7 +307,10 @@ static void wait_for_suspend(struct intel_gt *gt)
intel_uc_suspend_prepare(>->uc);
}
- intel_gt_pm_wait_for_idle(gt);
+ /* we are suspending, so we shouldn't be waiting forever */
+ if (intel_gt_pm_wait_timeout_for_idle(gt, timeout_ms) == -ETIME)
+ drm_warn(>->i915->drm, "Bailing from %s after %d milisec
timeout\n",
+__func__, timeout_ms);
}
void intel_gt_suspend_prepare(struct intel_gt *gt)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
index 6c9a46452364..5358acc2b5b1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.h
@@ -68,7 +68,12 @@ static inline void intel_gt_pm_might_put(struct intel_gt *gt)
static inline int intel_gt_pm_wait_for_idle(struct intel_gt *gt)
{
- return intel_wakeref_wait_for_idle(>->wakeref);
+ return intel_wakeref_wait_for_idle(>->wakeref, 0);
+}
+
+static inline int intel_gt_pm_wait_timeout_for_idle(struct intel_gt *gt, int
timeout_ms)
+{
+ return intel_wakeref_wait_for_idle(>->wakeref, timeout_ms);
}
void intel_gt_pm_init_early(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/intel_wakeref.c
b/drivers/gpu/drm/i915/intel_wakeref.c
index 718f2f1b6174..7e01d4cc300c 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.c
+++ b/drivers/gpu/drm/i915/intel_wakeref.c
@@ -111,14 +111,20 @@ void __intel_wakeref_init(struct intel_wakeref *wf,
"wakeref.work", &key->work, 0);
}
-int intel_wakeref_wait_for_idle(struct intel_wakeref *wf)
+int intel_wakeref_wait_for_idle(struct intel_wakeref *wf, int timeout_ms)
{
- int err;
+ int err = 0;
might_sleep();
- err = wait_var_event_killable(&wf->wakeref,
- !intel_wakeref_is_active(wf));
+ if (!timeout_ms)
+ err = wait_var_event_killable(&wf->wakeref,
+ !intel_wakeref_is_active(wf));
+ else if (wait_var_event_timeout(&wf->wakeref,
+ !intel_wakeref_is_active(wf),
+ msecs_to_jiffies(timeout_ms)) < 1)
+ err = -ETIME;
+
if (err)
return err;
diff --git a/drivers/gpu/drm/i915/intel_wakeref.h
b/drivers/gpu/drm/i915/intel_wakeref.h
index ec881b097368..6fbb7a2fb6ea 100644
--- a/drivers/gpu/drm/i915/intel_wakeref.h
+++ b/drivers/gpu/drm/i915/intel_wakeref.h
@@ -251,15 +251,16 @@ __intel_wakeref_defer_park(struct intel_wakeref *wf)
/**
* intel_wakeref_wait_for_idle: Wait until the wakeref is idle
* @wf: the wakeref
+ * @timeout_ms: timeout to wait in milisecs, zero means forever
*
* Wait for the earlier asynchronous release of the wakeref. Note
* this will wait for any third party as well, so make sure you only wait
* when you have control over the wakeref and trust no one else is acquiring
* it.
*
- * Return: 0 on success, error code if killed.
+ * Return: 0 on success, error code if killed, -ETIME if timed-out.
*/
-int intel_wakeref_wait_for_idl
[Intel-gfx] [PATCH v1 0/3] Resolve suspend-resume racing with GuC destroy-context-worker
This series is the result of debugging issues root caused to races between the GuC's destroyed_worker_func being triggered vs repeating suspend-resume cycles with concurrent delayed fence signals for engine-freeing. The reproduction steps require that an app is created right before the start of the suspend cycle where it creates a new gem context and submits a tiny workload that would complete in the middle of the suspend cycle. However this app uses dma-buffer sharing or dma-fence with non-GPU objects or signals that eventually triggers a FENCE_FREE via__i915_sw_fence_notify that connects to engines_notify -> free_engines_rcu -> intel_context_put -> kref_put(&ce->ref..) that queues the worker after the GuCs CTB has been disabled (i.e. after i915-gem's suspend-late flows). This sequence is a corner-case and required repeating this app->suspend->resume cycle ~1500 times across 4 identical systems to see it once. That said, based on above callstack, it is clear that merely flushing the context destruction worker, which is obviously missing and needed, isn't sufficient. Because of that, this series adds additional patches besides the obvious flushing of the worker during the suspend flows. It includes (1) closing a race between sending the context- deregistration H2G vs the CTB getting disabled in the midst of it (by detecing the failure and unrolling the guc-lrc-unpin flow) and (2) not infinitely waiting in intel_gt_pm_wait_timeout_for_idle when in the suspend-flow. Alan Previn (3): drm/i915/guc: Flush context destruction worker at suspend drm/i915/guc: Close deregister-context race against CT-loss drm/i915/gt: Timeout when waiting for idle in suspending drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 13 +- drivers/gpu/drm/i915/gt/intel_gt_pm.h | 7 ++- .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 43 +-- .../gpu/drm/i915/gt/uc/intel_guc_submission.h | 2 + drivers/gpu/drm/i915/gt/uc/intel_uc.c | 7 +++ drivers/gpu/drm/i915/gt/uc/intel_uc.h | 1 + drivers/gpu/drm/i915/intel_wakeref.c | 14 -- drivers/gpu/drm/i915/intel_wakeref.h | 5 ++- 9 files changed, 80 insertions(+), 14 deletions(-) base-commit: 20610a111d61d6945d578360942dc5c7bd828eb5 -- 2.39.0
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Determine context valid in OA reports (rev3)
== Series Details == Series: drm/i915/perf: Determine context valid in OA reports (rev3) URL : https://patchwork.freedesktop.org/series/119426/ State : success == Summary == CI Bug Log - changes from CI_DRM_13463 -> Patchwork_119426v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/index.html Participating hosts (42 -> 41) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_119426v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_lmem_swapping@parallel-random-engines: - bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#4613]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-mtlp-8/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@i915_pm_rpm@module-reload: - fi-rkl-11600: [PASS][2] -> [FAIL][3] ([i915#7940]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-rkl-11600/igt@i915_pm_...@module-reload.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/fi-rkl-11600/igt@i915_pm_...@module-reload.html - fi-cfl-8109u: [PASS][4] -> [FAIL][5] ([i915#7940]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_pm_rps@basic-api: - bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#6621]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_mocs: - bat-mtlp-8: NOTRUN -> [DMESG-FAIL][7] ([i915#7059]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][8] -> [ABORT][9] ([i915#4983] / [i915#7461] / [i915#8347] / [i915#8384]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rpls-1/igt@i915_selftest@l...@reset.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-rpls-1/igt@i915_selftest@l...@reset.html - bat-rpls-2: [PASS][10] -> [ABORT][11] ([i915#4983] / [i915#7461] / [i915#7913] / [i915#7981] / [i915#8347]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rpls-2/igt@i915_selftest@l...@reset.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@i915_selftest@live@slpc: - bat-mtlp-8: NOTRUN -> [DMESG-WARN][12] ([i915#6367]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-mtlp-8/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#6645]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#7828]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@prime_vgem@basic-fence-read: - bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#3708]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-mtlp-8/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-gtt: - bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#3708] / [i915#4077]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-mtlp-8/igt@prime_v...@basic-gtt.html Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - bat-mtlp-8: [ABORT][17] ([i915#7077] / [i915#7977] / [i915#8668]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_pm_rpm@basic-rte: - fi-kbl-x1275: [FAIL][19] ([i915#7940]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-kbl-x1275/igt@i915_pm_...@basic-rte.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/fi-kbl-x1275/igt@i915_pm_...@basic-rte.html - fi-kbl-7567u: [FAIL][21] ([i915#7940]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_119426v3/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][23] ([i915#5334]) -> [PASS][24] [23]: https://
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/1] drm/i915/pxp/mtl: intel_pxp_init_hw needs runtime-pm inside pm-complete
== Series Details == Series: series starting with [v2,1/1] drm/i915/pxp/mtl: intel_pxp_init_hw needs runtime-pm inside pm-complete URL : https://patchwork.freedesktop.org/series/121905/ State : success == Summary == CI Bug Log - changes from CI_DRM_13463 -> Patchwork_121905v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/index.html Participating hosts (42 -> 41) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_121905v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-2: [PASS][1] -> [ABORT][2] ([i915#6687] / [i915#7978] / [i915#8668]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rpm@module-reload: - fi-cfl-8109u: [PASS][3] -> [FAIL][4] ([i915#7940]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html - fi-tgl-1115g4: [PASS][5] -> [FAIL][6] ([i915#7940]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/fi-tgl-1115g4/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gem_contexts: - bat-atsm-1: [PASS][7] -> [INCOMPLETE][8] ([i915#7913]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/bat-atsm-1/igt@i915_selftest@live@gem_contexts.html * igt@i915_selftest@live@gt_mocs: - bat-mtlp-6: [PASS][9] -> [DMESG-FAIL][10] ([i915#7059]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/bat-mtlp-6/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][11] -> [DMESG-WARN][12] ([i915#7699]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-dg2-11/igt@i915_selftest@l...@migrate.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1: - bat-rplp-1: [PASS][13] -> [ABORT][14] ([i915#8442] / [i915#8668]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html Possible fixes * igt@i915_pm_rpm@basic-rte: - fi-kbl-x1275: [FAIL][15] ([i915#7940]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-kbl-x1275/igt@i915_pm_...@basic-rte.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/fi-kbl-x1275/igt@i915_pm_...@basic-rte.html - fi-kbl-7567u: [FAIL][17] ([i915#7940]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/fi-kbl-7567u/igt@i915_pm_...@basic-rte.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][19] ([i915#5334]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html - fi-kbl-soraka: [DMESG-FAIL][21] ([i915#5334] / [i915#7872]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@guc: - bat-rpls-1: [DMESG-WARN][23] ([i915#7852]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rpls-1/igt@i915_selftest@l...@guc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121905v1/bat-rpls-1/igt@i915_selftest@l...@guc.html * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-WARN][25] ([i915#6367]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rpls-2/igt@i915_self
Re: [Intel-gfx] [PATCH 1/4] drm/i915/cx0: Add intel_cx0_get_owned_lane_mask()
On Tue, 2023-07-25 at 18:27 -0300, Gustavo Sousa wrote:
> There are more parts of C10/C20 programming that need to take owned
> lanes into account. Define the function intel_cx0_get_owned_lane_mask()
> and use it. There will be new users of that function in upcoming
> changes.
>
> BSpec: 64539
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 44
> 1 file changed, 27 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 1b00ef2c6185..b903ceb0b56a 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -46,6 +46,22 @@ static int lane_mask_to_lane(u8 lane_mask)
> return ilog2(lane_mask);
> }
>
> +static u8 intel_cx0_get_owned_lane_mask(struct drm_i915_private *i915,
> + struct intel_encoder *encoder)
> +{
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> +
> + if (!intel_tc_port_in_dp_alt_mode(dig_port))
> + return INTEL_CX0_BOTH_LANES;
> +
> + /*
> + * In DP-alt with pin assignment D, only PHY lane 0 is owned
> + * by display and lane 1 is owned by USB.
> + */
lane_revesal is not being handled here. Do we need to take lane_reversal into
account
with Pin assignment D is being used?
-Clint
> + return intel_tc_port_fia_max_lane_count(dig_port) > 2
> + ? INTEL_CX0_BOTH_LANES : INTEL_CX0_LANE0;
> +}
> +
> static void
> assert_dc_off(struct drm_i915_private *i915)
> {
> @@ -2534,17 +2550,15 @@ static void intel_cx0_phy_lane_reset(struct
> drm_i915_private
> *i915,
> {
> enum port port = encoder->port;
> enum phy phy = intel_port_to_phy(i915, port);
> - bool both_lanes =
> intel_tc_port_fia_max_lane_count(enc_to_dig_port(encoder)) > 2;
> - u8 lane_mask = lane_reversal ? INTEL_CX0_LANE1 :
> - INTEL_CX0_LANE0;
> - u32 lane_pipe_reset = both_lanes ?
> - XELPDP_LANE_PIPE_RESET(0) |
> - XELPDP_LANE_PIPE_RESET(1) :
> - XELPDP_LANE_PIPE_RESET(0);
> - u32 lane_phy_current_status = both_lanes ?
> - XELPDP_LANE_PHY_CURRENT_STATUS(0) |
> - XELPDP_LANE_PHY_CURRENT_STATUS(1) :
> - XELPDP_LANE_PHY_CURRENT_STATUS(0);
> + u8 owned_lane_mask = intel_cx0_get_owned_lane_mask(i915, encoder);
> + u8 lane_mask = lane_reversal ? INTEL_CX0_LANE1 : INTEL_CX0_LANE0;
> + u32 lane_pipe_reset = owned_lane_mask == INTEL_CX0_BOTH_LANES
> + ? XELPDP_LANE_PIPE_RESET(0) |
> XELPDP_LANE_PIPE_RESET(1)
> + : XELPDP_LANE_PIPE_RESET(0);
> + u32 lane_phy_current_status = owned_lane_mask == INTEL_CX0_BOTH_LANES
> + ? (XELPDP_LANE_PHY_CURRENT_STATUS(0) |
> +XELPDP_LANE_PHY_CURRENT_STATUS(1))
> + : XELPDP_LANE_PHY_CURRENT_STATUS(0);
>
> if (__intel_de_wait_for_register(i915, XELPDP_PORT_BUF_CTL1(port),
>XELPDP_PORT_BUF_SOC_PHY_READY,
> @@ -2564,15 +2578,11 @@ static void intel_cx0_phy_lane_reset(struct
> drm_i915_private
> *i915,
>phy_name(phy), XELPDP_PORT_RESET_START_TIMEOUT_US);
>
> intel_de_rmw(i915, XELPDP_PORT_CLOCK_CTL(port),
> - intel_cx0_get_pclk_refclk_request(both_lanes ?
> -INTEL_CX0_BOTH_LANES :
> -INTEL_CX0_LANE0),
> + intel_cx0_get_pclk_refclk_request(owned_lane_mask),
>intel_cx0_get_pclk_refclk_request(lane_mask));
>
> if (__intel_de_wait_for_register(i915, XELPDP_PORT_CLOCK_CTL(port),
> -
> intel_cx0_get_pclk_refclk_ack(both_lanes ?
> -
> INTEL_CX0_BOTH_LANE
> S :
> -
> INTEL_CX0_LANE0),
> +
> intel_cx0_get_pclk_refclk_ack(owned_lane_mask),
>
> intel_cx0_get_pclk_refclk_ack(lane_mask),
>XELPDP_REFCLK_ENABLE_TIMEOUT_US, 0,
> NULL))
> drm_warn(&i915->drm, "PHY %c failed to request refclk after
> %dus.\n",
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Fix potential null pointer deref in GuC 'steal id' test
== Series Details == Series: drm/i915/guc: Fix potential null pointer deref in GuC 'steal id' test URL : https://patchwork.freedesktop.org/series/121903/ State : success == Summary == CI Bug Log - changes from CI_DRM_13463 -> Patchwork_121903v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/index.html Participating hosts (42 -> 40) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_121903v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-11:NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-mtlp-8: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - bat-adlp-11:NOTRUN -> [SKIP][3] ([i915#3282]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-adlp-11/igt@gem_tiled_pread_basic.html * igt@i915_pm_rpm@module-reload: - fi-rkl-11600: [PASS][4] -> [FAIL][5] ([i915#7940]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-rkl-11600/igt@i915_pm_...@module-reload.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/fi-rkl-11600/igt@i915_pm_...@module-reload.html - fi-cfl-8109u: [PASS][6] -> [FAIL][7] ([i915#7940]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_pm_rps@basic-api: - bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#6621]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_mocs: - bat-mtlp-8: NOTRUN -> [DMESG-FAIL][9] ([i915#7059]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@migrate: - bat-mtlp-8: NOTRUN -> [DMESG-FAIL][10] ([i915#7699]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@requests: - bat-mtlp-8: NOTRUN -> [DMESG-FAIL][11] ([i915#8497]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@slpc: - bat-mtlp-8: NOTRUN -> [DMESG-WARN][12] ([i915#6367]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@i915_selftest@l...@slpc.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][13] ([i915#6645]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@invalid-set-prop-any: - bat-adlp-11:NOTRUN -> [ABORT][14] ([i915#4423]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-adlp-11/igt@kms_addfb_ba...@invalid-set-prop-any.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-mtlp-8: NOTRUN -> [SKIP][15] ([i915#7828]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@prime_vgem@basic-fence-read: - bat-mtlp-8: NOTRUN -> [SKIP][16] ([i915#3708]) +2 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-gtt: - bat-mtlp-8: NOTRUN -> [SKIP][17] ([i915#3708] / [i915#4077]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-mtlp-8/igt@prime_v...@basic-gtt.html Possible fixes * igt@core_auth@basic-auth: - bat-adlp-11:[ABORT][18] ([i915#8011]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-adlp-11/igt@core_a...@basic-auth.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-adlp-11/igt@core_a...@basic-auth.html * igt@i915_module_load@load: - bat-adlp-11:[DMESG-WARN][20] ([i915#4423]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-adlp-11/igt@i915_module_l...@load.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121903v1/bat-adlp-11/igt@i915_module_l...@load.html * igt@i915_pm_rpm@basic-pci-d3-state: - bat-mtlp-8:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/1] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS
== Series Details == Series: series starting with [v4,1/1] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS URL : https://patchwork.freedesktop.org/series/121899/ State : success == Summary == CI Bug Log - changes from CI_DRM_13463 -> Patchwork_121899v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/index.html Participating hosts (42 -> 40) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_121899v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - fi-rkl-11600: [PASS][1] -> [FAIL][2] ([fdo#103375]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-8/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@i915_pm_rpm@basic-rte: - fi-tgl-1115g4: [PASS][4] -> [FAIL][5] ([i915#7940]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/fi-tgl-1115g4/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-rkl-11600: [PASS][6] -> [FAIL][7] ([i915#7940]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-rkl-11600/igt@i915_pm_...@module-reload.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/fi-rkl-11600/igt@i915_pm_...@module-reload.html - fi-cfl-8109u: [PASS][8] -> [FAIL][9] ([i915#7940]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_pm_rps@basic-api: - bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#6621]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_mocs: - bat-mtlp-8: NOTRUN -> [DMESG-FAIL][11] ([i915#7059]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@requests: - bat-mtlp-8: NOTRUN -> [DMESG-FAIL][12] ([i915#8497]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@reset: - bat-rpls-2: [PASS][13] -> [ABORT][14] ([i915#4983] / [i915#7461] / [i915#7913] / [i915#8347]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-rpls-2/igt@i915_selftest@l...@reset.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@i915_selftest@live@slpc: - bat-mtlp-8: NOTRUN -> [DMESG-WARN][15] ([i915#6367]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-8/igt@i915_selftest@l...@slpc.html * igt@i915_selftest@live@workarounds: - bat-mtlp-6: [PASS][16] -> [DMESG-FAIL][17] ([i915#6763]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13463/bat-mtlp-6/igt@i915_selftest@l...@workarounds.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-6/igt@i915_selftest@l...@workarounds.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][18] ([i915#6645]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-mtlp-8: NOTRUN -> [SKIP][19] ([i915#7828]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-8/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@prime_vgem@basic-fence-read: - bat-mtlp-8: NOTRUN -> [SKIP][20] ([i915#3708]) +2 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-8/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-gtt: - bat-mtlp-8: NOTRUN -> [SKIP][21] ([i915#3708] / [i915#4077]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121899v1/bat-mtlp-8/igt@prime_v...@basic-gtt.html Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - bat-mtlp-8: [ABORT][22] ([i915#7077] / [i915#7977] / [i915#8668]) -> [PASS][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/C
[Intel-gfx] [PATCH] drm/i915/perf: Determine context valid in OA reports
When supporting OA for TGL, it was seen that the context valid bit in
the report ID was not defined, however revisiting the spec seems to have
this bit defined. The bit is used to determine if a context is valid on
a context switch and is essential to determine active and idle periods
for a context. Re-enable the context valid bit for gen12 platforms.
BSpec: 52196 (description of report_id)
v2: Include BSpec reference (Ashutosh)
Fixes: 00a7f0d7155c ("drm/i915/tgl: Add perf support on TGL")
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 04bc1f4a1115..59e1e21df271 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -482,8 +482,7 @@ static void oa_report_id_clear(struct i915_perf_stream
*stream, u32 *report)
static bool oa_report_ctx_invalid(struct i915_perf_stream *stream, void
*report)
{
return !(oa_report_id(stream, report) &
- stream->perf->gen8_valid_ctx_bit) &&
- GRAPHICS_VER(stream->perf->i915) <= 11;
+ stream->perf->gen8_valid_ctx_bit);
}
static u64 oa_timestamp(struct i915_perf_stream *stream, void *report)
@@ -5106,6 +5105,7 @@ static void i915_perf_init_info(struct drm_i915_private
*i915)
perf->gen8_valid_ctx_bit = BIT(16);
break;
case 12:
+ perf->gen8_valid_ctx_bit = BIT(16);
/*
* Calculate offset at runtime in oa_pin_context for gen12 and
* cache the value in perf->ctx_oactxctrl_offset.
--
2.36.1
Re: [Intel-gfx] [PATCH 3/4] drm/uapi: document the USB subconnector type
2 августа 2023 г. 22:13:51 GMT+03:00, Laurent Pinchart
пишет:
>On Wed, Aug 02, 2023 at 10:01:19PM +0300, Dmitry Baryshkov wrote:
>> On 02/08/2023 21:55, Laurent Pinchart wrote:
>> > Hi Dmitry,
>> >
>> > Thank you for the patch.
>> >
>> > On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote:
>> >> To properly define the USB-C DP altmode connectors, add the USB
>> >> subconnector type.
>> >>
>> >> Suggested-by: Simon Ser
>> >> Signed-off-by: Dmitry Baryshkov
>> >> ---
>> >> drivers/gpu/drm/drm_connector.c | 1 +
>> >> include/uapi/drm/drm_mode.h | 1 +
>> >> 2 files changed, 2 insertions(+)
>> >>
>> >> diff --git a/drivers/gpu/drm/drm_connector.c
>> >> b/drivers/gpu/drm/drm_connector.c
>> >> index a6066e4a5e9a..9e96b038f5d0 100644
>> >> --- a/drivers/gpu/drm/drm_connector.c
>> >> +++ b/drivers/gpu/drm/drm_connector.c
>> >> @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list
>> >> drm_dp_subconnector_enum_list[] = {
>> >> { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
>> >> { DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
>> >> { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
>> >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
>> >
>> > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
>> > another USB type later ?
>>
>> Hmm, which id should I use for micro-USB then? (consider anx7808,
>> SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of
>> them. But maybe I should add another subtype for SlimPort.
>
>I suppose it depends on whether userspace needs a way to differentiate
>those. Do you have a good visibility on the userspace use cases ?
No. I'm not even sure, which userspace handles subtypes properly.
For the reference, SlimPort is mostly legacy hardware, think about Nexus 4, 5,
6, 7 (2013)
>
>> >> };
>> >>
>> >> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
>> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>> >> index 92d96a2b6763..0f74918b011c 100644
>> >> --- a/include/uapi/drm/drm_mode.h
>> >> +++ b/include/uapi/drm/drm_mode.h
>> >> @@ -398,6 +398,7 @@ enum drm_mode_subconnector {
>> >> DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
>> >> DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
>> >> DRM_MODE_SUBCONNECTOR_Wireless= 18, /*DP */
>> >> + DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
>> >> };
>> >>
>> >> #define DRM_MODE_CONNECTOR_Unknown 0
>
Re: [Intel-gfx] [PATCH 3/4] drm/uapi: document the USB subconnector type
On Wed, Aug 02, 2023 at 10:01:19PM +0300, Dmitry Baryshkov wrote:
> On 02/08/2023 21:55, Laurent Pinchart wrote:
> > Hi Dmitry,
> >
> > Thank you for the patch.
> >
> > On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote:
> >> To properly define the USB-C DP altmode connectors, add the USB
> >> subconnector type.
> >>
> >> Suggested-by: Simon Ser
> >> Signed-off-by: Dmitry Baryshkov
> >> ---
> >> drivers/gpu/drm/drm_connector.c | 1 +
> >> include/uapi/drm/drm_mode.h | 1 +
> >> 2 files changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_connector.c
> >> b/drivers/gpu/drm/drm_connector.c
> >> index a6066e4a5e9a..9e96b038f5d0 100644
> >> --- a/drivers/gpu/drm/drm_connector.c
> >> +++ b/drivers/gpu/drm/drm_connector.c
> >> @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list
> >> drm_dp_subconnector_enum_list[] = {
> >>{ DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
> >>{ DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
> >>{ DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> >> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
> >
> > Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
> > another USB type later ?
>
> Hmm, which id should I use for micro-USB then? (consider anx7808,
> SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of
> them. But maybe I should add another subtype for SlimPort.
I suppose it depends on whether userspace needs a way to differentiate
those. Do you have a good visibility on the userspace use cases ?
> >> };
> >>
> >> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
> >> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> >> index 92d96a2b6763..0f74918b011c 100644
> >> --- a/include/uapi/drm/drm_mode.h
> >> +++ b/include/uapi/drm/drm_mode.h
> >> @@ -398,6 +398,7 @@ enum drm_mode_subconnector {
> >>DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
> >>DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
> >>DRM_MODE_SUBCONNECTOR_Wireless= 18, /*DP */
> >> + DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
> >> };
> >>
> >> #define DRM_MODE_CONNECTOR_Unknown 0
--
Regards,
Laurent Pinchart
[Intel-gfx] [PATCH v2 1/1] drm/i915/pxp/mtl: intel_pxp_init_hw needs runtime-pm inside pm-complete
In the case of failed suspend flow or cases where the kernel does not go
into full suspend but goes from suspend_prepare back to resume_complete,
we get called for a pm_complete but without runtime_pm guaranteed.
Thus, ensure we take the runtime_pm when calling intel_pxp_init_hw
from within intel_pxp_resume_complete.
v2: resume_complete and runtime_resume should abstract a common
helper with different wakeref requirements. (Daniele)
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 18 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.h | 5 +++--
2 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 1a04067f61fc..6dfd24918953 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -34,8 +34,10 @@ void intel_pxp_suspend(struct intel_pxp *pxp)
}
}
-void intel_pxp_resume_complete(struct intel_pxp *pxp)
+static void _pxp_resume(struct intel_pxp *pxp, bool take_wakeref)
{
+ intel_wakeref_t wakeref;
+
if (!intel_pxp_is_enabled(pxp))
return;
@@ -48,7 +50,21 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
+ if (take_wakeref)
+ wakeref = intel_runtime_pm_get(&pxp->ctrl_gt->i915->runtime_pm);
intel_pxp_init_hw(pxp);
+ if (take_wakeref)
+ intel_runtime_pm_put(&pxp->ctrl_gt->i915->runtime_pm, wakeref);
+}
+
+void intel_pxp_resume_complete(struct intel_pxp *pxp)
+{
+ _pxp_resume(pxp, true);
+}
+
+void intel_pxp_runtime_resume(struct intel_pxp *pxp)
+{
+ _pxp_resume(pxp, false);
}
void intel_pxp_runtime_suspend(struct intel_pxp *pxp)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
index 06b46f535b42..8695889b8380 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.h
@@ -13,6 +13,7 @@ void intel_pxp_suspend_prepare(struct intel_pxp *pxp);
void intel_pxp_suspend(struct intel_pxp *pxp);
void intel_pxp_resume_complete(struct intel_pxp *pxp);
void intel_pxp_runtime_suspend(struct intel_pxp *pxp);
+void intel_pxp_runtime_resume(struct intel_pxp *pxp);
#else
static inline void intel_pxp_suspend_prepare(struct intel_pxp *pxp)
{
@@ -29,9 +30,9 @@ static inline void intel_pxp_resume_complete(struct intel_pxp
*pxp)
static inline void intel_pxp_runtime_suspend(struct intel_pxp *pxp)
{
}
-#endif
+
static inline void intel_pxp_runtime_resume(struct intel_pxp *pxp)
{
- intel_pxp_resume_complete(pxp);
}
+#endif
#endif /* __INTEL_PXP_PM_H__ */
base-commit: d7a437067a2146e1035a5609dae08b9595773a16
--
2.39.0
Re: [Intel-gfx] [PATCH 1/4] drm: allow specifying default subtype for the DP subconnector property
On 02/08/2023 21:54, Laurent Pinchart wrote:
Hi Dmitry,
Thank you for the patch.
On Sat, Jul 29, 2023 at 03:49:10AM +0300, Dmitry Baryshkov wrote:
In the embedded usecases the default subtype depends on the bridge
chain, so it is easier to specify the subtype at the proprety attachment
s/proprety/property/
type rather than specifying it later.
Did you mean s/type/time/ ?
I think I understand why you need this, looking at patch 2/4, but the
commit message isn't very clear. It would benefit from being reworded.
Ack, thanks for the feedback.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 3 ++-
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 ++-
drivers/gpu/drm/drm_connector.c | 6 --
drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
include/drm/drm_connector.h | 3 ++-
5 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index d34037b85cf8..c18459ecd4be 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -2022,7 +2022,8 @@ amdgpu_connector_add(struct amdgpu_device *adev,
if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
connector_type == DRM_MODE_CONNECTOR_eDP) {
-
drm_connector_attach_dp_subconnector_property(&amdgpu_connector->base);
+
drm_connector_attach_dp_subconnector_property(&amdgpu_connector->base,
+
DRM_MODE_SUBCONNECTOR_Unknown);
}
return;
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 943959012d04..297321f0199e 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -759,7 +759,8 @@ void amdgpu_dm_initialize_dp_connector(struct
amdgpu_display_manager *dm,
drm_dp_mst_topology_mgr_init(&aconnector->mst_mgr,
adev_to_drm(dm->adev),
&aconnector->dm_dp_aux.aux, 16, 4,
aconnector->connector_id);
- drm_connector_attach_dp_subconnector_property(&aconnector->base);
+ drm_connector_attach_dp_subconnector_property(&aconnector->base,
+
DRM_MODE_SUBCONNECTOR_Unknown);
}
int dm_mst_get_pbn_divider(struct dc_link *link)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a3d3e7dc08b2..a6066e4a5e9a 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1577,10 +1577,12 @@ EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
/**
* drm_connector_attach_dp_subconnector_property - create subconnector
property for DP
* @connector: drm_connector to attach property
+ * @subtype: initial value for the subconnector type
*
* Called by a driver when DP connector is created.
*/
-void drm_connector_attach_dp_subconnector_property(struct drm_connector
*connector)
+void drm_connector_attach_dp_subconnector_property(struct drm_connector
*connector,
+ enum drm_mode_subconnector
subtype)
{
struct drm_mode_config *mode_config = &connector->dev->mode_config;
@@ -1594,7 +1596,7 @@ void drm_connector_attach_dp_subconnector_property(struct drm_connector *connect
drm_object_attach_property(&connector->base,
mode_config->dp_subconnector_property,
- DRM_MODE_SUBCONNECTOR_Unknown);
+ subtype);
}
EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c b/drivers/gpu/drm/i915/display/intel_dp.c
index 474785110662..5819105187f6 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -5391,7 +5391,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp, struct
drm_connector *connect
enum port port = dp_to_dig_port(intel_dp)->base.port;
if (!intel_dp_is_edp(intel_dp))
- drm_connector_attach_dp_subconnector_property(connector);
+ drm_connector_attach_dp_subconnector_property(connector,
+
DRM_MODE_SUBCONNECTOR_Unknown);
if (!IS_G4X(dev_priv) && port != PORT_A)
intel_attach_force_audio_property(connector);
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 5a8115dca359..a130a78f6e0f 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1990,7 +1990,8 @@ const char *drm_get_hdcp_content_type_name(int val);
int drm_get_tv_mode_from_name(const char *na
Re: [Intel-gfx] [PATCH 3/4] drm/uapi: document the USB subconnector type
On 02/08/2023 21:55, Laurent Pinchart wrote:
Hi Dmitry,
Thank you for the patch.
On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote:
To properly define the USB-C DP altmode connectors, add the USB
subconnector type.
Suggested-by: Simon Ser
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_connector.c | 1 +
include/uapi/drm/drm_mode.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index a6066e4a5e9a..9e96b038f5d0 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list
drm_dp_subconnector_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
{ DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
{ DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
+ { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
another USB type later ?
Hmm, which id should I use for micro-USB then? (consider anx7808,
SlimPort). I thought about using DRM_MODE_SUBCONNECTOR_USB for both of
them. But maybe I should add another subtype for SlimPort.
};
DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 92d96a2b6763..0f74918b011c 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -398,6 +398,7 @@ enum drm_mode_subconnector {
DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
DRM_MODE_SUBCONNECTOR_Wireless= 18, /*DP */
+ DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
};
#define DRM_MODE_CONNECTOR_Unknown 0
--
With best wishes
Dmitry
Re: [Intel-gfx] [PATCH 3/4] drm/uapi: document the USB subconnector type
Hi Dmitry,
Thank you for the patch.
On Sat, Jul 29, 2023 at 03:49:12AM +0300, Dmitry Baryshkov wrote:
> To properly define the USB-C DP altmode connectors, add the USB
> subconnector type.
>
> Suggested-by: Simon Ser
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/drm_connector.c | 1 +
> include/uapi/drm/drm_mode.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a6066e4a5e9a..9e96b038f5d0 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1050,6 +1050,7 @@ static const struct drm_prop_enum_list
> drm_dp_subconnector_enum_list[] = {
> { DRM_MODE_SUBCONNECTOR_DisplayPort, "DP"}, /* DP */
> { DRM_MODE_SUBCONNECTOR_Wireless,"Wireless" }, /* DP */
> { DRM_MODE_SUBCONNECTOR_Native, "Native"}, /* DP */
> + { DRM_MODE_SUBCONNECTOR_USB, "USB" }, /* DP */
Should this be DRM_MODE_SUBCONNECTOR_USB_C and "USB-C", in case we get
another USB type later ?
> };
>
> DRM_ENUM_NAME_FN(drm_get_dp_subconnector_name,
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 92d96a2b6763..0f74918b011c 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -398,6 +398,7 @@ enum drm_mode_subconnector {
> DRM_MODE_SUBCONNECTOR_HDMIA = 11, /*DP */
> DRM_MODE_SUBCONNECTOR_Native = 15, /*DP */
> DRM_MODE_SUBCONNECTOR_Wireless= 18, /*DP */
> + DRM_MODE_SUBCONNECTOR_USB = 20, /*DP */
> };
>
> #define DRM_MODE_CONNECTOR_Unknown 0
--
Regards,
Laurent Pinchart
Re: [Intel-gfx] [PATCH 1/4] drm: allow specifying default subtype for the DP subconnector property
Hi Dmitry,
Thank you for the patch.
On Sat, Jul 29, 2023 at 03:49:10AM +0300, Dmitry Baryshkov wrote:
> In the embedded usecases the default subtype depends on the bridge
> chain, so it is easier to specify the subtype at the proprety attachment
s/proprety/property/
> type rather than specifying it later.
Did you mean s/type/time/ ?
I think I understand why you need this, looking at patch 2/4, but the
commit message isn't very clear. It would benefit from being reworded.
> Signed-off-by: Dmitry Baryshkov
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 3 ++-
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c | 3 ++-
> drivers/gpu/drm/drm_connector.c | 6 --
> drivers/gpu/drm/i915/display/intel_dp.c | 3 ++-
> include/drm/drm_connector.h | 3 ++-
> 5 files changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index d34037b85cf8..c18459ecd4be 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -2022,7 +2022,8 @@ amdgpu_connector_add(struct amdgpu_device *adev,
>
> if (connector_type == DRM_MODE_CONNECTOR_DisplayPort ||
> connector_type == DRM_MODE_CONNECTOR_eDP) {
> -
> drm_connector_attach_dp_subconnector_property(&amdgpu_connector->base);
> +
> drm_connector_attach_dp_subconnector_property(&amdgpu_connector->base,
> +
> DRM_MODE_SUBCONNECTOR_Unknown);
> }
>
> return;
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> index 943959012d04..297321f0199e 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
> @@ -759,7 +759,8 @@ void amdgpu_dm_initialize_dp_connector(struct
> amdgpu_display_manager *dm,
> drm_dp_mst_topology_mgr_init(&aconnector->mst_mgr,
> adev_to_drm(dm->adev),
>&aconnector->dm_dp_aux.aux, 16, 4,
> aconnector->connector_id);
>
> - drm_connector_attach_dp_subconnector_property(&aconnector->base);
> + drm_connector_attach_dp_subconnector_property(&aconnector->base,
> +
> DRM_MODE_SUBCONNECTOR_Unknown);
> }
>
> int dm_mst_get_pbn_divider(struct dc_link *link)
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index a3d3e7dc08b2..a6066e4a5e9a 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1577,10 +1577,12 @@ EXPORT_SYMBOL(drm_mode_create_dvi_i_properties);
> /**
> * drm_connector_attach_dp_subconnector_property - create subconnector
> property for DP
> * @connector: drm_connector to attach property
> + * @subtype: initial value for the subconnector type
> *
> * Called by a driver when DP connector is created.
> */
> -void drm_connector_attach_dp_subconnector_property(struct drm_connector
> *connector)
> +void drm_connector_attach_dp_subconnector_property(struct drm_connector
> *connector,
> +enum drm_mode_subconnector
> subtype)
> {
> struct drm_mode_config *mode_config = &connector->dev->mode_config;
>
> @@ -1594,7 +1596,7 @@ void
> drm_connector_attach_dp_subconnector_property(struct drm_connector *connect
>
> drm_object_attach_property(&connector->base,
> mode_config->dp_subconnector_property,
> -DRM_MODE_SUBCONNECTOR_Unknown);
> +subtype);
> }
> EXPORT_SYMBOL(drm_connector_attach_dp_subconnector_property);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 474785110662..5819105187f6 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5391,7 +5391,8 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
> enum port port = dp_to_dig_port(intel_dp)->base.port;
>
> if (!intel_dp_is_edp(intel_dp))
> - drm_connector_attach_dp_subconnector_property(connector);
> + drm_connector_attach_dp_subconnector_property(connector,
> +
> DRM_MODE_SUBCONNECTOR_Unknown);
>
> if (!IS_G4X(dev_priv) && port != PORT_A)
> intel_attach_force_audio_property(connector);
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 5a8115dca359..a130a78f6e0f 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -1990,7 +1990,8 @@ const char *drm_get_hdcp_conte
Re: [Intel-gfx] [PATCH 2/4] drm/bridge-connector: handle subconnector types
On 02/08/2023 21:46, Laurent Pinchart wrote:
On Wed, Aug 02, 2023 at 12:05:50PM +0300, Dmitry Baryshkov wrote:
On Wed, 2 Aug 2023 at 11:35, Neil Armstrong wrote:
On 29/07/2023 02:49, Dmitry Baryshkov wrote:
If the created connector type supports subconnector type property,
create and attach corresponding it. The default subtype value is 0,
which maps to the DRM_MODE_SUBCONNECTOR_Unknown type.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 33 +-
include/drm/drm_bridge.h | 4
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index 07b5930b1282..a7b92f0d2430 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -329,7 +329,9 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
struct drm_connector *connector;
struct i2c_adapter *ddc = NULL;
struct drm_bridge *bridge, *panel_bridge = NULL;
+ enum drm_mode_subconnector subconnector;
int connector_type;
+ int ret;
bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
if (!bridge_connector)
@@ -365,8 +367,10 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
if (bridge->ops & DRM_BRIDGE_OP_MODES)
bridge_connector->bridge_modes = bridge;
- if (!drm_bridge_get_next_bridge(bridge))
+ if (!drm_bridge_get_next_bridge(bridge)) {
connector_type = bridge->type;
+ subconnector = bridge->subtype;
+ }
#ifdef CONFIG_OF
if (!drm_bridge_get_next_bridge(bridge) &&
@@ -399,6 +403,33 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
if (panel_bridge)
drm_panel_bridge_set_orientation(connector, panel_bridge);
+ if (connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ drm_connector_attach_dp_subconnector_property(connector,
subconnector);
+ } else if (connector_type == DRM_MODE_CONNECTOR_DVII) {
+ ret = drm_mode_create_dvi_i_properties(drm);
+ if (ret)
+ return ERR_PTR(ret);
+
+ drm_object_attach_property(&connector->base,
+
drm->mode_config.dvi_i_subconnector_property,
+subconnector);
+ } else if (connector_type == DRM_MODE_CONNECTOR_TV) {
+ ret = drm_mode_create_tv_properties(drm,
+ BIT(DRM_MODE_TV_MODE_NTSC) |
+
BIT(DRM_MODE_TV_MODE_NTSC_443) |
+ BIT(DRM_MODE_TV_MODE_NTSC_J) |
+ BIT(DRM_MODE_TV_MODE_PAL) |
+ BIT(DRM_MODE_TV_MODE_PAL_M) |
+ BIT(DRM_MODE_TV_MODE_PAL_N) |
+ BIT(DRM_MODE_TV_MODE_SECAM));
+ if (ret)
+ return ERR_PTR(ret);
I don't think this is right, this should be called from the appropriate encoder
device depending on the analog tv mode capabilities.
Good question. My logic was the following: the DRM device can have
different TV out ports with different capabilities (yeah, pure
theoretical construct). In this case it might be impossible to create
a single subset of values. Thus it is more correct to create the
property listing all possible values. The property is immutable anyway
(and so the user doesn't have control over the value).
Those ports would correspond to different connectors, so I agree with
Neil, I don't think it's right to create a single property with all
modes and attach it to all analog output connectors.
I agree that this case is mishandled currently (as current design
assumes a single property that fits for the complete device).
If you want to support multiple analog outputs that have different
capabilities, this will need changes to drm_mode_create_tv_properties()
to allow creating multiple properties. If you don't want to do so now,
and prefer limiting support to devices where all ports support the same
modes (which includes devices with a single analog output), then the
modes should reflect what the device supports.
Ack, I'll drop the create call and check for the property existence
before attaching it.
+
+ drm_object_attach_property(&connector->base,
+
drm->mode_config.tv_subconnector_property,
+subconnector);
Here, only add the property if drm->mode_config.tv_subconnector_property exists,
and perhaps add a warning if not.
This property is created in the previous call,
drm_mode_c
[Intel-gfx] [PATCH] drm/i915/guc: Fix potential null pointer deref in GuC 'steal id' test
From: John Harrison
It was noticed that if the very first 'stealing' request failed to
create for some reason then the 'steal all ids' loop would immediately
exit with 'last' still being NULL. The test would attempt to continue
but using a null pointer. Fix that by aborting the test if it fails to
create any requests at all.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/selftest_guc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
index 1fd760539f77b..bfb72143566f6 100644
--- a/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/selftest_guc.c
@@ -204,9 +204,9 @@ static int intel_guc_steal_guc_ids(void *arg)
if (IS_ERR(rq)) {
ret = PTR_ERR(rq);
rq = NULL;
- if (ret != -EAGAIN) {
- guc_err(guc, "Failed to create request %d:
%pe\n",
- context_index, ERR_PTR(ret));
+ if ((ret != -EAGAIN) || !last) {
+ guc_err(guc, "Failed to create %srequest %d:
%pe\n",
+ last ? "" : "first ", context_index,
ERR_PTR(ret));
goto err_spin_rq;
}
} else {
--
2.39.1
Re: [Intel-gfx] [PATCH 2/4] drm/bridge-connector: handle subconnector types
On Wed, Aug 02, 2023 at 12:05:50PM +0300, Dmitry Baryshkov wrote:
> On Wed, 2 Aug 2023 at 11:35, Neil Armstrong wrote:
> > On 29/07/2023 02:49, Dmitry Baryshkov wrote:
> > > If the created connector type supports subconnector type property,
> > > create and attach corresponding it. The default subtype value is 0,
> > > which maps to the DRM_MODE_SUBCONNECTOR_Unknown type.
> > >
> > > Signed-off-by: Dmitry Baryshkov
> > > ---
> > > drivers/gpu/drm/drm_bridge_connector.c | 33 +-
> > > include/drm/drm_bridge.h | 4
> > > 2 files changed, 36 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> > > b/drivers/gpu/drm/drm_bridge_connector.c
> > > index 07b5930b1282..a7b92f0d2430 100644
> > > --- a/drivers/gpu/drm/drm_bridge_connector.c
> > > +++ b/drivers/gpu/drm/drm_bridge_connector.c
> > > @@ -329,7 +329,9 @@ struct drm_connector
> > > *drm_bridge_connector_init(struct drm_device *drm,
> > > struct drm_connector *connector;
> > > struct i2c_adapter *ddc = NULL;
> > > struct drm_bridge *bridge, *panel_bridge = NULL;
> > > + enum drm_mode_subconnector subconnector;
> > > int connector_type;
> > > + int ret;
> > >
> > > bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
> > > if (!bridge_connector)
> > > @@ -365,8 +367,10 @@ struct drm_connector
> > > *drm_bridge_connector_init(struct drm_device *drm,
> > > if (bridge->ops & DRM_BRIDGE_OP_MODES)
> > > bridge_connector->bridge_modes = bridge;
> > >
> > > - if (!drm_bridge_get_next_bridge(bridge))
> > > + if (!drm_bridge_get_next_bridge(bridge)) {
> > > connector_type = bridge->type;
> > > + subconnector = bridge->subtype;
> > > + }
> > >
> > > #ifdef CONFIG_OF
> > > if (!drm_bridge_get_next_bridge(bridge) &&
> > > @@ -399,6 +403,33 @@ struct drm_connector
> > > *drm_bridge_connector_init(struct drm_device *drm,
> > > if (panel_bridge)
> > > drm_panel_bridge_set_orientation(connector, panel_bridge);
> > >
> > > + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> > > + drm_connector_attach_dp_subconnector_property(connector,
> > > subconnector);
> > > + } else if (connector_type == DRM_MODE_CONNECTOR_DVII) {
> > > + ret = drm_mode_create_dvi_i_properties(drm);
> > > + if (ret)
> > > + return ERR_PTR(ret);
> > > +
> > > + drm_object_attach_property(&connector->base,
> > > +
> > > drm->mode_config.dvi_i_subconnector_property,
> > > +subconnector);
> > > + } else if (connector_type == DRM_MODE_CONNECTOR_TV) {
> > > + ret = drm_mode_create_tv_properties(drm,
> > > +
> > > BIT(DRM_MODE_TV_MODE_NTSC) |
> > > +
> > > BIT(DRM_MODE_TV_MODE_NTSC_443) |
> > > +
> > > BIT(DRM_MODE_TV_MODE_NTSC_J) |
> > > +
> > > BIT(DRM_MODE_TV_MODE_PAL) |
> > > +
> > > BIT(DRM_MODE_TV_MODE_PAL_M) |
> > > +
> > > BIT(DRM_MODE_TV_MODE_PAL_N) |
> > > +
> > > BIT(DRM_MODE_TV_MODE_SECAM));
> > > + if (ret)
> > > + return ERR_PTR(ret);
> >
> > I don't think this is right, this should be called from the appropriate
> > encoder
> > device depending on the analog tv mode capabilities.
>
> Good question. My logic was the following: the DRM device can have
> different TV out ports with different capabilities (yeah, pure
> theoretical construct). In this case it might be impossible to create
> a single subset of values. Thus it is more correct to create the
> property listing all possible values. The property is immutable anyway
> (and so the user doesn't have control over the value).
Those ports would correspond to different connectors, so I agree with
Neil, I don't think it's right to create a single property with all
modes and attach it to all analog output connectors.
If you want to support multiple analog outputs that have different
capabilities, this will need changes to drm_mode_create_tv_properties()
to allow creating multiple properties. If you don't want to do so now,
and prefer limiting support to devices where all ports support the same
modes (which includes devices with a single analog output), then the
modes should reflect what the device supports.
> > > +
> > > + drm_object_attach_property(&connector->base,
> > > +
> > > drm->mode_config.tv_subconnector_property,
> > > +
Re: [Intel-gfx] [PATCH] drm/i915/pxp/mtl: intel_pxp_init_hw needs runtime-pm inside pm-complete
> >
> >
alan:snip
Thanks Vinay and Daniele - i'll respin with below fix.
> > @@ -48,7 +50,8 @@ void intel_pxp_resume_complete()
> > if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
> > return;
> >
> > - intel_pxp_init_hw(pxp);
> > + with_intel_runtime_pm(&pxp->ctrl_gt->i915->runtime_pm, wakeref)
>
> This is called from within the rpm resume path, so you can't do an rpm
> get or it will deadlock. Maybe have:
>
> __pxp_resume_complete(struct intel_pxp *pxp, bool needs_rpm);
>
> intel_pxp_resume_complete(..)
> {
> return __pxp_resume_complete(pxp, true);
> }
>
> intel_pxp_runtime_resume(..)
> {
> return __pxp_resume_complete(pxp, false);
> }
>
>
> or something like that.
> Daniele
[Intel-gfx] [PATCH v4 1/1] drm/i915/pxp: Optimize GET_PARAM:PXP_STATUS
After recent discussions with Mesa folks, it was requested
that we optimize i915's GET_PARAM for the PXP_STATUS without
changing the UAPI spec.
Add these additional optimizations:
- If any PXP initializatoin flow failed, then ensure that
we catch it so that we can change the returned PXP_STATUS
from "2" (i.e. 'PXP is supported but not yet ready')
to "-ENODEV". This typically should not happen and if it
does, we have a platform configuration issue.
- If a PXP arbitration session creation event failed
due to incorrect firmware version or blocking SOC fusing
or blocking BIOS configuration (platform reasons that won't
change if we retry), then reflect that blockage by also
returning -ENODEV in the GET_PARAM:PXP_STATUS.
- GET_PARAM:PXP_STATUS should not wait at all if PXP is
supported but non-i915 dependencies (component-driver /
firmware) we are still pending to complete the init flows.
In this case, just return "2" immediately (i.e. 'PXP is
supported but not yet ready').
Difference from prio revs:
v3: - Rebase with latest tip that has pulled in setting the
gsc fw load to fail if proxy init fails.
v2: - Use a #define for the default readiness timeout (Vivaik).
- Improve comments around the failing of proxy-init.
v1: - Change the commit msg style to be imperative. (Jani)
- Rename timeout to timeout_ms. (Jani)
- Fix is_fw_err_platform_config to use higher order
param (pxp) first. (Jani)
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 40 ++
drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 7 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 7 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 9 +
6 files changed, 52 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_getparam.c
b/drivers/gpu/drm/i915/i915_getparam.c
index 890f2b382bee..5c3fec63cb4c 100644
--- a/drivers/gpu/drm/i915/i915_getparam.c
+++ b/drivers/gpu/drm/i915/i915_getparam.c
@@ -109,7 +109,7 @@ int i915_getparam_ioctl(struct drm_device *dev, void *data,
return value;
break;
case I915_PARAM_PXP_STATUS:
- value = intel_pxp_get_readiness_status(i915->pxp);
+ value = intel_pxp_get_readiness_status(i915->pxp, 0);
if (value < 0)
return value;
break;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 38ec754d0ec8..dc327cf40b5a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -359,22 +359,46 @@ void intel_pxp_end(struct intel_pxp *pxp)
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
}
+static bool pxp_required_fw_failed(struct intel_pxp *pxp)
+{
+ if (__intel_uc_fw_status(&pxp->ctrl_gt->uc.huc.fw) ==
INTEL_UC_FIRMWARE_LOAD_FAIL)
+ return true;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0) &&
+ __intel_uc_fw_status(&pxp->ctrl_gt->uc.gsc.fw) ==
INTEL_UC_FIRMWARE_LOAD_FAIL)
+ return true;
+
+ return false;
+}
+
+static bool pxp_fw_dependencies_completed(struct intel_pxp *pxp)
+{
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ return intel_pxp_gsccs_is_ready_for_sessions(pxp);
+
+ return pxp_component_bound(pxp);
+}
+
/*
* this helper is used by both intel_pxp_start and by
* the GET_PARAM IOCTL that user space calls. Thus, the
* return values here should match the UAPI spec.
*/
-int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
+int intel_pxp_get_readiness_status(struct intel_pxp *pxp, int timeout_ms)
{
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
- if (wait_for(intel_pxp_gsccs_is_ready_for_sessions(pxp), 250))
- return 2;
- } else {
- if (wait_for(pxp_component_bound(pxp), 250))
+ if (pxp_required_fw_failed(pxp))
+ return -ENODEV;
+
+ if (pxp->platform_cfg_is_bad)
+ return -ENODEV;
+
+ if (timeout_ms) {
+ if (wait_for(pxp_fw_dependencies_completed(pxp), timeout_ms))
return 2;
+ } else if (!pxp_fw_dependencies_completed(pxp)) {
+ return 2;
}
return 1;
}
@@ -383,11 +407,13 @@ int intel_pxp_get_readiness_status(struct intel_pxp *pxp)
* the arb session is restarted from the irq work when we receive the
* termination completion interrupt
*/
+#define PXP_READINESS_TIMEOUT 250
+
int intel_pxp_start(struct intel_pxp *pxp)
{
int ret = 0;
- ret = intel_pxp_get_readiness_status(pxp);
+ ret = intel_pxp_get_readiness_status(pxp, PXP_READINESS_TIMEOUT);
if (ret < 0)
retur
[Intel-gfx] ✓ Fi.CI.BAT: success for iommu/vt-d: Check domain flags before setting snp bit in page-control
== Series Details == Series: iommu/vt-d: Check domain flags before setting snp bit in page-control URL : https://patchwork.freedesktop.org/series/121893/ State : success == Summary == CI Bug Log - changes from CI_DRM_13462 -> Patchwork_121893v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/index.html Participating hosts (29 -> 41) -- Additional (13): fi-kbl-soraka bat-dg1-5 bat-dg2-13 fi-cfl-8700k fi-ilk-650 fi-hsw-4770 bat-adln-1 fi-kbl-x1275 fi-cfl-8109u fi-elk-e7500 bat-rplp-1 bat-rpls-1 fi-skl-6600u Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_121893v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-rpls-1: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/bat-rpls-1/igt@debugfs_t...@basic-hwmon.html - bat-rplp-1: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/bat-rplp-1/igt@debugfs_t...@basic-hwmon.html - bat-adln-1: NOTRUN -> [SKIP][3] ([i915#7456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/bat-adln-1/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@info: - fi-kbl-x1275: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1849]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-kbl-x1275/igt@fb...@info.html - bat-rpls-1: NOTRUN -> [SKIP][5] ([i915#1849] / [i915#2582]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/bat-rpls-1/igt@fb...@info.html * igt@fbdev@nullptr: - bat-rpls-1: NOTRUN -> [SKIP][6] ([i915#2582]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/bat-rpls-1/igt@fb...@nullptr.html * igt@gem_huc_copy@huc-copy: - fi-cfl-8109u: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-cfl-8109u/igt@gem_huc_c...@huc-copy.html - fi-cfl-8700k: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-cfl-8700k/igt@gem_huc_c...@huc-copy.html - fi-skl-6600u: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-skl-6600u/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html - fi-kbl-x1275: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#2190]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html - fi-cfl-8700k: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-cfl-8700k/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-rpls-1: NOTRUN -> [SKIP][14] ([i915#4613]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/bat-rpls-1/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - fi-skl-6600u: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#4613]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-skl-6600u/igt@gem_lmem_swapp...@random-engines.html * igt@gem_lmem_swapping@verify-random: - fi-kbl-x1275: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-kbl-x1275/igt@gem_lmem_swapp...@verify-random.html - fi-cfl-8109u: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-cfl-8109u/igt@gem_lmem_swapp...@verify-random.html * igt@gem_mmap@basic: - bat-dg1-5: NOTRUN -> [SKIP][18] ([i915#4083]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/bat-dg1-5/igt@gem_m...@basic.html * igt@gem_softpin@allocator-basic-reserve: - fi-hsw-4770:NOTRUN -> [SKIP][19] ([fdo#109271]) +21 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121893v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html * igt@gem_tiled_blits@basic: - bat-dg1-5: NOTRUN -> [SKIP][20] ([i915#4077]) +2 similar iss
[Intel-gfx] [CI] PR for PVC FWs for Xe
The following changes since commit 253cc179d849fc82489773b2b553a49858d8725f: amdgpu: Update DMCUB for DCN314 & Yellow Carp (2023-07-31 11:22:02 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware xe_pvc for you to fetch changes up to 3b72a71413f8ef76c76e1dbff0273ac3b77f68da: xe: add PVC guc 70.6.4 and 70.8.0 (2023-07-31 14:16:51 -0700) Daniele Ceraolo Spurio (1): xe: add PVC guc 70.6.4 and 70.8.0 WHENCE| 11 +++ xe/pvc_guc_70.6.4.bin | Bin 0 -> 525120 bytes xe/pvc_guc_70.bin | Bin 0 -> 533312 bytes 3 files changed, 11 insertions(+) create mode 100644 xe/pvc_guc_70.6.4.bin create mode 100644 xe/pvc_guc_70.bin
[Intel-gfx] [topic/core-for-ci] iommu/vt-d: Check domain flags before setting snp bit in page-control
From: Ashok Raj
Check domain flags before setting snp bit in PTE.
Signed-off-by: Ashok Raj
Signed-off-by: Radhakrishna Sripada
---
drivers/iommu/intel/iommu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iommu/intel/iommu.c b/drivers/iommu/intel/iommu.c
index 5c8c5cdc36cf..71da6f818e96 100644
--- a/drivers/iommu/intel/iommu.c
+++ b/drivers/iommu/intel/iommu.c
@@ -2150,7 +2150,7 @@ __domain_mapping(struct dmar_domain *domain, unsigned
long iov_pfn,
if ((prot & (DMA_PTE_READ|DMA_PTE_WRITE)) == 0)
return -EINVAL;
- attr = prot & (DMA_PTE_READ | DMA_PTE_WRITE | DMA_PTE_SNP);
+ attr = prot & (DMA_PTE_READ | DMA_PTE_WRITE);
attr |= DMA_FL_PTE_PRESENT;
if (domain->use_first_level) {
attr |= DMA_FL_PTE_XD | DMA_FL_PTE_US | DMA_FL_PTE_ACCESS;
--
2.34.1
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi,
On Tue, Aug 1, 2023 at 9:21 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
>
> include/drm/drm_panel.h:270: warning: Function parameter or member
> 'follower_lock' not described in 'drm_panel'
>
> Introduced by commit
>
> de0874165b83 ("drm/panel: Add a way for other devices to follow panel
> state")
Thanks for the report. I've posted:
https://lore.kernel.org/all/20230802074727.1.I4036706ad5e7f45e80d41b777164258e52079cd8@changeid/
To fix this one.
-Doug
Re: [Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi,
On Tue, Aug 1, 2023 at 9:17 PM Stephen Rothwell wrote:
>
> Hi all,
>
> After merging the drm-misc tree, today's linux-next build (htmldocs)
> produced this warning:
>
> Documentation/gpu/todo.rst:469: ERROR: Unexpected indentation.
>
> Introduced by commit
>
> d2aacaf07395 ("drm/panel: Check for already prepared/enabled in drm_panel")
Thanks for the report. I've posted:
https://lore.kernel.org/all/20230802074727.2.Iaeb7b0f7951aee6b8c090364bbc87b1ae198a857@changeid/
To fix this one.
-Doug
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/modes: Fix division by zero error
== Series Details == Series: drm/modes: Fix division by zero error URL : https://patchwork.freedesktop.org/series/121879/ State : success == Summary == CI Bug Log - changes from CI_DRM_13460 -> Patchwork_121879v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/index.html Participating hosts (42 -> 41) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_121879v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-rte: - fi-cfl-8109u: [PASS][1] -> [FAIL][2] ([i915#7940]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/fi-cfl-8109u/igt@i915_pm_...@basic-rte.html * igt@i915_pm_rpm@module-reload: - fi-rkl-11600: [PASS][3] -> [FAIL][4] ([i915#7940]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/fi-rkl-11600/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/fi-rkl-11600/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334] / [i915#7872]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_mocs: - bat-mtlp-8: [PASS][7] -> [DMESG-FAIL][8] ([i915#7059]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/bat-mtlp-8/igt@i915_selftest@live@gt_mocs.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][9] -> [DMESG-WARN][10] ([i915#7699]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/bat-dg2-11/igt@i915_selftest@l...@migrate.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@requests: - bat-mtlp-8: [PASS][11] -> [DMESG-FAIL][12] ([i915#8497]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/bat-mtlp-8/igt@i915_selftest@l...@requests.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html - bat-mtlp-6: [PASS][13] -> [DMESG-FAIL][14] ([i915#8497]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/bat-mtlp-6/igt@i915_selftest@l...@requests.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/bat-mtlp-6/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][15] -> [ABORT][16] ([i915#4983] / [i915#7461] / [i915#7981] / [i915#8347] / [i915#8384]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/bat-rpls-1/igt@i915_selftest@l...@reset.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@i915_selftest@live@slpc: - bat-mtlp-6: [PASS][17] -> [DMESG-WARN][18] ([i915#6367]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/bat-mtlp-6/igt@i915_selftest@l...@slpc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/bat-mtlp-6/igt@i915_selftest@l...@slpc.html - bat-rpls-2: NOTRUN -> [DMESG-WARN][19] ([i915#6367]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/bat-rpls-2/igt@i915_selftest@l...@slpc.html Possible fixes * igt@i915_pm_rpm@basic-pci-d3-state: - fi-tgl-1115g4: [FAIL][20] ([i915#7940]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/fi-tgl-1115g4/igt@i915_pm_...@basic-pci-d3-state.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/fi-tgl-1115g4/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [DMESG-FAIL][22] ([i915#5334]) -> [PASS][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@migrate: - bat-rpls-2: [DMESG-FAIL][24] ([i915#7699] / [i915#7913]) -> [PASS][25] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13460/bat-rpls-2/igt@i915_selftest@l...@migrate.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_121879v1/bat-rpls-2/igt@i915_selftest@l...@migrate.html - bat-atsm-1: [DMESG-FAIL][26] ([i915#
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/xelpd: Calculate first_line_bpg_offset for DSC 1.1
== Series Details == Series: drm/i915/xelpd: Calculate first_line_bpg_offset for DSC 1.1 URL : https://patchwork.freedesktop.org/series/121882/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool INSTALL libsubcmd_headers CC [M] drivers/gpu/drm/i915/display/intel_vdsc.o drivers/gpu/drm/i915/display/intel_vdsc.c: In function ‘calculate_rc_params’: drivers/gpu/drm/i915/display/intel_vdsc.c:93:4: error: ‘rc’ undeclared (first use in this function); did you mean ‘rq’? 93 |rc->first_line_bpg_offset = 12; |^~ |rq drivers/gpu/drm/i915/display/intel_vdsc.c:93:4: note: each undeclared identifier is reported only once for each function it appears in make[6]: *** [scripts/Makefile.build:243: drivers/gpu/drm/i915/display/intel_vdsc.o] Error 1 make[5]: *** [scripts/Makefile.build:480: drivers/gpu/drm/i915] Error 2 make[4]: *** [scripts/Makefile.build:480: drivers/gpu/drm] Error 2 make[3]: *** [scripts/Makefile.build:480: drivers/gpu] Error 2 make[2]: *** [scripts/Makefile.build:480: drivers] Error 2 make[1]: *** [/home/kbuild2/kernel/Makefile:2032: .] Error 2 make: *** [Makefile:234: __sub-make] Error 2 Build failed, no error log produced
Re: [Intel-gfx] [PATCH] drm/i915/xelpd: Calculate first_line_bpg_offset for DSC 1.1
Hi William,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-intel/for-linux-next-fixes]
[also build test ERROR on linus/master v6.5-rc4 next-20230802]
[cannot apply to drm-tip/drm-tip drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/William-Tseng/drm-i915-xelpd-Calculate-first_line_bpg_offset-for-DSC-1-1/20230802-181626
base: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
patch link:
https://lore.kernel.org/r/20230802101541.10045-1-william.tseng%40intel.com
patch subject: [Intel-gfx] [PATCH] drm/i915/xelpd: Calculate
first_line_bpg_offset for DSC 1.1
config: x86_64-randconfig-r016-20230731
(https://download.01.org/0day-ci/archive/20230802/202308022109.mp7mksid-...@intel.com/config)
compiler: clang version 16.0.4 (https://github.com/llvm/llvm-project.git
ae42196bc493ffe877a7e3dff8be32035dea4d07)
reproduce:
(https://download.01.org/0day-ci/archive/20230802/202308022109.mp7mksid-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202308022109.mp7mksid-...@intel.com/
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_vdsc.c:83:4: error: use of undeclared
>> identifier 'rc'
rc->first_line_bpg_offset = 12;
^
drivers/gpu/drm/i915/display/intel_vdsc.c:85:4: error: use of undeclared
identifier 'rc'
rc->first_line_bpg_offset = 15;
^
2 errors generated.
vim +/rc +83 drivers/gpu/drm/i915/display/intel_vdsc.c
54
55 static void
56 calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
57 {
58 int bpc = vdsc_cfg->bits_per_component;
59 int bpp = vdsc_cfg->bits_per_pixel >> 4;
60 static const s8 ofs_und6[] = {
61 0, -2, -2, -4, -6, -6, -8, -8, -8, -10, -10, -12, -12,
-12, -12
62 };
63 static const s8 ofs_und8[] = {
64 2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12,
-12, -12
65 };
66 static const s8 ofs_und12[] = {
67 2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12,
-12, -12
68 };
69 static const s8 ofs_und15[] = {
70 10, 8, 6, 4, 2, 0, -2, -4, -6, -8, -10, -10, -12, -12,
-12
71 };
72 int qp_bpc_modifier = (bpc - 8) * 2;
73 u32 res, buf_i, bpp_i;
74
75 if (vdsc_cfg->dsc_version_minor == 2) {
76 if (vdsc_cfg->slice_height >= 8)
77 vdsc_cfg->first_line_bpg_offset =
78 12 + DIV_ROUND_UP((9 * min(34,
vdsc_cfg->slice_height - 8)), 100);
79 else
80 vdsc_cfg->first_line_bpg_offset = 2 *
(vdsc_cfg->slice_height - 1);
81 } else {
82 if (bpp == 8)
> 83 rc->first_line_bpg_offset = 12;
84 else
85 rc->first_line_bpg_offset = 15;
86 }
87
88 /* Our hw supports only 444 modes as of today */
89 if (bpp >= 12)
90 vdsc_cfg->initial_offset = 2048;
91 else if (bpp >= 10)
92 vdsc_cfg->initial_offset = 5632 - DIV_ROUND_UP(((bpp -
10) * 3584), 2);
93 else if (bpp >= 8)
94 vdsc_cfg->initial_offset = 6144 - DIV_ROUND_UP(((bpp -
8) * 512), 2);
95 else
96 vdsc_cfg->initial_offset = 6144;
97
98 /* initial_xmit_delay = rc_model_size/2/compression_bpp */
99 vdsc_cfg->initial_xmit_delay =
DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
100
101 vdsc_cfg->flatness_min_qp = 3 + qp_bpc_modifier;
102 vdsc_cfg->flatness_max_qp = 12 + qp_bpc_modifier;
103
104 vdsc_cfg->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
105 vdsc_cfg->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
106
107 bpp_i = (2 * (bpp - 6));
108 for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
109 u8 range_bpg_offset;
110
111 /* Read range_minqp and range_max_qp from qp tables */
112 vdsc_cfg->rc_range_params[buf_i].range_min_qp =
113
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/modes: Fix division by zero error
== Series Details == Series: drm/modes: Fix division by zero error URL : https://patchwork.freedesktop.org/series/121879/ State : warning == Summary == Error: dim checkpatch failed 1beffd9a2b07 drm/modes: Fix division by zero error -:18: WARNING:BAD_REPORTED_BY_LINK: Reported-by: should be immediately followed by Closes: with a URL to the report #18: Reported-by: syzbot+622bba18029bcde67...@syzkaller.appspotmail.com Signed-off-by: Ziqi Zhao -:50: CHECK:SPACING: No space is necessary after a cast #50: FILE: drivers/gpu/drm/drm_modes.c:1306: + return DIV_ROUND_CLOSEST_ULL(num, (u32) den); total: 0 errors, 1 warnings, 1 checks, 27 lines checked
Re: [Intel-gfx] [PATCH] drm/i915/xelpd: Calculate first_line_bpg_offset for DSC 1.1
Hi William,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-intel/for-linux-next-fixes]
[also build test ERROR on linus/master v6.5-rc4 next-20230802]
[cannot apply to drm-tip/drm-tip drm-intel/for-linux-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/William-Tseng/drm-i915-xelpd-Calculate-first_line_bpg_offset-for-DSC-1-1/20230802-181626
base: git://anongit.freedesktop.org/drm-intel for-linux-next-fixes
patch link:
https://lore.kernel.org/r/20230802101541.10045-1-william.tseng%40intel.com
patch subject: [Intel-gfx] [PATCH] drm/i915/xelpd: Calculate
first_line_bpg_offset for DSC 1.1
config: x86_64-buildonly-randconfig-r002-20230731
(https://download.01.org/0day-ci/archive/20230802/202308022035.wnmrwpdc-...@intel.com/config)
compiler: gcc-12 (Debian 12.2.0-14) 12.2.0
reproduce:
(https://download.01.org/0day-ci/archive/20230802/202308022035.wnmrwpdc-...@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot
| Closes:
https://lore.kernel.org/oe-kbuild-all/202308022035.wnmrwpdc-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/display/intel_vdsc.c: In function 'calculate_rc_params':
>> drivers/gpu/drm/i915/display/intel_vdsc.c:83:25: error: 'rc' undeclared
>> (first use in this function); did you mean 'rq'?
83 | rc->first_line_bpg_offset = 12;
| ^~
| rq
drivers/gpu/drm/i915/display/intel_vdsc.c:83:25: note: each undeclared
identifier is reported only once for each function it appears in
vim +83 drivers/gpu/drm/i915/display/intel_vdsc.c
54
55 static void
56 calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
57 {
58 int bpc = vdsc_cfg->bits_per_component;
59 int bpp = vdsc_cfg->bits_per_pixel >> 4;
60 static const s8 ofs_und6[] = {
61 0, -2, -2, -4, -6, -6, -8, -8, -8, -10, -10, -12, -12,
-12, -12
62 };
63 static const s8 ofs_und8[] = {
64 2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12,
-12, -12
65 };
66 static const s8 ofs_und12[] = {
67 2, 0, 0, -2, -4, -6, -8, -8, -8, -10, -10, -10, -12,
-12, -12
68 };
69 static const s8 ofs_und15[] = {
70 10, 8, 6, 4, 2, 0, -2, -4, -6, -8, -10, -10, -12, -12,
-12
71 };
72 int qp_bpc_modifier = (bpc - 8) * 2;
73 u32 res, buf_i, bpp_i;
74
75 if (vdsc_cfg->dsc_version_minor == 2) {
76 if (vdsc_cfg->slice_height >= 8)
77 vdsc_cfg->first_line_bpg_offset =
78 12 + DIV_ROUND_UP((9 * min(34,
vdsc_cfg->slice_height - 8)), 100);
79 else
80 vdsc_cfg->first_line_bpg_offset = 2 *
(vdsc_cfg->slice_height - 1);
81 } else {
82 if (bpp == 8)
> 83 rc->first_line_bpg_offset = 12;
84 else
85 rc->first_line_bpg_offset = 15;
86 }
87
88 /* Our hw supports only 444 modes as of today */
89 if (bpp >= 12)
90 vdsc_cfg->initial_offset = 2048;
91 else if (bpp >= 10)
92 vdsc_cfg->initial_offset = 5632 - DIV_ROUND_UP(((bpp -
10) * 3584), 2);
93 else if (bpp >= 8)
94 vdsc_cfg->initial_offset = 6144 - DIV_ROUND_UP(((bpp -
8) * 512), 2);
95 else
96 vdsc_cfg->initial_offset = 6144;
97
98 /* initial_xmit_delay = rc_model_size/2/compression_bpp */
99 vdsc_cfg->initial_xmit_delay =
DIV_ROUND_UP(DSC_RC_MODEL_SIZE_CONST, 2 * bpp);
100
101 vdsc_cfg->flatness_min_qp = 3 + qp_bpc_modifier;
102 vdsc_cfg->flatness_max_qp = 12 + qp_bpc_modifier;
103
104 vdsc_cfg->rc_quant_incr_limit0 = 11 + qp_bpc_modifier;
105 vdsc_cfg->rc_quant_incr_limit1 = 11 + qp_bpc_modifier;
106
107 bpp_i = (2 * (bpp - 6));
108 for (buf_i = 0; buf_i < DSC_NUM_BUF_RANGES; buf_i++) {
109 u8 range_bpg_offset;
110
111 /* Read range_minqp and range_max_qp from qp tables */
112 vdsc_cfg->
Re: [Intel-gfx] [PATCH 10/20] drm/i915/dp: Add functions to get min/max src input bpc with DSC
On Fri, Jul 28, 2023 at 09:41:40AM +0530, Ankit Nautiyal wrote:
> Separate out functions for getting maximum and minimum input BPC based
> on platforms, when DSC is used.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 38 +++--
> 1 file changed, 30 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 7ec8a478e000..f41de126a8d3 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1535,6 +1535,18 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> return -EINVAL;
> }
>
> +static
> +u8 intel_dp_dsc_max_src_input_bpc(struct drm_i915_private *i915)
> +{
> + /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
> + if (DISPLAY_VER(i915) >= 12)
> + return 12;
> + if (DISPLAY_VER(i915) == 11)
> + return 10;
> +
> + return 0;
> +}
> +
> int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 max_req_bpc)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> @@ -1542,11 +1554,12 @@ int intel_dp_dsc_compute_bpp(struct intel_dp
> *intel_dp, u8 max_req_bpc)
> u8 dsc_bpc[3] = {0};
> u8 dsc_max_bpc;
>
> - /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
> - if (DISPLAY_VER(i915) >= 12)
> - dsc_max_bpc = min_t(u8, 12, max_req_bpc);
> - else
> - dsc_max_bpc = min_t(u8, 10, max_req_bpc);
> + dsc_max_bpc = intel_dp_dsc_max_src_input_bpc(i915);
> +
> + if (!dsc_max_bpc)
> + return dsc_max_bpc;
> +
> + dsc_max_bpc = min_t(u8, dsc_max_bpc, max_req_bpc);
>
> num_bpc = drm_dp_dsc_sink_supported_input_bpcs(intel_dp->dsc_dpcd,
> dsc_bpc);
> @@ -1674,6 +1687,16 @@ static bool intel_dp_dsc_supports_format(struct
> intel_dp *intel_dp,
> return drm_dp_dsc_sink_supports_format(intel_dp->dsc_dpcd,
> sink_dsc_format);
> }
>
> +static
> +u8 intel_dp_dsc_min_src_input_bpc(struct drm_i915_private *i915)
> +{
> + /* Min DSC Input BPC for ICL+ is 8 */
> + if (DISPLAY_VER(i915) >= 11)
> + return 8;
> +
> + return 0;
So does it mean that for anything below gen 11, there is no limit at all?
Also it means that the condition below will never be executed for gen <= 11.
Stan
> +}
> +
> int intel_dp_dsc_compute_config(struct intel_dp *intel_dp,
> struct intel_crtc_state *pipe_config,
> struct drm_connector_state *conn_state,
> @@ -1707,10 +1730,9 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> pipe_bpp = pipe_config->pipe_bpp;
> }
>
> - /* Min Input BPC for ICL+ is 8 */
> - if (pipe_bpp < 8 * 3) {
> + if (pipe_bpp < intel_dp_dsc_min_src_input_bpc(dev_priv) * 3) {
> drm_dbg_kms(&dev_priv->drm,
> - "No DSC support for less than 8bpc\n");
> + "Computed BPC less than min supported by source for
> DSC\n");
> return -EINVAL;
> }
>
> --
> 2.40.1
>
Re: [Intel-gfx] [PATCH 09/20] drm/i915/dp: Avoid forcing DSC BPC for MST case
On Fri, Jul 28, 2023 at 09:41:39AM +0530, Ankit Nautiyal wrote:
> For MST the bpc is hardcoded to 8, and pipe bpp to 24.
> So avoid forcing DSC bpc for MST case.
>
> v2: Warn and ignore the debug flag than to bail out. (Jani)
>
> v3: Fix dbg message to mention forced bpc instead of bpp.
>
> v4: Fix checkpatch longline warning.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 5 +
> 2 files changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c5d2e6f538ed..7ec8a478e000 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1697,14 +1697,14 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> if (!intel_dp_dsc_supports_format(intel_dp, pipe_config->output_format))
> return -EINVAL;
>
> - if (compute_pipe_bpp)
> + if (intel_dp->force_dsc_bpc && compute_pipe_bpp) {
> + pipe_bpp = intel_dp->force_dsc_bpc * 3;
> + drm_dbg_kms(&dev_priv->drm, "Input DSC BPC forced to %d\n",
> + intel_dp->force_dsc_bpc);
> + } else if (compute_pipe_bpp) {
> pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
> conn_state->max_requested_bpc);
> - else
> + } else {
> pipe_bpp = pipe_config->pipe_bpp;
> -
> - if (intel_dp->force_dsc_bpc) {
> - pipe_bpp = intel_dp->force_dsc_bpc * 3;
> - drm_dbg_kms(&dev_priv->drm, "Input DSC BPP forced to %d",
> pipe_bpp);
> }
>
> /* Min Input BPC for ICL+ is 8 */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 1f00713fb1ad..dff4717edbd0 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -361,6 +361,11 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
> /* enable compression if the mode doesn't fit available BW */
> drm_dbg_kms(&dev_priv->drm, "Force DSC en = %d\n",
> intel_dp->force_dsc_en);
> if (ret || intel_dp->force_dsc_en) {
> + /*
> + * FIXME: As bpc is hardcoded to 8, as mentioned above,
> + * WARN and ignore the debug flag force_dsc_bpc for now.
> + */
> + drm_WARN(&dev_priv->drm, intel_dp->force_dsc_bpc, "Cannot Force
> BPC for MST\n");
> /*
>* Try to get at least some timeslots and then see, if
>* we can fit there with DSC.
Reviewed-by: Stanislav Lisovskiy
> --
> 2.40.1
>
Re: [Intel-gfx] [PATCH 08/20] drm/display/dp: Fix the DP DSC Receiver cap size
On Fri, Jul 28, 2023 at 09:41:38AM +0530, Ankit Nautiyal wrote:
> DP DSC Receiver Capabilities are exposed via DPCD 60h-6Fh.
> Fix the DSC RECEIVER CAP SIZE accordingly.
>
> Fixes: ffddc4363c28 ("drm/dp: Add DP DSC DPCD receiver capability size define
> and missing SHIFT")
> Cc: Anusha Srivatsa
> Cc: Manasi Navare
> Cc: # v5.0+
>
> Signed-off-by: Ankit Nautiyal
> ---
> include/drm/display/drm_dp.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h
> index 02f2ac4dd2df..e69cece404b3 100644
> --- a/include/drm/display/drm_dp.h
> +++ b/include/drm/display/drm_dp.h
> @@ -1537,7 +1537,7 @@ enum drm_dp_phy {
>
> #define DP_BRANCH_OUI_HEADER_SIZE0xc
> #define DP_RECEIVER_CAP_SIZE 0xf
> -#define DP_DSC_RECEIVER_CAP_SIZE0xf
> +#define DP_DSC_RECEIVER_CAP_SIZE0x10 /* DSC Capabilities 0x60
> through 0x6F */
> #define EDP_PSR_RECEIVER_CAP_SIZE2
> #define EDP_DISPLAY_CTL_CAP_SIZE 3
> #define DP_LTTPR_COMMON_CAP_SIZE 8
Reviewed-by: Stanislav Lisovskiy
> --
> 2.40.1
>
Re: [Intel-gfx] [PATCH] drm/i915/xelpd: Calculate first_line_bpg_offset for DSC 1.1
On 8/2/2023 4:45 PM, Kandpal, Suraj wrote:
1.1
This change is required for DSC 1.1 because the current calculation is for DSC
1.2 and may get a calculated value which is not recommended by DSC 1.1, for
example, the calculated value at 8bpp becomes 15, not the value of 12
recommened by DSC 1.1.
Cc: Ankit Nautiyal
Cc: Juha-Pekka Heikkil
Signed-off-by: William Tseng
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index bd9116d2cd76..9b350f5f8ebb 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -72,11 +72,18 @@ calculate_rc_params(struct drm_dsc_config
*vdsc_cfg)
int qp_bpc_modifier = (bpc - 8) * 2;
u32 res, buf_i, bpp_i;
- if (vdsc_cfg->slice_height >= 8)
- vdsc_cfg->first_line_bpg_offset =
- 12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg-
This seem to be incorrect as per the spec this should have been
first_line_bpg_offset = 12 + floor(0.09 * MIN (34, slice_height – 8))for
slice_height ≥ 8
So instead of rounding up we should have just divided.
slice_height - 8)), 100);
- else
- vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg-
slice_height - 1);
+ if (vdsc_cfg->dsc_version_minor == 2) {
I think the check here should be for minor version 1 and move the code in this
block to
the else block and vice versa as this 8 bpp corner case is applicable only to
DSC 1.1
+ if (vdsc_cfg->slice_height >= 8)
+ vdsc_cfg->first_line_bpg_offset =
+ 12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg-
slice_height - 8)), 100);
+ else
+ vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg-
slice_height - 1);
+ } else {
+ if (bpp == 8)
+ rc->first_line_bpg_offset = 12;
+ else
+ rc->first_line_bpg_offset = 15;
+ }
Add the section in DSC spec/ Cmodel from where one can verify this in comments
I think this is coming from the recommended/ required value from DSC 1.1.
Regards,
Ankit
Regards,
Suraj Kandpal
/* Our hw supports only 444 modes as of today */
if (bpp >= 12)
--
2.34.1
Re: [Intel-gfx] [PATCH] drm/i915/xelpd: Calculate first_line_bpg_offset for DSC 1.1
1.1
>
> This change is required for DSC 1.1 because the current calculation is for DSC
> 1.2 and may get a calculated value which is not recommended by DSC 1.1, for
> example, the calculated value at 8bpp becomes 15, not the value of 12
> recommened by DSC 1.1.
>
> Cc: Ankit Nautiyal
> Cc: Juha-Pekka Heikkil
> Signed-off-by: William Tseng
> ---
> drivers/gpu/drm/i915/display/intel_vdsc.c | 17 -
> 1 file changed, 12 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index bd9116d2cd76..9b350f5f8ebb 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -72,11 +72,18 @@ calculate_rc_params(struct drm_dsc_config
> *vdsc_cfg)
> int qp_bpc_modifier = (bpc - 8) * 2;
> u32 res, buf_i, bpp_i;
>
> - if (vdsc_cfg->slice_height >= 8)
> - vdsc_cfg->first_line_bpg_offset =
> - 12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg-
> >slice_height - 8)), 100);
> - else
> - vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg-
> >slice_height - 1);
> + if (vdsc_cfg->dsc_version_minor == 2) {
I think the check here should be for minor version 1 and move the code in this
block to
the else block and vice versa as this 8 bpp corner case is applicable only to
DSC 1.1
> + if (vdsc_cfg->slice_height >= 8)
> + vdsc_cfg->first_line_bpg_offset =
> + 12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg-
> >slice_height - 8)), 100);
> + else
> + vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg-
> >slice_height - 1);
> + } else {
> + if (bpp == 8)
> + rc->first_line_bpg_offset = 12;
> + else
> + rc->first_line_bpg_offset = 15;
> + }
Add the section in DSC spec/ Cmodel from where one can verify this in comments
Regards,
Suraj Kandpal
>
> /* Our hw supports only 444 modes as of today */
> if (bpp >= 12)
> --
> 2.34.1
[Intel-gfx] [PATCH] drm/i915/xelpd: Calculate first_line_bpg_offset for DSC 1.1
This change is required for DSC 1.1 because the current calculation
is for DSC 1.2 and may get a calculated value which is not
recommended by DSC 1.1, for example, the calculated value at 8bpp
becomes 15, not the value of 12 recommened by DSC 1.1.
Cc: Ankit Nautiyal
Cc: Juha-Pekka Heikkil
Signed-off-by: William Tseng
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index bd9116d2cd76..9b350f5f8ebb 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -72,11 +72,18 @@ calculate_rc_params(struct drm_dsc_config *vdsc_cfg)
int qp_bpc_modifier = (bpc - 8) * 2;
u32 res, buf_i, bpp_i;
- if (vdsc_cfg->slice_height >= 8)
- vdsc_cfg->first_line_bpg_offset =
- 12 + DIV_ROUND_UP((9 * min(34, vdsc_cfg->slice_height -
8)), 100);
- else
- vdsc_cfg->first_line_bpg_offset = 2 * (vdsc_cfg->slice_height -
1);
+ if (vdsc_cfg->dsc_version_minor == 2) {
+ if (vdsc_cfg->slice_height >= 8)
+ vdsc_cfg->first_line_bpg_offset =
+ 12 + DIV_ROUND_UP((9 * min(34,
vdsc_cfg->slice_height - 8)), 100);
+ else
+ vdsc_cfg->first_line_bpg_offset = 2 *
(vdsc_cfg->slice_height - 1);
+ } else {
+ if (bpp == 8)
+ rc->first_line_bpg_offset = 12;
+ else
+ rc->first_line_bpg_offset = 15;
+ }
/* Our hw supports only 444 modes as of today */
if (bpp >= 12)
--
2.34.1
[Intel-gfx] [PATCH v2] drm/modes: Fix division by zero error
In the bug reported by Syzbot, the variable `den == (1 << 22)` and
`mode->vscan == (1 << 10)`, causing the multiplication to overflow and
accidentally make `den == 0`. To prevent any chance of overflow, we
replace `num` and `den` with 64-bit unsigned integers, and explicitly
check if the divisor `den` will overflow. If so, we employ full 64-bit
division with rounding; otherwise we keep the 64-bit to 32-bit division
that could potentially be better optimized.
In order to minimize the performance overhead, the overflow check for
`den` is wrapped with an `unlikely` condition. Please let me know if
this usage is appropriate.
Reported-by: syzbot+622bba18029bcde67...@syzkaller.appspotmail.com
Signed-off-by: Ziqi Zhao
---
V1 -> V2: address style comments suggested by Jani Nikula
drivers/gpu/drm/drm_modes.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index ac9a406250c5..137101960690 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1285,13 +1285,13 @@ EXPORT_SYMBOL(drm_mode_set_name);
*/
int drm_mode_vrefresh(const struct drm_display_mode *mode)
{
- unsigned int num, den;
+ u64 num, den;
if (mode->htotal == 0 || mode->vtotal == 0)
return 0;
- num = mode->clock;
- den = mode->htotal * mode->vtotal;
+ num = mul_u32_u32(mode->clock, 1000);
+ den = mul_u32_u32(mode->htotal, mode->vtotal);
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
num *= 2;
@@ -1300,7 +1300,10 @@ int drm_mode_vrefresh(const struct drm_display_mode
*mode)
if (mode->vscan > 1)
den *= mode->vscan;
- return DIV_ROUND_CLOSEST_ULL(mul_u32_u32(num, 1000), den);
+ if (unlikely(den > UINT_MAX))
+ return DIV64_U64_ROUND_CLOSEST(num, den);
+
+ return DIV_ROUND_CLOSEST_ULL(num, (u32) den);
}
EXPORT_SYMBOL(drm_mode_vrefresh);
--
2.34.1
Re: [Intel-gfx] [PATCH 2/4] drm/bridge-connector: handle subconnector types
On Wed, 2 Aug 2023 at 11:35, Neil Armstrong wrote:
>
> On 29/07/2023 02:49, Dmitry Baryshkov wrote:
> > If the created connector type supports subconnector type property,
> > create and attach corresponding it. The default subtype value is 0,
> > which maps to the DRM_MODE_SUBCONNECTOR_Unknown type.
> >
> > Signed-off-by: Dmitry Baryshkov
> > ---
> > drivers/gpu/drm/drm_bridge_connector.c | 33 +-
> > include/drm/drm_bridge.h | 4
> > 2 files changed, 36 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge_connector.c
> > b/drivers/gpu/drm/drm_bridge_connector.c
> > index 07b5930b1282..a7b92f0d2430 100644
> > --- a/drivers/gpu/drm/drm_bridge_connector.c
> > +++ b/drivers/gpu/drm/drm_bridge_connector.c
> > @@ -329,7 +329,9 @@ struct drm_connector *drm_bridge_connector_init(struct
> > drm_device *drm,
> > struct drm_connector *connector;
> > struct i2c_adapter *ddc = NULL;
> > struct drm_bridge *bridge, *panel_bridge = NULL;
> > + enum drm_mode_subconnector subconnector;
> > int connector_type;
> > + int ret;
> >
> > bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
> > if (!bridge_connector)
> > @@ -365,8 +367,10 @@ struct drm_connector *drm_bridge_connector_init(struct
> > drm_device *drm,
> > if (bridge->ops & DRM_BRIDGE_OP_MODES)
> > bridge_connector->bridge_modes = bridge;
> >
> > - if (!drm_bridge_get_next_bridge(bridge))
> > + if (!drm_bridge_get_next_bridge(bridge)) {
> > connector_type = bridge->type;
> > + subconnector = bridge->subtype;
> > + }
> >
> > #ifdef CONFIG_OF
> > if (!drm_bridge_get_next_bridge(bridge) &&
> > @@ -399,6 +403,33 @@ struct drm_connector *drm_bridge_connector_init(struct
> > drm_device *drm,
> > if (panel_bridge)
> > drm_panel_bridge_set_orientation(connector, panel_bridge);
> >
> > + if (connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
> > + drm_connector_attach_dp_subconnector_property(connector,
> > subconnector);
> > + } else if (connector_type == DRM_MODE_CONNECTOR_DVII) {
> > + ret = drm_mode_create_dvi_i_properties(drm);
> > + if (ret)
> > + return ERR_PTR(ret);
> > +
> > + drm_object_attach_property(&connector->base,
> > +
> > drm->mode_config.dvi_i_subconnector_property,
> > +subconnector);
> > + } else if (connector_type == DRM_MODE_CONNECTOR_TV) {
> > + ret = drm_mode_create_tv_properties(drm,
> > +
> > BIT(DRM_MODE_TV_MODE_NTSC) |
> > +
> > BIT(DRM_MODE_TV_MODE_NTSC_443) |
> > +
> > BIT(DRM_MODE_TV_MODE_NTSC_J) |
> > + BIT(DRM_MODE_TV_MODE_PAL)
> > |
> > +
> > BIT(DRM_MODE_TV_MODE_PAL_M) |
> > +
> > BIT(DRM_MODE_TV_MODE_PAL_N) |
> > +
> > BIT(DRM_MODE_TV_MODE_SECAM));
> > + if (ret)
> > + return ERR_PTR(ret);
>
> I don't think this is right, this should be called from the appropriate
> encoder
> device depending on the analog tv mode capabilities.
Good question. My logic was the following: the DRM device can have
different TV out ports with different capabilities (yeah, pure
theoretical construct). In this case it might be impossible to create
a single subset of values. Thus it is more correct to create the
property listing all possible values. The property is immutable anyway
(and so the user doesn't have control over the value).
> > +
> > + drm_object_attach_property(&connector->base,
> > +
> > drm->mode_config.tv_subconnector_property,
> > +subconnector);
>
> Here, only add the property if drm->mode_config.tv_subconnector_property
> exists,
> and perhaps add a warning if not.
This property is created in the previous call,
drm_mode_create_tv_properties() ->
drm_mode_create_tv_properties_legacy().
>
> AFAIK same for DRM_MODE_CONNECTOR_DVII.
>
> > + }
> > +
> > return connector;
> > }
> > EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
> > diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
> > index bf964cdfb330..68b14ac5ac0d 100644
> > --- a/include/drm/drm_bridge.h
> > +++ b/include/drm/drm_bridge.h
> > @@ -739,6 +739,10 @@ struct drm_bridge {
> >* identifies the type of connected display.
> >*/
> > int type;
> > + /**
> > + * @subtype: the subtype of the connector for the DP/TV/DVI-I
Re: [Intel-gfx] [PATCH 2/4] drm/bridge-connector: handle subconnector types
On 29/07/2023 02:49, Dmitry Baryshkov wrote:
If the created connector type supports subconnector type property,
create and attach corresponding it. The default subtype value is 0,
which maps to the DRM_MODE_SUBCONNECTOR_Unknown type.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/drm_bridge_connector.c | 33 +-
include/drm/drm_bridge.h | 4
2 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_bridge_connector.c
b/drivers/gpu/drm/drm_bridge_connector.c
index 07b5930b1282..a7b92f0d2430 100644
--- a/drivers/gpu/drm/drm_bridge_connector.c
+++ b/drivers/gpu/drm/drm_bridge_connector.c
@@ -329,7 +329,9 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
struct drm_connector *connector;
struct i2c_adapter *ddc = NULL;
struct drm_bridge *bridge, *panel_bridge = NULL;
+ enum drm_mode_subconnector subconnector;
int connector_type;
+ int ret;
bridge_connector = kzalloc(sizeof(*bridge_connector), GFP_KERNEL);
if (!bridge_connector)
@@ -365,8 +367,10 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
if (bridge->ops & DRM_BRIDGE_OP_MODES)
bridge_connector->bridge_modes = bridge;
- if (!drm_bridge_get_next_bridge(bridge))
+ if (!drm_bridge_get_next_bridge(bridge)) {
connector_type = bridge->type;
+ subconnector = bridge->subtype;
+ }
#ifdef CONFIG_OF
if (!drm_bridge_get_next_bridge(bridge) &&
@@ -399,6 +403,33 @@ struct drm_connector *drm_bridge_connector_init(struct
drm_device *drm,
if (panel_bridge)
drm_panel_bridge_set_orientation(connector, panel_bridge);
+ if (connector_type == DRM_MODE_CONNECTOR_DisplayPort) {
+ drm_connector_attach_dp_subconnector_property(connector,
subconnector);
+ } else if (connector_type == DRM_MODE_CONNECTOR_DVII) {
+ ret = drm_mode_create_dvi_i_properties(drm);
+ if (ret)
+ return ERR_PTR(ret);
+
+ drm_object_attach_property(&connector->base,
+
drm->mode_config.dvi_i_subconnector_property,
+ subconnector);
+ } else if (connector_type == DRM_MODE_CONNECTOR_TV) {
+ ret = drm_mode_create_tv_properties(drm,
+ BIT(DRM_MODE_TV_MODE_NTSC) |
+
BIT(DRM_MODE_TV_MODE_NTSC_443) |
+
BIT(DRM_MODE_TV_MODE_NTSC_J) |
+ BIT(DRM_MODE_TV_MODE_PAL) |
+ BIT(DRM_MODE_TV_MODE_PAL_M)
|
+ BIT(DRM_MODE_TV_MODE_PAL_N)
|
+
BIT(DRM_MODE_TV_MODE_SECAM));
+ if (ret)
+ return ERR_PTR(ret);
I don't think this is right, this should be called from the appropriate encoder
device depending on the analog tv mode capabilities.
+
+ drm_object_attach_property(&connector->base,
+
drm->mode_config.tv_subconnector_property,
+ subconnector);
Here, only add the property if drm->mode_config.tv_subconnector_property exists,
and perhaps add a warning if not.
AFAIK same for DRM_MODE_CONNECTOR_DVII.
+ }
+
return connector;
}
EXPORT_SYMBOL_GPL(drm_bridge_connector_init);
diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
index bf964cdfb330..68b14ac5ac0d 100644
--- a/include/drm/drm_bridge.h
+++ b/include/drm/drm_bridge.h
@@ -739,6 +739,10 @@ struct drm_bridge {
* identifies the type of connected display.
*/
int type;
+ /**
+* @subtype: the subtype of the connector for the DP/TV/DVI-I cases.
+*/
+ enum drm_mode_subconnector subtype;
/**
* @interlace_allowed: Indicate that the bridge can handle interlaced
* modes.
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Move stolen memory handling into i915_gem_stolen
On Wed, 2023-08-02 at 09:51 +0200, Nirmoy Das wrote:
>
> On 8/1/2023 10:33 AM, Hogander, Jouni wrote:
> > On Tue, 2023-08-01 at 10:02 +0200, Nirmoy Das wrote:
> > > Hi Jouni,
> > >
> > > On 6/14/2023 7:17 AM, Jouni Högander wrote:
> > > > We are preparing for Xe. Xe stolen memory handling differs from
> > > > i915 so we
> > > > want to move stolen memory handling details into
> > > > i915_gem_stolen.
> > > >
> > > > Also add a common type for fbc compressed fb and use it from
> > > > fbc
> > > > code
> > > > instead of underlying type directly. This way we can have
> > > > common
> > > > type
> > > > i915_stolen_fb for both i915 and Xe.
> > > >
> > > > v2: Fix couple of checkpatch warnings
> > > >
> > > > Signed-off-by: Jouni Högander
> > > > Signed-off-by: Maarten Lankhorst
> > > >
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_fbc.c | 46 +++-
> > > > -
> > > > -
> > > > drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 36
> > > > +
> > > > drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 13 ++
> > > > 3 files changed, 73 insertions(+), 22 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > index 7f8b2d7713c7..a18e84efe911 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> > > > @@ -94,8 +94,7 @@ struct intel_fbc {
> > > > struct mutex lock;
> > > > unsigned int busy_bits;
> > > >
> > > > - struct drm_mm_node compressed_fb;
> > > > - struct drm_mm_node compressed_llb;
> > > > + struct i915_stolen_fb compressed_fb, compressed_llb;
> > > >
> > > > enum intel_fbc_id id;
> > > >
> > > > @@ -332,15 +331,16 @@ static void i8xx_fbc_program_cfb(struct
> > > > intel_fbc *fbc)
> > > > {
> > > > struct drm_i915_private *i915 = fbc->i915;
> > > >
> > > > - GEM_BUG_ON(range_overflows_end_t(u64, i915-
> > > > > dsm.stolen.start,
> > > > - fbc-
> > > > >compressed_fb.start,
> > > > U32_MAX));
> > > > - GEM_BUG_ON(range_overflows_end_t(u64, i915-
> > > > > dsm.stolen.start,
> > > > - fbc-
> > > > >compressed_llb.start,
> > > > U32_MAX));
> > > > -
> > > > + GEM_BUG_ON(range_overflows_end_t(u64,
> > > > i915_gem_stolen_area_address(i915),
> > > > +
> > > > i915_gem_stolen_node_offset(&fbc->compressed_fb),
> > > > + U32_MAX));
> > > > + GEM_BUG_ON(range_overflows_end_t(u64,
> > > > i915_gem_stolen_area_address(i915),
> > > > +
> > > > i915_gem_stolen_node_offset(&fbc->compressed_llb),
> > > > + U32_MAX));
> > > > intel_de_write(i915, FBC_CFB_BASE,
> > > > - i915->dsm.stolen.start + fbc-
> > > > > compressed_fb.start);
> > > > + i915_gem_stolen_node_address(i915, &fbc-
> > > > > compressed_fb));
> > > > intel_de_write(i915, FBC_LL_BASE,
> > > > - i915->dsm.stolen.start + fbc-
> > > > > compressed_llb.start);
> > > > + i915_gem_stolen_node_address(i915, &fbc-
> > > > > compressed_llb));
> > > > }
> > > >
> > > > static const struct intel_fbc_funcs i8xx_fbc_funcs = {
> > > > @@ -447,7 +447,8 @@ static void g4x_fbc_program_cfb(struct
> > > > intel_fbc *fbc)
> > > > {
> > > > struct drm_i915_private *i915 = fbc->i915;
> > > >
> > > > - intel_de_write(i915, DPFC_CB_BASE, fbc-
> > > > > compressed_fb.start);
> > > > + intel_de_write(i915, DPFC_CB_BASE,
> > > > + i915_gem_stolen_node_offset(&fbc-
> > > > > compressed_fb));
> > > > }
> > > >
> > > > static const struct intel_fbc_funcs g4x_fbc_funcs = {
> > > > @@ -498,7 +499,8 @@ static void ilk_fbc_program_cfb(struct
> > > > intel_fbc *fbc)
> > > > {
> > > > struct drm_i915_private *i915 = fbc->i915;
> > > >
> > > > - intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), fbc-
> > > > > compressed_fb.start);
> > > > + intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id),
> > > > + i915_gem_stolen_node_offset(&fbc-
> > > > > compressed_fb));
> > > > }
> > > >
> > > > static const struct intel_fbc_funcs ilk_fbc_funcs = {
> > > > @@ -713,7 +715,7 @@ static u64 intel_fbc_stolen_end(struct
> > > > drm_i915_private *i915)
> > > > * underruns, even if that range is not reserved by
> > > > the
> > > > BIOS. */
> > > > if (IS_BROADWELL(i915) ||
> > > > (DISPLAY_VER(i915) == 9 && !IS_BROXTON(i915)))
> > > > - end = resource_size(&i915->dsm.stolen) - 8 *
> > > > 1024 *
> > > > 1024;
> > > > + end = i915_gem_stolen_area_size(i915) - 8 *
> > > > 1024 *
> > > > 1024;
> > > > else
> > > > end = U64_MAX;
> > > >
> > > > @@ -770,9 +772,9
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Move stolen memory handling into i915_gem_stolen
On 8/1/2023 10:33 AM, Hogander, Jouni wrote:
On Tue, 2023-08-01 at 10:02 +0200, Nirmoy Das wrote:
Hi Jouni,
On 6/14/2023 7:17 AM, Jouni Högander wrote:
We are preparing for Xe. Xe stolen memory handling differs from
i915 so we
want to move stolen memory handling details into i915_gem_stolen.
Also add a common type for fbc compressed fb and use it from fbc
code
instead of underlying type directly. This way we can have common
type
i915_stolen_fb for both i915 and Xe.
v2: Fix couple of checkpatch warnings
Signed-off-by: Jouni Högander
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_fbc.c | 46 +++--
-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 36 +
drivers/gpu/drm/i915/gem/i915_gem_stolen.h | 13 ++
3 files changed, 73 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 7f8b2d7713c7..a18e84efe911 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -94,8 +94,7 @@ struct intel_fbc {
struct mutex lock;
unsigned int busy_bits;
- struct drm_mm_node compressed_fb;
- struct drm_mm_node compressed_llb;
+ struct i915_stolen_fb compressed_fb, compressed_llb;
enum intel_fbc_id id;
@@ -332,15 +331,16 @@ static void i8xx_fbc_program_cfb(struct
intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
- GEM_BUG_ON(range_overflows_end_t(u64, i915-
dsm.stolen.start,
- fbc->compressed_fb.start,
U32_MAX));
- GEM_BUG_ON(range_overflows_end_t(u64, i915-
dsm.stolen.start,
- fbc->compressed_llb.start,
U32_MAX));
-
+ GEM_BUG_ON(range_overflows_end_t(u64,
i915_gem_stolen_area_address(i915),
+
i915_gem_stolen_node_offset(&fbc->compressed_fb),
+ U32_MAX));
+ GEM_BUG_ON(range_overflows_end_t(u64,
i915_gem_stolen_area_address(i915),
+
i915_gem_stolen_node_offset(&fbc->compressed_llb),
+ U32_MAX));
intel_de_write(i915, FBC_CFB_BASE,
- i915->dsm.stolen.start + fbc-
compressed_fb.start);
+ i915_gem_stolen_node_address(i915, &fbc-
compressed_fb));
intel_de_write(i915, FBC_LL_BASE,
- i915->dsm.stolen.start + fbc-
compressed_llb.start);
+ i915_gem_stolen_node_address(i915, &fbc-
compressed_llb));
}
static const struct intel_fbc_funcs i8xx_fbc_funcs = {
@@ -447,7 +447,8 @@ static void g4x_fbc_program_cfb(struct
intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
- intel_de_write(i915, DPFC_CB_BASE, fbc-
compressed_fb.start);
+ intel_de_write(i915, DPFC_CB_BASE,
+ i915_gem_stolen_node_offset(&fbc-
compressed_fb));
}
static const struct intel_fbc_funcs g4x_fbc_funcs = {
@@ -498,7 +499,8 @@ static void ilk_fbc_program_cfb(struct
intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
- intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), fbc-
compressed_fb.start);
+ intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id),
+ i915_gem_stolen_node_offset(&fbc-
compressed_fb));
}
static const struct intel_fbc_funcs ilk_fbc_funcs = {
@@ -713,7 +715,7 @@ static u64 intel_fbc_stolen_end(struct
drm_i915_private *i915)
* underruns, even if that range is not reserved by the
BIOS. */
if (IS_BROADWELL(i915) ||
(DISPLAY_VER(i915) == 9 && !IS_BROXTON(i915)))
- end = resource_size(&i915->dsm.stolen) - 8 * 1024 *
1024;
+ end = i915_gem_stolen_area_size(i915) - 8 * 1024 *
1024;
else
end = U64_MAX;
@@ -770,9 +772,9 @@ static int intel_fbc_alloc_cfb(struct intel_fbc
*fbc,
int ret;
drm_WARN_ON(&i915->drm,
- drm_mm_node_allocated(&fbc->compressed_fb));
+ i915_gem_stolen_node_allocated(&fbc-
compressed_fb));
drm_WARN_ON(&i915->drm,
- drm_mm_node_allocated(&fbc->compressed_llb));
+ i915_gem_stolen_node_allocated(&fbc-
compressed_llb));
if (DISPLAY_VER(i915) < 5 && !IS_G4X(i915)) {
ret = i915_gem_stolen_insert_node(i915, &fbc-
compressed_llb,
@@ -792,15 +794,14 @@ static int intel_fbc_alloc_cfb(struct
intel_fbc *fbc,
drm_dbg_kms(&i915->drm,
"reserved %llu bytes of contiguous stolen space
for FBC, limit: %d\n",
- fbc->compressed_fb.size, fbc->limit);
-
+ i915_gem_stolen_node_size(&fbc->compressed_fb),
fbc->limit);
return 0;
err_llb:
- if (drm_mm_node_allocated(&fbc->compressed_llb))
+ if (i915_gem_stolen_node_allocated(&fbc->com
Re: [Intel-gfx] [PULL] gvt-fixes
On 02/08/2023 06:54, Zhenyu Wang wrote: Hi, Here is one gvt fix for bug in AUX CH register message length get. Please help to pick. Pulled, thank you! Regards, Tvrtko Thanks! -- The following changes since commit e354f67733115b4453268f61e6e072e9b1ea7a2f: drm/i915: Fix an error handling path in igt_write_huge() (2023-07-25 08:38:12 +0100) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-fixes-2023-08-02 for you to fetch changes up to 46d14e17095237007b59f56aae2d81ae2dcb0f93: drm/i915/gvt: Fix bug in getting msg length in AUX CH registers handler (2023-08-01 11:21:09 +0800) gvt-fixes-2023-08-02 - Fix bug to get AUX CH register message length (Yan) Yan Zhao (1): drm/i915/gvt: Fix bug in getting msg length in AUX CH registers handler drivers/gpu/drm/i915/gvt/edid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Re: [Intel-gfx] [RESEND 0/2] drm/i915/uncore: unclaimed reg debug race fix
On Tue, 01 Aug 2023, Jani Nikula wrote: > Resend of the first two patches of [1], dropping the third. Pushed to din. > > BR, > Jani. > > [1] https://patchwork.freedesktop.org/series/120167/ > > Jani Nikula (2): > drm/i915/uncore: split unclaimed_reg_debug() to header and footer > drm/i915/uncore: fix race around i915->params.mmio_debug > > drivers/gpu/drm/i915/intel_uncore.c | 44 ++--- > 1 file changed, 27 insertions(+), 17 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
