[Intel-gfx] ✓ Fi.CI.BAT: success for HDCP MST aux issue fix (rev6)
== Series Details == Series: HDCP MST aux issue fix (rev6) URL : https://patchwork.freedesktop.org/series/122267/ State : success == Summary == CI Bug Log - changes from CI_DRM_13570 -> Patchwork_122267v6 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/index.html Participating hosts (25 -> 36) -- Additional (13): fi-kbl-soraka fi-kbl-7567u bat-adls-5 bat-adlp-9 bat-dg2-13 bat-adlm-1 fi-cfl-guc fi-kbl-x1275 bat-dg2-14 bat-rpls-1 bat-jsl-1 bat-mtlp-8 bat-mtlp-6 Missing(2): bat-dg2-9 fi-snb-2520m Known issues Here are the changes found in Patchwork_122267v6 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html - bat-adlp-9: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adlp-9/igt@debugfs_t...@basic-hwmon.html - bat-adls-5: NOTRUN -> [SKIP][3] ([i915#7456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adls-5/igt@debugfs_t...@basic-hwmon.html - bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#7456]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][5] ([i915#7456]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html - bat-rpls-1: NOTRUN -> [SKIP][6] ([i915#7456]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-rpls-1/igt@debugfs_t...@basic-hwmon.html - bat-mtlp-6: NOTRUN -> [SKIP][7] ([i915#7456]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-mtlp-6/igt@debugfs_t...@basic-hwmon.html * igt@debugfs_test@read_all_entries: - fi-kbl-7567u: NOTRUN -> [ABORT][8] ([i915#8913]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/fi-kbl-7567u/igt@debugfs_test@read_all_entries.html * igt@fbdev@eof: - bat-adls-5: NOTRUN -> [SKIP][9] ([i915#2582]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adls-5/igt@fb...@eof.html - bat-adlm-1: NOTRUN -> [SKIP][10] ([i915#2582]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adlm-1/igt@fb...@eof.html * igt@fbdev@info: - fi-kbl-x1275: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1849]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/fi-kbl-x1275/igt@fb...@info.html - bat-rpls-1: NOTRUN -> [SKIP][12] ([i915#1849] / [i915#2582]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-rpls-1/igt@fb...@info.html - bat-adls-5: NOTRUN -> [SKIP][13] ([i915#1849] / [i915#2582]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adls-5/igt@fb...@info.html - bat-adlm-1: NOTRUN -> [SKIP][14] ([i915#1849] / [i915#2582]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adlm-1/igt@fb...@info.html - bat-mtlp-6: NOTRUN -> [SKIP][15] ([i915#1849] / [i915#2582]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-mtlp-6/igt@fb...@info.html * igt@fbdev@write: - bat-rpls-1: NOTRUN -> [SKIP][16] ([i915#2582]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-rpls-1/igt@fb...@write.html - bat-mtlp-6: NOTRUN -> [SKIP][17] ([i915#2582]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-mtlp-6/igt@fb...@write.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][18] ([i915#2190]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-jsl-1/igt@gem_huc_c...@huc-copy.html - fi-kbl-x1275: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2190]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2190]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - bat-adlp-9: NOTRUN -> [SKIP][21] ([i915#4613]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adlp-9/igt@gem_lmem_swapp...@basic.html - fi-kbl-soraka: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#4613]) +3 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
Re: [Intel-gfx] [PATCH v15 00/23] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers
On 8/28/23 18:24, Helen Mae Koike Fornazier wrote: > On Monday, August 28, 2023 11:37 -03, "Helen Mae Koike Fornazier" > wrote: > >> On Sunday, August 27, 2023 14:54 -03, Dmitry Osipenko >> wrote: >> >>> This series: >>> >>> 1. Adds common drm-shmem memory shrinker >>> 2. Enables shrinker for VirtIO-GPU driver >>> 3. Switches Panfrost driver to the common shrinker >> >> Hi Dmitry, >> >> Would you mind testing with drm-ci? We virt-io tests there and it would be >> really great to get your feedback of it. >> >> https://cgit.freedesktop.org/drm/drm/log/?h=topic/drm-ci > > sorry, I forgot that you also need this patchset: > https://lists.freedesktop.org/archives/dri-devel/2023-August/420063.html > to enable virtio_gpu test job. > > Thanks again. > Helen > >> >> You need to merge your changes with the above tree. >> To configure it, you just need to have a tree on gitlab.freedesktop.org, >> go to the settings and change the CI/CD configuration file from >> .gitlab-ci.yml >> to drivers/gpu/drm/ci/gitlab-ci.yml, and you can start a pipeline >> on your branch. >> >> at the time of this writting, gitlab.freedesktop.org is under maintenance, >> but it should be back soon. Thanks, Helen. I'll give it a try for the next version -- Best regards, Dmitry
Re: [Intel-gfx] [PATCH v15 17/23] drm/shmem-helper: Add and use drm_gem_shmem_resv_assert_held() helper
On 8/28/23 13:12, Boris Brezillon wrote:
> On Sun, 27 Aug 2023 20:54:43 +0300
> Dmitry Osipenko wrote:
>
>> In a preparation of adding drm-shmem memory shrinker, move all reservation
>> locking lockdep checks to use new drm_gem_shmem_resv_assert_held() that
>> will resolve spurious lockdep warning about wrong locking order vs
>> fs_reclam code paths during freeing of shmem GEM, where lockdep isn't
>> aware that it's impossible to have locking contention with the fs_reclam
>> at this special time.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/drm/drm_gem_shmem_helper.c | 37 +-
>> 1 file changed, 25 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
>> b/drivers/gpu/drm/drm_gem_shmem_helper.c
>> index d96fee3d6166..ca5da976aafa 100644
>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
>> @@ -128,6 +128,23 @@ struct drm_gem_shmem_object
>> *drm_gem_shmem_create(struct drm_device *dev, size_t
>> }
>> EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
>>
>> +static void drm_gem_shmem_resv_assert_held(struct drm_gem_shmem_object
>> *shmem)
>> +{
>> +/*
>> + * Destroying the object is a special case.. drm_gem_shmem_free()
>> + * calls many things that WARN_ON if the obj lock is not held. But
>> + * acquiring the obj lock in drm_gem_shmem_free() can cause a locking
>> + * order inversion between reservation_ww_class_mutex and fs_reclaim.
>> + *
>> + * This deadlock is not actually possible, because no one should
>> + * be already holding the lock when drm_gem_shmem_free() is called.
>> + * Unfortunately lockdep is not aware of this detail. So when the
>> + * refcount drops to zero, we pretend it is already locked.
>> + */
>> +if (kref_read(>base.refcount))
>> +drm_gem_shmem_resv_assert_held(shmem);
>> +}
>> +
>> /**
>> * drm_gem_shmem_free - Free resources associated with a shmem GEM object
>> * @shmem: shmem GEM object to free
>> @@ -142,8 +159,6 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
>> *shmem)
>> if (obj->import_attach) {
>> drm_prime_gem_destroy(obj, shmem->sgt);
>> } else if (!shmem->imported_sgt) {
>> -dma_resv_lock(shmem->base.resv, NULL);
>> -
>> drm_WARN_ON(obj->dev, kref_read(>vmap_use_count));
>>
>> if (shmem->sgt) {
>> @@ -156,8 +171,6 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
>> *shmem)
>> drm_gem_shmem_put_pages_locked(shmem);
>
> AFAICT, drm_gem_shmem_put_pages_locked() is the only function that's
> called in the free path and would complain about resv-lock not being
> held. I think I'd feel more comfortable if we were adding a
> drm_gem_shmem_free_pages() function that did everything
> drm_gem_shmem_put_pages_locked() does except for the lock_held() check
> and the refcount dec, and have it called here (and in
> drm_gem_shmem_put_pages_locked()). This way we can keep using
> dma_resv_assert_held() instead of having our own variant.
It's not only drm_gem_shmem_free_pages(), but any drm-shmem function
that drivers may use in the GEM's freeing callback.
For example, panfrost_gem_free_object() may unpin shmem BO and then do
drm_gem_shmem_free().
--
Best regards,
Dmitry
Re: [Intel-gfx] [PATCH v15 12/23] drm/shmem-helper: Add and use pages_pin_count
On 8/28/23 14:46, Boris Brezillon wrote:
> On Sun, 27 Aug 2023 20:54:38 +0300
> Dmitry Osipenko wrote:
>
>> Add separate pages_pin_count for tracking of whether drm-shmem pages are
>> moveable or not. With the addition of memory shrinker support to drm-shmem,
>> the pages_use_count will no longer determine whether pages are hard-pinned
>> in memory, but whether pages exit and are soft-pinned (and could be swapped
>> out). The pages_pin_count > 1 will hard-pin pages in memory.
>>
>> Suggested-by: Boris Brezillon
>> Signed-off-by: Dmitry Osipenko
>> ---
>> drivers/gpu/drm/drm_gem_shmem_helper.c | 22 +-
>> include/drm/drm_gem_shmem_helper.h | 10 ++
>> 2 files changed, 27 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
>> b/drivers/gpu/drm/drm_gem_shmem_helper.c
>> index d545d3d227d7..1a7e5c332fd8 100644
>> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
>> @@ -234,14 +234,22 @@ static int drm_gem_shmem_pin_locked(struct
>> drm_gem_shmem_object *shmem)
>>
>> dma_resv_assert_held(shmem->base.resv);
>>
>> +if (kref_get_unless_zero(>pages_pin_count))
>> +return 0;
>> +
>> ret = drm_gem_shmem_get_pages_locked(shmem);
>> +if (!ret)
>> +kref_init(>pages_pin_count);
>>
>> return ret;
>> }
>>
>> -static void drm_gem_shmem_unpin_locked(struct drm_gem_shmem_object *shmem)
>> +static void drm_gem_shmem_kref_unpin_pages(struct kref *kref)
>> {
>> -dma_resv_assert_held(shmem->base.resv);
>> +struct drm_gem_shmem_object *shmem;
>> +
>> +shmem = container_of(kref, struct drm_gem_shmem_object,
>> + pages_pin_count);
>>
>> drm_gem_shmem_put_pages_locked(shmem);
>> }
>> @@ -263,6 +271,9 @@ int drm_gem_shmem_pin(struct drm_gem_shmem_object *shmem)
>>
>> drm_WARN_ON(obj->dev, obj->import_attach);
>>
>> +if (kref_get_unless_zero(>pages_pin_count))
>> +return 0;
>> +
>> ret = dma_resv_lock_interruptible(shmem->base.resv, NULL);
>> if (ret)
>> return ret;
>> @@ -286,9 +297,10 @@ void drm_gem_shmem_unpin(struct drm_gem_shmem_object
>> *shmem)
>>
>> drm_WARN_ON(obj->dev, obj->import_attach);
>>
>> -dma_resv_lock(shmem->base.resv, NULL);
>> -drm_gem_shmem_unpin_locked(shmem);
>> -dma_resv_unlock(shmem->base.resv);
>> +if (kref_put_dma_resv(>pages_pin_count,
>> + drm_gem_shmem_kref_unpin_pages,
>> + obj->resv, NULL))
>> +dma_resv_unlock(obj->resv);
>> }
>> EXPORT_SYMBOL_GPL(drm_gem_shmem_unpin);
>>
>> diff --git a/include/drm/drm_gem_shmem_helper.h
>> b/include/drm/drm_gem_shmem_helper.h
>> index ec2d8b24e3cf..afb7cd671e2a 100644
>> --- a/include/drm/drm_gem_shmem_helper.h
>> +++ b/include/drm/drm_gem_shmem_helper.h
>> @@ -39,6 +39,16 @@ struct drm_gem_shmem_object {
>> */
>> unsigned int pages_use_count;
>>
>> +/**
>> + * @pages_pin_count:
>> + *
>> + * Reference count on the pinned pages table.
>> + * The pages allowed to be evicted and purged by memory
>> + * shrinker only when the count is zero, otherwise pages
>> + * are hard-pinned in memory.
>> + */
>> +struct kref pages_pin_count;
>
> I know it's tempting to use kref for the pages use/pin count, but I'm
> wondering if we wouldn't be better using a refcount_t, which provides
> overflow/underflow protection while still letting us control how we
> want to handle the locking for 0 <-> 1 transitions. By doing that, we
> avoid introducing core locking changes that might be more
> controversial/longer to get accepted. Besides, I suspect the resulting
> code (the one using a refcount_t) won't be more verbose/complicated (no
> release functions needed if you don't use kref_put(), which makes
> things closer to what we have right now).
Alright, let's try to use refcount_t since Christian also doesn't like kref
--
Best regards,
Dmitry
Re: [Intel-gfx] [PATCH v15 10/23] locking/refcount, kref: Add kref_put_ww_mutex()
On 8/28/23 12:26, Boris Brezillon wrote:
> On Sun, 27 Aug 2023 20:54:36 +0300
> Dmitry Osipenko wrote:
>
>> Introduce kref_put_ww_mutex() helper that will handle the wait-wound
>> mutex auto-locking on kref_put(). This helper is wanted by DRM drivers
>> that extensively use dma-reservation locking which in turns uses ww-mutex.
>>
>> Signed-off-by: Dmitry Osipenko
>> ---
>> include/linux/kref.h | 12
>> include/linux/refcount.h | 5 +
>> lib/refcount.c | 34 ++
>> 3 files changed, 51 insertions(+)
>>
>> diff --git a/include/linux/kref.h b/include/linux/kref.h
>> index d32e21a2538c..b2d8dc6e9ae0 100644
>> --- a/include/linux/kref.h
>> +++ b/include/linux/kref.h
>> @@ -90,6 +90,18 @@ static inline int kref_put_lock(struct kref *kref,
>> return 0;
>> }
>>
>> +static inline int kref_put_ww_mutex(struct kref *kref,
>> +void (*release)(struct kref *kref),
>> +struct ww_mutex *lock,
>> +struct ww_acquire_ctx *ctx)
>> +{
>> +if (refcount_dec_and_ww_mutex_lock(>refcount, lock, ctx)) {
>> +release(kref);
>> +return 1;
>> +}
>> +return 0;
>> +}
>> +
>> /**
>> * kref_get_unless_zero - Increment refcount for object unless it is zero.
>> * @kref: object.
>> diff --git a/include/linux/refcount.h b/include/linux/refcount.h
>> index a62fcca97486..be9ad272bc77 100644
>> --- a/include/linux/refcount.h
>> +++ b/include/linux/refcount.h
>> @@ -99,6 +99,8 @@
>> #include
>>
>> struct mutex;
>> +struct ww_mutex;
>> +struct ww_acquire_ctx;
>>
>> /**
>> * typedef refcount_t - variant of atomic_t specialized for reference counts
>> @@ -366,4 +368,7 @@ extern __must_check bool
>> refcount_dec_and_lock(refcount_t *r, spinlock_t *lock)
>> extern __must_check bool refcount_dec_and_lock_irqsave(refcount_t *r,
>> spinlock_t *lock,
>> unsigned long *flags)
>> __cond_acquires(lock);
>> +extern __must_check bool refcount_dec_and_ww_mutex_lock(refcount_t *r,
>> +struct ww_mutex *lock,
>> +struct ww_acquire_ctx
>> *ctx) __cond_acquires(>base);
>> #endif /* _LINUX_REFCOUNT_H */
>> diff --git a/lib/refcount.c b/lib/refcount.c
>> index a207a8f22b3c..3f6fd0ceed02 100644
>> --- a/lib/refcount.c
>> +++ b/lib/refcount.c
>> @@ -6,6 +6,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>>
>> #define REFCOUNT_WARN(str) WARN_ONCE(1, "refcount_t: " str ".\n")
>> @@ -184,3 +185,36 @@ bool refcount_dec_and_lock_irqsave(refcount_t *r,
>> spinlock_t *lock,
>> return true;
>> }
>> EXPORT_SYMBOL(refcount_dec_and_lock_irqsave);
>> +
>> +/**
>> + * refcount_dec_and_ww_mutex_lock - return holding ww-mutex if able to
>> + * decrement refcount to 0
>> + * @r: the refcount
>> + * @lock: the ww-mutex to be locked
>> + * @ctx: wait-wound context
>> + *
>> + * Similar to atomic_dec_and_lock(), it will WARN on underflow and fail to
>> + * decrement when saturated at REFCOUNT_SATURATED.
>> + *
>> + * Provides release memory ordering, such that prior loads and stores are
>> done
>> + * before, and provides a control dependency such that free() must come
>> after.
>> + * See the comment on top.
>> + *
>> + * Return: true and hold ww-mutex lock if able to decrement refcount to 0,
>> + * false otherwise
>> + */
>> +bool refcount_dec_and_ww_mutex_lock(refcount_t *r, struct ww_mutex *lock,
>> +struct ww_acquire_ctx *ctx)
>> +{
>> +if (refcount_dec_not_one(r))
>> +return false;
>> +
>> +ww_mutex_lock(lock, ctx);
>
> Unless I'm wrong, ww_mutex_lock() can return -EDEADLK when ctx !=
> NULL, in which case, the lock is not held when it returns. Question is,
> do we really have a use case for ctx != NULL in that kref_put_ww_mutex()
> path. If we need to acquire other ww_locks, this lock, and the other
> locks should have been acquired beforehand, and we can simply call
> kref_put() when we want to release the ref on the resource.
Right, I completely forgot about the deadlocking
--
Best regards,
Dmitry
Re: [Intel-gfx] [Intel-xe] [PATCH 3/4] drm/i915/lnl: support FBC on any plane
On Mon, Aug 28, 2023 at 09:20:34AM +0300, Vinod Govindapillai wrote:
> In LNL onwards, FBC can be associated to the first three planes.
The title of this patch shouldn't say "any plane" when the reality is
that only the first three support FBC (the upper two do not).
> The FBC will be enabled for first FBC capable visible plane
> until the userspace can select one of these FBC capable plane
> explicitly
Even if we add new Intel-specific uapi to select this explicitly, is any
userspace actually going to use it? Would it make more sense to try to
come up with a heuristic to guess which plane would benefit the most and
switch to that automatically without userspace needing to be involved in
the decision? For that matter, do we have a real-world use case lined
up where we can see that switching FBC to a higher plane is beneficial?
Even if the hardware suddenly has this capability, it isn't necessarily
worth adding the extra complexity to the driver if we don't expect to
get real-world benefit from it.
BTW, I'm not super familiar with all the FBC-specific details, but it
feels like if we do go forward with this, the decision to select a
specific plane for FBC usage should be handled more deliberately during
the atomic check phase. Right now it doesn't seem like we're really
making a firm decision on which plane to use, and we're probably not
handling all the cases where the register needs to be reprogrammed
if/when the FBC moves from one plane to another (potentially on a
per-frame basis).
>
> Bspec: 69560
> Signed-off-by: Vinod Govindapillai
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 29 +++
> .../drm/i915/display/skl_universal_plane.c| 5 +++-
> drivers/gpu/drm/i915/i915_reg.h | 4 +++
> 3 files changed, 37 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 45e205a0f740..62f59630d410 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -649,6 +649,21 @@ static void skl_fbc_program_cfb_stride(struct intel_fbc
> *fbc)
>CHICKEN_FBC_STRIDE_MASK, val);
> }
>
> +static u32 lnl_plane_binding(struct intel_fbc *fbc)
> +{
> + switch (fbc->state.plane->id) {
> + default:
> + MISSING_CASE(fbc->state.plane->id);
> + fallthrough;
> + case 0:
> + return DPFC_CTL_PLANE_BINDING_1;
> + case 1:
> + return DPFC_CTL_PLANE_BINDING_2;
> + case 2:
> + return DPFC_CTL_PLANE_BINDING_3;
> + }
> +}
> +
> static u32 ivb_dpfc_ctl(struct intel_fbc *fbc)
> {
> const struct intel_fbc_state *fbc_state = >state;
> @@ -660,6 +675,9 @@ static u32 ivb_dpfc_ctl(struct intel_fbc *fbc)
> if (IS_IVYBRIDGE(i915))
> dpfc_ctl |= DPFC_CTL_PLANE_IVB(fbc_state->plane->i9xx_plane);
>
> + if (DISPLAY_VER(i915) >= 20)
> + dpfc_ctl |= lnl_plane_binding(fbc);
> +
> if (fbc_state->fence_id >= 0)
> dpfc_ctl |= DPFC_CTL_FENCE_EN_IVB;
>
> @@ -1250,6 +1268,17 @@ static int intel_fbc_check_plane(struct
> intel_atomic_state *state,
> }
> }
>
> + /*
> + * From LNL, FBC can be assigned on any plane. Until a provision is
> + * provided for the userspace to select a plane for FBC, lets select
> + * the first visible plane that is FBC capable.
> + */
> + if (DISPLAY_VER(i915) >= 20 && fbc->state.plane &&
Isn't the fbc->state.plane here redundant with the plane check on the
next line (since a NULL plane wouldn't match there either)?
> + fbc->state.plane != plane) {
> + plane_state->no_fbc_reason = "fbc enabled on another plane";
If you set this here...
> + return 0;
> + }
> +
> plane_state->no_fbc_reason = NULL;
>
> return 0;
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index 4d01c7ae4485..1291351c9941 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -1962,7 +1962,10 @@ static bool skl_plane_has_fbc(struct drm_i915_private
> *dev_priv,
> if ((DISPLAY_RUNTIME_INFO(dev_priv)->fbc_mask & BIT(fbc_id)) == 0)
> return false;
>
> - return plane_id == PLANE_PRIMARY;
> + if (DISPLAY_VER(dev_priv) >= 20)
> + return plane_id <= PLANE_SPRITE1;
> + else
> + return plane_id == PLANE_PRIMARY;
...and also point all three FBC-capable planes at the pipe's FBC
structure, then won't intel_fbc_update() see the non-NULL reason and try
to turn off the pipe's FBC (even though it's being used on a different
plane)?
Matt
> }
>
> static struct intel_fbc *skl_plane_fbc(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index
Re: [Intel-gfx] [Intel-xe] [PATCH 2/4] drm/i915/lnl: update FBC debugfs to include plane information
On Mon, Aug 28, 2023 at 09:20:33AM +0300, Vinod Govindapillai wrote:
> In future platforms, FBC can be supported on planes other than
"future platforms" on a patch labelled "drm/i915/lnl" makes it sound
like this is something that shows up beyond LNL, which isn't really the
case. The "future" is already here, so I'd drop the "lnl" part of the
subject and just say "With Xe2_LPD and beyond..."
> the primary plane. So update the debugfs entry for FBC status
> to have the plane ID included.
>
> Signed-off-by: Vinod Govindapillai
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index d36499d7e0be..45e205a0f740 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1837,7 +1837,9 @@ static int intel_fbc_debugfs_status_show(struct
> seq_file *m, void *unused)
> mutex_lock(>lock);
>
> if (fbc->active) {
> - seq_puts(m, "FBC enabled\n");
> + seq_printf(m, "FBC enabled: [PLANE:%d:%s]\n",
> +fbc->state.plane->base.base.id,
> +fbc->state.plane->base.name);
> seq_printf(m, "Compressing: %s\n",
> str_yes_no(intel_fbc_is_compressing(fbc)));
> } else {
> @@ -1910,10 +1912,16 @@ static void intel_fbc_debugfs_add(struct intel_fbc
> *fbc,
>
> void intel_fbc_crtc_debugfs_add(struct intel_crtc *crtc)
> {
> - struct intel_plane *plane = to_intel_plane(crtc->base.primary);
> + struct drm_i915_private *i915 = to_i915(crtc->base.dev);
> + struct intel_plane *plane;
> +
> + for_each_intel_plane(>drm, plane) {
You can use for_each_intel_plane_on_crtc here to avoid the pipe check
below.
Matt
> + if (!plane->fbc || plane->pipe != crtc->pipe)
> + continue;
>
> - if (plane->fbc)
> intel_fbc_debugfs_add(plane->fbc, crtc->base.debugfs_entry);
> + break;
> + }
> }
>
> /* FIXME: remove this once igt is on board with per-crtc stuff */
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [Intel-xe] [PATCH 1/4] drm/i915/lnl: FBC can be enabled with PSR2
On Mon, Aug 28, 2023 at 09:20:32AM +0300, Vinod Govindapillai wrote:
> FBC restriction with PSR2 can be removed from LNL onwards
>
> Signed-off-by: Vinod Govindapillai
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 66c8aed07bbc..d36499d7e0be 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1169,11 +1169,11 @@ static int intel_fbc_check_plane(struct
> intel_atomic_state *state,
> }
>
> /*
> - * Display 12+ is not supporting FBC with PSR2.
> + * Display 12 to 14 is not supporting FBC with PSR2.
>* Recommendation is to keep this combination disabled
>* Bspec: 50422 HSD: 14010260002
>*/
> - if (DISPLAY_VER(i915) >= 12 && crtc_state->has_psr2) {
> + if (IS_DISPLAY_VER(i915, 12, 14) && crtc_state->has_psr2) {
According to bspec 68881, the situation is more complicated than just
flipping this back on. FBC + PSR2 should only be enabled together if a
bunch of other conditions are met (multiple planes enabled, selective
fetch is not enabled, etc.). Otherwise we may be hurting power usage
rather than helping it by turning these two on together.
Matt
> plane_state->no_fbc_reason = "PSR2 enabled";
> return 0;
> }
> --
> 2.34.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] ✗ Fi.CI.BAT: failure for Test MTL DMC v2.16 (rev2)
== Series Details ==
Series: Test MTL DMC v2.16 (rev2)
URL : https://patchwork.freedesktop.org/series/122986/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_13572 -> Patchwork_122986v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_122986v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_122986v2, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122986v2/index.html
Participating hosts (39 -> 36)
--
Missing(3): fi-kbl-soraka bat-dg2-9 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_122986v2:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gt_heartbeat:
- fi-hsw-4770:[PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13572/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122986v2/fi-hsw-4770/igt@i915_selftest@live@gt_heartbeat.html
Known issues
Here are the changes found in Patchwork_122986v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-2: [PASS][3] -> [ABORT][4] ([i915#7978] / [i915#8668])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13572/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122986v2/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_suspend@basic-s3-without-i915:
- bat-mtlp-8: NOTRUN -> [SKIP][5] ([i915#6645])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122986v2/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html
Possible fixes
* igt@i915_selftest@live@requests:
- bat-mtlp-8: [ABORT][6] ([i915#7982]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13572/bat-mtlp-8/igt@i915_selftest@l...@requests.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122986v2/bat-mtlp-8/igt@i915_selftest@l...@requests.html
Warnings
* igt@kms_psr@cursor_plane_move:
- bat-rplp-1: [SKIP][8] ([i915#1072]) -> [ABORT][9] ([i915#8469] /
[i915#8668])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13572/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122986v2/bat-rplp-1/igt@kms_psr@cursor_plane_move.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645
[i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
[i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982
[i915#8469]: https://gitlab.freedesktop.org/drm/intel/issues/8469
[i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668
[i915#8879]: https://gitlab.freedesktop.org/drm/intel/issues/8879
Build changes
-
* Linux: CI_DRM_13572 -> Patchwork_122986v2
CI-20190529: 20190529
CI_DRM_13572: f2dfaec0582a995d5e74e5b1896dd6772f5ca9e6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7454: 7454
Patchwork_122986v2: f2dfaec0582a995d5e74e5b1896dd6772f5ca9e6 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
af581650f082 Test MTL DMC v2.16
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122986v2/index.html
Re: [Intel-gfx] [PATCH v5] drm/i915: Avoid circular locking dependency when flush delayed work on gt reset
On 8/23/2023 10:37, John Harrison wrote:
On 8/23/2023 09:00, Daniel Vetter wrote:
On Tue, Aug 22, 2023 at 11:53:24AM -0700, John Harrison wrote:
On 8/11/2023 11:20, Zhanjun Dong wrote:
This attempts to avoid circular locking dependency between flush
delayed
work and intel_gt_reset.
When intel_gt_reset was called, task will hold a lock.
To cacel delayed work here, the _sync version will also acquire a
lock,
which might trigger the possible cirular locking dependency warning.
When intel_gt_reset called, reset_in_progress flag will be set, add
code
to check the flag, call async verion if reset is in progress.
Signed-off-by: Zhanjun Dong
Cc: John Harrison
Cc: Andi Shyti
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
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..600388c849f7 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1359,7 +1359,16 @@ static void
guc_enable_busyness_worker(struct intel_guc *guc)
static void guc_cancel_busyness_worker(struct intel_guc *guc)
{
- cancel_delayed_work_sync(>timestamp.work);
+ /*
+ * When intel_gt_reset was called, task will hold a lock.
+ * To cacel delayed work here, the _sync version will also
acquire a lock, which might
+ * trigger the possible cirular locking dependency warning.
+ * Check the reset_in_progress flag, call async verion if
reset is in progress.
+ */
This needs to explain in much more detail what is going on and why
it is not
a problem. E.g.:
The busyness worker needs to be cancelled. In general that means
using the synchronous cancel version to ensure that an in-progress
worker will not keep executing beyond whatever is happening that
needs the cancel. E.g. suspend, driver unload, etc. However, in the
case of a reset, the synchronous version is not required and can
trigger a false deadlock detection warning.
The business worker takes the reset mutex to protect against resets
interfering with it. However, it does a trylock and bails out if
the
reset lock is already acquired. Thus there is no actual deadlock or
other concern with the worker running concurrently with a reset. So
an asynchronous cancel is safe in the case of a reset rather than a
driver unload or suspend type operation. On the other hand, if the
cancel_sync version is used when a reset is in progress then the
mutex deadlock detection sees the mutex being acquired through
multiple paths and complains.
So just don't bother. That keeps the detection code happy and is
safe because of the trylock code described above.
So why do we even need to cancel anything if it doesn't do anything
while
the reset is in progress?
It still needs to be cancelled. The worker only aborts if it is
actively executing concurrently with the reset. It might not start to
execute until after the reset has completed. And there is presumably a
reason why the cancel is being called, a reason not necessarily
related to resets at all. Leaving the worker to run arbitrarily after
the driver is expecting it to be stopped will lead to much worse
things than a fake lockdep splat, e.g. a use after free pointer deref.
John.
@Daniel Vetter - ping? Is this explanation sufficient? Are you okay with
this change now?
John.
Just remove the cancel from the reset path as uneeded instead, and
explain
why that's ok? Because that's defacto what the cancel_work with a
potential deadlock scenario for cancel_work_sync does, you either don't
need it at all, or the replacement creates a bug.
-Daniel
John.
+ if (guc_to_gt(guc)->uc.reset_in_progress)
+ cancel_delayed_work(>timestamp.work);
+ else
+ cancel_delayed_work_sync(>timestamp.work);
}
static void __reset_guc_busyness_stats(struct intel_guc *guc)
Re: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout threshold
Hi Gustavo,
> -Original Message-
> From: Sousa, Gustavo
> Sent: Monday, August 28, 2023 2:46 PM
> To: Sripada, Radhakrishna ; intel-
> g...@lists.freedesktop.org
> Subject: RE: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus
> timeout threshold
>
> Quoting Sripada, Radhakrishna (2023-08-28 17:30:19-03:00)
> >Hi Gustavo,
>
> Hi, RK.
>
> Thanks for the feedback! Please, see my replies below.
>
> >
> >> -Original Message-
> >> From: Intel-gfx On Behalf Of
> Gustavo
> >> Sousa
> >> Sent: Monday, August 28, 2023 10:34 AM
> >> To: intel-gfx@lists.freedesktop.org
> >> Subject: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus
> timeout
> >> threshold
> >>
> >> We have experienced timeout issues when accessing C20 SRAM registers.
> >This wording is misleading. It seems to imply that we directly access SRAM
> >registers via msg bus but the reads/writes go through intermediate registers
> >and it is this read/write that is failing. Adding extra clarity here would
> >be helpful.
>
> Hm... Okay. I thought that would already be implied to someone familiar with
> the
> code. What about:
>
> s/when accessing/when going through the sequence to access/
This is better to indicate that it is not direct access.
>
> ?
>
> >
> >> Experimentation showed that bumping the message bus timer threshold
> >> helped on getting display Type-C connection on the C20 PHY to work.
> >>
> >> While the timeout is still under investigation with the HW team, having
> >> logic to allow forward progress (with the proper warnings) seems useful.
> >> Thus, let's bump the threshold when a timeout is detected.
> >>
> >> The maximum value of 0x200 pclk cycles was somewhat arbitrary - 2x the
> >> default value. That value was successfully tested on real hardware that
> >> was displaying timeouts otherwise.
> >>
> >> BSpec: 65156
> >> Signed-off-by: Gustavo Sousa
> >> ---
> >> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 41 +++
> >> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 12 ++
> >> 2 files changed, 53 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> index dd489b50ad60..55d2333032e3 100644
> >> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> >> @@ -5,6 +5,7 @@
> >>
> >> #include
> >> #include
> >> +#include
> >> #include "i915_reg.h"
> >> #include "intel_cx0_phy.h"
> >> #include "intel_cx0_phy_regs.h"
> >> @@ -29,6 +30,8 @@
> >> #define INTEL_CX0_LANE1BIT(1)
> >> #define INTEL_CX0_BOTH_LANES(INTEL_CX0_LANE1 |
> >> INTEL_CX0_LANE0)
> >>
> >> +#define INTEL_CX0_MSGBUS_TIMER_VAL_MAX0x200
> >> +
> >> bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
> >> {
> >> if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C)
> >> @@ -119,6 +122,43 @@ static void intel_cx0_bus_reset(struct
> drm_i915_private
> >> *i915, enum port port, i
> >> intel_clear_response_ready_flag(i915, port, lane);
> >> }
> >>
> >> +/*
> >> + * Check if there was a timeout detected by the hardware in the message
> >> bus
> >> + * and bump the threshold if so.
> >> + */
> >> +static void intel_cx0_bus_check_and_bump_timer(struct drm_i915_private
> >> *i915,
> >> + enum port port, int lane)
> >> +{
> >> +enum phy phy = intel_port_to_phy(i915, port);
> >> +i915_reg_t reg;
> >> +u32 val;
> >> +u32 timer_val;
> >> +
> >> +reg = XELPDP_PORT_MSGBUS_TIMER(port, lane);
> >> +val = intel_de_read(i915, reg);
> >> +
> >> +if (!(val & XELPDP_PORT_MSGBUS_TIMER_TIMED_OUT)) {
> >> +drm_warn(>drm,
> >> + "PHY %c lane %d: hardware did not detect a
> >> timeout\n",
> >> + phy_name(phy), lane);
> >> +return;
> >> +}
> >> +
> >> +timer_val =
> >> REG_FIELD_GET(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK, val);
> >> +
> >> +if (timer_val == INTEL_CX0_MSGBUS_TIMER_VAL_MAX)
> >> +return;
> >> +
> >> +timer_val = min(2 * timer_val,
> >> (u32)INTEL_CX0_MSGBUS_TIMER_VAL_MAX);
> > ^ is this cast necessary?
>
> Yes. I remember getting a warning without it. Let me remove it to remember...
Got it thanks for the quick check.
>
> ...done! I think it complains because the arguments are of different types:
>
> In file included from drivers/gpu/drm/i915/display/intel_cx0_phy.c:8:
> drivers/gpu/drm/i915/display/intel_cx0_phy.c: In function
> ‘intel_cx0_bus_check_and_bump_timer’:
> ./include/linux/minmax.h:20:35: error: comparison of distinct pointer
> types
> lacks a cast [-Werror]
>20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
> | ^~
> ./include/linux/minmax.h:26:18: note: in expansion of macro
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/cx0: Check and increase msgbus timeout threshold
== Series Details == Series: drm/i915/cx0: Check and increase msgbus timeout threshold URL : https://patchwork.freedesktop.org/series/122982/ State : success == Summary == CI Bug Log - changes from CI_DRM_13571_full -> Patchwork_122982v1_full Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/index.html Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_122982v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@render-ccs: - shard-dg2: NOTRUN -> [FAIL][1] ([i915#6122]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-11/igt@api_intel...@render-ccs.html * igt@drm_fdinfo@busy-hang@bcs0: - shard-dg2: NOTRUN -> [SKIP][2] ([i915#8414]) +9 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-11/igt@drm_fdinfo@busy-h...@bcs0.html * igt@gem_ctx_persistence@engines-hostile: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-snb7/igt@gem_ctx_persiste...@engines-hostile.html * igt@gem_ctx_persistence@hang: - shard-dg2: NOTRUN -> [SKIP][4] ([i915#8555]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-11/igt@gem_ctx_persiste...@hang.html * igt@gem_ctx_sseu@invalid-sseu: - shard-dg2: NOTRUN -> [SKIP][5] ([i915#280]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-8/igt@gem_ctx_s...@invalid-sseu.html * igt@gem_eio@in-flight-contexts-10ms: - shard-mtlp: [PASS][6] -> [ABORT][7] ([i915#7941]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-mtlp-6/igt@gem_...@in-flight-contexts-10ms.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-mtlp-1/igt@gem_...@in-flight-contexts-10ms.html * igt@gem_eio@in-flight-contexts-1us: - shard-mtlp: [PASS][8] -> [ABORT][9] ([i915#8503]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-mtlp-4/igt@gem_...@in-flight-contexts-1us.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-mtlp-2/igt@gem_...@in-flight-contexts-1us.html * igt@gem_eio@kms: - shard-dg1: [PASS][10] -> [FAIL][11] ([i915#5784]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-dg1-13/igt@gem_...@kms.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg1-13/igt@gem_...@kms.html * igt@gem_exec_balancer@bonded-semaphore: - shard-dg2: NOTRUN -> [SKIP][12] ([i915#4812]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-8/igt@gem_exec_balan...@bonded-semaphore.html * igt@gem_exec_flush@basic-batch-kernel-default-uc: - shard-mtlp: [PASS][13] -> [DMESG-FAIL][14] ([i915#8962] / [i915#9121]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-mtlp-2/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-mtlp-4/igt@gem_exec_fl...@basic-batch-kernel-default-uc.html * igt@gem_exec_flush@basic-uc-rw-default: - shard-dg2: NOTRUN -> [SKIP][15] ([i915#3539] / [i915#4852]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-11/igt@gem_exec_fl...@basic-uc-rw-default.html * igt@gem_exec_reloc@basic-cpu-gtt-active: - shard-dg2: NOTRUN -> [SKIP][16] ([i915#3281]) +7 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-8/igt@gem_exec_re...@basic-cpu-gtt-active.html * igt@gem_exec_schedule@preempt-queue-contexts-chain: - shard-dg2: NOTRUN -> [SKIP][17] ([i915#4537] / [i915#4812]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-11/igt@gem_exec_sched...@preempt-queue-contexts-chain.html * igt@gem_exec_suspend@basic-s0@smem: - shard-dg2: [PASS][18] -> [INCOMPLETE][19] ([i915#6311]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-dg2-10/igt@gem_exec_suspend@basic...@smem.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-2/igt@gem_exec_suspend@basic...@smem.html * igt@gem_fence_thrash@bo-write-verify-none: - shard-dg2: NOTRUN -> [SKIP][20] ([i915#4860]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/shard-dg2-11/igt@gem_fence_thr...@bo-write-verify-none.html * igt@gem_lmem_swapping@verify-random: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [i915#4613]) [21]:
[Intel-gfx] [PATCH 1/1] [CI] Test MTL DMC v2.16
NOT TO BE REVIEWED/MERGED. Hardcode DMC path to i915/mtl_dmc_ver2_16.bin for CI purposes. Signed-off-by: Gustavo Sousa --- drivers/gpu/drm/i915/display/intel_dmc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c index 1623c0c5e8a1..a7667302a68c 100644 --- a/drivers/gpu/drm/i915/display/intel_dmc.c +++ b/drivers/gpu/drm/i915/display/intel_dmc.c @@ -93,7 +93,7 @@ static struct intel_dmc *i915_to_dmc(struct drm_i915_private *i915) #define DISPLAY_VER13_DMC_MAX_FW_SIZE 0x2 #define DISPLAY_VER12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE -#define MTL_DMC_PATH DMC_PATH(mtl) +#define MTL_DMC_PATH "i915/mtl_dmc_ver2_16.bin" MODULE_FIRMWARE(MTL_DMC_PATH); #define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08) -- 2.41.0
[Intel-gfx] [PATCH 0/1] [CI] Test MTL DMC v2.16
The following changes since commit db99828b2466119dc068d564066192347105: copy-firmware: Introduce 'RawFile' keyword (2023-08-28 07:18:15 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware CI-dmc-mtl_2.16 for you to fetch changes up to 918ffce8105a3514434c93e97fd54b80fb20a96e: [CI] MTL DMC v2.16 (2023-08-28 16:35:31 -0300) Gustavo Sousa (1): [CI] MTL DMC v2.16 i915/mtl_dmc_ver2_16.bin | Bin 0 -> 52388 bytes 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 i915/mtl_dmc_ver2_16.bin
Re: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout threshold
Quoting Sripada, Radhakrishna (2023-08-28 17:30:19-03:00)
>Hi Gustavo,
Hi, RK.
Thanks for the feedback! Please, see my replies below.
>
>> -Original Message-
>> From: Intel-gfx On Behalf Of
>> Gustavo
>> Sousa
>> Sent: Monday, August 28, 2023 10:34 AM
>> To: intel-gfx@lists.freedesktop.org
>> Subject: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout
>> threshold
>>
>> We have experienced timeout issues when accessing C20 SRAM registers.
>This wording is misleading. It seems to imply that we directly access SRAM
>registers via msg bus but the reads/writes go through intermediate registers
>and it is this read/write that is failing. Adding extra clarity here would be
>helpful.
Hm... Okay. I thought that would already be implied to someone familiar with the
code. What about:
s/when accessing/when going through the sequence to access/
?
>
>> Experimentation showed that bumping the message bus timer threshold
>> helped on getting display Type-C connection on the C20 PHY to work.
>>
>> While the timeout is still under investigation with the HW team, having
>> logic to allow forward progress (with the proper warnings) seems useful.
>> Thus, let's bump the threshold when a timeout is detected.
>>
>> The maximum value of 0x200 pclk cycles was somewhat arbitrary - 2x the
>> default value. That value was successfully tested on real hardware that
>> was displaying timeouts otherwise.
>>
>> BSpec: 65156
>> Signed-off-by: Gustavo Sousa
>> ---
>> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 41 +++
>> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 12 ++
>> 2 files changed, 53 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> index dd489b50ad60..55d2333032e3 100644
>> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
>> @@ -5,6 +5,7 @@
>>
>> #include
>> #include
>> +#include
>> #include "i915_reg.h"
>> #include "intel_cx0_phy.h"
>> #include "intel_cx0_phy_regs.h"
>> @@ -29,6 +30,8 @@
>> #define INTEL_CX0_LANE1BIT(1)
>> #define INTEL_CX0_BOTH_LANES(INTEL_CX0_LANE1 |
>> INTEL_CX0_LANE0)
>>
>> +#define INTEL_CX0_MSGBUS_TIMER_VAL_MAX0x200
>> +
>> bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
>> {
>> if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C)
>> @@ -119,6 +122,43 @@ static void intel_cx0_bus_reset(struct drm_i915_private
>> *i915, enum port port, i
>> intel_clear_response_ready_flag(i915, port, lane);
>> }
>>
>> +/*
>> + * Check if there was a timeout detected by the hardware in the message bus
>> + * and bump the threshold if so.
>> + */
>> +static void intel_cx0_bus_check_and_bump_timer(struct drm_i915_private
>> *i915,
>> + enum port port, int lane)
>> +{
>> +enum phy phy = intel_port_to_phy(i915, port);
>> +i915_reg_t reg;
>> +u32 val;
>> +u32 timer_val;
>> +
>> +reg = XELPDP_PORT_MSGBUS_TIMER(port, lane);
>> +val = intel_de_read(i915, reg);
>> +
>> +if (!(val & XELPDP_PORT_MSGBUS_TIMER_TIMED_OUT)) {
>> +drm_warn(>drm,
>> + "PHY %c lane %d: hardware did not detect a
>> timeout\n",
>> + phy_name(phy), lane);
>> +return;
>> +}
>> +
>> +timer_val =
>> REG_FIELD_GET(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK, val);
>> +
>> +if (timer_val == INTEL_CX0_MSGBUS_TIMER_VAL_MAX)
>> +return;
>> +
>> +timer_val = min(2 * timer_val,
>> (u32)INTEL_CX0_MSGBUS_TIMER_VAL_MAX);
> ^ is this cast necessary?
Yes. I remember getting a warning without it. Let me remove it to remember...
...done! I think it complains because the arguments are of different types:
In file included from drivers/gpu/drm/i915/display/intel_cx0_phy.c:8:
drivers/gpu/drm/i915/display/intel_cx0_phy.c: In function
‘intel_cx0_bus_check_and_bump_timer’:
./include/linux/minmax.h:20:35: error: comparison of distinct pointer types
lacks a cast [-Werror]
20 | (!!(sizeof((typeof(x) *)1 == (typeof(y) *)1)))
| ^~
./include/linux/minmax.h:26:18: note: in expansion of macro ‘__typecheck’
26 | (__typecheck(x, y) && __no_side_effects(x, y))
| ^~~
./include/linux/minmax.h:36:31: note: in expansion of macro ‘__safe_cmp’
36 | __builtin_choose_expr(__safe_cmp(x, y), \
| ^~
./include/linux/minmax.h:67:25: note: in expansion of macro ‘__careful_cmp’
67 | #define min(x, y) __careful_cmp(x, y, <)
| ^
drivers/gpu/drm/i915/display/intel_cx0_phy.c:152:21: note: in expansion of
macro ‘min’
152 |
Re: [Intel-gfx] [PATCH] drm/i915/guc: fix compile issue of guc_klvs_abi.h
On 25.08.2023 07:50, Linyu Yuan wrote: > > On 8/25/2023 1:37 PM, Jani Nikula wrote: >> On Fri, 25 Aug 2023, Linyu Yuan wrote: >>> GCC report GUC_KLV_0_KEY and GUC_KLV_0_LEN is not constant when do >>> preprocessing. >> Please paste the actual compiler warning. > > > CC drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o > In file included from :0:0: > In function ‘__guc_context_policy_add_priority.isra.47’, > inlined from ‘__guc_context_set_prio.isra.48’ at > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3332:3, > inlined from ‘guc_context_set_prio’ at > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3360:2: > ././include/linux/compiler_types.h:397:38: error: call to > ‘__compiletime_assert_1803’ declared with attribute error: FIELD_PREP: > mask is not constant > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ././include/linux/compiler_types.h:378:4: note: in definition of macro > ‘__compiletime_assert’ > prefix ## suffix(); \ > ^~ > ././include/linux/compiler_types.h:397:2: note: in expansion of macro > ‘_compiletime_assert’ > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^~~ > ./include/linux/build_bug.h:39:37: note: in expansion of macro > ‘compiletime_assert’ > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > ^~ > ./include/linux/bitfield.h:65:3: note: in expansion of macro > ‘BUILD_BUG_ON_MSG’ > BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ > ^~~~ > ./include/linux/bitfield.h:114:3: note: in expansion of macro > ‘__BF_FIELD_CHECK’ > __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ > ^~~~ > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2461:3: note: in > expansion of macro ‘FIELD_PREP’ > FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ > ^~ > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2469:1: note: in > expansion of macro ‘MAKE_CONTEXT_POLICY_ADD’ > MAKE_CONTEXT_POLICY_ADD(priority, SCHEDULING_PRIORITY) > ^~~ > In function ‘__guc_context_policy_add_preemption_timeout.isra.51’, > inlined from ‘__guc_context_set_preemption_timeout’ at > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3005:3: > ././include/linux/compiler_types.h:397:38: error: call to > ‘__compiletime_assert_1793’ declared with attribute error: FIELD_PREP: > mask is not constant > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ././include/linux/compiler_types.h:378:4: note: in definition of macro > ‘__compiletime_assert’ > prefix ## suffix(); \ > ^~ > ././include/linux/compiler_types.h:397:2: note: in expansion of macro > ‘_compiletime_assert’ > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^~~ > ./include/linux/build_bug.h:39:37: note: in expansion of macro > ‘compiletime_assert’ > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > ^~ > ./include/linux/bitfield.h:65:3: note: in expansion of macro > ‘BUILD_BUG_ON_MSG’ > BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ > ^~~~ > ./include/linux/bitfield.h:114:3: note: in expansion of macro > ‘__BF_FIELD_CHECK’ > __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ > ^~~~ > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2461:3: note: in > expansion of macro ‘FIELD_PREP’ > FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ > ^~ > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2468:1: note: in > expansion of macro ‘MAKE_CONTEXT_POLICY_ADD’ > MAKE_CONTEXT_POLICY_ADD(preemption_timeout, PREEMPTION_TIMEOUT) > ^~~ > In function ‘__guc_context_policy_add_priority.isra.47’, > inlined from ‘__guc_add_request’ at > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2503:2: > ././include/linux/compiler_types.h:397:38: error: call to > ‘__compiletime_assert_1803’ declared with attribute error: FIELD_PREP: > mask is not constant > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^ > ././include/linux/compiler_types.h:378:4: note: in definition of macro > ‘__compiletime_assert’ > prefix ## suffix(); \ > ^~ > ././include/linux/compiler_types.h:397:2: note: in expansion of macro > ‘_compiletime_assert’ > _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) > ^~~ > ./include/linux/build_bug.h:39:37: note: in expansion of macro > ‘compiletime_assert’ > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) > ^~ > ./include/linux/bitfield.h:65:3: note: in expansion of macro >
Re: [Intel-gfx] [PATCH v6 1/4] drm: Use XArray instead of IDR for minors
On Fri, Aug 25, 2023 at 12:59:26PM -0400, James Zhu wrote:
>
> On 2023-07-24 17:14, Michał Winiarski wrote:
> > IDR is deprecated, and since XArray manages its own state with internal
> > locking, it simplifies the locking on DRM side.
> > Additionally, don't use the IRQ-safe variant, since operating on drm
> > minor is not done in IRQ context.
> >
> > Signed-off-by: Michał Winiarski
> > Suggested-by: Matthew Wilcox
> > ---
> > drivers/gpu/drm/drm_drv.c | 63 ---
> > 1 file changed, 25 insertions(+), 38 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 3eda026ffac6..3faecb01186f 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > #include
> > @@ -54,8 +55,7 @@ MODULE_AUTHOR("Gareth Hughes, Leif Delgass, José Fonseca,
> > Jon Smirl");
> > MODULE_DESCRIPTION("DRM shared core routines");
> > MODULE_LICENSE("GPL and additional rights");
> > -static DEFINE_SPINLOCK(drm_minor_lock);
> > -static struct idr drm_minors_idr;
> > +static DEFINE_XARRAY_ALLOC(drm_minors_xa);
> > /*
> >* If the drm core fails to init for whatever reason,
> > @@ -101,26 +101,23 @@ static struct drm_minor **drm_minor_get_slot(struct
> > drm_device *dev,
> > static void drm_minor_alloc_release(struct drm_device *dev, void *data)
> > {
> > struct drm_minor *minor = data;
> > - unsigned long flags;
> > WARN_ON(dev != minor->dev);
> > put_device(minor->kdev);
> > - if (minor->type == DRM_MINOR_ACCEL) {
> > + if (minor->type == DRM_MINOR_ACCEL)
> > accel_minor_remove(minor->index);
> > - } else {
> > - spin_lock_irqsave(_minor_lock, flags);
> > - idr_remove(_minors_idr, minor->index);
> > - spin_unlock_irqrestore(_minor_lock, flags);
> > - }
> > + else
> > + xa_erase(_minors_xa, minor->index);
> > }
> > +#define DRM_MINOR_LIMIT(t) ({ typeof(t) _t = (t); XA_LIMIT(64 * _t, 64 *
> > _t + 63); })
> > +
> > static int drm_minor_alloc(struct drm_device *dev, enum drm_minor_type
> > type)
> > {
> > struct drm_minor *minor;
> > - unsigned long flags;
> > - int r;
> > + int index, r;
> > minor = drmm_kzalloc(dev, sizeof(*minor), GFP_KERNEL);
> > if (!minor)
> > @@ -129,24 +126,17 @@ static int drm_minor_alloc(struct drm_device *dev,
> > enum drm_minor_type type)
> > minor->type = type;
> > minor->dev = dev;
> > - idr_preload(GFP_KERNEL);
> > if (type == DRM_MINOR_ACCEL) {
> > r = accel_minor_alloc();
> > + index = r;
> > } else {
> > - spin_lock_irqsave(_minor_lock, flags);
> > - r = idr_alloc(_minors_idr,
> > - NULL,
> > - 64 * type,
> > - 64 * (type + 1),
> > - GFP_NOWAIT);
> > - spin_unlock_irqrestore(_minor_lock, flags);
> > + r = xa_alloc(_minors_xa, , NULL,
> > DRM_MINOR_LIMIT(type), GFP_KERNEL);
> > }
> > - idr_preload_end();
> > if (r < 0)
> > return r;
> > - minor->index = r;
> > + minor->index = index;
> > r = drmm_add_action_or_reset(dev, drm_minor_alloc_release, minor);
> > if (r)
> > @@ -163,7 +153,7 @@ static int drm_minor_alloc(struct drm_device *dev, enum
> > drm_minor_type type)
> > static int drm_minor_register(struct drm_device *dev, enum drm_minor_type
> > type)
> > {
> > struct drm_minor *minor;
> > - unsigned long flags;
> > + void *entry;
> > int ret;
> > DRM_DEBUG("\n");
> > @@ -190,9 +180,12 @@ static int drm_minor_register(struct drm_device *dev,
> > enum drm_minor_type type)
> > if (minor->type == DRM_MINOR_ACCEL) {
> > accel_minor_replace(minor, minor->index);
> > } else {
> > - spin_lock_irqsave(_minor_lock, flags);
> > - idr_replace(_minors_idr, minor, minor->index);
> > - spin_unlock_irqrestore(_minor_lock, flags);
> > + entry = xa_store(_minors_xa, minor->index, minor,
> > GFP_KERNEL);
> > + if (xa_is_err(entry)) {
> > + ret = xa_err(entry);
> > + goto err_debugfs;
> > + }
> > + WARN_ON(entry);
> [JZ] would WARN_ON(entry != minor)be better?
We expect NULL here.
The same one that was previously stored here ⌄⌄⌄
r = xa_alloc(_minors_xa, >index, NULL, DRM_EXTENDED_MINOR_LIMIT,
GFP_KERNEL);
in drm_minor_alloc.
> > }
> > DRM_DEBUG("new minor registered %d\n", minor->index);
> > @@ -206,20 +199,16 @@ static int drm_minor_register(struct drm_device *dev,
> > enum drm_minor_type type)
> > static void drm_minor_unregister(struct drm_device *dev, enum
> > drm_minor_type type)
> > {
> > struct drm_minor *minor;
> > - unsigned long flags;
> > minor = *drm_minor_get_slot(dev, type);
> > if (!minor || !device_is_registered(minor->kdev))
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Close deregister-context race against CT-loss
Additional update from the most recent testing. When relying solely on guc_lrc_desc_unpin getting a failure from deregister_context as a means for identifying that we are in the "deregister-context-vs-suspend-late" race, it is too late a location to handle this safely. This is because one of the first things destroyed_worker_func does it to take a gt pm wakeref - which triggers the gt_unpark function that does a whole lot bunch of other flows including triggering more workers and taking additional refs. That said, its best to not even call deregister_destroyed_contexts from the worker when !intel_guc_is_ready (ct-is-disabled). ...alan On Fri, 2023-08-25 at 11:54 -0700, Teres Alexis, Alan Previn wrote: > just a follow up note-to-self: > > On Tue, 2023-08-15 at 12:08 -0700, Teres Alexis, Alan Previn wrote: > > On Tue, 2023-08-15 at 09:56 -0400, Vivi, Rodrigo wrote: > > > On Mon, Aug 14, 2023 at 06:12:09PM -0700, Alan Previn wrote: > > > > > [snip] > > in guc_submission_send_busy_loop, we are incrementing the following > that needs to be decremented if the function fails. > > atomic_inc(>outstanding_submission_g2h); > > also, it seems that even with thie unroll design - we are still > leaking a wakeref elsewhere. this is despite a cleaner redesign of > flows in function "guc_lrc_desc_unpin" > (discussed earlier that wasnt very readible). > > will re-rev today but will probably need more follow ups > tracking that one more leaking gt-wakeref (one in thousands-cycles) > but at least now we are not hanging mid-suspend.. we bail from suspend > with useful kernel messages. > > > >
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Wait longer for tasks in migrate selftest
== Series Details == Series: drm/i915/gt: Wait longer for tasks in migrate selftest URL : https://patchwork.freedesktop.org/series/122984/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13571 -> Patchwork_122984v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_122984v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122984v1, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/index.html Participating hosts (38 -> 38) -- Additional (1): bat-adlp-11 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122984v1: ### IGT changes ### Possible regressions * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-6: - bat-adlp-11:NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-6.html New tests - New tests have been introduced between CI_DRM_13571 and Patchwork_122984v1: ### New IGT tests (7) ### * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-xr24@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@hang-read-crc@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-8: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-b-dp-5: - Statuses : 1 dmesg-fail(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-c-dp-8: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@read-crc@pipe-c-dp-8: - Statuses : 1 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_122984v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlp-11:NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.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_122984v1/bat-adlp-11/igt@gem_tiled_pread_basic.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][4] -> [DMESG-FAIL][5] ([i915#5334] / [i915#7872]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][6] ([i915#6645]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-11:NOTRUN -> [SKIP][7] ([i915#4103]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-adlp-11:NOTRUN -> [SKIP][8] ([i915#4093]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-b-dp-5 (NEW): - bat-adlp-11:NOTRUN -> [DMESG-FAIL][9] ([i915#6868]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/bat-adlp-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-b-dp-5.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-dp-2: - bat-adlp-11:NOTRUN -> [ABORT][10] ([i915#8668]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/bat-adlp-11/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-dp-2.html * igt@kms_psr@cursor_plane_move: - bat-rplp-1: NOTRUN -> [SKIP][11] ([i915#1072]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/bat-rplp-1/igt@kms_psr@cursor_plane_move.html * igt@kms_psr@primary_page_flip: - bat-adlp-6: NOTRUN -> [ABORT][12] ([i915#8442] / [i915#8668]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122984v1/bat-adlp-6/igt@kms_psr@primary_page_flip.html * igt@kms_psr@sprite_plane_onoff: - bat-rplp-1: NOTRUN ->
Re: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout threshold
Hi Gustavo,
> -Original Message-
> From: Intel-gfx On Behalf Of Gustavo
> Sousa
> Sent: Monday, August 28, 2023 10:34 AM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout
> threshold
>
> We have experienced timeout issues when accessing C20 SRAM registers.
This wording is misleading. It seems to imply that we directly access SRAM
registers via msg bus but the reads/writes go through intermediate registers
and it is this read/write that is failing. Adding extra clarity here would be
helpful.
> Experimentation showed that bumping the message bus timer threshold
> helped on getting display Type-C connection on the C20 PHY to work.
>
> While the timeout is still under investigation with the HW team, having
> logic to allow forward progress (with the proper warnings) seems useful.
> Thus, let's bump the threshold when a timeout is detected.
>
> The maximum value of 0x200 pclk cycles was somewhat arbitrary - 2x the
> default value. That value was successfully tested on real hardware that
> was displaying timeouts otherwise.
>
> BSpec: 65156
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 41 +++
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 12 ++
> 2 files changed, 53 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index dd489b50ad60..55d2333032e3 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
> #include "i915_reg.h"
> #include "intel_cx0_phy.h"
> #include "intel_cx0_phy_regs.h"
> @@ -29,6 +30,8 @@
> #define INTEL_CX0_LANE1 BIT(1)
> #define INTEL_CX0_BOTH_LANES (INTEL_CX0_LANE1 |
> INTEL_CX0_LANE0)
>
> +#define INTEL_CX0_MSGBUS_TIMER_VAL_MAX 0x200
> +
> bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
> {
> if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C)
> @@ -119,6 +122,43 @@ static void intel_cx0_bus_reset(struct drm_i915_private
> *i915, enum port port, i
> intel_clear_response_ready_flag(i915, port, lane);
> }
>
> +/*
> + * Check if there was a timeout detected by the hardware in the message bus
> + * and bump the threshold if so.
> + */
> +static void intel_cx0_bus_check_and_bump_timer(struct drm_i915_private
> *i915,
> +enum port port, int lane)
> +{
> + enum phy phy = intel_port_to_phy(i915, port);
> + i915_reg_t reg;
> + u32 val;
> + u32 timer_val;
> +
> + reg = XELPDP_PORT_MSGBUS_TIMER(port, lane);
> + val = intel_de_read(i915, reg);
> +
> + if (!(val & XELPDP_PORT_MSGBUS_TIMER_TIMED_OUT)) {
> + drm_warn(>drm,
> + "PHY %c lane %d: hardware did not detect a
> timeout\n",
> + phy_name(phy), lane);
> + return;
> + }
> +
> + timer_val =
> REG_FIELD_GET(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK, val);
> +
> + if (timer_val == INTEL_CX0_MSGBUS_TIMER_VAL_MAX)
> + return;
> +
> + timer_val = min(2 * timer_val,
> (u32)INTEL_CX0_MSGBUS_TIMER_VAL_MAX);
^ is this cast necessary?
> + val &= ~XELPDP_PORT_MSGBUS_TIMER_VAL_MASK;
> + val |= REG_FIELD_PREP(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK,
> timer_val);
We do not use REG_FIELD_PREP in the function. Instead we use it in
register definition in intel_cx0_phy_regs.h.
Thanks,
Radhakrishna Sripada
> +
> + drm_dbg_kms(>drm,
> + "PHY %c lane %d: increasing msgbus timer threshold to
> %#x\n",
> + phy_name(phy), lane, timer_val);
> + intel_de_write(i915, reg, val);
> +}
> +
> static int intel_cx0_wait_for_ack(struct drm_i915_private *i915, enum port
> port,
> int command, int lane, u32 *val)
> {
> @@ -132,6 +172,7 @@ static int intel_cx0_wait_for_ack(struct
> drm_i915_private *i915, enum port port,
>XELPDP_MSGBUS_TIMEOUT_SLOW,
> val)) {
> drm_dbg_kms(>drm, "PHY %c Timeout waiting for
> message ACK. Status: 0x%x\n",
> phy_name(phy), *val);
> + intel_cx0_bus_check_and_bump_timer(i915, port, lane);
> intel_cx0_bus_reset(i915, port, lane);
> return -ETIMEDOUT;
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> index cb5d1be2ba19..17cc3385aabb 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
> @@ -110,6 +110,18 @@
> #define CX0_P4PG_STATE_DISABLE 0xC
> #define CX0_P2_STATE_RESET 0x2
>
> +#define _XELPDP_PORT_MSGBUS_TIMER_LN0_A
> 0x640d8
> +#define _XELPDP_PORT_MSGBUS_TIMER_LN0_B
> 0x641d8
>
Re: [Intel-gfx] [PATCH v2] drm: Update file owner during use
On Wed, Jun 21, 2023 at 2:48 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> With the typical model where the display server opens the file descriptor
> and then hands it over to the client(*), we were showing stale data in
> debugfs.
>
> Fix it by updating the drm_file->pid on ioctl access from a different
> process.
>
> The field is also made RCU protected to allow for lockless readers. Update
> side is protected with dev->filelist_mutex.
>
> Before:
>
> $ cat /sys/kernel/debug/dri/0/clients
> command pid dev master a uid magic
> Xorg 2344 0 yy 0 0
> Xorg 2344 0 ny 0 2
> Xorg 2344 0 ny 0 3
> Xorg 2344 0 ny 0 4
>
> After:
>
> $ cat /sys/kernel/debug/dri/0/clients
> command tgid dev master a uid magic
> Xorg 830 0 yy 0 0
>xfce4-session 880 0 ny 0 1
>xfwm4 943 0 ny 0 2
>neverball 1095 0 ny 0 3
>
> *)
> More detailed and historically accurate description of various handover
> implementation kindly provided by Emil Velikov:
>
> """
> The traditional model, the server was the orchestrator managing the
> primary device node. From the fd, to the master status and
> authentication. But looking at the fd alone, this has varied across
> the years.
>
> IIRC in the DRI1 days, Xorg (libdrm really) would have a list of open
> fd(s) and reuse those whenever needed, DRI2 the client was responsible
> for open() themselves and with DRI3 the fd was passed to the client.
>
> Around the inception of DRI3 and systemd-logind, the latter became
> another possible orchestrator. Whereby Xorg and Wayland compositors
> could ask it for the fd. For various reasons (hysterical and genuine
> ones) Xorg has a fallback path going the open(), whereas Wayland
> compositors are moving to solely relying on logind... some never had
> fallback even.
>
> Over the past few years, more projects have emerged which provide
> functionality similar (be that on API level, Dbus, or otherwise) to
> systemd-logind.
> """
>
> v2:
> * Fixed typo in commit text and added a fine historical explanation
>from Emil.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: "Christian König"
> Cc: Daniel Vetter
> Acked-by: Christian König
> Reviewed-by: Emil Velikov
Reviewed-by: Rob Clark
Tested-by: Rob Clark
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 6 ++--
> drivers/gpu/drm/drm_auth.c | 3 +-
> drivers/gpu/drm/drm_debugfs.c | 10 ---
> drivers/gpu/drm/drm_file.c | 40 +++--
> drivers/gpu/drm/drm_ioctl.c | 3 ++
> drivers/gpu/drm/nouveau/nouveau_drm.c | 5 +++-
> drivers/gpu/drm/vmwgfx/vmwgfx_gem.c | 6 ++--
> include/drm/drm_file.h | 13 ++--
> 8 files changed, 71 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> index 74055cba3dc9..849097dff02b 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
> @@ -963,6 +963,7 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file
> *m, void *unused)
> list_for_each_entry(file, >filelist, lhead) {
> struct task_struct *task;
> struct drm_gem_object *gobj;
> + struct pid *pid;
> int id;
>
> /*
> @@ -972,8 +973,9 @@ static int amdgpu_debugfs_gem_info_show(struct seq_file
> *m, void *unused)
> * Therefore, we need to protect this ->comm access using RCU.
> */
> rcu_read_lock();
> - task = pid_task(file->pid, PIDTYPE_TGID);
> - seq_printf(m, "pid %8d command %s:\n", pid_nr(file->pid),
> + pid = rcu_dereference(file->pid);
> + task = pid_task(pid, PIDTYPE_TGID);
> + seq_printf(m, "pid %8d command %s:\n", pid_nr(pid),
>task ? task->comm : "");
> rcu_read_unlock();
>
> diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
> index cf92a9ae8034..2ed2585ded37 100644
> --- a/drivers/gpu/drm/drm_auth.c
> +++ b/drivers/gpu/drm/drm_auth.c
> @@ -235,7 +235,8 @@ static int drm_new_set_master(struct drm_device *dev,
> struct drm_file *fpriv)
> static int
> drm_master_check_perm(struct drm_device *dev, struct drm_file *file_priv)
> {
> - if (file_priv->pid == task_pid(current) && file_priv->was_master)
> + if (file_priv->was_master &&
> + rcu_access_pointer(file_priv->pid) == task_pid(current))
> return 0;
>
> if (!capable(CAP_SYS_ADMIN))
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index
[Intel-gfx] [PATCH 0/1] drm/i915/gt: Wait longer for tasks in migrate selftest
The thread_global_copy subtest of the live migrate selftest creates a large number of threads and waits 10ms for them all to start. This is not enough time to wait for the threaded tasks to start, as some may need to wait for additional ring space to be granted. Threads that do so are at risk of getting stopped (signaled) in the middle of waiting for additional space, which can result in ERESTARTSYS getting reported erroneously by i915_request_wait. Instead of waiting a flat 10ms for the threads to start, wait 10ms per thread. This grants enough of a buffer for each thread to wait for additional ring space when needed. Signed-off-by: Jonathan Cavitt CC: Chris Wilson CC: Andi Shyti Jonathan Cavitt (1): drm/i915/gt: Wait longer for tasks in migrate selftest drivers/gpu/drm/i915/gt/selftest_migrate.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.25.1
[Intel-gfx] [PATCH 1/1] drm/i915/gt: Wait longer for tasks in migrate selftest
The thread_global_copy subtest of the live migrate selftest creates a
large number of threads and waits 10ms for them all to start. This is
not enough time to wait for the threaded tasks to start, as some may
need to wait for additional ring space to be granted. Threads that do
so are at risk of getting stopped (signaled) in the middle of waiting
for additional space, which can result in ERESTARTSYS getting reported
erroneously by i915_request_wait.
Instead of waiting a flat 10ms for the threads to start, wait 10ms per
thread. This grants enough of a buffer for each thread to wait for
additional ring space when needed.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gt/selftest_migrate.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
b/drivers/gpu/drm/i915/gt/selftest_migrate.c
index 3def5ca72dec..1a34cbe04fb6 100644
--- a/drivers/gpu/drm/i915/gt/selftest_migrate.c
+++ b/drivers/gpu/drm/i915/gt/selftest_migrate.c
@@ -710,7 +710,7 @@ static int threaded_migrate(struct intel_migrate *migrate,
thread[i].tsk = tsk;
}
- msleep(10); /* start all threads before we kthread_stop() */
+ msleep(10 * n_cpus); /* start all threads before we kthread_stop() */
for (i = 0; i < n_cpus; ++i) {
struct task_struct *tsk = thread[i].tsk;
--
2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/cx0: Check and increase msgbus timeout threshold
== Series Details == Series: drm/i915/cx0: Check and increase msgbus timeout threshold URL : https://patchwork.freedesktop.org/series/122982/ State : success == Summary == CI Bug Log - changes from CI_DRM_13571 -> Patchwork_122982v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/index.html Participating hosts (38 -> 36) -- Additional (1): bat-adlp-11 Missing(3): fi-kbl-soraka bat-dg2-9 fi-snb-2520m New tests - New tests have been introduced between CI_DRM_13571 and Patchwork_122982v1: ### New IGT tests (7) ### * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-nv12@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-xr24@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@hang-read-crc@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s * igt@kms_pipe_crc_basic@read-crc@pipe-b-dp-5: - Statuses : 1 pass(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_122982v1 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_122982v1/bat-adlp-11/igt@debugfs_t...@basic-hwmon.html * igt@gem_tiled_pread_basic: - bat-adlp-11:NOTRUN -> [SKIP][2] ([i915#3282]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-adlp-11/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-adlp-11:NOTRUN -> [ABORT][3] ([i915#8668]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-adlp-11/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@migrate: - bat-adlp-9: [PASS][4] -> [DMESG-FAIL][5] ([i915#7699] / [i915#7913]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-adlp-9/igt@i915_selftest@l...@migrate.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-adlp-9/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@mman: - bat-rpls-1: [PASS][6] -> [TIMEOUT][7] ([i915#6794] / [i915#7392]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-rpls-1/igt@i915_selftest@l...@mman.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-rpls-1/igt@i915_selftest@l...@mman.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-rpls-1: [PASS][8] -> [WARN][9] ([i915#8747]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#6645]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-11:NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-adlp-11/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-adlp-11:NOTRUN -> [SKIP][12] ([i915#4093]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-adlp-11/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][13] ([i915#1845]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_psr@primary_page_flip: - bat-adlp-6: NOTRUN -> [ABORT][14] ([i915#8442] / [i915#8668]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-adlp-6/igt@kms_psr@primary_page_flip.html - bat-adlp-11:NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122982v1/bat-adlp-11/igt@kms_psr@primary_page_flip.html * igt@kms_setmode@basic-clone-single-crtc: - bat-adlp-11:NOTRUN -> [SKIP][16] ([i915#3555]) [16]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/cx0: Check and increase msgbus timeout threshold
== Series Details == Series: drm/i915/cx0: Check and increase msgbus timeout threshold URL : https://patchwork.freedesktop.org/series/122982/ State : warning == Summary == Error: dim checkpatch failed 7a4474bf6960 drm/i915/cx0: Check and increase msgbus timeout threshold -:107: WARNING:LONG_LINE: line length of 115 exceeds 100 columns #107: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:118: + _XELPDP_PORT_MSGBUS_TIMER_LN0_A, \ -:108: WARNING:LONG_LINE: line length of 115 exceeds 100 columns #108: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:119: + _XELPDP_PORT_MSGBUS_TIMER_LN0_B, \ -:109: WARNING:LONG_LINE: line length of 119 exceeds 100 columns #109: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:120: + _XELPDP_PORT_MSGBUS_TIMER_LN0_USBC1, \ -:110: WARNING:LONG_LINE: line length of 131 exceeds 100 columns #110: FILE: drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h:121: + _XELPDP_PORT_MSGBUS_TIMER_LN0_USBC2) + (lane) * 4) total: 0 errors, 4 warnings, 0 checks, 83 lines checked
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Enable VRR later during fastsets
On Sun, Aug 27, 2023 at 10:41 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> In order to reconcile seamless M/N updates with VRR we'll
> need to defer the fastset VRR enable to happen after the
> seamless M/N update (which happens during the vblank evade
> critical section). So just push the VRR enable to be the last
> thing during the update.
>
> This will also affect the vblank evasion as the transcoder
> will now still be running with the old VRR state during
> the vblank evasion. So just grab the timings always from the
> old crtc state during any non-modeset commit, and also grab
> the current state of VRR from the active timings (as we disable
> VRR before vblank evasion during fastsets).
>
> This also fixes vblank evasion for seamless M/N updates as
> we now properly account for the fact that the M/N update
> happens after vblank evasion.
>
> Cc: Manasi Navare
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c| 35
> drivers/gpu/drm/i915/display/intel_display.c | 21
> 2 files changed, 36 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index e46a15d59d79..1992e7060263 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -472,15 +472,31 @@ static void intel_crtc_vblank_evade_scanlines(struct
> intel_atomic_state *state,
> struct intel_crtc *crtc,
> int *min, int *max, int
> *vblank_start)
> {
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
> const struct intel_crtc_state *new_crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> - const struct drm_display_mode *adjusted_mode =
> _crtc_state->hw.adjusted_mode;
> + const struct intel_crtc_state *crtc_state;
> + const struct drm_display_mode *adjusted_mode;
>
> - if (new_crtc_state->vrr.enable) {
> - if (intel_vrr_is_push_sent(new_crtc_state))
> - *vblank_start =
> intel_vrr_vmin_vblank_start(new_crtc_state);
> + /*
> +* During fastsets/etc. the transcoder is still
> +* running with the old timings at this point.
> +*
> +* TODO: maybe just use the active timings here?
> +*/
> + if (intel_crtc_needs_modeset(new_crtc_state))
> + crtc_state = new_crtc_state;
> + else
> + crtc_state = old_crtc_state;
> +
> + adjusted_mode = _state->hw.adjusted_mode;
> +
> + if (crtc->mode_flags & I915_MODE_FLAG_VRR) {
> + if (intel_vrr_is_push_sent(crtc_state))
> + *vblank_start =
> intel_vrr_vmin_vblank_start(crtc_state);
> else
> - *vblank_start =
> intel_vrr_vmax_vblank_start(new_crtc_state);
> + *vblank_start =
> intel_vrr_vmax_vblank_start(crtc_state);
> } else {
> *vblank_start = intel_mode_vblank_start(adjusted_mode);
> }
> @@ -710,15 +726,6 @@ void intel_pipe_update_end(struct intel_atomic_state
> *state,
> */
> intel_vrr_send_push(new_crtc_state);
>
> - /*
> -* Seamless M/N update may need to update frame timings.
> -*
> -* FIXME Should be synchronized with the start of vblank somehow...
> -*/
> - if (new_crtc_state->seamless_m_n &&
> intel_crtc_needs_fastset(new_crtc_state))
> - intel_crtc_update_active_timings(new_crtc_state,
> -new_crtc_state->vrr.enable);
> -
> local_irq_enable();
>
> if (intel_vgpu_active(dev_priv))
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index cfad967b5684..632f1f58df9e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6476,6 +6476,8 @@ static void commit_pipe_post_planes(struct
> intel_atomic_state *state,
> struct intel_crtc *crtc)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + const struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
> const struct intel_crtc_state *new_crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
>
> @@ -6487,6 +6489,9 @@ static void commit_pipe_post_planes(struct
> intel_atomic_state *state,
> if (DISPLAY_VER(dev_priv) >= 9 &&
> !intel_crtc_needs_modeset(new_crtc_state))
> skl_detach_scalers(new_crtc_state);
> +
> + if (vrr_enabling(old_crtc_state, new_crtc_state))
> + intel_vrr_enable(new_crtc_state);
Wouldnt
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Extract intel_crtc_vblank_evade_scanlines()
This looks good to me,
Reviewed-by: Manasi Navare
Manasi
On Sun, Aug 27, 2023 at 10:41 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Pull the vblank evasion scanline calculations into their own helper
> to declutter intel_pipe_update_start() a bit.
>
> Cc: Manasi Navare
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 53 +--
> 1 file changed, 31 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 461949b48411..e46a15d59d79 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -468,6 +468,36 @@ static int intel_mode_vblank_start(const struct
> drm_display_mode *mode)
> return vblank_start;
> }
>
> +static void intel_crtc_vblank_evade_scanlines(struct intel_atomic_state
> *state,
> + struct intel_crtc *crtc,
> + int *min, int *max, int
> *vblank_start)
> +{
> + const struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + const struct drm_display_mode *adjusted_mode =
> _crtc_state->hw.adjusted_mode;
> +
> + if (new_crtc_state->vrr.enable) {
> + if (intel_vrr_is_push_sent(new_crtc_state))
> + *vblank_start =
> intel_vrr_vmin_vblank_start(new_crtc_state);
> + else
> + *vblank_start =
> intel_vrr_vmax_vblank_start(new_crtc_state);
> + } else {
> + *vblank_start = intel_mode_vblank_start(adjusted_mode);
> + }
> +
> + /* FIXME needs to be calibrated sensibly */
> + *min = *vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> +
> VBLANK_EVASION_TIME_US);
> + *max = *vblank_start - 1;
> +
> + /*
> +* M/N is double buffered on the transcoder's undelayed vblank,
> +* so with seamless M/N we must evade both vblanks.
> +*/
> + if (new_crtc_state->seamless_m_n &&
> intel_crtc_needs_fastset(new_crtc_state))
> + *min -= adjusted_mode->crtc_vblank_start -
> adjusted_mode->crtc_vdisplay;
> +}
> +
> /**
> * intel_pipe_update_start() - start update of a set of display registers
> * @state: the atomic state
> @@ -487,7 +517,6 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct intel_crtc_state *new_crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> - const struct drm_display_mode *adjusted_mode =
> _crtc_state->hw.adjusted_mode;
> long timeout = msecs_to_jiffies_timeout(1);
> int scanline, min, max, vblank_start;
> wait_queue_head_t *wq = drm_crtc_vblank_waitqueue(>base);
> @@ -503,27 +532,7 @@ void intel_pipe_update_start(struct intel_atomic_state
> *state,
> if (intel_crtc_needs_vblank_work(new_crtc_state))
> intel_crtc_vblank_work_init(new_crtc_state);
>
> - if (new_crtc_state->vrr.enable) {
> - if (intel_vrr_is_push_sent(new_crtc_state))
> - vblank_start =
> intel_vrr_vmin_vblank_start(new_crtc_state);
> - else
> - vblank_start =
> intel_vrr_vmax_vblank_start(new_crtc_state);
> - } else {
> - vblank_start = intel_mode_vblank_start(adjusted_mode);
> - }
> -
> - /* FIXME needs to be calibrated sensibly */
> - min = vblank_start - intel_usecs_to_scanlines(adjusted_mode,
> - VBLANK_EVASION_TIME_US);
> - max = vblank_start - 1;
> -
> - /*
> -* M/N is double buffered on the transcoder's undelayed vblank,
> -* so with seamless M/N we must evade both vblanks.
> -*/
> - if (new_crtc_state->seamless_m_n &&
> intel_crtc_needs_fastset(new_crtc_state))
> - min -= adjusted_mode->crtc_vblank_start -
> adjusted_mode->crtc_vdisplay;
> -
> + intel_crtc_vblank_evade_scanlines(state, crtc, , ,
> _start);
> if (min <= 0 || max <= 0)
> goto irq_disable;
>
> --
> 2.41.0
>
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Change intel_pipe_update_{start, end}() calling convention
On Sun, Aug 27, 2023 at 10:41 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> We'll need to also look at the old crtc state in
> intel_pipe_update_start() so change the calling convention to
> just plumb in the full atomic state instead.
I am guessing we would need the old crtc state to look at if VRR parameters
were changed?
Could we elaborate why we would need old crtc state so we better understand this
change in the patch?
Manasi
>
> Cc: Manasi Navare
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c| 18 --
> drivers/gpu/drm/i915/display/intel_crtc.h| 6 --
> drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
> 3 files changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 5caa928e5ce9..461949b48411 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -470,7 +470,8 @@ static int intel_mode_vblank_start(const struct
> drm_display_mode *mode)
>
> /**
> * intel_pipe_update_start() - start update of a set of display registers
> - * @new_crtc_state: the new crtc state
> + * @state: the atomic state
> + * @crtc: the crtc
> *
> * Mark the start of an update to pipe registers that should be updated
> * atomically regarding vblank. If the next vblank will happens within
> @@ -480,10 +481,12 @@ static int intel_mode_vblank_start(const struct
> drm_display_mode *mode)
> * until a subsequent call to intel_pipe_update_end(). That is done to
> * avoid random delays.
> */
> -void intel_pipe_update_start(struct intel_crtc_state *new_crtc_state)
> +void intel_pipe_update_start(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
> {
> - struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> + struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> const struct drm_display_mode *adjusted_mode =
> _crtc_state->hw.adjusted_mode;
> long timeout = msecs_to_jiffies_timeout(1);
> int scanline, min, max, vblank_start;
> @@ -631,15 +634,18 @@ static void dbg_vblank_evade(struct intel_crtc *crtc,
> ktime_t end) {}
>
> /**
> * intel_pipe_update_end() - end update of a set of display registers
> - * @new_crtc_state: the new crtc state
> + * @state: the atomic state
> + * @crtc: the crtc
> *
> * Mark the end of an update started with intel_pipe_update_start(). This
> * re-enables interrupts and verifies the update was actually completed
> * before a vblank.
> */
> -void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state)
> +void intel_pipe_update_end(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> {
> - struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> + struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> enum pipe pipe = crtc->pipe;
> int scanline_end = intel_get_crtc_scanline(crtc);
> u32 end_vbl_count = intel_crtc_get_vblank_counter(crtc);
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h
> b/drivers/gpu/drm/i915/display/intel_crtc.h
> index 51a4c8df9e65..22d7993d1f0b 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.h
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.h
> @@ -36,8 +36,10 @@ void intel_crtc_state_reset(struct intel_crtc_state
> *crtc_state,
> u32 intel_crtc_get_vblank_counter(struct intel_crtc *crtc);
> void intel_crtc_vblank_on(const struct intel_crtc_state *crtc_state);
> void intel_crtc_vblank_off(const struct intel_crtc_state *crtc_state);
> -void intel_pipe_update_start(struct intel_crtc_state *new_crtc_state);
> -void intel_pipe_update_end(struct intel_crtc_state *new_crtc_state);
> +void intel_pipe_update_start(struct intel_atomic_state *state,
> +struct intel_crtc *crtc);
> +void intel_pipe_update_end(struct intel_atomic_state *state,
> + struct intel_crtc *crtc);
> void intel_wait_for_vblank_workers(struct intel_atomic_state *state);
> struct intel_crtc *intel_first_crtc(struct drm_i915_private *i915);
> struct intel_crtc *intel_crtc_for_pipe(struct drm_i915_private *i915,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f6397462e4c2..cfad967b5684 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -6559,7 +6559,7 @@ static void intel_update_crtc(struct intel_atomic_state
> *state,
> intel_crtc_planes_update_noarm(state, crtc);
>
> /* Perform vblank evasion around commit operation */
> - intel_pipe_update_start(new_crtc_state);
> +
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Update workaround 14016712196
On 8/28/2023 8:34 AM, Tejas Upadhyay wrote:
Now this workaround is permanent workaround on MTL and DG2,
earlier we used to apply on MTL A0 step only.
VLK-45480
Please remove the internal VLK reference. Otherwise this is
Acked-by: Nirmoy Das
Fixes: d922b80b1010 ("drm/i915/gt: Add workaround 14016712196")
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 6187b25b67ab..0143445dba83 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -226,8 +226,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_engine_cs
*engine, u32 *cs)
static int mtl_dummy_pipe_control(struct i915_request *rq)
{
/* Wa_14016712196 */
- if (IS_GFX_GT_IP_STEP(rq->engine->gt, IP_VER(12, 70), STEP_A0, STEP_B0)
||
- IS_GFX_GT_IP_STEP(rq->engine->gt, IP_VER(12, 71), STEP_A0,
STEP_B0)) {
+ if (IS_GFX_GT_IP_RANGE(rq->engine->gt, IP_VER(12, 70), IP_VER(12, 71))
||
+ IS_DG2(rq->i915)) {
u32 *cs;
/* dummy PIPE_CONTROL + depth flush */
@@ -810,8 +810,7 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request
*rq, u32 *cs)
PIPE_CONTROL_FLUSH_ENABLE);
/* Wa_14016712196 */
- if (IS_GFX_GT_IP_STEP(gt, IP_VER(12, 70), STEP_A0, STEP_B0) ||
- IS_GFX_GT_IP_STEP(gt, IP_VER(12, 71), STEP_A0, STEP_B0))
+ if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) ||
IS_DG2(i915))
/* dummy PIPE_CONTROL + depth flush */
cs = gen12_emit_pipe_control(cs, 0,
PIPE_CONTROL_DEPTH_CACHE_FLUSH, 0);
Re: [Intel-gfx] [PATCH 1/6] drm/i915: Move psr unlock out from the pipe update critical section
By doing psr_unlock after the vblank evade, are we ensuring that even
when VRR params change during the pipe update, psr unlock will
happen after the actual vblank based on newly programmed VRR params?
Manasi
On Sun, Aug 27, 2023 at 10:41 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Do the PSR unlock after the vblank evade critcal section is
> fully over, not before.
>
> Cc: Manasi Navare
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 182c6dd64f47..5caa928e5ce9 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -646,10 +646,8 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
> ktime_t end_vbl_time = ktime_get();
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>
> - intel_psr_unlock(new_crtc_state);
> -
> if (new_crtc_state->do_async_flip)
> - return;
> + goto out;
>
> trace_intel_pipe_update_end(crtc, end_vbl_count, scanline_end);
>
> @@ -709,7 +707,7 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
> local_irq_enable();
>
> if (intel_vgpu_active(dev_priv))
> - return;
> + goto out;
>
> if (crtc->debug.start_vbl_count &&
> crtc->debug.start_vbl_count != end_vbl_count) {
> @@ -724,4 +722,7 @@ void intel_pipe_update_end(struct intel_crtc_state
> *new_crtc_state)
> }
>
> dbg_vblank_evade(crtc, end_vbl_time);
> +
> +out:
> + intel_psr_unlock(new_crtc_state);
> }
> --
> 2.41.0
>
[Intel-gfx] [PATCH] drm/i915/cx0: Check and increase msgbus timeout threshold
We have experienced timeout issues when accessing C20 SRAM registers.
Experimentation showed that bumping the message bus timer threshold
helped on getting display Type-C connection on the C20 PHY to work.
While the timeout is still under investigation with the HW team, having
logic to allow forward progress (with the proper warnings) seems useful.
Thus, let's bump the threshold when a timeout is detected.
The maximum value of 0x200 pclk cycles was somewhat arbitrary - 2x the
default value. That value was successfully tested on real hardware that
was displaying timeouts otherwise.
BSpec: 65156
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_cx0_phy.c | 41 +++
.../gpu/drm/i915/display/intel_cx0_phy_regs.h | 12 ++
2 files changed, 53 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
index dd489b50ad60..55d2333032e3 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
@@ -5,6 +5,7 @@
#include
#include
+#include
#include "i915_reg.h"
#include "intel_cx0_phy.h"
#include "intel_cx0_phy_regs.h"
@@ -29,6 +30,8 @@
#define INTEL_CX0_LANE1BIT(1)
#define INTEL_CX0_BOTH_LANES (INTEL_CX0_LANE1 | INTEL_CX0_LANE0)
+#define INTEL_CX0_MSGBUS_TIMER_VAL_MAX 0x200
+
bool intel_is_c10phy(struct drm_i915_private *i915, enum phy phy)
{
if (DISPLAY_VER_FULL(i915) == IP_VER(14, 0) && phy < PHY_C)
@@ -119,6 +122,43 @@ static void intel_cx0_bus_reset(struct drm_i915_private
*i915, enum port port, i
intel_clear_response_ready_flag(i915, port, lane);
}
+/*
+ * Check if there was a timeout detected by the hardware in the message bus
+ * and bump the threshold if so.
+ */
+static void intel_cx0_bus_check_and_bump_timer(struct drm_i915_private *i915,
+ enum port port, int lane)
+{
+ enum phy phy = intel_port_to_phy(i915, port);
+ i915_reg_t reg;
+ u32 val;
+ u32 timer_val;
+
+ reg = XELPDP_PORT_MSGBUS_TIMER(port, lane);
+ val = intel_de_read(i915, reg);
+
+ if (!(val & XELPDP_PORT_MSGBUS_TIMER_TIMED_OUT)) {
+ drm_warn(>drm,
+"PHY %c lane %d: hardware did not detect a timeout\n",
+phy_name(phy), lane);
+ return;
+ }
+
+ timer_val = REG_FIELD_GET(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK, val);
+
+ if (timer_val == INTEL_CX0_MSGBUS_TIMER_VAL_MAX)
+ return;
+
+ timer_val = min(2 * timer_val, (u32)INTEL_CX0_MSGBUS_TIMER_VAL_MAX);
+ val &= ~XELPDP_PORT_MSGBUS_TIMER_VAL_MASK;
+ val |= REG_FIELD_PREP(XELPDP_PORT_MSGBUS_TIMER_VAL_MASK, timer_val);
+
+ drm_dbg_kms(>drm,
+ "PHY %c lane %d: increasing msgbus timer threshold to
%#x\n",
+ phy_name(phy), lane, timer_val);
+ intel_de_write(i915, reg, val);
+}
+
static int intel_cx0_wait_for_ack(struct drm_i915_private *i915, enum port
port,
int command, int lane, u32 *val)
{
@@ -132,6 +172,7 @@ static int intel_cx0_wait_for_ack(struct drm_i915_private
*i915, enum port port,
XELPDP_MSGBUS_TIMEOUT_SLOW, val)) {
drm_dbg_kms(>drm, "PHY %c Timeout waiting for message
ACK. Status: 0x%x\n",
phy_name(phy), *val);
+ intel_cx0_bus_check_and_bump_timer(i915, port, lane);
intel_cx0_bus_reset(i915, port, lane);
return -ETIMEDOUT;
}
diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
index cb5d1be2ba19..17cc3385aabb 100644
--- a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
+++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h
@@ -110,6 +110,18 @@
#define CX0_P4PG_STATE_DISABLE 0xC
#define CX0_P2_STATE_RESET 0x2
+#define _XELPDP_PORT_MSGBUS_TIMER_LN0_A0x640d8
+#define _XELPDP_PORT_MSGBUS_TIMER_LN0_B0x641d8
+#define _XELPDP_PORT_MSGBUS_TIMER_LN0_USBC10x16f258
+#define _XELPDP_PORT_MSGBUS_TIMER_LN0_USBC20x16f458
+#define XELPDP_PORT_MSGBUS_TIMER(port, lane)
_MMIO(_PICK_EVEN_2RANGES(port, PORT_TC1, \
+
_XELPDP_PORT_MSGBUS_TIMER_LN0_A, \
+
_XELPDP_PORT_MSGBUS_TIMER_LN0_B, \
+
_XELPDP_PORT_MSGBUS_TIMER_LN0_USBC1, \
+
_XELPDP_PORT_MSGBUS_TIMER_LN0_USBC2) + (lane) * 4)
+#define XELPDP_PORT_MSGBUS_TIMER_TIMED_OUT REG_BIT(31)
+#define
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag behaviour
Hi Ville,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 28 August 2023 11:12
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 5/6] drm/i915: Adjust seamless_m_n flag
> behaviour
>
> From: Ville Syrjälä
>
> Make the seamless_m_n flag more like the update_pipe fastset flag, ie. the
> flag will only be set if we need to do the seamless M/N update, and in all
> other cases the flag is cleared. Also rename the flag to update_m_n to
> make it more clear it's similar to update_pipe.
>
> I believe special casing seamless_m_n like this makes sense as it also affects
> eg. vblank evasion. We can potentially avoid some vblank evasion tricks,
> simplify some checks, and hopefully will help with the VRR vs. M/N mess.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_atomic.c | 1 +
> drivers/gpu/drm/i915/display/intel_crtc.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display.c | 22 +++
> .../drm/i915/display/intel_display_types.h| 2 +-
> drivers/gpu/drm/i915/display/intel_dp.c | 2 +-
> 5 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
> b/drivers/gpu/drm/i915/display/intel_atomic.c
> index 7cf51dd8c056..aaddd8c0cfa0 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
> @@ -259,6 +259,7 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
> drm_property_blob_get(crtc_state->post_csc_lut);
>
> crtc_state->update_pipe = false;
> + crtc_state->update_m_n = false;
> crtc_state->disable_lp_wm = false;
> crtc_state->disable_cxsr = false;
> crtc_state->update_wm_pre = false;
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index 1992e7060263..a04076064f02 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -510,7 +510,7 @@ static void intel_crtc_vblank_evade_scanlines(struct
> intel_atomic_state *state,
>* M/N is double buffered on the transcoder's undelayed vblank,
>* so with seamless M/N we must evade both vblanks.
>*/
> - if (new_crtc_state->seamless_m_n &&
> intel_crtc_needs_fastset(new_crtc_state))
> + if (new_crtc_state->update_m_n)
> *min -= adjusted_mode->crtc_vblank_start -
> adjusted_mode->crtc_vdisplay; }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 632f1f58df9e..6196ef76390b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -5170,7 +5170,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> PIPE_CONF_CHECK_X(lane_lat_optim_mask);
>
> if (HAS_DOUBLE_BUFFERED_M_N(dev_priv)) {
> - if (!fastset || !pipe_config->seamless_m_n)
> + if (!fastset || !pipe_config->update_m_n)
> PIPE_CONF_CHECK_M_N(dp_m_n);
> } else {
> PIPE_CONF_CHECK_M_N(dp_m_n);
> @@ -5307,7 +5307,7 @@ intel_pipe_config_compare(const struct
> intel_crtc_state *current_config,
> if (IS_G4X(dev_priv) || DISPLAY_VER(dev_priv) >= 5)
> PIPE_CONF_CHECK_I(pipe_bpp);
>
> - if (!fastset || !pipe_config->seamless_m_n) {
> + if (!fastset || !pipe_config->update_m_n) {
> PIPE_CONF_CHECK_I(hw.pipe_mode.crtc_clock);
> PIPE_CONF_CHECK_I(hw.adjusted_mode.crtc_clock);
> }
> @@ -5402,6 +5402,7 @@ int intel_modeset_all_pipes(struct
> intel_atomic_state *state,
>
> crtc_state->uapi.mode_changed = true;
> crtc_state->update_pipe = false;
> + crtc_state->update_m_n = false;
>
> ret = drm_atomic_add_affected_connectors(>base,
>>base);
> @@ -5519,13 +5520,14 @@ static void intel_crtc_check_fastset(const struct
> intel_crtc_state *old_crtc_sta {
> struct drm_i915_private *i915 = to_i915(old_crtc_state->uapi.crtc-
> >dev);
>
> - if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
> true)) {
> + if (!intel_pipe_config_compare(old_crtc_state, new_crtc_state,
> true))
> drm_dbg_kms(>drm, "fastset requirement not met,
> forcing full modeset\n");
> + else
> + new_crtc_state->uapi.mode_changed = false;
>
> - return;
> - }
> + if (intel_crtc_needs_modeset(new_crtc_state))
> + new_crtc_state->update_m_n = false;
>
> - new_crtc_state->uapi.mode_changed = false;
> if (!intel_crtc_needs_modeset(new_crtc_state))
> new_crtc_state->update_pipe = true;
> }
> @@ -6240,6 +6242,7 @@ int intel_atomic_check(struct drm_device *dev,
> if (intel_cpu_transcoders_need_modeset(state,
> BIT(master))) {
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: fix compile issue of guc_klvs_abi.h
== Series Details == Series: drm/i915/guc: fix compile issue of guc_klvs_abi.h URL : https://patchwork.freedesktop.org/series/122971/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13571_full -> Patchwork_122971v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_122971v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122971v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122971v1_full: ### IGT changes ### Possible regressions * igt@gem_ctx_shared@detached-shared-gtt: - shard-mtlp: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-mtlp-2/igt@gem_ctx_sha...@detached-shared-gtt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-mtlp-1/igt@gem_ctx_sha...@detached-shared-gtt.html Known issues Here are the changes found in Patchwork_122971v1_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_fdinfo@most-busy-idle-check-all@rcs0: - shard-rkl: [PASS][3] -> [FAIL][4] ([i915#7742]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html * igt@gem_busy@close-race: - shard-glk: [PASS][5] -> [ABORT][6] ([i915#6016]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-glk7/igt@gem_b...@close-race.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-glk1/igt@gem_b...@close-race.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-rkl: [PASS][7] -> [FAIL][8] ([i915#6268]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_sseu@invalid-sseu: - shard-dg2: NOTRUN -> [SKIP][9] ([i915#280]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-dg2-8/igt@gem_ctx_s...@invalid-sseu.html * igt@gem_eio@reset-stress: - shard-dg1: [PASS][10] -> [FAIL][11] ([i915#5784]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-dg1-13/igt@gem_...@reset-stress.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-dg1-19/igt@gem_...@reset-stress.html * igt@gem_exec_balancer@bonded-semaphore: - shard-dg2: NOTRUN -> [SKIP][12] ([i915#4812]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-dg2-8/igt@gem_exec_balan...@bonded-semaphore.html * igt@gem_exec_balancer@bonded-sync: - shard-mtlp: NOTRUN -> [SKIP][13] ([i915#4771]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-mtlp-7/igt@gem_exec_balan...@bonded-sync.html * igt@gem_exec_capture@pi@ccs0: - shard-mtlp: [PASS][14] -> [FAIL][15] ([i915#7765]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-mtlp-8/igt@gem_exec_capture@p...@ccs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-mtlp-5/igt@gem_exec_capture@p...@ccs0.html * igt@gem_exec_capture@pi@rcs0: - shard-mtlp: [PASS][16] -> [FAIL][17] ([i915#4475]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-mtlp-8/igt@gem_exec_capture@p...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-mtlp-5/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_flush@basic-wb-ro-before-default: - shard-dg2: NOTRUN -> [SKIP][18] ([i915#3539] / [i915#4852]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-dg2-8/igt@gem_exec_fl...@basic-wb-ro-before-default.html * igt@gem_exec_reloc@basic-cpu-gtt-active: - shard-dg2: NOTRUN -> [SKIP][19] ([i915#3281]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/shard-dg2-8/igt@gem_exec_re...@basic-cpu-gtt-active.html * igt@gem_exec_suspend@basic-s4-devices@smem: - shard-tglu: [PASS][20] -> [ABORT][21] ([i915#7975] / [i915#8213]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-tglu-4/igt@gem_exec_suspend@basic-s4-devi...@smem.html [21]:
Re: [Intel-gfx] [PATCH v15 00/23] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers
On Monday, August 28, 2023 11:37 -03, "Helen Mae Koike Fornazier" wrote: > On Sunday, August 27, 2023 14:54 -03, Dmitry Osipenko > wrote: > > > This series: > > > > 1. Adds common drm-shmem memory shrinker > > 2. Enables shrinker for VirtIO-GPU driver > > 3. Switches Panfrost driver to the common shrinker > > Hi Dmitry, > > Would you mind testing with drm-ci? We virt-io tests there and it would be > really great to get your feedback of it. > > https://cgit.freedesktop.org/drm/drm/log/?h=topic/drm-ci sorry, I forgot that you also need this patchset: https://lists.freedesktop.org/archives/dri-devel/2023-August/420063.html to enable virtio_gpu test job. Thanks again. Helen > > You need to merge your changes with the above tree. > To configure it, you just need to have a tree on gitlab.freedesktop.org, > go to the settings and change the CI/CD configuration file from .gitlab-ci.yml > to drivers/gpu/drm/ci/gitlab-ci.yml, and you can start a pipeline > on your branch. > > at the time of this writting, gitlab.freedesktop.org is under maintenance, > but it should be back soon. > > Thank you! > Helen > > > > > Changelog: > > > > v15:- Moved drm-shmem reference counters to use kref that allows to > > optimize unlocked functions, like was suggested by Boris Brezillon. > > > > - Changed drm/gem/shmem function names to use _locked postfix and > > dropped the _unlocked, making the naming scheme consistent across > > DRM code, like was suggested by Boris Brezillon. > > > > - Added patch that fixes UAF in drm-shmem for drivers that import > > dma-buf and then release buffer in the import error code path. > > > > - Added patch that makes drm-shmem use new flag for SGT's get_pages() > > refcounting, preventing unbalanced refcounting when GEM is freed. > > > > - Fixed guest blob pinning in virtio-gpu driver that was missed > > previously in the shrinker patch. > > > > - Moved VC4 and virtio-gpu drivers to use drm_gem_put() in > > GEM-creation error code paths, which is now required by drm-shmem > > and was missed in a previous patch versions. > > > > - Virtio-GPU now attaches shmem pages to host on first use and not > > when BO is created. In older patch versions there was a potential > > race condition in the BO creation code path where both > > get_sgt()+object_attach() should've been made under same resv lock, > > otherwise pages could be evicted before attachment is invoked. > > > > - Virtio-GPU and drm-shmem shrinker patches are split into smaller > > ones. > > > > v14:- All the prerequisite reservation locking patches landed upstream, > > previously were a part of this series in v13 and older. > > > > > > https://lore.kernel.org/dri-devel/20230529223935.2672495-1-dmitry.osipe...@collabora.com/ > > > > - Added patches to improve locked/unlocked function names, like was > > suggested by Boris Brezillon for v13. > > > > - Made all exported drm-shmem symbols GPL, like was previously > > discussed with Thomas Zimmermann on this series. > > > > - Improved virtio-gpu shrinker patch. Now it won't detach purged BO > > when userspace closes GEM. Crosvm (and not qemu) checks res_id on > > CMD_CTX_DETACH_RESOURCE and prints noisy error message if ID is > > invalid, which wasn't noticed before. > > > > v13:- Updated virtio-gpu shrinker patch to use drm_gem_shmem_object_pin() > > directly instead of drm_gem_pin() and dropped patch that exported > > drm_gem_pin() functions, like was requested by Thomas Zimmermann in > > v12. > > > > v12:- Fixed the "no previous prototype for function" warning reported by > > kernel build bot for v11. > > > > - Fixed the missing reservation lock reported by Intel CI for VGEM > > driver. Other drivers using drm-shmem were affected similarly to > > VGEM. The problem was in the dma-buf attachment code path that led > > to drm-shmem pinning function which assumed the held reservation lock > > by drm_gem_pin(). In the past that code path was causing trouble for > > i915 driver and we've changed the locking scheme for the attachment > > code path in the dma-buf core to let exporters to handle the locking > > themselves. After a closer investigation, I realized that my > > assumption > > about testing of dma-buf export code path using Panfrost driver was > > incorrect. Now I created additional local test to exrecise the > > Panfrost > > export path. I also reproduced the issue reported by the Intel CI for > > v10. It's all fixed now by making the drm_gem_shmem_pin() to take the > > resv lock by itself. > > > > - Patches are based on top of drm-tip, CC'd intel-gfx CI for testing. > > > > v11:- Rebased on a recent linux-next. Added new patch as a result: > > > > drm/shmem-helper: Export
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
== Series Details == Series: drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top URL : https://patchwork.freedesktop.org/series/122970/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13571_full -> Patchwork_122970v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_122970v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122970v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122970v1_full: ### IGT changes ### Possible regressions * igt@kms_plane@pixel-format-source-clamping@pipe-a-planes: - shard-rkl: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-rkl-4/igt@kms_plane@pixel-format-source-clamp...@pipe-a-planes.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-rkl-1/igt@kms_plane@pixel-format-source-clamp...@pipe-a-planes.html Known issues Here are the changes found in Patchwork_122970v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-reloc-purge-cache: - shard-dg2: NOTRUN -> [SKIP][3] ([i915#8411]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-dg2-5/igt@api_intel...@object-reloc-purge-cache.html * igt@api_intel_bb@render-ccs: - shard-dg2: NOTRUN -> [FAIL][4] ([i915#6122]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-dg2-11/igt@api_intel...@render-ccs.html * igt@drm_fdinfo@busy-idle@bcs0: - shard-dg2: NOTRUN -> [SKIP][5] ([i915#8414]) +19 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-dg2-5/igt@drm_fdinfo@busy-i...@bcs0.html * igt@gem_ctx_persistence@engines-hostile: - shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-snb6/igt@gem_ctx_persiste...@engines-hostile.html * igt@gem_ctx_persistence@hang: - shard-dg2: NOTRUN -> [SKIP][7] ([i915#8555]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-dg2-11/igt@gem_ctx_persiste...@hang.html * igt@gem_ctx_sseu@invalid-sseu: - shard-dg2: NOTRUN -> [SKIP][8] ([i915#280]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-dg2-1/igt@gem_ctx_s...@invalid-sseu.html * igt@gem_exec_balancer@bonded-sync: - shard-mtlp: NOTRUN -> [SKIP][9] ([i915#4771]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-mtlp-3/igt@gem_exec_balan...@bonded-sync.html * igt@gem_exec_capture@pi@rcs0: - shard-mtlp: [PASS][10] -> [FAIL][11] ([i915#4475]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-mtlp-8/igt@gem_exec_capture@p...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-mtlp-8/igt@gem_exec_capture@p...@rcs0.html * igt@gem_exec_create@forked@smem: - shard-snb: [PASS][12] -> [ABORT][13] ([i915#8865]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-snb5/igt@gem_exec_create@for...@smem.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-snb7/igt@gem_exec_create@for...@smem.html * igt@gem_exec_endless@dispatch@vecs1: - shard-dg2: NOTRUN -> [TIMEOUT][14] ([i915#7016] / [i915#8628]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-dg2-5/igt@gem_exec_endless@dispa...@vecs1.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fence@submit3: - shard-dg2: NOTRUN -> [SKIP][17] ([i915#4812]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-dg2-5/igt@gem_exec_fe...@submit3.html * igt@gem_exec_flush@basic-wb-rw-default: - shard-dg2: NOTRUN -> [SKIP][18] ([i915#3539] / [i915#4852]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/shard-dg2-5/igt@gem_exec_fl...@basic-wb-rw-default.html * igt@gem_exec_reloc@basic-gtt-wc: - shard-dg2: NOTRUN -> [SKIP][19] ([i915#3281]) +14 similar issues
Re: [Intel-gfx] [PATCH v15 00/23] Add generic memory shrinker to VirtIO-GPU and Panfrost DRM drivers
On Sunday, August 27, 2023 14:54 -03, Dmitry Osipenko wrote: > This series: > > 1. Adds common drm-shmem memory shrinker > 2. Enables shrinker for VirtIO-GPU driver > 3. Switches Panfrost driver to the common shrinker Hi Dmitry, Would you mind testing with drm-ci? We virt-io tests there and it would be really great to get your feedback of it. https://cgit.freedesktop.org/drm/drm/log/?h=topic/drm-ci You need to merge your changes with the above tree. To configure it, you just need to have a tree on gitlab.freedesktop.org, go to the settings and change the CI/CD configuration file from .gitlab-ci.yml to drivers/gpu/drm/ci/gitlab-ci.yml, and you can start a pipeline on your branch. at the time of this writting, gitlab.freedesktop.org is under maintenance, but it should be back soon. Thank you! Helen > > Changelog: > > v15:- Moved drm-shmem reference counters to use kref that allows to > optimize unlocked functions, like was suggested by Boris Brezillon. > > - Changed drm/gem/shmem function names to use _locked postfix and > dropped the _unlocked, making the naming scheme consistent across > DRM code, like was suggested by Boris Brezillon. > > - Added patch that fixes UAF in drm-shmem for drivers that import > dma-buf and then release buffer in the import error code path. > > - Added patch that makes drm-shmem use new flag for SGT's get_pages() > refcounting, preventing unbalanced refcounting when GEM is freed. > > - Fixed guest blob pinning in virtio-gpu driver that was missed > previously in the shrinker patch. > > - Moved VC4 and virtio-gpu drivers to use drm_gem_put() in > GEM-creation error code paths, which is now required by drm-shmem > and was missed in a previous patch versions. > > - Virtio-GPU now attaches shmem pages to host on first use and not > when BO is created. In older patch versions there was a potential > race condition in the BO creation code path where both > get_sgt()+object_attach() should've been made under same resv lock, > otherwise pages could be evicted before attachment is invoked. > > - Virtio-GPU and drm-shmem shrinker patches are split into smaller > ones. > > v14:- All the prerequisite reservation locking patches landed upstream, > previously were a part of this series in v13 and older. > > > https://lore.kernel.org/dri-devel/20230529223935.2672495-1-dmitry.osipe...@collabora.com/ > > - Added patches to improve locked/unlocked function names, like was > suggested by Boris Brezillon for v13. > > - Made all exported drm-shmem symbols GPL, like was previously > discussed with Thomas Zimmermann on this series. > > - Improved virtio-gpu shrinker patch. Now it won't detach purged BO > when userspace closes GEM. Crosvm (and not qemu) checks res_id on > CMD_CTX_DETACH_RESOURCE and prints noisy error message if ID is > invalid, which wasn't noticed before. > > v13:- Updated virtio-gpu shrinker patch to use drm_gem_shmem_object_pin() > directly instead of drm_gem_pin() and dropped patch that exported > drm_gem_pin() functions, like was requested by Thomas Zimmermann in > v12. > > v12:- Fixed the "no previous prototype for function" warning reported by > kernel build bot for v11. > > - Fixed the missing reservation lock reported by Intel CI for VGEM > driver. Other drivers using drm-shmem were affected similarly to > VGEM. The problem was in the dma-buf attachment code path that led > to drm-shmem pinning function which assumed the held reservation lock > by drm_gem_pin(). In the past that code path was causing trouble for > i915 driver and we've changed the locking scheme for the attachment > code path in the dma-buf core to let exporters to handle the locking > themselves. After a closer investigation, I realized that my assumption > about testing of dma-buf export code path using Panfrost driver was > incorrect. Now I created additional local test to exrecise the Panfrost > export path. I also reproduced the issue reported by the Intel CI for > v10. It's all fixed now by making the drm_gem_shmem_pin() to take the > resv lock by itself. > > - Patches are based on top of drm-tip, CC'd intel-gfx CI for testing. > > v11:- Rebased on a recent linux-next. Added new patch as a result: > > drm/shmem-helper: Export drm_gem_shmem_get_pages_sgt_locked() > > It's needed by the virtio-gpu driver to swap-in/unevict shmem > object, previously get_pages_sgt() didn't use locking. > > - Separated the "Add memory shrinker" patch into smaller parts to ease > the reviewing, as was requested by Thomas Zimmermann: > > drm/shmem-helper: Factor out pages alloc/release from > drm_gem_shmem_get/put_pages() > drm/shmem-helper: Add pages_pin_count
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: fix compile issue of guc_klvs_abi.h
== Series Details == Series: drm/i915/guc: fix compile issue of guc_klvs_abi.h URL : https://patchwork.freedesktop.org/series/122971/ State : success == Summary == CI Bug Log - changes from CI_DRM_13571 -> Patchwork_122971v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/index.html Participating hosts (38 -> 27) -- Missing(11): fi-kbl-7567u bat-adls-5 bat-adlp-9 bat-dg2-9 fi-cfl-8700k fi-apl-guc fi-snb-2520m fi-cfl-guc fi-ivb-3770 fi-elk-e7500 bat-mtlp-8 Known issues Here are the changes found in Patchwork_122971v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334] / [i915#7872]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html - bat-jsl-1: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-jsl-1/igt@i915_selftest@live@gt_heartbeat.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/bat-jsl-1/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][5] ([i915#1845]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_psr@primary_mmap_gtt: - bat-rplp-1: NOTRUN -> [SKIP][6] ([i915#1072]) +2 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html * igt@kms_psr@primary_page_flip: - bat-adlp-6: NOTRUN -> [ABORT][7] ([i915#8442] / [i915#8668]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/bat-adlp-6/igt@kms_psr@primary_page_flip.html * igt@kms_setmode@basic-clone-single-crtc: - bat-rplp-1: NOTRUN -> [ABORT][8] ([i915#8260] / [i915#8668]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html Possible fixes * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-a-edp-1: - bat-adlp-6: [ABORT][9] ([i915#7977] / [i915#8469] / [i915#8668]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-adlp-6/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-edp-1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/bat-adlp-6/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-edp-1.html Warnings * igt@kms_psr@primary_page_flip: - bat-rplp-1: [ABORT][11] ([i915#8442] / [i915#8668] / [i915#8860]) -> [SKIP][12] ([i915#1072]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-rplp-1/igt@kms_psr@primary_page_flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/bat-rplp-1/igt@kms_psr@primary_page_flip.html [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872 [i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977 [i915#8260]: https://gitlab.freedesktop.org/drm/intel/issues/8260 [i915#8442]: https://gitlab.freedesktop.org/drm/intel/issues/8442 [i915#8469]: https://gitlab.freedesktop.org/drm/intel/issues/8469 [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668 [i915#8860]: https://gitlab.freedesktop.org/drm/intel/issues/8860 Build changes - * Linux: CI_DRM_13571 -> Patchwork_122971v1 CI-20190529: 20190529 CI_DRM_13571: d3f0e020609215d9097f1b1fad5a13ea0b37548e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7454: 7454 Patchwork_122971v1: d3f0e020609215d9097f1b1fad5a13ea0b37548e @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 6a7147fc198e drm/i915/guc: fix compile issue of guc_klvs_abi.h == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122971v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: fix compile issue of guc_klvs_abi.h
== Series Details == Series: drm/i915/guc: fix compile issue of guc_klvs_abi.h URL : https://patchwork.freedesktop.org/series/122971/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
== Series Details == Series: drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top URL : https://patchwork.freedesktop.org/series/122970/ State : success == Summary == CI Bug Log - changes from CI_DRM_13571 -> Patchwork_122970v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/index.html Participating hosts (38 -> 35) -- Missing(3): fi-kbl-soraka fi-skl-guc fi-snb-2520m Known issues Here are the changes found in Patchwork_122970v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@smem: - bat-dg2-9: [PASS][1] -> [INCOMPLETE][2] ([i915#6311]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@mman: - bat-rpls-1: [PASS][3] -> [TIMEOUT][4] ([i915#6794] / [i915#7392]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-rpls-1/igt@i915_selftest@l...@mman.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/bat-rpls-1/igt@i915_selftest@l...@mman.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-rpls-1: [PASS][5] -> [WARN][6] ([i915#8747]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#6645]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][8] ([i915#1845]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/bat-dg2-11/igt@kms_pipe_crc_ba...@nonblocking-crc-frame-sequence.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1: - bat-rplp-1: [PASS][9] -> [ABORT][10] ([i915#8442] / [i915#8668]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html * igt@kms_psr@primary_page_flip: - bat-adlp-6: NOTRUN -> [ABORT][11] ([i915#8442] / [i915#8668]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/bat-adlp-6/igt@kms_psr@primary_page_flip.html Possible fixes * igt@i915_selftest@live@requests: - bat-mtlp-8: [ABORT][12] ([i915#7982] / [i915#8865]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-mtlp-8/igt@i915_selftest@l...@requests.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-a-edp-1: - bat-adlp-6: [ABORT][14] ([i915#7977] / [i915#8469] / [i915#8668]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-adlp-6/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-edp-1.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122970v1/bat-adlp-6/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-a-edp-1.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311 [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645 [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794 [i915#7392]: https://gitlab.freedesktop.org/drm/intel/issues/7392 [i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977 [i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982 [i915#8442]: https://gitlab.freedesktop.org/drm/intel/issues/8442 [i915#8469]: https://gitlab.freedesktop.org/drm/intel/issues/8469 [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668 [i915#8747]: https://gitlab.freedesktop.org/drm/intel/issues/8747 [i915#8865]: https://gitlab.freedesktop.org/drm/intel/issues/8865 Build changes - * Linux: CI_DRM_13571 -> Patchwork_122970v1 CI-20190529: 20190529 CI_DRM_13571: d3f0e020609215d9097f1b1fad5a13ea0b37548e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7454: 7454 Patchwork_122970v1: d3f0e020609215d9097f1b1fad5a13ea0b37548e @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits caed1203dfa5 drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top == Logs ==
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
== Series Details == Series: drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top URL : https://patchwork.freedesktop.org/series/122970/ State : warning == Summary == Error: dim checkpatch failed 483b43d16420 drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top -:14: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #14: i915 :00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of GGTT for GuC -:41: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a separate line #41: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:520: + * in uc_fw_ggtt_offset() simple. */ -:55: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #55: FILE: drivers/gpu/drm/i915/gt/intel_ggtt.c:531: + GEM_BUG_ON(ggtt->vm.total <= GUC_TOP_RESERVE_SIZE); total: 0 errors, 3 warnings, 0 checks, 35 lines checked
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/psr: Add psr sink error status into sink status debugfs
== Series Details == Series: drm/i915/psr: Add psr sink error status into sink status debugfs URL : https://patchwork.freedesktop.org/series/122965/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13571_full -> Patchwork_122965v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_122965v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122965v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122965v1_full: ### IGT changes ### Possible regressions * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: - shard-rkl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-rkl-4/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html Known issues Here are the changes found in Patchwork_122965v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-reloc-purge-cache: - shard-dg2: NOTRUN -> [SKIP][2] ([i915#8411]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-dg2-10/igt@api_intel...@object-reloc-purge-cache.html * igt@api_intel_bb@render-ccs: - shard-dg2: NOTRUN -> [FAIL][3] ([i915#6122]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-dg2-11/igt@api_intel...@render-ccs.html * igt@drm_fdinfo@busy-idle@bcs0: - shard-dg2: NOTRUN -> [SKIP][4] ([i915#8414]) +19 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-dg2-10/igt@drm_fdinfo@busy-i...@bcs0.html * igt@feature_discovery@chamelium: - shard-rkl: NOTRUN -> [SKIP][5] ([fdo#111827]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-rkl-4/igt@feature_discov...@chamelium.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-rkl: [PASS][6] -> [FAIL][7] ([i915#6268]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-rkl-1/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_persistence@engines-hostile: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-snb6/igt@gem_ctx_persiste...@engines-hostile.html * igt@gem_ctx_persistence@hang: - shard-dg2: NOTRUN -> [SKIP][9] ([i915#8555]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-dg2-11/igt@gem_ctx_persiste...@hang.html * igt@gem_ctx_sseu@mmap-args: - shard-dg2: NOTRUN -> [SKIP][10] ([i915#280]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-dg2-1/igt@gem_ctx_s...@mmap-args.html * igt@gem_eio@reset-stress: - shard-dg1: [PASS][11] -> [FAIL][12] ([i915#5784]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-dg1-13/igt@gem_...@reset-stress.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-dg1-16/igt@gem_...@reset-stress.html * igt@gem_exec_balancer@bonded-sync: - shard-mtlp: NOTRUN -> [SKIP][13] ([i915#4771]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-mtlp-4/igt@gem_exec_balan...@bonded-sync.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-rkl: [PASS][14] -> [FAIL][15] ([i915#2842]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-rkl-7/igt@gem_exec_fair@basic-f...@rcs0.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-rkl-7/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-solo@rcs0: - shard-apl: [PASS][16] -> [FAIL][17] ([i915#2842]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/shard-apl6/igt@gem_exec_fair@basic-none-s...@rcs0.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-apl2/igt@gem_exec_fair@basic-none-s...@rcs0.html * igt@gem_exec_fence@submit3: - shard-dg2: NOTRUN -> [SKIP][18] ([i915#4812]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/shard-dg2-10/igt@gem_exec_fe...@submit3.html * igt@gem_exec_flush@basic-batch-kernel-default-uc: - shard-mtlp: [PASS][19] -> [DMESG-FAIL][20] ([i915#8962] / [i915#9121]) [19]:
[Intel-gfx] [PATCH] drm/i915/guc: fix compile issue of guc_klvs_abi.h
GCC report GUC_KLV_0_KEY and GUC_KLV_0_LEN is not constant when do preprocessing. Change to use GENMASK() to avoid the issue. Signed-off-by: Linyu Yuan --- drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h index 58012edd4eb0..fd3c16695e5f 100644 --- a/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h +++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h @@ -29,8 +29,8 @@ */ #define GUC_KLV_LEN_MIN1u -#define GUC_KLV_0_KEY (0x << 16) -#define GUC_KLV_0_LEN (0x << 0) +#define GUC_KLV_0_KEY GENMASK(31, 16) +#define GUC_KLV_0_LEN GENMASK(15, 0) #define GUC_KLV_n_VALUE(0x << 0) /** -- 2.17.1
Re: [Intel-gfx] [PATCH 0/4] drm/amd/display: stop using drm_edid_override_connector_update()
On 2023-08-22 06:01, Jani Nikula wrote: Over the past years I've been trying to unify the override and firmware EDID handling as well as EDID property updates. It won't work if drivers do their own random things. Let's check how to replace these references by appropriate ones or fork the function as reverting these patches causes regressions. Cheers, Alex BR, Jani. Cc: Alex Deucher Cc: Alex Hung Cc: Chao-kai Wang Cc: Daniel Wheeler Cc: Harry Wentland Cc: Hersen Wu Cc: Leo Li Cc: Rodrigo Siqueira Cc: Wenchieh Chien Cc: David Airlie Cc: Daniel Vetter Jani Nikula (4): Revert "drm/amd/display: drop unused count variable in create_eml_sink()" Revert "drm/amd/display: assign edid_blob_ptr with edid from debugfs" Revert "drm/amd/display: mark amdgpu_dm_connector_funcs_force static" Revert "drm/amd/display: implement force function in amdgpu_dm_connector_funcs" .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 44 +++ 1 file changed, 5 insertions(+), 39 deletions(-)
Re: [Intel-gfx] [PATCH] drm/i915/guc: fix compile issue of guc_klvs_abi.h
On 8/25/2023 1:37 PM, Jani Nikula wrote: On Fri, 25 Aug 2023, Linyu Yuan wrote: GCC report GUC_KLV_0_KEY and GUC_KLV_0_LEN is not constant when do preprocessing. Please paste the actual compiler warning. CC drivers/gpu/drm/i915/gt/uc/intel_guc_submission.o In file included from :0:0: In function ‘__guc_context_policy_add_priority.isra.47’, inlined from ‘__guc_context_set_prio.isra.48’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3332:3, inlined from ‘guc_context_set_prio’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3360:2: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1803’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: note: in expansion of macro ‘__BF_FIELD_CHECK’ __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ ^~~~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2461:3: note: in expansion of macro ‘FIELD_PREP’ FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2469:1: note: in expansion of macro ‘MAKE_CONTEXT_POLICY_ADD’ MAKE_CONTEXT_POLICY_ADD(priority, SCHEDULING_PRIORITY) ^~~ In function ‘__guc_context_policy_add_preemption_timeout.isra.51’, inlined from ‘__guc_context_set_preemption_timeout’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:3005:3: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1793’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: note: in expansion of macro ‘__BF_FIELD_CHECK’ __BF_FIELD_CHECK(_mask, 0ULL, _val, "FIELD_PREP: "); \ ^~~~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2461:3: note: in expansion of macro ‘FIELD_PREP’ FIELD_PREP(GUC_KLV_0_KEY, GUC_CONTEXT_POLICIES_KLV_ID_##id) | \ ^~ drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2468:1: note: in expansion of macro ‘MAKE_CONTEXT_POLICY_ADD’ MAKE_CONTEXT_POLICY_ADD(preemption_timeout, PREEMPTION_TIMEOUT) ^~~ In function ‘__guc_context_policy_add_priority.isra.47’, inlined from ‘__guc_add_request’ at drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c:2503:2: ././include/linux/compiler_types.h:397:38: error: call to ‘__compiletime_assert_1803’ declared with attribute error: FIELD_PREP: mask is not constant _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^ ././include/linux/compiler_types.h:378:4: note: in definition of macro ‘__compiletime_assert’ prefix ## suffix(); \ ^~ ././include/linux/compiler_types.h:397:2: note: in expansion of macro ‘_compiletime_assert’ _compiletime_assert(condition, msg, __compiletime_assert_, __COUNTER__) ^~~ ./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’ #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg) ^~ ./include/linux/bitfield.h:65:3: note: in expansion of macro ‘BUILD_BUG_ON_MSG’ BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ ^~~~ ./include/linux/bitfield.h:114:3: note: in expansion of macro ‘__BF_FIELD_CHECK’ __BF_FIELD_CHECK(_mask, 0ULL,
[Intel-gfx] [PATCH] drm/i915/gt: Fix reservation address in ggtt_reserve_guc_top
There is an assertion in ggtt_reserve_guc_top that the global GTT
is of size at least GUC_GGTT_TOP, which is not the case on a 32-bit
platform; see commit 562d55d991b39ce376c492df2f7890fd6a541ffc
("drm/i915/bdw: Only use 2g GGTT for 32b platforms"). If GEM_BUG_ON
is enabled, this triggers a BUG(); if GEM_BUG_ON is disabled, the
subsequent reservation fails and the driver fails to initialise
the device:
i915 :00:02.0: [drm:i915_init_ggtt [i915]] Failed to reserve top of GGTT
for GuC
i915 :00:02.0: Device initialization failed (-28)
i915 :00:02.0: Please file a bug on drm/i915; see
https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs for
details.
i915: probe of :00:02.0 failed with error -28
Make the reservation at the top of the available space, whatever
that is, instead of assuming that the top will be GUC_GGTT_TOP.
Fixes: 911800765ef6 ("drm/i915/uc: Reserve upper range of GGTT")
Signed-off-by: Javier Pello
Cc: intel-gfx@lists.freedesktop.org
Cc: sta...@vger.kernel.org # v5.3+
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index e9328e1a..0157bebb 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -511,20 +511,29 @@ void intel_ggtt_unbind_vma(struct i915_address_space *vm,
vm->clear_range(vm, vma_res->start, vma_res->vma_size);
}
+/* Reserve the top of the GuC address space for firmware images. Addresses
+ * beyond GUC_GGTT_TOP in the GuC address space are inaccessible by GuC,
+ * which makes for a suitable range to hold GuC/HuC firmware images if the
+ * size of the GGTT is 4G. However, on a 32-bit platform the size of the GGTT
+ * is limited to 2G, which is less than GUC_GGTT_TOP, but we reserve a chunk
+ * of the same size anyway, which is far more than needed, to keep the logic
+ * in uc_fw_ggtt_offset() simple. */
+#define GUC_TOP_RESERVE_SIZE (SZ_4G - GUC_GGTT_TOP)
+
static int ggtt_reserve_guc_top(struct i915_ggtt *ggtt)
{
- u64 size;
+ u64 offset;
int ret;
if (!intel_uc_uses_guc(>vm.gt->uc))
return 0;
- GEM_BUG_ON(ggtt->vm.total <= GUC_GGTT_TOP);
- size = ggtt->vm.total - GUC_GGTT_TOP;
+ GEM_BUG_ON(ggtt->vm.total <= GUC_TOP_RESERVE_SIZE);
+ offset = ggtt->vm.total - GUC_TOP_RESERVE_SIZE;
- ret = i915_gem_gtt_reserve(>vm, NULL, >uc_fw, size,
- GUC_GGTT_TOP, I915_COLOR_UNEVICTABLE,
- PIN_NOEVICT);
+ ret = i915_gem_gtt_reserve(>vm, NULL, >uc_fw,
+ GUC_TOP_RESERVE_SIZE, offset,
+ I915_COLOR_UNEVICTABLE, PIN_NOEVICT);
if (ret)
drm_dbg(>vm.i915->drm,
"Failed to reserve top of GGTT for GuC\n");
--
2.41.0
Re: [Intel-gfx] [PATCH v15 12/23] drm/shmem-helper: Add and use pages_pin_count
On Sun, 27 Aug 2023 20:54:38 +0300
Dmitry Osipenko wrote:
> Add separate pages_pin_count for tracking of whether drm-shmem pages are
> moveable or not. With the addition of memory shrinker support to drm-shmem,
> the pages_use_count will no longer determine whether pages are hard-pinned
> in memory, but whether pages exit and are soft-pinned (and could be swapped
> out). The pages_pin_count > 1 will hard-pin pages in memory.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 22 +-
> include/drm/drm_gem_shmem_helper.h | 10 ++
> 2 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index d545d3d227d7..1a7e5c332fd8 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -234,14 +234,22 @@ static int drm_gem_shmem_pin_locked(struct
> drm_gem_shmem_object *shmem)
>
> dma_resv_assert_held(shmem->base.resv);
>
> + if (kref_get_unless_zero(>pages_pin_count))
> + return 0;
> +
> ret = drm_gem_shmem_get_pages_locked(shmem);
> + if (!ret)
> + kref_init(>pages_pin_count);
>
> return ret;
> }
>
> -static void drm_gem_shmem_unpin_locked(struct drm_gem_shmem_object *shmem)
> +static void drm_gem_shmem_kref_unpin_pages(struct kref *kref)
> {
> - dma_resv_assert_held(shmem->base.resv);
> + struct drm_gem_shmem_object *shmem;
> +
> + shmem = container_of(kref, struct drm_gem_shmem_object,
> + pages_pin_count);
>
> drm_gem_shmem_put_pages_locked(shmem);
> }
> @@ -263,6 +271,9 @@ int drm_gem_shmem_pin(struct drm_gem_shmem_object *shmem)
>
> drm_WARN_ON(obj->dev, obj->import_attach);
>
> + if (kref_get_unless_zero(>pages_pin_count))
> + return 0;
> +
> ret = dma_resv_lock_interruptible(shmem->base.resv, NULL);
> if (ret)
> return ret;
> @@ -286,9 +297,10 @@ void drm_gem_shmem_unpin(struct drm_gem_shmem_object
> *shmem)
>
> drm_WARN_ON(obj->dev, obj->import_attach);
>
> - dma_resv_lock(shmem->base.resv, NULL);
> - drm_gem_shmem_unpin_locked(shmem);
> - dma_resv_unlock(shmem->base.resv);
> + if (kref_put_dma_resv(>pages_pin_count,
> + drm_gem_shmem_kref_unpin_pages,
> + obj->resv, NULL))
> + dma_resv_unlock(obj->resv);
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_unpin);
>
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index ec2d8b24e3cf..afb7cd671e2a 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -39,6 +39,16 @@ struct drm_gem_shmem_object {
>*/
> unsigned int pages_use_count;
>
> + /**
> + * @pages_pin_count:
> + *
> + * Reference count on the pinned pages table.
> + * The pages allowed to be evicted and purged by memory
> + * shrinker only when the count is zero, otherwise pages
> + * are hard-pinned in memory.
> + */
> + struct kref pages_pin_count;
I know it's tempting to use kref for the pages use/pin count, but I'm
wondering if we wouldn't be better using a refcount_t, which provides
overflow/underflow protection while still letting us control how we
want to handle the locking for 0 <-> 1 transitions. By doing that, we
avoid introducing core locking changes that might be more
controversial/longer to get accepted. Besides, I suspect the resulting
code (the one using a refcount_t) won't be more verbose/complicated (no
release functions needed if you don't use kref_put(), which makes
things closer to what we have right now).
> +
> /**
>* @madv: State for madvise
>*
Re: [Intel-gfx] [PATCH v15 09/23] drm/shmem-helper: Remove obsoleted is_iomem test
On Sun, 27 Aug 2023 20:54:35 +0300
Dmitry Osipenko wrote:
> Everything that uses the mapped buffer should by agnostic to is_iomem.
^be
> The only reason for the is_iomem test is that we're setting shmem->vaddr
> to the returned map->vaddr. Now that the shmem->vaddr code is gone, remove
> the obsoleted is_iomem test to clean up the code.
>
> Suggested-by: Thomas Zimmermann
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 6 --
> 1 file changed, 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index f053dc511508..d545d3d227d7 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -315,12 +315,6 @@ int drm_gem_shmem_vmap_locked(struct
> drm_gem_shmem_object *shmem,
>
> if (obj->import_attach) {
> ret = dma_buf_vmap(obj->import_attach->dmabuf, map);
> - if (!ret) {
> - if (drm_WARN_ON(obj->dev, map->is_iomem)) {
> - dma_buf_vunmap(obj->import_attach->dmabuf, map);
> - return -EIO;
> - }
> - }
> } else {
> pgprot_t prot = PAGE_KERNEL;
>
Re: [Intel-gfx] [PATCH v15 08/23] drm/shmem-helper: Refactor locked/unlocked functions
On Sun, 27 Aug 2023 20:54:34 +0300
Dmitry Osipenko wrote:
> Add locked and remove unlocked postfixes from drm-shmem function names,
> making names consistent with the drm/gem core code.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c| 64 +--
> drivers/gpu/drm/lima/lima_gem.c | 8 +--
> drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_gem.c | 6 +-
> .../gpu/drm/panfrost/panfrost_gem_shrinker.c | 2 +-
> drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +-
> drivers/gpu/drm/v3d/v3d_bo.c | 4 +-
> drivers/gpu/drm/virtio/virtgpu_object.c | 4 +-
> include/drm/drm_gem_shmem_helper.h| 36 +--
> 9 files changed, 64 insertions(+), 64 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 575704f38808..f053dc511508 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -43,8 +43,8 @@ static const struct drm_gem_object_funcs
> drm_gem_shmem_funcs = {
> .pin = drm_gem_shmem_object_pin,
> .unpin = drm_gem_shmem_object_unpin,
> .get_sg_table = drm_gem_shmem_object_get_sg_table,
> - .vmap = drm_gem_shmem_object_vmap,
> - .vunmap = drm_gem_shmem_object_vunmap,
> + .vmap = drm_gem_shmem_object_vmap_locked,
> + .vunmap = drm_gem_shmem_object_vunmap_locked,
> .mmap = drm_gem_shmem_object_mmap,
> .vm_ops = _gem_shmem_vm_ops,
> };
> @@ -153,7 +153,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> kfree(shmem->sgt);
> }
> if (shmem->got_sgt)
> - drm_gem_shmem_put_pages(shmem);
> + drm_gem_shmem_put_pages_locked(shmem);
>
> drm_WARN_ON(obj->dev, shmem->pages_use_count);
>
> @@ -165,7 +165,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_free);
>
> -static int drm_gem_shmem_get_pages(struct drm_gem_shmem_object *shmem)
> +static int drm_gem_shmem_get_pages_locked(struct drm_gem_shmem_object *shmem)
> {
> struct drm_gem_object *obj = >base;
> struct page **pages;
> @@ -199,12 +199,12 @@ static int drm_gem_shmem_get_pages(struct
> drm_gem_shmem_object *shmem)
> }
>
> /*
> - * drm_gem_shmem_put_pages - Decrease use count on the backing pages for a
> shmem GEM object
> + * drm_gem_shmem_put_pages_locked - Decrease use count on the backing pages
> for a shmem GEM object
> * @shmem: shmem GEM object
> *
> * This function decreases the use count and puts the backing pages when use
> drops to zero.
> */
> -void drm_gem_shmem_put_pages(struct drm_gem_shmem_object *shmem)
> +void drm_gem_shmem_put_pages_locked(struct drm_gem_shmem_object *shmem)
> {
> struct drm_gem_object *obj = >base;
>
> @@ -226,7 +226,7 @@ void drm_gem_shmem_put_pages(struct drm_gem_shmem_object
> *shmem)
> shmem->pages_mark_accessed_on_put);
> shmem->pages = NULL;
> }
> -EXPORT_SYMBOL_GPL(drm_gem_shmem_put_pages);
> +EXPORT_SYMBOL_GPL(drm_gem_shmem_put_pages_locked);
>
> static int drm_gem_shmem_pin_locked(struct drm_gem_shmem_object *shmem)
> {
> @@ -234,7 +234,7 @@ static int drm_gem_shmem_pin_locked(struct
> drm_gem_shmem_object *shmem)
>
> dma_resv_assert_held(shmem->base.resv);
>
> - ret = drm_gem_shmem_get_pages(shmem);
> + ret = drm_gem_shmem_get_pages_locked(shmem);
>
> return ret;
> }
> @@ -243,7 +243,7 @@ static void drm_gem_shmem_unpin_locked(struct
> drm_gem_shmem_object *shmem)
> {
> dma_resv_assert_held(shmem->base.resv);
>
> - drm_gem_shmem_put_pages(shmem);
> + drm_gem_shmem_put_pages_locked(shmem);
> }
>
> /**
> @@ -293,7 +293,7 @@ void drm_gem_shmem_unpin(struct drm_gem_shmem_object
> *shmem)
> EXPORT_SYMBOL_GPL(drm_gem_shmem_unpin);
>
> /*
> - * drm_gem_shmem_vmap - Create a virtual mapping for a shmem GEM object
> + * drm_gem_shmem_vmap_locked - Create a virtual mapping for a shmem GEM
> object
> * @shmem: shmem GEM object
> * @map: Returns the kernel virtual address of the SHMEM GEM object's backing
> * store.
> @@ -302,13 +302,13 @@ EXPORT_SYMBOL_GPL(drm_gem_shmem_unpin);
> * exists for the buffer backing the shmem GEM object. It hides the
> differences
> * between dma-buf imported and natively allocated objects.
> *
> - * Acquired mappings should be cleaned up by calling drm_gem_shmem_vunmap().
> + * Acquired mappings should be cleaned up by calling
> drm_gem_shmem_vunmap_locked().
> *
> * Returns:
> * 0 on success or a negative error code on failure.
> */
> -int drm_gem_shmem_vmap(struct drm_gem_shmem_object *shmem,
> -struct iosys_map *map)
> +int drm_gem_shmem_vmap_locked(struct
Re: [Intel-gfx] [PATCH v15 04/23] drm/gem: Add _locked postfix to functions that have unlocked counterpart
On Sun, 27 Aug 2023 20:54:30 +0300
Dmitry Osipenko wrote:
> Add _locked postfix to drm_gem functions that have unlocked counterpart
> functions to make GEM functions naming more consistent and intuitive in
> regards to the locking requirements.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_gem.c | 6 +++---
> include/drm/drm_gem.h | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index fae5832bb0bd..8c0268944199 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1488,10 +1488,10 @@ drm_gem_lru_scan(struct drm_gem_lru *lru,
> EXPORT_SYMBOL(drm_gem_lru_scan);
>
> /**
> - * drm_gem_evict - helper to evict backing pages for a GEM object
> + * drm_gem_evict_locked - helper to evict backing pages for a GEM object
> * @obj: obj in question
> */
> -int drm_gem_evict(struct drm_gem_object *obj)
> +int drm_gem_evict_locked(struct drm_gem_object *obj)
> {
> dma_resv_assert_held(obj->resv);
>
> @@ -1503,4 +1503,4 @@ int drm_gem_evict(struct drm_gem_object *obj)
>
> return 0;
> }
> -EXPORT_SYMBOL(drm_gem_evict);
> +EXPORT_SYMBOL(drm_gem_evict_locked);
> diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
> index f338f8cfacf7..e78e6d817451 100644
> --- a/include/drm/drm_gem.h
> +++ b/include/drm/drm_gem.h
> @@ -542,7 +542,7 @@ unsigned long drm_gem_lru_scan(struct drm_gem_lru *lru,
> unsigned long *remaining,
> bool (*shrink)(struct drm_gem_object *obj));
>
> -int drm_gem_evict(struct drm_gem_object *obj);
> +int drm_gem_evict_locked(struct drm_gem_object *obj);
>
> #ifdef CONFIG_LOCKDEP
> /**
Re: [Intel-gfx] [PATCH v15 03/23] drm/gem: Change locked/unlocked postfix of drm_gem_v/unmap() function names
On Sun, 27 Aug 2023 20:54:29 +0300
Dmitry Osipenko wrote:
> Make drm/gem API function names consistent by having locked function
> use the _locked postfix in the name, while the unlocked variants don't
> use the _unlocked postfix. Rename drm_gem_v/unmap() function names to
> make them consistent with the rest of the API functions.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/drm_client.c | 6 +++---
> drivers/gpu/drm/drm_gem.c| 20 ++--
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 6 +++---
> drivers/gpu/drm/drm_internal.h | 4 ++--
> drivers/gpu/drm/drm_prime.c | 4 ++--
> drivers/gpu/drm/lima/lima_sched.c| 4 ++--
> drivers/gpu/drm/panfrost/panfrost_dump.c | 4 ++--
> drivers/gpu/drm/panfrost/panfrost_perfcnt.c | 6 +++---
> include/drm/drm_gem.h| 4 ++--
> 9 files changed, 29 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index 037e36f2049c..29306657117a 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -265,7 +265,7 @@ void drm_client_dev_restore(struct drm_device *dev)
> static void drm_client_buffer_delete(struct drm_client_buffer *buffer)
> {
> if (buffer->gem) {
> - drm_gem_vunmap_unlocked(buffer->gem, >map);
> + drm_gem_vunmap(buffer->gem, >map);
> drm_gem_object_put(buffer->gem);
> }
>
> @@ -349,7 +349,7 @@ drm_client_buffer_vmap(struct drm_client_buffer *buffer,
>* fd_install step out of the driver backend hooks, to make that
>* final step optional for internal users.
>*/
> - ret = drm_gem_vmap_unlocked(buffer->gem, map);
> + ret = drm_gem_vmap(buffer->gem, map);
> if (ret)
> return ret;
>
> @@ -371,7 +371,7 @@ void drm_client_buffer_vunmap(struct drm_client_buffer
> *buffer)
> {
> struct iosys_map *map = >map;
>
> - drm_gem_vunmap_unlocked(buffer->gem, map);
> + drm_gem_vunmap(buffer->gem, map);
> }
> EXPORT_SYMBOL(drm_client_buffer_vunmap);
>
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 6129b89bb366..fae5832bb0bd 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
> @@ -1173,7 +1173,7 @@ void drm_gem_unpin(struct drm_gem_object *obj)
> obj->funcs->unpin(obj);
> }
>
> -int drm_gem_vmap(struct drm_gem_object *obj, struct iosys_map *map)
> +int drm_gem_vmap_locked(struct drm_gem_object *obj, struct iosys_map *map)
> {
> int ret;
>
> @@ -1190,9 +1190,9 @@ int drm_gem_vmap(struct drm_gem_object *obj, struct
> iosys_map *map)
>
> return 0;
> }
> -EXPORT_SYMBOL(drm_gem_vmap);
> +EXPORT_SYMBOL(drm_gem_vmap_locked);
>
> -void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
> +void drm_gem_vunmap_locked(struct drm_gem_object *obj, struct iosys_map *map)
> {
> dma_resv_assert_held(obj->resv);
>
> @@ -1205,27 +1205,27 @@ void drm_gem_vunmap(struct drm_gem_object *obj,
> struct iosys_map *map)
> /* Always set the mapping to NULL. Callers may rely on this. */
> iosys_map_clear(map);
> }
> -EXPORT_SYMBOL(drm_gem_vunmap);
> +EXPORT_SYMBOL(drm_gem_vunmap_locked);
>
> -int drm_gem_vmap_unlocked(struct drm_gem_object *obj, struct iosys_map *map)
> +int drm_gem_vmap(struct drm_gem_object *obj, struct iosys_map *map)
> {
> int ret;
>
> dma_resv_lock(obj->resv, NULL);
> - ret = drm_gem_vmap(obj, map);
> + ret = drm_gem_vmap_locked(obj, map);
> dma_resv_unlock(obj->resv);
>
> return ret;
> }
> -EXPORT_SYMBOL(drm_gem_vmap_unlocked);
> +EXPORT_SYMBOL(drm_gem_vmap);
>
> -void drm_gem_vunmap_unlocked(struct drm_gem_object *obj, struct iosys_map
> *map)
> +void drm_gem_vunmap(struct drm_gem_object *obj, struct iosys_map *map)
> {
> dma_resv_lock(obj->resv, NULL);
> - drm_gem_vunmap(obj, map);
> + drm_gem_vunmap_locked(obj, map);
> dma_resv_unlock(obj->resv);
> }
> -EXPORT_SYMBOL(drm_gem_vunmap_unlocked);
> +EXPORT_SYMBOL(drm_gem_vunmap);
>
> /**
> * drm_gem_lock_reservations - Sets up the ww context and acquires
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index 3bdb6ba37ff4..3808f47310bf 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -362,7 +362,7 @@ int drm_gem_fb_vmap(struct drm_framebuffer *fb, struct
> iosys_map *map,
> ret = -EINVAL;
> goto err_drm_gem_vunmap;
> }
> - ret = drm_gem_vmap_unlocked(obj, [i]);
> + ret = drm_gem_vmap(obj, [i]);
> if (ret)
> goto err_drm_gem_vunmap;
> }
> @@ -384,7 +384,7 @@ int
Re: [Intel-gfx] [PATCH v15 01/23] drm/shmem-helper: Fix UAF in error path when freeing SGT of imported GEM
On Sun, 27 Aug 2023 20:54:27 +0300
Dmitry Osipenko wrote:
> Freeing drm-shmem GEM right after creating it using
> drm_gem_shmem_prime_import_sg_table() frees SGT of the imported dma-buf
> and then dma-buf frees this SGT second time.
>
> The v3d_prime_import_sg_table() is example of a error code path where
> dma-buf's SGT is freed by drm-shmem and then it's freed second time by
> dma_buf_unmap_attachment() in drm_gem_prime_import_dev().
>
> Add drm-shmem GEM flag telling that this is imported SGT shall not be
> treated as own SGT, fixing the use-after-free bug.
>
> Cc: sta...@vger.kernel.org
> Fixes: 2194a63a818d ("drm: Add library for shmem backed GEM objects")
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
> include/drm/drm_gem_shmem_helper.h | 7 +++
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index a783d2245599..78d9cf2355a5 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -141,7 +141,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
>
> if (obj->import_attach) {
> drm_prime_gem_destroy(obj, shmem->sgt);
> - } else {
> + } else if (!shmem->imported_sgt) {
> dma_resv_lock(shmem->base.resv, NULL);
>
> drm_WARN_ON(obj->dev, shmem->vmap_use_count);
> @@ -758,6 +758,7 @@ drm_gem_shmem_prime_import_sg_table(struct drm_device
> *dev,
> return ERR_CAST(shmem);
>
> shmem->sgt = sgt;
> + shmem->imported_sgt = true;
I feel like adding more fields that can be used to do the is_imported()
check is going to be even more confusing. Can we instead have
/* drm_gem_shmem_prime_import_sg_table() can be called from a
* driver specific ->import_sg_table() implementations that
* have extra failable initialization steps. Assign
* drm_gem_object::import_attach here (even though it's
* assigned in drm_gem_prime_import_dev()), so we don't end up
* with driver error paths calling drm_gem_shmem_free() with an
* imported sg_table assigned to drm_gem_shmem_object::sgt and
* drm_gem_object::import_attach left uninitialized.
*/
shmem->base.import_attach = attach;
here?
>
> drm_dbg_prime(dev, "size = %zu\n", size);
>
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index bf0c31aa8fbe..ec70a98a8fe1 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -73,6 +73,13 @@ struct drm_gem_shmem_object {
>*/
> unsigned int vmap_use_count;
>
> + /**
> + * @imported_sgt:
> + *
> + * True if SG table belongs to imported dma-buf.
> + */
> + bool imported_sgt : 1;
> +
> /**
>* @pages_mark_dirty_on_put:
>*
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Update workaround 14016712196
== Series Details == Series: drm/i915/mtl: Update workaround 14016712196 URL : https://patchwork.freedesktop.org/series/122959/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13570_full -> Patchwork_122959v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_122959v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122959v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 9) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122959v1_full: ### IGT changes ### Possible regressions * igt@gem_exec_schedule@deep@rcs0: - shard-mtlp: [PASS][1] -> [SKIP][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13570/shard-mtlp-1/igt@gem_exec_schedule@d...@rcs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-mtlp-7/igt@gem_exec_schedule@d...@rcs0.html * igt@kms_plane@pixel-format-source-clamping@pipe-b-planes: - shard-rkl: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13570/shard-rkl-7/igt@kms_plane@pixel-format-source-clamp...@pipe-b-planes.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-rkl-2/igt@kms_plane@pixel-format-source-clamp...@pipe-b-planes.html * igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend: - shard-rkl: NOTRUN -> [INCOMPLETE][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-rkl-6/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html Known issues Here are the changes found in Patchwork_122959v1_full that come from known issues: ### IGT changes ### Issues hit * igt@api_intel_bb@object-reloc-keep-cache: - shard-dg2: NOTRUN -> [SKIP][6] ([i915#8411]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-dg2-12/igt@api_intel...@object-reloc-keep-cache.html * igt@device_reset@cold-reset-bound: - shard-tglu: NOTRUN -> [SKIP][7] ([i915#7701]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-tglu-8/igt@device_re...@cold-reset-bound.html * igt@drm_fdinfo@busy-idle-check-all@vcs0: - shard-dg2: NOTRUN -> [SKIP][8] ([i915#8414]) +9 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-dg2-12/igt@drm_fdinfo@busy-idle-check-...@vcs0.html * igt@feature_discovery@chamelium: - shard-rkl: NOTRUN -> [SKIP][9] ([fdo#111827]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-rkl-6/igt@feature_discov...@chamelium.html * igt@gem_create@create-ext-set-pat: - shard-dg2: NOTRUN -> [SKIP][10] ([i915#8562]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-dg2-12/igt@gem_cre...@create-ext-set-pat.html * igt@gem_ctx_param@set-priority-not-supported: - shard-dg2: NOTRUN -> [SKIP][11] ([fdo#109314]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-dg2-12/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@file: - shard-snb: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1099]) +1 similar issue [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-snb4/igt@gem_ctx_persiste...@file.html * igt@gem_eio@kms: - shard-dg1: [PASS][13] -> [FAIL][14] ([i915#5784]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13570/shard-dg1-17/igt@gem_...@kms.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-dg1-17/igt@gem_...@kms.html * igt@gem_exec_balancer@noheartbeat: - shard-dg2: NOTRUN -> [SKIP][15] ([i915#8555]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-dg2-12/igt@gem_exec_balan...@noheartbeat.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][16] -> [FAIL][17] ([i915#2846]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13570/shard-glk1/igt@gem_exec_f...@basic-deadline.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-glk3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglu: [PASS][18] -> [FAIL][19] ([i915#2842]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13570/shard-tglu-10/igt@gem_exec_fair@basic-f...@rcs0.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/shard-tglu-2/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none: - shard-dg2: NOTRUN -> [SKIP][20] ([i915#3539] /
Re: [Intel-gfx] PR for GSC FW release 102.0.0.1655 for MTL
On Wed, Aug 23, 2023 at 2:43 PM Daniele Ceraolo Spurio wrote: > > The following changes since commit 0e048b061bde79ad735c7b7b5161ee1bd3400150: > > Merge branch 'for-upstream' of > https://github.com/CirrusLogic/linux-firmware (2023-08-14 13:03:41 -0400) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-firmware mtl_gsc_1655 Pulled and pushed out. josh > > for you to fetch changes up to 81caac98eda1696fa057191ee969c377154a: > > i915: add GSC 102.0.0.1655 for MTL (2023-08-21 14:13:11 -0700) > > > Daniele Ceraolo Spurio (1): > i915: add GSC 102.0.0.1655 for MTL > > WHENCE | 3 +++ > i915/mtl_gsc_1.bin | Bin 0 -> 1142784 bytes > 2 files changed, 3 insertions(+) > create mode 100755 i915/mtl_gsc_1.bin
Re: [Intel-gfx] [PATCH v15 02/23] drm/shmem-helper: Use flag for tracking page count bumped by get_pages_sgt()
On Sun, 27 Aug 2023 20:54:28 +0300
Dmitry Osipenko wrote:
> Use separate flag for tracking page count bumped by shmem->sgt to avoid
> imbalanced page counter during of drm_gem_shmem_free() time. It's fragile
> to assume that populated shmem->pages at a freeing time means that the
> count was bumped by drm_gem_shmem_get_pages_sgt(), using a flag removes
> the ambiguity.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 3 ++-
> drivers/gpu/drm/lima/lima_gem.c| 1 +
> include/drm/drm_gem_shmem_helper.h | 7 +++
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 78d9cf2355a5..db20b9123891 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -152,7 +152,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> sg_free_table(shmem->sgt);
> kfree(shmem->sgt);
> }
> - if (shmem->pages)
> + if (shmem->got_sgt)
> drm_gem_shmem_put_pages(shmem);
Can't we just move this drm_gem_shmem_put_pages() call in the
if (shmem->sgt) block?
>
> drm_WARN_ON(obj->dev, shmem->pages_use_count);
> @@ -687,6 +687,7 @@ static struct sg_table
> *drm_gem_shmem_get_pages_sgt_locked(struct drm_gem_shmem_
> if (ret)
> goto err_free_sgt;
>
> + shmem->got_sgt = true;
> shmem->sgt = sgt;
>
> return sgt;
> diff --git a/drivers/gpu/drm/lima/lima_gem.c b/drivers/gpu/drm/lima/lima_gem.c
> index 4f9736e5f929..28602302c281 100644
> --- a/drivers/gpu/drm/lima/lima_gem.c
> +++ b/drivers/gpu/drm/lima/lima_gem.c
> @@ -89,6 +89,7 @@ int lima_heap_alloc(struct lima_bo *bo, struct lima_vm *vm)
> }
>
> *bo->base.sgt = sgt;
> + bo->base.got_sgt = true;
>
> if (vm) {
> ret = lima_vm_map_bo(vm, bo, old_size >> PAGE_SHIFT);
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index ec70a98a8fe1..f87124629bb5 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -73,6 +73,13 @@ struct drm_gem_shmem_object {
>*/
> unsigned int vmap_use_count;
>
> + /**
> + * @got_sgt:
> + *
> + * True if SG table was retrieved using drm_gem_shmem_get_pages_sgt()
> + */
> + bool got_sgt : 1;
> +
> /**
>* @imported_sgt:
>*
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/psr: Add psr sink error status into sink status debugfs
== Series Details == Series: drm/i915/psr: Add psr sink error status into sink status debugfs URL : https://patchwork.freedesktop.org/series/122965/ State : success == Summary == CI Bug Log - changes from CI_DRM_13571 -> Patchwork_122965v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/index.html Participating hosts (38 -> 36) -- Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_122965v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#6645]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_psr@primary_mmap_gtt: - bat-rplp-1: NOTRUN -> [SKIP][2] ([i915#1072]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html * igt@kms_setmode@basic-clone-single-crtc: - bat-rplp-1: NOTRUN -> [ABORT][3] ([i915#8260]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html Possible fixes * igt@gem_exec_suspend@basic-s0@lmem0: - bat-dg2-9: [INCOMPLETE][4] ([i915#6311]) -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html * igt@i915_selftest@live@requests: - bat-mtlp-8: [ABORT][6] ([i915#7982] / [i915#8865]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-mtlp-8/igt@i915_selftest@l...@requests.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/bat-mtlp-8/igt@i915_selftest@l...@requests.html Warnings * igt@kms_psr@primary_page_flip: - bat-rplp-1: [ABORT][8] ([i915#8442] / [i915#8668] / [i915#8860]) -> [SKIP][9] ([i915#1072]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13571/bat-rplp-1/igt@kms_psr@primary_page_flip.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/bat-rplp-1/igt@kms_psr@primary_page_flip.html [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311 [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645 [i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982 [i915#8260]: https://gitlab.freedesktop.org/drm/intel/issues/8260 [i915#8442]: https://gitlab.freedesktop.org/drm/intel/issues/8442 [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668 [i915#8860]: https://gitlab.freedesktop.org/drm/intel/issues/8860 [i915#8865]: https://gitlab.freedesktop.org/drm/intel/issues/8865 Build changes - * Linux: CI_DRM_13571 -> Patchwork_122965v1 CI-20190529: 20190529 CI_DRM_13571: d3f0e020609215d9097f1b1fad5a13ea0b37548e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7454: 7454 Patchwork_122965v1: d3f0e020609215d9097f1b1fad5a13ea0b37548e @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 1514610095f1 drm/i915/psr: Add psr sink error status into sink status debugfs == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122965v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/psr: Add psr sink error status into sink status debugfs
== Series Details == Series: drm/i915/psr: Add psr sink error status into sink status debugfs URL : https://patchwork.freedesktop.org/series/122965/ State : warning == Summary == Error: dim sparse failed /home/kbuild2/linux/maintainer-tools/dim: line 50: /home/kbuild2/.dimrc: No such file or directory
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/psr: Add psr sink error status into sink status debugfs
== Series Details == Series: drm/i915/psr: Add psr sink error status into sink status debugfs URL : https://patchwork.freedesktop.org/series/122965/ State : warning == Summary == Error: dim checkpatch failed /home/kbuild2/linux/maintainer-tools/dim: line 50: /home/kbuild2/.dimrc: No such file or directory
Re: [Intel-gfx] [PATCH v15 11/23] dma-resv: Add kref_put_dma_resv()
Am 27.08.23 um 19:54 schrieb Dmitry Osipenko:
Add simple kref_put_dma_resv() helper that wraps around kref_put_ww_mutex()
for drivers that needs to lock dma-resv on kref_put().
It's not possible to easily add this helper to kref.h because of the
headers inclusion dependency, hence add it to dma-resv.h.
I was never really a big fan of kref_put_mutex() in the first place.
The main advantage comes from the included memory barrier, but this
actually doesn't work like most people think it works and is usually
pretty dangerous.
And IIRC this was done because of the some special behavior mutexes have
with memory barriers and that isn't necessary with ww-mutex.
Christian.
Signed-off-by: Dmitry Osipenko
---
include/linux/dma-resv.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index 8d0e34dad446..c5cf302e4194 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -41,6 +41,7 @@
#include
#include
+#include
#include
#include
#include
@@ -464,6 +465,14 @@ static inline void dma_resv_unlock(struct dma_resv *obj)
ww_mutex_unlock(>lock);
}
+static inline int kref_put_dma_resv(struct kref *kref,
+ void (*release)(struct kref *kref),
+ struct dma_resv *resv,
+ struct ww_acquire_ctx *ctx)
+{
+ return kref_put_ww_mutex(kref, release, >lock, ctx);
+}
+
void dma_resv_init(struct dma_resv *obj);
void dma_resv_fini(struct dma_resv *obj);
int dma_resv_reserve_fences(struct dma_resv *obj, unsigned int num_fences);
Re: [Intel-gfx] [PATCH v15 17/23] drm/shmem-helper: Add and use drm_gem_shmem_resv_assert_held() helper
On Sun, 27 Aug 2023 20:54:43 +0300
Dmitry Osipenko wrote:
> In a preparation of adding drm-shmem memory shrinker, move all reservation
> locking lockdep checks to use new drm_gem_shmem_resv_assert_held() that
> will resolve spurious lockdep warning about wrong locking order vs
> fs_reclam code paths during freeing of shmem GEM, where lockdep isn't
> aware that it's impossible to have locking contention with the fs_reclam
> at this special time.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 37 +-
> 1 file changed, 25 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index d96fee3d6166..ca5da976aafa 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -128,6 +128,23 @@ struct drm_gem_shmem_object *drm_gem_shmem_create(struct
> drm_device *dev, size_t
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_create);
>
> +static void drm_gem_shmem_resv_assert_held(struct drm_gem_shmem_object
> *shmem)
> +{
> + /*
> + * Destroying the object is a special case.. drm_gem_shmem_free()
> + * calls many things that WARN_ON if the obj lock is not held. But
> + * acquiring the obj lock in drm_gem_shmem_free() can cause a locking
> + * order inversion between reservation_ww_class_mutex and fs_reclaim.
> + *
> + * This deadlock is not actually possible, because no one should
> + * be already holding the lock when drm_gem_shmem_free() is called.
> + * Unfortunately lockdep is not aware of this detail. So when the
> + * refcount drops to zero, we pretend it is already locked.
> + */
> + if (kref_read(>base.refcount))
> + drm_gem_shmem_resv_assert_held(shmem);
> +}
> +
> /**
> * drm_gem_shmem_free - Free resources associated with a shmem GEM object
> * @shmem: shmem GEM object to free
> @@ -142,8 +159,6 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> if (obj->import_attach) {
> drm_prime_gem_destroy(obj, shmem->sgt);
> } else if (!shmem->imported_sgt) {
> - dma_resv_lock(shmem->base.resv, NULL);
> -
> drm_WARN_ON(obj->dev, kref_read(>vmap_use_count));
>
> if (shmem->sgt) {
> @@ -156,8 +171,6 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> drm_gem_shmem_put_pages_locked(shmem);
AFAICT, drm_gem_shmem_put_pages_locked() is the only function that's
called in the free path and would complain about resv-lock not being
held. I think I'd feel more comfortable if we were adding a
drm_gem_shmem_free_pages() function that did everything
drm_gem_shmem_put_pages_locked() does except for the lock_held() check
and the refcount dec, and have it called here (and in
drm_gem_shmem_put_pages_locked()). This way we can keep using
dma_resv_assert_held() instead of having our own variant.
>
> drm_WARN_ON(obj->dev, kref_read(>pages_use_count));
> -
> - dma_resv_unlock(shmem->base.resv);
> }
>
> drm_gem_object_release(obj);
> @@ -170,7 +183,7 @@ static int drm_gem_shmem_get_pages_locked(struct
> drm_gem_shmem_object *shmem)
> struct drm_gem_object *obj = >base;
> struct page **pages;
>
> - dma_resv_assert_held(shmem->base.resv);
> + drm_gem_shmem_resv_assert_held(shmem);
>
> if (kref_get_unless_zero(>pages_use_count))
> return 0;
> @@ -228,7 +241,7 @@ static void drm_gem_shmem_kref_release_pages(struct kref
> *kref)
> */
> void drm_gem_shmem_put_pages_locked(struct drm_gem_shmem_object *shmem)
> {
> - dma_resv_assert_held(shmem->base.resv);
> + drm_gem_shmem_resv_assert_held(shmem);
>
> kref_put(>pages_use_count, drm_gem_shmem_kref_release_pages);
> }
> @@ -252,7 +265,7 @@ static int drm_gem_shmem_pin_locked(struct
> drm_gem_shmem_object *shmem)
> {
> int ret;
>
> - dma_resv_assert_held(shmem->base.resv);
> + drm_gem_shmem_resv_assert_held(shmem);
>
> if (kref_get_unless_zero(>pages_pin_count))
> return 0;
> @@ -276,7 +289,7 @@ static void drm_gem_shmem_kref_unpin_pages(struct kref
> *kref)
>
> static void drm_gem_shmem_unpin_locked(struct drm_gem_shmem_object *shmem)
> {
> - dma_resv_assert_held(shmem->base.resv);
> + drm_gem_shmem_resv_assert_held(shmem);
>
> kref_put(>pages_pin_count, drm_gem_shmem_kref_unpin_pages);
> }
> @@ -357,7 +370,7 @@ int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object
> *shmem,
> } else {
> pgprot_t prot = PAGE_KERNEL;
>
> - dma_resv_assert_held(shmem->base.resv);
> + drm_gem_shmem_resv_assert_held(shmem);
>
> if (kref_get_unless_zero(>vmap_use_count)) {
> iosys_map_set_vaddr(map, shmem->vaddr);
> @@ -426,7 +439,7 @@ void drm_gem_shmem_vunmap_locked(struct
>
Re: [Intel-gfx] [Intel-xe] [PATCH 3/4] drm/i915/lnl: support FBC on any plane
On Mon, 2023-08-28 at 12:00 +0300, Jani Nikula wrote: > On Mon, 28 Aug 2023, Vinod Govindapillai > wrote: > > diff --git a/drivers/gpu/drm/i915/i915_reg.h > > b/drivers/gpu/drm/i915/i915_reg.h > > index aefad14ab27a..b207774f3c33 100644 > > --- a/drivers/gpu/drm/i915/i915_reg.h > > +++ b/drivers/gpu/drm/i915/i915_reg.h > > @@ -1327,6 +1327,10 @@ > > #define DPFC_CTL_PLANE_IVB(i9xx_plane) > > REG_FIELD_PREP(DPFC_CTL_PLANE_MASK_IVB, > > (i9xx_plane)) > > #define DPFC_CTL_FENCE_EN_IVBREG_BIT(28) /* ivb+ > > */ > > #define DPFC_CTL_PERSISTENT_MODE REG_BIT(25) /* g4x-snb */ > > +#define DPFC_CTL_PLANE_BINDING_MASK REG_GENMASK(12, 11) /* XE */ > > +#define DPFC_CTL_PLANE_BINDING_1 > > REG_FIELD_PREP(DPFC_CTL_PLANE_BINDING_MASK, 0) > > /* XE */ > > +#define DPFC_CTL_PLANE_BINDING_2 > > REG_FIELD_PREP(DPFC_CTL_PLANE_BINDING_MASK, 1) > > /* XE */ > > +#define DPFC_CTL_PLANE_BINDING_3 > > REG_FIELD_PREP(DPFC_CTL_PLANE_BINDING_MASK, 2) > > /* XE */ > > What's with the /* XE */ comments? Forgot to update that! I will add "lnl+" similar to lines above. BR Vinod > > BR, > Jani. > >
Re: [Intel-gfx] [PATCH v15 16/23] drm/shmem-helper: Use kref for vmap_use_count
On Sun, 27 Aug 2023 20:54:42 +0300
Dmitry Osipenko wrote:
> Use kref helper for vmap_use_count to make refcounting consistent with
> pages_use_count and pages_pin_count that use kref. This will allow to
> optimize unlocked vmappings by skipping reservation locking if refcnt > 1.
The core is taking the resv lock before calling ->v[un]map(), so
switching to a kref sounds a bit premature/useless, unless there are
plans to delegate the locking to the drivers. The only thing it brings
is standard overflow/underflow checks. Not really sure it's worth
transitioning to a kref for this field until we have a real use case.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 37 ++
> include/drm/drm_gem_shmem_helper.h | 2 +-
> 2 files changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index 17a0177acb5d..d96fee3d6166 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -144,7 +144,7 @@ void drm_gem_shmem_free(struct drm_gem_shmem_object
> *shmem)
> } else if (!shmem->imported_sgt) {
> dma_resv_lock(shmem->base.resv, NULL);
>
> - drm_WARN_ON(obj->dev, shmem->vmap_use_count);
> + drm_WARN_ON(obj->dev, kref_read(>vmap_use_count));
>
> if (shmem->sgt) {
> dma_unmap_sgtable(obj->dev->dev, shmem->sgt,
> @@ -359,23 +359,25 @@ int drm_gem_shmem_vmap_locked(struct
> drm_gem_shmem_object *shmem,
>
> dma_resv_assert_held(shmem->base.resv);
>
> - if (shmem->vmap_use_count++ > 0) {
> + if (kref_get_unless_zero(>vmap_use_count)) {
> iosys_map_set_vaddr(map, shmem->vaddr);
> return 0;
> }
>
> ret = drm_gem_shmem_pin_locked(shmem);
> if (ret)
> - goto err_zero_use;
> + return ret;
>
> if (shmem->map_wc)
> prot = pgprot_writecombine(prot);
> shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
> VM_MAP, prot);
> - if (!shmem->vaddr)
> + if (!shmem->vaddr) {
> ret = -ENOMEM;
> - else
> + } else {
> iosys_map_set_vaddr(map, shmem->vaddr);
> + kref_init(>vmap_use_count);
> + }
> }
>
> if (ret) {
> @@ -388,13 +390,22 @@ int drm_gem_shmem_vmap_locked(struct
> drm_gem_shmem_object *shmem,
> err_put_pages:
> if (!obj->import_attach)
> drm_gem_shmem_unpin_locked(shmem);
> -err_zero_use:
> - shmem->vmap_use_count = 0;
>
> return ret;
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_vmap_locked);
>
> +static void drm_gem_shmem_kref_vunmap(struct kref *kref)
> +{
> + struct drm_gem_shmem_object *shmem;
> +
> + shmem = container_of(kref, struct drm_gem_shmem_object,
> + vmap_use_count);
> +
> + vunmap(shmem->vaddr);
> + drm_gem_shmem_unpin_locked(shmem);
> +}
> +
> /*
> * drm_gem_shmem_vunmap_locked - Unmap a virtual mapping for a shmem GEM
> object
> * @shmem: shmem GEM object
> @@ -416,15 +427,7 @@ void drm_gem_shmem_vunmap_locked(struct
> drm_gem_shmem_object *shmem,
> dma_buf_vunmap(obj->import_attach->dmabuf, map);
> } else {
> dma_resv_assert_held(shmem->base.resv);
> -
> - if (drm_WARN_ON_ONCE(obj->dev, !shmem->vmap_use_count))
> - return;
> -
> - if (--shmem->vmap_use_count > 0)
> - return;
> -
> - vunmap(shmem->vaddr);
> - drm_gem_shmem_unpin_locked(shmem);
> + kref_put(>vmap_use_count, drm_gem_shmem_kref_vunmap);
> }
>
> shmem->vaddr = NULL;
> @@ -663,7 +666,7 @@ void drm_gem_shmem_print_info(const struct
> drm_gem_shmem_object *shmem,
> return;
>
> drm_printf_indent(p, indent, "pages_use_count=%u\n",
> kref_read(>pages_use_count));
> - drm_printf_indent(p, indent, "vmap_use_count=%u\n",
> shmem->vmap_use_count);
> + drm_printf_indent(p, indent, "vmap_use_count=%u\n",
> kref_read(>vmap_use_count));
> drm_printf_indent(p, indent, "vaddr=%p\n", shmem->vaddr);
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_print_info);
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index 400ecd63f45f..0e0ccd380f66 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -81,7 +81,7 @@ struct drm_gem_shmem_object {
>* Reference count on the virtual address.
>* The address are un-mapped when the count reaches zero.
>*/
> - unsigned int vmap_use_count;
> + struct kref
Re: [Intel-gfx] [PATCH v15 12/23] drm/shmem-helper: Add and use pages_pin_count
On Sun, 27 Aug 2023 20:54:38 +0300
Dmitry Osipenko wrote:
> Add separate pages_pin_count for tracking of whether drm-shmem pages are
> moveable or not. With the addition of memory shrinker support to drm-shmem,
> the pages_use_count will no longer determine whether pages are hard-pinned
> in memory, but whether pages exit and are soft-pinned (and could be swapped
^exist
> out). The pages_pin_count > 1 will hard-pin pages in memory.
>
> Suggested-by: Boris Brezillon
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/drm_gem_shmem_helper.c | 22 +-
> include/drm/drm_gem_shmem_helper.h | 10 ++
> 2 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
> b/drivers/gpu/drm/drm_gem_shmem_helper.c
> index d545d3d227d7..1a7e5c332fd8 100644
> --- a/drivers/gpu/drm/drm_gem_shmem_helper.c
> +++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
> @@ -234,14 +234,22 @@ static int drm_gem_shmem_pin_locked(struct
> drm_gem_shmem_object *shmem)
>
> dma_resv_assert_held(shmem->base.resv);
>
> + if (kref_get_unless_zero(>pages_pin_count))
> + return 0;
> +
> ret = drm_gem_shmem_get_pages_locked(shmem);
> + if (!ret)
> + kref_init(>pages_pin_count);
>
> return ret;
> }
>
> -static void drm_gem_shmem_unpin_locked(struct drm_gem_shmem_object *shmem)
> +static void drm_gem_shmem_kref_unpin_pages(struct kref *kref)
> {
> - dma_resv_assert_held(shmem->base.resv);
> + struct drm_gem_shmem_object *shmem;
> +
> + shmem = container_of(kref, struct drm_gem_shmem_object,
> + pages_pin_count);
>
> drm_gem_shmem_put_pages_locked(shmem);
> }
> @@ -263,6 +271,9 @@ int drm_gem_shmem_pin(struct drm_gem_shmem_object *shmem)
>
> drm_WARN_ON(obj->dev, obj->import_attach);
>
> + if (kref_get_unless_zero(>pages_pin_count))
> + return 0;
> +
> ret = dma_resv_lock_interruptible(shmem->base.resv, NULL);
> if (ret)
> return ret;
> @@ -286,9 +297,10 @@ void drm_gem_shmem_unpin(struct drm_gem_shmem_object
> *shmem)
>
> drm_WARN_ON(obj->dev, obj->import_attach);
>
> - dma_resv_lock(shmem->base.resv, NULL);
> - drm_gem_shmem_unpin_locked(shmem);
> - dma_resv_unlock(shmem->base.resv);
> + if (kref_put_dma_resv(>pages_pin_count,
> + drm_gem_shmem_kref_unpin_pages,
> + obj->resv, NULL))
> + dma_resv_unlock(obj->resv);
> }
> EXPORT_SYMBOL_GPL(drm_gem_shmem_unpin);
>
> diff --git a/include/drm/drm_gem_shmem_helper.h
> b/include/drm/drm_gem_shmem_helper.h
> index ec2d8b24e3cf..afb7cd671e2a 100644
> --- a/include/drm/drm_gem_shmem_helper.h
> +++ b/include/drm/drm_gem_shmem_helper.h
> @@ -39,6 +39,16 @@ struct drm_gem_shmem_object {
>*/
> unsigned int pages_use_count;
>
> + /**
> + * @pages_pin_count:
> + *
> + * Reference count on the pinned pages table.
> + * The pages allowed to be evicted and purged by memory
> + * shrinker only when the count is zero, otherwise pages
> + * are hard-pinned in memory.
> + */
> + struct kref pages_pin_count;
> +
> /**
>* @madv: State for madvise
>*
[Intel-gfx] ✗ Fi.CI.BAT: failure for HDCP MST aux issue fix (rev6)
== Series Details == Series: HDCP MST aux issue fix (rev6) URL : https://patchwork.freedesktop.org/series/122267/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13570 -> Patchwork_122267v6 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_122267v6 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122267v6, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/index.html Participating hosts (25 -> 36) -- Additional (13): fi-kbl-soraka fi-kbl-7567u bat-adls-5 bat-adlp-9 bat-dg2-13 bat-adlm-1 fi-cfl-guc fi-kbl-x1275 bat-dg2-14 bat-rpls-1 bat-jsl-1 bat-mtlp-8 bat-mtlp-6 Missing(2): bat-dg2-9 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122267v6: ### IGT changes ### Possible regressions * igt@i915_selftest@live@workarounds: - bat-dg2-11: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13570/bat-dg2-11/igt@i915_selftest@l...@workarounds.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-dg2-11/igt@i915_selftest@l...@workarounds.html Known issues Here are the changes found in Patchwork_122267v6 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#7456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html - bat-adlp-9: NOTRUN -> [SKIP][4] ([i915#7456]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adlp-9/igt@debugfs_t...@basic-hwmon.html - bat-adls-5: NOTRUN -> [SKIP][5] ([i915#7456]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adls-5/igt@debugfs_t...@basic-hwmon.html - bat-adlm-1: NOTRUN -> [SKIP][6] ([i915#7456]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][7] ([i915#7456]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html - bat-rpls-1: NOTRUN -> [SKIP][8] ([i915#7456]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-rpls-1/igt@debugfs_t...@basic-hwmon.html - bat-mtlp-6: NOTRUN -> [SKIP][9] ([i915#7456]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-mtlp-6/igt@debugfs_t...@basic-hwmon.html * igt@debugfs_test@read_all_entries: - fi-kbl-7567u: NOTRUN -> [ABORT][10] ([i915#8913]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/fi-kbl-7567u/igt@debugfs_test@read_all_entries.html * igt@fbdev@eof: - bat-adls-5: NOTRUN -> [SKIP][11] ([i915#2582]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adls-5/igt@fb...@eof.html - bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#2582]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adlm-1/igt@fb...@eof.html * igt@fbdev@info: - fi-kbl-x1275: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#1849]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/fi-kbl-x1275/igt@fb...@info.html - bat-rpls-1: NOTRUN -> [SKIP][14] ([i915#1849] / [i915#2582]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-rpls-1/igt@fb...@info.html - bat-adls-5: NOTRUN -> [SKIP][15] ([i915#1849] / [i915#2582]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adls-5/igt@fb...@info.html - bat-adlm-1: NOTRUN -> [SKIP][16] ([i915#1849] / [i915#2582]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-adlm-1/igt@fb...@info.html - bat-mtlp-6: NOTRUN -> [SKIP][17] ([i915#1849] / [i915#2582]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-mtlp-6/igt@fb...@info.html * igt@fbdev@write: - bat-rpls-1: NOTRUN -> [SKIP][18] ([i915#2582]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-rpls-1/igt@fb...@write.html - bat-mtlp-6: NOTRUN -> [SKIP][19] ([i915#2582]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122267v6/bat-mtlp-6/igt@fb...@write.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][20] ([i915#2190]) [20]:
Re: [Intel-gfx] [PATCH v15 10/23] locking/refcount, kref: Add kref_put_ww_mutex()
On Sun, 27 Aug 2023 20:54:36 +0300
Dmitry Osipenko wrote:
> Introduce kref_put_ww_mutex() helper that will handle the wait-wound
> mutex auto-locking on kref_put(). This helper is wanted by DRM drivers
> that extensively use dma-reservation locking which in turns uses ww-mutex.
>
> Signed-off-by: Dmitry Osipenko
> ---
> include/linux/kref.h | 12
> include/linux/refcount.h | 5 +
> lib/refcount.c | 34 ++
> 3 files changed, 51 insertions(+)
>
> diff --git a/include/linux/kref.h b/include/linux/kref.h
> index d32e21a2538c..b2d8dc6e9ae0 100644
> --- a/include/linux/kref.h
> +++ b/include/linux/kref.h
> @@ -90,6 +90,18 @@ static inline int kref_put_lock(struct kref *kref,
> return 0;
> }
>
> +static inline int kref_put_ww_mutex(struct kref *kref,
> + void (*release)(struct kref *kref),
> + struct ww_mutex *lock,
> + struct ww_acquire_ctx *ctx)
> +{
> + if (refcount_dec_and_ww_mutex_lock(>refcount, lock, ctx)) {
> + release(kref);
> + return 1;
> + }
> + return 0;
> +}
> +
> /**
> * kref_get_unless_zero - Increment refcount for object unless it is zero.
> * @kref: object.
> diff --git a/include/linux/refcount.h b/include/linux/refcount.h
> index a62fcca97486..be9ad272bc77 100644
> --- a/include/linux/refcount.h
> +++ b/include/linux/refcount.h
> @@ -99,6 +99,8 @@
> #include
>
> struct mutex;
> +struct ww_mutex;
> +struct ww_acquire_ctx;
>
> /**
> * typedef refcount_t - variant of atomic_t specialized for reference counts
> @@ -366,4 +368,7 @@ extern __must_check bool refcount_dec_and_lock(refcount_t
> *r, spinlock_t *lock)
> extern __must_check bool refcount_dec_and_lock_irqsave(refcount_t *r,
> spinlock_t *lock,
> unsigned long *flags)
> __cond_acquires(lock);
> +extern __must_check bool refcount_dec_and_ww_mutex_lock(refcount_t *r,
> + struct ww_mutex *lock,
> + struct ww_acquire_ctx
> *ctx) __cond_acquires(>base);
> #endif /* _LINUX_REFCOUNT_H */
> diff --git a/lib/refcount.c b/lib/refcount.c
> index a207a8f22b3c..3f6fd0ceed02 100644
> --- a/lib/refcount.c
> +++ b/lib/refcount.c
> @@ -6,6 +6,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #define REFCOUNT_WARN(str) WARN_ONCE(1, "refcount_t: " str ".\n")
> @@ -184,3 +185,36 @@ bool refcount_dec_and_lock_irqsave(refcount_t *r,
> spinlock_t *lock,
> return true;
> }
> EXPORT_SYMBOL(refcount_dec_and_lock_irqsave);
> +
> +/**
> + * refcount_dec_and_ww_mutex_lock - return holding ww-mutex if able to
> + * decrement refcount to 0
> + * @r: the refcount
> + * @lock: the ww-mutex to be locked
> + * @ctx: wait-wound context
> + *
> + * Similar to atomic_dec_and_lock(), it will WARN on underflow and fail to
> + * decrement when saturated at REFCOUNT_SATURATED.
> + *
> + * Provides release memory ordering, such that prior loads and stores are
> done
> + * before, and provides a control dependency such that free() must come
> after.
> + * See the comment on top.
> + *
> + * Return: true and hold ww-mutex lock if able to decrement refcount to 0,
> + * false otherwise
> + */
> +bool refcount_dec_and_ww_mutex_lock(refcount_t *r, struct ww_mutex *lock,
> + struct ww_acquire_ctx *ctx)
> +{
> + if (refcount_dec_not_one(r))
> + return false;
> +
> + ww_mutex_lock(lock, ctx);
Unless I'm wrong, ww_mutex_lock() can return -EDEADLK when ctx !=
NULL, in which case, the lock is not held when it returns. Question is,
do we really have a use case for ctx != NULL in that kref_put_ww_mutex()
path. If we need to acquire other ww_locks, this lock, and the other
locks should have been acquired beforehand, and we can simply call
kref_put() when we want to release the ref on the resource.
> + if (!refcount_dec_and_test(r)) {
> + ww_mutex_unlock(lock);
> + return false;
> + }
> +
> + return true;
> +}
> +EXPORT_SYMBOL(refcount_dec_and_ww_mutex_lock);
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for HDCP MST aux issue fix (rev6)
== Series Details == Series: HDCP MST aux issue fix (rev6) URL : https://patchwork.freedesktop.org/series/122267/ State : warning == Summary == Error: dim sparse failed /home/kbuild2/linux/maintainer-tools/dim: line 50: /home/kbuild2/.dimrc: No such file or directory
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for HDCP MST aux issue fix (rev6)
== Series Details == Series: HDCP MST aux issue fix (rev6) URL : https://patchwork.freedesktop.org/series/122267/ State : warning == Summary == Error: dim checkpatch failed /home/kbuild2/linux/maintainer-tools/dim: line 50: /home/kbuild2/.dimrc: No such file or directory
[Intel-gfx] ✗ Fi.CI.IGT: failure for fbc on any plane
== Series Details == Series: fbc on any plane URL : https://patchwork.freedesktop.org/series/122958/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13569_full -> Patchwork_122958v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_122958v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_122958v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 10) -- Additional (1): shard-rkl0 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_122958v1_full: ### IGT changes ### Possible regressions * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-dg2: NOTRUN -> [FAIL][1] +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-dg2-12/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt: - shard-snb: NOTRUN -> [FAIL][2] +9 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-snb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-move: - shard-dg2: [PASS][3] -> [FAIL][4] +28 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-dg2-6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-dg2-2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-move.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-msflip-blt: - shard-dg1: [PASS][5] -> [FAIL][6] +45 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-dg1-14/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-msflip-blt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-dg1-15/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-tglu: [PASS][7] -> [FAIL][8] +61 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-tglu-6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-tglu-6/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-rkl: [PASS][9] -> [FAIL][10] +55 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-rkl-7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-rkl-2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-pri-indfb-draw-blt: - shard-glk: [PASS][11] -> [FAIL][12] +117 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-glk6/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-indfb-draw-blt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-glk3/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-pri-indfb-draw-blt.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-mmap-gtt: - shard-snb: [PASS][13] -> [FAIL][14] +48 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-snb4/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-gtt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-snb6/igt@kms_frontbuffer_track...@fbc-rgb565-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-pwrite: - shard-apl: [PASS][15] -> [FAIL][16] +58 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-apl4/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-apl2/igt@kms_frontbuffer_track...@fbc-rgb565-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-shrfb-scaledprimary: - shard-rkl: NOTRUN -> [FAIL][17] +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/shard-rkl-2/igt@kms_frontbuffer_track...@fbc-shrfb-scaledprimary.html Warnings * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-snb: [DMESG-WARN][18] ([i915#8841]) -> [FAIL][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-snb2/igt@kms_frontbuffer_track...@fbc-suspend.html [19]:
Re: [Intel-gfx] [Intel-xe] [PATCH 3/4] drm/i915/lnl: support FBC on any plane
On Mon, 28 Aug 2023, Vinod Govindapillai wrote: > diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h > index aefad14ab27a..b207774f3c33 100644 > --- a/drivers/gpu/drm/i915/i915_reg.h > +++ b/drivers/gpu/drm/i915/i915_reg.h > @@ -1327,6 +1327,10 @@ > #define DPFC_CTL_PLANE_IVB(i9xx_plane) > REG_FIELD_PREP(DPFC_CTL_PLANE_MASK_IVB, (i9xx_plane)) > #define DPFC_CTL_FENCE_EN_IVB REG_BIT(28) /* ivb+ */ > #define DPFC_CTL_PERSISTENT_MODE REG_BIT(25) /* g4x-snb */ > +#define DPFC_CTL_PLANE_BINDING_MASKREG_GENMASK(12, 11) /* > XE */ > +#define DPFC_CTL_PLANE_BINDING_1 > REG_FIELD_PREP(DPFC_CTL_PLANE_BINDING_MASK, 0) /* XE */ > +#define DPFC_CTL_PLANE_BINDING_2 > REG_FIELD_PREP(DPFC_CTL_PLANE_BINDING_MASK, 1) /* XE */ > +#define DPFC_CTL_PLANE_BINDING_3 > REG_FIELD_PREP(DPFC_CTL_PLANE_BINDING_MASK, 2) /* XE */ What's with the /* XE */ comments? BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/mtl: Update workaround 14016712196
== Series Details == Series: drm/i915/mtl: Update workaround 14016712196 URL : https://patchwork.freedesktop.org/series/122959/ State : success == Summary == CI Bug Log - changes from CI_DRM_13570 -> Patchwork_122959v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/index.html Participating hosts (25 -> 37) -- Additional (13): fi-kbl-soraka fi-kbl-7567u bat-adls-5 bat-adlp-9 bat-dg2-13 bat-adlm-1 fi-cfl-guc fi-kbl-x1275 bat-dg2-14 bat-rpls-1 bat-jsl-1 bat-mtlp-8 bat-mtlp-6 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_122959v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-mtlp-8/igt@debugfs_t...@basic-hwmon.html - bat-adlp-9: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-adlp-9/igt@debugfs_t...@basic-hwmon.html - bat-adls-5: NOTRUN -> [SKIP][3] ([i915#7456]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-adls-5/igt@debugfs_t...@basic-hwmon.html - bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#7456]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html - bat-jsl-1: NOTRUN -> [SKIP][5] ([i915#7456]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-jsl-1/igt@debugfs_t...@basic-hwmon.html - bat-rpls-1: NOTRUN -> [SKIP][6] ([i915#7456]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-rpls-1/igt@debugfs_t...@basic-hwmon.html - bat-mtlp-6: NOTRUN -> [SKIP][7] ([i915#7456]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-mtlp-6/igt@debugfs_t...@basic-hwmon.html * igt@debugfs_test@read_all_entries: - fi-kbl-7567u: NOTRUN -> [ABORT][8] ([i915#8913]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/fi-kbl-7567u/igt@debugfs_test@read_all_entries.html * igt@fbdev@eof: - bat-adls-5: NOTRUN -> [SKIP][9] ([i915#2582]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-adls-5/igt@fb...@eof.html - bat-adlm-1: NOTRUN -> [SKIP][10] ([i915#2582]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-adlm-1/igt@fb...@eof.html * igt@fbdev@info: - fi-kbl-x1275: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#1849]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/fi-kbl-x1275/igt@fb...@info.html - bat-rpls-1: NOTRUN -> [SKIP][12] ([i915#1849] / [i915#2582]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-rpls-1/igt@fb...@info.html - bat-adls-5: NOTRUN -> [SKIP][13] ([i915#1849] / [i915#2582]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-adls-5/igt@fb...@info.html - bat-adlm-1: NOTRUN -> [SKIP][14] ([i915#1849] / [i915#2582]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-adlm-1/igt@fb...@info.html - bat-mtlp-6: NOTRUN -> [SKIP][15] ([i915#1849] / [i915#2582]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-mtlp-6/igt@fb...@info.html * igt@fbdev@write: - bat-rpls-1: NOTRUN -> [SKIP][16] ([i915#2582]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-rpls-1/igt@fb...@write.html - bat-mtlp-6: NOTRUN -> [SKIP][17] ([i915#2582]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-mtlp-6/igt@fb...@write.html * igt@gem_huc_copy@huc-copy: - bat-jsl-1: NOTRUN -> [SKIP][18] ([i915#2190]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-jsl-1/igt@gem_huc_c...@huc-copy.html - fi-kbl-x1275: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#2190]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/fi-kbl-x1275/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][20] ([fdo#109271] / [i915#2190]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - bat-adlp-9: NOTRUN -> [SKIP][21] ([i915#4613]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122959v1/bat-adlp-9/igt@gem_lmem_swapp...@basic.html - fi-kbl-soraka: NOTRUN -> [SKIP][22] ([fdo#109271] / [i915#4613]) +3 similar issues [22]:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Update workaround 14016712196
== Series Details == Series: drm/i915/mtl: Update workaround 14016712196 URL : https://patchwork.freedesktop.org/series/122959/ State : warning == Summary == Error: dim sparse failed /home/kbuild2/linux/maintainer-tools/dim: line 50: /home/kbuild2/.dimrc: No such file or directory
[Intel-gfx] [PATCH] drm/i915/psr: Add psr sink error status into sink status debugfs
Normally PSR errors detected by the panel are triggering HPD interrupt and
seen as error in dmesg. Some panels are not triggering the interrupt even
it is requested and they are detecting error. Due to this it would be good
to have possibility to check panel detected errors. Add PSR error status
into PSR sink status debugfs interface.
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 34 +---
1 file changed, 25 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 72887c29fb51..a008918b4d71 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -23,6 +23,7 @@
#include
#include
+#include
#include "i915_drv.h"
#include "i915_reg.h"
@@ -3153,7 +3154,7 @@ static int i915_psr_sink_status_show(struct seq_file *m,
void *data)
};
const char *str;
int ret;
- u8 val;
+ u8 status, error_status;
if (!CAN_PSR(intel_dp)) {
seq_puts(m, "PSR Unsupported\n");
@@ -3163,19 +3164,34 @@ static int i915_psr_sink_status_show(struct seq_file
*m, void *data)
if (connector->base.status != connector_status_connected)
return -ENODEV;
- ret = drm_dp_dpcd_readb(_dp->aux, DP_PSR_STATUS, );
- if (ret != 1)
- return ret < 0 ? ret : -EIO;
+ ret = psr_get_status_and_error_status(intel_dp, , _status);
+ if (ret)
+ return ret;
- val &= DP_PSR_SINK_STATE_MASK;
- if (val < ARRAY_SIZE(sink_status))
- str = sink_status[val];
+ status &= DP_PSR_SINK_STATE_MASK;
+ if (status < ARRAY_SIZE(sink_status))
+ str = sink_status[status];
else
str = "unknown";
- seq_printf(m, "Sink PSR status: 0x%x [%s]\n", val, str);
+ seq_printf(m, "Sink PSR status: 0x%x [%s]\n", status, str);
- return 0;
+ seq_printf(m, "Sink PSR error status: 0x%x", error_status);
+
+ if (error_status & (DP_PSR_RFB_STORAGE_ERROR |
+ DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR |
+ DP_PSR_LINK_CRC_ERROR))
+ seq_puts(m, ":\n");
+ else
+ seq_puts(m, "\n");
+ if (error_status & DP_PSR_RFB_STORAGE_ERROR)
+ seq_puts(m, "\tPSR RFB storage error\n");
+ if (error_status & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
+ seq_puts(m, "\tPSR VSC SDP uncorrectable error\n");
+ if (error_status & DP_PSR_LINK_CRC_ERROR)
+ seq_puts(m, "\tPSR Link CRC error\n");
+
+ return ret;
}
DEFINE_SHOW_ATTRIBUTE(i915_psr_sink_status);
--
2.34.1
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: VRR and M/N stuff
== Series Details == Series: drm/i915: VRR and M/N stuff URL : https://patchwork.freedesktop.org/series/122955/ State : success == Summary == CI Bug Log - changes from CI_DRM_13569_full -> Patchwork_122955v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_122955v1_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_fdinfo@most-busy-check-all@bcs0: - shard-dg2: NOTRUN -> [SKIP][1] ([i915#8414]) +9 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-dg2-1/igt@drm_fdinfo@most-busy-check-...@bcs0.html * igt@drm_fdinfo@most-busy-check-all@rcs0: - shard-rkl: [PASS][2] -> [FAIL][3] ([i915#7742]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html * igt@gem_busy@close-race: - shard-mtlp: [PASS][4] -> [ABORT][5] ([i915#9151]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-mtlp-5/igt@gem_b...@close-race.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-mtlp-2/igt@gem_b...@close-race.html * igt@gem_ccs@suspend-resume@xmajor-compressed-compfmt0-smem-lmem0: - shard-dg2: [PASS][6] -> [INCOMPLETE][7] ([i915#6311] / [i915#7297]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-dg2-11/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-smem-lmem0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-dg2-10/igt@gem_ccs@suspend-res...@xmajor-compressed-compfmt0-smem-lmem0.html * igt@gem_close_race@multigpu-basic-process: - shard-mtlp: NOTRUN -> [SKIP][8] ([i915#7697]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-mtlp-6/igt@gem_close_r...@multigpu-basic-process.html * igt@gem_create@create-ext-set-pat: - shard-rkl: NOTRUN -> [SKIP][9] ([i915#8562]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-rkl-6/igt@gem_cre...@create-ext-set-pat.html * igt@gem_ctx_exec@basic-nohangcheck: - shard-rkl: [PASS][10] -> [FAIL][11] ([i915#6268]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-rkl-7/igt@gem_ctx_e...@basic-nohangcheck.html * igt@gem_ctx_param@set-priority-not-supported: - shard-dg2: NOTRUN -> [SKIP][12] ([fdo#109314]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-dg2-12/igt@gem_ctx_pa...@set-priority-not-supported.html * igt@gem_ctx_persistence@legacy-engines-mixed: - shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#1099]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-snb7/igt@gem_ctx_persiste...@legacy-engines-mixed.html * igt@gem_ctx_sseu@invalid-args: - shard-mtlp: NOTRUN -> [SKIP][14] ([i915#280]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-mtlp-6/igt@gem_ctx_s...@invalid-args.html * igt@gem_eio@hibernate: - shard-tglu: [PASS][15] -> [ABORT][16] ([i915#7975] / [i915#8213] / [i915#8398]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-tglu-2/igt@gem_...@hibernate.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-tglu-10/igt@gem_...@hibernate.html * igt@gem_eio@kms: - shard-dg1: [PASS][17] -> [FAIL][18] ([i915#5784]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-dg1-14/igt@gem_...@kms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-dg1-18/igt@gem_...@kms.html * igt@gem_exec_capture@pi@bcs0: - shard-mtlp: [PASS][19] -> [FAIL][20] ([i915#4475] / [i915#7765]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/shard-mtlp-2/igt@gem_exec_capture@p...@bcs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-mtlp-4/igt@gem_exec_capture@p...@bcs0.html * igt@gem_exec_fair@basic-none: - shard-dg2: NOTRUN -> [SKIP][21] ([i915#3539] / [i915#4852]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-dg2-12/igt@gem_exec_f...@basic-none.html * igt@gem_exec_fair@basic-pace: - shard-dg2: NOTRUN -> [SKIP][22] ([i915#3539]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/shard-dg2-1/igt@gem_exec_f...@basic-pace.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][23] ->
[Intel-gfx] ✓ Fi.CI.BAT: success for fbc on any plane
== Series Details == Series: fbc on any plane URL : https://patchwork.freedesktop.org/series/122958/ State : success == Summary == CI Bug Log - changes from CI_DRM_13569 -> Patchwork_122958v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/index.html Participating hosts (40 -> 37) -- Missing(3): bat-atsm-1 fi-snb-2520m fi-bsw-n3050 Known issues Here are the changes found in Patchwork_122958v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@lmem0: - bat-dg2-9: NOTRUN -> [INCOMPLETE][1] ([i915#6311]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/bat-dg2-9/igt@gem_exec_suspend@basic...@lmem0.html * igt@gem_lmem_swapping@verify-random: - bat-mtlp-8: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html * igt@i915_pm_rps@basic-api: - bat-mtlp-8: NOTRUN -> [SKIP][3] ([i915#6621]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][4] ([i915#6645]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1: - bat-rplp-1: [PASS][5] -> [ABORT][6] ([i915#8442] / [i915#8668]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html * igt@prime_vgem@basic-fence-mmap: - bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#3708] / [i915#4077]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/bat-mtlp-8/igt@prime_v...@basic-fence-mmap.html * igt@prime_vgem@basic-fence-read: - bat-mtlp-8: NOTRUN -> [SKIP][8] ([i915#3708]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/bat-mtlp-8/igt@prime_v...@basic-fence-read.html Possible fixes * igt@gem_exec_suspend@basic-s0@smem: - bat-dg2-9: [INCOMPLETE][9] ([i915#6311]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rpm@basic-pci-d3-state: - bat-mtlp-8: [ABORT][11] ([i915#7077] / [i915#7977] / [i915#8668]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708 [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311 [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621 [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645 [i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077 [i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977 [i915#8442]: https://gitlab.freedesktop.org/drm/intel/issues/8442 [i915#8668]: https://gitlab.freedesktop.org/drm/intel/issues/8668 Build changes - * Linux: CI_DRM_13569 -> Patchwork_122958v1 CI-20190529: 20190529 CI_DRM_13569: eb0ba85982a1832f4a61954c3fb99ac3e3f2e076 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7454: 7454 Patchwork_122958v1: eb0ba85982a1832f4a61954c3fb99ac3e3f2e076 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 2448614b9c2e drm/i915/lnl: FBC is supported with per pixel alpha 00e4f6841570 drm/i915/lnl: support FBC on any plane 5152f3342aad drm/i915/lnl: update FBC debugfs to include plane information de17d676ce6c drm/i915/lnl: FBC can be enabled with PSR2 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122958v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fbc on any plane
== Series Details == Series: fbc on any plane URL : https://patchwork.freedesktop.org/series/122958/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for fbc on any plane
== Series Details == Series: fbc on any plane URL : https://patchwork.freedesktop.org/series/122958/ State : warning == Summary == Error: dim checkpatch failed /home/kbuild2/linux/maintainer-tools/dim: line 50: /home/kbuild2/.dimrc: No such file or directory
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add DSC PPS readout (rev12)
== Series Details == Series: Add DSC PPS readout (rev12) URL : https://patchwork.freedesktop.org/series/120456/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13569 -> Patchwork_120456v12 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_120456v12 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_120456v12, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/index.html Participating hosts (40 -> 36) -- Missing(4): bat-rpls-2 bat-atsm-1 fi-snb-2520m fi-bsw-n3050 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_120456v12: ### IGT changes ### Possible regressions * igt@dmabuf@all-tests@sanitycheck: - bat-kbl-2: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-kbl-2/igt@dmabuf@all-te...@sanitycheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/bat-kbl-2/igt@dmabuf@all-te...@sanitycheck.html Known issues Here are the changes found in Patchwork_120456v12 that come from known issues: ### IGT changes ### Issues hit * igt@dmabuf@all-tests@dma_fence: - bat-kbl-2: [PASS][3] -> [DMESG-FAIL][4] ([i915#8189]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-kbl-2/igt@dmabuf@all-tests@dma_fence.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/bat-kbl-2/igt@dmabuf@all-tests@dma_fence.html * igt@gem_lmem_swapping@verify-random: - bat-mtlp-8: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.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_120456v12/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][7] -> [DMESG-FAIL][8] ([i915#5334] / [i915#7872]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html - fi-apl-guc: [PASS][9] -> [DMESG-FAIL][10] ([i915#5334]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#6645]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence@pipe-d-edp-1: - bat-rplp-1: [PASS][12] -> [ABORT][13] ([i915#8442] / [i915#8668]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/bat-rplp-1/igt@kms_pipe_crc_basic@read-crc-frame-seque...@pipe-d-edp-1.html * igt@prime_vgem@basic-fence-mmap: - bat-mtlp-8: NOTRUN -> [SKIP][14] ([i915#3708] / [i915#4077]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/bat-mtlp-8/igt@prime_v...@basic-fence-mmap.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_120456v12/bat-mtlp-8/igt@prime_v...@basic-fence-read.html Possible fixes * igt@gem_exec_suspend@basic-s0@smem: - bat-dg2-9: [INCOMPLETE][16] ([i915#6311]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rpm@basic-pci-d3-state: - bat-mtlp-8: [ABORT][18] ([i915#7077] / [i915#7977] / [i915#8668]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_120456v12/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708 [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add DSC PPS readout (rev12)
== Series Details == Series: Add DSC PPS readout (rev12) URL : https://patchwork.freedesktop.org/series/120456/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +drivers/gpu/drm/i915/display/intel_display_types.h:1884:17: warning: unreplaced symbol 'encoder' +drivers/gpu/drm/i915/display/intel_display_types.h:1884:9: warning:
[Intel-gfx] [PATCH v4 2/4] drm/i915/hdcp: Propagate aux info in DP HDCP functions
We were propagating dig_port info to dp hdcp2 specific functions.
Let us clean that up and send intel_connector in the following
functions: intel_dp_hdcp2_wait_for_msg, get_receiver_id_list_rx_info,
intel_dp_hdcp2_read_rx_status.
This optimises mst scenarios where aux ends up being remote and not
stored in dig_port and dig_port can always be derived from
intel_connector if needed.
--v2
-Fix Typo [Arun]
-Dont pass drm_dp core structures [Arun]
-Fix commit message styling [Arun]
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 +++-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 6cd42363837a..59ef77476cb9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -331,10 +331,11 @@ static const struct hdcp2_dp_msg_data hdcp2_dp_msg_data[]
= {
};
static int
-intel_dp_hdcp2_read_rx_status(struct intel_digital_port *dig_port,
+intel_dp_hdcp2_read_rx_status(struct intel_connector *connector,
u8 *rx_status)
{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
ssize_t ret;
ret = drm_dp_dpcd_read(_port->dp.aux,
@@ -350,14 +351,14 @@ intel_dp_hdcp2_read_rx_status(struct intel_digital_port
*dig_port,
}
static
-int hdcp2_detect_msg_availability(struct intel_digital_port *dig_port,
+int hdcp2_detect_msg_availability(struct intel_connector *connector,
u8 msg_id, bool *msg_ready)
{
u8 rx_status;
int ret;
*msg_ready = false;
- ret = intel_dp_hdcp2_read_rx_status(dig_port, _status);
+ ret = intel_dp_hdcp2_read_rx_status(connector, _status);
if (ret < 0)
return ret;
@@ -383,12 +384,11 @@ int hdcp2_detect_msg_availability(struct
intel_digital_port *dig_port,
}
static ssize_t
-intel_dp_hdcp2_wait_for_msg(struct intel_digital_port *dig_port,
+intel_dp_hdcp2_wait_for_msg(struct intel_connector *connector,
const struct hdcp2_dp_msg_data *hdcp2_msg_data)
{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_dp *dp = _port->dp;
- struct intel_hdcp *hdcp = >attached_connector->hdcp;
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
u8 msg_id = hdcp2_msg_data->msg_id;
int ret, timeout;
bool msg_ready = false;
@@ -411,8 +411,8 @@ intel_dp_hdcp2_wait_for_msg(struct intel_digital_port
*dig_port,
* the timeout at wait for CP_IRQ.
*/
intel_dp_hdcp_wait_for_cp_irq(hdcp, timeout);
- ret = hdcp2_detect_msg_availability(dig_port,
- msg_id, _ready);
+ ret = hdcp2_detect_msg_availability(connector, msg_id,
+ _ready);
if (!msg_ready)
ret = -ETIMEDOUT;
}
@@ -445,6 +445,7 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
const struct hdcp2_dp_msg_data *hdcp2_msg_data;
+ struct drm_dp_aux *aux;
hdcp2_msg_data = get_hdcp2_dp_msg_data(*byte);
if (!hdcp2_msg_data)
@@ -452,6 +453,8 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
offset = hdcp2_msg_data->offset;
+ aux = _port->dp.aux;
+
/* No msg_id in DP HDCP2.2 msgs */
bytes_to_write = size - 1;
byte++;
@@ -460,7 +463,7 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_write;
- ret = drm_dp_dpcd_write(_port->dp.aux,
+ ret = drm_dp_dpcd_write(aux,
offset, (void *)byte, len);
if (ret < 0)
return ret;
@@ -474,8 +477,10 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
}
static
-ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
+ssize_t get_receiver_id_list_rx_info(struct intel_connector *connector,
+u32 *dev_cnt, u8 *byte)
{
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
ssize_t ret;
u8 *rx_info = byte;
@@ -500,8 +505,7 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
{
struct intel_digital_port *dig_port =
[Intel-gfx] [PATCH v3 2/4] drm/i915/hdcp: Propagate aux info in DP HDCP functions
We were propagating dig_port info to dp hdcp2 specific functions.
Let us clean that up and send intel_connector in the following
functions: intel_dp_hdcp2_wait_for_msg, get_receiver_id_list_rx_info,
intel_dp_hdcp2_read_rx_status.
This optimises mst scenarios where aux ends up being remote and not
stored in dig_port and dig_port can always be derived from
intel_connector if needed.
--v2
-Fix Typo [Arun]
-Dont pass drm_dp core structures [Arun]
-Fix commit message styling [Arun]
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 39 +++-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 6cd42363837a..59ef77476cb9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -331,10 +331,11 @@ static const struct hdcp2_dp_msg_data hdcp2_dp_msg_data[]
= {
};
static int
-intel_dp_hdcp2_read_rx_status(struct intel_digital_port *dig_port,
+intel_dp_hdcp2_read_rx_status(struct intel_connector *connector,
u8 *rx_status)
{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
ssize_t ret;
ret = drm_dp_dpcd_read(_port->dp.aux,
@@ -350,14 +351,14 @@ intel_dp_hdcp2_read_rx_status(struct intel_digital_port
*dig_port,
}
static
-int hdcp2_detect_msg_availability(struct intel_digital_port *dig_port,
+int hdcp2_detect_msg_availability(struct intel_connector *connector,
u8 msg_id, bool *msg_ready)
{
u8 rx_status;
int ret;
*msg_ready = false;
- ret = intel_dp_hdcp2_read_rx_status(dig_port, _status);
+ ret = intel_dp_hdcp2_read_rx_status(connector, _status);
if (ret < 0)
return ret;
@@ -383,12 +384,11 @@ int hdcp2_detect_msg_availability(struct
intel_digital_port *dig_port,
}
static ssize_t
-intel_dp_hdcp2_wait_for_msg(struct intel_digital_port *dig_port,
+intel_dp_hdcp2_wait_for_msg(struct intel_connector *connector,
const struct hdcp2_dp_msg_data *hdcp2_msg_data)
{
- struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
- struct intel_dp *dp = _port->dp;
- struct intel_hdcp *hdcp = >attached_connector->hdcp;
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
+ struct intel_hdcp *hdcp = >hdcp;
u8 msg_id = hdcp2_msg_data->msg_id;
int ret, timeout;
bool msg_ready = false;
@@ -411,8 +411,8 @@ intel_dp_hdcp2_wait_for_msg(struct intel_digital_port
*dig_port,
* the timeout at wait for CP_IRQ.
*/
intel_dp_hdcp_wait_for_cp_irq(hdcp, timeout);
- ret = hdcp2_detect_msg_availability(dig_port,
- msg_id, _ready);
+ ret = hdcp2_detect_msg_availability(connector, msg_id,
+ _ready);
if (!msg_ready)
ret = -ETIMEDOUT;
}
@@ -445,6 +445,7 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
const struct hdcp2_dp_msg_data *hdcp2_msg_data;
+ struct drm_dp_aux *aux;
hdcp2_msg_data = get_hdcp2_dp_msg_data(*byte);
if (!hdcp2_msg_data)
@@ -452,6 +453,8 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
offset = hdcp2_msg_data->offset;
+ aux = _port->dp.aux;
+
/* No msg_id in DP HDCP2.2 msgs */
bytes_to_write = size - 1;
byte++;
@@ -460,7 +463,7 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
len = bytes_to_write > DP_AUX_MAX_PAYLOAD_BYTES ?
DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_write;
- ret = drm_dp_dpcd_write(_port->dp.aux,
+ ret = drm_dp_dpcd_write(aux,
offset, (void *)byte, len);
if (ret < 0)
return ret;
@@ -474,8 +477,10 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
}
static
-ssize_t get_receiver_id_list_rx_info(struct intel_digital_port *dig_port, u32
*dev_cnt, u8 *byte)
+ssize_t get_receiver_id_list_rx_info(struct intel_connector *connector,
+u32 *dev_cnt, u8 *byte)
{
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
ssize_t ret;
u8 *rx_info = byte;
@@ -500,8 +505,7 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
{
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
[Intel-gfx] [PATCH v3 4/4] drm/i915/hdcp: Adjust timeout for read in DPMST Scenario
For dpmst hdcp scenario increase the message timeout based
on the number of ports connected as each port needs to be
validated and each will take the prescribed amount of time
for the respective msg_id and total timeout will be
original_timeout * num_ports.
--v2
-Add justification for Adjusting the timeout [Arun]
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index df68fd8f2eed..b0cfe759d3e5 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -560,9 +560,15 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
DP_AUX_MAX_PAYLOAD_BYTES : bytes_to_recv;
/* Entire msg read timeout since initiate of msg read */
- if (bytes_to_recv == size - 1 &&
hdcp2_msg_data->msg_read_timeout > 0)
- msg_end = ktime_add_ms(ktime_get_raw(),
-
hdcp2_msg_data->msg_read_timeout);
+ if (bytes_to_recv == size - 1 &&
hdcp2_msg_data->msg_read_timeout > 0) {
+ if (intel_encoder_is_mst(connector->encoder))
+ msg_end = ktime_add_ms(ktime_get_raw(),
+
hdcp2_msg_data->msg_read_timeout *
+
connector->port->parent->num_ports);
+ else
+ msg_end = ktime_add_ms(ktime_get_raw(),
+
hdcp2_msg_data->msg_read_timeout);
+ }
ret = drm_dp_dpcd_read(aux, offset,
(void *)byte, len);
--
2.25.1
[Intel-gfx] [PATCH v3 3/4] drm/i915/hdcp: Send the correct aux for DPMST HDCP scenario
Up until now we were sending the base aux stored in dig_port which
is not correct as this causes an issue when monitor is connected via
a DPMST hub causing it to be remote hence we end up seeing AUX
failures so let's send the remote aux in case of DPMST.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 27 +++-
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index 59ef77476cb9..df68fd8f2eed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -330,15 +330,26 @@ static const struct hdcp2_dp_msg_data hdcp2_dp_msg_data[]
= {
0, 0 },
};
+static struct drm_dp_aux *
+intel_dp_hdcp_get_aux(struct intel_connector *connector)
+{
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+
+ if (intel_encoder_is_mst(connector->encoder))
+ return >port->aux;
+ else
+ return _port->dp.aux;
+}
+
static int
intel_dp_hdcp2_read_rx_status(struct intel_connector *connector,
u8 *rx_status)
{
struct drm_i915_private *i915 = to_i915(connector->base.dev);
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = intel_dp_hdcp_get_aux(connector);
ssize_t ret;
- ret = drm_dp_dpcd_read(_port->dp.aux,
+ ret = drm_dp_dpcd_read(aux,
DP_HDCP_2_2_REG_RXSTATUS_OFFSET, rx_status,
HDCP_2_2_DP_RXSTATUS_LEN);
if (ret != HDCP_2_2_DP_RXSTATUS_LEN) {
@@ -440,7 +451,6 @@ static
int intel_dp_hdcp2_write_msg(struct intel_connector *connector,
void *buf, size_t size)
{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
@@ -453,7 +463,7 @@ int intel_dp_hdcp2_write_msg(struct intel_connector
*connector,
offset = hdcp2_msg_data->offset;
- aux = _port->dp.aux;
+ aux = intel_dp_hdcp_get_aux(connector);
/* No msg_id in DP HDCP2.2 msgs */
bytes_to_write = size - 1;
@@ -480,11 +490,11 @@ static
ssize_t get_receiver_id_list_rx_info(struct intel_connector *connector,
u32 *dev_cnt, u8 *byte)
{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
+ struct drm_dp_aux *aux = intel_dp_hdcp_get_aux(connector);
ssize_t ret;
u8 *rx_info = byte;
- ret = drm_dp_dpcd_read(_port->dp.aux,
+ ret = drm_dp_dpcd_read(aux,
DP_HDCP_2_2_REG_RXINFO_OFFSET,
(void *)rx_info, HDCP_2_2_RXINFO_LEN);
if (ret != HDCP_2_2_RXINFO_LEN)
@@ -506,6 +516,7 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_hdcp *hdcp = >hdcp;
+ struct drm_dp_aux *aux;
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_recv, len;
@@ -519,6 +530,8 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
return -EINVAL;
offset = hdcp2_msg_data->offset;
+ aux = intel_dp_hdcp_get_aux(connector);
+
ret = intel_dp_hdcp2_wait_for_msg(connector, hdcp2_msg_data);
if (ret < 0)
return ret;
@@ -551,7 +564,7 @@ int intel_dp_hdcp2_read_msg(struct intel_connector
*connector,
msg_end = ktime_add_ms(ktime_get_raw(),
hdcp2_msg_data->msg_read_timeout);
- ret = drm_dp_dpcd_read(_port->dp.aux, offset,
+ ret = drm_dp_dpcd_read(aux, offset,
(void *)byte, len);
if (ret < 0) {
drm_dbg_kms(>drm, "msg_id %d, ret %zd\n",
--
2.25.1
[Intel-gfx] [PATCH v3 1/4] drm/i915/hdcp: Use intel_connector argument in intel_hdcp_shim
Update intel_hdcp_shim funcs specifically read_2_2_message,
write_2_2_message and config_stream_type to use intel_connector
argument instead of intel_digital_port as this will help in getting
correct aux later for dp mst scenarios also already hdcp funcs
derive digital_port from connector and then many funcs again get back
the connector from dig_port which doesn't seem right.
Connector specific hdcp functions can derive dig_port on need basis.
Signed-off-by: Suraj Kandpal
Reviewed-by: Arun R Murthy
---
.../drm/i915/display/intel_display_types.h| 6 ++--
drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 10 ---
drivers/gpu/drm/i915/display/intel_hdcp.c | 30 ---
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 ++--
4 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 731f2ec04d5c..c62f4ec315e8 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -504,11 +504,11 @@ struct intel_hdcp_shim {
bool *capable);
/* Write HDCP2.2 messages */
- int (*write_2_2_msg)(struct intel_digital_port *dig_port,
+ int (*write_2_2_msg)(struct intel_connector *connector,
void *buf, size_t size);
/* Read HDCP2.2 messages */
- int (*read_2_2_msg)(struct intel_digital_port *dig_port,
+ int (*read_2_2_msg)(struct intel_connector *connector,
u8 msg_id, void *buf, size_t size);
/*
@@ -516,7 +516,7 @@ struct intel_hdcp_shim {
* type to Receivers. In DP HDCP2.2 Stream type is one of the input to
* the HDCP2.2 Cipher for En/De-Cryption. Not applicable for HDMI.
*/
- int (*config_stream_type)(struct intel_digital_port *dig_port,
+ int (*config_stream_type)(struct intel_connector *connector,
bool is_repeater, u8 type);
/* Enable/Disable HDCP 2.2 stream encryption on DP MST Transport Link */
diff --git a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
index e0c177161407..6cd42363837a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_hdcp.c
@@ -437,9 +437,10 @@ static const struct hdcp2_dp_msg_data
*get_hdcp2_dp_msg_data(u8 msg_id)
}
static
-int intel_dp_hdcp2_write_msg(struct intel_digital_port *dig_port,
+int intel_dp_hdcp2_write_msg(struct intel_connector *connector,
void *buf, size_t size)
{
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
unsigned int offset;
u8 *byte = buf;
ssize_t ret, bytes_to_write, len;
@@ -494,9 +495,10 @@ ssize_t get_receiver_id_list_rx_info(struct
intel_digital_port *dig_port, u32 *d
}
static
-int intel_dp_hdcp2_read_msg(struct intel_digital_port *dig_port,
+int intel_dp_hdcp2_read_msg(struct intel_connector *connector,
u8 msg_id, void *buf, size_t size)
{
+ struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
struct intel_dp *dp = _port->dp;
struct intel_hdcp *hdcp = >attached_connector->hdcp;
@@ -574,7 +576,7 @@ int intel_dp_hdcp2_read_msg(struct intel_digital_port
*dig_port,
}
static
-int intel_dp_hdcp2_config_stream_type(struct intel_digital_port *dig_port,
+int intel_dp_hdcp2_config_stream_type(struct intel_connector *connector,
bool is_repeater, u8 content_type)
{
int ret;
@@ -593,7 +595,7 @@ int intel_dp_hdcp2_config_stream_type(struct
intel_digital_port *dig_port,
stream_type_msg.msg_id = HDCP_2_2_ERRATA_DP_STREAM_TYPE;
stream_type_msg.stream_type = content_type;
- ret = intel_dp_hdcp2_write_msg(dig_port, _type_msg,
+ ret = intel_dp_hdcp2_write_msg(connector, _type_msg,
sizeof(stream_type_msg));
return ret < 0 ? ret : 0;
diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c
b/drivers/gpu/drm/i915/display/intel_hdcp.c
index a42549fa9691..cb45f21f71eb 100644
--- a/drivers/gpu/drm/i915/display/intel_hdcp.c
+++ b/drivers/gpu/drm/i915/display/intel_hdcp.c
@@ -1415,7 +1415,6 @@ static int hdcp2_deauthenticate_port(struct
intel_connector *connector)
/* Authentication flow starts from here */
static int hdcp2_authentication_key_exchange(struct intel_connector *connector)
{
- struct intel_digital_port *dig_port =
intel_attached_dig_port(connector);
struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_hdcp *hdcp = >hdcp;
union {
@@ -1437,12 +1436,12 @@ static int hdcp2_authentication_key_exchange(struct
intel_connector *connector)
if
[Intel-gfx] [PATCH v3 0/4] HDCP MST aux issue fix
Up until now all dp hdcp specific function derived the aux from dig_port which gave the aux of the primary port but with DPMST when a MST hub comes into picture the monitor becomes remote and what we need is a corresponding aux which is also remote. These set of patches aim to fix up just that. --v2 -Do not pass drm_core struct to i915 function [Arun] -Fix typo and correct commit message in 3rd patch [Arun] -Provide justification for timeout adjustment [Arun] Signed-off-by: Suraj Kandpal Suraj Kandpal (4): drm/i915/hdcp: Use intel_connector argument in intel_hdcp_shim drm/i915/hdcp: Propagate aux info in DP HDCP functions drm/i915/hdcp: Send the correct aux for DPMST HDCP scenario drm/i915/hdcp: Adjust timeout for read in DPMST Scenario .../drm/i915/display/intel_display_types.h| 6 +- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 80 --- drivers/gpu/drm/i915/display/intel_hdcp.c | 30 +++ drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +- 4 files changed, 73 insertions(+), 49 deletions(-) -- 2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: VRR and M/N stuff
== Series Details == Series: drm/i915: VRR and M/N stuff URL : https://patchwork.freedesktop.org/series/122955/ State : success == Summary == CI Bug Log - changes from CI_DRM_13569 -> Patchwork_122955v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/index.html Participating hosts (40 -> 37) -- Missing(3): bat-atsm-1 fi-snb-2520m fi-bsw-n3050 Known issues Here are the changes found in Patchwork_122955v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_lmem_swapping@verify-random: - bat-mtlp-8: NOTRUN -> [SKIP][1] ([i915#4613]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-mtlp-8/igt@gem_lmem_swapp...@verify-random.html * igt@i915_pm_rps@basic-api: - bat-mtlp-8: NOTRUN -> [SKIP][2] ([i915#6621]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-mtlp-8/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@mman: - bat-rpls-1: [PASS][3] -> [TIMEOUT][4] ([i915#6794] / [i915#7392]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-rpls-1/igt@i915_selftest@l...@mman.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-rpls-1/igt@i915_selftest@l...@mman.html * igt@i915_suspend@basic-s2idle-without-i915: - bat-rpls-1: [PASS][5] -> [WARN][6] ([i915#8747]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - bat-mtlp-8: NOTRUN -> [SKIP][7] ([i915#6645]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-mtlp-8/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_psr@primary_mmap_gtt: - bat-rplp-1: NOTRUN -> [SKIP][8] ([i915#1072]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-rplp-1/igt@kms_psr@primary_mmap_gtt.html * igt@kms_setmode@basic-clone-single-crtc: - bat-rplp-1: NOTRUN -> [ABORT][9] ([i915#8260] / [i915#8668]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-rplp-1/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-mmap: - bat-mtlp-8: NOTRUN -> [SKIP][10] ([i915#3708] / [i915#4077]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-mtlp-8/igt@prime_v...@basic-fence-mmap.html * igt@prime_vgem@basic-fence-read: - bat-mtlp-8: NOTRUN -> [SKIP][11] ([i915#3708]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-mtlp-8/igt@prime_v...@basic-fence-read.html Possible fixes * igt@gem_exec_suspend@basic-s0@smem: - bat-dg2-9: [INCOMPLETE][12] ([i915#6311]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-dg2-9/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rpm@basic-pci-d3-state: - bat-mtlp-8: [ABORT][14] ([i915#7077] / [i915#7977] / [i915#8668]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-mtlp-8/igt@i915_pm_...@basic-pci-d3-state.html Warnings * igt@kms_psr@primary_page_flip: - bat-rplp-1: [ABORT][16] ([i915#8860]) -> [SKIP][17] ([i915#1072]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13569/bat-rplp-1/igt@kms_psr@primary_page_flip.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_122955v1/bat-rplp-1/igt@kms_psr@primary_page_flip.html [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708 [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#6311]: https://gitlab.freedesktop.org/drm/intel/issues/6311 [i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621 [i915#6645]: https://gitlab.freedesktop.org/drm/intel/issues/6645 [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794 [i915#7077]: https://gitlab.freedesktop.org/drm/intel/issues/7077 [i915#7392]: https://gitlab.freedesktop.org/drm/intel/issues/7392 [i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977 [i915#8260]: https://gitlab.freedesktop.org/drm/intel/issues/8260 [i915#8668]:
[Intel-gfx] [PATCH] drm/i915/mtl: Update workaround 14016712196
Now this workaround is permanent workaround on MTL and DG2,
earlier we used to apply on MTL A0 step only.
VLK-45480
Fixes: d922b80b1010 ("drm/i915/gt: Add workaround 14016712196")
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 6187b25b67ab..0143445dba83 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -226,8 +226,8 @@ u32 *gen12_emit_aux_table_inv(struct intel_engine_cs
*engine, u32 *cs)
static int mtl_dummy_pipe_control(struct i915_request *rq)
{
/* Wa_14016712196 */
- if (IS_GFX_GT_IP_STEP(rq->engine->gt, IP_VER(12, 70), STEP_A0, STEP_B0)
||
- IS_GFX_GT_IP_STEP(rq->engine->gt, IP_VER(12, 71), STEP_A0,
STEP_B0)) {
+ if (IS_GFX_GT_IP_RANGE(rq->engine->gt, IP_VER(12, 70), IP_VER(12, 71))
||
+ IS_DG2(rq->i915)) {
u32 *cs;
/* dummy PIPE_CONTROL + depth flush */
@@ -810,8 +810,7 @@ u32 *gen12_emit_fini_breadcrumb_rcs(struct i915_request
*rq, u32 *cs)
PIPE_CONTROL_FLUSH_ENABLE);
/* Wa_14016712196 */
- if (IS_GFX_GT_IP_STEP(gt, IP_VER(12, 70), STEP_A0, STEP_B0) ||
- IS_GFX_GT_IP_STEP(gt, IP_VER(12, 71), STEP_A0, STEP_B0))
+ if (IS_GFX_GT_IP_RANGE(gt, IP_VER(12, 70), IP_VER(12, 71)) ||
IS_DG2(i915))
/* dummy PIPE_CONTROL + depth flush */
cs = gen12_emit_pipe_control(cs, 0,
PIPE_CONTROL_DEPTH_CACHE_FLUSH, 0);
--
2.25.1
[Intel-gfx] [PATCH 4/4] drm/i915/lnl: FBC is supported with per pixel alpha
For LNL onwards, FBC can be supported on planes with per
pixel alpha
Bspec: 69560
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_fbc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 62f59630d410..f36eb8652d3c 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1224,7 +1224,8 @@ static int intel_fbc_check_plane(struct
intel_atomic_state *state,
return 0;
}
- if (plane_state->hw.pixel_blend_mode != DRM_MODE_BLEND_PIXEL_NONE &&
+ if (DISPLAY_VER(i915) < 20 &&
+ plane_state->hw.pixel_blend_mode != DRM_MODE_BLEND_PIXEL_NONE &&
fb->format->has_alpha) {
plane_state->no_fbc_reason = "per-pixel alpha not supported";
return 0;
--
2.34.1
[Intel-gfx] [PATCH 3/4] drm/i915/lnl: support FBC on any plane
In LNL onwards, FBC can be associated to the first three planes.
The FBC will be enabled for first FBC capable visible plane
until the userspace can select one of these FBC capable plane
explicitly
Bspec: 69560
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_fbc.c | 29 +++
.../drm/i915/display/skl_universal_plane.c| 5 +++-
drivers/gpu/drm/i915/i915_reg.h | 4 +++
3 files changed, 37 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 45e205a0f740..62f59630d410 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -649,6 +649,21 @@ static void skl_fbc_program_cfb_stride(struct intel_fbc
*fbc)
CHICKEN_FBC_STRIDE_MASK, val);
}
+static u32 lnl_plane_binding(struct intel_fbc *fbc)
+{
+ switch (fbc->state.plane->id) {
+ default:
+ MISSING_CASE(fbc->state.plane->id);
+ fallthrough;
+ case 0:
+ return DPFC_CTL_PLANE_BINDING_1;
+ case 1:
+ return DPFC_CTL_PLANE_BINDING_2;
+ case 2:
+ return DPFC_CTL_PLANE_BINDING_3;
+ }
+}
+
static u32 ivb_dpfc_ctl(struct intel_fbc *fbc)
{
const struct intel_fbc_state *fbc_state = >state;
@@ -660,6 +675,9 @@ static u32 ivb_dpfc_ctl(struct intel_fbc *fbc)
if (IS_IVYBRIDGE(i915))
dpfc_ctl |= DPFC_CTL_PLANE_IVB(fbc_state->plane->i9xx_plane);
+ if (DISPLAY_VER(i915) >= 20)
+ dpfc_ctl |= lnl_plane_binding(fbc);
+
if (fbc_state->fence_id >= 0)
dpfc_ctl |= DPFC_CTL_FENCE_EN_IVB;
@@ -1250,6 +1268,17 @@ static int intel_fbc_check_plane(struct
intel_atomic_state *state,
}
}
+ /*
+* From LNL, FBC can be assigned on any plane. Until a provision is
+* provided for the userspace to select a plane for FBC, lets select
+* the first visible plane that is FBC capable.
+*/
+ if (DISPLAY_VER(i915) >= 20 && fbc->state.plane &&
+ fbc->state.plane != plane) {
+ plane_state->no_fbc_reason = "fbc enabled on another plane";
+ return 0;
+ }
+
plane_state->no_fbc_reason = NULL;
return 0;
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 4d01c7ae4485..1291351c9941 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1962,7 +1962,10 @@ static bool skl_plane_has_fbc(struct drm_i915_private
*dev_priv,
if ((DISPLAY_RUNTIME_INFO(dev_priv)->fbc_mask & BIT(fbc_id)) == 0)
return false;
- return plane_id == PLANE_PRIMARY;
+ if (DISPLAY_VER(dev_priv) >= 20)
+ return plane_id <= PLANE_SPRITE1;
+ else
+ return plane_id == PLANE_PRIMARY;
}
static struct intel_fbc *skl_plane_fbc(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index aefad14ab27a..b207774f3c33 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1327,6 +1327,10 @@
#define DPFC_CTL_PLANE_IVB(i9xx_plane)
REG_FIELD_PREP(DPFC_CTL_PLANE_MASK_IVB, (i9xx_plane))
#define DPFC_CTL_FENCE_EN_IVBREG_BIT(28) /* ivb+ */
#define DPFC_CTL_PERSISTENT_MODE REG_BIT(25) /* g4x-snb */
+#define DPFC_CTL_PLANE_BINDING_MASK REG_GENMASK(12, 11) /* XE */
+#define DPFC_CTL_PLANE_BINDING_1
REG_FIELD_PREP(DPFC_CTL_PLANE_BINDING_MASK, 0) /* XE */
+#define DPFC_CTL_PLANE_BINDING_2
REG_FIELD_PREP(DPFC_CTL_PLANE_BINDING_MASK, 1) /* XE */
+#define DPFC_CTL_PLANE_BINDING_3
REG_FIELD_PREP(DPFC_CTL_PLANE_BINDING_MASK, 2) /* XE */
#define DPFC_CTL_FALSE_COLOR REG_BIT(10) /* ivb+ */
#define DPFC_CTL_SR_EN REG_BIT(10) /* g4x only */
#define DPFC_CTL_SR_EXIT_DIS REG_BIT(9) /* g4x only */
--
2.34.1
[Intel-gfx] [PATCH 2/4] drm/i915/lnl: update FBC debugfs to include plane information
In future platforms, FBC can be supported on planes other than
the primary plane. So update the debugfs entry for FBC status
to have the plane ID included.
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_fbc.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index d36499d7e0be..45e205a0f740 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1837,7 +1837,9 @@ static int intel_fbc_debugfs_status_show(struct seq_file
*m, void *unused)
mutex_lock(>lock);
if (fbc->active) {
- seq_puts(m, "FBC enabled\n");
+ seq_printf(m, "FBC enabled: [PLANE:%d:%s]\n",
+ fbc->state.plane->base.base.id,
+ fbc->state.plane->base.name);
seq_printf(m, "Compressing: %s\n",
str_yes_no(intel_fbc_is_compressing(fbc)));
} else {
@@ -1910,10 +1912,16 @@ static void intel_fbc_debugfs_add(struct intel_fbc *fbc,
void intel_fbc_crtc_debugfs_add(struct intel_crtc *crtc)
{
- struct intel_plane *plane = to_intel_plane(crtc->base.primary);
+ struct drm_i915_private *i915 = to_i915(crtc->base.dev);
+ struct intel_plane *plane;
+
+ for_each_intel_plane(>drm, plane) {
+ if (!plane->fbc || plane->pipe != crtc->pipe)
+ continue;
- if (plane->fbc)
intel_fbc_debugfs_add(plane->fbc, crtc->base.debugfs_entry);
+ break;
+ }
}
/* FIXME: remove this once igt is on board with per-crtc stuff */
--
2.34.1
[Intel-gfx] [PATCH 1/4] drm/i915/lnl: FBC can be enabled with PSR2
FBC restriction with PSR2 can be removed from LNL onwards
Signed-off-by: Vinod Govindapillai
---
drivers/gpu/drm/i915/display/intel_fbc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 66c8aed07bbc..d36499d7e0be 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1169,11 +1169,11 @@ static int intel_fbc_check_plane(struct
intel_atomic_state *state,
}
/*
-* Display 12+ is not supporting FBC with PSR2.
+* Display 12 to 14 is not supporting FBC with PSR2.
* Recommendation is to keep this combination disabled
* Bspec: 50422 HSD: 14010260002
*/
- if (DISPLAY_VER(i915) >= 12 && crtc_state->has_psr2) {
+ if (IS_DISPLAY_VER(i915, 12, 14) && crtc_state->has_psr2) {
plane_state->no_fbc_reason = "PSR2 enabled";
return 0;
}
--
2.34.1
[Intel-gfx] [PATCH 0/4] fbc on any plane
In LNL, FBC can be supported in planes other than the primary planes. Vinod Govindapillai (4): drm/i915/lnl: FBC can be enabled with PSR2 drm/i915/lnl: update FBC debugfs to include plane information drm/i915/lnl: support FBC on any plane drm/i915/lnl: FBC is supported with per pixel alpha drivers/gpu/drm/i915/display/intel_fbc.c | 50 --- .../drm/i915/display/skl_universal_plane.c| 5 +- drivers/gpu/drm/i915/i915_reg.h | 4 ++ 3 files changed, 52 insertions(+), 7 deletions(-) -- 2.34.1
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: VRR and M/N stuff
== Series Details == Series: drm/i915: VRR and M/N stuff URL : https://patchwork.freedesktop.org/series/122955/ State : warning == Summary == Error: dim sparse failed /home/kbuild2/linux/maintainer-tools/dim: line 50: /home/kbuild2/.dimrc: No such file or directory
