[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix build failure with debug and extra logging enabled
== Series Details == Series: drm/i915: Fix build failure with debug and extra logging enabled URL : https://patchwork.freedesktop.org/series/110930/ State : success == Summary == CI Bug Log - changes from CI_DRM_12382_full -> Patchwork_110930v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (11 -> 11) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_110930v1_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-hang: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-hang.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][2] ([i915#3354]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-snb6/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/igt@gem_exec_f...@basic-deadline.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-glk8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-tglb3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-skl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#4613]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-skl9/igt@gem_lmem_swapp...@verify-random-ccs.html * igt@gem_pread@exhaustion: - shard-skl: NOTRUN -> [INCOMPLETE][11] ([i915#7248]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-skl4/igt@gem_pr...@exhaustion.html * igt@gem_softpin@evict-single-offset: - shard-tglb: [PASS][12] -> [FAIL][13] ([i915#4171]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb6/igt@gem_soft...@evict-single-offset.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-tglb2/igt@gem_soft...@evict-single-offset.html * igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-skl4/igt@kms_ccs@pipe-b-random-ccs-data-y_tiled_gen12_mc_ccs.html * igt@kms_chamelium@dp-hpd-for-each-pipe: - shard-skl: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-skl9/igt@kms_chamel...@dp-hpd-for-each-pipe.html * igt@kms_chamelium@vga-hpd-with-enabled-mode: - shard-snb: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-snb6/igt@kms_chamel...@vga-hpd-with-enabled-mode.html * igt@kms_cursor_crc@cursor-offscreen-32x10: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271]) +55 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-skl9/igt@kms_cursor_...@cursor-offscreen-32x10.html * igt@kms_flip@2x-flip-vs-expired-vblank@ac-hdmi-a1-hdmi-a2: - shard-glk: [PASS][18] -> [FAIL][19] ([i915#79]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@ac-hdmi-a1-hdmi-a2.html * igt@kms_flip@flip-vs-expired-vblank-interruptible@a-dp1: - shard-apl: [PASS][20] -> [FAIL][21] ([i915#79]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-apl7/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110930v1/shard-apl6/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-dp1.html *
[Intel-gfx] [PATCH 1/2] drm/ttm: Clean up page shift operation
remove page shift operations as ttm_resource moved
from num_pages to size_t size in bytes.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +---
drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 974e85d8b6cc..19ad365dc159 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -541,12 +541,10 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA)) {
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
- size <<= PAGE_SHIFT;
-
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
- size = ALIGN(size, 4) << PAGE_SHIFT;
+ size = ALIGN(size, 4);
} else {
/* Memory should be aligned at least to a page size. */
page_align = ALIGN(bp->byte_align, PAGE_SIZE) >> PAGE_SHIFT;
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 0a8bc0b7f380..4c7cba4ffdbf 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -83,7 +83,7 @@ static int ttm_range_man_alloc(struct ttm_resource_manager
*man,
spin_lock(&rman->lock);
ret = drm_mm_insert_node_in_range(mm, &node->mm_nodes[0],
- PFN_UP(node->base.size),
+ node->base.size,
bo->page_alignment, 0,
place->fpfn, lpfn, mode);
spin_unlock(&rman->lock);
--
2.32.0
[Intel-gfx] [PATCH 2/2] drm/gem: Remove BUG_ON in drm_gem_private_object_init
ttm_resource allocate size in bytes i.e less than page size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index b8db675e7fb5..a346e3b7f9a8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL(drm_gem_object_init);
void drm_gem_private_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size)
{
- BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+ //BUG_ON((size & (PAGE_SIZE - 1)) != 0);
obj->dev = dev;
obj->filp = NULL;
--
2.32.0
Re: [Intel-gfx] [PATCH 2/2] drm/gem: Remove BUG_ON in drm_gem_private_object_init
Hi Amar,
On 11/16/2022 2:20 PM, Somalapuram Amaranath wrote:
ttm_resource allocate size in bytes i.e less than page size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index b8db675e7fb5..a346e3b7f9a8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL(drm_gem_object_init);
void drm_gem_private_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size)
{
- BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+ //BUG_ON((size & (PAGE_SIZE - 1)) != 0);
This line is added by mistake?
Regards,
Arun
obj->dev = dev;
obj->filp = NULL;
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/mtl: Media GT and Render GT share common GGTT (rev4)
== Series Details ==
Series: drm/i915/mtl: Media GT and Render GT share common GGTT (rev4)
URL : https://patchwork.freedesktop.org/series/110321/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12382_full -> Patchwork_110321v4_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110321v4_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110321v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110321v4_full:
### IGT changes ###
Possible regressions
* igt@i915_hangman@detector@vecs0:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb1/igt@i915_hangman@detec...@vecs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/shard-tglb5/igt@i915_hangman@detec...@vecs0.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rc6_residency@rc6-idle@rcs0:
- {shard-dg1}:[FAIL][3] ([i915#3591]) -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-dg1-19/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/shard-dg1-12/igt@i915_pm_rc6_residency@rc6-i...@rcs0.html
Known issues
Here are the changes found in Patchwork_110321v4_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][5], [PASS][6], [PASS][7], [PASS][8],
[PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14],
[PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20],
[PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26],
[PASS][27], [PASS][28], [PASS][29]) -> ([PASS][30], [PASS][31], [PASS][32],
[PASS][33], [FAIL][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38],
[PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44],
[PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50],
[PASS][51], [PASS][52], [PASS][53], [PASS][54]) ([i915#4392])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk1/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk1/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk8/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk7/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk7/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk1/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk7/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk7/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk6/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk6/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk5/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk5/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk3/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk3/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk3/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk9/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk9/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk9/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk8/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk8/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/shard-glk9/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/shard-glk9/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110321v4/shard-glk9/boot.ht
Re: [Intel-gfx] [PATCH] drm/fb-helper: Try to protect cleanup against delayed setup
On Tue, Nov 15, 2022 at 10:30:01AM +0100, Andrzej Hajda wrote:
> On 13.07.2021 15:59, Daniel Vetter wrote:
> > Some vague evidences suggests this can go wrong. Try to prevent it by
> > holding the right mutex and clearing ->deferred_setup to make sure we
> > later on don't accidentally try to re-register the fbdev when the
> > driver thought it had it all cleaned up already.
> >
> > v2: I realized that this is fundamentally butchered, and CI complained
> > about lockdep splats. So limit the critical section again and just add
> > a few notes what the proper fix is.
> >
> > References:
> > https://intel-gfx-ci.01.org/tree/linux-next/next-20201215/fi-byt-j1900/igt@i915_pm_...@module-reload.html
> > Signed-off-by: Daniel Vetter
> > Cc: Ville Syrjälä
> > Cc: Chris Wilson
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Thomas Zimmermann
> > Cc: David Airlie
> > Cc: Daniel Vetter
>
> Reviewed-by: Andrzej Hajda
I just dropped this one from my patch pile a while ago, because there were
conflicts. If you like it, feel free to resurrect&rebase and then merge it
(but maybe cc intel-gfx so the CI there can test it).
-Daniel
>
> Regards
> Andrzej
>
> > ---
> > drivers/gpu/drm/drm_fb_helper.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_fb_helper.c
> > b/drivers/gpu/drm/drm_fb_helper.c
> > index 9d82fda274eb..8f11e5abb222 100644
> > --- a/drivers/gpu/drm/drm_fb_helper.c
> > +++ b/drivers/gpu/drm/drm_fb_helper.c
> > @@ -598,6 +598,9 @@ EXPORT_SYMBOL(drm_fb_helper_alloc_fbi);
> >* A wrapper around unregister_framebuffer, to release the fb_info
> >* framebuffer device. This must be called before releasing all resources
> > for
> >* @fb_helper by calling drm_fb_helper_fini().
> > + *
> > + * Note that this is fundamentally racy on hotunload because it doen't
> > handle
> > + * open fbdev file descriptors at all. Use drm_fbdev_generic_setup()
> > instead.
> >*/
> > void drm_fb_helper_unregister_fbi(struct drm_fb_helper *fb_helper)
> > {
> > @@ -611,6 +614,9 @@ EXPORT_SYMBOL(drm_fb_helper_unregister_fbi);
> >* @fb_helper: driver-allocated fbdev helper, can be NULL
> >*
> >* This cleans up all remaining resources associated with @fb_helper.
> > + *
> > + * Note that this is fundamentally racy on hotunload because it doen't
> > handle
> > + * open fbdev file descriptors at all. Use drm_fbdev_generic_setup()
> > instead.
> >*/
> > void drm_fb_helper_fini(struct drm_fb_helper *fb_helper)
> > {
> > @@ -2382,6 +2388,10 @@ static void drm_fbdev_client_unregister(struct
> > drm_client_dev *client)
> > {
> > struct drm_fb_helper *fb_helper = drm_fb_helper_from_client(client);
> > + mutex_lock(&fb_helper->lock);
> > + fb_helper->deferred_setup = false;
> > + mutex_unlock(&fb_helper->lock);
> > +
> > if (fb_helper->fbdev)
> > /* drm_fbdev_fb_destroy() takes care of cleanup */
> > drm_fb_helper_unregister_fbi(fb_helper);
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
Re: [Intel-gfx] [RESEND] drm/edid/firmware: stop using a throwaway platform device
Hi
Am 14.11.22 um 12:17 schrieb Jani Nikula:
We've used a temporary platform device for firmware EDID loading since
it was introduced in commit da0df92b5731 ("drm: allow loading an EDID as
firmware to override broken monitor"), but there's no explanation why.
Using a temporary device does not play well with CONFIG_FW_CACHE=y,
which caches firmware images (e.g. on suspend) so that drivers can
request firmware when the system is not ready for it, and return the
images from the cache (e.g. during resume). This works automatically for
regular devices, but obviously not for a temporarily created device.
Stop using the throwaway platform device, and use the drm device
instead.
Note that this may still be problematic for cases where the display was
plugged in during suspend, and the firmware wasn't loaded and therefore
not cached before suspend.
References:
https://lore.kernel.org/r/20220727074152.43059-1-matthieu.chare...@gmail.com
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2061
Reported-by: Matthieu CHARETTE
Tested-by: Matthieu CHARETTE
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
Acked-by: Thomas Zimmermann
I looked through request_firmware() but did not see any signs that it
somehow depends on a platform device. I assume that this might only
affect the device name in the error message.
Best regards
Thomas
---
Resend with a proper commit message; patch itself is unchanged.
---
drivers/gpu/drm/drm_edid_load.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index ef4ab59d6935..5d9ef267ebb3 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -172,20 +172,9 @@ static const struct drm_edid *edid_load(struct
drm_connector *connector, const c
fwdata = generic_edid[builtin];
fwsize = sizeof(generic_edid[builtin]);
} else {
- struct platform_device *pdev;
int err;
- pdev = platform_device_register_simple(connector->name, -1, NULL, 0);
- if (IS_ERR(pdev)) {
- drm_err(connector->dev,
- "[CONNECTOR:%d:%s] Failed to register EDID firmware platform
device for connector \"%s\"\n",
- connector->base.id, connector->name,
- connector->name);
- return ERR_CAST(pdev);
- }
-
- err = request_firmware(&fw, name, &pdev->dev);
- platform_device_unregister(pdev);
+ err = request_firmware(&fw, name, connector->dev->dev);
if (err) {
drm_err(connector->dev,
"[CONNECTOR:%d:%s] Requesting EDID firmware \"%s\"
failed (err=%d)\n",
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev
OpenPGP_signature
Description: OpenPGP digital signature
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory bandwidth via sysfs.
On 15-11-2022 13:38, Himal Prasad Ghimiray wrote:
> Export lmem maximum memory bandwidth to the userspace via sysfs.
>
> Signed-off-by: Himal Prasad Ghimiray
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/i915_sysfs.c | 27 +++
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index c4921c9a60770..3ba1efa995ca9 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6603,6 +6603,8 @@
> #define POWER_SETUP_I1_WATTSREG_BIT(31)
> #define POWER_SETUP_I1_SHIFT6 /* 10.6 fixed
> point format */
> #define POWER_SETUP_I1_DATA_MASKREG_GENMASK(15, 0)
> +#definePCODE_MEMORY_CONFIG 0x70
> +#define MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH 0x0
> #define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US 0x23
> #define XEHP_PCODE_FREQUENCY_CONFIG0x6e/* xehpsdv, pvc
> */
> /* XEHP_PCODE_FREQUENCY_CONFIG sub-commands (param1) */
> diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
> b/drivers/gpu/drm/i915/i915_sysfs.c
> index 595e8b5749907..0a6efc300998b 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -37,7 +37,10 @@
>
> #include "i915_drv.h"
> #include "i915_sysfs.h"
> +#include "i915_reg.h"
> #include "intel_pm.h"
> +#include "intel_pcode.h"
> +
>
> struct drm_i915_private *kdev_minor_to_i915(struct device *kdev)
> {
> @@ -231,11 +234,35 @@ static void i915_setup_error_capture(struct device
> *kdev) {}
> static void i915_teardown_error_capture(struct device *kdev) {}
> #endif
>
prelim naming shall not be used.
Thanks,
Aravind.
> +static ssize_t
> +prelim_lmem_max_bw_Mbps_show(struct device *dev, struct device_attribute
> *attr, char *buff)
> +{
> + struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> + u32 val;
> + int err;
> +
> + err = snb_pcode_read_p(&i915->uncore, PCODE_MEMORY_CONFIG,
> +MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH,
> +0x0, &val);
> + if (err)
> + return err;
> +
> + return sysfs_emit(buff, "%u\n", val);
> +}
> +
> +static DEVICE_ATTR_RO(prelim_lmem_max_bw_Mbps);
> +
> void i915_setup_sysfs(struct drm_i915_private *dev_priv)
> {
> struct device *kdev = dev_priv->drm.primary->kdev;
> int ret;
>
> + if (IS_DG1(dev_priv) || IS_DG2(dev_priv)) {
> + ret = sysfs_create_file(&kdev->kobj,
> &dev_attr_prelim_lmem_max_bw_Mbps.attr);
> + if (ret)
> + drm_err(&dev_priv->drm, "Setting up sysfs to read max
> B/W failed\n");
> + }
> +
> if (HAS_L3_DPF(dev_priv)) {
> ret = device_create_bin_file(kdev, &dpf_attrs);
> if (ret)
Re: [Intel-gfx] [PATCH i-g-t] tests/i915/madvise: verify async eviction with madvise
On 11/15/2022 11:34 AM, Matthew Auld wrote:
Simple regression test for lmem to check if an in-progress async unbind
and eviction is syncronised with discarding the pages when marking
the object as DONTNEED.
Signed-off-by: Matthew Auld
Cc: Niranjana Vishwanathapura
Cc: Andrzej Hajda
Cc: Nirmoy Das
---
tests/i915/gem_madvise.c | 130 ++-
1 file changed, 129 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_madvise.c b/tests/i915/gem_madvise.c
index 2502d84c..d164df3a 100644
--- a/tests/i915/gem_madvise.c
+++ b/tests/i915/gem_madvise.c
@@ -36,8 +36,9 @@
#include
#include
-#include "drm.h"
+#include "igt_kmod.h"
#include "i915/gem_create.h"
+#include "i915/gem.h"
IGT_TEST_DESCRIPTION("Checks that the kernel reports EFAULT when trying to use"
" purged bo.");
@@ -188,6 +189,76 @@ dontneed_before_exec(void)
close(fd);
}
+#define PAGE_SIZE 4096
+
+static uint32_t batch_create_size(int fd, uint64_t size)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(fd, size);
+ gem_write(fd, handle, 0, &bbe, sizeof(bbe));
+
+ return handle;
+}
+
+static int upload(int fd, uint32_t handle)
+{
+ struct drm_i915_gem_exec_object2 exec[2] = {};
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(&exec),
+ .buffer_count = 2,
+ };
+
+ exec[0].handle = handle;
+ exec[0].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+ exec[1].handle = batch_create_size(fd, PAGE_SIZE);
+ exec[1].flags = EXEC_OBJECT_SUPPORTS_48B_ADDRESS;
+
+ gem_execbuf(fd, &execbuf);
+ return 0;
+}
+
When we have some time in future, we should move above functions to a
common files.
Thanks Matt, for clarifying my doubts regarding this over Teams.
Reviewed-by: Nirmoy Das
+static void test_dontneed_evict_race(int fd,
+struct gem_memory_region *region)
+{
+ const uint64_t size = region->size >> 1;
+ uint64_t ahnd = get_reloc_ahnd(fd, 0);
+ uint32_t handle1;
+ igt_spin_t *spin;
+
+ handle1 = gem_create_in_memory_region_list(fd, size, 0,
+ ®ion->ci, 1);
+ spin = igt_spin_new(fd,
+ .ahnd = ahnd,
+ .dependency = handle1);
+
+ igt_fork(child, 1) {
+ uint32_t handle2;
+
+ fd = gem_reopen_driver(fd);
+
+ handle2 = gem_create_in_memory_region_list(fd,
+ size, 0,
+ ®ion->ci, 1);
+ /*
+* The actual move when evicting will be pipelined
+* behind the spinner, so can't fire until the spinner
+* is killed.
+*/
+ upload(fd, handle2);
+ gem_close(fd, handle2);
+ }
+
+ sleep(2); /* Give eviction time to find handle1 */
+ igt_spin_end(spin);
+ gem_madvise(fd, handle1, I915_MADV_DONTNEED);
+ igt_waitchildren();
+
+ igt_spin_free(fd, spin);
+ gem_close(fd, handle1);
+}
+
igt_main
{
igt_describe("Check signal for Segmentation Fault and bus error before"
@@ -209,4 +280,61 @@ igt_main
" purged bo for GPU.");
igt_subtest("dontneed-before-exec")
dontneed_before_exec();
+
+ igt_subtest_group {
+ struct drm_i915_query_memory_regions *regions;
+ int i915 = -1;
+
+ igt_fixture {
+ char *tmp;
+
+ if (igt_kmod_is_loaded("i915")) {
+ i915 = __drm_open_driver(DRIVER_INTEL);
+ igt_require_fd(i915);
+ igt_require_gem(i915);
+ igt_require(gem_has_lmem(i915));
+ close(i915);
+ }
+
+ igt_i915_driver_unload();
+ /*
+* To avoid running of ring space and stalling during
evicting
+* (while holding the dma-resv lock), we need to use a
smaller
+* lmem size, such we can easliy trigger eviction
without
+* needing to wait for more ring space. The point of
the test is
+* to mark the object as DONTNEED which has an
in-progress
+* pipilined unbind/move, which also requires grabbing
the
+* dma-resv lock.
+*/
+ igt_assert_eq(igt_i915_driver_load("lmem_size=128"), 0);
+
+ i915 = __drm_open_driver(DRIVER_INTEL);
+ igt_require_fd(i915);
+
Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: call i915_request_await_object from _i915_vma_move_to_active
On 15/11/2022 18:13, Andrzej Hajda wrote: On 08.11.2022 11:24, Matthew Auld wrote: On 19/10/2022 22:59, Andrzej Hajda wrote: Since almost all calls to i915_vma_move_to_active are prepended with i915_request_await_object, let's call the latter from _i915_vma_move_to_active by default and add flag allowing bypassing it. Adjust all callers accordingly. The patch should not introduce functional changes. Signed-off-by: Andrzej Hajda I thought someone already reviewed this series. Anyway, Reviewed-by: Matthew Auld Gently ping for merge. Pushed to gt-next. Thanks. Regards Andrzej
Re: [Intel-gfx] How is the progress for removing flush_scheduled_work() callers?
On Sun, 06 Nov 2022, Tetsuo Handa wrote:
> Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
> macro") says, flush_scheduled_work() is dangerous and will be forbidden.
> We are on the way for removing all flush_scheduled_work() callers from
> the kernel, and there are only 4 callers remaining as of linux-20221104.
>
> drivers/gpu/drm/i915/display/intel_display.c:8997:
> flush_scheduled_work();
Thanks for the reminder, I've pinged folks to get someone working on
this. We do schedule quite a bunch of work, so it's not immediately
obvious (at least to me) what exactly needs flushing.
https://gitlab.freedesktop.org/drm/intel/-/issues/7546
> drivers/gpu/drm/i915/gt/selftest_execlists.c:88:
> flush_scheduled_work();
Removed by commit 7d33fd02dd94 ("drm/i915/selftests: Remove
flush_scheduled_work() from live_execlists") in drm-next.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory bandwidth via sysfs.
> -Original Message-
> From: Intel-gfx On Behalf Of
> Himal Prasad Ghimiray
> Sent: Tuesday, November 15, 2022 1:39 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> bandwidth via sysfs.
>
> Export lmem maximum memory bandwidth to the userspace via sysfs.
>
> Signed-off-by: Himal Prasad Ghimiray
> ---
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> drivers/gpu/drm/i915/i915_sysfs.c | 27 +++
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h index c4921c9a60770..3ba1efa995ca9
> 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -6603,6 +6603,8 @@
> #define POWER_SETUP_I1_WATTSREG_BIT(31)
> #define POWER_SETUP_I1_SHIFT6 /* 10.6 fixed
> point format */
> #define POWER_SETUP_I1_DATA_MASK
> REG_GENMASK(15, 0)
> +#definePCODE_MEMORY_CONFIG 0x70
Please re-arrange the macros in increasing order of pcode command.
> +#define
> MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH 0x0
> #define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US 0x23
> #define XEHP_PCODE_FREQUENCY_CONFIG0x6e/* xehpsdv,
> pvc */
> /* XEHP_PCODE_FREQUENCY_CONFIG sub-commands (param1) */ diff --git
> a/drivers/gpu/drm/i915/i915_sysfs.c b/drivers/gpu/drm/i915/i915_sysfs.c
> index 595e8b5749907..0a6efc300998b 100644
> --- a/drivers/gpu/drm/i915/i915_sysfs.c
> +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> @@ -37,7 +37,10 @@
>
> #include "i915_drv.h"
> #include "i915_sysfs.h"
> +#include "i915_reg.h"
> #include "intel_pm.h"
> +#include "intel_pcode.h"
> +
>
> struct drm_i915_private *kdev_minor_to_i915(struct device *kdev) { @@ -
> 231,11 +234,35 @@ static void i915_setup_error_capture(struct device
> *kdev) {} static void i915_teardown_error_capture(struct device *kdev) {}
> #endif
>
> +static ssize_t
> +prelim_lmem_max_bw_Mbps_show(struct device *dev, struct
Please don't use mixed case here,
How about i915_lmem_max_bw_mbps_show ?
> +device_attribute *attr, char *buff) {
> + struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> + u32 val;
> + int err;
> +
> + err = snb_pcode_read_p(&i915->uncore,
> PCODE_MEMORY_CONFIG,
> +
> MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH,
> +0x0, &val);
> + if (err)
> + return err;
> +
> + return sysfs_emit(buff, "%u\n", val);
> +}
> +
> +static DEVICE_ATTR_RO(prelim_lmem_max_bw_Mbps);
> +
> void i915_setup_sysfs(struct drm_i915_private *dev_priv) {
> struct device *kdev = dev_priv->drm.primary->kdev;
> int ret;
>
> + if (IS_DG1(dev_priv) || IS_DG2(dev_priv)) {
This seems to discrete agnostic.
How about HAS_LMEM ?
> + ret = sysfs_create_file(&kdev->kobj,
> &dev_attr_prelim_lmem_max_bw_Mbps.attr);
> + if (ret)
> + drm_err(&dev_priv->drm, "Setting up sysfs to read
> max B/W failed\n");
Why this sys fs is outside gt directory ?
Thanks,
Anshuman.
> + }
> +
> if (HAS_L3_DPF(dev_priv)) {
> ret = device_create_bin_file(kdev, &dpf_attrs);
> if (ret)
> --
> 2.25.1
Re: [Intel-gfx] [PATCH 2/2] drm/gem: Remove BUG_ON in drm_gem_private_object_init
Am 16.11.22 um 10:20 schrieb Arunpravin Paneer Selvam:
Hi Amar,
On 11/16/2022 2:20 PM, Somalapuram Amaranath wrote:
ttm_resource allocate size in bytes i.e less than page size.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/drm_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index b8db675e7fb5..a346e3b7f9a8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL(drm_gem_object_init);
void drm_gem_private_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size)
{
- BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+ //BUG_ON((size & (PAGE_SIZE - 1)) != 0);
This line is added by mistake?
Yeah, comment it out is not a good idea. Instead we should probably move
it somewhere else, e.g. the shmem object initializing code path still
needs this.
Additional to that please re-order the patches, this here is a
prerequisite and should come first.
Regards,
Christian.
Regards,
Arun
obj->dev = dev;
obj->filp = NULL;
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory bandwidth via sysfs.
> -Original Message-
> From: Gupta, Anshuman
> Sent: 16 November 2022 15:38
> To: Ghimiray, Himal Prasad ; intel-
> g...@lists.freedesktop.org
> Cc: Iddamsetty, Aravind
> Subject: RE: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> bandwidth via sysfs.
>
>
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Himal Prasad Ghimiray
> > Sent: Tuesday, November 15, 2022 1:39 PM
> > To: intel-gfx@lists.freedesktop.org
> > Subject: [Intel-gfx] [PATCH 1/1] drm/i915: Export LMEM max memory
> > bandwidth via sysfs.
> >
> > Export lmem maximum memory bandwidth to the userspace via sysfs.
> >
> > Signed-off-by: Himal Prasad Ghimiray
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > drivers/gpu/drm/i915/i915_sysfs.c | 27 +++
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index c4921c9a60770..3ba1efa995ca9
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -6603,6 +6603,8 @@
> > #definePOWER_SETUP_I1_WATTSREG_BIT(31)
> > #definePOWER_SETUP_I1_SHIFT6 /* 10.6 fixed
> > point format */
> > #definePOWER_SETUP_I1_DATA_MASK
> > REG_GENMASK(15, 0)
> > +#define PCODE_MEMORY_CONFIG 0x70
> Please re-arrange the macros in increasing order of pcode command.
> > +#define
> > MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH 0x0
> > #define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US0x23
> > #define XEHP_PCODE_FREQUENCY_CONFIG 0x6e/*
> xehpsdv,
> > pvc */
> > /* XEHP_PCODE_FREQUENCY_CONFIG sub-commands (param1) */ diff --
> git
> > a/drivers/gpu/drm/i915/i915_sysfs.c
> > b/drivers/gpu/drm/i915/i915_sysfs.c
> > index 595e8b5749907..0a6efc300998b 100644
> > --- a/drivers/gpu/drm/i915/i915_sysfs.c
> > +++ b/drivers/gpu/drm/i915/i915_sysfs.c
> > @@ -37,7 +37,10 @@
> >
> > #include "i915_drv.h"
> > #include "i915_sysfs.h"
> > +#include "i915_reg.h"
> > #include "intel_pm.h"
> > +#include "intel_pcode.h"
> > +
> >
> > struct drm_i915_private *kdev_minor_to_i915(struct device *kdev) {
> > @@ -
> > 231,11 +234,35 @@ static void i915_setup_error_capture(struct device
> > *kdev) {} static void i915_teardown_error_capture(struct device
> > *kdev) {} #endif
> >
> > +static ssize_t
> > +prelim_lmem_max_bw_Mbps_show(struct device *dev, struct
> Please don't use mixed case here,
> How about i915_lmem_max_bw_mbps_show ?
[Ghimiray, Himal Prasad]
We need to differentiate between Mb (Mega bit) vs MB(MegaByte) ,Hence I used
camelCase.
Using i915_lmem_max_bw_mbps_show will not give clarity whether the value is in
Mb or MB.
BR
Himal Ghimiray
> > +device_attribute *attr, char *buff) {
> > + struct drm_i915_private *i915 = kdev_minor_to_i915(dev);
> > + u32 val;
> > + int err;
> > +
> > + err = snb_pcode_read_p(&i915->uncore,
> > PCODE_MEMORY_CONFIG,
> > +
> > MEMORY_CONFIG_SUBCOMMAND_READ_MAX_BANDWIDTH,
> > + 0x0, &val);
> > + if (err)
> > + return err;
> > +
> > + return sysfs_emit(buff, "%u\n", val); }
> > +
> > +static DEVICE_ATTR_RO(prelim_lmem_max_bw_Mbps);
> > +
> > void i915_setup_sysfs(struct drm_i915_private *dev_priv) {
> > struct device *kdev = dev_priv->drm.primary->kdev;
> > int ret;
> >
> > + if (IS_DG1(dev_priv) || IS_DG2(dev_priv)) {
> This seems to discrete agnostic.
> How about HAS_LMEM ?
> > + ret = sysfs_create_file(&kdev->kobj,
> > &dev_attr_prelim_lmem_max_bw_Mbps.attr);
>
> > + if (ret)
> > + drm_err(&dev_priv->drm, "Setting up sysfs to read
> > max B/W failed\n");
> Why this sys fs is outside gt directory ?
> Thanks,
> Anshuman.
> > + }
> > +
> > if (HAS_L3_DPF(dev_priv)) {
> > ret = device_create_bin_file(kdev, &dpf_attrs);
> > if (ret)
> > --
> > 2.25.1
[Intel-gfx] [PATCH 0/3] drm/i915: Fix timeout handling when retiring requests
Fixes for issues discovered via code review while working on https://gitlab.freedesktop.org/drm/intel/issues/7349. Reworked version of a series supposed to fix the same issues, sent before under the same subject. Since some solutions are significantly different than before, I'm not marking this series and individual patches as v2. Janusz Krzysztofik (3): drm/i915: Fix negative remaining time after retire requests drm/i915: Never return 0 on timeout when retiring requests drm/i915: Never return 0 if request wait succeeds drivers/gpu/drm/i915/gt/intel_gt_requests.c | 26 ++--- drivers/gpu/drm/i915/i915_request.c | 2 ++ 2 files changed, 25 insertions(+), 3 deletions(-) -- 2.25.1
[Intel-gfx] [PATCH 1/3] drm/i915: Fix negative remaining time after retire requests
Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
with GuC") extended the API of intel_gt_retire_requests_timeout() with an
extra argument 'remaining_timeout', intended for passing back unconsumed
portion of requested timeout when 0 (success) is returned. However, when
request retirement happens to succeed despite an error returned by
dma_fence_wait_timeout(), the error code (a negative value) is passed back
instead of remaining time. If a user then passes that negative value
forward as requested timeout to another wait, an explicit WARN or BUG can
be triggered.
Instead of copying the value of timeout variable to *remaining_timeout
before return, update the *remaining_timeout after each DMA fence wait.
Set it to 0 on -ETIME, -EINTR or -ERESTARTSYS, and assume no time has been
consumed on other errors returned from the wait.
Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with
GuC")
Signed-off-by: Janusz Krzysztofik
Cc: sta...@vger.kernel.org # v5.15+
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 23 ++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index edb881d756309..ccaf2fd80625b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -138,6 +138,9 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout,
unsigned long active_count = 0;
LIST_HEAD(free);
+ if (remaining_timeout)
+ *remaining_timeout = timeout;
+
flush_submission(gt, timeout); /* kick the ksoftirqd tasklets */
spin_lock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &timelines->active_list, link) {
@@ -163,6 +166,23 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout,
timeout);
dma_fence_put(fence);
+ if (remaining_timeout) {
+ /*
+* If we get an error here but request
+* retirement succeeds anyway
+* (!active_count) and we return 0, the
+* caller may want to spend remaining
+* time on waiting for other events.
+*/
+ if (timeout == -ETIME ||
+ timeout == -EINTR ||
+ timeout == -ERESTARTSYS)
+ *remaining_timeout = 0;
+ else if (timeout >= 0)
+ *remaining_timeout = timeout;
+ /* else assume no time consumed */
+ }
+
/* Retirement is best effort */
if (!mutex_trylock(&tl->mutex)) {
active_count++;
@@ -196,9 +216,6 @@ out_active: spin_lock(&timelines->lock);
if (flush_submission(gt, timeout)) /* Wait, there's more! */
active_count++;
- if (remaining_timeout)
- *remaining_timeout = timeout;
-
return active_count ? timeout : 0;
}
--
2.25.1
[Intel-gfx] [PATCH 2/3] drm/i915: Never return 0 on timeout when retiring requests
Users of intel_gt_retire_requests_timeout() expect 0 return value on
success. However, we have no protection from passing back 0 potentially
returned by dma_fence_wait_timeout() on timeout.
Replace 0 with -ETIME before using timeout as return value.
Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request")
Signed-off-by: Janusz Krzysztofik
Cc: sta...@vger.kernel.org # v5.5+
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index ccaf2fd80625b..ac6b2b1861397 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -213,6 +213,9 @@ out_active: spin_lock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &free, link)
__intel_timeline_free(&tl->kref);
+ if (!timeout)
+ timeout = -ETIME;
+
if (flush_submission(gt, timeout)) /* Wait, there's more! */
active_count++;
--
2.25.1
[Intel-gfx] [PATCH 3/3] drm/i915: Never return 0 if request wait succeeds
According to the docs of i915_request_wait_timeout(), its return value
"may be zero if the request is unfinished after the timeout expires."
However, 0 is also returned when the request is found finished right
after the timeout has expired.
Since the docs also state: "If the timeout is 0, it will return 1 if the
fence is signaled.", return 1 also when the fence is found signaled after
non-zero timeout has expired.
Fixes: 7e2e69ed4678 ("drm/i915: Fix i915_request fence wait semantics")
Signed-off-by: Janusz Krzysztofik
Cc: sta...@vger.kernel.org # v5.17
---
drivers/gpu/drm/i915/i915_request.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f949a9495758a..406ddfafbed4d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -2079,6 +2079,8 @@ long i915_request_wait_timeout(struct i915_request *rq,
timeout = io_schedule_timeout(timeout);
}
+ if (!timeout) /* expired but signaled, we shouldn't return 0 */
+ timeout = 1;
__set_current_state(TASK_RUNNING);
if (READ_ONCE(wait.tsk))
--
2.25.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Update workaround documentation (rev2)
== Series Details == Series: drm/i915: Update workaround documentation (rev2) URL : https://patchwork.freedesktop.org/series/110639/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12382_full -> Patchwork_110639v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_110639v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110639v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (11 -> 11) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110639v2_full: ### IGT changes ### Possible regressions * igt@gem_exec_fence@syncobj-unused-fence: - shard-skl: [PASS][1] -> [WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-skl10/igt@gem_exec_fe...@syncobj-unused-fence.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-skl2/igt@gem_exec_fe...@syncobj-unused-fence.html Known issues Here are the changes found in Patchwork_110639v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-hang: - shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-snb4/igt@gem_ctx_persiste...@legacy-engines-hang.html * igt@gem_eio@unwedge-stress: - shard-snb: NOTRUN -> [FAIL][4] ([i915#3354]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-snb4/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk2/igt@gem_exec_f...@basic-deadline.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-glk6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vecs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-glk3/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][9] -> [FAIL][10] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-tglb8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-tglb1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_lmem_swapping@verify-random-ccs: - shard-skl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-skl9/igt@gem_lmem_swapp...@verify-random-ccs.html * igt@i915_pm_dc@dc6-dpms: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#3989] / [i915#454]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-iclb5/igt@i915_pm...@dc6-dpms.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-iclb3/igt@i915_pm...@dc6-dpms.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][14] -> [DMESG-WARN][15] ([i915#180]) +1 similar issue [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_atomic_transition@plane-all-modeset-transition-fencing@pipe-b-hdmi-a-2: - shard-glk: NOTRUN -> [INCOMPLETE][16] ([i915#5584]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-glk8/igt@kms_atomic_transition@plane-all-modeset-transition-fenc...@pipe-b-hdmi-a-2.html * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#5138]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12382/shard-iclb3/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-iclb5/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0.html * igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc: - shard-skl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110639v2/shard-skl9/igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html * igt@kms_chamelium@dp-hpd-for-each-pipe: - shard-skl:
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm-misc-fixes tree
Am 16.11.22 um 01:25 schrieb Stephen Rothwell:
Hi all,
On Wed, 16 Nov 2022 10:47:52 +1100 Stephen Rothwell
wrote:
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
between commit:
eca13f3c67b6 ("drm/amdgpu: use the last IB as gang leader v2")
from the drm-misc-fixes tree and commit:
1728baa7e4e6 ("drm/amdgpu: use scheduler dependencies for CS")
from the drm-misc tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index de5cb056c9ad,0528c2b1db6e..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@@ -1197,10 -1201,7 +1203,10 @@@ static int amdgpu_cs_sync_rings(struct
}
for (i = 0; i < p->gang_size; ++i) {
+ if (p->jobs[i] == leader)
+ continue;
+
- r = amdgpu_sync_clone(&leader->sync, &p->jobs[i]->sync);
+ r = amdgpu_sync_push_to_job(&p->sync, p->jobs[i]);
if (r)
return r;
}
@@@ -1241,14 -1243,11 +1247,14 @@@ static int amdgpu_cs_submit(struct amdg
for (i = 0; i < p->gang_size; ++i)
drm_sched_job_arm(&p->jobs[i]->base);
- for (i = 0; i < (p->gang_size - 1); ++i) {
+ for (i = 0; i < p->gang_size; ++i) {
struct dma_fence *fence;
+ if (p->jobs[i] == leader)
+ continue;
+
fence = &p->jobs[i]->base.s_fence->scheduled;
- r = amdgpu_sync_fence(&leader->sync, fence);
+ r = drm_sched_job_add_dependency(&leader->base, fence);
if (r)
goto error_cleanup;
}
Note that I had to keep the declaration of "leader" in amdgpu_cs_sync_rings().
This and all your other merge resolutions look good to me.
And sorry for the noise, drm-tip somehow doesn't seem to work any more
and we had a lot of conflicting patches going in through -fixes and -next.
Regards,
Christian.
Re: [Intel-gfx] [PATCH 1/2] drm/ttm: Clean up page shift operation
Am 16.11.22 um 09:50 schrieb Somalapuram Amaranath:
remove page shift operations as ttm_resource moved
from num_pages to size_t size in bytes.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 4 +---
drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +-
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 974e85d8b6cc..19ad365dc159 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -541,12 +541,10 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA)) {
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
- size <<= PAGE_SHIFT;
-
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
- size = ALIGN(size, 4) << PAGE_SHIFT;
+ size = ALIGN(size, 4);
} else {
/* Memory should be aligned at least to a page size. */
page_align = ALIGN(bp->byte_align, PAGE_SIZE) >> PAGE_SHIFT;
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 0a8bc0b7f380..4c7cba4ffdbf 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -83,7 +83,7 @@ static int ttm_range_man_alloc(struct ttm_resource_manager
*man,
spin_lock(&rman->lock);
ret = drm_mm_insert_node_in_range(mm, &node->mm_nodes[0],
- PFN_UP(node->base.size),
+ node->base.size,
bo->page_alignment, 0,
place->fpfn, lpfn, mode);
You need to make sure that fpfn and lpfn are now page shifted instead.
Same for the overlap and compatible functions.
Regards,
Christian.
spin_unlock(&rman->lock);
[Intel-gfx] [PATCH v3 1/2] mei: add timeout to send
When driver wakes up the firmware from the low power state,
it is sending a memory ready message.
The send is done via synchronous/blocking function to ensure
that firmware is in ready state. However, in case of firmware
undergoing reset send might be block forever.
To address this issue a timeout is added to blocking
write command on the internal bus.
Introduce the __mei_cl_send_timeout function to use instead of
__mei_cl_send in cases where timeout is required.
The mei_cl_write has only two callers and there is no need to split
it into two functions.
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/bus-fixup.c | 7 +--
drivers/misc/mei/bus.c | 22 +-
drivers/misc/mei/client.c| 20
drivers/misc/mei/client.h| 2 +-
drivers/misc/mei/main.c | 2 +-
drivers/misc/mei/mei_dev.h | 2 ++
6 files changed, 46 insertions(+), 9 deletions(-)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 71fbf0bc8453..90023c34666e 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -188,17 +188,20 @@ static int mei_fwver(struct mei_cl_device *cldev)
return ret;
}
+#define GFX_MEMORY_READY_TIMEOUT 200 /* timeout in milliseconds */
+
static int mei_gfx_memory_ready(struct mei_cl_device *cldev)
{
struct mkhi_gfx_mem_ready req = {0};
- unsigned int mode = MEI_CL_IO_TX_INTERNAL;
+ unsigned int mode = MEI_CL_IO_TX_INTERNAL | MEI_CL_IO_TX_BLOCKING;
req.hdr.group_id = MKHI_GROUP_ID_GFX;
req.hdr.command = MKHI_GFX_MEMORY_READY_CMD_REQ;
req.flags = MKHI_GFX_MEM_READY_PXP_ALLOWED;
dev_dbg(&cldev->dev, "Sending memory ready command\n");
- return __mei_cl_send(cldev->cl, (u8 *)&req, sizeof(req), 0, mode);
+ return __mei_cl_send_timeout(cldev->cl, (u8 *)&req, sizeof(req), 0,
+mode, GFX_MEMORY_READY_TIMEOUT);
}
static void mei_mkhi_fix(struct mei_cl_device *cldev)
diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 1fbe127ff633..4a08b624910a 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -34,6 +34,26 @@
*/
ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf, size_t length, u8 vtag,
unsigned int mode)
+{
+ return __mei_cl_send_timeout(cl, buf, length, vtag, mode,
MAX_SCHEDULE_TIMEOUT);
+}
+
+/**
+ * __mei_cl_send_timeout - internal client send (write)
+ *
+ * @cl: host client
+ * @buf: buffer to send
+ * @length: buffer length
+ * @vtag: virtual tag
+ * @mode: sending mode
+ * @timeout: send timeout in milliseconds.
+ * effective only for blocking writes: the MEI_CL_IO_TX_BLOCKING
mode bit is set.
+ * set timeout to the MAX_SCHEDULE_TIMEOUT to maixum allowed wait.
+ *
+ * Return: written size bytes or < 0 on error
+ */
+ssize_t __mei_cl_send_timeout(struct mei_cl *cl, const u8 *buf, size_t length,
u8 vtag,
+ unsigned int mode, unsigned long timeout)
{
struct mei_device *bus;
struct mei_cl_cb *cb;
@@ -108,7 +128,7 @@ ssize_t __mei_cl_send(struct mei_cl *cl, const u8 *buf,
size_t length, u8 vtag,
cb->buf.size = 0;
}
- rets = mei_cl_write(cl, cb);
+ rets = mei_cl_write(cl, cb, timeout);
if (mode & MEI_CL_IO_SGL && rets == 0)
rets = length;
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index 6c8b71ae32c8..9ddb854b8155 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -1954,10 +1954,13 @@ int mei_cl_irq_write(struct mei_cl *cl, struct
mei_cl_cb *cb,
*
* @cl: host client
* @cb: write callback with filled data
+ * @timeout: send timeout in milliseconds.
+ * effective only for blocking writes: the cb->blocking is set.
+ * set timeout to the MAX_SCHEDULE_TIMEOUT to maixum allowed wait.
*
* Return: number of bytes sent on success, <0 on failure.
*/
-ssize_t mei_cl_write(struct mei_cl *cl, struct mei_cl_cb *cb)
+ssize_t mei_cl_write(struct mei_cl *cl, struct mei_cl_cb *cb, unsigned long
timeout)
{
struct mei_device *dev;
struct mei_msg_data *buf;
@@ -2081,11 +2084,20 @@ ssize_t mei_cl_write(struct mei_cl *cl, struct
mei_cl_cb *cb)
if (blocking && cl->writing_state != MEI_WRITE_COMPLETE) {
mutex_unlock(&dev->device_lock);
- rets = wait_event_interruptible(cl->tx_wait,
- cl->writing_state == MEI_WRITE_COMPLETE ||
- (!mei_cl_is_connected(cl)));
+ rets = wait_event_interruptible_timeout(cl->tx_wait,
+ cl->writing_state ==
MEI_WRITE_COMPLETE ||
+
(!mei_cl_is_connected(cl)),
+
msecs_to_jiffies(timeout));
mutex_lock(&dev->device
[Intel-gfx] [PATCH v3 0/2] mei: add timeout to send
When driver wakes up the firmware from the low power state, it is sending a memory ready message. The send is done via synchronous/blocking function to ensure that firmware is in ready state. However, in case of firmware undergoing reset send might be block forever. To address this issue a timeout is added to blocking write command on the internal bus. Introduce the __mei_cl_send_timeout function to use instead of __mei_cl_send in cases where timeout is required. The mei_cl_write has only two callers and there is no need to split it into two functions. V2: address review comments: - split __mei_cl_send and __mei_cl_send_timeout - add units to timeout KDoc - use MAX_SCHEDULE_TIMEOUT to squash wait to one macro V3: - split the state fix into separate patch - document define unit - expand timeout KDoc Alexander Usyskin (2): mei: add timeout to send mei: bus-fixup: change pxp mode only if message was sent drivers/misc/mei/bus-fixup.c | 14 +- drivers/misc/mei/bus.c | 22 +- drivers/misc/mei/client.c| 20 drivers/misc/mei/client.h| 2 +- drivers/misc/mei/main.c | 2 +- drivers/misc/mei/mei_dev.h | 2 ++ 6 files changed, 50 insertions(+), 12 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH v3 2/2] mei: bus-fixup: change pxp mode only if message was sent
Move PXP mode state machine to SETUP mode only if
memory ready message sent successfully to the firmware.
Leave it in INIT mode otherwise to allow try to send message later.
Signed-off-by: Alexander Usyskin
---
drivers/misc/mei/bus-fixup.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/misc/mei/bus-fixup.c b/drivers/misc/mei/bus-fixup.c
index 90023c34666e..6df7679d9739 100644
--- a/drivers/misc/mei/bus-fixup.c
+++ b/drivers/misc/mei/bus-fixup.c
@@ -266,12 +266,13 @@ static void mei_gsc_mkhi_fix_ver(struct mei_cl_device
*cldev)
if (cldev->bus->pxp_mode == MEI_DEV_PXP_INIT) {
ret = mei_gfx_memory_ready(cldev);
- if (ret < 0)
+ if (ret < 0) {
dev_err(&cldev->dev, "memory ready command failed
%d\n", ret);
- else
+ } else {
dev_dbg(&cldev->dev, "memory ready command sent\n");
+ cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
+ }
/* we go to reset after that */
- cldev->bus->pxp_mode = MEI_DEV_PXP_SETUP;
goto out;
}
--
2.34.1
Re: [Intel-gfx] How is the progress for removing flush_scheduled_work() callers?
On Wed, Nov 16, 2022 at 12:08:27PM +0200, Jani Nikula wrote:
> On Sun, 06 Nov 2022, Tetsuo Handa wrote:
> > Like commit c4f135d643823a86 ("workqueue: Wrap flush_workqueue() using a
> > macro") says, flush_scheduled_work() is dangerous and will be forbidden.
> > We are on the way for removing all flush_scheduled_work() callers from
> > the kernel, and there are only 4 callers remaining as of linux-20221104.
> >
> > drivers/gpu/drm/i915/display/intel_display.c:8997:
> > flush_scheduled_work();
>
> Thanks for the reminder, I've pinged folks to get someone working on
> this. We do schedule quite a bunch of work, so it's not immediately
> obvious (at least to me) what exactly needs flushing.
Here's my earlier cursory analysis of the subject:
https://lore.kernel.org/intel-gfx/yy3byxfrfafql...@intel.com/
>
> https://gitlab.freedesktop.org/drm/intel/-/issues/7546
>
> > drivers/gpu/drm/i915/gt/selftest_execlists.c:88:
> > flush_scheduled_work();
>
> Removed by commit 7d33fd02dd94 ("drm/i915/selftests: Remove
> flush_scheduled_work() from live_execlists") in drm-next.
>
> BR,
> Jani.
>
> --
> Jani Nikula, Intel Open Source Graphics Center
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix negative remaining time after retire requests
On 16.11.2022 12:25, Janusz Krzysztofik wrote:
Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
with GuC") extended the API of intel_gt_retire_requests_timeout() with an
extra argument 'remaining_timeout', intended for passing back unconsumed
portion of requested timeout when 0 (success) is returned. However, when
request retirement happens to succeed despite an error returned by
dma_fence_wait_timeout(), the error code (a negative value) is passed back
instead of remaining time. If a user then passes that negative value
forward as requested timeout to another wait, an explicit WARN or BUG can
be triggered.
Instead of copying the value of timeout variable to *remaining_timeout
before return, update the *remaining_timeout after each DMA fence wait.
Set it to 0 on -ETIME, -EINTR or -ERESTARTSYS, and assume no time has been
consumed on other errors returned from the wait.
Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with
GuC")
Signed-off-by: Janusz Krzysztofik
Cc: sta...@vger.kernel.org # v5.15+
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 23 ++---
1 file changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index edb881d756309..ccaf2fd80625b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -138,6 +138,9 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout,
unsigned long active_count = 0;
LIST_HEAD(free);
+ if (remaining_timeout)
+ *remaining_timeout = timeout;
+
flush_submission(gt, timeout); /* kick the ksoftirqd tasklets */
spin_lock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &timelines->active_list, link) {
@@ -163,6 +166,23 @@ long intel_gt_retire_requests_timeout(struct intel_gt *gt,
long timeout,
timeout);
dma_fence_put(fence);
+if (remaining_timeout) {
+ /*
+* If we get an error here but request
+* retirement succeeds anyway
+* (!active_count) and we return 0, the
+* caller may want to spend remaining
+* time on waiting for other events.
+*/
+ if (timeout == -ETIME ||
+ timeout == -EINTR ||
+ timeout == -ERESTARTSYS)
+ *remaining_timeout = 0;
+ else if (timeout >= 0)
+ *remaining_timeout = timeout;
+ /* else assume no time consumed */
Looks correct, but the crazy semantic of dma_fence_wait_timeout does not
make it easy to understand.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
+ }
+
/* Retirement is best effort */
if (!mutex_trylock(&tl->mutex)) {
active_count++;
@@ -196,9 +216,6 @@ out_active: spin_lock(&timelines->lock);
if (flush_submission(gt, timeout)) /* Wait, there's more! */
active_count++;
- if (remaining_timeout)
- *remaining_timeout = timeout;
-
return active_count ? timeout : 0;
}
Re: [Intel-gfx] [RESEND] drm/edid/firmware: stop using a throwaway platform device
On Wed, 16 Nov 2022, Thomas Zimmermann wrote:
> Hi
>
> Am 14.11.22 um 12:17 schrieb Jani Nikula:
>> We've used a temporary platform device for firmware EDID loading since
>> it was introduced in commit da0df92b5731 ("drm: allow loading an EDID as
>> firmware to override broken monitor"), but there's no explanation why.
>>
>> Using a temporary device does not play well with CONFIG_FW_CACHE=y,
>> which caches firmware images (e.g. on suspend) so that drivers can
>> request firmware when the system is not ready for it, and return the
>> images from the cache (e.g. during resume). This works automatically for
>> regular devices, but obviously not for a temporarily created device.
>>
>> Stop using the throwaway platform device, and use the drm device
>> instead.
>>
>> Note that this may still be problematic for cases where the display was
>> plugged in during suspend, and the firmware wasn't loaded and therefore
>> not cached before suspend.
>>
>> References:
>> https://lore.kernel.org/r/20220727074152.43059-1-matthieu.chare...@gmail.com
>> Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2061
>> Reported-by: Matthieu CHARETTE
>> Tested-by: Matthieu CHARETTE
>> Cc: Ville Syrjälä
>> Signed-off-by: Jani Nikula
>
> Acked-by: Thomas Zimmermann
>
> I looked through request_firmware() but did not see any signs that it
> somehow depends on a platform device. I assume that this might only
> affect the device name in the error message.
Thanks, pushed to drm-misc-next.
Matthieu, thanks for you patience and the report as well!
BR,
Jani.
>
> Best regards
> Thomas
>
>>
>> ---
>>
>> Resend with a proper commit message; patch itself is unchanged.
>> ---
>> drivers/gpu/drm/drm_edid_load.c | 13 +
>> 1 file changed, 1 insertion(+), 12 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_edid_load.c
>> b/drivers/gpu/drm/drm_edid_load.c
>> index ef4ab59d6935..5d9ef267ebb3 100644
>> --- a/drivers/gpu/drm/drm_edid_load.c
>> +++ b/drivers/gpu/drm/drm_edid_load.c
>> @@ -172,20 +172,9 @@ static const struct drm_edid *edid_load(struct
>> drm_connector *connector, const c
>> fwdata = generic_edid[builtin];
>> fwsize = sizeof(generic_edid[builtin]);
>> } else {
>> -struct platform_device *pdev;
>> int err;
>>
>> -pdev = platform_device_register_simple(connector->name, -1,
>> NULL, 0);
>> -if (IS_ERR(pdev)) {
>> -drm_err(connector->dev,
>> -"[CONNECTOR:%d:%s] Failed to register EDID
>> firmware platform device for connector \"%s\"\n",
>> -connector->base.id, connector->name,
>> -connector->name);
>> -return ERR_CAST(pdev);
>> -}
>> -
>> -err = request_firmware(&fw, name, &pdev->dev);
>> -platform_device_unregister(pdev);
>> +err = request_firmware(&fw, name, connector->dev->dev);
>> if (err) {
>> drm_err(connector->dev,
>> "[CONNECTOR:%d:%s] Requesting EDID firmware
>> \"%s\" failed (err=%d)\n",
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool
On Fr, 2022-11-11 at 15:58 +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used > to display a sorted by card and usage list of processes using GPUs. > > Borrows a bit of code from intel_gpu_top but for now omits the fancy > features like interactive functionality, card selection, client > aggregation, sort modes, JSON output and pretty engine names. Also no > support for global GPU or system metrics. > > On the other hand it shows clients from all DRM cards which > intel_gpu_top does not do. > > Signed-off-by: Tvrtko Ursulin > Cc: Rob Clark > Cc: Christian König > Acked-by: Christian König Tested-by: Philipp Zabel on etnaviv with [1]. [1] https://lore.kernel.org/dri-devel/20220916151205.165687-3-l.st...@pengutronix.de/ regards Philipp
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Never return 0 on timeout when retiring requests
On 16.11.2022 12:25, Janusz Krzysztofik wrote:
Users of intel_gt_retire_requests_timeout() expect 0 return value on
success. However, we have no protection from passing back 0 potentially
returned by dma_fence_wait_timeout() on timeout.
Replace 0 with -ETIME before using timeout as return value.
Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request")
Signed-off-by: Janusz Krzysztofik
Cc: sta...@vger.kernel.org # v5.5+
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index ccaf2fd80625b..ac6b2b1861397 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -213,6 +213,9 @@ out_active: spin_lock(&timelines->lock);
list_for_each_entry_safe(tl, tn, &free, link)
__intel_timeline_free(&tl->kref);
+ if (!timeout)
+ timeout = -ETIME;
+
Reviewed-by: Andrzej Hajda
Regards
Andrzej
if (flush_submission(gt, timeout)) /* Wait, there's more! */
active_count++;
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Never return 0 if request wait succeeds
On 16.11.2022 12:25, Janusz Krzysztofik wrote:
According to the docs of i915_request_wait_timeout(), its return value
"may be zero if the request is unfinished after the timeout expires."
However, 0 is also returned when the request is found finished right
after the timeout has expired.
Since the docs also state: "If the timeout is 0, it will return 1 if the
fence is signaled.", return 1 also when the fence is found signaled after
non-zero timeout has expired.
As I understand the patch "drm/i915: Fix i915_request fence wait
semantics", and the docs "timeout is 0" means the initial value of
timeout argument and this is handled already on the beginning of the
function.
In case initial timeout is greater than zero and then it expires,
function should return 0 regardless of fence state. This is what I have
understood from reading docs and implementation of
dma_fence_default_wait [1], which should be the best source of info
about "dma_fence wait semantic".
As I said already, mixing remaining time and bool in return value of
dma_fence_wait* functions is very confusing, but changing it would
require major rework of the framework.
[1]:
https://elixir.bootlin.com/linux/latest/source/drivers/dma-buf/dma-fence.c#L753
Regards
Andrzej
Fixes: 7e2e69ed4678 ("drm/i915: Fix i915_request fence wait semantics")
Signed-off-by: Janusz Krzysztofik
Cc: sta...@vger.kernel.org # v5.17
---
drivers/gpu/drm/i915/i915_request.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index f949a9495758a..406ddfafbed4d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -2079,6 +2079,8 @@ long i915_request_wait_timeout(struct i915_request *rq,
timeout = io_schedule_timeout(timeout);
}
+ if (!timeout) /* expired but signaled, we shouldn't return 0 */
+ timeout = 1;
__set_current_state(TASK_RUNNING);
if (READ_ONCE(wait.tsk))
[Intel-gfx] [PATCH 1/3] drm/i915/display: Add missing checks for cdclk crawling
cdclk_sanitize() function was written assuming vco was a signed integer.
vco gets assigned to -1 (essentially ~0) for the case where PLL
might be enabled and vco is not a frequency that will ever
get used. In such a scenario the right thing to do is disable the
PLL and re-enable it again with a valid frequency.
However the vco is declared as a unsigned variable.
With the above assumption, driver takes crawl path when not needed.
Add explicit check to not crawl in the case of an invalid PLL.
v2: Move the check from .h to .c (MattR)
- Move check to bxt_set_cdclk() instead of
intel_modeset_calc_cdclk() which is directly in
the path of the sanitize() function (Ville)
v3: remove unwanted parenthesis(Ville)
Cc: Ville Syrjälä
Cc: Matt Roper
Suggested-by: Ville Syrjälä
Signed-off-by: Anusha Srivatsa
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index b74e36d76013..25d01271dc09 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1717,6 +1717,16 @@ static void dg2_cdclk_squash_program(struct
drm_i915_private *i915,
intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl);
}
+static bool cdclk_pll_is_unknown(unsigned int vco)
+{
+ /*
+* Ensure driver does not take the crawl path for the
+* case when the vco is set to ~0 in the
+* sanitize path.
+*/
+ return vco == ~0;
+}
+
static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
const struct intel_cdclk_config *cdclk_config,
enum pipe pipe)
@@ -1749,7 +1759,8 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
return;
}
- if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 &&
vco > 0) {
+ if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 &&
vco > 0 &&
+ !cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
if (dev_priv->display.cdclk.hw.vco != vco)
adlp_cdclk_pll_crawl(dev_priv, vco);
} else if (DISPLAY_VER(dev_priv) >= 11)
--
2.25.1
[Intel-gfx] [PATCH 3/3] drm/i915/display: Add CDCLK Support for MTL
As per bSpec MTL has 38.4 MHz Reference clock.
Adding the cdclk tables and cdclk_funcs that MTL
will use.
v2: Revert to using bxt_get_cdclk()
BSpec: 65243
Cc: Clint Taylor
Signed-off-by: Anusha Srivatsa
Reviewed-by: Clint Taylor
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 6e122d56428c..6694e83287d9 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1346,6 +1346,16 @@ static const struct intel_cdclk_vals dg2_cdclk_table[] =
{
{}
};
+static const struct intel_cdclk_vals mtl_cdclk_table[] = {
+ { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 16,
.waveform = 0xad5a },
+ { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 16,
.waveform = 0xb6b6 },
+ { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16,
.waveform = 0x },
+ { .refclk = 38400, .cdclk = 48, .divider = 2, .ratio = 25,
.waveform = 0x },
+ { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29,
.waveform = 0x },
+ { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34,
.waveform = 0x },
+ {}
+};
+
static int bxt_calc_cdclk(struct drm_i915_private *dev_priv, int min_cdclk)
{
const struct intel_cdclk_vals *table = dev_priv->display.cdclk.table;
@@ -3184,6 +3194,13 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
return freq;
}
+static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
+ .get_cdclk = bxt_get_cdclk,
+ .set_cdclk = bxt_set_cdclk,
+ .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
+ .calc_voltage_level = tgl_calc_voltage_level,
+};
+
static const struct intel_cdclk_funcs tgl_cdclk_funcs = {
.get_cdclk = bxt_get_cdclk,
.set_cdclk = bxt_set_cdclk,
@@ -3319,7 +3336,10 @@ static const struct intel_cdclk_funcs i830_cdclk_funcs =
{
*/
void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
{
- if (IS_DG2(dev_priv)) {
+ if (IS_METEORLAKE(dev_priv)) {
+ dev_priv->display.funcs.cdclk = &mtl_cdclk_funcs;
+ dev_priv->display.cdclk.table = mtl_cdclk_table;
+ } else if (IS_DG2(dev_priv)) {
dev_priv->display.funcs.cdclk = &tgl_cdclk_funcs;
dev_priv->display.cdclk.table = dg2_cdclk_table;
} else if (IS_ALDERLAKE_P(dev_priv)) {
--
2.25.1
[Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
From: Ville Syrjälä
For MTL, changing cdclk from between certain frequencies has
both squash and crawl. Use the current cdclk config and
the new(desired) cdclk config to construtc a mid cdclk config.
Set the cdclk twice:
- Current cdclk -> mid cdclk
- mid cdclk -> desired cdclk
Driver should not take some Pcode mailbox communication
in the cdclk path for platforms that are Display 14 and later.
v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
change via modeset for platforms that support squash_crawl sequences(Ville)
v3: Add checks for:
- scenario where only slow clock is used and
cdclk is actually 0 (bringing up display).
- PLLs are on before looking up the waveform.
- Squash and crawl capability checks.(Ville)
v4: Rebase
- Move checks to be more consistent (Ville)
- Add comments (Bala)
v5:
- Further small changes. Move checks around.
- Make if-else better looking (Ville)
v6: MTl should not follow PUnit mailbox communication as the rest of
gen11+ platforms.(Anusha)
Cc: Clint Taylor
Cc: Balasubramani Vivekanandan
Signed-off-by: Anusha Srivatsa
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 175 +
1 file changed, 144 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 25d01271dc09..6e122d56428c 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1727,37 +1727,75 @@ static bool cdclk_pll_is_unknown(unsigned int vco)
return vco == ~0;
}
-static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
- const struct intel_cdclk_config *cdclk_config,
- enum pipe pipe)
+static int cdclk_squash_divider(u16 waveform)
+{
+ return hweight16(waveform ?: 0x);
+}
+
+static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
*i915,
+ const struct
intel_cdclk_config *old_cdclk_config,
+ const struct
intel_cdclk_config *new_cdclk_config,
+ struct intel_cdclk_config
*mid_cdclk_config)
+{
+ u16 old_waveform, new_waveform, mid_waveform;
+ int size = 16;
+ int div = 2;
+
+ /* Return if both Squash and Crawl are not present */
+ if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
+ return false;
+
+ old_waveform = cdclk_squash_waveform(i915, old_cdclk_config->cdclk);
+ new_waveform = cdclk_squash_waveform(i915, new_cdclk_config->cdclk);
+
+ /* Return if Squash only or Crawl only is the desired action */
+ if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
+ old_cdclk_config->vco == new_cdclk_config->vco ||
+ old_waveform == new_waveform)
+ return false;
+
+ *mid_cdclk_config = *new_cdclk_config;
+
+ /*
+* Populate the mid_cdclk_config accordingly.
+* - If moving to a higher cdclk, the desired action is squashing.
+* The mid cdclk config should have the new (squash) waveform.
+* - If moving to a lower cdclk, the desired action is crawling.
+* The mid cdclk config should have the new vco.
+*/
+
+ if (cdclk_squash_divider(new_waveform) >
cdclk_squash_divider(old_waveform)) {
+ mid_cdclk_config->vco = old_cdclk_config->vco;
+ mid_waveform = new_waveform;
+ } else {
+ mid_cdclk_config->vco = new_cdclk_config->vco;
+ mid_waveform = old_waveform;
+ }
+
+ mid_cdclk_config->cdclk =
DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
+ mid_cdclk_config->vco, size
* div);
+
+ /* make sure the mid clock came out sane */
+
+ drm_WARN_ON(&i915->drm, mid_cdclk_config->cdclk <
+ min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
+ drm_WARN_ON(&i915->drm, mid_cdclk_config->cdclk >
+ i915->display.cdclk.max_cdclk_freq);
+ drm_WARN_ON(&i915->drm, cdclk_squash_waveform(i915,
mid_cdclk_config->cdclk) !=
+ mid_waveform);
+
+ return true;
+}
+
+static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
+ const struct intel_cdclk_config *cdclk_config,
+ enum pipe pipe)
{
int cdclk = cdclk_config->cdclk;
int vco = cdclk_config->vco;
u32 val;
u16 waveform;
int clock;
- int ret;
-
- /* Inform power controller of upcoming frequency change. */
- if (DISPLAY_VER(dev_priv) >= 11)
- ret = skl_pcode_request(&dev_priv->uncore,
SKL_PCODE_CDCLK_CONTROL,
- SKL_CDCLK_PREPARE_FOR_CHANGE,
- SKL_CDCLK_READY_FOR_CHANGE,
-
[Intel-gfx] [PATCH] drm/i915/edp: wait power off delay at driver remove to optimize probe
Panel power off delay is the time the panel power needs to remain off
after being switched off, before it can be switched on again.
For the purpose of respecting panel power off delay at driver probe,
assuming the panel was last switched off at driver probe is overly
pessimistic. If the panel was never on, we'd end up waiting for no
reason.
We don't know what has happened before kernel boot, but we can make some
assumptions:
- The panel may have been switched off right before kernel boot by some
pre-os environment.
- After kernel boot, the panel may only be switched off by i915.
- At i915 driver probe, only a previously loaded and removed i915 may
have switched the panel power off.
With these assumptions, we can initialize the last power off time to
kernel boot time, if we also ensure i915 driver remove waits for the
panel power off delay after switching panel power off.
This shaves off the time it takes from kernel boot to i915 probe from
the first panel enable, if (and only if) the panel was not already
enabled at boot.
The encoder destroy hook is pretty much the last place where we can
wait, right after we've ensured the panel power has been switched off,
and before the whole encode is destroyed.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7417
Cc: Lee Shawn C
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
drivers/gpu/drm/i915/display/intel_pps.c | 8 +++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 914161d7d122..67089711d9e2 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4877,6 +4877,12 @@ void intel_dp_encoder_flush_work(struct drm_encoder
*encoder)
intel_pps_vdd_off_sync(intel_dp);
+ /*
+* Ensure power off delay is respected on module remove, so that we can
+* reduce delays at driver probe. See pps_init_timestamps().
+*/
+ intel_pps_wait_power_cycle(intel_dp);
+
intel_dp_aux_fini(intel_dp);
}
diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
b/drivers/gpu/drm/i915/display/intel_pps.c
index 81ee7f3aadf6..9bbf41a076f7 100644
--- a/drivers/gpu/drm/i915/display/intel_pps.c
+++ b/drivers/gpu/drm/i915/display/intel_pps.c
@@ -1100,7 +1100,13 @@ bool intel_pps_have_panel_power_or_vdd(struct intel_dp
*intel_dp)
static void pps_init_timestamps(struct intel_dp *intel_dp)
{
- intel_dp->pps.panel_power_off_time = ktime_get_boottime();
+ /*
+* Initialize panel power off time to 0, assuming panel power could have
+* been toggled between kernel boot and now only by a previously loaded
+* and removed i915, which has already ensured sufficient power off
+* delay at module remove.
+*/
+ intel_dp->pps.panel_power_off_time = 0;
intel_dp->pps.last_power_on = jiffies;
intel_dp->pps.last_backlight_off = jiffies;
}
--
2.34.1
Re: [Intel-gfx] [v4] drm/i915/pps: improve eDP power on flow
On Mon, 14 Nov 2022, Lee Shawn C wrote:
> After i915 dirver initialized, a panel power off cycle delay
> always append before turn eDP on. If eDP display did not
> power on before. With this change, power off duration might
> longer than power cycle delay. So driver can save power cycle
> delay to speed up driver initialization time.
>
> v2: fix commit messages
> v3: refine panel_power_off_time default value and modify
> commit messages
> v4: add eDP power off cycle delay at the path to unload i915 module
>
> Cc: Shankar Uma
> Cc: Jani Nikula
> Cc: Ville Syrjälä
> Signed-off-by: Lee Shawn C
> ---
> drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
> drivers/gpu/drm/i915/i915_driver.c | 4
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 81ee7f3aadf6..ab4118b38120 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -1100,7 +1100,7 @@ bool intel_pps_have_panel_power_or_vdd(struct intel_dp
> *intel_dp)
>
> static void pps_init_timestamps(struct intel_dp *intel_dp)
> {
> - intel_dp->pps.panel_power_off_time = ktime_get_boottime();
> + intel_dp->pps.panel_power_off_time = 0;
> intel_dp->pps.last_power_on = jiffies;
> intel_dp->pps.last_backlight_off = jiffies;
> }
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index c3d43f9b1e45..0e3cbd129055 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -107,6 +107,8 @@ static const char irst_name[] = "INT3392";
>
> static const struct drm_driver i915_drm_driver;
>
> +static void intel_shutdown_encoders(struct drm_i915_private *dev_priv);
> +
> static void i915_release_bridge_dev(struct drm_device *dev,
> void *bridge)
> {
> @@ -796,6 +798,8 @@ static void i915_driver_unregister(struct
> drm_i915_private *dev_priv)
>
> intel_display_driver_unregister(dev_priv);
>
> + intel_shutdown_encoders(dev_priv);
> +
Per Ville's comments on IRC, this is still too early. See [1] for
another approach.
BR,
Jani.
[1]
https://patchwork.freedesktop.org/patch/msgid/20221116150657.1347504-1-jani.nik...@intel.com
> for_each_gt(gt, dev_priv, i)
> intel_gt_driver_unregister(gt);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Never return 0 if request wait succeeds
On Wednesday, 16 November 2022 15:42:46 CET Andrzej Hajda wrote:
> On 16.11.2022 12:25, Janusz Krzysztofik wrote:
> > According to the docs of i915_request_wait_timeout(), its return value
> > "may be zero if the request is unfinished after the timeout expires."
> > However, 0 is also returned when the request is found finished right
> > after the timeout has expired.
> >
> > Since the docs also state: "If the timeout is 0, it will return 1 if the
> > fence is signaled.", return 1 also when the fence is found signaled after
> > non-zero timeout has expired.
>
> As I understand the patch "drm/i915: Fix i915_request fence wait
> semantics", and the docs "timeout is 0" means the initial value of
> timeout argument and this is handled already on the beginning of the
> function.
> In case initial timeout is greater than zero and then it expires,
> function should return 0 regardless of fence state. This is what I have
> understood from reading docs and implementation of
> dma_fence_default_wait [1], which should be the best source of info
> about "dma_fence wait semantic".
>
> As I said already, mixing remaining time and bool in return value of
> dma_fence_wait* functions is very confusing, but changing it would
> require major rework of the framework.
OK, let's drop this controversial patch. The corner case it touches should
already be handled correctly by intel_gt_retire_requests_timeout(), which this
series is about, after 1/3 and 2/3 are applied.
Thanks,
Janusz
>
> [1]:
> https://elixir.bootlin.com/linux/latest/source/drivers/dma-buf/dma-fence.c#L753
>
> Regards
> Andrzej
>
> >
> > Fixes: 7e2e69ed4678 ("drm/i915: Fix i915_request fence wait semantics")
> > Signed-off-by: Janusz Krzysztofik
> > Cc: sta...@vger.kernel.org # v5.17
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index f949a9495758a..406ddfafbed4d 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -2079,6 +2079,8 @@ long i915_request_wait_timeout(struct i915_request
> > *rq,
> >
> > timeout = io_schedule_timeout(timeout);
> > }
> > + if (!timeout) /* expired but signaled, we shouldn't return 0 */
> > + timeout = 1;
> > __set_current_state(TASK_RUNNING);
> >
> > if (READ_ONCE(wait.tsk))
>
>
Re: [Intel-gfx] [v4] drm/i915/pps: improve eDP power on flow
On Wednesday, November 16, 2022 11:45 PM, Jani Nikula
wrote:
>On Mon, 14 Nov 2022, Lee Shawn C wrote:
>> After i915 dirver initialized, a panel power off cycle delay always
>> append before turn eDP on. If eDP display did not power on before.
>> With this change, power off duration might longer than power cycle
>> delay. So driver can save power cycle delay to speed up driver
>> initialization time.
>>
>> v2: fix commit messages
>> v3: refine panel_power_off_time default value and modify
>> commit messages
>> v4: add eDP power off cycle delay at the path to unload i915 module
>>
>> Cc: Shankar Uma
>> Cc: Jani Nikula
>> Cc: Ville Syrjälä
>> Signed-off-by: Lee Shawn C
>> ---
>> drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
>> drivers/gpu/drm/i915/i915_driver.c | 4
>> 2 files changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
>> b/drivers/gpu/drm/i915/display/intel_pps.c
>> index 81ee7f3aadf6..ab4118b38120 100644
>> --- a/drivers/gpu/drm/i915/display/intel_pps.c
>> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
>> @@ -1100,7 +1100,7 @@ bool intel_pps_have_panel_power_or_vdd(struct
>> intel_dp *intel_dp)
>>
>> static void pps_init_timestamps(struct intel_dp *intel_dp) {
>> -intel_dp->pps.panel_power_off_time = ktime_get_boottime();
>> +intel_dp->pps.panel_power_off_time = 0;
>> intel_dp->pps.last_power_on = jiffies;
>> intel_dp->pps.last_backlight_off = jiffies; } diff --git
>> a/drivers/gpu/drm/i915/i915_driver.c
>> b/drivers/gpu/drm/i915/i915_driver.c
>> index c3d43f9b1e45..0e3cbd129055 100644
>> --- a/drivers/gpu/drm/i915/i915_driver.c
>> +++ b/drivers/gpu/drm/i915/i915_driver.c
>> @@ -107,6 +107,8 @@ static const char irst_name[] = "INT3392";
>>
>> static const struct drm_driver i915_drm_driver;
>>
>> +static void intel_shutdown_encoders(struct drm_i915_private
>> +*dev_priv);
>> +
>> static void i915_release_bridge_dev(struct drm_device *dev,
>> void *bridge)
>> {
>> @@ -796,6 +798,8 @@ static void i915_driver_unregister(struct
>> drm_i915_private *dev_priv)
>>
>> intel_display_driver_unregister(dev_priv);
>>
>> +intel_shutdown_encoders(dev_priv);
>> +
>
>Per Ville's comments on IRC, this is still too early. See [1] for another
>approach.
>
>BR,
>Jani.
>
Thank you! I've tested this patch and it works properly. Detail kernel log is
attached on [2].
Please help to review and merge that patch ASAP.
Best regards,
Shawn
>
>[1]
>https://patchwork.freedesktop.org/patch/msgid/20221116150657.1347504-1-jani.nik...@intel.com
[2] https://gitlab.freedesktop.org/drm/intel/-/issues/7417#note_1643009
>
>
>> for_each_gt(gt, dev_priv, i)
>> intel_gt_driver_unregister(gt);
>
>--
>Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/guc: add the GSC CS to the GuC capture list
I'm assuming that you have verified that the GuC ADS code is calling for the
registration of the GSC capture register
list accordingly and for the correct tile. That said:
Reviewed-by: Alan Previn
On Thu, 2022-11-10 at 16:18 -0800, Ceraolo Spurio, Daniele wrote:
> For the GSC engine we only want to capture the instance regs.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Alan Previn
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> index 4e6dca707d94..1d49a7ec0bd8 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c
> @@ -132,6 +132,11 @@ static const struct __guc_mmio_reg_descr
> xe_lpd_blt_inst_regs[] = {
> COMMON_BASE_ENGINE_INSTANCE,
> };
>
> +/* XE_LPD - GSC Per-Engine-Instance */
> +static const struct __guc_mmio_reg_descr xe_lpd_gsc_inst_regs[] = {
> + COMMON_BASE_ENGINE_INSTANCE,
> +};
> +
> /* GEN9 - Global */
> static const struct __guc_mmio_reg_descr default_global_regs[] = {
> COMMON_BASE_GLOBAL,
> @@ -177,6 +182,8 @@ static struct __guc_mmio_reg_descr_group default_lists[]
> = {
> MAKE_REGLIST(xe_lpd_vec_inst_regs, PF, ENGINE_INSTANCE,
> GUC_VIDEOENHANCE_CLASS),
> MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_BLITTER_CLASS),
> MAKE_REGLIST(xe_lpd_blt_inst_regs, PF, ENGINE_INSTANCE,
> GUC_BLITTER_CLASS),
> + MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_GSC_OTHER_CLASS),
> + MAKE_REGLIST(xe_lpd_gsc_inst_regs, PF, ENGINE_INSTANCE,
> GUC_GSC_OTHER_CLASS),
> {}
> };
>
> @@ -192,6 +199,8 @@ static const struct __guc_mmio_reg_descr_group
> xe_lpd_lists[] = {
> MAKE_REGLIST(xe_lpd_vec_inst_regs, PF, ENGINE_INSTANCE,
> GUC_VIDEOENHANCE_CLASS),
> MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_BLITTER_CLASS),
> MAKE_REGLIST(xe_lpd_blt_inst_regs, PF, ENGINE_INSTANCE,
> GUC_BLITTER_CLASS),
> + MAKE_REGLIST(empty_regs_list, PF, ENGINE_CLASS, GUC_GSC_OTHER_CLASS),
> + MAKE_REGLIST(xe_lpd_gsc_inst_regs, PF, ENGINE_INSTANCE,
> GUC_GSC_OTHER_CLASS),
> {}
> };
>
> @@ -454,6 +463,8 @@ __stringify_engclass(u32 class)
> return "Blitter";
> case GUC_COMPUTE_CLASS:
> return "Compute";
> + case GUC_GSC_OTHER_CLASS:
> + return "GSC-Other";
> default:
> break;
> }
> --
> 2.37.3
>
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: Enable Idle Messaging for GSC CS
On 11/15/2022 5:44 AM, Badal Nilawar wrote:
From: Vinay Belgaumkar
By defaut idle mesaging is disabled for GSC CS so to unblock RC6
entry on media tile idle messaging need to be enabled.
v2:
- Fix review comments (Vinay)
- Set GSC idle hysterisis to 5 us (Badal)
Bspec: 71496
Cc: Daniele Ceraolo Spurio
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 18 ++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index b0a4a2dbe3ee..5522885b2db0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -15,6 +15,22 @@
#include "intel_rc6.h"
#include "intel_ring.h"
#include "shmem_utils.h"
+#include "intel_gt_regs.h"
+
+static void intel_gsc_idle_msg_enable(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ if (IS_METEORLAKE(i915) && engine->id == GSC0) {
+ intel_uncore_write(engine->gt->uncore,
+ RC_PSMI_CTRL_GSCCS,
+ _MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
+ /* 5 us hysterisis */
+ intel_uncore_write(engine->gt->uncore,
+ PWRCTX_MAXCNT_GSCCS,
+ 0xA);
+ }
+}
static void dbg_poison_ce(struct intel_context *ce)
{
@@ -275,6 +291,8 @@ void intel_engine_init__pm(struct intel_engine_cs *engine)
intel_wakeref_init(&engine->wakeref, rpm, &wf_ops);
intel_engine_init_heartbeat(engine);
+
+ intel_gsc_idle_msg_enable(engine);
}
/**
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 07031e03f80c..20472eb15364 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -913,6 +913,10 @@
#define MSG_IDLE_FW_MASK REG_GENMASK(13, 9)
#define MSG_IDLE_FW_SHIFT9
+#define RC_PSMI_CTRL_GSCCS _MMIO(0x11a050)
Alignment still seems off? Other than that,
Reviewed-by: Vinay Belgaumkar
+#define IDLE_MSG_DISABLE BIT(0)
+#define PWRCTX_MAXCNT_GSCCS_MMIO(0x11a054)
+
#define FORCEWAKE_MEDIA_GEN9 _MMIO(0xa270)
#define FORCEWAKE_RENDER_GEN9 _MMIO(0xa278)
Re: [Intel-gfx] [RESEND] drm/edid/firmware: stop using a throwaway platform device
Thank you everyone for your work!
Matthieu.
On Wed, Nov 16 2022 at 03:32:01 PM +0200, Jani Nikula
wrote:
On Wed, 16 Nov 2022, Thomas Zimmermann wrote:
Hi
Am 14.11.22 um 12:17 schrieb Jani Nikula:
We've used a temporary platform device for firmware EDID loading
since
it was introduced in commit da0df92b5731 ("drm: allow loading an
EDID as
firmware to override broken monitor"), but there's no explanation
why.
Using a temporary device does not play well with CONFIG_FW_CACHE=y,
which caches firmware images (e.g. on suspend) so that drivers can
request firmware when the system is not ready for it, and return
the
images from the cache (e.g. during resume). This works
automatically for
regular devices, but obviously not for a temporarily created
device.
Stop using the throwaway platform device, and use the drm device
instead.
Note that this may still be problematic for cases where the
display was
plugged in during suspend, and the firmware wasn't loaded and
therefore
not cached before suspend.
References:
https://lore.kernel.org/r/20220727074152.43059-1-matthieu.chare...@gmail.com
Closes: https://gitlab.freedesktop.org/drm/amd/-/issues/2061
Reported-by: Matthieu CHARETTE
Tested-by: Matthieu CHARETTE
Cc: Ville Syrjälä
Signed-off-by: Jani Nikula
Acked-by: Thomas Zimmermann
I looked through request_firmware() but did not see any signs that
it
somehow depends on a platform device. I assume that this might only
affect the device name in the error message.
Thanks, pushed to drm-misc-next.
Matthieu, thanks for you patience and the report as well!
BR,
Jani.
Best regards
Thomas
---
Resend with a proper commit message; patch itself is unchanged.
---
drivers/gpu/drm/drm_edid_load.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid_load.c
b/drivers/gpu/drm/drm_edid_load.c
index ef4ab59d6935..5d9ef267ebb3 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -172,20 +172,9 @@ static const struct drm_edid
*edid_load(struct drm_connector *connector, const c
fwdata = generic_edid[builtin];
fwsize = sizeof(generic_edid[builtin]);
} else {
- struct platform_device *pdev;
int err;
- pdev = platform_device_register_simple(connector->name, -1,
NULL, 0);
- if (IS_ERR(pdev)) {
- drm_err(connector->dev,
-"[CONNECTOR:%d:%s] Failed to register EDID firmware platform
device for connector \"%s\"\n",
- connector->base.id, connector->name,
- connector->name);
- return ERR_CAST(pdev);
- }
-
- err = request_firmware(&fw, name, &pdev->dev);
- platform_device_unregister(pdev);
+ err = request_firmware(&fw, name, connector->dev->dev);
if (err) {
drm_err(connector->dev,
"[CONNECTOR:%d:%s] Requesting EDID firmware \"%s\" failed
(err=%d)\n",
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/edp: wait power off delay at driver remove to optimize probe
On Wed, Nov 16, 2022 at 05:06:57PM +0200, Jani Nikula wrote:
> Panel power off delay is the time the panel power needs to remain off
> after being switched off, before it can be switched on again.
>
> For the purpose of respecting panel power off delay at driver probe,
> assuming the panel was last switched off at driver probe is overly
> pessimistic. If the panel was never on, we'd end up waiting for no
> reason.
>
> We don't know what has happened before kernel boot, but we can make some
> assumptions:
>
> - The panel may have been switched off right before kernel boot by some
> pre-os environment.
>
> - After kernel boot, the panel may only be switched off by i915.
>
> - At i915 driver probe, only a previously loaded and removed i915 may
> have switched the panel power off.
>
> With these assumptions, we can initialize the last power off time to
> kernel boot time, if we also ensure i915 driver remove waits for the
> panel power off delay after switching panel power off.
>
> This shaves off the time it takes from kernel boot to i915 probe from
> the first panel enable, if (and only if) the panel was not already
> enabled at boot.
>
> The encoder destroy hook is pretty much the last place where we can
> wait, right after we've ensured the panel power has been switched off,
> and before the whole encode is destroyed.
Yeah, the fact that we have the vdd_off_sync() in there at least
theoretically means the vdd might be on at any point before that.
I was also pondering about doing this for all encoder types.
Though the benefits are slightly less pronounced I guess:
a) we don't need to power the panel for the output probe on those,
so a bit more time will have elapsed anyway before we have to
power the panel on during the first modeset
b) for LVDS we rely 100% on the pps state machine so the initial
boot case is already as optimal as possible. Adding the explicit
wait into the unload path could thus only help the speed of
of the first modeset during module reload
But maybe we'd stil want to do that, for consistency if nothing else?
Either way, this patch is
Reviewed-by: Ville Syrjälä
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7417
> Cc: Lee Shawn C
> Cc: Ville Syrjälä
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 6 ++
> drivers/gpu/drm/i915/display/intel_pps.c | 8 +++-
> 2 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 914161d7d122..67089711d9e2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4877,6 +4877,12 @@ void intel_dp_encoder_flush_work(struct drm_encoder
> *encoder)
>
> intel_pps_vdd_off_sync(intel_dp);
>
> + /*
> + * Ensure power off delay is respected on module remove, so that we can
> + * reduce delays at driver probe. See pps_init_timestamps().
> + */
> + intel_pps_wait_power_cycle(intel_dp);
> +
> intel_dp_aux_fini(intel_dp);
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_pps.c
> b/drivers/gpu/drm/i915/display/intel_pps.c
> index 81ee7f3aadf6..9bbf41a076f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_pps.c
> +++ b/drivers/gpu/drm/i915/display/intel_pps.c
> @@ -1100,7 +1100,13 @@ bool intel_pps_have_panel_power_or_vdd(struct intel_dp
> *intel_dp)
>
> static void pps_init_timestamps(struct intel_dp *intel_dp)
> {
> - intel_dp->pps.panel_power_off_time = ktime_get_boottime();
> + /*
> + * Initialize panel power off time to 0, assuming panel power could have
> + * been toggled between kernel boot and now only by a previously loaded
> + * and removed i915, which has already ensured sufficient power off
> + * delay at module remove.
> + */
> + intel_dp->pps.panel_power_off_time = 0;
> intel_dp->pps.last_power_on = jiffies;
> intel_dp->pps.last_backlight_off = jiffies;
> }
> --
> 2.34.1
--
Ville Syrjälä
Intel
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/ttm: Clean up page shift operation
== Series Details ==
Series: series starting with [1/2] drm/ttm: Clean up page shift operation
URL : https://patchwork.freedesktop.org/series/110957/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12389 -> Patchwork_110957v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/index.html
Participating hosts (40 -> 41)
--
Additional (1): bat-atsm-1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110957v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@requests:
- {bat-adlm-1}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/bat-adlm-1/igt@i915_selftest@l...@requests.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/bat-adlm-1/igt@i915_selftest@l...@requests.html
Known issues
Here are the changes found in Patchwork_110957v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_selftest@live@execlists:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][4] ([i915#7156])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][5] -> [INCOMPLETE][6] ([i915#4418])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827]) +8
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_psr@sprite_plane_onoff:
- fi-apl-guc: NOTRUN -> [SKIP][8] ([fdo#109271]) +11 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/fi-apl-guc/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- bat-dg1-6: NOTRUN -> [FAIL][9] ([i915#4312])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/bat-dg1-6/igt@run...@aborted.html
Possible fixes
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [INCOMPLETE][10] ([i915#7056]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: [DMESG-WARN][12] ([i915#1982]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/fi-kbl-soraka/igt@i915_module_l...@reload.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka: [INCOMPLETE][14] ([i915#7099]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@gt_engines:
- {bat-dg1-7}:[INCOMPLETE][16] ([i915#4418]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/bat-dg1-7/igt@i915_selftest@live@gt_engines.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/bat-dg1-7/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [DMESG-FAIL][18] ([i915#5334]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1836]: https://gitlab.freed
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
On Wed, Nov 16, 2022 at 06:50:07AM -0800, Anusha Srivatsa wrote:
> From: Ville Syrjälä
>
> For MTL, changing cdclk from between certain frequencies has
> both squash and crawl. Use the current cdclk config and
> the new(desired) cdclk config to construtc a mid cdclk config.
> Set the cdclk twice:
> - Current cdclk -> mid cdclk
> - mid cdclk -> desired cdclk
>
> Driver should not take some Pcode mailbox communication
> in the cdclk path for platforms that are Display 14 and later.
Nit: display _version_ 14 and later.
>
> v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
> change via modeset for platforms that support squash_crawl sequences(Ville)
>
> v3: Add checks for:
> - scenario where only slow clock is used and
> cdclk is actually 0 (bringing up display).
> - PLLs are on before looking up the waveform.
> - Squash and crawl capability checks.(Ville)
>
> v4: Rebase
> - Move checks to be more consistent (Ville)
> - Add comments (Bala)
> v5:
> - Further small changes. Move checks around.
> - Make if-else better looking (Ville)
>
> v6: MTl should not follow PUnit mailbox communication as the rest of
> gen11+ platforms.(Anusha)
>
> Cc: Clint Taylor
> Cc: Balasubramani Vivekanandan
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 175 +
> 1 file changed, 144 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 25d01271dc09..6e122d56428c 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1727,37 +1727,75 @@ static bool cdclk_pll_is_unknown(unsigned int vco)
> return vco == ~0;
> }
>
> -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> - const struct intel_cdclk_config *cdclk_config,
> - enum pipe pipe)
> +static int cdclk_squash_divider(u16 waveform)
> +{
> + return hweight16(waveform ?: 0x);
> +}
> +
> +static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
> *i915,
> + const struct
> intel_cdclk_config *old_cdclk_config,
> + const struct
> intel_cdclk_config *new_cdclk_config,
> + struct intel_cdclk_config
> *mid_cdclk_config)
> +{
> + u16 old_waveform, new_waveform, mid_waveform;
> + int size = 16;
> + int div = 2;
> +
> + /* Return if both Squash and Crawl are not present */
> + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> + return false;
> +
> + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config->cdclk);
> + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config->cdclk);
> +
> + /* Return if Squash only or Crawl only is the desired action */
> + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
We still have "<= 0" checks here. As noted before, the < part can never
evaluate to true since vco is an unsigned value. I think you meant to
update this to include a check with your new cdclk_pll_is_unknown()
helper?
Also, the comment above this check says "if squash only or crawl only is
the desired action" which is what the "==" conditions below cover. But
the vco 0/unknown checks are technically to ensure we bail out if the
desired action is to do neither of the two (traditional modeset).
> + old_cdclk_config->vco == new_cdclk_config->vco ||
> + old_waveform == new_waveform)
> + return false;
> +
> + *mid_cdclk_config = *new_cdclk_config;
> +
> + /*
> + * Populate the mid_cdclk_config accordingly.
> + * - If moving to a higher cdclk, the desired action is squashing.
> + * The mid cdclk config should have the new (squash) waveform.
> + * - If moving to a lower cdclk, the desired action is crawling.
> + * The mid cdclk config should have the new vco.
> + */
> +
> + if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> + mid_cdclk_config->vco = old_cdclk_config->vco;
> + mid_waveform = new_waveform;
> + } else {
> + mid_cdclk_config->vco = new_cdclk_config->vco;
> + mid_waveform = old_waveform;
> + }
> +
> + mid_cdclk_config->cdclk =
> DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
> + mid_cdclk_config->vco, size
> * div);
> +
> + /* make sure the mid clock came out sane */
> +
> + drm_WARN_ON(&i915->drm, mid_cdclk_config->cdclk <
> + min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
> + drm_WARN_ON(&i915->drm, mid_cdclk_config->cdclk >
> + i915->display.cdclk.max_cdclk_freq);
> + drm_WARN_ON(&i915->drm, cdclk_squash_waveform(i915,
> mid_cdclk_conf
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix timeout handling when retiring requests
== Series Details ==
Series: drm/i915: Fix timeout handling when retiring requests
URL : https://patchwork.freedesktop.org/series/110964/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12389 -> Patchwork_110964v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/index.html
Participating hosts (40 -> 39)
--
Missing(1): fi-pnv-d510
Known issues
Here are the changes found in Patchwork_110964v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#4613]) +3
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [PASS][2] -> [DMESG-WARN][3] ([i915#7077])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-6: [PASS][4] -> [INCOMPLETE][5] ([i915#4418])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/bat-dg1-6/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][6] -> [INCOMPLETE][7] ([i915#4785])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8
similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_psr@sprite_plane_onoff:
- fi-apl-guc: NOTRUN -> [SKIP][9] ([fdo#109271]) +11 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/fi-apl-guc/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][10] ([fdo#109271] / [i915#4312] /
[i915#5594])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/fi-hsw-4770/igt@run...@aborted.html
- bat-adlp-4: NOTRUN -> [FAIL][11] ([i915#4312])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/bat-adlp-4/igt@run...@aborted.html
- bat-dg1-6: NOTRUN -> [FAIL][12] ([i915#4312])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/bat-dg1-6/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-rpls-2}: [DMESG-WARN][13] ([i915#6434]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [INCOMPLETE][15] ([i915#7056]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@i915_module_load@reload:
- fi-kbl-soraka: [DMESG-WARN][17] ([i915#1982]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/fi-kbl-soraka/igt@i915_module_l...@reload.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/fi-kbl-soraka/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@module-reload:
- {bat-rpls-2}: [WARN][19] ([i915#7346]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/bat-rpls-2/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/bat-rpls-2/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@gt_engines:
- {bat-dg1-7}:[INCOMPLETE][21] ([i915#4418]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/bat-dg1-7/igt@i915_selftest@live@gt_engines.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/bat-dg1-7/igt@i915_selftest@live@gt_engines.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [DMESG-FAIL][23] ([i915#5334]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11096
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
> -Original Message-
> From: Roper, Matthew D
> Sent: Wednesday, November 16, 2022 10:44 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org; Vivekanandan, Balasubramani
>
> Subject: Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and
> squash when changing cdclk
>
> On Wed, Nov 16, 2022 at 06:50:07AM -0800, Anusha Srivatsa wrote:
> > From: Ville Syrjälä
> >
> > For MTL, changing cdclk from between certain frequencies has both
> > squash and crawl. Use the current cdclk config and the new(desired)
> > cdclk config to construtc a mid cdclk config.
> > Set the cdclk twice:
> > - Current cdclk -> mid cdclk
> > - mid cdclk -> desired cdclk
> >
> > Driver should not take some Pcode mailbox communication in the cdclk
> > path for platforms that are Display 14 and later.
>
> Nit: display _version_ 14 and later.
>
> >
> > v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk change via
> > modeset for platforms that support squash_crawl sequences(Ville)
> >
> > v3: Add checks for:
> > - scenario where only slow clock is used and cdclk is actually 0
> > (bringing up display).
> > - PLLs are on before looking up the waveform.
> > - Squash and crawl capability checks.(Ville)
> >
> > v4: Rebase
> > - Move checks to be more consistent (Ville)
> > - Add comments (Bala)
> > v5:
> > - Further small changes. Move checks around.
> > - Make if-else better looking (Ville)
> >
> > v6: MTl should not follow PUnit mailbox communication as the rest of
> > gen11+ platforms.(Anusha)
> >
> > Cc: Clint Taylor
> > Cc: Balasubramani Vivekanandan
>
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 175
> > +
> > 1 file changed, 144 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index 25d01271dc09..6e122d56428c 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1727,37 +1727,75 @@ static bool cdclk_pll_is_unknown(unsigned int
> vco)
> > return vco == ~0;
> > }
> >
> > -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> > - const struct intel_cdclk_config *cdclk_config,
> > - enum pipe pipe)
> > +static int cdclk_squash_divider(u16 waveform) {
> > + return hweight16(waveform ?: 0x); }
> > +
> > +static bool cdclk_compute_crawl_and_squash_midpoint(struct
> drm_i915_private *i915,
> > + const struct
> intel_cdclk_config *old_cdclk_config,
> > + const struct
> intel_cdclk_config *new_cdclk_config,
> > + struct intel_cdclk_config
> *mid_cdclk_config) {
> > + u16 old_waveform, new_waveform, mid_waveform;
> > + int size = 16;
> > + int div = 2;
> > +
> > + /* Return if both Squash and Crawl are not present */
> > + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> > + return false;
> > +
> > + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config-
> >cdclk);
> > + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config-
> >cdclk);
> > +
> > + /* Return if Squash only or Crawl only is the desired action */
> > + if (old_cdclk_config->vco <= 0 || new_cdclk_config->vco <= 0 ||
>
> We still have "<= 0" checks here. As noted before, the < part can never
> evaluate to true since vco is an unsigned value. I think you meant to update
> this to include a check with your new cdclk_pll_is_unknown() helper?
Argh. No the check here should just be vco==0. For the case ~0 or the signed
value, we have it covered in bxt_set_cdclk() where we end up not taking the
crawl path.
> Also, the comment above this check says "if squash only or crawl only is the
> desired action" which is what the "==" conditions below cover. But the vco
> 0/unknown checks are technically to ensure we bail out if the desired action
> is to do neither of the two (traditional modeset).
>
> > + old_cdclk_config->vco == new_cdclk_config->vco ||
> > + old_waveform == new_waveform)
> > + return false;
> > +
> > + *mid_cdclk_config = *new_cdclk_config;
> > +
> > + /*
> > +* Populate the mid_cdclk_config accordingly.
> > +* - If moving to a higher cdclk, the desired action is squashing.
> > +* The mid cdclk config should have the new (squash) waveform.
> > +* - If moving to a lower cdclk, the desired action is crawling.
> > +* The mid cdclk config should have the new vco.
> > +*/
> > +
> > + if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> > + mid_cdclk_config->vco = old_cdclk_config->vco;
> > + mid_waveform = new_waveform;
> > + } else {
> > + mid_cdclk_config->vco = new_cdclk_config->vco;
> > + mid_wavefo
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling
== Series Details == Series: series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling URL : https://patchwork.freedesktop.org/series/110970/ State : warning == Summary == Error: dim checkpatch failed 8b43fdea884d drm/i915/display: Add missing checks for cdclk crawling 0058d40d8134 drm/i915/display: Do both crawl and squash when changing cdclk -:61: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #61: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1736: + const struct intel_cdclk_config *old_cdclk_config, -:62: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #62: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1737: + const struct intel_cdclk_config *new_cdclk_config, -:170: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional statements (8, 26) #170: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1850: + if (DISPLAY_VER(dev_priv) >= 14) + /* NOOP */; -:201: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional statements (8, 19) #201: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1881: + if (DISPLAY_VER(dev_priv) >= 14) [...] +*/; total: 0 errors, 4 warnings, 0 checks, 214 lines checked b56ac994c40f drm/i915/display: Add CDCLK Support for MTL
Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT
just recapping offline conversation summary - we agreed on:
intel_pxp_enabled(i915)
intel_pxp_enabled_on_gt(pxp)
(where one is wrapper over the other, the action part of the function
name stays the same).
...alan
On Mon, 2022-11-14 at 21:13 -0800, Alan Previn Teres Alexis wrote:
>
> On Mon, 2022-11-14 at 20:00 -0800, Ceraolo Spurio, Daniele wrote:
> >
> > On 10/21/2022 10:39 AM, Alan Previn wrote:
> > > In preparation for future MTL-PXP feature support, PXP control
> > > @@ -142,22 +166,21 @@ void intel_pxp_init(struct intel_pxp *pxp)
> > > {
> > > struct intel_gt *gt = pxp_to_gt(pxp);
> > >
> > > - /* we rely on the mei PXP module */
> > > - if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
> > > - return;
> > > -
> > > /*
> > >* If HuC is loaded by GSC but PXP is disabled, we can skip the
> > > init of
> > >* the full PXP session/object management and just init the tee
> > > channel.
> > >*/
> > > - if (HAS_PXP(gt->i915))
> > > + if (_gt_supports_pxp(gt))
> > > pxp_init_full(pxp);
> > > - else if (intel_huc_is_loaded_by_gsc(>->uc.huc) &&
> > > intel_uc_uses_huc(>->uc))
> > > + else if (_gt_needs_teelink(gt))
> > > intel_pxp_tee_component_init(pxp);
> > > }
> > >
> > > void intel_pxp_fini(struct intel_pxp *pxp)
> > > {
> > > + if (!intel_gtpxp_is_supported(pxp))
> > > + return;
> >
> > Why do you need this? the fini below should already be smart enough to
> > only cleanup when needed.
> Eventually i plan to create a backend abstraction for tee based vs mtl's
> gscccs based and rather keep as much of the
> checking on the front end to keep it cleaner.
> >
> > > +
> > > pxp->arb_is_valid = false;
> > >
> > > intel_pxp_tee_component_fini(pxp);
> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > index 2da309088c6d..c12e4d419c78 100644
> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
> > > @@ -13,6 +13,8 @@ struct intel_pxp;
> > > struct drm_i915_gem_object;
> > >
> > > struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
> > > +bool intel_gtpxp_is_supported(struct intel_pxp *pxp);
> > > +
> > > bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
> > > bool intel_pxp_is_active(const struct intel_pxp *pxp);
> > >
> > > diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > > b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > > index 4359e8be4101..124663cf0047 100644
> > > --- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
> > > @@ -70,7 +70,7 @@ void intel_pxp_debugfs_register(struct intel_pxp *pxp,
> > > struct dentry *gt_root)
> > > if (!gt_root)
> > > return;
> > >
> > > - if (!HAS_PXP((pxp_to_gt(pxp)->i915)))
> > > + if (!intel_gtpxp_is_supported(pxp))
> > > return;
> > >
> >
> > This now returns true for DG2, but we don't want to register the PXP
> > debugfs there as we don't support PXP aside from HuC loading.
> >
>
> yeah - ok.
>
> > IMO a
> > better approach would be to have intel_gtpxp_is_supported be what you
> > currently have as _gt_supports_pxp().
> >
> Okay, let me take a look at that since i recall that future patches would
> rely on intel_gtpxp_is_supported for the case
> where PXP is not supported but we just want to know if GT has backend tee for
> component binding or something - but i
> guess that could get a separate function as opposed to reusing
> intel_gtpxp_is_supported.
>
>
> > Also, intel_gtpxp_is_supported is a bit confusing because of the new
> > "gtpxp" prefix. Why not use just intel_pxp_is_supported? We already have
> > per-gt checkers that refer only to the subcomponent, like
> > intel_huc_is_supported(), which for MTL is false on the primary GT and
> > true on the media one. I don't see why we can't do the same for PXP.
>
> I think that existing method isn't a good way - i rather use this opportunity
> to set a precendence for pxp we can have a
> more standardized naming convention based on the global-vs-per-gt level
> checking (i also wish i had time to look at
> "intra-vs-inter function naming). So when something is called with _pxp_ its
> meant to be called as a global check
> (passing in i915 as its param) and if its using _gtpxp_, then its meant to be
> called as gt-level checker. And the
> similar function name should be okay if the check is similar (just at
> different hierarchy level). I prefer my way
> because it allows that understanding purely from the function name as opposed
> to having to look at the full definition
> before knowing if its a global check vs a gt level check. I think we really
> ought to have a more concise naming
> convention as opposed to "we do it like this, so why not just follow". An
> alternative would be instead of
> "int
[Intel-gfx] ✓ Fi.CI.BAT: success for mei: add timeout to send (rev3)
== Series Details ==
Series: mei: add timeout to send (rev3)
URL : https://patchwork.freedesktop.org/series/110495/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12390 -> Patchwork_110495v3
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/index.html
Participating hosts (41 -> 38)
--
Additional (1): bat-atsm-1
Missing(4): bat-kbl-2 bat-jsl-3 bat-dg1-6 bat-dg1-5
Known issues
Here are the changes found in Patchwork_110495v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-4: NOTRUN -> [SKIP][1] ([i915#4613]) +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [PASS][2] -> [INCOMPLETE][3] ([i915#7056])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@i915_pm_rps@basic-api:
- bat-adlp-4: NOTRUN -> [SKIP][4] ([i915#6621])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@i915_pm_...@basic-api.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-adlp-4: NOTRUN -> [SKIP][6] ([fdo#111827])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlp-4: NOTRUN -> [SKIP][7] ([i915#3546])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html
* igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][8] ([fdo#109295] / [i915#3301] /
[i915#3708])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@prime_v...@basic-userptr.html
* igt@prime_vgem@basic-write:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@prime_v...@basic-write.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-rpls-2}: [INCOMPLETE][10] ([i915#6434]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-rpls-2/igt@i915_module_l...@reload.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-rpls-2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [DMESG-WARN][12] ([i915#7077]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][14] ([i915#4785]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-2:
- {bat-dg2-11}: [FAIL][16] -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-2.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-dg2-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-2.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1836]: https://gitlab.freedesktop.org/drm/intel/issues/1836
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3291]: https://gitlab.freedesktop.org/drm/intel/issues/3291
[i915#3301]: https://gitlab.freedesktop.org/drm/intel/issues/3301
[i915#3546]: https://gitlab.freedesktop.org/drm/intel/is
[Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
From: Ville Syrjälä
For MTL, changing cdclk from between certain frequencies has
both squash and crawl. Use the current cdclk config and
the new(desired) cdclk config to construct a mid cdclk config.
Set the cdclk twice:
- Current cdclk -> mid cdclk
- mid cdclk -> desired cdclk
Driver should not take some Pcode mailbox communication
in the cdclk path for platforms that are Display version 14 and later.
v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
change via modeset for platforms that support squash_crawl sequences(Ville)
v3: Add checks for:
- scenario where only slow clock is used and
cdclk is actually 0 (bringing up display).
- PLLs are on before looking up the waveform.
- Squash and crawl capability checks.(Ville)
v4: Rebase
- Move checks to be more consistent (Ville)
- Add comments (Bala)
v5:
- Further small changes. Move checks around.
- Make if-else better looking (Ville)
v6: MTl should not follow PUnit mailbox communication as the rest of
gen11+ platforms.(Anusha)
Cc: Clint Taylor
Cc: Balasubramani Vivekanandan
Signed-off-by: Anusha Srivatsa
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 177 +
1 file changed, 146 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 25d01271dc09..ddbe94aac293 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1727,37 +1727,77 @@ static bool cdclk_pll_is_unknown(unsigned int vco)
return vco == ~0;
}
-static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
- const struct intel_cdclk_config *cdclk_config,
- enum pipe pipe)
+static int cdclk_squash_divider(u16 waveform)
+{
+ return hweight16(waveform ?: 0x);
+}
+
+static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
*i915,
+ const struct
intel_cdclk_config *old_cdclk_config,
+ const struct
intel_cdclk_config *new_cdclk_config,
+ struct intel_cdclk_config
*mid_cdclk_config)
+{
+ u16 old_waveform, new_waveform, mid_waveform;
+ int size = 16;
+ int div = 2;
+
+ drm_WARN_ON(&i915->drm, cdclk_pll_is_unknown(old_cdclk_config->vco));
+
+ /* Return if both Squash and Crawl are not present */
+ if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
+ return false;
+
+ old_waveform = cdclk_squash_waveform(i915, old_cdclk_config->cdclk);
+ new_waveform = cdclk_squash_waveform(i915, new_cdclk_config->cdclk);
+
+ /* Return if Squash only or Crawl only is the desired action */
+ if (old_cdclk_config->vco == 0 || new_cdclk_config->vco == 0 ||
+ old_cdclk_config->vco == new_cdclk_config->vco ||
+ old_waveform == new_waveform)
+ return false;
+
+ *mid_cdclk_config = *new_cdclk_config;
+
+ /*
+* Populate the mid_cdclk_config accordingly.
+* - If moving to a higher cdclk, the desired action is squashing.
+* The mid cdclk config should have the new (squash) waveform.
+* - If moving to a lower cdclk, the desired action is crawling.
+* The mid cdclk config should have the new vco.
+*/
+
+ if (cdclk_squash_divider(new_waveform) >
cdclk_squash_divider(old_waveform)) {
+ mid_cdclk_config->vco = old_cdclk_config->vco;
+ mid_waveform = new_waveform;
+ } else {
+ mid_cdclk_config->vco = new_cdclk_config->vco;
+ mid_waveform = old_waveform;
+ }
+
+ mid_cdclk_config->cdclk =
DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
+ mid_cdclk_config->vco, size
* div);
+
+ /* make sure the mid clock came out sane */
+
+ drm_WARN_ON(&i915->drm, mid_cdclk_config->cdclk <
+ min(old_cdclk_config->cdclk, new_cdclk_config->cdclk));
+ drm_WARN_ON(&i915->drm, mid_cdclk_config->cdclk >
+ i915->display.cdclk.max_cdclk_freq);
+ drm_WARN_ON(&i915->drm, cdclk_squash_waveform(i915,
mid_cdclk_config->cdclk) !=
+ mid_waveform);
+
+ return true;
+}
+
+static void _bxt_set_cdclk(struct drm_i915_private *dev_priv,
+ const struct intel_cdclk_config *cdclk_config,
+ enum pipe pipe)
{
int cdclk = cdclk_config->cdclk;
int vco = cdclk_config->vco;
u32 val;
u16 waveform;
int clock;
- int ret;
-
- /* Inform power controller of upcoming frequency change. */
- if (DISPLAY_VER(dev_priv) >= 11)
- ret = skl_pcode_request(&dev_priv->uncore,
SKL_PCODE_CDCLK_CONTROL,
- SKL_CDCLK_PREPA
[Intel-gfx] [PATCH 3/3] drm/i915/display: Add CDCLK Support for MTL
As per bSpec MTL has 38.4 MHz Reference clock.
Adding the cdclk tables and cdclk_funcs that MTL
will use.
v2: Revert to using bxt_get_cdclk()
BSpec: 65243
Cc: Clint Taylor
Signed-off-by: Anusha Srivatsa
Reviewed-by: Clint Taylor
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index ddbe94aac293..f540869c5b29 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1346,6 +1346,16 @@ static const struct intel_cdclk_vals dg2_cdclk_table[] =
{
{}
};
+static const struct intel_cdclk_vals mtl_cdclk_table[] = {
+ { .refclk = 38400, .cdclk = 172800, .divider = 2, .ratio = 16,
.waveform = 0xad5a },
+ { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 16,
.waveform = 0xb6b6 },
+ { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16,
.waveform = 0x },
+ { .refclk = 38400, .cdclk = 48, .divider = 2, .ratio = 25,
.waveform = 0x },
+ { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29,
.waveform = 0x },
+ { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34,
.waveform = 0x },
+ {}
+};
+
static int bxt_calc_cdclk(struct drm_i915_private *dev_priv, int min_cdclk)
{
const struct intel_cdclk_vals *table = dev_priv->display.cdclk.table;
@@ -3186,6 +3196,13 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
return freq;
}
+static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
+ .get_cdclk = bxt_get_cdclk,
+ .set_cdclk = bxt_set_cdclk,
+ .modeset_calc_cdclk = bxt_modeset_calc_cdclk,
+ .calc_voltage_level = tgl_calc_voltage_level,
+};
+
static const struct intel_cdclk_funcs tgl_cdclk_funcs = {
.get_cdclk = bxt_get_cdclk,
.set_cdclk = bxt_set_cdclk,
@@ -3321,7 +3338,10 @@ static const struct intel_cdclk_funcs i830_cdclk_funcs =
{
*/
void intel_init_cdclk_hooks(struct drm_i915_private *dev_priv)
{
- if (IS_DG2(dev_priv)) {
+ if (IS_METEORLAKE(dev_priv)) {
+ dev_priv->display.funcs.cdclk = &mtl_cdclk_funcs;
+ dev_priv->display.cdclk.table = mtl_cdclk_table;
+ } else if (IS_DG2(dev_priv)) {
dev_priv->display.funcs.cdclk = &tgl_cdclk_funcs;
dev_priv->display.cdclk.table = dg2_cdclk_table;
} else if (IS_ALDERLAKE_P(dev_priv)) {
--
2.25.1
[Intel-gfx] [PATCH 1/3] drm/i915/display: Add missing checks for cdclk crawling
cdclk_sanitize() function was written assuming vco was a signed integer.
vco gets assigned to -1 (essentially ~0) for the case where PLL
might be enabled and vco is not a frequency that will ever
get used. In such a scenario the right thing to do is disable the
PLL and re-enable it again with a valid frequency.
However the vco is declared as a unsigned variable.
With the above assumption, driver takes crawl path when not needed.
Add explicit check to not crawl in the case of an invalid PLL.
v2: Move the check from .h to .c (MattR)
- Move check to bxt_set_cdclk() instead of
intel_modeset_calc_cdclk() which is directly in
the path of the sanitize() function (Ville)
v3: remove unwanted parenthesis(Ville)
Cc: Ville Syrjälä
Cc: Matt Roper
Suggested-by: Ville Syrjälä
Signed-off-by: Anusha Srivatsa
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index b74e36d76013..25d01271dc09 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1717,6 +1717,16 @@ static void dg2_cdclk_squash_program(struct
drm_i915_private *i915,
intel_de_write(i915, CDCLK_SQUASH_CTL, squash_ctl);
}
+static bool cdclk_pll_is_unknown(unsigned int vco)
+{
+ /*
+* Ensure driver does not take the crawl path for the
+* case when the vco is set to ~0 in the
+* sanitize path.
+*/
+ return vco == ~0;
+}
+
static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
const struct intel_cdclk_config *cdclk_config,
enum pipe pipe)
@@ -1749,7 +1759,8 @@ static void bxt_set_cdclk(struct drm_i915_private
*dev_priv,
return;
}
- if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 &&
vco > 0) {
+ if (HAS_CDCLK_CRAWL(dev_priv) && dev_priv->display.cdclk.hw.vco > 0 &&
vco > 0 &&
+ !cdclk_pll_is_unknown(dev_priv->display.cdclk.hw.vco)) {
if (dev_priv->display.cdclk.hw.vco != vco)
adlp_cdclk_pll_crawl(dev_priv, vco);
} else if (DISPLAY_VER(dev_priv) >= 11)
--
2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling
== Series Details ==
Series: series starting with [1/3] drm/i915/display: Add missing checks for
cdclk crawling
URL : https://patchwork.freedesktop.org/series/110970/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12390 -> Patchwork_110970v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/index.html
Participating hosts (41 -> 40)
--
Additional (1): fi-kbl-soraka
Missing(2): bat-kbl-2 bat-jsl-3
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110970v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html
Known issues
Here are the changes found in Patchwork_110970v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
- fi-pnv-d510:[PASS][4] -> [FAIL][5] ([i915#7229])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-4: NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_rps@basic-api:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([i915#6621])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/bat-adlp-4/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][10] ([i915#7099])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][11] ([i915#1886])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-adlp-4: NOTRUN -> [SKIP][13] ([fdo#111827])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +7
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlp-4: NOTRUN -> [SKIP][15] ([i915#3546])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html
* igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301] /
[i915#3708])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/bat-adlp-4/igt@prime_v...@basic-userptr.html
* igt@prime_vgem@basic-write:
- bat-adlp-4: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/bat-adlp-4/igt@prime_v...@basic-write.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-rpls-2}: [INCOMPLETE][18] ([i915#6434]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-rpls-2/igt@i915_module_l...@reload.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/bat-rp
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Finish (de)gamma readout (rev9)
== Series Details ==
Series: drm/i915: Finish (de)gamma readout (rev9)
URL : https://patchwork.freedesktop.org/series/79614/
State : warning
== Summary ==
Error: dim checkpatch failed
cac4d657a616 drm/i915: Clean up legacy palette defines
ce63ce25648d drm/i915: Clean up 10bit precision palette defines
-:31: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#31: FILE: drivers/gpu/drm/i915/display/intel_color.c:475:
+ REG_FIELD_PREP(PREC_PALETTE_10_GREEN_MASK,
drm_color_lut_extract(color->green, 10)) |
total: 0 errors, 1 warnings, 0 checks, 48 lines checked
edb4556cf4b8 drm/i915: Clean up 12.4bit precision palette defines
6b13c0d663bb drm/i915: Clean up chv CGM (de)gamma defines
-:29: WARNING:LONG_LINE: line length of 105 exceeds 100 columns
#29: FILE: drivers/gpu/drm/i915/display/intel_color.c:1081:
+ return REG_FIELD_PREP(CGM_PIPE_DEGAMMA_GREEN_LDW_MASK,
drm_color_lut_extract(color->green, 14)) |
-:30: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#30: FILE: drivers/gpu/drm/i915/display/intel_color.c:1082:
+ REG_FIELD_PREP(CGM_PIPE_DEGAMMA_BLUE_LDW_MASK,
drm_color_lut_extract(color->blue, 14));
-:46: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#46: FILE: drivers/gpu/drm/i915/display/intel_color.c:1108:
+ return REG_FIELD_PREP(CGM_PIPE_GAMMA_GREEN_LDW_MASK,
drm_color_lut_extract(color->green, 10)) |
-:47: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#47: FILE: drivers/gpu/drm/i915/display/intel_color.c:1109:
+ REG_FIELD_PREP(CGM_PIPE_GAMMA_BLUE_LDW_MASK,
drm_color_lut_extract(color->blue, 10));
total: 0 errors, 4 warnings, 0 checks, 65 lines checked
8c7fd0bd4deb drm/i915: Reorder 12.4 lut udw vs. ldw functions
686b18544844 drm/i915: Fix adl+ degamma LUT size
ee7a9ad39b99 drm/i915: s/gamma/post_csc_lut/
c67c29895246 drm/i915: Add glk+ degamma readout
81af8fe489c0 drm/i915: Read out CHV CGM degamma
-:27: WARNING:LONG_LINE: line length of 101 exceeds 100 columns
#27: FILE: drivers/gpu/drm/i915/display/intel_color.c:1092:
+ entry->green =
intel_color_lut_pack(REG_FIELD_GET(CGM_PIPE_DEGAMMA_GREEN_LDW_MASK, ldw), 14);
total: 0 errors, 1 warnings, 0 checks, 54 lines checked
e8da1ccfc3b2 drm/i915: Add gamma/degamma readout for bdw+
59d8d5d8d768 drm/i915: Add gamma/degamma readout for ivb/hsw
031e17bf0c4b drm/i915: Make ilk_read_luts() capable of degamma readout
b1f469c17d03 drm/i915: Prep for C8 palette readout
91bd79f686e8 drm/i915: Make .read_luts() mandatory
ccd194651a58 drm/i915: Finish the LUT state checker
-:517: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'lut' - possible
side-effects?
#517: FILE: drivers/gpu/drm/i915/display/intel_display.c:5679:
+#define PIPE_CONF_CHECK_COLOR_LUT(lut, is_pre_csc_lut) do { \
+ if (current_config->gamma_mode == pipe_config->gamma_mode && \
+ !intel_color_lut_equal(current_config, \
+ current_config->lut, pipe_config->lut, \
+ is_pre_csc_lut)) { \
+ pipe_config_mismatch(fastset, crtc, __stringify(lut), \
+"hw_state doesn't match sw_state"); \
+ ret = false; \
} \
} while (0)
-:517: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'lut' may be better as
'(lut)' to avoid precedence issues
#517: FILE: drivers/gpu/drm/i915/display/intel_display.c:5679:
+#define PIPE_CONF_CHECK_COLOR_LUT(lut, is_pre_csc_lut) do { \
+ if (current_config->gamma_mode == pipe_config->gamma_mode && \
+ !intel_color_lut_equal(current_config, \
+ current_config->lut, pipe_config->lut, \
+ is_pre_csc_lut)) { \
+ pipe_config_mismatch(fastset, crtc, __stringify(lut), \
+"hw_state doesn't match sw_state"); \
+ ret = false; \
} \
} while (0)
total: 0 errors, 0 warnings, 2 checks, 476 lines checked
3e5b3da7e9fc drm/i915: Rework legacy LUT handling
7c90905dfd1f drm/i915: Use hw degamma LUT for sw gamma on glk with YCbCr output
-:93: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"crtc_state->post_csc_lut"
#93: FILE: drivers/gpu/drm/i915/display/intel_color.c:1426:
+ crtc_state->post_csc_lut != NULL &&
total: 0 errors, 0 warnings, 1 checks, 131 lines checked
a98bc605f874 drm/i915: Use gamma LUT for RGB limited range compression
debf0208736a drm/i915: Add 10bit gamma mode for gen2/3
bc983b9016a7 drm/i915: Do state check for color management changes
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: CAGF and RC6 changes for MTL (rev14)
== Series Details == Series: i915: CAGF and RC6 changes for MTL (rev14) URL : https://patchwork.freedesktop.org/series/108156/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling
== Series Details == Series: series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling URL : https://patchwork.freedesktop.org/series/110986/ State : warning == Summary == Error: dim checkpatch failed aa8ce217526b drm/i915/display: Add missing checks for cdclk crawling b688374372d5 drm/i915/display: Do both crawl and squash when changing cdclk -:61: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #61: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1736: + const struct intel_cdclk_config *old_cdclk_config, -:62: WARNING:LONG_LINE: line length of 102 exceeds 100 columns #62: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1737: + const struct intel_cdclk_config *new_cdclk_config, -:172: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional statements (8, 26) #172: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1852: + if (DISPLAY_VER(dev_priv) >= 14) + /* NOOP */; -:203: WARNING:SUSPECT_CODE_INDENT: suspect code indent for conditional statements (8, 19) #203: FILE: drivers/gpu/drm/i915/display/intel_cdclk.c:1883: + if (DISPLAY_VER(dev_priv) >= 14) [...] +*/; total: 0 errors, 4 warnings, 0 checks, 216 lines checked 2ab8faf850e7 drm/i915/display: Add CDCLK Support for MTL
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/edp: wait power off delay at driver remove to optimize probe
== Series Details ==
Series: drm/i915/edp: wait power off delay at driver remove to optimize probe
URL : https://patchwork.freedesktop.org/series/110971/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12390 -> Patchwork_110971v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/index.html
Participating hosts (41 -> 41)
--
Additional (2): fi-kbl-soraka bat-atsm-1
Missing(2): fi-rkl-11600 bat-dg1-5
Known issues
Here are the changes found in Patchwork_110971v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +9 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-4: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_rps@basic-api:
- bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#6621])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/bat-adlp-4/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gem_migrate:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][6] ([i915#7363])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/fi-kbl-soraka/igt@i915_selftest@live@gem_migrate.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-adlp-4: NOTRUN -> [SKIP][9] ([fdo#111827])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827]) +7
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][11] -> [FAIL][12] ([i915#6298])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlp-4: NOTRUN -> [SKIP][13] ([i915#3546])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html
* igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3301] /
[i915#3708])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/bat-adlp-4/igt@prime_v...@basic-userptr.html
* igt@prime_vgem@basic-write:
- bat-adlp-4: NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/bat-adlp-4/igt@prime_v...@basic-write.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-rpls-2}: [INCOMPLETE][16] ([i915#6434]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-rpls-2/igt@i915_module_l...@reload.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/bat-rpls-2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [DMESG-WARN][18] ([i915#7077]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110971v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Finish (de)gamma readout (rev9)
== Series Details ==
Series: drm/i915: Finish (de)gamma readout (rev9)
URL : https://patchwork.freedesktop.org/series/79614/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12390 -> Patchwork_79614v9
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/index.html
Participating hosts (41 -> 40)
--
Additional (1): fi-kbl-soraka
Missing(2): fi-rkl-11600 bat-dg1-5
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_79614v9:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-a-dp-2:
- {bat-dg2-11}: [PASS][1] -> [FAIL][2] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-dp-2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/bat-dg2-11/igt@kms_pipe_crc_basic@suspend-read-...@pipe-a-dp-2.html
Known issues
Here are the changes found in Patchwork_79614v9 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271]) +9 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
- fi-pnv-d510:[PASS][4] -> [FAIL][5] ([i915#7229])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-4: NOTRUN -> [SKIP][8] ([i915#4613]) +3 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_rps@basic-api:
- bat-adlp-4: NOTRUN -> [SKIP][9] ([i915#6621])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/bat-adlp-4/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gem_contexts:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][10] ([i915#7099])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][11] ([i915#1886])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-adlp-4: NOTRUN -> [SKIP][13] ([fdo#111827])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +7
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlp-4: NOTRUN -> [SKIP][15] ([i915#3546])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html
* igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3301] /
[i915#3708])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/bat-adlp-4/igt@prime_v...@basic-userptr.html
* igt@prime_vgem@basic-write:
- bat-adlp-4: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_79614v9/bat-adlp-4/igt@prime_v...@basic-write.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-rpls-2}: [INCOMPLETE][18] ([i915#6434]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-rpls-2/igt@i915_module_l...@reload.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_
[Intel-gfx] ✓ Fi.CI.BAT: success for i915: CAGF and RC6 changes for MTL (rev14)
== Series Details ==
Series: i915: CAGF and RC6 changes for MTL (rev14)
URL : https://patchwork.freedesktop.org/series/108156/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12390 -> Patchwork_108156v14
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/index.html
Participating hosts (41 -> 40)
--
Additional (1): fi-kbl-soraka
Missing(2): bat-dg1-6 bat-dg1-5
Known issues
Here are the changes found in Patchwork_108156v14 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271]) +9 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +3
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-4: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_rps@basic-api:
- bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#6621])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/bat-adlp-4/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#5334])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][7] ([i915#1886])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@requests:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][8] ([i915#7352])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/fi-kbl-soraka/igt@i915_selftest@l...@requests.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
- bat-adlp-4: NOTRUN -> [SKIP][10] ([fdo#111827])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271] / [fdo#111827]) +7
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlp-4: NOTRUN -> [SKIP][12] ([i915#3546])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html
* igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][13] ([fdo#109295] / [i915#3301] /
[i915#3708])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/bat-adlp-4/igt@prime_v...@basic-userptr.html
* igt@prime_vgem@basic-write:
- bat-adlp-4: NOTRUN -> [SKIP][14] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/bat-adlp-4/igt@prime_v...@basic-write.html
* igt@runner@aborted:
- fi-kbl-soraka: NOTRUN -> [FAIL][15] ([i915#4312] / [i915#4991])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/fi-kbl-soraka/igt@run...@aborted.html
Possible fixes
* igt@i915_module_load@reload:
- {bat-rpls-2}: [INCOMPLETE][16] ([i915#6434]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-rpls-2/igt@i915_module_l...@reload.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/bat-rpls-2/igt@i915_module_l...@reload.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [DMESG-WARN][18] ([i915#7077]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v14/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][20] ([i915#4785]) ->
[Intel-gfx] [PATCH v4 1/6] drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT
In preparation for future MTL-PXP feature support, PXP control
context should only valid on the correct gt tile. Depending on the
device-info this depends on which tile owns the VEBOX and KCR.
PXP is still a global feature though (despite its control-context
located in the owning GT structure). Additionally, we find
that the HAS_PXP macro is only used within the pxp module,
That said, lets drop that HAS_PXP macro altogether and replace it
with a more fitting named intel_gtpxp_is_supported and helpers
so that PXP init/fini can use to verify if the referenced gt supports
PXP or teelink.
Add TODO for Meteorlake that will come in future series.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_drv.h | 4
drivers/gpu/drm/i915/pxp/intel_pxp.c | 22 ++--
drivers/gpu/drm/i915/pxp/intel_pxp.h | 3 +++
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
4 files changed, 20 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7e3820d2c404..0616e5f0bd31 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -933,10 +933,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_GLOBAL_MOCS_REGISTERS(dev_priv)
(INTEL_INFO(dev_priv)->has_global_mocs)
-#define HAS_PXP(dev_priv) ((IS_ENABLED(CONFIG_DRM_I915_PXP) && \
- INTEL_INFO(dev_priv)->has_pxp) && \
- VDBOX_MASK(to_gt(dev_priv)))
-
#define HAS_GMCH(dev_priv) (INTEL_INFO(dev_priv)->display.has_gmch)
#define HAS_GMD_ID(i915) (INTEL_INFO(i915)->has_gmd_id)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 5efe61f67546..d993e752bd36 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -44,6 +44,20 @@ struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp)
return container_of(pxp, struct intel_gt, pxp);
}
+static bool _gt_needs_teelink(struct intel_gt *gt)
+{
+ /* TODO: MTL won't rely on CONFIG_INTEL_MEI_PXP but on GSC engine */
+ return (IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
intel_huc_is_loaded_by_gsc(>->uc.huc) &&
+ intel_uc_uses_huc(>->uc));
+}
+
+bool intel_pxp_supported_on_gt(const struct intel_pxp *pxp)
+{
+ /* TODO: MTL won't rely on CONFIG_INTEL_MEI_PXP but on GSC engine */
+ return (IS_ENABLED(CONFIG_INTEL_MEI_PXP) &&
IS_ENABLED(CONFIG_DRM_I915_PXP) &&
+ INTEL_INFO((pxp_to_gt(pxp))->i915)->has_pxp &&
VDBOX_MASK(pxp_to_gt(pxp)));
+}
+
bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
{
return pxp->ce;
@@ -142,17 +156,13 @@ void intel_pxp_init(struct intel_pxp *pxp)
{
struct intel_gt *gt = pxp_to_gt(pxp);
- /* we rely on the mei PXP module */
- if (!IS_ENABLED(CONFIG_INTEL_MEI_PXP))
- return;
-
/*
* If HuC is loaded by GSC but PXP is disabled, we can skip the init of
* the full PXP session/object management and just init the tee channel.
*/
- if (HAS_PXP(gt->i915))
+ if (intel_pxp_supported_on_gt(pxp))
pxp_init_full(pxp);
- else if (intel_huc_is_loaded_by_gsc(>->uc.huc) &&
intel_uc_uses_huc(>->uc))
+ else if (_gt_needs_teelink(gt))
intel_pxp_tee_component_init(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 2da309088c6d..efa83f9d5e24 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -13,6 +13,9 @@ struct intel_pxp;
struct drm_i915_gem_object;
struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
+
+bool intel_pxp_supported_on_gt(const struct intel_pxp *pxp);
+
bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
bool intel_pxp_is_active(const struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4359e8be4101..f0ad6f34624a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -70,7 +70,7 @@ void intel_pxp_debugfs_register(struct intel_pxp *pxp, struct
dentry *gt_root)
if (!gt_root)
return;
- if (!HAS_PXP((pxp_to_gt(pxp)->i915)))
+ if (!intel_pxp_supported_on_gt(pxp))
return;
root = debugfs_create_dir("pxp", gt_root);
--
2.34.1
[Intel-gfx] [PATCH v4 0/6] drm/i915/pxp: Prepare intel_pxp entry points for MTL
MTL has two tiles that is represented by the intel_gt structure in the i915 code. The PXP feature has a control-structure that contains the PXP context and this hangs of the intel_gt structure. In MTL, the standalone media tile (i.e. not the root tile) contains the VDBOX and KCR engine which is what PXP relies on for establishing and tearing down the PXP session. However PXP is a global feature as other engines on other tiles can reference the PXP session in object info within batch buffer instructions.That coherrency is handled implicitly by the HW. However current intel_pxp functions such as intel_pxp_enabled, intel_pxp_start and others take in the intel_gt structure pointer as its input thus creation the perception that PXP is a GT-tile specific domain that is independant from other GT tiles. This series updates all of the intel_pxp_foo functions that are accessed from outside the PXP subsystem so that the callers only need to pass in the i915 structure as the input param (being a global handle). Internally, these functions will loop through all available GT structures on the GPU and find the one GT structure that contains the one PXP+TEE control structure before proceeding with the rest of its operation. Changes from prior revs: v3: - Rename gt level helper functions to "intel_pxp_is_enabled/supported/ active_on_gt" (Daniele) - Upgrade _gt_supports_pxp to replace what was intel_gtpxp_is_supported as the new intel_pxp_is_supported_on_gt to check for PXP feature support vs the tee support for huc authentication. Fix pxp-debugfs- registration to use only the former to decide support. (Daniele) - Couple minor optimizations. v2: - Avoid introduction of new device info or gt variables and use existing checks / macros to differentiate the correct GT->PXP control ownership (Daniele Ceraolo Spurio) - Don't reuse the updated global-checkers for per-GT callers (such as other files within PXP) to avoid unnecessary GT-reparsing, expose a replacement helper like the prior ones. (Daniele). v1: Add one more patch to the series for the intel_pxp suspend/resume for similiar refactoring Patches that received R-B so far: Patch 4, 5, 6. Alan Previn (6): drm/i915/pxp: Make gt and pxp init/fini aware of PXP-owning-GT drm/i915/pxp: Make intel_pxp_is_enabled implicitly sort PXP-owning-GT drm/i915/pxp: Make intel_pxp_is_active implicitly sort PXP-owning-GT drm/i915/pxp: Make PXP tee component bind/unbind aware of PXP-owning-GT drm/i915/pxp: Make intel_pxp_start implicitly sort PXP-owning-GT drm/i915/pxp: Make intel_pxp_key_check implicitly sort PXP-owning-GT .../drm/i915/display/skl_universal_plane.c| 2 +- drivers/gpu/drm/i915/gem/i915_gem_context.c | 6 +- drivers/gpu/drm/i915/gem/i915_gem_create.c| 2 +- .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +- drivers/gpu/drm/i915/i915_drv.h | 4 - drivers/gpu/drm/i915/pxp/intel_pxp.c | 83 --- drivers/gpu/drm/i915/pxp/intel_pxp.h | 16 +++- drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 2 +- drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 8 +- drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 4 +- drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 8 +- drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 18 +++- 12 files changed, 114 insertions(+), 41 deletions(-) base-commit: b7288a4715c68710aadbd63112b699356e8a2b65 -- 2.34.1
[Intel-gfx] [PATCH v4 2/6] drm/i915/pxp: Make intel_pxp_is_enabled implicitly sort PXP-owning-GT
Make intel_pxp_is_enabled a global check and implicitly find the
PXP-owning-GT.
PXP feature support is a device-config flag. In preparation for MTL
PXP control-context shall reside on of the two GT's. That said,
update intel_pxp_is_enabled to take in i915 as its input and internally
find the right gt to check if PXP is enabled so its transparent to
callers of this functions.
However we also need to expose the per-gt variation of this internal
pxp files to use (like what intel_pxp_enabled was prior) so also expose
a new intel_gtpxp_is_enabled function for replacement.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_create.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 28 ++--
drivers/gpu/drm/i915/pxp/intel_pxp.h | 4 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 8 +++---
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 4 +--
9 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 7f2831efc798..c123f4847b19 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -257,7 +257,7 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
if (!protected) {
pc->uses_protected_content = false;
- } else if (!intel_pxp_is_enabled(&to_gt(i915)->pxp)) {
+ } else if (!intel_pxp_is_enabled(i915)) {
ret = -ENODEV;
} else if ((pc->user_flags & BIT(UCONTEXT_RECOVERABLE)) ||
!(pc->user_flags & BIT(UCONTEXT_BANNABLE))) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_create.c
b/drivers/gpu/drm/i915/gem/i915_gem_create.c
index 33673fe7ee0a..e44803f9bec4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_create.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_create.c
@@ -384,7 +384,7 @@ static int ext_set_protected(struct i915_user_extension
__user *base, void *data
if (ext.flags)
return -EINVAL;
- if (!intel_pxp_is_enabled(&to_gt(ext_data->i915)->pxp))
+ if (!intel_pxp_is_enabled(ext_data->i915))
return -ENODEV;
ext_data->flags |= I915_BO_PROTECTED;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index d993e752bd36..88105101af79 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -9,6 +9,7 @@
#include "intel_pxp_tee.h"
#include "gem/i915_gem_context.h"
#include "gt/intel_context.h"
+#include "gt/intel_gt.h"
#include "i915_drv.h"
/**
@@ -58,11 +59,34 @@ bool intel_pxp_supported_on_gt(const struct intel_pxp *pxp)
INTEL_INFO((pxp_to_gt(pxp))->i915)->has_pxp &&
VDBOX_MASK(pxp_to_gt(pxp)));
}
-bool intel_pxp_is_enabled(const struct intel_pxp *pxp)
+bool intel_pxp_is_enabled_on_gt(const struct intel_pxp *pxp)
{
return pxp->ce;
}
+static struct intel_gt *i915_to_pxp_gt(struct drm_i915_private *i915)
+{
+ struct intel_gt *gt = NULL;
+ int i = 0;
+
+ for_each_gt(gt, i915, i) {
+ /* There can be only one GT that supports PXP */
+ if (intel_pxp_supported_on_gt(>->pxp))
+ return gt;
+ }
+ return NULL;
+}
+
+bool intel_pxp_is_enabled(struct drm_i915_private *i915)
+{
+ struct intel_gt *gt = i915_to_pxp_gt(i915);
+
+ if (!gt)
+ return false;
+
+ return intel_pxp_is_enabled_on_gt(>->pxp);
+}
+
bool intel_pxp_is_active(const struct intel_pxp *pxp)
{
return pxp->arb_is_valid;
@@ -216,7 +240,7 @@ int intel_pxp_start(struct intel_pxp *pxp)
{
int ret = 0;
- if (!intel_pxp_is_enabled(pxp))
+ if (!intel_pxp_is_enabled_on_gt(pxp))
return -ENODEV;
if (wait_for(pxp_component_bound(pxp), 250))
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index efa83f9d5e24..3f71b1653f74 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -11,12 +11,14 @@
struct intel_pxp;
struct drm_i915_gem_object;
+struct drm_i915_private;
struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
bool intel_pxp_supported_on_gt(const struct intel_pxp *pxp);
-bool intel_pxp_is_enabled(const struct intel_pxp *pxp);
+bool intel_pxp_is_enabled_on_gt(const struct intel_pxp *pxp);
+bool intel_pxp_is_enabled(struct drm_i915_private *i915);
bool intel_pxp_is_active(const struct intel_pxp *pxp);
void intel_pxp_init(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd.c
index f41e45763d0d..f322a49ebadc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cm
[Intel-gfx] [PATCH v4 3/6] drm/i915/pxp: Make intel_pxp_is_active implicitly sort PXP-owning-GT
Make intel_pxp_is_active a global check and implicitly find
the PXP-owning-GT.
As per prior two patches, callers of this function shall now
pass in i915 since PXP is a global GPU feature. Make
intel_pxp_is_active implicitly find the right gt so it's transparent
for global view callers (like display or gem-exec).
However we also need to expose the per-gt variation of this for internal
pxp files to use (like what intel_pxp_is_active was prior) so also expose
a new intel_gtpxp_is_active function for replacement.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 14 --
drivers/gpu/drm/i915/pxp/intel_pxp.h | 3 ++-
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 4 ++--
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 2 +-
5 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index c123f4847b19..165be45a3c13 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -271,7 +271,7 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
*/
pc->pxp_wakeref = intel_runtime_pm_get(&i915->runtime_pm);
- if (!intel_pxp_is_active(&to_gt(i915)->pxp))
+ if (!intel_pxp_is_active(i915))
ret = intel_pxp_start(&to_gt(i915)->pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 88105101af79..76a924587543 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -87,11 +87,21 @@ bool intel_pxp_is_enabled(struct drm_i915_private *i915)
return intel_pxp_is_enabled_on_gt(>->pxp);
}
-bool intel_pxp_is_active(const struct intel_pxp *pxp)
+bool intel_pxp_is_active_on_gt(const struct intel_pxp *pxp)
{
return pxp->arb_is_valid;
}
+bool intel_pxp_is_active(struct drm_i915_private *i915)
+{
+ struct intel_gt *gt = i915_to_pxp_gt(i915);
+
+ if (!gt)
+ return false;
+
+ return intel_pxp_is_active_on_gt(>->pxp);
+}
+
/* KCR register definitions */
#define KCR_INIT _MMIO(0x320f0)
/* Setting KCR Init bit is required after system boot */
@@ -287,7 +297,7 @@ int intel_pxp_key_check(struct intel_pxp *pxp,
struct drm_i915_gem_object *obj,
bool assign)
{
- if (!intel_pxp_is_active(pxp))
+ if (!intel_pxp_is_active_on_gt(pxp))
return -ENODEV;
if (!i915_gem_object_is_protected(obj))
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 3f71b1653f74..fe981eebf0ec 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -19,7 +19,8 @@ bool intel_pxp_supported_on_gt(const struct intel_pxp *pxp);
bool intel_pxp_is_enabled_on_gt(const struct intel_pxp *pxp);
bool intel_pxp_is_enabled(struct drm_i915_private *i915);
-bool intel_pxp_is_active(const struct intel_pxp *pxp);
+bool intel_pxp_is_active_on_gt(const struct intel_pxp *pxp);
+bool intel_pxp_is_active(struct drm_i915_private *i915);
void intel_pxp_init(struct intel_pxp *pxp);
void intel_pxp_fini(struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4d257055434b..52a808fd4704 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -25,7 +25,7 @@ static int pxp_info_show(struct seq_file *m, void *data)
return 0;
}
- drm_printf(&p, "active: %s\n", str_yes_no(intel_pxp_is_active(pxp)));
+ drm_printf(&p, "active: %s\n",
str_yes_no(intel_pxp_is_active_on_gt(pxp)));
drm_printf(&p, "instance counter: %u\n", pxp->key_instance);
return 0;
@@ -43,7 +43,7 @@ static int pxp_terminate_set(void *data, u64 val)
struct intel_pxp *pxp = data;
struct intel_gt *gt = pxp_to_gt(pxp);
- if (!intel_pxp_is_active(pxp))
+ if (!intel_pxp_is_active_on_gt(pxp))
return -ENODEV;
/* simulate a termination interrupt */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index d3c697bf9aab..c25c1979 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -86,7 +86,7 @@ void intel_pxp_irq_disable(struct intel_pxp *pxp)
* called in a path were the driver consider the session as valid and
* doesn't call a termination on restart.
*/
- GEM_WARN_ON(intel_pxp_is_active(pxp));
+ GEM_WARN_ON(intel_pxp_is_active_on_gt(pxp));
spin_lock_irq(gt->irq_lock);
--
2.34.1
[Intel-gfx] [PATCH v4 6/6] drm/i915/pxp: Make intel_pxp_key_check implicitly sort PXP-owning-GT
Make intel_pxp_key_check implicitly find the PXP-owning-GT.
Callers of this function shall now pass in i915 since PXP
is a global GPU feature. Make intel_pxp_key_check implicitly
find the right gt to verify pxp session key establishment count
so it's transparent to the callers.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/display/skl_universal_plane.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 10 +-
drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 +-
4 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
b/drivers/gpu/drm/i915/display/skl_universal_plane.c
index 76490cc59d8f..3436bf433c10 100644
--- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
+++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
@@ -1848,7 +1848,7 @@ static bool bo_has_valid_encryption(struct
drm_i915_gem_object *obj)
{
struct drm_i915_private *i915 = to_i915(obj->base.dev);
- return intel_pxp_key_check(&to_gt(i915)->pxp, obj, false) == 0;
+ return intel_pxp_key_check(i915, obj, false) == 0;
}
static bool pxp_is_borked(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 29e9e8d5b6fe..9943d5827300 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -869,7 +869,7 @@ static struct i915_vma *eb_lookup_vma(struct
i915_execbuffer *eb, u32 handle)
*/
if (i915_gem_context_uses_protected_content(eb->gem_context) &&
i915_gem_object_is_protected(obj)) {
- err = intel_pxp_key_check(&vm->gt->pxp, obj, true);
+ err = intel_pxp_key_check(vm->gt->i915, obj, true);
if (err) {
i915_gem_object_put(obj);
return ERR_PTR(err);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 43f3790e1520..58219beecfa4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -300,10 +300,18 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp)
intel_pxp_irq_disable(pxp);
}
-int intel_pxp_key_check(struct intel_pxp *pxp,
+int intel_pxp_key_check(struct drm_i915_private *i915,
struct drm_i915_gem_object *obj,
bool assign)
{
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
+ struct intel_pxp *pxp;
+
+ if (!gt)
+ return -ENODEV;
+
+ pxp = >->pxp;
+
if (!intel_pxp_is_active_on_gt(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index 7b2b93a2ba94..6fe1595a84d6 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -34,7 +34,7 @@ void intel_pxp_mark_termination_in_progress(struct intel_pxp
*pxp);
int intel_pxp_start(struct drm_i915_private *i915);
-int intel_pxp_key_check(struct intel_pxp *pxp,
+int intel_pxp_key_check(struct drm_i915_private *i915,
struct drm_i915_gem_object *obj,
bool assign);
--
2.34.1
[Intel-gfx] [PATCH v4 5/6] drm/i915/pxp: Make intel_pxp_start implicitly sort PXP-owning-GT
Make intel_pxp_is_start implicitly find the PXP-owning-GT.
Callers of this function shall now pass in i915 since PXP
is a global GPU feature. Make intel_pxp_start implicitly
find the right gt to start PXP arb session so
it's transparent to the callers.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c| 9 -
drivers/gpu/drm/i915/pxp/intel_pxp.h| 2 +-
3 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 165be45a3c13..15c3d435093a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -272,7 +272,7 @@ static int proto_context_set_protected(struct
drm_i915_private *i915,
pc->pxp_wakeref = intel_runtime_pm_get(&i915->runtime_pm);
if (!intel_pxp_is_active(i915))
- ret = intel_pxp_start(&to_gt(i915)->pxp);
+ ret = intel_pxp_start(i915);
}
return ret;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 6a78b6ef0235..43f3790e1520 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -246,10 +246,17 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
* the arb session is restarted from the irq work when we receive the
* termination completion interrupt
*/
-int intel_pxp_start(struct intel_pxp *pxp)
+int intel_pxp_start(struct drm_i915_private *i915)
{
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
+ struct intel_pxp *pxp;
int ret = 0;
+ if (!gt)
+ return -ENODEV;
+
+ pxp = >->pxp;
+
if (!intel_pxp_is_enabled_on_gt(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index c798c3bde957..7b2b93a2ba94 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -32,7 +32,7 @@ void intel_pxp_fini_hw(struct intel_pxp *pxp);
void intel_pxp_mark_termination_in_progress(struct intel_pxp *pxp);
-int intel_pxp_start(struct intel_pxp *pxp);
+int intel_pxp_start(struct drm_i915_private *i915);
int intel_pxp_key_check(struct intel_pxp *pxp,
struct drm_i915_gem_object *obj,
--
2.34.1
[Intel-gfx] [PATCH v4 4/6] drm/i915/pxp: Make PXP tee component bind/unbind aware of PXP-owning-GT
Ensure i915_pxp_tee_component_bind / unbind implicitly sorts out
getting the correct per-GT PXP control-context from the PXP-owning-GT
when establishing or ending connection. Thus, replace _i915_to_pxp_gt
with intel_pxp_get_owning_gt (also takes in i915).
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 6 +++---
drivers/gpu/drm/i915/pxp/intel_pxp.h | 2 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 14 --
3 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 76a924587543..6a78b6ef0235 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -64,7 +64,7 @@ bool intel_pxp_is_enabled_on_gt(const struct intel_pxp *pxp)
return pxp->ce;
}
-static struct intel_gt *i915_to_pxp_gt(struct drm_i915_private *i915)
+struct intel_gt *intel_pxp_get_owning_gt(struct drm_i915_private *i915)
{
struct intel_gt *gt = NULL;
int i = 0;
@@ -79,7 +79,7 @@ static struct intel_gt *i915_to_pxp_gt(struct
drm_i915_private *i915)
bool intel_pxp_is_enabled(struct drm_i915_private *i915)
{
- struct intel_gt *gt = i915_to_pxp_gt(i915);
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
if (!gt)
return false;
@@ -94,7 +94,7 @@ bool intel_pxp_is_active_on_gt(const struct intel_pxp *pxp)
bool intel_pxp_is_active(struct drm_i915_private *i915)
{
- struct intel_gt *gt = i915_to_pxp_gt(i915);
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
if (!gt)
return false;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.h
b/drivers/gpu/drm/i915/pxp/intel_pxp.h
index fe981eebf0ec..c798c3bde957 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.h
@@ -13,6 +13,8 @@ struct intel_pxp;
struct drm_i915_gem_object;
struct drm_i915_private;
+struct intel_gt *intel_pxp_get_owning_gt(struct drm_i915_private *i915);
+
struct intel_gt *pxp_to_gt(const struct intel_pxp *pxp);
bool intel_pxp_supported_on_gt(const struct intel_pxp *pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
index a5c9c692c20d..b9198e961cb6 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_tee.c
@@ -20,8 +20,12 @@
static inline struct intel_pxp *i915_dev_to_pxp(struct device *i915_kdev)
{
struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
+ struct intel_gt *gt = intel_pxp_get_owning_gt(i915);
- return &to_gt(i915)->pxp;
+ if (!gt)
+ return NULL;
+
+ return >->pxp;
}
static int intel_pxp_tee_io_message(struct intel_pxp *pxp,
@@ -128,10 +132,16 @@ static int i915_pxp_tee_component_bind(struct device
*i915_kdev,
{
struct drm_i915_private *i915 = kdev_to_i915(i915_kdev);
struct intel_pxp *pxp = i915_dev_to_pxp(i915_kdev);
- struct intel_uc *uc = &pxp_to_gt(pxp)->uc;
+ struct intel_uc *uc;
intel_wakeref_t wakeref;
int ret = 0;
+ if (!pxp) {
+ drm_warn(&i915->drm, "tee comp binding without a PXP-owner
GT\n");
+ return -ENODEV;
+ }
+ uc = &pxp_to_gt(pxp)->uc;
+
mutex_lock(&pxp->tee_mutex);
pxp->pxp_component = data;
pxp->pxp_component->tee_dev = tee_kdev;
--
2.34.1
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling
== Series Details ==
Series: series starting with [1/3] drm/i915/display: Add missing checks for
cdclk crawling
URL : https://patchwork.freedesktop.org/series/110986/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12390 -> Patchwork_110986v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110986v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110986v1, 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_110986v1/index.html
Participating hosts (41 -> 40)
--
Additional (1): bat-adls-5
Missing(2): bat-kbl-2 bat-jsl-3
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110986v1:
### CI changes ###
Possible regressions
* boot:
- fi-ivb-3770:[PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-ivb-3770/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/fi-ivb-3770/boot.html
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-bxt-dsi: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-bxt-dsi/igt@i915_pm_...@basic-pci-d3-state.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/fi-bxt-dsi/igt@i915_pm_...@basic-pci-d3-state.html
- fi-glk-j4005: [PASS][5] -> [DMESG-WARN][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-glk-j4005/igt@i915_pm_...@basic-pci-d3-state.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/fi-glk-j4005/igt@i915_pm_...@basic-pci-d3-state.html
- fi-rkl-guc: [PASS][7] -> [DMESG-WARN][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-rkl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/fi-rkl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- bat-dg1-6: [PASS][9] -> [DMESG-WARN][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg1-6/igt@i915_pm_...@basic-pci-d3-state.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/bat-dg1-6/igt@i915_pm_...@basic-pci-d3-state.html
- fi-rkl-11600: [PASS][11] -> [DMESG-WARN][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-rkl-11600/igt@i915_pm_...@basic-pci-d3-state.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/fi-rkl-11600/igt@i915_pm_...@basic-pci-d3-state.html
- fi-icl-u2: [PASS][13] -> [DMESG-WARN][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-icl-u2/igt@i915_pm_...@basic-pci-d3-state.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/fi-icl-u2/igt@i915_pm_...@basic-pci-d3-state.html
- fi-apl-guc: [PASS][15] -> [DMESG-WARN][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/fi-apl-guc/igt@i915_pm_...@basic-pci-d3-state.html
- bat-dg1-5: [PASS][17] -> [DMESG-WARN][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg1-5/igt@i915_pm_...@basic-pci-d3-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/bat-dg1-5/igt@i915_pm_...@basic-pci-d3-state.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [DMESG-WARN][19] ([i915#7077]) -> [DMESG-WARN][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@basic-pci-d3-state:
- {bat-adlm-1}: [PASS][21] -> [DMESG-WARN][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-adlm-1/igt@i915_pm_...@basic-pci-d3-state.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/bat-adlm-1/igt@i915_pm_...@basic-pci-d3-state.html
- {bat-jsl-1}:[PASS][23] -> [DMESG-WARN][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-jsl-1/igt@i915_pm_...@basic-pci-d3-state.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110986v1/bat-jsl-1/igt@i915_pm_...@basic-pci-d3-state.html
- {fi-jsl-1}: [PASS][25] -> [DMESG-WARN][26]
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for mei: add timeout to send (rev3)
On Wed, Nov 16, 2022 at 09:49:20PM +, Patchwork wrote:
> == Series Details ==
>
> Series: mei: add timeout to send (rev3)
> URL : https://patchwork.freedesktop.org/series/110495/
> State : success
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12390 -> Patchwork_110495v3
>
>
> Summary
> ---
>
> **SUCCESS**
>
Since this series is expected to resolve one of the remaining blockers
to DG2 force_probe removal, we've temporarily added this to the
topic/core-for-CI branch that gets included in drm-tip to verify it
fully solves the problem across multiple builds. We can drop it from
the CI branch when this series actually lands (which I believe will
happen via the mei tree) or if we need to replace it with an updated
version of the series.
Matt
> No regressions found.
>
> External URL:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/index.html
>
> Participating hosts (41 -> 38)
> --
>
> Additional (1): bat-atsm-1
> Missing(4): bat-kbl-2 bat-jsl-3 bat-dg1-6 bat-dg1-5
>
> Known issues
>
>
> Here are the changes found in Patchwork_110495v3 that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_lmem_swapping@parallel-random-engines:
> - bat-adlp-4: NOTRUN -> [SKIP][1] ([i915#4613]) +3 similar issues
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html
>
> * igt@gem_render_tiled_blits@basic:
> - fi-apl-guc: [PASS][2] -> [INCOMPLETE][3] ([i915#7056])
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
>
> * igt@i915_pm_rps@basic-api:
> - bat-adlp-4: NOTRUN -> [SKIP][4] ([i915#6621])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@i915_pm_...@basic-api.html
>
> * igt@kms_chamelium@common-hpd-after-suspend:
> - fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
> - bat-adlp-4: NOTRUN -> [SKIP][6] ([fdo#111827])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html
>
> * igt@kms_pipe_crc_basic@suspend-read-crc:
> - bat-adlp-4: NOTRUN -> [SKIP][7] ([i915#3546])
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html
>
> * igt@prime_vgem@basic-userptr:
> - bat-adlp-4: NOTRUN -> [SKIP][8] ([fdo#109295] / [i915#3301] /
> [i915#3708])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@prime_v...@basic-userptr.html
>
> * igt@prime_vgem@basic-write:
> - bat-adlp-4: NOTRUN -> [SKIP][9] ([fdo#109295] / [i915#3291] /
> [i915#3708]) +2 similar issues
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@prime_v...@basic-write.html
>
>
> Possible fixes
>
> * igt@i915_module_load@reload:
> - {bat-rpls-2}: [INCOMPLETE][10] ([i915#6434]) -> [PASS][11]
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-rpls-2/igt@i915_module_l...@reload.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-rpls-2/igt@i915_module_l...@reload.html
>
> * igt@i915_pm_rpm@basic-pci-d3-state:
> - bat-adlp-4: [DMESG-WARN][12] ([i915#7077]) -> [PASS][13]
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
>
> * igt@i915_selftest@live@hangcheck:
> - fi-hsw-4770:[INCOMPLETE][14] ([i915#4785]) -> [PASS][15]
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
>
> * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-d-dp-2:
> - {bat-dg2-11}: [FAIL][16] -> [PASS][17]
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-2.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/bat-dg2-11/igt@kms_pipe_crc_basic@nonblocking-...@pipe-d-dp-2.html
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> [fdo
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Prepare intel_pxp entry points for MTL (rev4)
== Series Details == Series: drm/i915/pxp: Prepare intel_pxp entry points for MTL (rev4) URL : https://patchwork.freedesktop.org/series/109429/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 2/3] drm/i915/display: Do both crawl and squash when changing cdclk
On Wed, Nov 16, 2022 at 01:50:39PM -0800, Anusha Srivatsa wrote:
> From: Ville Syrjälä
>
> For MTL, changing cdclk from between certain frequencies has
> both squash and crawl. Use the current cdclk config and
> the new(desired) cdclk config to construct a mid cdclk config.
> Set the cdclk twice:
> - Current cdclk -> mid cdclk
> - mid cdclk -> desired cdclk
>
> Driver should not take some Pcode mailbox communication
> in the cdclk path for platforms that are Display version 14 and later.
>
> v2: Add check in intel_modeset_calc_cdclk() to avoid cdclk
> change via modeset for platforms that support squash_crawl sequences(Ville)
>
> v3: Add checks for:
> - scenario where only slow clock is used and
> cdclk is actually 0 (bringing up display).
> - PLLs are on before looking up the waveform.
> - Squash and crawl capability checks.(Ville)
>
> v4: Rebase
> - Move checks to be more consistent (Ville)
> - Add comments (Bala)
> v5:
> - Further small changes. Move checks around.
> - Make if-else better looking (Ville)
>
> v6: MTl should not follow PUnit mailbox communication as the rest of
> gen11+ platforms.(Anusha)
>
> Cc: Clint Taylor
> Cc: Balasubramani Vivekanandan
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 177 +
> 1 file changed, 146 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 25d01271dc09..ddbe94aac293 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1727,37 +1727,77 @@ static bool cdclk_pll_is_unknown(unsigned int vco)
> return vco == ~0;
> }
>
> -static void bxt_set_cdclk(struct drm_i915_private *dev_priv,
> - const struct intel_cdclk_config *cdclk_config,
> - enum pipe pipe)
> +static int cdclk_squash_divider(u16 waveform)
> +{
> + return hweight16(waveform ?: 0x);
> +}
> +
> +static bool cdclk_compute_crawl_and_squash_midpoint(struct drm_i915_private
> *i915,
> + const struct
> intel_cdclk_config *old_cdclk_config,
> + const struct
> intel_cdclk_config *new_cdclk_config,
> + struct intel_cdclk_config
> *mid_cdclk_config)
> +{
> + u16 old_waveform, new_waveform, mid_waveform;
> + int size = 16;
> + int div = 2;
> +
> + drm_WARN_ON(&i915->drm, cdclk_pll_is_unknown(old_cdclk_config->vco));
We're going to trip this assertion easily during init with this
sequence:
bxt_cdclk_init_hw
-> bxt_sanitize_cdclk
-> potentially set hw.vco = -1 at the end
-> bxt_set_cdclk (initial, non-atomic direct call)
-> cdclk_compute_crawl_and_squash_midpoint (hw is 'old' param)
-> ASSERT!
We only wind up checking for unknown PLL in _bxt_set_cdclk(), which gets
called after this function completes.
However having a warning like this would be good down in
intel_cdclk_can_crawl_and_squash() --- that's only called from atomic
check and by the time we start doing real atomic transactions, we'll
have already done a sanitization cdclk update to set the PLL to a known
value. That's the point I overlooked in my comments on the previous
version of the series.
Matt
> +
> + /* Return if both Squash and Crawl are not present */
> + if (!HAS_CDCLK_CRAWL(i915) || !HAS_CDCLK_SQUASH(i915))
> + return false;
> +
> + old_waveform = cdclk_squash_waveform(i915, old_cdclk_config->cdclk);
> + new_waveform = cdclk_squash_waveform(i915, new_cdclk_config->cdclk);
> +
> + /* Return if Squash only or Crawl only is the desired action */
> + if (old_cdclk_config->vco == 0 || new_cdclk_config->vco == 0 ||
> + old_cdclk_config->vco == new_cdclk_config->vco ||
> + old_waveform == new_waveform)
> + return false;
> +
> + *mid_cdclk_config = *new_cdclk_config;
> +
> + /*
> + * Populate the mid_cdclk_config accordingly.
> + * - If moving to a higher cdclk, the desired action is squashing.
> + * The mid cdclk config should have the new (squash) waveform.
> + * - If moving to a lower cdclk, the desired action is crawling.
> + * The mid cdclk config should have the new vco.
> + */
> +
> + if (cdclk_squash_divider(new_waveform) >
> cdclk_squash_divider(old_waveform)) {
> + mid_cdclk_config->vco = old_cdclk_config->vco;
> + mid_waveform = new_waveform;
> + } else {
> + mid_cdclk_config->vco = new_cdclk_config->vco;
> + mid_waveform = old_waveform;
> + }
> +
> + mid_cdclk_config->cdclk =
> DIV_ROUND_CLOSEST(cdclk_squash_divider(mid_waveform) *
> + mid_cdclk_config->vco, size
> * div);
> +
> + /* make sure the mid clock came o
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/ttm: Clean up page shift operation
== Series Details == Series: series starting with [1/2] drm/ttm: Clean up page shift operation URL : https://patchwork.freedesktop.org/series/110957/ State : success == Summary == CI Bug Log - changes from CI_DRM_12389_full -> Patchwork_110957v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 9) -- Missing(1): shard-rkl Known issues Here are the changes found in Patchwork_110957v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [FAIL][22], [FAIL][23], [PASS][24], [PASS][25]) ([i915#4392]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk1/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk2/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk2/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk3/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk3/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk3/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk5/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk7/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk7/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk8/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk8/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk8/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk9/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk9/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk9/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk1/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk2/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk2/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk2/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk3/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk3/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk3/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk5/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk5/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk5/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk6/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk6/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk6/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk6/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110957v1/shard-glk7/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwor
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Prepare intel_pxp entry points for MTL (rev4)
== Series Details ==
Series: drm/i915/pxp: Prepare intel_pxp entry points for MTL (rev4)
URL : https://patchwork.freedesktop.org/series/109429/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12390 -> Patchwork_109429v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/index.html
Participating hosts (41 -> 39)
--
Missing(2): bat-dg1-6 bat-dg1-5
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_109429v4:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@core_hotunplug@unbind-rebind:
- {bat-dg2-9}:[PASS][1] -> [DMESG-WARN][2] +4 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-9/igt@core_hotunp...@unbind-rebind.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-dg2-9/igt@core_hotunp...@unbind-rebind.html
* igt@gem_lmem_swapping@parallel-random-engines@lmem0:
- {bat-dg2-8}:[PASS][3] -> [DMESG-WARN][4] +8 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-8/igt@gem_lmem_swapping@parallel-random-engi...@lmem0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-dg2-8/igt@gem_lmem_swapping@parallel-random-engi...@lmem0.html
* igt@i915_pm_rpm@module-reload:
- {bat-dg2-11}: [PASS][5] -> [DMESG-WARN][6] +6 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-11/igt@i915_pm_...@module-reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-dg2-11/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@workarounds:
- {bat-dg2-9}:[PASS][7] -> [INCOMPLETE][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-9/igt@i915_selftest@l...@workarounds.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-dg2-9/igt@i915_selftest@l...@workarounds.html
- {bat-dg2-11}: [PASS][9] -> [INCOMPLETE][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-dg2-11/igt@i915_selftest@l...@workarounds.html
- {bat-dg2-8}:[PASS][11] -> [INCOMPLETE][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-dg2-8/igt@i915_selftest@l...@workarounds.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-dg2-8/igt@i915_selftest@l...@workarounds.html
Known issues
Here are the changes found in Patchwork_109429v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@parallel-random-engines:
- bat-adlp-4: NOTRUN -> [SKIP][13] ([i915#4613]) +3 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-adlp-4/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@i915_pm_rps@basic-api:
- bat-adlp-4: NOTRUN -> [SKIP][14] ([i915#6621])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-adlp-4/igt@i915_pm_...@basic-api.html
* igt@kms_chamelium@common-hpd-after-suspend:
- bat-adlp-4: NOTRUN -> [SKIP][15] ([fdo#111827])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-adlp-4/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc:
- bat-adlp-4: NOTRUN -> [SKIP][16] ([i915#3546])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-adlp-4/igt@kms_pipe_crc_ba...@suspend-read-crc.html
* igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3301] /
[i915#3708])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-adlp-4/igt@prime_v...@basic-userptr.html
* igt@prime_vgem@basic-write:
- bat-adlp-4: NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-adlp-4/igt@prime_v...@basic-write.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][19] ([fdo#109271] / [i915#4312] /
[i915#5594])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@i915_pm_rpm@basic-pci-d3-state:
- bat-adlp-4: [DMESG-WARN][20] ([i915#7077]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109429v4/bat-adlp-4/igt@i915_pm_...@basic-pci-d3-state.html
[Intel-gfx] [PATCH 1/1] drm/i915: use the original Wa_14010685332 for PCH_ADP
Bspec: 33450 lists 2 sequences for Wa_14010685332.
The original sequence was implemented for PCH_ICP+
commit b896898c7369 implemented the tweaked verson for ICP, JSP and MCC
commit b8441b288d60 removed the orignal and applied the tweaked one to
all PCHs(CNP+), and caused regressions on ADP.
Fixes: b8441b288d60 ("drm/i915: Tweaked Wa_14010685332 for all PCHs")
Signed-off-by: James Xiong
---
drivers/gpu/drm/i915/display/intel_display_power.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 4c1de91e56ff..235b22205393 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -2199,9 +2199,14 @@ void intel_display_power_suspend_late(struct
drm_i915_private *i915)
hsw_enable_pc8(i915);
}
- /* Tweaked Wa_14010685332:cnp,icp,jsp,mcc,tgp,adp */
- if (INTEL_PCH_TYPE(i915) >= PCH_CNP && INTEL_PCH_TYPE(i915) < PCH_DG1)
+ /* Tweaked Wa_14010685332:cnp,icp,jsp,mcc,tgp */
+ if (INTEL_PCH_TYPE(i915) >= PCH_CNP && INTEL_PCH_TYPE(i915) < PCH_DG1) {
intel_de_rmw(i915, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS,
SBCLK_RUN_REFCLK_DIS);
+
+ /* Original Wa_14010685332: adp */
+ if (INTEL_PCH_TYPE(i915) == PCH_ADP)
+ intel_de_rmw(i915, SOUTH_CHICKEN1,
SBCLK_RUN_REFCLK_DIS, 0);
+ }
}
void intel_display_power_resume_early(struct drm_i915_private *i915)
@@ -2214,8 +2219,9 @@ void intel_display_power_resume_early(struct
drm_i915_private *i915)
hsw_disable_pc8(i915);
}
- /* Tweaked Wa_14010685332:cnp,icp,jsp,mcc,tgp,adp */
- if (INTEL_PCH_TYPE(i915) >= PCH_CNP && INTEL_PCH_TYPE(i915) < PCH_DG1)
+ /* Tweaked Wa_14010685332:cnp,icp,jsp,mcc,tgp */
+ if ((INTEL_PCH_TYPE(i915) >= PCH_CNP && INTEL_PCH_TYPE(i915) < PCH_DG1)
&&
+ INTEL_PCH_TYPE(i915) != PCH_ADP)
intel_de_rmw(i915, SOUTH_CHICKEN1, SBCLK_RUN_REFCLK_DIS, 0);
}
--
2.25.1
Re: [Intel-gfx] [PATCH] drm/i915/huc: fix leak of debug object in huc load fence on driver unload
Hi Daniele,
On Thu, Nov 10, 2022 at 04:56:51PM -0800, Daniele Ceraolo Spurio wrote:
> The fence is always initialized in huc_init_early, but the cleanup in
> huc_fini is only being run if HuC is enabled. This causes a leaking of
> the debug object when HuC is disabled/not supported, which can in turn
> trigger a warning if we try to register a new debug offset at the same
> address on driver reload.
>
> To fix the issue, make sure to always run the cleanup code.
>
> Reported-by: Tvrtko Ursulin
> Reported-by: Brian Norris
> Fixes: 27536e03271d ("drm/i915/huc: track delayed HuC load with a fence")
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
> Cc: Brian Norris
> Cc: Alan Previn
> Cc: John Harrison
> ---
>
> Note: I didn't manage to repro the reported warning, but I did confirm
> that we weren't correctly calling i915_sw_fence_fini and that this patch
> fixes that.
I *did* reproduce, and with this patch, I no longer reproduce. So:
Tested-by: Brian Norris
I see this differs very slightly from the draft version (which didn't
work for me):
https://lore.kernel.org/all/ac5fde11-c17d-8574-c938-c2278d53c...@intel.com/
so presumably that diff is the fix.
Thanks a bunch!
Brian
> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 12 +++-
> drivers/gpu/drm/i915/gt/uc/intel_uc.c | 1 +
> 2 files changed, 8 insertions(+), 5 deletions(-)
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/1] drm/i915: use the original Wa_14010685332 for PCH_ADP
== Series Details ==
Series: series starting with [1/1] drm/i915: use the original Wa_14010685332
for PCH_ADP
URL : https://patchwork.freedesktop.org/series/110988/
State : warning
== Summary ==
Error: dim checkpatch failed
8187aa163d26 drm/i915: use the original Wa_14010685332 for PCH_ADP
-:8: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b896898c7369 ("drm/i915: Tweaked
Wa_14010685332 for PCHs used on gen11 platforms")'
#8:
commit b896898c7369 implemented the tweaked verson for ICP, JSP and MCC
-:8: WARNING:TYPO_SPELLING: 'verson' may be misspelled - perhaps 'version'?
#8:
commit b896898c7369 implemented the tweaked verson for ICP, JSP and MCC
^^
-:9: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit b8441b288d60 ("drm/i915: Tweaked
Wa_14010685332 for all PCHs")'
#9:
commit b8441b288d60 removed the orignal and applied the tweaked one to
-:9: WARNING:TYPO_SPELLING: 'orignal' may be misspelled - perhaps 'original'?
#9:
commit b8441b288d60 removed the orignal and applied the tweaked one to
^^^
total: 2 errors, 2 warnings, 0 checks, 27 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915: use the original Wa_14010685332 for PCH_ADP
== Series Details ==
Series: series starting with [1/1] drm/i915: use the original Wa_14010685332
for PCH_ADP
URL : https://patchwork.freedesktop.org/series/110988/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12391 -> Patchwork_110988v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/index.html
Participating hosts (40 -> 39)
--
Additional (1): fi-hsw-4770
Missing(2): bat-dg1-6 bat-dg1-5
Known issues
Here are the changes found in Patchwork_110988v1 that come from known issues:
### CI changes ###
Possible fixes
* boot:
- fi-bxt-dsi: [FAIL][1] ([i915#7362]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12391/fi-bxt-dsi/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-bxt-dsi/boot.html
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600: [PASS][3] -> [FAIL][4] ([fdo#103375])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12391/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-rkl-11600/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- fi-bxt-dsi: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-bxt-dsi/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_render_tiled_blits@basic:
- fi-apl-guc: [PASS][7] -> [INCOMPLETE][8] ([i915#7056])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12391/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-apl-guc/igt@gem_render_tiled_bl...@basic.html
* igt@gem_softpin@allocator-basic-reserve:
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271]) +10 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-hsw-4770/igt@gem_soft...@allocator-basic-reserve.html
* igt@gem_tiled_blits@basic:
- fi-bxt-dsi: NOTRUN -> [SKIP][10] ([fdo#109271]) +13 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-hsw-4770:NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3012])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@execlists:
- fi-bsw-kefka: [PASS][12] -> [INCOMPLETE][13] ([i915#2940] /
[i915#6734])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12391/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-bsw-kefka/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@dp-crc-fast:
- fi-hsw-4770:NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-bxt-dsi: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +8
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [PASS][16] -> [FAIL][17] ([i915#6298])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12391/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_psr@sprite_plane_onoff:
- fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#1072]) +3
similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html
* igt@runner@aborted:
- fi-bsw-kefka: NOTRUN -> [FAIL][19] ([fdo#109271] / [i915#4312])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110988v1/fi-bsw-kefka/igt@run...@aborted.html
Possible fixes
* igt@fbdev@read:
- {bat-rpls-2}: [SKIP][20] ([i915#2582]) -> [PASS][21] +4 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12391/bat-rpls-2/igt@fb...@read.html
[21]:
Re: [Intel-gfx] [PULL] gvt-next
On 2022.11.15 10:36:59 -0500, Rodrigo Vivi wrote:
> On Fri, Nov 11, 2022 at 04:59:03PM +0800, Zhenyu Wang wrote:
> > Hi,
> >
> > Here's current accumulated changes in gvt-next. Sorry that I delayed
> > to refresh them on time for upstream...It contains mostly kernel doc,
> > typo fixes and small code cleanups, as details below.
> >
> > btw, one gvt change for next https://patchwork.freedesktop.org/patch/58/
> > is still pending, I need a backmerge from linus tree e.g with recent
> > vfio/mdev
> > consolidate change with gvt and Jason's fix for destroy device, to apply
> > Zhi's
> > change cleanly. Pls help on that.
> >
> > Thanks!
> > ---
> > The following changes since commit a6ebd538364b1e9e6048faaafbc0188172ed50c3:
> >
> > drm/i915/sdvo: Fix debug print (2022-10-28 14:46:21 +0300)
> >
> > are available in the Git repository at:
> >
> > https://github.com/intel/gvt-linux.git tags/gvt-next-2022-11-11
> >
> > for you to fetch changes up to 50468ca2e2e1ce882f060a8c263f678affe112db:
> >
> > drm/i915/gvt: Remove the unused function get_pt_type() (2022-11-08
> > 15:34:06 +0800)
> >
> >
> > gvt-next-2022-11-11
> >
> > - kernel doc fixes
> > - remove vgpu->released sanity check
> > - small clean up
> >
> >
> > Colin Ian King (1):
> > drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
>
> dim: d7e4e9579f01 ("drm/i915/reg: Fix spelling mistake "Unsupport" ->
> "Unsupported""): committer Signed-off-by missing.
>
> could you please fix this before we can merge this pr?
>
That should still be .mailmap issue for Colin's email...
But could we improve our dim script to grep mailmap in that case? So if s-o-b
mail is valid
in mailmap, we should still allow it, right?
> >
> > Jiapeng Chong (4):
> > drm/i915/gvt: Fix kernel-doc
> > drm/i915/gvt: Fix kernel-doc
> > drm/i915/gvt: Fix kernel-doc
> > drm/i915/gvt: Remove the unused function get_pt_type()
> >
> > Julia Lawall (1):
> > drm/i915/gvt: fix typo in comment
> >
> > Mauro Carvalho Chehab (1):
> > drm/i915: gvt: fix kernel-doc trivial warnings
> >
> > Paulo Miguel Almeida (1):
> > i915/gvt: remove hardcoded value on crc32_start calculation
> >
> > Zhi Wang (1):
> > drm/i915/gvt: remove the vgpu->released and its sanity check
> >
> > wangjianli (1):
> > drm/i915: fix repeated words in comments
> >
> > drivers/gpu/drm/i915/gvt/aperture_gm.c | 4 ++--
> > drivers/gpu/drm/i915/gvt/cfg_space.c| 2 +-
> > drivers/gpu/drm/i915/gvt/dmabuf.h | 2 +-
> > drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
> > drivers/gpu/drm/i915/gvt/gtt.c | 9 ++---
> > drivers/gpu/drm/i915/gvt/gvt.h | 2 --
> > drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
> > drivers/gpu/drm/i915/gvt/kvmgt.c| 4
> > drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
> > drivers/gpu/drm/i915/gvt/page_track.c | 2 +-
> > drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
> > 11 files changed, 14 insertions(+), 25 deletions(-)
>
>
signature.asc
Description: PGP signature
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix timeout handling when retiring requests
== Series Details == Series: drm/i915: Fix timeout handling when retiring requests URL : https://patchwork.freedesktop.org/series/110964/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12389_full -> Patchwork_110964v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_110964v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110964v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 9) -- Missing(1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110964v1_full: ### IGT changes ### Possible regressions * igt@gem_eio@reset-stress: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-skl4/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-skl9/igt@gem_...@reset-stress.html Known issues Here are the changes found in Patchwork_110964v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-glk: ([PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [FAIL][24], [FAIL][25], [PASS][26], [PASS][27]) ([i915#4392]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk1/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk1/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk2/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk2/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk2/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk3/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk3/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk3/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk6/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk6/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk7/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk7/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk8/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk8/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk8/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk9/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk9/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12389/shard-glk9/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-glk9/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-glk9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-glk9/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-glk8/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-glk8/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-glk8/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-glk7/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-glk7/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110964v1/shard-glk
Re: [Intel-gfx] [PULL] gvt-next
On Thu, 2022-11-17 at 11:02 +0800, Zhenyu Wang wrote:
> On 2022.11.15 10:36:59 -0500, Rodrigo Vivi wrote:
> > On Fri, Nov 11, 2022 at 04:59:03PM +0800, Zhenyu Wang wrote:
> > > Hi,
> > >
> > > Here's current accumulated changes in gvt-next. Sorry that I
> > > delayed
> > > to refresh them on time for upstream...It contains mostly kernel
> > > doc,
> > > typo fixes and small code cleanups, as details below.
> > >
> > > btw, one gvt change for next
> > > https://patchwork.freedesktop.org/patch/58/
> > > is still pending, I need a backmerge from linus tree e.g with
> > > recent vfio/mdev
> > > consolidate change with gvt and Jason's fix for destroy device,
> > > to apply Zhi's
> > > change cleanly. Pls help on that.
> > >
> > > Thanks!
> > > ---
> > > The following changes since commit
> > > a6ebd538364b1e9e6048faaafbc0188172ed50c3:
> > >
> > > drm/i915/sdvo: Fix debug print (2022-10-28 14:46:21 +0300)
> > >
> > > are available in the Git repository at:
> > >
> > > https://github.com/intel/gvt-linux.git tags/gvt-next-2022-11-11
> > >
> > > for you to fetch changes up to
> > > 50468ca2e2e1ce882f060a8c263f678affe112db:
> > >
> > > drm/i915/gvt: Remove the unused function get_pt_type() (2022-
> > > 11-08 15:34:06 +0800)
> > >
> > >
> > > gvt-next-2022-11-11
> > >
> > > - kernel doc fixes
> > > - remove vgpu->released sanity check
> > > - small clean up
> > >
> > >
> > > Colin Ian King (1):
> > > drm/i915/reg: Fix spelling mistake "Unsupport" ->
> > > "Unsupported"
> >
> > dim: d7e4e9579f01 ("drm/i915/reg: Fix spelling mistake "Unsupport"
> > -> "Unsupported""): committer Signed-off-by missing.
> >
> > could you please fix this before we can merge this pr?
> >
>
> That should still be .mailmap issue for Colin's email...
> But could we improve our dim script to grep mailmap in that case? So
> if s-o-b mail is valid
> in mailmap, we should still allow it, right?
Based on what I could verify the commiter signature is really not
there. It looks like you later forced a rebase and while
rebasing you forgot to re-sign everything.
We need to fix this in your tree to avoid propagating that to other
trees later:
From tig view:
Commit: Zhenyu Wang
CommitDate: Tue Nov 8 15:04:53 2022 +0800
drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
There is a spelling mistake in a gvt_vgpu_err error message. Fix
it.
Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with
gvt_vgpu_err")
Signed-off-by: Colin Ian King
Signed-off-by: Zhi Wang
Link:
http://patchwork.freedesktop.org/patch/msgid/20220315202449.2952845-1-colin.i.k...@gmail.com
Reviewed-by: Zhi Wang
no signature from you.
>
> > >
> > > Jiapeng Chong (4):
> > > drm/i915/gvt: Fix kernel-doc
> > > drm/i915/gvt: Fix kernel-doc
> > > drm/i915/gvt: Fix kernel-doc
> > > drm/i915/gvt: Remove the unused function get_pt_type()
> > >
> > > Julia Lawall (1):
> > > drm/i915/gvt: fix typo in comment
> > >
> > > Mauro Carvalho Chehab (1):
> > > drm/i915: gvt: fix kernel-doc trivial warnings
> > >
> > > Paulo Miguel Almeida (1):
> > > i915/gvt: remove hardcoded value on crc32_start calculation
> > >
> > > Zhi Wang (1):
> > > drm/i915/gvt: remove the vgpu->released and its sanity
> > > check
> > >
> > > wangjianli (1):
> > > drm/i915: fix repeated words in comments
> > >
> > > drivers/gpu/drm/i915/gvt/aperture_gm.c | 4 ++--
> > > drivers/gpu/drm/i915/gvt/cfg_space.c | 2 +-
> > > drivers/gpu/drm/i915/gvt/dmabuf.h | 2 +-
> > > drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
> > > drivers/gpu/drm/i915/gvt/gtt.c | 9 ++---
> > > drivers/gpu/drm/i915/gvt/gvt.h | 2 --
> > > drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
> > > drivers/gpu/drm/i915/gvt/kvmgt.c | 4
> > > drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
> > > drivers/gpu/drm/i915/gvt/page_track.c | 2 +-
> > > drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
> > > 11 files changed, 14 insertions(+), 25 deletions(-)
> >
> >
Re: [Intel-gfx] [PULL] gvt-next
On 2022.11.17 03:37:17 +, Vivi, Rodrigo wrote:
> On Thu, 2022-11-17 at 11:02 +0800, Zhenyu Wang wrote:
> > On 2022.11.15 10:36:59 -0500, Rodrigo Vivi wrote:
> > > On Fri, Nov 11, 2022 at 04:59:03PM +0800, Zhenyu Wang wrote:
> > > > Hi,
> > > >
> > > > Here's current accumulated changes in gvt-next. Sorry that I
> > > > delayed
> > > > to refresh them on time for upstream...It contains mostly kernel
> > > > doc,
> > > > typo fixes and small code cleanups, as details below.
> > > >
> > > > btw, one gvt change for next
> > > > https://patchwork.freedesktop.org/patch/58/
> > > > is still pending, I need a backmerge from linus tree e.g with
> > > > recent vfio/mdev
> > > > consolidate change with gvt and Jason's fix for destroy device,
> > > > to apply Zhi's
> > > > change cleanly. Pls help on that.
> > > >
> > > > Thanks!
> > > > ---
> > > > The following changes since commit
> > > > a6ebd538364b1e9e6048faaafbc0188172ed50c3:
> > > >
> > > > ?? drm/i915/sdvo: Fix debug print (2022-10-28 14:46:21 +0300)
> > > >
> > > > are available in the Git repository at:
> > > >
> > > > ?? https://github.com/intel/gvt-linux.git??tags/gvt-next-2022-11-11
> > > >
> > > > for you to fetch changes up to
> > > > 50468ca2e2e1ce882f060a8c263f678affe112db:
> > > >
> > > > ?? drm/i915/gvt: Remove the unused function get_pt_type() (2022-
> > > > 11-08 15:34:06 +0800)
> > > >
> > > >
> > > > gvt-next-2022-11-11
> > > >
> > > > - kernel doc fixes
> > > > - remove vgpu->released sanity check
> > > > - small clean up
> > > >
> > > >
> > > > Colin Ian King (1):
> > > > ?? drm/i915/reg: Fix spelling mistake "Unsupport" ->
> > > > "Unsupported"
> > >
> > > dim: d7e4e9579f01 ("drm/i915/reg: Fix spelling mistake "Unsupport"
> > > -> "Unsupported""): committer Signed-off-by missing.
> > >
> > > could you please fix this before we can merge this pr?
> > >
> >
> > That should still be .mailmap issue for Colin's email...
> > But could we improve our dim script to grep mailmap in that case? So
> > if s-o-b mail is valid
> > in mailmap, we should still allow it, right?
>
> Based on what I could verify the commiter signature is really not
> there. It looks like you later forced a rebase and while
> rebasing you forgot to re-sign everything.
>
Oops! Sorry for that. I'll redo this.
> We need to fix this in your tree to avoid propagating that to other
> trees later:
>
> From tig view:
> Commit: Zhenyu Wang
> CommitDate: Tue Nov 8 15:04:53 2022 +0800
>
> drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported"
>
> There is a spelling mistake in a gvt_vgpu_err error message. Fix
> it.
>
> Fixes: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with
> gvt_vgpu_err")
> Signed-off-by: Colin Ian King
> Signed-off-by: Zhi Wang
> Link:
> http://patchwork.freedesktop.org/patch/msgid/20220315202449.2952845-1-colin.i.k...@gmail.com
> Reviewed-by: Zhi Wang
>
> no signature from you.
>
> >
> > > >
> > > > Jiapeng Chong (4):
> > > > ?? drm/i915/gvt: Fix kernel-doc
> > > > ?? drm/i915/gvt: Fix kernel-doc
> > > > ?? drm/i915/gvt: Fix kernel-doc
> > > > ?? drm/i915/gvt: Remove the unused function get_pt_type()
> > > >
> > > > Julia Lawall (1):
> > > > ?? drm/i915/gvt: fix typo in comment
> > > >
> > > > Mauro Carvalho Chehab (1):
> > > > ?? drm/i915: gvt: fix kernel-doc trivial warnings
> > > >
> > > > Paulo Miguel Almeida (1):
> > > > ?? i915/gvt: remove hardcoded value on crc32_start calculation
> > > >
> > > > Zhi Wang (1):
> > > > ?? drm/i915/gvt: remove the vgpu->released and its sanity
> > > > check
> > > >
> > > > wangjianli (1):
> > > > ?? drm/i915: fix repeated words in comments
> > > >
> > > > ??drivers/gpu/drm/i915/gvt/aperture_gm.c?? | 4 ++--
> > > > ??drivers/gpu/drm/i915/gvt/cfg_space.c?? | 2 +-
> > > > ??drivers/gpu/drm/i915/gvt/dmabuf.h | 2 +-
> > > > ??drivers/gpu/drm/i915/gvt/firmware.c | 2 +-
> > > > ??drivers/gpu/drm/i915/gvt/gtt.c?? | 9 ++---
> > > > ??drivers/gpu/drm/i915/gvt/gvt.h?? | 2 --
> > > > ??drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
> > > > ??drivers/gpu/drm/i915/gvt/kvmgt.c?? | 4
> > > > ??drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
> > > > ??drivers/gpu/drm/i915/gvt/page_track.c | 2 +-
> > > > ??drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++---
> > > > ??11 files changed, 14 insertions(+), 25 deletions(-)
> > >
> > >
>
signature.asc
Description: PGP signature
[Intel-gfx] [PATCH v3] drm/i915/display: Don't disable DDI/Transcoder when setting phy test pattern
Bspecs has updated recently to remove the restriction to disable
DDI/Transcoder before setting PHY test pattern. This update is to
address PHY compliance test failures observed on a port with LTTPR.
The issue is that when Transc. is disabled, the main link signals fed
to LTTPR will be dropped invalidating link training, which will affect
the quality of the phy test pattern when the transcoder is enabled again.
v2: Update commit message (Clint)
v3: Add missing Signed-off in v2
Bspec: 50482
Cc: Imre Deak
Cc: Clint Taylor
CC: Jani Nikula
Tested-by: Khaled Almahallawy
Signed-off-by: Khaled Almahallawy
Reviewed-by: Clint Taylor
---
drivers/gpu/drm/i915/display/intel_dp.c | 59 -
1 file changed, 59 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 914161d7d122..16cf961b4d1a 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -3679,61 +3679,6 @@ static void intel_dp_phy_pattern_update(struct intel_dp
*intel_dp,
}
}
-static void
-intel_dp_autotest_phy_ddi_disable(struct intel_dp *intel_dp,
- const struct intel_crtc_state *crtc_state)
-{
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- struct drm_device *dev = dig_port->base.base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
- enum pipe pipe = crtc->pipe;
- u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value;
-
- trans_ddi_func_ctl_value = intel_de_read(dev_priv,
-TRANS_DDI_FUNC_CTL(pipe));
- trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
- dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
-
- trans_ddi_func_ctl_value &= ~(TRANS_DDI_FUNC_ENABLE |
- TGL_TRANS_DDI_PORT_MASK);
- trans_conf_value &= ~PIPECONF_ENABLE;
- dp_tp_ctl_value &= ~DP_TP_CTL_ENABLE;
-
- intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
- intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
- trans_ddi_func_ctl_value);
- intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
-}
-
-static void
-intel_dp_autotest_phy_ddi_enable(struct intel_dp *intel_dp,
-const struct intel_crtc_state *crtc_state)
-{
- struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
- struct drm_device *dev = dig_port->base.base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
- enum port port = dig_port->base.port;
- struct intel_crtc *crtc = to_intel_crtc(dig_port->base.base.crtc);
- enum pipe pipe = crtc->pipe;
- u32 trans_ddi_func_ctl_value, trans_conf_value, dp_tp_ctl_value;
-
- trans_ddi_func_ctl_value = intel_de_read(dev_priv,
-TRANS_DDI_FUNC_CTL(pipe));
- trans_conf_value = intel_de_read(dev_priv, PIPECONF(pipe));
- dp_tp_ctl_value = intel_de_read(dev_priv, TGL_DP_TP_CTL(pipe));
-
- trans_ddi_func_ctl_value |= TRANS_DDI_FUNC_ENABLE |
- TGL_TRANS_DDI_SELECT_PORT(port);
- trans_conf_value |= PIPECONF_ENABLE;
- dp_tp_ctl_value |= DP_TP_CTL_ENABLE;
-
- intel_de_write(dev_priv, PIPECONF(pipe), trans_conf_value);
- intel_de_write(dev_priv, TGL_DP_TP_CTL(pipe), dp_tp_ctl_value);
- intel_de_write(dev_priv, TRANS_DDI_FUNC_CTL(pipe),
- trans_ddi_func_ctl_value);
-}
-
static void intel_dp_process_phy_request(struct intel_dp *intel_dp,
const struct intel_crtc_state
*crtc_state)
{
@@ -3752,14 +3697,10 @@ static void intel_dp_process_phy_request(struct
intel_dp *intel_dp,
intel_dp_get_adjust_train(intel_dp, crtc_state, DP_PHY_DPRX,
link_status);
- intel_dp_autotest_phy_ddi_disable(intel_dp, crtc_state);
-
intel_dp_set_signal_levels(intel_dp, crtc_state, DP_PHY_DPRX);
intel_dp_phy_pattern_update(intel_dp, crtc_state);
- intel_dp_autotest_phy_ddi_enable(intel_dp, crtc_state);
-
drm_dp_dpcd_write(&intel_dp->aux, DP_TRAINING_LANE0_SET,
intel_dp->train_set, crtc_state->lane_count);
--
2.25.1
Re: [Intel-gfx] [PATCH 1/7] drm: mark drm.debug-on-dyndbg as BROKEN for now
On Fri, Nov 11, 2022 at 03:17:09PM -0700, Jim Cromie wrote: > drm.debug-on-dyndbg has a regression, due to a chicken-egg > initialization problem: > > 1- modprobe i915 >i915 needs drm.ko, which is loaded 1st > > 2- "modprobe drm drm.debug=0x1ff" (virtual/implied) >drm.debug is set post-initialization, from boot-args etc > > 3- `modprobe i915` finishes > > W/O drm.debug-on-dyndbg that just works, because all drm_dbg* > callsites use drm_debug_enabled() to check __drm_debug & DEM_UT_ > before printing. > > But the whole point of drm.debug-on-dyndbg is to avoid that runtime > test, by enabling (at post-modinit) a static-key at each callsite in > the just-loaded module. > > And since drm.ko is loaded before all dependent modules, none are > "just-loaded", and no drm.debug callsites are present yet, except > those in drm.ko itself. > > Signed-off-by: Jim Cromie > --- > drivers/gpu/drm/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig > index 34f5a092c99e..0d1e59e6bb7e 100644 > --- a/drivers/gpu/drm/Kconfig > +++ b/drivers/gpu/drm/Kconfig > @@ -54,6 +54,7 @@ config DRM_DEBUG_MM > config DRM_USE_DYNAMIC_DEBUG > bool "use dynamic debug to implement drm.debug" > default y > + depends on BROKEN # chicken-egg initial enable problem > depends on DRM > depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE > depends on JUMP_LABEL > -- > 2.38.1 This should go through the drm tree now. The rest probably should also go that way and not through my tree as well. thanks, greg k-h
Re: [Intel-gfx] [PATCH 0/7] DYNAMIC_DEBUG fixups for rc
On Fri, Nov 11, 2022 at 03:17:08PM -0700, Jim Cromie wrote: > hi Jason, Greg, DRM-folk, > > drm.debug-on-dyndbg has a regression due to a chicken-&-egg problem; > drm.debug is applied to enable dyndbg callsites before the dependent > modules' callsites are available to be enabled. > > My "fixes" are unready, so lets just mark it BROKEN for now. > > Meanwhile, heres some other fixes, a comment tweak, a proof of > non-bug, an internal simplification, and a cleanup/improvement to the > main macro (API): > > Split DECLARE_DYNDBG_CLASSMAP in 1/2; REFERENCE_DYNDBG_CLASSMAP now > refers to a classmap DECLARE'd just once. I think this gives a path > away from the coordination-by-identical-classmaps "feature" that Jani > and others thought was "weird" (my term). > Acked-by: Greg Kroah-Hartman
Re: [Intel-gfx] [PULL] gvt-next
On 2022.11.17 03:37:17 +, Vivi, Rodrigo wrote: > On Thu, 2022-11-17 at 11:02 +0800, Zhenyu Wang wrote: > > On 2022.11.15 10:36:59 -0500, Rodrigo Vivi wrote: > > > On Fri, Nov 11, 2022 at 04:59:03PM +0800, Zhenyu Wang wrote: > > > > Hi, > > > > > > > > Here's current accumulated changes in gvt-next. Sorry that I > > > > delayed > > > > to refresh them on time for upstream...It contains mostly kernel > > > > doc, > > > > typo fixes and small code cleanups, as details below. > > > > > > > > btw, one gvt change for next > > > > https://patchwork.freedesktop.org/patch/58/ > > > > is still pending, I need a backmerge from linus tree e.g with > > > > recent vfio/mdev > > > > consolidate change with gvt and Jason's fix for destroy device, > > > > to apply Zhi's > > > > change cleanly. Pls help on that. > > > > > > Based on what I could verify the commiter signature is really not > there. It looks like you later forced a rebase and while > rebasing you forgot to re-sign everything. > Hi, pls re-pull this one. thanks! --- The following changes since commit a6ebd538364b1e9e6048faaafbc0188172ed50c3: drm/i915/sdvo: Fix debug print (2022-10-28 14:46:21 +0300) are available in the Git repository at: https://github.com/intel/gvt-linux.git tags/gvt-next-2022-11-17 for you to fetch changes up to 04ec334e1a0381c3305da4d277cef9250769ca43: drm/i915/gvt: Remove the unused function get_pt_type() (2022-11-17 14:07:09 +0800) gvt-next-2022-11-17 - kernel doc fixes - remove vgpu->released sanity check - small clean up Colin Ian King (1): drm/i915/reg: Fix spelling mistake "Unsupport" -> "Unsupported" Jiapeng Chong (4): drm/i915/gvt: Fix kernel-doc drm/i915/gvt: Fix kernel-doc drm/i915/gvt: Fix kernel-doc drm/i915/gvt: Remove the unused function get_pt_type() Julia Lawall (1): drm/i915/gvt: fix typo in comment Mauro Carvalho Chehab (1): drm/i915: gvt: fix kernel-doc trivial warnings Paulo Miguel Almeida (1): i915/gvt: remove hardcoded value on crc32_start calculation Zhi Wang (1): drm/i915/gvt: remove the vgpu->released and its sanity check wangjianli (1): drm/i915: fix repeated words in comments drivers/gpu/drm/i915/gvt/aperture_gm.c | 4 ++-- drivers/gpu/drm/i915/gvt/cfg_space.c| 2 +- drivers/gpu/drm/i915/gvt/dmabuf.h | 2 +- drivers/gpu/drm/i915/gvt/firmware.c | 2 +- drivers/gpu/drm/i915/gvt/gtt.c | 9 ++--- drivers/gpu/drm/i915/gvt/gvt.h | 2 -- drivers/gpu/drm/i915/gvt/handlers.c | 4 ++-- drivers/gpu/drm/i915/gvt/kvmgt.c| 4 drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +- drivers/gpu/drm/i915/gvt/page_track.c | 2 +- drivers/gpu/drm/i915/gvt/vgpu.c | 6 +++--- 11 files changed, 14 insertions(+), 25 deletions(-) signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: Enable Idle Messaging for GSC CS
Hi Rodrigo,
On 15-11-2022 20:57, Rodrigo Vivi wrote:
On Tue, Nov 15, 2022 at 07:14:40PM +0530, Badal Nilawar wrote:
From: Vinay Belgaumkar
By defaut idle mesaging is disabled for GSC CS so to unblock RC6
entry on media tile idle messaging need to be enabled.
v2:
- Fix review comments (Vinay)
- Set GSC idle hysterisis to 5 us (Badal)
btw, no need for the cover letter in single/standalone patches.
This history here is enough.
Sure, next revision I will take care of this.
Bspec: 71496
Cc: Daniele Ceraolo Spurio
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 18 ++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index b0a4a2dbe3ee..5522885b2db0 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -15,6 +15,22 @@
#include "intel_rc6.h"
#include "intel_ring.h"
#include "shmem_utils.h"
+#include "intel_gt_regs.h"
+
+static void intel_gsc_idle_msg_enable(struct intel_engine_cs *engine)
+{
+ struct drm_i915_private *i915 = engine->i915;
+
+ if (IS_METEORLAKE(i915) && engine->id == GSC0) {
+ intel_uncore_write(engine->gt->uncore,
+ RC_PSMI_CTRL_GSCCS,
+ _MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
+ /* 5 us hysterisis */
typo
+ intel_uncore_write(engine->gt->uncore,
+ PWRCTX_MAXCNT_GSCCS,
+ 0xA);
you said 5 above, but used 10 here, why?
Bspec:71496 specifies 0xA = 5us.
+ }
+}
static void dbg_poison_ce(struct intel_context *ce)
{
@@ -275,6 +291,8 @@ void intel_engine_init__pm(struct intel_engine_cs *engine)
intel_wakeref_init(&engine->wakeref, rpm, &wf_ops);
intel_engine_init_heartbeat(engine);
+
+ intel_gsc_idle_msg_enable(engine);
}
/**
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 07031e03f80c..20472eb15364 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -913,6 +913,10 @@
#define MSG_IDLE_FW_MASK REG_GENMASK(13, 9)
#define MSG_IDLE_FW_SHIFT9
+#define RC_PSMI_CTRL_GSCCS _MMIO(0x11a050)
+#define IDLE_MSG_DISABLE BIT(0)
REG_BIT should be preferred.
I will take care of this and above comments in next revision.
Regards,
Badal
+#define PWRCTX_MAXCNT_GSCCS_MMIO(0x11a054)
+
#define FORCEWAKE_MEDIA_GEN9 _MMIO(0xa270)
#define FORCEWAKE_RENDER_GEN9 _MMIO(0xa278)
--
2.25.1
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Don't disable DDI/Transcoder when setting phy test pattern (rev4)
== Series Details == Series: drm/i915/display: Don't disable DDI/Transcoder when setting phy test pattern (rev4) URL : https://patchwork.freedesktop.org/series/108636/ State : success == Summary == CI Bug Log - changes from CI_DRM_12391 -> Patchwork_108636v4 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/index.html Participating hosts (40 -> 27) -- Additional (1): fi-hsw-4770 Missing(14): bat-dg1-7 bat-dg1-6 bat-dg1-5 bat-dg2-8 bat-adlm-1 bat-dg2-9 fi-cfl-guc bat-adlp-6 bat-adlp-4 bat-adln-1 bat-rplp-1 bat-rpls-2 bat-dg2-11 bat-jsl-1 Known issues Here are the changes found in Patchwork_108636v4 that come from known issues: ### CI changes ### Possible fixes * boot: - fi-bxt-dsi: [FAIL][1] ([i915#7362]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12391/fi-bxt-dsi/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-bxt-dsi/boot.html ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-bxt-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@verify-random: - fi-bxt-dsi: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-bxt-dsi/igt@gem_lmem_swapp...@verify-random.html * igt@gem_tiled_blits@basic: - fi-bxt-dsi: NOTRUN -> [SKIP][5] ([fdo#109271]) +13 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-bxt-dsi/igt@gem_tiled_bl...@basic.html * igt@i915_pm_backlight@basic-brightness: - fi-hsw-4770:NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3012]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-hsw-4770/igt@i915_pm_backli...@basic-brightness.html * igt@kms_addfb_basic@addfb25-y-tiled-small-legacy: - fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271]) +10 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-hsw-4770/igt@kms_addfb_ba...@addfb25-y-tiled-small-legacy.html * igt@kms_chamelium@dp-crc-fast: - fi-hsw-4770:NOTRUN -> [SKIP][8] ([fdo#109271] / [fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-hsw-4770/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-edid-read: - fi-bxt-dsi: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-bxt-dsi/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_psr@sprite_plane_onoff: - fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#1072]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-hsw-4770/igt@kms_psr@sprite_plane_onoff.html Warnings * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: [FAIL][11] ([fdo#103375]) -> [INCOMPLETE][12] ([i915#4817]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12391/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html [fdo#103375]: https://bugs.freedesktop.org/show_bug.cgi?id=103375 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#3012]: https://gitlab.freedesktop.org/drm/intel/issues/3012 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#4817]: https://gitlab.freedesktop.org/drm/intel/issues/4817 [i915#7362]: https://gitlab.freedesktop.org/drm/intel/issues/7362 Build changes - * Linux: CI_DRM_12391 -> Patchwork_108636v4 CI-20190529: 20190529 CI_DRM_12391: c413e36ac30e0c84e28f5e9add894346b9450755 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7062: 6539ea5fe17fce683133c45f07fac316593ee1f7 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_108636v4: c413e36ac30e0c84e28f5e9add894346b9450755 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits f5b335189ab5 drm/i915/display: Don't disable DDI/Transcoder when setting phy test pattern == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108636v4/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for mei: add timeout to send (rev3)
== Series Details == Series: mei: add timeout to send (rev3) URL : https://patchwork.freedesktop.org/series/110495/ State : success == Summary == CI Bug Log - changes from CI_DRM_12390_full -> Patchwork_110495v3_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_110495v3_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [FAIL][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) ([i915#4392]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk9/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk9/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk9/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk8/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk8/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk8/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk3/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk3/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk2/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk1/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk2/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk2/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-glk1/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk6/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk6/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk6/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk7/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk9/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk8/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk8/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk8/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk8/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk9/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk9/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk1/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk1/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk2/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk2/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110495v3/shard-glk2/boot.html
[Intel-gfx] linux-next: build failure after merge of the drm-misc tree
Hi all,
After merging the drm-misc tree, today's linux-next build (powerpc
ppc44x_defconfig) failed like this:
ld: drivers/video/fbdev/core/fbmon.o: in function `fb_modesetting_disabled':
fbmon.c:(.text+0x1e4): multiple definition of `fb_modesetting_disabled';
drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
ld: drivers/video/fbdev/core/fbcmap.o: in function `fb_modesetting_disabled':
fbcmap.c:(.text+0x478): multiple definition of `fb_modesetting_disabled';
drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
ld: drivers/video/fbdev/core/fbsysfs.o: in function `fb_modesetting_disabled':
fbsysfs.c:(.text+0xb64): multiple definition of `fb_modesetting_disabled';
drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
ld: drivers/video/fbdev/core/modedb.o: in function `fb_modesetting_disabled':
modedb.c:(.text+0x129c): multiple definition of `fb_modesetting_disabled';
drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
ld: drivers/video/fbdev/core/fbcvt.o: in function `fb_modesetting_disabled':
fbcvt.c:(.text+0x0): multiple definition of `fb_modesetting_disabled';
drivers/video/fbdev/core/fbmem.o:fbmem.c:(.text+0x1bac): first defined here
Caused by commit
0ba2fa8cbd29 ("fbdev: Add support for the nomodeset kernel parameter")
This build does not have CONFIG_VIDEO_NOMODESET set.
I applied the following patch for today.
From 63f957a050c62478ed1348c5b204bc65c68df4d7 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell
Date: Thu, 17 Nov 2022 18:19:22 +1100
Subject: [PATCH] fix up for "fbdev: Add support for the nomodeset kernel
parameter"
Signed-off-by: Stephen Rothwell
---
include/linux/fb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 3a822e4357b1..ea421724f733 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -807,7 +807,7 @@ extern int fb_find_mode(struct fb_var_screeninfo *var,
#if defined(CONFIG_VIDEO_NOMODESET)
bool fb_modesetting_disabled(const char *drvname);
#else
-bool fb_modesetting_disabled(const char *drvname)
+static inline bool fb_modesetting_disabled(const char *drvname)
{
return false;
}
--
2.35.1
--
Cheers,
Stephen Rothwell
pgpXVU0mipOSU.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.BUILD: failure for linux-next: build failure after merge of the drm-misc tree
== Series Details == Series: linux-next: build failure after merge of the drm-misc tree URL : https://patchwork.freedesktop.org/series/111006/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/111006/revisions/1/mbox/ not applied Patch is empty. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To record the empty patch as an empty commit, run "git am --allow-empty". To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling
== Series Details == Series: series starting with [1/3] drm/i915/display: Add missing checks for cdclk crawling URL : https://patchwork.freedesktop.org/series/110970/ State : success == Summary == CI Bug Log - changes from CI_DRM_12390_full -> Patchwork_110970v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (9 -> 9) -- No changes in participating hosts Known issues Here are the changes found in Patchwork_110970v1_full that come from known issues: ### IGT changes ### Issues hit * igt@feature_discovery@display-2x: - shard-tglb: NOTRUN -> [SKIP][1] ([i915#1839]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-tglb7/igt@feature_discov...@display-2x.html * igt@gem_create@create-massive: - shard-skl: NOTRUN -> [DMESG-WARN][2] ([i915#4991]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-skl2/igt@gem_cre...@create-massive.html * igt@gem_exec_balancer@parallel-keep-in-fence: - shard-iclb: [PASS][3] -> [SKIP][4] ([i915#4525]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-iclb1/igt@gem_exec_balan...@parallel-keep-in-fence.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-iclb6/igt@gem_exec_balan...@parallel-keep-in-fence.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][5] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-iclb1/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-tglb: [PASS][6] -> [SKIP][7] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-tglb3/igt@gem_huc_c...@huc-copy.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-tglb6/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@random-engines: - shard-skl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-skl1/igt@gem_lmem_swapp...@random-engines.html * igt@gem_userptr_blits@unsync-overlap: - shard-skl: NOTRUN -> [SKIP][9] ([fdo#109271]) +185 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-skl2/igt@gem_userptr_bl...@unsync-overlap.html * igt@gem_userptr_blits@vma-merge: - shard-skl: NOTRUN -> [FAIL][10] ([i915#3318]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-skl1/igt@gem_userptr_bl...@vma-merge.html * igt@gen7_exec_parse@chained-batch: - shard-tglb: NOTRUN -> [SKIP][11] ([fdo#109289]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-tglb7/igt@gen7_exec_pa...@chained-batch.html * igt@gen9_exec_parse@allowed-single: - shard-apl: [PASS][12] -> [DMESG-WARN][13] ([i915#5566] / [i915#716]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-apl7/igt@gen9_exec_pa...@allowed-single.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-apl2/igt@gen9_exec_pa...@allowed-single.html * igt@i915_module_load@load: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#6227]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-skl2/igt@i915_module_l...@load.html * igt@i915_pm_dc@dc6-dpms: - shard-tglb: NOTRUN -> [FAIL][15] ([i915#3989] / [i915#454]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-tglb7/igt@i915_pm...@dc6-dpms.html * igt@i915_pm_dc@dc6-psr: - shard-skl: NOTRUN -> [FAIL][16] ([i915#3989] / [i915#454]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-skl4/igt@i915_pm...@dc6-psr.html * igt@i915_pm_rc6_residency@rc6-idle@vcs0: - shard-skl: NOTRUN -> [WARN][17] ([i915#1804]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-skl3/igt@i915_pm_rc6_residency@rc6-i...@vcs0.html * igt@i915_pm_rpm@system-suspend: - shard-tglb: [PASS][18] -> [INCOMPLETE][19] ([i915#2411]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-tglb8/igt@i915_pm_...@system-suspend.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-tglb8/igt@i915_pm_...@system-suspend.html * igt@i915_selftest@live@gt_heartbeat: - shard-skl: [PASS][20] -> [DMESG-FAIL][21] ([i915#5334]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12390/shard-skl7/igt@i915_selftest@live@gt_heartbeat.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110970v1/shard-skl7/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_big_fb@yf-tiled-max-hw-stride-32bpp-rotate-180-async-flip: - shard-tglb: NOTRUN -> [SKIP][22] ([fdo#
