Re: [Intel-gfx] [PATCH v2 05/27] drm/i915/gvt: Verify VFIO-pinned page is THP when shadowing 2M gtt entry
On Fri, Mar 10, 2023 at 04:22:36PM -0800, Sean Christopherson wrote:
> When shadowing a GTT entry with a 2M page, explicitly verify that the
> first page pinned by VFIO is a transparent hugepage instead of assuming
> that page observed by is_2MB_gtt_possible() is the same page pinned by
> vfio_pin_pages(). E.g. if userspace is doing something funky with the
> guest's memslots, or if the page is demoted between is_2MB_gtt_possible()
> and vfio_pin_pages().
>
> This is more of a performance optimization than a bug fix as the check
> for contiguous struct pages should guard against incorrect mapping (even
> though assuming struct pages are virtually contiguous is wrong).
>
> The real motivation for explicitly checking for a transparent hugepage
> after pinning is that it will reduce the risk of introducing a bug in a
> future fix for a page refcount leak (KVMGT doesn't put the reference
> acquired by gfn_to_pfn()), and eventually will allow KVMGT to stop using
> KVM's gfn_to_pfn() altogether.
>
> Signed-off-by: Sean Christopherson
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 8ae7039b3683..90997cc385b4 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -159,11 +159,25 @@ static int gvt_pin_guest_page(struct intel_vgpu *vgpu,
> unsigned long gfn,
> goto err;
> }
>
> - if (npage == 0)
> - base_page = cur_page;
> + if (npage == 0) {
> + /*
> + * Bail immediately to avoid unnecessary pinning when
> + * trying to shadow a 2M page and the host page isn't
> + * a transparent hugepage.
> + *
> + * TODO: support other type hugepages, e.g. HugeTLB.
> + */
> + if (size == I915_GTT_PAGE_SIZE_2M &&
> + !PageTransHuge(cur_page))
Maybe the checking of PageTransHuge(cur_page) and bailing out is not necessary.
If a page is not transparent huge, but there are 512 contigous 4K
pages, I think it's still good to map them in IOMMU in 2M.
See vfio_pin_map_dma() who does similar things.
> + ret = -EIO;
> + else
> + base_page = cur_page;
> + }
> else if (base_page + npage != cur_page) {
> gvt_vgpu_err("The pages are not continuous\n");
> ret = -EINVAL;
> + }
> + if (ret < 0) {
> npage++;
> goto err;
> }
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/audio: update audio keepalive clock values
== Series Details ==
Series: drm/i915/audio: update audio keepalive clock values
URL : https://patchwork.freedesktop.org/series/115300/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12872_full -> Patchwork_115300v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 7)
--
Missing(1): shard-rkl0
Known issues
Here are the changes found in Patchwork_115300v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-apl7/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-apl4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@verify:
- shard-apl: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-apl2/igt@gem_lmem_swapp...@verify.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#3323])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-glk7/igt@gem_userptr_bl...@dmabuf-sync.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-apl: [PASS][5] -> [DMESG-FAIL][6] ([i915#5334])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-apl7/igt@i915_selftest@live@gt_heartbeat.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-apl4/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +58 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-glk4/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3886])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-glk7/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3886]) +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-apl2/igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271]) +45 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-apl6/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_cursor_legacy@forked-bo@pipe-b:
- shard-glk: [PASS][11] -> [DMESG-WARN][12] ([i915#118])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk9/igt@kms_cursor_legacy@forked...@pipe-b.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-glk3/igt@kms_cursor_legacy@forked...@pipe-b.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a2:
- shard-glk: [PASS][13] -> [FAIL][14] ([i915#2122])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-glk3/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
* igt@kms_psr2_su@frontbuffer-xrgb:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#658])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-apl6/igt@kms_psr2...@frontbuffer-xrgb.html
* igt@kms_writeback@writeback-pixel-formats:
- shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2437])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-apl2/igt@kms_writeb...@writeback-pixel-formats.html
Possible fixes
* igt@fbdev@eof:
- {shard-tglu}: [SKIP][17] ([i915#2582]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-tglu-10/igt@fb...@eof.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-tglu-6/igt@fb...@eof.html
* {igt@gem_barrier_race@remote-request@rcs0}:
- shard-glk: [ABORT][19] ([i915#8211]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk3/igt@gem_barrier_race@remote-requ...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/shard-glk4/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][21] ([i915#6268]) ->
[Intel-gfx] [PATCH] drm/i915/gt: Consider multi-gt at all places
In order to make igt_live_test work in proper
way, we need to consider multi-gt in all tests
where igt_live_test is used as well as at other
random places where multi-gt should be considered.
Cc: Andi Shyti
Signed-off-by: Tejas Upadhyay
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 13 ++--
.../drm/i915/gem/selftests/i915_gem_context.c | 28
drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
drivers/gpu/drm/i915/gt/selftest_execlists.c | 68 +--
drivers/gpu/drm/i915/selftests/i915_request.c | 36 +-
.../gpu/drm/i915/selftests/igt_live_test.c| 10 +--
.../gpu/drm/i915/selftests/igt_live_test.h| 4 +-
7 files changed, 81 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9dce2957b4e5..289b75ac39e1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2449,9 +2449,9 @@ static int eb_submit(struct i915_execbuffer *eb)
return err;
}
-static int num_vcs_engines(struct drm_i915_private *i915)
+static int num_vcs_engines(struct intel_gt *gt)
{
- return hweight_long(VDBOX_MASK(to_gt(i915)));
+ return hweight_long(VDBOX_MASK(gt));
}
/*
@@ -2459,7 +2459,7 @@ static int num_vcs_engines(struct drm_i915_private *i915)
* The engine index is returned.
*/
static unsigned int
-gen8_dispatch_bsd_engine(struct drm_i915_private *dev_priv,
+gen8_dispatch_bsd_engine(struct intel_gt *gt,
struct drm_file *file)
{
struct drm_i915_file_private *file_priv = file->driver_priv;
@@ -2467,7 +2467,7 @@ gen8_dispatch_bsd_engine(struct drm_i915_private
*dev_priv,
/* Check whether the file_priv has already selected one ring. */
if ((int)file_priv->bsd_engine < 0)
file_priv->bsd_engine =
- get_random_u32_below(num_vcs_engines(dev_priv));
+ get_random_u32_below(num_vcs_engines(gt));
return file_priv->bsd_engine;
}
@@ -2644,6 +2644,7 @@ static unsigned int
eb_select_legacy_ring(struct i915_execbuffer *eb)
{
struct drm_i915_private *i915 = eb->i915;
+ struct intel_gt *gt = eb->gt;
struct drm_i915_gem_execbuffer2 *args = eb->args;
unsigned int user_ring_id = args->flags & I915_EXEC_RING_MASK;
@@ -2655,11 +2656,11 @@ eb_select_legacy_ring(struct i915_execbuffer *eb)
return -1;
}
- if (user_ring_id == I915_EXEC_BSD && num_vcs_engines(i915) > 1) {
+ if (user_ring_id == I915_EXEC_BSD && num_vcs_engines(gt) > 1) {
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
- bsd_idx = gen8_dispatch_bsd_engine(i915, eb->file);
+ bsd_idx = gen8_dispatch_bsd_engine(gt, eb->file);
} else if (bsd_idx >= I915_EXEC_BSD_RING1 &&
bsd_idx <= I915_EXEC_BSD_RING2) {
bsd_idx >>= I915_EXEC_BSD_SHIFT;
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index a81fa6a20f5a..b2695aab54e5 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -93,7 +93,7 @@ static int live_nop_switch(void *arg)
}
if (i915_request_wait(rq, 0, 10 * HZ) < 0) {
pr_err("Failed to populated %d contexts\n", nctx);
- intel_gt_set_wedged(to_gt(i915));
+ intel_gt_set_wedged(engine->gt);
i915_request_put(rq);
err = -EIO;
goto out_file;
@@ -105,7 +105,7 @@ static int live_nop_switch(void *arg)
pr_info("Populated %d contexts on %s in %lluns\n",
nctx, engine->name, ktime_to_ns(times[1] - times[0]));
- err = igt_live_test_begin(, i915, __func__, engine->name);
+ err = igt_live_test_begin(, engine->gt, __func__,
engine->name);
if (err)
goto out_file;
@@ -149,7 +149,7 @@ static int live_nop_switch(void *arg)
if (i915_request_wait(rq, 0, HZ / 5) < 0) {
pr_err("Switching between %ld contexts timed
out\n",
prime);
- intel_gt_set_wedged(to_gt(i915));
+ intel_gt_set_wedged(engine->gt);
i915_request_put(rq);
break;
}
@@ -163,7 +163,7 @@ static int live_nop_switch(void *arg)
break;
}
- err = igt_live_test_end();
+ err = igt_live_test_end(, engine->gt);
Re: [Intel-gfx] [PATCH v6 02/12] drm/i915/mtl: Synchronize i915/BIOS on C6 enabling
On Thu, 16 Mar 2023 20:43:39 -0700, Dixit, Ashutosh wrote: > > On Wed, 15 Mar 2023 18:00:51 -0700, Umesh Nerlige Ramappa wrote: > > > > From: Vinay Belgaumkar > > Hi Vinay, > > > If BIOS enables/disables C6, i915 should do the same. > > So MTL bios has a control for enabling/disabling C6? Both RC6 and MC6 > individually or collectively? > > What happens if bios has disabled RC6 and i915 enables it: just that it > will bust OA? > > The patch itself LGTM if the above is true, I can R-b it after I hear about > the above. > > Thanks. > -- > Ashutosh > > > Also, retain this value across driver reloads. This is needed only for > > MTL as of now due to an existing bug in OA which needs C6 disabled for it Let's say "C6 disabled in BIOS for it to function". > > to function. BIOS behavior is also different across platforms in terms of > > how C6 is enabled. > > > > Signed-off-by: Vinay Belgaumkar Otherwise as promised above: Reviewed-by: Ashutosh Dixit
Re: [Intel-gfx] [PATCH v6 12/12] drm/i915/perf: Wa_14017512683: Disable OAM if media C6 is enabled in BIOS
On Wed, 15 Mar 2023 18:01:01 -0700, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
Mostly looks good but one nit below.
> OAM does not work with media C6 enabled on some steppings of MTL.
> Disable OAM if we detect that media C6 was enabled in bios.
>
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/i915_perf.c | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 77fae3d80128..4ac6535a0356 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -209,6 +209,7 @@
> #include "gt/intel_gt_regs.h"
> #include "gt/intel_lrc.h"
> #include "gt/intel_lrc_reg.h"
> +#include "gt/intel_rc6.h"
> #include "gt/intel_ring.h"
> #include "gt/uc/intel_guc_slpc.h"
>
> @@ -4898,6 +4899,18 @@ static u32 num_perf_groups_per_gt(struct intel_gt *gt)
>
> static u32 __oam_engine_group(struct intel_engine_cs *engine)
> {
> + /*
> + * Wa_14017512683: mtl[a0..c0): Use of OAM must be preceded with Media
> + * C6 disable in BIOS. Do not enable OA for media classes if MC6 is
> + * enabled in BIOS.
> + */
> + if (IS_MTL_MEDIA_STEP(engine->i915, STEP_A0, STEP_C0) &&
> + intel_check_bios_c6_setup(>gt->rc6)) {
> + drm_notice_once(>i915->drm,
> + "OAM requires media C6 to be disabled in
> BIOS\n");
I think the typical mode of working with MTL would be to enable C6 unless OA
is needed. But this will print out this notice on every MTL system. So IMO
we should print this out only when a OAM perf stream is opened and that
fails.
Though not sure if it's ok to add a line to an already cluttered dmesg? The
default console log level is 4 (WARNING) so maybe ok?
https://linuxconfig.org/introduction-to-the-linux-kernel-log-levels
Though if we fail the opening of an OAM stream we could make it a drm_warn?
> + return PERF_GROUP_INVALID;
> + }
> +
> if (GRAPHICS_VER_FULL(engine->i915) >= IP_VER(12, 70)) {
> /*
>* There's 1 SAMEDIA gt and 1 OAM per SAMEDIA gt. All media
> slices
> @@ -5317,6 +5330,23 @@ int i915_perf_ioctl_version(struct drm_i915_private
> *i915)
>*
>* 7: Add support for video decode and enhancement classes.
>*/
> +
> + /*
> + * Wa_14017512683: mtl[a0..c0): Use of OAM must be preceded with Media
> + * C6 disable in BIOS. Do not enable OA for media classes if MC6 is
> + * enabled in BIOS.
Maybe add something like "Return version 6 to indicate non-support for OAM."
just to make clear.
> + */
> + if (IS_MTL_MEDIA_STEP(i915, STEP_A0, STEP_C0)) {
> + struct intel_gt *gt;
> + int i;
> +
> + for_each_gt(gt, i915, i) {
> + if (gt->type == GT_MEDIA &&
> + intel_check_bios_c6_setup(>rc6))
> + return 6;
> + }
> + }
> +
> return 7;
> }
>
> --
> 2.36.1
>
Thanks.
--
Ashutosh
Re: [Intel-gfx] [PATCH v6 11/12] drm/i915/perf: Pass i915 object to perf revision helper
On Wed, 15 Mar 2023 18:01:00 -0700, Umesh Nerlige Ramappa wrote: > > In some cases, perf revision may rely on specific steppings of a > platform. To determine the platform, pass i915 object to the perf > revision helper. Reviewed-by: Ashutosh Dixit
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: perform uc late init after probe error injection (rev2)
== Series Details ==
Series: drm/i915/gt: perform uc late init after probe error injection (rev2)
URL : https://patchwork.freedesktop.org/series/115137/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12872_full -> Patchwork_115137v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115137v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_plane_scaling@i915-max-src-size}:
- {shard-rkl}:NOTRUN -> [SKIP][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-rkl-4/igt@kms_plane_scal...@i915-max-src-size.html
- {shard-tglu}: NOTRUN -> [SKIP][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-tglu-10/igt@kms_plane_scal...@i915-max-src-size.html
Known issues
Here are the changes found in Patchwork_115137v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: NOTRUN -> [FAIL][3] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-glk1/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_reloc@basic-write-gtt-active:
- shard-apl: [PASS][6] -> [DMESG-WARN][7] ([i915#62]) +5 similar
issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-apl2/igt@gem_exec_re...@basic-write-gtt-active.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-apl3/igt@gem_exec_re...@basic-write-gtt-active.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3323])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-glk1/igt@gem_userptr_bl...@dmabuf-sync.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][9] -> [ABORT][10] ([i915#5566])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk4/igt@gen9_exec_pa...@allowed-single.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-glk6/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_module_load@reload:
- shard-snb: [PASS][11] -> [ABORT][12] ([i915#4528])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-snb5/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-snb2/igt@i915_module_l...@reload.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271]) +58 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-glk3/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-glk1/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271]) +14 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-apl7/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_color@legacy-gamma@pipe-b-dp-1:
- shard-apl: [PASS][16] -> [DMESG-WARN][17] ([i915#180] /
[i915#62]) +11 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-apl2/igt@kms_color@legacy-ga...@pipe-b-dp-1.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-apl3/igt@kms_color@legacy-ga...@pipe-b-dp-1.html
* igt@kms_cursor_crc@cursor-suspend@pipe-a-dp-1:
- shard-apl: [PASS][18] -> [ABORT][19] ([i915#180]) +1 similar
issue
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-apl6/igt@kms_cursor_crc@cursor-susp...@pipe-a-dp-1.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/shard-apl7/igt@kms_cursor_crc@cursor-susp...@pipe-a-dp-1.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][20] -> [FAIL][21] ([i915#2346])
[20]:
Re: [Intel-gfx] [PATCH v2 03/27] drm/i915/gvt: remove interface intel_gvt_is_valid_gfn
Tested-by: Yan Zhao
On Fri, Mar 10, 2023 at 04:22:34PM -0800, Sean Christopherson wrote:
> From: Yan Zhao
>
> Currently intel_gvt_is_valid_gfn() is called in two places:
> (1) shadowing guest GGTT entry
> (2) shadowing guest PPGTT leaf entry,
> which was introduced in commit cc753fbe1ac4
> ("drm/i915/gvt: validate gfn before set shadow page entry").
>
> However, now it's not necessary to call this interface any more, because
> a. GGTT partial write issue has been fixed by
>commit bc0686ff5fad
>("drm/i915/gvt: support inconsecutive partial gtt entry write")
>commit 510fe10b6180
>("drm/i915/gvt: fix a bug of partially write ggtt enties")
> b. PPGTT resides in normal guest RAM and we only treat 8-byte writes
>as valid page table writes. Any invalid GPA found is regarded as
>an error, either due to guest misbehavior/attack or bug in host
>shadow code.
>So,rather than do GFN pre-checking and replace invalid GFNs with
>scratch GFN and continue silently, just remove the pre-checking and
>abort PPGTT shadowing on error detected.
> c. GFN validity check is still performed in
>intel_gvt_dma_map_guest_page() --> gvt_pin_guest_page().
>It's more desirable to call VFIO interface to do both validity check
>and mapping.
>Calling intel_gvt_is_valid_gfn() to do GFN validity check from KVM side
>while later mapping the GFN through VFIO interface is unnecessarily
>fragile and confusing for unaware readers.
>
> Signed-off-by: Yan Zhao
> [sean: remove now-unused local variables]
> Signed-off-by: Sean Christopherson
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 36 +-
> 1 file changed, 1 insertion(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 58b9b316ae46..f30922c55a0c 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -49,22 +49,6 @@
> static bool enable_out_of_sync = false;
> static int preallocated_oos_pages = 8192;
>
> -static bool intel_gvt_is_valid_gfn(struct intel_vgpu *vgpu, unsigned long
> gfn)
> -{
> - struct kvm *kvm = vgpu->vfio_device.kvm;
> - int idx;
> - bool ret;
> -
> - if (!test_bit(INTEL_VGPU_STATUS_ATTACHED, vgpu->status))
> - return false;
> -
> - idx = srcu_read_lock(>srcu);
> - ret = kvm_is_visible_gfn(kvm, gfn);
> - srcu_read_unlock(>srcu, idx);
> -
> - return ret;
> -}
> -
> /*
> * validate a gm address and related range size,
> * translate it to host gm address
> @@ -1333,11 +1317,9 @@ static int ppgtt_populate_shadow_entry(struct
> intel_vgpu *vgpu,
> static int ppgtt_populate_spt(struct intel_vgpu_ppgtt_spt *spt)
> {
> struct intel_vgpu *vgpu = spt->vgpu;
> - struct intel_gvt *gvt = vgpu->gvt;
> - const struct intel_gvt_gtt_pte_ops *ops = gvt->gtt.pte_ops;
> struct intel_vgpu_ppgtt_spt *s;
> struct intel_gvt_gtt_entry se, ge;
> - unsigned long gfn, i;
> + unsigned long i;
> int ret;
>
> trace_spt_change(spt->vgpu->id, "born", spt,
> @@ -1354,13 +1336,6 @@ static int ppgtt_populate_spt(struct
> intel_vgpu_ppgtt_spt *spt)
> ppgtt_generate_shadow_entry(, s, );
> ppgtt_set_shadow_entry(spt, , i);
> } else {
> - gfn = ops->get_pfn();
> - if (!intel_gvt_is_valid_gfn(vgpu, gfn)) {
> - ops->set_pfn(, gvt->gtt.scratch_mfn);
> - ppgtt_set_shadow_entry(spt, , i);
> - continue;
> - }
> -
> ret = ppgtt_populate_shadow_entry(vgpu, spt, i, );
> if (ret)
> goto fail;
> @@ -2335,14 +2310,6 @@ static int emulate_ggtt_mmio_write(struct intel_vgpu
> *vgpu, unsigned int off,
> m.val64 = e.val64;
> m.type = e.type;
>
> - /* one PTE update may be issued in multiple writes and the
> - * first write may not construct a valid gfn
> - */
> - if (!intel_gvt_is_valid_gfn(vgpu, gfn)) {
> - ops->set_pfn(, gvt->gtt.scratch_mfn);
> - goto out;
> - }
> -
> ret = intel_gvt_dma_map_guest_page(vgpu, gfn, PAGE_SIZE,
> _addr);
> if (ret) {
> @@ -2359,7 +2326,6 @@ static int emulate_ggtt_mmio_write(struct intel_vgpu
> *vgpu, unsigned int off,
> ops->clear_present();
> }
>
> -out:
> ggtt_set_guest_entry(ggtt_mm, , g_gtt_index);
>
> ggtt_get_host_entry(ggtt_mm, , g_gtt_index);
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [Intel-gfx] [PATCH v2 01/27] drm/i915/gvt: Verify pfn is "valid" before dereferencing "struct page"
Reviewed-by: Yan Zhao
On Fri, Mar 10, 2023 at 04:22:32PM -0800, Sean Christopherson wrote:
> Check that the pfn found by gfn_to_pfn() is actually backed by "struct
> page" memory prior to retrieving and dereferencing the page. KVM
> supports backing guest memory with VM_PFNMAP, VM_IO, etc., and so
> there is no guarantee the pfn returned by gfn_to_pfn() has an associated
> "struct page".
>
> Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M huge gtt support")
> Signed-off-by: Sean Christopherson
> ---
> drivers/gpu/drm/i915/gvt/gtt.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 4ec85308379a..58b9b316ae46 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -1183,6 +1183,10 @@ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu,
> pfn = gfn_to_pfn(vgpu->vfio_device.kvm, ops->get_pfn(entry));
> if (is_error_noslot_pfn(pfn))
> return -EINVAL;
> +
> + if (!pfn_valid(pfn))
> + return -EINVAL;
> +
> return PageTransHuge(pfn_to_page(pfn));
> }
>
> --
> 2.40.0.rc1.284.g88254d51c5-goog
>
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915_pm_rps: Enable waitboost tests for SLPC
On Tue, 14 Mar 2023 11:06:40 -0700, Vinay Belgaumkar wrote: > > Waitboost is supported with SLPC. Re-enable the tests so > we have coverage. Reviewed-by: Ashutosh Dixit
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/audio: update audio keepalive clock values
== Series Details == Series: drm/i915/audio: update audio keepalive clock values URL : https://patchwork.freedesktop.org/series/115300/ State : success == Summary == CI Bug Log - changes from CI_DRM_12872 -> Patchwork_115300v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/index.html Participating hosts (35 -> 36) -- Additional (2): bat-atsm-1 fi-pnv-d510 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_115300v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][7] -> [ABORT][8] ([i915#7911]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [PASS][9] -> [DMESG-WARN][10] ([i915#8073]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@slpc: - bat-rpls-1: [PASS][11] -> [DMESG-FAIL][12] ([i915#6367]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-rpls-1/igt@i915_selftest@l...@slpc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-5: NOTRUN -> [SKIP][13] ([i915#7828]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-adln-1: NOTRUN -> [SKIP][14] ([i915#7828]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_psr@primary_page_flip: - fi-pnv-d510:NOTRUN -> [SKIP][15] ([fdo#109271]) +38 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - bat-adln-1: [FAIL][16] ([i915#8064]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - bat-adln-1: [ABORT][18] ([i915#8144]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [ABORT][20] ([i915#4983]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115300v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][22] ([i915#7699]) -> [PASS][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg2-11/igt@i915_selftest@l...@migrate.html [23]:
Re: [Intel-gfx] [PATCH] drm/i915/selftests: keep same cache settings as timeline
>> From: Fei Yang
>>
>> On MTL, objects allocated through i915_gem_object_create_internal() are
>> mapped as uncached in GPU by default because HAS_LLC is false. However
>> in the live_hwsp_read selftest these watcher objects are mapped as WB
>> on CPU side. The conseqence is that the updates done by the GPU are not
>> immediately visible to CPU, thus the selftest is randomly failing due to
>> the stale data in CPU cache. Solution can be either setting WC for CPU +
>> UC for GPU, or WB for CPU + 1-way coherent WB for GPU.
>> To keep the consistency, let's simply inherit the same cache settings
>> from the timeline, which is WB for CPU + 1-way coherent WB for GPU,
>> because this test is supposed to emulate the behavior of the timeline
>> anyway.
>>
>> Signed-off-by: Fei Yang
>
> It looks like there might be an indentation mistake on the second line
> of the i915_gem_object_pin_map_unlocked() call, but we can fix that up
> while applying; no need to re-send.
>
> Reviewed-by: Matt Roper
Thanks for reviewing.
> Is there an FDO issue # for the random failures thar were being seen?
> If so, we should add a Closes: or References: tag here.
I'm not aware of a FDO filed for this failure. That might be because the
issue is reproduced on MTL which might not be widely available to the
community yet.
> Matt
>> ---
>> drivers/gpu/drm/i915/gt/selftest_timeline.c | 14 +++---
>> 1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
>> b/drivers/gpu/drm/i915/gt/selftest_timeline.c
>> index 522d0190509c..631aaed9bc3d 100644
>> --- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
>> +++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
>> @@ -825,7 +825,8 @@ static bool cmp_gte(u32 a, u32 b)
>>return a >= b;
>> }
>>
>> -static int setup_watcher(struct hwsp_watcher *w, struct intel_gt *gt)
>> +static int setup_watcher(struct hwsp_watcher *w, struct intel_gt *gt,
>> + struct intel_timeline *tl)
>> {
>>struct drm_i915_gem_object *obj;
>>struct i915_vma *vma;
>> @@ -834,7 +835,10 @@ static int setup_watcher(struct hwsp_watcher *w, struct
>> intel_gt *gt)
>>if (IS_ERR(obj))
>>return PTR_ERR(obj);
>>
>> - w->map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
>> + /* keep the same cache settings as timeline */
>> + i915_gem_object_set_cache_coherency(obj,
>> tl->hwsp_ggtt->obj->cache_level);
>> + w->map = i915_gem_object_pin_map_unlocked(obj,
>> + page_unmask_bits(tl->hwsp_ggtt->obj->mm.mapping));
>>if (IS_ERR(w->map)) {
>>i915_gem_object_put(obj);
>>return PTR_ERR(w->map);
>> @@ -1004,8 +1008,10 @@ static int live_hwsp_read(void *arg)
>>if (!tl->has_initial_breadcrumb)
>>goto out_free;
>>
>> + selftest_tl_pin(tl);
>> +
>>for (i = 0; i < ARRAY_SIZE(watcher); i++) {
>> - err = setup_watcher([i], gt);
>> + err = setup_watcher([i], gt, tl);
>>if (err)
>>goto out;
>>}
>> @@ -1160,6 +1166,8 @@ static int live_hwsp_read(void *arg)
>>for (i = 0; i < ARRAY_SIZE(watcher); i++)
>>cleanup_watcher([i]);
>>
>> + intel_timeline_unpin(tl);
>> +
>>if (igt_flush_test(gt->i915))
>>err = -EIO;
>>
>> --
>> 2.25.1
Re: [Intel-gfx] [PATCH v6 02/12] drm/i915/mtl: Synchronize i915/BIOS on C6 enabling
On Wed, 15 Mar 2023 18:00:51 -0700, Umesh Nerlige Ramappa wrote: > > From: Vinay Belgaumkar Hi Vinay, > If BIOS enables/disables C6, i915 should do the same. So MTL bios has a control for enabling/disabling C6? Both RC6 and MC6 individually or collectively? What happens if bios has disabled RC6 and i915 enables it: just that it will bust OA? The patch itself LGTM if the above is true, I can R-b it after I hear about the above. Thanks. -- Ashutosh > Also, retain this value across driver reloads. This is needed only for > MTL as of now due to an existing bug in OA which needs C6 disabled for it > to function. BIOS behavior is also different across platforms in terms of > how C6 is enabled. > > Signed-off-by: Vinay Belgaumkar
Re: [Intel-gfx] [PATCH v7 15/22] vfio-iommufd: Add detach_ioas support for physical VFIO devices
> From: Liu, Yi L
> Sent: Friday, March 17, 2023 11:07 AM
>
> > From: Tian, Kevin
> > Sent: Friday, March 17, 2023 10:14 AM
> >
> > > From: Liu, Yi L
> > > Sent: Thursday, March 16, 2023 8:55 PM
> > >
> > > +void vfio_iommufd_physical_detach_ioas(struct vfio_device *vdev)
> > > +{
> > > + lockdep_assert_held(>dev_set->lock);
> > > +
> > > + if (WARN_ON(!vdev->iommufd_device) || !vdev->iommufd_attached)
> > > + return;
> > > +
> >
> > the 2nd check shouldn't be a WARN_ON. It's user-triggerable.
>
> Yes. it has already been removed in this version.:)
Huh, bad eyes.
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Simplify vcs/bsc engine selection
== Series Details ==
Series: drm/i915: Simplify vcs/bsc engine selection
URL : https://patchwork.freedesktop.org/series/115271/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12872_full -> Patchwork_115271v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_115271v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@verify:
- shard-apl: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-apl4/igt@gem_lmem_swapp...@verify.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][4] -> [ABORT][5] ([i915#5566])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk4/igt@gen9_exec_pa...@allowed-single.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-glk6/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271]) +38 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-glk9/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-apl4/igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271]) +45 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-apl3/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_cursor_crc@cursor-suspend@pipe-c-dp-1:
- shard-apl: [PASS][9] -> [ABORT][10] ([i915#180])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-apl6/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-apl3/igt@kms_cursor_crc@cursor-susp...@pipe-c-dp-1.html
* igt@kms_flip@2x-flip-vs-expired-vblank@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#79])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-glk1/igt@kms_flip@2x-flip-vs-expired-vbl...@bc-hdmi-a1-hdmi-a2.html
* igt@kms_psr2_su@frontbuffer-xrgb:
- shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#658])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-apl3/igt@kms_psr2...@frontbuffer-xrgb.html
* igt@kms_vblank@pipe-b-accuracy-idle:
- shard-glk: [PASS][14] -> [FAIL][15] ([i915#43])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk2/igt@kms_vbl...@pipe-b-accuracy-idle.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-glk7/igt@kms_vbl...@pipe-b-accuracy-idle.html
* igt@kms_writeback@writeback-pixel-formats:
- shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#2437])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-apl4/igt@kms_writeb...@writeback-pixel-formats.html
Possible fixes
* igt@fbdev@eof:
- {shard-tglu}: [SKIP][17] ([i915#2582]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-tglu-10/igt@fb...@eof.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-tglu-2/igt@fb...@eof.html
* {igt@gem_barrier_race@remote-request@rcs0}:
- shard-glk: [ABORT][19] ([i915#8211]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk3/igt@gem_barrier_race@remote-requ...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/shard-glk9/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][21] ([i915#6268]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-rkl-4/igt@gem_ctx_e...@basic-nohangcheck.html
[22]:
Re: [Intel-gfx] [PATCH v7 15/22] vfio-iommufd: Add detach_ioas support for physical VFIO devices
> From: Tian, Kevin
> Sent: Friday, March 17, 2023 10:14 AM
>
> > From: Liu, Yi L
> > Sent: Thursday, March 16, 2023 8:55 PM
> >
> > +void vfio_iommufd_physical_detach_ioas(struct vfio_device *vdev)
> > +{
> > + lockdep_assert_held(>dev_set->lock);
> > +
> > + if (WARN_ON(!vdev->iommufd_device) || !vdev->iommufd_attached)
> > + return;
> > +
>
> the 2nd check shouldn't be a WARN_ON. It's user-triggerable.
Yes. it has already been removed in this version.:)
[Intel-gfx] ✗ Fi.CI.BAT: failure for More MTL WA and powerwell patches (rev2)
== Series Details == Series: More MTL WA and powerwell patches (rev2) URL : https://patchwork.freedesktop.org/series/115292/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12872 -> Patchwork_115292v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_115292v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_115292v2, 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_115292v2/index.html Participating hosts (35 -> 35) -- Additional (2): bat-atsm-1 fi-pnv-d510 Missing(2): fi-kbl-soraka fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_115292v2: ### IGT changes ### Possible regressions * igt@i915_module_load@load: - bat-dg2-11: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg2-11/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-dg2-11/igt@i915_module_l...@load.html - bat-adlm-1: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adlm-1/igt@i915_module_l...@load.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-adlm-1/igt@i915_module_l...@load.html Known issues Here are the changes found in Patchwork_115292v2 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#2582]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#4083]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][7] ([i915#8062]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#4077]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][9] ([i915#4079]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][10] ([i915#8060]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][11] -> [ABORT][12] ([i915#7911]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@slpc: - bat-rpls-1: [PASS][13] -> [DMESG-FAIL][14] ([i915#6367]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-rpls-1/igt@i915_selftest@l...@slpc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-5: NOTRUN -> [SKIP][15] ([i915#7828]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-adln-1: NOTRUN -> [SKIP][16] ([i915#7828]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-b-dp-3: - bat-dg2-9: [PASS][17] -> [FAIL][18] ([fdo#103375]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-dp-3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-b-dp-3.html * igt@kms_pipe_crc_basic@suspend-read-crc@pipe-c-dp-3: - bat-dg2-9: [PASS][19] -> [FAIL][20] ([fdo#103375] / [i915#7932]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115292v2/bat-dg2-9/igt@kms_pipe_crc_basic@suspend-read-...@pipe-c-dp-3.html *
Re: [Intel-gfx] [PATCH v7 22/22] docs: vfio: Add vfio device cdev description
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:56 PM > > This gives notes for userspace applications on device cdev usage. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v7 19/22] vfio: Add VFIO_DEVICE_BIND_IOMMUFD
> From: Yi Liu
> Sent: Thursday, March 16, 2023 8:56 PM
>
> +
> +static int vfio_device_cdev_enable_noiommu(struct vfio_device *device)
> +{
> + if (!vfio_device_is_noiommu(device))
> + return -EINVAL;
> +
> + if (!capable(CAP_SYS_RAWIO))
> + return -EPERM;
> +
> + return 0;
> +}
it makes more sense to check CAP first.
Reviewed-by: Kevin Tian
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/regs: split display regs by function
== Series Details ==
Series: drm/i915/regs: split display regs by function
URL : https://patchwork.freedesktop.org/series/115269/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12872_full -> Patchwork_115269v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115269v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@in-flight-suspend:
- {shard-dg1}:[PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-dg1-13/igt@gem_...@in-flight-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-dg1-14/igt@gem_...@in-flight-suspend.html
* igt@kms_pipe_crc_basic@suspend-read-crc@pipe-d-hdmi-a-1:
- {shard-tglu}: [PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-tglu-8/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-1.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-tglu-4/igt@kms_pipe_crc_basic@suspend-read-...@pipe-d-hdmi-a-1.html
* {igt@kms_plane_scaling@i915-max-src-size}:
- {shard-rkl}:NOTRUN -> [SKIP][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-rkl-2/igt@kms_plane_scal...@i915-max-src-size.html
* igt@syncobj_timeline@etime-multi-wait-all-submitted-signaled:
- {shard-dg1}:[PASS][6] -> [DMESG-WARN][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-dg1-13/igt@syncobj_timel...@etime-multi-wait-all-submitted-signaled.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-dg1-14/igt@syncobj_timel...@etime-multi-wait-all-submitted-signaled.html
Known issues
Here are the changes found in Patchwork_115269v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: NOTRUN -> [FAIL][8] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-glk4/igt@gem_exec_fair@basic-none-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@verify:
- shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-apl6/igt@gem_lmem_swapp...@verify.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3323])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-glk4/igt@gem_userptr_bl...@dmabuf-sync.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][13] -> [ABORT][14] ([i915#5566])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-apl2/igt@gen9_exec_pa...@allowed-single.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-apl1/igt@gen9_exec_pa...@allowed-single.html
- shard-glk: [PASS][15] -> [ABORT][16] ([i915#5566])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk4/igt@gen9_exec_pa...@allowed-single.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271]) +58 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-glk6/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#3886])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-glk4/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][19] ([fdo#109271] / [i915#3886]) +1
similar issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/shard-apl6/igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- shard-apl: NOTRUN -> [SKIP][20] ([fdo#109271]) +45 similar
Re: [Intel-gfx] [PATCH v7 17/22] vfio-iommufd: Add detach_ioas support for emulated VFIO devices
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
> +
> +void vfio_iommufd_emulated_detach_ioas(struct vfio_device *vdev)
> +{
> + lockdep_assert_held(>dev_set->lock);
> +
> + if (WARN_ON(!vdev->iommufd_access) || !vdev->iommufd_attached)
> + return;
> +
ditto the WANR_ON on the latter condition should be removed.
Re: [Intel-gfx] [PATCH v7 15/22] vfio-iommufd: Add detach_ioas support for physical VFIO devices
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> +void vfio_iommufd_physical_detach_ioas(struct vfio_device *vdev)
> +{
> + lockdep_assert_held(>dev_set->lock);
> +
> + if (WARN_ON(!vdev->iommufd_device) || !vdev->iommufd_attached)
> + return;
> +
the 2nd check shouldn't be a WARN_ON. It's user-triggerable.
Re: [Intel-gfx] [PATCH v7 16/22] iommufd/device: Add iommufd_access_detach() API
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:55 PM > > From: Nicolin Chen > > Previously, the detach routine is only done by the destroy(). And it was > called by vfio_iommufd_emulated_unbind() when the device runs close(), so > all the mappings in iopt were cleaned in that setup, when the call trace > reaches this detach() routine. > > Now, there's a need of a detach uAPI, meaning that it does not only need > a new iommufd_access_detach() API, but also requires access->ops->unmap() > call as a cleanup. So add one. > > However, leaving that unprotected can introduce some potential of a race > condition during the pin_/unpin_pages() call, where access->ioas->iopt is > getting referenced. So, add an ioas_lock to protect the context of iopt > referencings. > > Also, to allow the iommufd_access_unpin_pages() callback to happen via > this unmap() call, add an ioas_unpin pointer, so the unpin routine won't > be affected by the "access->ioas = NULL" trick. > > Signed-off-by: Nicolin Chen > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v7 14/22] vfio: Record devid in vfio_device_file
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:55 PM > > .bind_iommufd() will generate an ID to represent this bond, which is > needed by userspace for further usage. Store devid in vfio_device_file > to avoid passing the pointer in multiple places. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v7 13/22] vfio-iommufd: Split bind/attach into two steps
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:55 PM > > to align with the coming vfio device cdev support. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v7 12/22] vfio-iommufd: Move noiommu support out of vfio_iommufd_bind()
> From: Liu, Yi L
> Sent: Thursday, March 16, 2023 8:55 PM
>
> @@ -192,6 +192,15 @@ static int vfio_device_group_open(struct
> vfio_device_file *df)
> vfio_device_group_get_kvm_safe(device);
>
> df->iommufd = device->group->iommufd;
> + if (device->group->iommufd && vfio_device_is_noiommu(device)) {
> + if (device->open_count == 0) {
> + ret =
> vfio_iommufd_enable_noiommu_compat(device,
> + device-
> >group->iommufd);
use df->iommufd which is simpler.
Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v7 11/22] vfio: Make vfio_device_first_open() to accept NULL iommufd for noiommu
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:55 PM > > vfio_device_first_open() requires the caller to provide either a valid > iommufd (the group path in iommufd compat mode) or a valid container > (the group path in legacy container mode). As preparation for noiommu > support in device cdev path it's extended to allow both being NULL. The > caller is expected to verify noiommu permission before passing NULL > to this function. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v7 06/22] kvm/vfio: Accept vfio device file from userspace
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:55 PM > > This defines KVM_DEV_VFIO_FILE* and make alias with > KVM_DEV_VFIO_GROUP*. > Old userspace uses KVM_DEV_VFIO_GROUP* works as well. > > Reviewed-by: Jason Gunthorpe > Tested-by: Terrence Xu > Tested-by: Nicolin Chen > Tested-by: Matthew Rosato > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v7 03/22] vfio: Remove vfio_file_is_group()
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:55 PM > > since no user of vfio_file_is_group() now. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH 7/7] vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:42 PM > > Now user can also provide an array of device fds as a 3rd method to verify > the reset ownership. It's not useful at this point when the device fds are > acquired via group fds. But it's necessary when moving to device cdev which > allows the user to directly acquire device fds by skipping group. In that > case this method can be used as a last resort when the preferred iommufd > verification doesn't work, e.g. in noiommu usages. > > Clarify it in uAPI. > > Signed-off-by: Yi Liu this may be adjusted upon whether zero-length approach will be included finally. but on its own: Reviewed-by: Kevin Tian
[Intel-gfx] ✓ Fi.CI.IGT: success for Introduce new methods for verifying ownership in vfio PCI hot reset
== Series Details ==
Series: Introduce new methods for verifying ownership in vfio PCI hot reset
URL : https://patchwork.freedesktop.org/series/115264/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12872_full -> Patchwork_115264v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_115264v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_ccs@pipe-d-random-ccs-data-y_tiled_gen12_rc_ccs_cc:
- {shard-dg1}:NOTRUN -> [DMESG-WARN][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-dg1-13/igt@kms_ccs@pipe-d-random-ccs-data-y_tiled_gen12_rc_ccs_cc.html
* {igt@kms_plane_scaling@i915-max-src-size}:
- {shard-rkl}:NOTRUN -> [SKIP][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-rkl-1/igt@kms_plane_scal...@i915-max-src-size.html
* {igt@kms_plane_scaling@i915-max-src-size@pipe-a-hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-dg1-14/igt@kms_plane_scaling@i915-max-src-s...@pipe-a-hdmi-a-1.html
Known issues
Here are the changes found in Patchwork_115264v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-none-share@rcs0:
- shard-glk: NOTRUN -> [FAIL][4] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-glk8/igt@gem_exec_fair@basic-none-sh...@rcs0.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_12872/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_lmem_swapping@verify:
- shard-apl: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#4613]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-apl6/igt@gem_lmem_swapp...@verify.html
* igt@gem_userptr_blits@dmabuf-sync:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#3323])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-glk8/igt@gem_userptr_bl...@dmabuf-sync.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][9] -> [ABORT][10] ([i915#5566])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk4/igt@gen9_exec_pa...@allowed-single.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_big_fb@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271]) +58 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-glk1/igt@kms_big...@yf-tiled-max-hw-stride-64bpp-rotate-180-hflip-async-flip.html
* igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3886])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-glk8/igt@kms_ccs@pipe-b-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3886]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-apl6/igt@kms_ccs@pipe-c-crc-primary-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271]) +45 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-apl4/igt@kms_chamelium_...@common-hpd-after-suspend.html
* igt@kms_flip@flip-vs-expired-vblank@a-hdmi-a1:
- shard-glk: [PASS][15] -> [FAIL][16] ([i915#79])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/shard-glk6/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a1.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-glk6/igt@kms_flip@flip-vs-expired-vbl...@a-hdmi-a1.html
* igt@kms_psr2_su@frontbuffer-xrgb:
- shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#658])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/shard-apl4/igt@kms_psr2...@frontbuffer-xrgb.html
* igt@kms_writeback@writeback-pixel-formats:
- shard-apl: NOTRUN -> [SKIP][18] ([fdo#109271] / [i915#2437])
[18]:
Re: [Intel-gfx] [PATCH 6/7] vfio: Accpet device file from vfio PCI hot reset path
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:42 PM > > This extends both vfio_file_is_valid() and vfio_file_has_dev() to accept > device file from the vfio PCI hot reset. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH 5/7] vfio: Refine vfio file kAPIs for vfio PCI hot reset
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:42 PM > > This prepares vfio core to accept vfio device file from the vfio PCI > hot reset path. vfio_file_is_group() is still kept for KVM usage. > > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH 4/7] vfio/pci: Renaming for accepting device fd in hot reset path
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:42 PM > @@ -2469,7 +2469,8 @@ static int vfio_pci_dev_set_hot_reset(struct > vfio_device_set *dev_set, >* cannot race being opened by another user simultaneously. >* >* Otherwise all opened devices in the dev_set must be > - * contained by the set of groups provided by the user. > + * contained by the set of groups/devices provided by > + * the user. just a nit. You may want to add "devices" in the last patch. Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH 3/7] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:42 PM > > as an alternative method for ownership check when iommufd is used. In > this case all opened devices in the affected dev_set are verified to > be bound to a same valid iommufd value to allow reset. It's simpler > and faster as user does not need to pass a set of fds and kernel no > need to search the device within the given fds. > > a device in noiommu mode doesn't have a valid iommufd, so this method > should not be used in a dev_set which contains multiple devices and one > of them is in noiommu. The only allowed noiommu scenario is that the > calling device is noiommu and it's in a singleton dev_set. > > Suggested-by: Jason Gunthorpe > Signed-off-by: Jason Gunthorpe > Signed-off-by: Yi Liu let's hold this one until there is a consensus with Alex/Jason.
Re: [Intel-gfx] [PATCH v2 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:15 PM > > After making the no-DMA drivers (samples/vfio-mdev) providing iommufd > callbacks, __vfio_register_dev() should check the presence of the iommufd > callbacks if CONFIG_IOMMUFD is enabled. > > Reviewed-by: Jason Gunthorpe > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v2 4/5] vfio/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers
> From: Liu, Yi L > Sent: Thursday, March 16, 2023 8:15 PM > > This harmonizes the no-DMA devices (the vfio-mdev sample drivers) with > the emulated devices (gvt-g, vfio-ap etc.). It makes it easier to add > BIND_IOMMUFD user interface which requires to return an iommufd ID to > represent the device/iommufd bond. > > Reviewed-by: Jason Gunthorpe > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
Re: [Intel-gfx] [PATCH v2 2/5] vfio-iommufd: No need to record iommufd_ctx in vfio_device
> From: Yi Liu > Sent: Thursday, March 16, 2023 8:15 PM > > iommufd_ctx is stored in vfio_device for emulated devices per > bind_iommufd. > However, as iommufd_access is created in bind, no more need to stored it > since iommufd_access implicitly stores it. > > Reviewed-by: Jason Gunthorpe > Signed-off-by: Yi Liu Reviewed-by: Kevin Tian
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: perform uc late init after probe error injection (rev2)
== Series Details == Series: drm/i915/gt: perform uc late init after probe error injection (rev2) URL : https://patchwork.freedesktop.org/series/115137/ State : success == Summary == CI Bug Log - changes from CI_DRM_12872 -> Patchwork_115137v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/index.html Participating hosts (35 -> 35) -- Additional (2): bat-atsm-1 fi-pnv-d510 Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_115137v2 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@i915_selftest@live@execlists: - fi-bsw-nick:[PASS][7] -> [ABORT][8] ([i915#7911] / [i915#7913]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][9] -> [ABORT][10] ([i915#4983]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-rpls-1/igt@i915_selftest@l...@reset.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-5: NOTRUN -> [SKIP][11] ([i915#7828]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-adln-1: NOTRUN -> [SKIP][12] ([i915#7828]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_psr@primary_page_flip: - fi-pnv-d510:NOTRUN -> [SKIP][13] ([fdo#109271]) +38 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/fi-pnv-d510/igt@kms_psr@primary_page_flip.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - bat-adln-1: [FAIL][14] ([i915#8064]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - bat-adln-1: [ABORT][16] ([i915#8144]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [ABORT][18] ([i915#4983]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][20] ([i915#7699]) -> [PASS][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg2-11/igt@i915_selftest@l...@migrate.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115137v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582 [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077 [i915#4079]:
Re: [Intel-gfx] [PATCH v11 06/11] drm/i915/dp: Consider output_format while computing dsc bpp for mode_valid
On Tue, Mar 14, 2023 at 04:34:10PM +0530, Ankit Nautiyal wrote:
> During modevalid step, the pipe bpp is computed assuming RGB output
> format. When checking with DSC, consider the output_format and compute
> the input bpp for DSC appropriately.
>
> v2: For DP-MST we currently use RGB output format only, so continue
> using RGB while computing dsc_bpp for MST case.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 28 -
> drivers/gpu/drm/i915/display/intel_dp.h | 4 ++-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
> 3 files changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index dcb3c2519041..499390c519ca 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1110,11 +1110,21 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>
> if (HAS_DSC(dev_priv) &&
> drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
> + int pipe_bpp;
> + enum intel_output_format output_format, sink_format;
> + const struct drm_display_info *info =
> >base.display_info;
> +
> + if (drm_mode_is_420_only(info, mode))
> + sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> + else
> + sink_format = INTEL_OUTPUT_FORMAT_RGB;
I think I saw this same code duplicated somewhere else already.
Time for a intel_dp_sink_format()?
> +
> + output_format = intel_dp_output_format(connector, sink_format);
> /*
>* TBD pass the connector BPC,
>* for now U8_MAX so that max BPC on that platform would be
> picked
>*/
> - int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
> + pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, output_format,
> U8_MAX);
>
> /*
>* Output bpp is stored in 6.4 format so right shift by 4 to
> get the
> @@ -1454,12 +1464,15 @@ intel_dp_compute_link_config_wide(struct intel_dp
> *intel_dp,
> return -EINVAL;
> }
>
> -int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp, u8 max_req_bpc)
> +int intel_dp_dsc_compute_bpp(struct intel_dp *intel_dp,
> + enum intel_output_format output_format,
> + u8 max_req_bpc)
> {
> struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> int i, num_bpc;
> u8 dsc_bpc[3] = {0};
> u8 dsc_max_bpc;
> + int pipe_bpp = 0;
>
> /* Max DSC Input BPC for ICL is 10 and for TGL+ is 12 */
> if (DISPLAY_VER(i915) >= 12)
> @@ -1470,11 +1483,13 @@ int intel_dp_dsc_compute_bpp(struct intel_dp
> *intel_dp, u8 max_req_bpc)
> num_bpc = drm_dp_dsc_sink_supported_input_bpcs(intel_dp->dsc_dpcd,
> dsc_bpc);
> for (i = 0; i < num_bpc; i++) {
> - if (dsc_max_bpc >= dsc_bpc[i])
> - return dsc_bpc[i] * 3;
> + if (dsc_max_bpc >= dsc_bpc[i]) {
> + pipe_bpp = dsc_bpc[i] * 3;
> + break;
> + }
> }
>
> - return 0;
> + return intel_dp_output_bpp(output_format, pipe_bpp);
The pipe_bpp vs. output_bpp terms seem a bit confused now in the dsc
code.
In the non-compressed cases pipe_bpp does not include any
subsampling, output_bpp is the subsampled version.
What this dsc code seems to want is an intermediate value which
is the subsampled pipe_bpp that is the input to dsc compressor?
And output_bpp/dsc.compressed_bpp is then the final bpp coming
out of the compressor.
I think we should invent a consistent set of names for each so that
it's clear which value the code is concerned with.
> }
>
> static int intel_dp_source_dsc_version_minor(struct intel_dp *intel_dp)
> @@ -1588,7 +1603,8 @@ int intel_dp_dsc_compute_config(struct intel_dp
> *intel_dp,
> return -EINVAL;
>
> if (compute_pipe_bpp)
> - pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
> conn_state->max_requested_bpc);
> + pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp,
> pipe_config->output_format,
> +
> conn_state->max_requested_bpc);
This pipe_bpp gets plugged back into crtc_state->pipe_bpp later and
then it'll be the subsampled version. I don't think that is what we want
eg. for dithering setup and whatnot.
> else
> pipe_bpp = pipe_config->pipe_bpp;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index ef39e4f7a329..2f4136e43f38 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -102,7 +102,9 @@ void intel_read_dp_sdp(struct intel_encoder *encoder,
> struct intel_crtc_state
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Alex Williamson > Sent: Friday, March 17, 2023 8:23 AM > > On Thu, 16 Mar 2023 23:29:21 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Friday, March 17, 2023 2:46 AM > > > > > > On Wed, 15 Mar 2023 23:31:23 + > > > "Tian, Kevin" wrote: > > > > > > > > From: Alex Williamson > > > > > Sent: Thursday, March 16, 2023 6:53 AM > > > > > I'm afraid this proposal reduces or eliminates the handshake we have > > > > > with userspace between VFIO_DEVICE_GET_PCI_HOT_RESET_INFO > and > > > > > VFIO_DEVICE_PCI_HOT_RESET, which could promote userspace to > ignore > > > the > > > > > _INFO ioctl altogether, resulting in drivers that don't understand the > > > > > scope of the reset. Is it worth it? What do we really gain? > > > > > > > > Jason raised the concern whether GET_PCI_HOT_RESET_INFO is actually > > > > useful today. > > > > > > > > It's an interface on opened device. So the tiny difference is whether > > > > the > > > > user knows the device is resettable when calling GET_INFO or later > when > > > > actually calling PCI_HOT_RESET. > > > > > > No, GET_PCI_HOT_RESET_INFO conveys not only whether a > PCI_HOT_RESET > > > can > > > be performed, but equally important the scope of the reset, ie. which > > > devices are affected by the reset. If we de-emphasize the INFO > > > portion, then this easily gets confused as just a variant of > > > VFIO_DEVICE_RESET, which is explicitly a device-level cscope reset. In > > > fact, I'd say the interface is not only trying to validate that the > > > user has sufficient privileges for the reset, but that they explicitly > > > acknowledge the scope of the reset. > > > > > > > IMHO the usefulness of scope is if it's discoverable by the management > > stack which then can try to assign devices with affected reset to a same > > user. > > Disagree, the user needs to know the scope of reset. Take for instance > two function of a device configured onto separate buses within a VM. > The VMM needs to know that a hot-reset of one will reset the other. > That's not obvious to the VMM without some understanding of PCI/e > topology and analysis of the host system. The info ioctl simplifies > that discovery for the VMM and the handshake of passing the affected > groups makes sure that the info ioctl remains relevant. If that is the intended usage then I don't see why this proposal will promote userspace to ignore the _INFO ioctl. It should be always queried no matter how the reset ioctl itself is designed. The motivation of calling _INFO is not from the reset ioctl asking for an array of fds. > > OTOH, I really haven't seen any evidence that the null-array concept > provides significant simplification for userspace, especially without > compromising the user's understanding of the scope of the provided > reset. Thanks, > I'll let Jason to further comment after he is back. The bottom line, if this cannot be converged in short time, is to move it out of the preparatory series for cdev. There is no reason to block cdev just for this open. Anyway we'll allow using device fd array for cdev so there is no function gap.
Re: [Intel-gfx] [PATCH v11 05/11] drm/i915/dp: Rearrange check for illegal mode and comments in mode_valid
On Tue, Mar 14, 2023 at 04:34:09PM +0530, Ankit Nautiyal wrote:
> Check for MODE_H_ILLEGAL before calculating max rates, lanes etc.
> Move comments about compressed bpp U6.4 format closer to where it is used.
>
> Signed-off-by: Ankit Nautiyal
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index b49d113357e4..dcb3c2519041 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1098,6 +1098,9 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> if (target_clock > max_dotclk)
> return MODE_CLOCK_HIGH;
>
> + if (intel_dp_hdisplay_bad(dev_priv, mode->hdisplay))
> + return MODE_H_ILLEGAL;
> +
> max_link_clock = intel_dp_max_link_rate(intel_dp);
> max_lanes = intel_dp_max_lane_count(intel_dp);
>
> @@ -1105,13 +1108,6 @@ intel_dp_mode_valid(struct drm_connector *_connector,
> mode_rate = intel_dp_link_required(target_clock,
>
> intel_dp_mode_min_output_bpp(connector, mode));
>
> - if (intel_dp_hdisplay_bad(dev_priv, mode->hdisplay))
> - return MODE_H_ILLEGAL;
> -
> - /*
> - * Output bpp is stored in 6.4 format so right shift by 4 to get the
> - * integer value since we support only integer values of bpp.
> - */
> if (HAS_DSC(dev_priv) &&
> drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd)) {
> /*
> @@ -1120,6 +1116,10 @@ intel_dp_mode_valid(struct drm_connector *_connector,
>*/
> int pipe_bpp = intel_dp_dsc_compute_bpp(intel_dp, U8_MAX);
>
> + /*
> + * Output bpp is stored in 6.4 format so right shift by 4 to
> get the
> + * integer value since we support only integer values of bpp.
> + */
> if (intel_dp_is_edp(intel_dp)) {
> dsc_max_output_bpp =
> drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd)
> >> 4;
> --
> 2.25.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v11 04/11] drm/i915/display: Use sink_format instead of ycbcr420_output flag
On Tue, Mar 14, 2023 at 04:34:08PM +0530, Ankit Nautiyal wrote:
> Start passing the sink_format, to all functions that take a bool
> ycbcr420_output as parameter. This will make the functions generic,
> and will serve as a slight step towards 4:2:2 support later.
>
> v2: Rebased.
>
> Suggested-by: Ville Syrj_l_
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 33 +++
> drivers/gpu/drm/i915/display/intel_hdmi.c | 50 ---
> drivers/gpu/drm/i915/display/intel_hdmi.h | 5 ++-
> 3 files changed, 44 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index c31ec9c91c64..b49d113357e4 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -967,7 +967,8 @@ static int intel_dp_max_tmds_clock(struct intel_dp
> *intel_dp)
>
> static enum drm_mode_status
> intel_dp_tmds_clock_valid(struct intel_dp *intel_dp,
> - int clock, int bpc, bool ycbcr420_output,
> + int clock, int bpc,
> + enum intel_output_format sink_format,
> bool respect_downstream_limits)
> {
> int tmds_clock, min_tmds_clock, max_tmds_clock;
> @@ -975,7 +976,7 @@ intel_dp_tmds_clock_valid(struct intel_dp *intel_dp,
> if (!respect_downstream_limits)
> return MODE_OK;
>
> - tmds_clock = intel_hdmi_tmds_clock(clock, bpc, ycbcr420_output);
> + tmds_clock = intel_hdmi_tmds_clock(clock, bpc, sink_format);
>
> min_tmds_clock = intel_dp->dfp.min_tmds_clock;
> max_tmds_clock = intel_dp_max_tmds_clock(intel_dp);
> @@ -998,6 +999,7 @@ intel_dp_mode_valid_downstream(struct intel_connector
> *connector,
> const struct drm_display_info *info = >base.display_info;
> enum drm_mode_status status;
> bool ycbcr_420_only;
> + enum intel_output_format sink_format;
>
> /* If PCON supports FRL MODE, check FRL bandwidth constraints */
> if (intel_dp->dfp.pcon_max_frl_bw) {
> @@ -1024,18 +1026,22 @@ intel_dp_mode_valid_downstream(struct intel_connector
> *connector,
>
> ycbcr_420_only = drm_mode_is_420_only(info, mode);
>
> + if (ycbcr_420_only && connector->base.ycbcr_420_allowed)
drm_mode_validate_ycbcr420() already checks for this combination.
So I don't think we should need to redo it here, and we didn't
before.
> + sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> + else
> + sink_format = INTEL_OUTPUT_FORMAT_RGB;
> +
> /* Assume 8bpc for the DP++/HDMI/DVI TMDS clock check */
> status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
> -8, ycbcr_420_only, true);
> +8, sink_format, true);
>
> if (status != MODE_OK) {
> - if (ycbcr_420_only ||
> - !connector->base.ycbcr_420_allowed ||
But here we do need to keep the allowed flag check since
drm_mode_validate_ycbcr420() doesn't care about 420_also() modes.
> + if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> !drm_mode_is_420_also(info, mode))
> return status;
> -
> + sink_format = INTEL_OUTPUT_FORMAT_YCBCR420;
> status = intel_dp_tmds_clock_valid(intel_dp, target_clock,
> -8, true, true);
> +8, sink_format, true);
> if (status != MODE_OK)
> return status;
> }
> @@ -1271,19 +1277,10 @@ static bool intel_dp_supports_dsc(struct intel_dp
> *intel_dp,
> drm_dp_sink_supports_dsc(intel_dp->dsc_dpcd);
> }
>
> -static bool intel_dp_is_ycbcr420(struct intel_dp *intel_dp,
> - const struct intel_crtc_state *crtc_state)
> -{
> - return crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR420 ||
> - (crtc_state->output_format == INTEL_OUTPUT_FORMAT_YCBCR444 &&
> - intel_dp->dfp.ycbcr_444_to_420);
> -}
> -
> static int intel_dp_hdmi_compute_bpc(struct intel_dp *intel_dp,
>const struct intel_crtc_state *crtc_state,
>int bpc, bool respect_downstream_limits)
> {
> - bool ycbcr420_output = intel_dp_is_ycbcr420(intel_dp, crtc_state);
> int clock = crtc_state->hw.adjusted_mode.crtc_clock;
>
> /*
> @@ -1303,8 +1300,8 @@ static int intel_dp_hdmi_compute_bpc(struct intel_dp
> *intel_dp,
>
> for (; bpc >= 8; bpc -= 2) {
> if (intel_hdmi_bpc_possible(crtc_state, bpc,
> - intel_dp->has_hdmi_sink,
> ycbcr420_output) &&
> - intel_dp_tmds_clock_valid(intel_dp, clock, bpc,
> ycbcr420_output,
> +
Re: [Intel-gfx] [PATCH v11 01/11] drm/i915/display: Add new member to configure PCON color conversion
On Tue, Mar 14, 2023 at 04:34:05PM +0530, Ankit Nautiyal wrote: > The decision to use DFP output format conversion capabilities should be > during compute_config phase. > > This patch adds new member to crtc_state to represent the final > output_format to the sink. In case of a DFP this can be different than > the output_format, as per the format conversion done via the PCON. > > This will help to store only the format conversion capabilities of the > DP device in intel_dp->dfp, and use crtc_state to compute and store the > configuration for color/format conversion for a given mode. > > v2: modified the new member to crtc_state to represent the final > output_format that eaches the sink, after possible conversion by > PCON kind of devices. (Ville) > > v3: Addressed comments from Ville: > -Added comments to clarify difference between sink_format and > output_format. > -Corrected the order of setting sink_format and output_format. > -Added readout for sink_format in get_pipe_config hooks. > > v4: Set sink_format for intel_sdvo too. (Ville) > > v5: Rebased. > > v6: Fixed condition to go for YCbCr420 format for dp and hdmi. (Ville) > > Signed-off-by: Ankit Nautiyal > Reviewed-by: Ville Syrjälä (v3) > --- > drivers/gpu/drm/i915/display/icl_dsi.c| 1 + > drivers/gpu/drm/i915/display/intel_crt.c | 1 + > .../drm/i915/display/intel_crtc_state_dump.c | 5 +-- > drivers/gpu/drm/i915/display/intel_display.c | 5 +++ > .../drm/i915/display/intel_display_types.h| 11 ++- > drivers/gpu/drm/i915/display/intel_dp.c | 33 +-- > drivers/gpu/drm/i915/display/intel_dp_mst.c | 1 + > drivers/gpu/drm/i915/display/intel_dvo.c | 1 + > drivers/gpu/drm/i915/display/intel_hdmi.c | 23 +++-- > drivers/gpu/drm/i915/display/intel_lvds.c | 1 + > drivers/gpu/drm/i915/display/intel_sdvo.c | 1 + > drivers/gpu/drm/i915/display/intel_tv.c | 1 + > drivers/gpu/drm/i915/display/vlv_dsi.c| 1 + > 13 files changed, 62 insertions(+), 23 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c > b/drivers/gpu/drm/i915/display/icl_dsi.c > index 50dcaa895854..e8ac4552e681 100644 > --- a/drivers/gpu/drm/i915/display/icl_dsi.c > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c > @@ -1593,6 +1593,7 @@ static int gen11_dsi_compute_config(struct > intel_encoder *encoder, > _config->hw.adjusted_mode; > int ret; > > + pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB; > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; > > ret = intel_panel_compute_config(intel_connector, adjusted_mode); > diff --git a/drivers/gpu/drm/i915/display/intel_crt.c > b/drivers/gpu/drm/i915/display/intel_crt.c > index 8f2ebead0826..e925e21d87fc 100644 > --- a/drivers/gpu/drm/i915/display/intel_crt.c > +++ b/drivers/gpu/drm/i915/display/intel_crt.c > @@ -393,6 +393,7 @@ static int intel_crt_compute_config(struct intel_encoder > *encoder, > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN) > return -EINVAL; > > + pipe_config->sink_format = INTEL_OUTPUT_FORMAT_RGB; > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; > > return 0; > diff --git a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c > b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c > index 766633566fd6..185cd1971aa5 100644 > --- a/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c > +++ b/drivers/gpu/drm/i915/display/intel_crtc_state_dump.c > @@ -178,10 +178,11 @@ void intel_crtc_state_dump(const struct > intel_crtc_state *pipe_config, > > snprintf_output_types(buf, sizeof(buf), pipe_config->output_types); > drm_dbg_kms(>drm, > - "active: %s, output_types: %s (0x%x), output format: %s\n", > + "active: %s, output_types: %s (0x%x), output format: %s, > sink format: %s\n", > str_yes_no(pipe_config->hw.active), > buf, pipe_config->output_types, > - output_formats(pipe_config->output_format)); > + output_formats(pipe_config->output_format), > + output_formats(pipe_config->sink_format)); > > drm_dbg_kms(>drm, > "cpu_transcoder: %s, pipe bpp: %i, dithering: %i\n", > diff --git a/drivers/gpu/drm/i915/display/intel_display.c > b/drivers/gpu/drm/i915/display/intel_display.c > index 410c84fd905c..6fa86d1e0480 100644 > --- a/drivers/gpu/drm/i915/display/intel_display.c > +++ b/drivers/gpu/drm/i915/display/intel_display.c > @@ -3127,6 +3127,7 @@ static bool i9xx_get_pipe_config(struct intel_crtc > *crtc, > return false; > > pipe_config->output_format = INTEL_OUTPUT_FORMAT_RGB; > + pipe_config->sink_format = pipe_config->output_format; > pipe_config->cpu_transcoder = (enum transcoder) crtc->pipe; > pipe_config->shared_dpll = NULL; > > @@ -3586,6 +3587,8 @@ static bool ilk_get_pipe_config(struct intel_crtc *crtc, >
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Thu, 16 Mar 2023 23:29:21 + "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Friday, March 17, 2023 2:46 AM > > > > On Wed, 15 Mar 2023 23:31:23 + > > "Tian, Kevin" wrote: > > > > > > From: Alex Williamson > > > > Sent: Thursday, March 16, 2023 6:53 AM > > > > I'm afraid this proposal reduces or eliminates the handshake we have > > > > with userspace between VFIO_DEVICE_GET_PCI_HOT_RESET_INFO and > > > > VFIO_DEVICE_PCI_HOT_RESET, which could promote userspace to ignore > > the > > > > _INFO ioctl altogether, resulting in drivers that don't understand the > > > > scope of the reset. Is it worth it? What do we really gain? > > > > > > Jason raised the concern whether GET_PCI_HOT_RESET_INFO is actually > > > useful today. > > > > > > It's an interface on opened device. So the tiny difference is whether the > > > user knows the device is resettable when calling GET_INFO or later when > > > actually calling PCI_HOT_RESET. > > > > No, GET_PCI_HOT_RESET_INFO conveys not only whether a PCI_HOT_RESET > > can > > be performed, but equally important the scope of the reset, ie. which > > devices are affected by the reset. If we de-emphasize the INFO > > portion, then this easily gets confused as just a variant of > > VFIO_DEVICE_RESET, which is explicitly a device-level cscope reset. In > > fact, I'd say the interface is not only trying to validate that the > > user has sufficient privileges for the reset, but that they explicitly > > acknowledge the scope of the reset. > > > > IMHO the usefulness of scope is if it's discoverable by the management > stack which then can try to assign devices with affected reset to a same > user. Disagree, the user needs to know the scope of reset. Take for instance two function of a device configured onto separate buses within a VM. The VMM needs to know that a hot-reset of one will reset the other. That's not obvious to the VMM without some understanding of PCI/e topology and analysis of the host system. The info ioctl simplifies that discovery for the VMM and the handshake of passing the affected groups makes sure that the info ioctl remains relevant. OTOH, I really haven't seen any evidence that the null-array concept provides significant simplification for userspace, especially without compromising the user's understanding of the scope of the provided reset. Thanks, Alex
Re: [Intel-gfx] [PATCH] drm/i915/selftests: keep same cache settings as timeline
On Wed, Mar 15, 2023 at 11:08:00AM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> On MTL, objects allocated through i915_gem_object_create_internal() are
> mapped as uncached in GPU by default because HAS_LLC is false. However
> in the live_hwsp_read selftest these watcher objects are mapped as WB
> on CPU side. The conseqence is that the updates done by the GPU are not
> immediately visible to CPU, thus the selftest is randomly failing due to
> the stale data in CPU cache. Solution can be either setting WC for CPU +
> UC for GPU, or WB for CPU + 1-way coherent WB for GPU.
> To keep the consistency, let's simply inherit the same cache settings
> from the timeline, which is WB for CPU + 1-way coherent WB for GPU,
> because this test is supposed to emulate the behavior of the timeline
> anyway.
>
> Signed-off-by: Fei Yang
It looks like there might be an indentation mistake on the second line
of the i915_gem_object_pin_map_unlocked() call, but we can fix that up
while applying; no need to re-send.
Reviewed-by: Matt Roper
Is there an FDO issue # for the random failures thar were being seen?
If so, we should add a Closes: or References: tag here.
Matt
> ---
> drivers/gpu/drm/i915/gt/selftest_timeline.c | 14 +++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_timeline.c
> b/drivers/gpu/drm/i915/gt/selftest_timeline.c
> index 522d0190509c..631aaed9bc3d 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_timeline.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_timeline.c
> @@ -825,7 +825,8 @@ static bool cmp_gte(u32 a, u32 b)
> return a >= b;
> }
>
> -static int setup_watcher(struct hwsp_watcher *w, struct intel_gt *gt)
> +static int setup_watcher(struct hwsp_watcher *w, struct intel_gt *gt,
> + struct intel_timeline *tl)
> {
> struct drm_i915_gem_object *obj;
> struct i915_vma *vma;
> @@ -834,7 +835,10 @@ static int setup_watcher(struct hwsp_watcher *w, struct
> intel_gt *gt)
> if (IS_ERR(obj))
> return PTR_ERR(obj);
>
> - w->map = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
> + /* keep the same cache settings as timeline */
> + i915_gem_object_set_cache_coherency(obj,
> tl->hwsp_ggtt->obj->cache_level);
> + w->map = i915_gem_object_pin_map_unlocked(obj,
> + page_unmask_bits(tl->hwsp_ggtt->obj->mm.mapping));
> if (IS_ERR(w->map)) {
> i915_gem_object_put(obj);
> return PTR_ERR(w->map);
> @@ -1004,8 +1008,10 @@ static int live_hwsp_read(void *arg)
> if (!tl->has_initial_breadcrumb)
> goto out_free;
>
> + selftest_tl_pin(tl);
> +
> for (i = 0; i < ARRAY_SIZE(watcher); i++) {
> - err = setup_watcher([i], gt);
> + err = setup_watcher([i], gt, tl);
> if (err)
> goto out;
> }
> @@ -1160,6 +1166,8 @@ static int live_hwsp_read(void *arg)
> for (i = 0; i < ARRAY_SIZE(watcher); i++)
> cleanup_watcher([i]);
>
> + intel_timeline_unpin(tl);
> +
> if (igt_flush_test(gt->i915))
> err = -EIO;
>
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH dii-client v1.1] drm/i915/mtl: Extend Wa_22011802037 to MTL A-step
On Thu, Mar 16, 2023 at 01:41:43PM -0700, Radhakrishna Sripada wrote:
From: Madhumitha Tolakanahalli Pradeep
Wa_22011802037 was being applied to all graphics_ver 11 & 12. This patch
updates the if statement to apply the W/A to right platforms and extends
it to MTL-M:A0.
it should be any A stepping, not just A0. But the code is correct, it's
only here that is wrong.
btw wrong subject-prefix here, not sure CI will pick it up for
execution.
v1.1: Fix checkpatch warning.
Signed-off-by: Madhumitha Tolakanahalli Pradeep
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 88e881b100cf..a099406dcc38 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1629,7 +1629,9 @@ static void guc_reset_state(struct intel_context *ce, u32
head, bool scrub)
static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
{
- if (!IS_GRAPHICS_VER(engine->i915, 11, 12))
+ if (!(IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+ (GRAPHICS_VER(engine->i915) >= 11 &&
+ GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70
the double negation + parenthesis + line wrap make it hard to read.
It seems that in commit 0667429ce68e ("drm/i915/reset: Add additional
steps for Wa_22011802037 for execlist backend") the Wa comment got
misplaced as the call to intel_engine_stop_cs() is part of the Wa
handling, no?
+Umesh
Maybe let's change to a positive check and move the Wa comment to be
above the check?
static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
{
/*
* Wa_22011802037: stop the cs and wait for any pending mi force
* wakeups
*/
if (IS_MTL_GRAPHICS_STEP(gt->i915, M, STEP_A0, STEP_B0) ||
(GRAPHICS_VER(gt->i915) >= 11 &&
GRAPHICS_VER_FULL(gt->i915) < IP_VER(12, 70))) {
intel_engine_stop_cs(engine);
intel_engine_wait_for_pending_mi_fw(engine);
}
}
This matches the condition checked everywhere else in the driver:
$ git grep Wa_22011802037
drivers/gpu/drm/i915/gt/intel_engine_cs.c: * Wa_22011802037:
Prior to doing a reset, ensure CS is
drivers/gpu/drm/i915/gt/intel_engine_cs.c: * Wa_22011802037:gen12: In
addition to stopping the cs, we need to wait for any
drivers/gpu/drm/i915/gt/intel_execlists_submission.c:*
Wa_22011802037: In addition to stopping the cs, we need
drivers/gpu/drm/i915/gt/uc/intel_guc.c: /* Wa_22011802037: graphics
version 11/12 */
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c: *
Wa_22011802037: In addition to stopping the cs, we need
Btw then comments about graphics versions didn't age well: they are not matching
the code anymore
Lucas De Marchi
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Simplify vcs/bsc engine selection
== Series Details == Series: drm/i915: Simplify vcs/bsc engine selection URL : https://patchwork.freedesktop.org/series/115271/ State : success == Summary == CI Bug Log - changes from CI_DRM_12872 -> Patchwork_115271v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/index.html Participating hosts (35 -> 35) -- Additional (1): fi-pnv-d510 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_115271v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#4983]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-rpls-1/igt@i915_selftest@l...@reset.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-5: NOTRUN -> [SKIP][3] ([i915#7828]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-adln-1: NOTRUN -> [SKIP][4] ([i915#7828]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][5] ([i915#3546]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html * igt@kms_psr@primary_page_flip: - fi-pnv-d510:NOTRUN -> [SKIP][6] ([fdo#109271]) +38 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - bat-adln-1: [FAIL][7] ([i915#8064]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - bat-adln-1: [ABORT][9] ([i915#8144]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [ABORT][11] ([i915#4983]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][13] ([i915#7699]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg2-11/igt@i915_selftest@l...@migrate.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#8064]: https://gitlab.freedesktop.org/drm/intel/issues/8064 [i915#8144]: https://gitlab.freedesktop.org/drm/intel/issues/8144 Build changes - * Linux: CI_DRM_12872 -> Patchwork_115271v1 CI-20190529: 20190529 CI_DRM_12872: f65e171596ef70c076fe02be596de29e83cfc8a3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7202: b4ec7dac375eed2dda89c64d4de94c4c9205b601 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115271v1: f65e171596ef70c076fe02be596de29e83cfc8a3 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits f7683782e1e8 drm/i915: Simplify vcs/bsc engine selection == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115271v1/index.html
Re: [Intel-gfx] [PATCH] drm/i915/display: Audio keep alive timestamp cdclk divisors
Wrong patch sent in error. PLease ignore this version.
-Clint
On Thu, 2023-03-16 at 14:46 -0700, Clint Taylor wrote:
> From: "Taylor, Clinton A"
>
> Use BSPEC values for the Audio Keep alive M and N values as included in
> the cdclk BSPEC pages for display > 13
>
> BSPEC: 54034, 55409
> Cc: Kai Vehmanen
> Cc: Uma Shankar
> Cc: Ville Syrjälä
> Signed-off-by: Taylor, Clinton A
> ---
> drivers/gpu/drm/i915/display/intel_audio.c | 23 +--
> drivers/gpu/drm/i915/display/intel_cdclk.c | 79 ++
> drivers/gpu/drm/i915/display/intel_cdclk.h | 1 +
> 3 files changed, 51 insertions(+), 52 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
> b/drivers/gpu/drm/i915/display/intel_audio.c
> index 6c9ee905f132..cb45be5edfec 100644
> --- a/drivers/gpu/drm/i915/display/intel_audio.c
> +++ b/drivers/gpu/drm/i915/display/intel_audio.c
> @@ -945,37 +945,16 @@ void intel_audio_hooks_init(struct drm_i915_private
> *dev_priv)
> }
> }
>
> -struct aud_ts_cdclk_m_n {
> - u8 m;
> - u16 n;
> -};
> -
> void intel_audio_cdclk_change_pre(struct drm_i915_private *i915)
> {
> if (DISPLAY_VER(i915) >= 13)
> intel_de_rmw(i915, AUD_TS_CDCLK_M, AUD_TS_CDCLK_M_EN, 0);
> }
>
> -static void get_aud_ts_cdclk_m_n(int refclk, int cdclk, struct
> aud_ts_cdclk_m_n
> *aud_ts)
> -{
> - if (refclk == 24000)
> - aud_ts->m = 12;
> - else
> - aud_ts->m = 15;
> -
> - aud_ts->n = cdclk * aud_ts->m / 24000;
> -}
> -
> void intel_audio_cdclk_change_post(struct drm_i915_private *i915)
> {
> - struct aud_ts_cdclk_m_n aud_ts;
> -
> if (DISPLAY_VER(i915) >= 13) {
> - get_aud_ts_cdclk_m_n(i915->cdclk.hw.ref, i915->cdclk.hw.cdclk,
> _ts);
> -
> - intel_de_write(i915, AUD_TS_CDCLK_N, aud_ts.n);
> - intel_de_write(i915, AUD_TS_CDCLK_M, aud_ts.m |
> AUD_TS_CDCLK_M_EN);
> - drm_dbg_kms(>drm, "aud_ts_cdclk set to M=%u, N=%u\n",
> aud_ts.m,
> aud_ts.n);
> + intel_update_audio_keep_alive(i915);
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 86a22c3766e5..57021ecad509 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -37,6 +37,7 @@
> #include "intel_pcode.h"
> #include "intel_psr.h"
> #include "vlv_sideband.h"
> +#include "intel_audio_regs.h"
>
> /**
> * DOC: CDCLK / RAWCLK
> @@ -1231,6 +1232,8 @@ struct intel_cdclk_vals {
> u16 waveform;
> u8 divider; /* CD2X divider * 2 */
> u8 ratio;
> + u16 aud_m;
> + u16 aud_n;
> };
>
> static const struct intel_cdclk_vals bxt_cdclk_table[] = {
> @@ -1313,40 +1316,40 @@ static const struct intel_cdclk_vals
> adlp_a_step_cdclk_table[] =
> {
> };
>
> static const struct intel_cdclk_vals adlp_cdclk_table[] = {
> - { .refclk = 19200, .cdclk = 172800, .divider = 3, .ratio = 27 },
> - { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
> - { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
> - { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
> - { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
> -
> - { .refclk = 24000, .cdclk = 176000, .divider = 3, .ratio = 22 },
> - { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
> - { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
> - { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
> - { .refclk = 24400, .cdclk = 648000, .divider = 2, .ratio = 54 },
> -
> - { .refclk = 38400, .cdclk = 179200, .divider = 3, .ratio = 14 },
> - { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
> - { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
> - { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
> - { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34 },
> + { .refclk = 19200, .cdclk = 172800, .divider = 3, .ratio = 27, .aud_m =
> 0x3C,
> .aud_n = 0x140 },
> + { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20, .aud_m =
> 0x3C,
> .aud_n = 0x1E0 },
> + { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32, .aud_m =
> 0x3C,
> .aud_n = 0x300 },
> + { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58, .aud_m =
> 0x3C,
> .aud_n = 0x570 },
> + { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68, .aud_m =
> 0x3C,
> .aud_n = 0x660 },
> +
> + { .refclk = 24000, .cdclk = 176000, .divider = 3, .ratio = 22, .aud_m =
> 0x3C,
> .aud_n = 0x1B8 },
> + { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16, .aud_m =
> 0x3C,
> .aud_n = 0x1E0 },
> + { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26, .aud_m =
> 0x3C,
> .aud_n = 0x30C },
> + { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46, .aud_m =
>
Re: [Intel-gfx] [PATCH v11 03/11] drm/i915/dp: Replace intel_dp.dfp members with the new crtc_state sink_format
On Tue, Mar 14, 2023 at 04:34:07PM +0530, Ankit Nautiyal wrote:
> The decision to use DFP output format conversion capabilities should be
> during compute_config phase.
>
> This patch uses the members of intel_dp->dfp to only store the
> format conversion capabilities of the DP device and uses the crtc_state
> sink_format member, to program the protocol-converter for
> colorspace/format conversion.
>
> v2: Use sink_format to determine the color conversion config for the
> pcon (Ville).
>
> v3: Fix typo: missing 'break' in switch case (lkp kernel test robot).
>
> v4: Add helper to check if DP supports YCBCR420.
>
> v5: Simplify logic for computing output_format, based on the given
> sink_format. (Ville).
> Added scaler constraint for YCbCr420 output.
>
> v6: Split the patch for Scaler constraint for Ycbcr420.
>
> v7: Simplify the policy for selecting output_format:
> Always try for RGB first, followed by YCBCR444, and finally by YCBCR420.
>
> Signed-off-by: Ankit Nautiyal
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 182 +---
> 1 file changed, 129 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index e52e2ffc355c..c31ec9c91c64 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -817,24 +817,82 @@ u8 intel_dp_dsc_get_slice_count(struct intel_dp
> *intel_dp,
> return 0;
> }
>
> +static bool source_can_output(struct intel_dp *intel_dp,
> + enum intel_output_format format)
> +{
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> + bool is_branch = drm_dp_is_branch(intel_dp->dpcd);
> +
> + if (format == INTEL_OUTPUT_FORMAT_RGB)
> + return true;
> +
> + /*
> + * No YCbCr output support on gmch platforms.
> + * Also, ILK doesn't seem capable of DP YCbCr output.
> + * The displayed image is severly corrupted. SNB+ is fine.
> + */
> + if (HAS_GMCH(i915) || IS_IRONLAKE(i915))
> + return false;
> +
> + if (format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return true;
> +
> + /* Platform < Gen 11 cannot output YCbCr420 format */
> + if (DISPLAY_VER(i915) < 11)
> + return false;
> +
> + /* If branch device then PCONs should support YCbCr420 Passthrough */
> + if (format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + return !is_branch || intel_dp->dfp.ycbcr420_passthrough;
This part isn't really about the source capabilities.
I think it would be more appropriate to do these checks
in the caller.
> +
> + return false;
> +}
> +
> +static bool
> +dfp_can_convert_from_rgb(struct intel_dp *intel_dp,
> + enum intel_output_format sink_format)
> +{
> + if (!drm_dp_is_branch(intel_dp->dpcd))
> + return false;
> +
> + if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444)
> + return intel_dp->dfp.rgb_to_ycbcr;
> +
> + if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + return intel_dp->dfp.rgb_to_ycbcr &&
> + intel_dp->dfp.ycbcr_444_to_420;
> +
> + return false;
> +}
> +
> +static bool
> +dfp_can_convert_from_ycbcr444(struct intel_dp *intel_dp,
> + enum intel_output_format sink_format)
> +{
> + if (!drm_dp_is_branch(intel_dp->dpcd))
> + return false;
> +
> + if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + return intel_dp->dfp.ycbcr_444_to_420;
> +
> + return false;
> +}
> +
> static enum intel_output_format
> intel_dp_output_format(struct intel_connector *connector,
> enum intel_output_format sink_format)
> {
> struct intel_dp *intel_dp = intel_attached_dp(connector);
>
> - if (!connector->base.ycbcr_420_allowed ||
> - sink_format != INTEL_OUTPUT_FORMAT_YCBCR420)
> - return INTEL_OUTPUT_FORMAT_RGB;
> -
> - if (intel_dp->dfp.rgb_to_ycbcr &&
> - intel_dp->dfp.ycbcr_444_to_420)
> + if (sink_format == INTEL_OUTPUT_FORMAT_RGB ||
> + dfp_can_convert_from_rgb(intel_dp, sink_format))
> return INTEL_OUTPUT_FORMAT_RGB;
>
> - if (intel_dp->dfp.ycbcr_444_to_420)
> + if (sink_format == INTEL_OUTPUT_FORMAT_YCBCR444 ||
> + dfp_can_convert_from_ycbcr444(intel_dp, sink_format))
> return INTEL_OUTPUT_FORMAT_YCBCR444;
> - else
> - return INTEL_OUTPUT_FORMAT_YCBCR420;
> +
> + return INTEL_OUTPUT_FORMAT_YCBCR420;
> }
I'm thinking the caller of intel_dp_output_format() might want
to do a drm_WARN_ON(!source_can_output(output_format))
just to make sure we didn't screw things up too badly.
Or maybe we want to have that assert in intel_dp_output_format()
itself in case there are many callers.
>
> int intel_dp_min_bpp(enum intel_output_format output_format)
> @@ -2751,6 +2809,8 @@ void
[Intel-gfx] [PATCH] drm/i915/audio: update audio keepalive clock values
BSPEC has updated the cdclk audio keepalives AUD_TS_CDCLK_M value to 60
for all supported platforms and refclks.
BSPEC: 54034
BSPEC: 55409
BSPEC: 65243
Cc: Kai Vehmanen
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/display/intel_audio.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index 65151f5dcb15..3d5a9bbc6fde 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -983,11 +983,7 @@ void intel_audio_cdclk_change_pre(struct drm_i915_private
*i915)
static void get_aud_ts_cdclk_m_n(int refclk, int cdclk, struct
aud_ts_cdclk_m_n *aud_ts)
{
- if (refclk == 24000)
- aud_ts->m = 12;
- else
- aud_ts->m = 15;
-
+ aud_ts->m = 60;
aud_ts->n = cdclk * aud_ts->m / 24000;
}
--
2.25.1
Re: [Intel-gfx] [Freedreno] [RFC PATCH 1/2] drm/msm/dpu: add dsc helper functions
On 3/16/2023 9:36 AM, Abhinav Kumar wrote:
On 3/16/2023 9:23 AM, Dmitry Baryshkov wrote:
On 16/03/2023 18:13, Abhinav Kumar wrote:
On 3/16/2023 9:03 AM, Dmitry Baryshkov wrote:
Hi,
[removed previous conversation]
Hi Dmitry and Abhinav,
Just wanted to follow up on this thread. I've gone over the
MSM-specific
DSC params for DP and DSI and have found a few shared calculations and
variables between both DSI and DP paths:
- (as mentioned earlier in the thread) almost all the calculations in
dpu_dsc_populate_dsc_config() match dsi_populate_dsc_params() [1]. The
only difference in the math I'm seeing is initial_scale_value.
The value in dsi code is valid for initial_offset = 6144. Please use
the formula from the standard (= sde_dsc_populate_dsc_config) and add
it to drm_dsc_helper.c
Yes, I agree with this part. for rc_model_size we can use
DSC_RC_MODEL_SIZE_CONST.
initial_offset is already handled in
https://patchwork.freedesktop.org/patch/525424/?series=114472=2
Then we can use this math:
rc_model_size / (rc_model_size -
initial_offset), keeping in mind that initial_scale_value has three
fractional bits.
So this would be 8192 / (8192 - 6144) = 4
Then << 3 for 3 fractional bits = 32.
If I remember correctly the last remaining item in
dsi_populate_dsc_params() (except mentioned initial_offset) was
line_buf_depth, see [3]. I'm not sure about setting it to bpc+1.
According to the standard it should come from a DSC decoder spec,
which means it should be set by the DSI panel driver or via
drm_dp_dsc_sink_line_buf_depth() in the case of DP output.
- dsc_extra_pclk_cycle_cnt and dce_bytes_per_line, which were
introduced
in Kuogee's v1 DSC series [2], are used for DSI, DP, and the DPU
timing
engine. dsc_extra_pclk_cycle_cnt is calculated based on pclk_per_line
(which is calculated differently between DP and DSI), but
dce_bytes_per_line is calculated the same way between DP and DSI.
To avoid having to duplicate math in 2 different places, I think it
would help to have these calculations in some msm_dsc_helper.c
file. Any
thoughts on this?
dsc_extra_pclk_cycle_cnt and dce_bytes_per_line are used only in DPU
code, so they can stay in DPU driver.
They can stay in the dpu driver is fine but where?
Like Jessica wrote, this is computed and used in 3 places today :
1) DSI video engine computation
2) DP controller computation
3) timing engine programming
Please excuse me if I'm wrong. I checked both vendor techpack and the
Kuogee's patches. I see them being used only in the SDE / DPU driver
code. Could you please point me to the code path that we are discussing?
DSI code :
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/dsi/dsi_host.c#L868
DP code:
Refer to dp_panel_dsc_pclk_param_calc in
https://patchwork.freedesktop.org/patch/519837/?series=113240=1
Timing engine:
refer to
https://patchwork.freedesktop.org/patch/519838/?series=113240=1
Probably confusion is due to the naming. bytes_per_line is nothing but
bytes_per_pkt * pkt_per_line but the concept is common for DP and DSI.
+ if (phys->comp_type == MSM_DISPLAY_COMPRESSION_DSC) {
+ phys->dsc_extra_pclk_cycle_cnt = dsc_info->pclk_per_line;
+ phys->dsc_extra_disp_width = dsc_info->extra_width;
+ phys->dce_bytes_per_line =
+ dsc_info->bytes_per_pkt * dsc_info->pkt_per_line;
So either we have a helper in a common location somewhere so that
these 3 modules can call that helper and use it OR each module
duplicates the computation code.
What should be the common location is the discussion here.
It cannot be dpu_encoder.c as the DSI/DP dont call into the encoder
methods.
Thanks,
Jessica Zhang
[1]
https://elixir.bootlin.com/linux/v6.3-rc2/source/drivers/gpu/drm/msm/dsi/dsi_host.c#L1756
[2]
https://patchwork.freedesktop.org/patch/519845/?series=113240=1
[3] https://patchwork.freedesktop.org/patch/525441/?series=114472=2
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Alex Williamson > Sent: Friday, March 17, 2023 2:46 AM > > On Wed, 15 Mar 2023 23:31:23 + > "Tian, Kevin" wrote: > > > > From: Alex Williamson > > > Sent: Thursday, March 16, 2023 6:53 AM > > > I'm afraid this proposal reduces or eliminates the handshake we have > > > with userspace between VFIO_DEVICE_GET_PCI_HOT_RESET_INFO and > > > VFIO_DEVICE_PCI_HOT_RESET, which could promote userspace to ignore > the > > > _INFO ioctl altogether, resulting in drivers that don't understand the > > > scope of the reset. Is it worth it? What do we really gain? > > > > Jason raised the concern whether GET_PCI_HOT_RESET_INFO is actually > > useful today. > > > > It's an interface on opened device. So the tiny difference is whether the > > user knows the device is resettable when calling GET_INFO or later when > > actually calling PCI_HOT_RESET. > > No, GET_PCI_HOT_RESET_INFO conveys not only whether a PCI_HOT_RESET > can > be performed, but equally important the scope of the reset, ie. which > devices are affected by the reset. If we de-emphasize the INFO > portion, then this easily gets confused as just a variant of > VFIO_DEVICE_RESET, which is explicitly a device-level cscope reset. In > fact, I'd say the interface is not only trying to validate that the > user has sufficient privileges for the reset, but that they explicitly > acknowledge the scope of the reset. > IMHO the usefulness of scope is if it's discoverable by the management stack which then can try to assign devices with affected reset to a same user. but this info is only available after the device is opened. Then the mgmt. stack just assigns devices w/o awareness of reset scope and nothing can be changed by the user no matter it knows the scope or not. from this angle I don't see a value of probe-and-reset vs. direct reset when reset itself also takes the scope into consideration. Probably the slight difference is that with probe a more informative error message can be printed out?
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/regs: split display regs by function
== Series Details == Series: drm/i915/regs: split display regs by function URL : https://patchwork.freedesktop.org/series/115269/ State : success == Summary == CI Bug Log - changes from CI_DRM_12872 -> Patchwork_115269v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/index.html Participating hosts (35 -> 35) -- Additional (2): bat-atsm-1 fi-pnv-d510 Missing(2): fi-kbl-soraka fi-snb-2520m Known issues Here are the changes found in Patchwork_115269v1 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_sync@basic-each: - bat-atsm-1: NOTRUN -> [FAIL][3] ([i915#8062]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-atsm-1/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4077]) +2 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#4079]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_hangman@error-state-basic: - bat-atsm-1: NOTRUN -> [ABORT][6] ([i915#8060]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-atsm-1/igt@i915_hang...@error-state-basic.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][7] -> [ABORT][8] ([i915#7911]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html - fi-bsw-nick:[PASS][9] -> [ABORT][10] ([i915#7911] / [i915#7913]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@i915_suspend@basic-s3-without-i915: - bat-adln-1: NOTRUN -> [DMESG-WARN][11] ([i915#2867]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-adln-1/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-5: NOTRUN -> [SKIP][12] ([i915#7828]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-adln-1: NOTRUN -> [SKIP][13] ([i915#7828]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_psr@primary_page_flip: - fi-pnv-d510:NOTRUN -> [SKIP][14] ([fdo#109271]) +38 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - bat-adln-1: [FAIL][15] ([i915#8064]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - bat-adln-1: [ABORT][17] ([i915#8144]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [ABORT][19] ([i915#4983]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][21] ([i915#7699]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg2-11/igt@i915_selftest@l...@migrate.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115269v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html [fdo#109271]:
Re: [Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness
On Thu, Mar 16, 2023 at 3:22 PM Sebastian Wick wrote: > > On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote: > > > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote: > > > > > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote: > > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote: > > > > > > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote: > > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl > > > > > > wrote: > > > > > > > > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > > > > > > > > From: Rob Clark > > > > > > > > > > > > > > > > Add a way to hint to the fence signaler of an upcoming > > > > > > > > deadline, such as > > > > > > > > vblank, which the fence waiter would prefer not to miss. This > > > > > > > > is to aid > > > > > > > > the fence signaler in making power management decisions, like > > > > > > > > boosting > > > > > > > > frequency as the deadline approaches and awareness of missing > > > > > > > > deadlines > > > > > > > > so that can be factored in to the frequency scaling. > > > > > > > > > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter > > > > > > > > duplicate > > > > > > > > deadlines, to avoid increasing dma_fence size. The > > > > > > > > fence-context > > > > > > > > implementation will need similar logic to track deadlines > > > > > > > > of all > > > > > > > > the fences on the same timeline. [ckoenig] > > > > > > > > v3: Clarify locking wrt. set_deadline callback > > > > > > > > v4: Clarify in docs comment that this is a hint > > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > > > > > > > > v6: More docs > > > > > > > > v7: Fix typo, clarify past deadlines > > > > > > > > > > > > > > > > Signed-off-by: Rob Clark > > > > > > > > Reviewed-by: Christian König > > > > > > > > Acked-by: Pekka Paalanen > > > > > > > > Reviewed-by: Bagas Sanjaya > > > > > > > > --- > > > > > > > > > > > > > > Hi Rob! > > > > > > > > > > > > > > > Documentation/driver-api/dma-buf.rst | 6 +++ > > > > > > > > drivers/dma-buf/dma-fence.c | 59 > > > > > > > > > > > > > > > > include/linux/dma-fence.h| 22 +++ > > > > > > > > 3 files changed, 87 insertions(+) > > > > > > > > > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst > > > > > > > > b/Documentation/driver-api/dma-buf.rst > > > > > > > > index 622b8156d212..183e480d8cea 100644 > > > > > > > > --- a/Documentation/driver-api/dma-buf.rst > > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst > > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations > > > > > > > > .. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > > :doc: fence signalling annotation > > > > > > > > > > > > > > > > +DMA Fence Deadline Hints > > > > > > > > + > > > > > > > > + > > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > > + :doc: deadline hints > > > > > > > > + > > > > > > > > DMA Fences Functions Reference > > > > > > > > ~~ > > > > > > > > > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c > > > > > > > > b/drivers/dma-buf/dma-fence.c > > > > > > > > index 0de0482cd36e..f177c56269bb 100644 > > > > > > > > --- a/drivers/dma-buf/dma-fence.c > > > > > > > > +++ b/drivers/dma-buf/dma-fence.c > > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct > > > > > > > > dma_fence **fences, uint32_t count, > > > > > > > > } > > > > > > > > EXPORT_SYMBOL(dma_fence_wait_any_timeout); > > > > > > > > > > > > > > > > +/** > > > > > > > > + * DOC: deadline hints > > > > > > > > + * > > > > > > > > + * In an ideal world, it would be possible to pipeline a > > > > > > > > workload sufficiently > > > > > > > > + * that a utilization based device frequency governor could > > > > > > > > arrive at a minimum > > > > > > > > + * frequency that meets the requirements of the use-case, in > > > > > > > > order to minimize > > > > > > > > + * power consumption. But in the real world there are many > > > > > > > > workloads which > > > > > > > > + * defy this ideal. For example, but not limited to: > > > > > > > > + * > > > > > > > > + * * Workloads that ping-pong between device and CPU, with > > > > > > > > alternating periods > > > > > > > > + * of CPU waiting for device, and device waiting on CPU. > > > > > > > > This can result in > > > > > > > > + * devfreq and cpufreq seeing idle time in their respective > > > > > > > > domains and in > > > > > > > > + * result reduce frequency. > > > > > > > > + * > > > > > > > > + * * Workloads that interact with a periodic time based > > > > > > > > deadline, such as double > > > > > > > > + * buffered GPU rendering vs vblank sync'd page flipping. > > > > > > > > In this scenario, > > > > > > > > + * missing a vblank deadline results in an *increase* in > > > > > > > > idle time on the GPU > > > > > > > > + *
Re: [Intel-gfx] [PATCH 2/7] drm/tegra: allow compile test on !ARM
Hi Christian, I love your patch! Yet something to improve: [auto build test ERROR on drm-misc/drm-misc-next] [cannot apply to drm-tip/drm-tip] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Christian-K-nig/drm-tegra-allow-compile-test-on-ARM/20230316-172205 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20230316082035.567520-3-christian.koenig%40amd.com patch subject: [Intel-gfx] [PATCH 2/7] drm/tegra: allow compile test on !ARM config: mips-allmodconfig (https://download.01.org/0day-ci/archive/20230317/202303170635.a2rsq1wu-...@intel.com/config) compiler: mips-linux-gcc (GCC) 12.1.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/8a2dbd34b0290b78a1ac2252d451abbcbcd50666 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Christian-K-nig/drm-tegra-allow-compile-test-on-ARM/20230316-172205 git checkout 8a2dbd34b0290b78a1ac2252d451abbcbcd50666 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=mips olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=mips SHELL=/bin/bash drivers/gpu/drm/tegra/ If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202303170635.a2rsq1wu-...@intel.com/ All errors (new ones prefixed by >>): drivers/gpu/drm/tegra/gem.c: In function 'tegra_bo_mmap': >> drivers/gpu/drm/tegra/gem.c:188:24: error: implicit declaration of function >> 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration] 188 | return vmap(obj->pages, obj->num_pages, VM_MAP, |^~~~ |kmap >> drivers/gpu/drm/tegra/gem.c:188:57: error: 'VM_MAP' undeclared (first use in >> this function); did you mean 'VM_MTE'? 188 | return vmap(obj->pages, obj->num_pages, VM_MAP, | ^~ | VM_MTE drivers/gpu/drm/tegra/gem.c:188:57: note: each undeclared identifier is reported only once for each function it appears in drivers/gpu/drm/tegra/gem.c: In function 'tegra_bo_munmap': >> drivers/gpu/drm/tegra/gem.c:203:17: error: implicit declaration of function >> 'vunmap'; did you mean 'kunmap'? [-Werror=implicit-function-declaration] 203 | vunmap(addr); | ^~ | kunmap drivers/gpu/drm/tegra/gem.c: In function 'tegra_bo_mmap': drivers/gpu/drm/tegra/gem.c:191:1: error: control reaches end of non-void function [-Werror=return-type] 191 | } | ^ cc1: some warnings being treated as errors -- drivers/gpu/drm/tegra/fb.c: In function 'tegra_fbdev_probe': >> drivers/gpu/drm/tegra/fb.c:276:29: error: implicit declaration of function >> 'vmap'; did you mean 'kmap'? [-Werror=implicit-function-declaration] 276 | bo->vaddr = vmap(bo->pages, bo->num_pages, VM_MAP, | ^~~~ | kmap >> drivers/gpu/drm/tegra/fb.c:276:60: error: 'VM_MAP' undeclared (first use in >> this function); did you mean 'VM_MTE'? 276 | bo->vaddr = vmap(bo->pages, bo->num_pages, VM_MAP, |^~ |VM_MTE drivers/gpu/drm/tegra/fb.c:276:60: note: each undeclared identifier is reported only once for each function it appears in drivers/gpu/drm/tegra/fb.c: In function 'tegra_fbdev_exit': >> drivers/gpu/drm/tegra/fb.c:359:25: error: implicit declaration of function >> 'vunmap'; did you mean 'kunmap'? [-Werror=implicit-function-declaration] 359 | vunmap(bo->vaddr); | ^~ | kunmap cc1: some warnings being treated as errors vim +188 drivers/gpu/drm/tegra/gem.c de2ba664c30fcdb drivers/gpu/host1x/drm/gem.c Arto Merilainen 2013-03-22 175 de2ba664c30fcdb drivers/gpu/host1x/drm/gem.c Arto Merilainen 2013-03-22 176 static void *tegra_bo_mmap(struct host1x_bo *bo
Re: [Intel-gfx] [PATCH 4/7] drm/debugfs: rework debugfs directory creation v2
Hi Christian, I love your patch! Yet something to improve: [auto build test ERROR on drm-misc/drm-misc-next] [also build test ERROR on drm-intel/for-linux-next drm-intel/for-linux-next-fixes linus/master v6.3-rc2 next-20230316] [cannot apply to drm-tip/drm-tip tegra/for-next] [If your patch is applied to the wrong git tree, kindly drop us a note. And when submitting patch, we suggest to use '--base' as documented in https://git-scm.com/docs/git-format-patch#_base_tree_information] url: https://github.com/intel-lab-lkp/linux/commits/Christian-K-nig/drm-tegra-allow-compile-test-on-ARM/20230316-172205 base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next patch link: https://lore.kernel.org/r/20230316082035.567520-5-christian.koenig%40amd.com patch subject: [Intel-gfx] [PATCH 4/7] drm/debugfs: rework debugfs directory creation v2 config: ia64-defconfig (https://download.01.org/0day-ci/archive/20230317/202303170646.mwaw3ikp-...@intel.com/config) compiler: ia64-linux-gcc (GCC) 12.1.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/a3ad5ec323e8f1864cc8b721dbb154f0e0e2919d git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Christian-K-nig/drm-tegra-allow-compile-test-on-ARM/20230316-172205 git checkout a3ad5ec323e8f1864cc8b721dbb154f0e0e2919d # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=ia64 olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=ia64 SHELL=/bin/bash drivers/gpu/ If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202303170646.mwaw3ikp-...@intel.com/ All errors (new ones prefixed by >>): In file included from drivers/gpu/drm/drm_atomic.c:47: >> drivers/gpu/drm/drm_internal.h:195:8: error: return type defaults to 'int' >> [-Werror=implicit-int] 195 | static drm_debugfs_dev_register(struct drm_device *dev) |^~~~ drivers/gpu/drm/drm_internal.h:195:8: warning: 'drm_debugfs_dev_register' defined but not used [-Wunused-function] In file included from drivers/gpu/drm/drm_atomic.c:38: include/drm/drm_drv.h:596:13: warning: 'drm_debugfs_dev_init' defined but not used [-Wunused-function] 596 | static void drm_debugfs_dev_init(struct drm_device *dev, struct dentry *root) | ^~~~ cc1: some warnings being treated as errors -- In file included from drivers/gpu/drm/drm_drv.c:50: >> drivers/gpu/drm/drm_internal.h:195:8: error: return type defaults to 'int' >> [-Werror=implicit-int] 195 | static drm_debugfs_dev_register(struct drm_device *dev) |^~~~ drivers/gpu/drm/drm_drv.c: In function 'drm_dev_unregister': >> drivers/gpu/drm/drm_drv.c:1011:9: error: implicit declaration of function >> 'drm_debugfs_dev_fini'; did you mean 'drm_debugfs_dev_init'? >> [-Werror=implicit-function-declaration] 1011 | drm_debugfs_dev_fini(dev); | ^~~~ | drm_debugfs_dev_init drivers/gpu/drm/drm_internal.h: In function 'drm_debugfs_dev_register': drivers/gpu/drm/drm_internal.h:197:1: error: control reaches end of non-void function [-Werror=return-type] 197 | } | ^ cc1: some warnings being treated as errors -- In file included from drivers/gpu/drm/drm_managed.c:18: >> drivers/gpu/drm/drm_internal.h:195:8: error: return type defaults to 'int' >> [-Werror=implicit-int] 195 | static drm_debugfs_dev_register(struct drm_device *dev) |^~~~ drivers/gpu/drm/drm_internal.h:195:8: warning: 'drm_debugfs_dev_register' defined but not used [-Wunused-function] cc1: some warnings being treated as errors vim +/int +195 drivers/gpu/drm/drm_internal.h 180 181 /* drm_debugfs.c drm_debugfs_crc.c */ 182 #if defined(CONFIG_DEBUG_FS) 183 void drm_debugfs_dev_fini(struct drm_device *dev); 184 void drm_debugfs_dev_register(struct drm_device *dev); 185 int drm_debugfs_register(struct drm_minor *minor, int minor_id, 186 struct dentry *root); 187 void drm_debugfs_cleanup(struct drm_minor *minor); 188 void drm_debugfs_late_register(struct drm_device *dev); 189 void drm_debugfs_connector_add(struct drm_connector *connector); 190 void drm_debugfs_connector_remove(struct drm_connector *connector); 191 void drm_debugfs_crtc_add(struct drm_crtc *crtc); 192 void drm_debugfs_crtc_
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/tc: Fix a few TypeC / MST issues
== Series Details == Series: drm/i915/tc: Fix a few TypeC / MST issues URL : https://patchwork.freedesktop.org/series/115270/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12872 -> Patchwork_115270v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_115270v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_115270v1, 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_115270v1/index.html Participating hosts (35 -> 34) -- Additional (1): fi-pnv-d510 Missing(2): fi-kbl-soraka fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_115270v1: ### IGT changes ### Possible regressions * igt@i915_module_load@load: - bat-adlm-1: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adlm-1/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/bat-adlm-1/igt@i915_module_l...@load.html Known issues Here are the changes found in Patchwork_115270v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][3] -> [ABORT][4] ([i915#7911]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@slpc: - bat-rpls-1: [PASS][5] -> [DMESG-FAIL][6] ([i915#6367] / [i915#7996]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-rpls-1/igt@i915_selftest@l...@slpc.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-5: NOTRUN -> [SKIP][7] ([i915#7828]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-adln-1: NOTRUN -> [SKIP][8] ([i915#7828]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_psr@primary_page_flip: - fi-pnv-d510:NOTRUN -> [SKIP][9] ([fdo#109271]) +38 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - bat-adln-1: [FAIL][10] ([i915#8064]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - bat-adln-1: [ABORT][12] ([i915#8144]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [ABORT][14] ([i915#4983]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][16] ([i915#7699]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg2-11/igt@i915_selftest@l...@migrate.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115270v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 [i915#8064]: https://gitlab.freedesktop.org/drm/intel/issues/8064 [i915#8144]: https://gitlab.freedesktop.org/drm/intel/issues/8144 Build changes - * Linux: CI_DRM_12872 -> Patchwork_115270v1 CI-20190529: 20190529 CI_DRM_12872: f65e171596ef70c076fe02be596de29e83cfc8a3 @
Re: [Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness
On Thu, Mar 16, 2023 at 5:29 PM Rob Clark wrote: > > On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote: > > > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote: > > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote: > > > > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote: > > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl wrote: > > > > > > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > > > > > > > From: Rob Clark > > > > > > > > > > > > > > Add a way to hint to the fence signaler of an upcoming deadline, > > > > > > > such as > > > > > > > vblank, which the fence waiter would prefer not to miss. This is > > > > > > > to aid > > > > > > > the fence signaler in making power management decisions, like > > > > > > > boosting > > > > > > > frequency as the deadline approaches and awareness of missing > > > > > > > deadlines > > > > > > > so that can be factored in to the frequency scaling. > > > > > > > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter duplicate > > > > > > > deadlines, to avoid increasing dma_fence size. The > > > > > > > fence-context > > > > > > > implementation will need similar logic to track deadlines of > > > > > > > all > > > > > > > the fences on the same timeline. [ckoenig] > > > > > > > v3: Clarify locking wrt. set_deadline callback > > > > > > > v4: Clarify in docs comment that this is a hint > > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > > > > > > > v6: More docs > > > > > > > v7: Fix typo, clarify past deadlines > > > > > > > > > > > > > > Signed-off-by: Rob Clark > > > > > > > Reviewed-by: Christian König > > > > > > > Acked-by: Pekka Paalanen > > > > > > > Reviewed-by: Bagas Sanjaya > > > > > > > --- > > > > > > > > > > > > Hi Rob! > > > > > > > > > > > > > Documentation/driver-api/dma-buf.rst | 6 +++ > > > > > > > drivers/dma-buf/dma-fence.c | 59 > > > > > > > > > > > > > > include/linux/dma-fence.h| 22 +++ > > > > > > > 3 files changed, 87 insertions(+) > > > > > > > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst > > > > > > > b/Documentation/driver-api/dma-buf.rst > > > > > > > index 622b8156d212..183e480d8cea 100644 > > > > > > > --- a/Documentation/driver-api/dma-buf.rst > > > > > > > +++ b/Documentation/driver-api/dma-buf.rst > > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations > > > > > > > .. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > :doc: fence signalling annotation > > > > > > > > > > > > > > +DMA Fence Deadline Hints > > > > > > > + > > > > > > > + > > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > > + :doc: deadline hints > > > > > > > + > > > > > > > DMA Fences Functions Reference > > > > > > > ~~ > > > > > > > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c > > > > > > > b/drivers/dma-buf/dma-fence.c > > > > > > > index 0de0482cd36e..f177c56269bb 100644 > > > > > > > --- a/drivers/dma-buf/dma-fence.c > > > > > > > +++ b/drivers/dma-buf/dma-fence.c > > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct dma_fence > > > > > > > **fences, uint32_t count, > > > > > > > } > > > > > > > EXPORT_SYMBOL(dma_fence_wait_any_timeout); > > > > > > > > > > > > > > +/** > > > > > > > + * DOC: deadline hints > > > > > > > + * > > > > > > > + * In an ideal world, it would be possible to pipeline a > > > > > > > workload sufficiently > > > > > > > + * that a utilization based device frequency governor could > > > > > > > arrive at a minimum > > > > > > > + * frequency that meets the requirements of the use-case, in > > > > > > > order to minimize > > > > > > > + * power consumption. But in the real world there are many > > > > > > > workloads which > > > > > > > + * defy this ideal. For example, but not limited to: > > > > > > > + * > > > > > > > + * * Workloads that ping-pong between device and CPU, with > > > > > > > alternating periods > > > > > > > + * of CPU waiting for device, and device waiting on CPU. This > > > > > > > can result in > > > > > > > + * devfreq and cpufreq seeing idle time in their respective > > > > > > > domains and in > > > > > > > + * result reduce frequency. > > > > > > > + * > > > > > > > + * * Workloads that interact with a periodic time based > > > > > > > deadline, such as double > > > > > > > + * buffered GPU rendering vs vblank sync'd page flipping. In > > > > > > > this scenario, > > > > > > > + * missing a vblank deadline results in an *increase* in idle > > > > > > > time on the GPU > > > > > > > + * (since it has to wait an additional vblank period), sending > > > > > > > a signal to > > > > > > > + * the GPU's devfreq to reduce frequency, when in fact the > > > > > > > opposite is what is > > > > > > > + * needed. > > > > > > > > > > > > This is the use case I'd like to get some
[Intel-gfx] [PATCH v2 1/2] drm/i915/guc: Improve GuC load error reporting
From: John Harrison
There are multiple ways in which the GuC load can fail. The driver was
reporting the status register as is, but not everyone can read the
matrix unfiltered. So add decoding of the common error cases.
Also, remove the comment about interrupt based load completion
checking being not recommended. The interrupt was removed from the GuC
firmware some time ago so it is no longer an option anyway. While at
it, also abort the timeout if a known error code is reported. No need
to keep waiting if the GuC has already given up the load.
v2: Fix mis-matched case and confusing 'success' variable (Daniele).
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
---
.../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 17
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 95 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h| 4 +-
3 files changed, 95 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
index 8085fb1812748..bcb1129b36102 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h
@@ -21,6 +21,9 @@ enum intel_guc_load_status {
INTEL_GUC_LOAD_STATUS_ERROR_DEVID_BUILD_MISMATCH = 0x02,
INTEL_GUC_LOAD_STATUS_GUC_PREPROD_BUILD_MISMATCH = 0x03,
INTEL_GUC_LOAD_STATUS_ERROR_DEVID_INVALID_GUCTYPE = 0x04,
+ INTEL_GUC_LOAD_STATUS_HWCONFIG_START = 0x05,
+ INTEL_GUC_LOAD_STATUS_HWCONFIG_DONE= 0x06,
+ INTEL_GUC_LOAD_STATUS_HWCONFIG_ERROR = 0x07,
INTEL_GUC_LOAD_STATUS_GDT_DONE = 0x10,
INTEL_GUC_LOAD_STATUS_IDT_DONE = 0x20,
INTEL_GUC_LOAD_STATUS_LAPIC_DONE = 0x30,
@@ -38,4 +41,18 @@ enum intel_guc_load_status {
INTEL_GUC_LOAD_STATUS_READY= 0xF0,
};
+enum intel_bootrom_load_status {
+ INTEL_BOOTROM_STATUS_NO_KEY_FOUND = 0x13,
+ INTEL_BOOTROM_STATUS_AES_PROD_KEY_FOUND = 0x1A,
+ INTEL_BOOTROM_STATUS_RSA_FAILED = 0x50,
+ INTEL_BOOTROM_STATUS_PAVPC_FAILED = 0x73,
+ INTEL_BOOTROM_STATUS_WOPCM_FAILED = 0x74,
+ INTEL_BOOTROM_STATUS_LOADLOC_FAILED = 0x75,
+ INTEL_BOOTROM_STATUS_JUMP_PASSED = 0x76,
+ INTEL_BOOTROM_STATUS_JUMP_FAILED = 0x77,
+ INTEL_BOOTROM_STATUS_RC6CTXCONFIG_FAILED = 0x79,
+ INTEL_BOOTROM_STATUS_MPUMAP_INCORRECT = 0x7A,
+ INTEL_BOOTROM_STATUS_EXCEPTION= 0x7E,
+};
+
#endif /* _ABI_GUC_ERRORS_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 69133420c78b2..0b49d84a8a9c2 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -88,31 +88,64 @@ static int guc_xfer_rsa(struct intel_uc_fw *guc_fw,
/*
* Read the GuC status register (GUC_STATUS) and store it in the
* specified location; then return a boolean indicating whether
- * the value matches either of two values representing completion
- * of the GuC boot process.
+ * the value matches either completion or a known failure code.
*
* This is used for polling the GuC status in a wait_for()
* loop below.
*/
-static inline bool guc_ready(struct intel_uncore *uncore, u32 *status)
+static inline bool guc_load_done(struct intel_uncore *uncore, u32 *status,
bool *success)
{
u32 val = intel_uncore_read(uncore, GUC_STATUS);
u32 uk_val = REG_FIELD_GET(GS_UKERNEL_MASK, val);
+ u32 br_val = REG_FIELD_GET(GS_BOOTROM_MASK, val);
*status = val;
- return uk_val == INTEL_GUC_LOAD_STATUS_READY;
+ switch (uk_val) {
+ case INTEL_GUC_LOAD_STATUS_READY:
+ *success = true;
+ return true;
+
+ case INTEL_GUC_LOAD_STATUS_ERROR_DEVID_BUILD_MISMATCH:
+ case INTEL_GUC_LOAD_STATUS_GUC_PREPROD_BUILD_MISMATCH:
+ case INTEL_GUC_LOAD_STATUS_ERROR_DEVID_INVALID_GUCTYPE:
+ case INTEL_GUC_LOAD_STATUS_HWCONFIG_ERROR:
+ case INTEL_GUC_LOAD_STATUS_DPC_ERROR:
+ case INTEL_GUC_LOAD_STATUS_EXCEPTION:
+ case INTEL_GUC_LOAD_STATUS_INIT_DATA_INVALID:
+ case INTEL_GUC_LOAD_STATUS_MPU_DATA_INVALID:
+ case INTEL_GUC_LOAD_STATUS_INIT_MMIO_SAVE_RESTORE_INVALID:
+ *success = false;
+ return true;
+ }
+
+ switch (br_val) {
+ case INTEL_BOOTROM_STATUS_NO_KEY_FOUND:
+ case INTEL_BOOTROM_STATUS_RSA_FAILED:
+ case INTEL_BOOTROM_STATUS_PAVPC_FAILED:
+ case INTEL_BOOTROM_STATUS_WOPCM_FAILED:
+ case INTEL_BOOTROM_STATUS_LOADLOC_FAILED:
+ case INTEL_BOOTROM_STATUS_JUMP_FAILED:
+ case
[Intel-gfx] [PATCH v2 0/2] Improvements to GuC load failure handling
From: John Harrison Add more decoding of the GuC load failures. Also include information about GT frequency to see if timeouts are due to a failure to boost the clocks. Finally, increase the timeout to accommodate situations where the clock boost does fail. v2: Reduce timeout in release builds, add bug references, make usage of 'success' variable a litte clearer (review feedback from Daniele). Signed-off-by: John Harrison John Harrison (2): drm/i915/guc: Improve GuC load error reporting drm/i915/guc: Allow for very slow GuC loading .../gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 17 +++ drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 141 +++--- drivers/gpu/drm/i915/gt/uc/intel_guc_reg.h| 4 +- 3 files changed, 140 insertions(+), 22 deletions(-) -- 2.39.1
[Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Allow for very slow GuC loading
From: John Harrison
A failure to load the GuC is occasionally observed where the GuC log
actually showed that the GuC had loaded just fine. The implication
being that the load just took ever so slightly longer than the 200ms
timeout. Given that the actual time should be tens of milliseconds at
the slowest, this should never happen. So far the issue has generally
been caused by a bad IFWI resulting in low frequencies during boot
(depsite the KMD requesting max frequency). However, the issue seems
to happen more often than one would like.
So a) increase the timeout so that the user still gets a working
system even in the case of slow load. And b) report the frequency
during the load to see if that is the case of the slow down.
v2: Reduce timeout in non-debug builds, add references (Daniele)
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7931
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8060
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8083
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8136
References: https://gitlab.freedesktop.org/drm/intel/-/issues/8137
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 50 +--
1 file changed, 47 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
index 0b49d84a8a9c2..6fda3aec5c66a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -12,6 +12,7 @@
#include "gt/intel_gt.h"
#include "gt/intel_gt_mcr.h"
#include "gt/intel_gt_regs.h"
+#include "gt/intel_rps.h"
#include "intel_guc_fw.h"
#include "intel_guc_print.h"
#include "i915_drv.h"
@@ -135,13 +136,29 @@ static inline bool guc_load_done(struct intel_uncore
*uncore, u32 *status, bool
return false;
}
+/*
+ * Use a longer timeout for debug builds so that problems can be detected
+ * and analysed. But a shorter timeout for releases so that user's don't
+ * wait forever to find out there is a problem. Note that the only reason
+ * an end user should hit the timeout is in case of extreme thermal throttling.
+ * And a system that is that hot during boot is probably dead anyway!
+ */
+#if defined(CONFIG_DRM_I915_DEBUG_GEM)
+#define GUC_LOAD_RETRY_LIMIT 20
+#else
+#define GUC_LOAD_RETRY_LIMIT 3
+#endif
+
static int guc_wait_ucode(struct intel_guc *guc)
{
struct intel_gt *gt = guc_to_gt(guc);
struct intel_uncore *uncore = gt->uncore;
+ ktime_t before, after, delta;
bool success;
u32 status;
- int ret;
+ int ret, count;
+ u64 delta_ms;
+ u32 before_freq;
/*
* Wait for the GuC to start up.
@@ -159,13 +176,32 @@ static int guc_wait_ucode(struct intel_guc *guc)
* issues to be resolved. In the meantime bump the timeout to
* 200ms. Even at slowest clock, this should be sufficient. And
* in the working case, a larger timeout makes no difference.
+*
+* IFWI updates have also been seen to cause sporadic failures due to
+* the requested frequency not being granted and thus the firmware
+* load is attempted at minimum frequency. That can lead to load times
+* in the seconds range. However, there is a limit on how long an
+* individual wait_for() can wait. So wrap it in a loop.
*/
- ret = wait_for(guc_load_done(uncore, , ), 200);
+ before_freq = intel_rps_read_actual_frequency(>gt->rps);
+ before = ktime_get();
+ for (count = 0; count < GUC_LOAD_RETRY_LIMIT; count++) {
+ ret = wait_for(guc_load_done(uncore, , ), 1000);
+ if (!ret || !success)
+ break;
+
+ guc_dbg(guc, "load still in progress, count = %d, freq =
%dMHz\n",
+ count,
intel_rps_read_actual_frequency(>gt->rps));
+ }
+ after = ktime_get();
+ delta = ktime_sub(after, before);
+ delta_ms = ktime_to_ms(delta);
if (ret || !success) {
u32 ukernel = REG_FIELD_GET(GS_UKERNEL_MASK, status);
u32 bootrom = REG_FIELD_GET(GS_BOOTROM_MASK, status);
- guc_info(guc, "load failed: status = 0x%08X, ret = %d\n",
status, ret);
+ guc_info(guc, "load failed: status = 0x%08X, time = %lldms,
freq = %dMHz, ret = %d\n",
+status, delta_ms,
intel_rps_read_actual_frequency(>gt->rps), ret);
guc_info(guc, "load failed: status: Reset = %d, BootROM =
0x%02X, UKernel = 0x%02X, MIA = 0x%02X, Auth = 0x%02X\n",
REG_FIELD_GET(GS_MIA_IN_RESET, status),
bootrom, ukernel,
@@ -206,6 +242,14 @@ static int guc_wait_ucode(struct intel_guc *guc)
/* Uncommon/unexpected error, see earlier status code print for
details */
if (ret == 0)
ret = -ENXIO;
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add vfio_device cdev for iommufd support (rev8)
== Series Details == Series: Add vfio_device cdev for iommufd support (rev8) URL : https://patchwork.freedesktop.org/series/113696/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/113696/revisions/8/mbox/ not applied Applying: vfio: Allocate per device file structure error: sha1 information is lacking or useless (drivers/vfio/vfio_main.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 vfio: Allocate per device file structure When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". Build failed, no error log produced
[Intel-gfx] [PATCH] drm/i915/display: Audio keep alive timestamp cdclk divisors
From: "Taylor, Clinton A"
Use BSPEC values for the Audio Keep alive M and N values as included in
the cdclk BSPEC pages for display > 13
BSPEC: 54034, 55409
Cc: Kai Vehmanen
Cc: Uma Shankar
Cc: Ville Syrjälä
Signed-off-by: Taylor, Clinton A
---
drivers/gpu/drm/i915/display/intel_audio.c | 23 +--
drivers/gpu/drm/i915/display/intel_cdclk.c | 79 ++
drivers/gpu/drm/i915/display/intel_cdclk.h | 1 +
3 files changed, 51 insertions(+), 52 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_audio.c
b/drivers/gpu/drm/i915/display/intel_audio.c
index 6c9ee905f132..cb45be5edfec 100644
--- a/drivers/gpu/drm/i915/display/intel_audio.c
+++ b/drivers/gpu/drm/i915/display/intel_audio.c
@@ -945,37 +945,16 @@ void intel_audio_hooks_init(struct drm_i915_private
*dev_priv)
}
}
-struct aud_ts_cdclk_m_n {
- u8 m;
- u16 n;
-};
-
void intel_audio_cdclk_change_pre(struct drm_i915_private *i915)
{
if (DISPLAY_VER(i915) >= 13)
intel_de_rmw(i915, AUD_TS_CDCLK_M, AUD_TS_CDCLK_M_EN, 0);
}
-static void get_aud_ts_cdclk_m_n(int refclk, int cdclk, struct
aud_ts_cdclk_m_n *aud_ts)
-{
- if (refclk == 24000)
- aud_ts->m = 12;
- else
- aud_ts->m = 15;
-
- aud_ts->n = cdclk * aud_ts->m / 24000;
-}
-
void intel_audio_cdclk_change_post(struct drm_i915_private *i915)
{
- struct aud_ts_cdclk_m_n aud_ts;
-
if (DISPLAY_VER(i915) >= 13) {
- get_aud_ts_cdclk_m_n(i915->cdclk.hw.ref, i915->cdclk.hw.cdclk,
_ts);
-
- intel_de_write(i915, AUD_TS_CDCLK_N, aud_ts.n);
- intel_de_write(i915, AUD_TS_CDCLK_M, aud_ts.m |
AUD_TS_CDCLK_M_EN);
- drm_dbg_kms(>drm, "aud_ts_cdclk set to M=%u, N=%u\n",
aud_ts.m, aud_ts.n);
+ intel_update_audio_keep_alive(i915);
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 86a22c3766e5..57021ecad509 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -37,6 +37,7 @@
#include "intel_pcode.h"
#include "intel_psr.h"
#include "vlv_sideband.h"
+#include "intel_audio_regs.h"
/**
* DOC: CDCLK / RAWCLK
@@ -1231,6 +1232,8 @@ struct intel_cdclk_vals {
u16 waveform;
u8 divider; /* CD2X divider * 2 */
u8 ratio;
+ u16 aud_m;
+ u16 aud_n;
};
static const struct intel_cdclk_vals bxt_cdclk_table[] = {
@@ -1313,40 +1316,40 @@ static const struct intel_cdclk_vals
adlp_a_step_cdclk_table[] = {
};
static const struct intel_cdclk_vals adlp_cdclk_table[] = {
- { .refclk = 19200, .cdclk = 172800, .divider = 3, .ratio = 27 },
- { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20 },
- { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32 },
- { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58 },
- { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68 },
-
- { .refclk = 24000, .cdclk = 176000, .divider = 3, .ratio = 22 },
- { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16 },
- { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26 },
- { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46 },
- { .refclk = 24400, .cdclk = 648000, .divider = 2, .ratio = 54 },
-
- { .refclk = 38400, .cdclk = 179200, .divider = 3, .ratio = 14 },
- { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio = 10 },
- { .refclk = 38400, .cdclk = 307200, .divider = 2, .ratio = 16 },
- { .refclk = 38400, .cdclk = 556800, .divider = 2, .ratio = 29 },
- { .refclk = 38400, .cdclk = 652800, .divider = 2, .ratio = 34 },
+ { .refclk = 19200, .cdclk = 172800, .divider = 3, .ratio = 27, .aud_m =
0x3C, .aud_n = 0x140 },
+ { .refclk = 19200, .cdclk = 192000, .divider = 2, .ratio = 20, .aud_m =
0x3C, .aud_n = 0x1E0 },
+ { .refclk = 19200, .cdclk = 307200, .divider = 2, .ratio = 32, .aud_m =
0x3C, .aud_n = 0x300 },
+ { .refclk = 19200, .cdclk = 556800, .divider = 2, .ratio = 58, .aud_m =
0x3C, .aud_n = 0x570 },
+ { .refclk = 19200, .cdclk = 652800, .divider = 2, .ratio = 68, .aud_m =
0x3C, .aud_n = 0x660 },
+
+ { .refclk = 24000, .cdclk = 176000, .divider = 3, .ratio = 22, .aud_m =
0x3C, .aud_n = 0x1B8 },
+ { .refclk = 24000, .cdclk = 192000, .divider = 2, .ratio = 16, .aud_m =
0x3C, .aud_n = 0x1E0 },
+ { .refclk = 24000, .cdclk = 312000, .divider = 2, .ratio = 26, .aud_m =
0x3C, .aud_n = 0x30C },
+ { .refclk = 24000, .cdclk = 552000, .divider = 2, .ratio = 46, .aud_m =
0x3C, .aud_n = 0x564 },
+ { .refclk = 24400, .cdclk = 648000, .divider = 2, .ratio = 54, .aud_m =
0x3C, .aud_n = 0x654 },
+
+ { .refclk = 38400, .cdclk = 179200, .divider = 3, .ratio = 14, .aud_m =
0x3C, .aud_n = 0x1C0 },
+ { .refclk = 38400, .cdclk = 192000, .divider = 2, .ratio =
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce new methods for verifying ownership in vfio PCI hot reset
== Series Details == Series: Introduce new methods for verifying ownership in vfio PCI hot reset URL : https://patchwork.freedesktop.org/series/115264/ State : success == Summary == CI Bug Log - changes from CI_DRM_12872 -> Patchwork_115264v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/index.html Participating hosts (35 -> 35) -- Additional (1): fi-pnv-d510 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_115264v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: [PASS][1] -> [DMESG-FAIL][2] ([i915#5334] / [i915#7872]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@reset: - bat-rpls-1: [PASS][3] -> [ABORT][4] ([i915#4983]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-rpls-1/igt@i915_selftest@l...@reset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-dg1-5: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/bat-dg1-5/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-adln-1: NOTRUN -> [SKIP][6] ([i915#7828]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/bat-adln-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][7] ([i915#3546]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html * igt@kms_psr@primary_page_flip: - fi-pnv-d510:NOTRUN -> [SKIP][8] ([fdo#109271]) +38 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html Possible fixes * igt@dmabuf@all-tests@dma_fence: - bat-adln-1: [FAIL][9] ([i915#8064]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/bat-adln-1/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - bat-adln-1: [ABORT][11] ([i915#8144]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/bat-adln-1/igt@dmabuf@all-te...@sanitycheck.html * igt@i915_selftest@live@hangcheck: - bat-dg1-5: [ABORT][13] ([i915#4983]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/bat-dg1-5/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][15] ([i915#7699]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12872/bat-dg2-11/igt@i915_selftest@l...@migrate.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115264v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#3546]: https://gitlab.freedesktop.org/drm/intel/issues/3546 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872 [i915#8064]: https://gitlab.freedesktop.org/drm/intel/issues/8064 [i915#8144]: https://gitlab.freedesktop.org/drm/intel/issues/8144 Build changes - * Linux: CI_DRM_12872 -> Patchwork_115264v1 CI-20190529: 20190529 CI_DRM_12872: f65e171596ef70c076fe02be596de29e83cfc8a3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7202: b4ec7dac375eed2dda89c64d4de94c4c9205b601 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115264v1: f65e171596ef70c076fe02be596de29e83cfc8a3 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 15f6240acfe3 vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl 76d2563c493a vfio: Accpet device file from vfio PCI hot reset path 89b88bf90326 vfio: Refine vfio file kAPIs for vfio PCI hot reset 66d08bb82754 vfio/pci: Renaming for accepting device
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Thu, Mar 16, 2023 at 01:22:58PM +, Liu, Yi L wrote: > > And regarding the new baseline for the replace series and the > > nesting series, it'd be nicer to have another one git-merging > > your cdev v7 branch on top of Jason's iommufd_hwpt branch. We > > could wait for him updating to 6.3-rc2, if that's necessary. > > Yes. I cherry-pick his iommufd_hwpt to 6.3-rc2 and then try a > merge and then cherry-pick the replace and nesting series from > your above branch. Though the order between cdev and > iommufd_hwpt not perfect, we may use it as a wip baseline > when we try to address the comments w.r.t. nesting and > replace series. > > https://github.com/yiliu1765/iommufd/tree/wip/iommufd_nesting-03162023 Nice. It looks like you integrated everything from my tree so it saves me some effort :) Regarding the order between cdev and iommufd_hwpt, I think it would be Jason's decision whether to merge his changes prior to the PR from the VFIO tree, or the other way around. One way or another, I think the replace v5 and the nesting v2 will be less impacted, unless Jason makes some huge changes to his branch. Let's use this tree this week to rework both series, and rebase after he comes back and updates his tree. Lemme know if you need a help for the nesting series or so. Thanks Nic
Re: [Intel-gfx] [PATCH v10 00/15] dma-fence: Deadline awareness
On Wed, Mar 8, 2023 at 7:53 AM Rob Clark wrote: > > From: Rob Clark > > This series adds a deadline hint to fences, so realtime deadlines > such as vblank can be communicated to the fence signaller for power/ > frequency management decisions. > > This is partially inspired by a trick i915 does, but implemented > via dma-fence for a couple of reasons: > > 1) To continue to be able to use the atomic helpers > 2) To support cases where display and gpu are different drivers > > This iteration adds a dma-fence ioctl to set a deadline (both to > support igt-tests, and compositors which delay decisions about which > client buffer to display), and a sw_sync ioctl to read back the > deadline. IGT tests utilizing these can be found at: > > > https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline > jfwiw, mesa side of this: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21973 BR, -R > > v1: https://patchwork.freedesktop.org/series/93035/ > v2: Move filtering out of later deadlines to fence implementation > to avoid increasing the size of dma_fence > v3: Add support in fence-array and fence-chain; Add some uabi to > support igt tests and userspace compositors. > v4: Rebase, address various comments, and add syncobj deadline > support, and sync_file EPOLLPRI based on experience with perf/ > freq issues with clvk compute workloads on i915 (anv) > v5: Clarify that this is a hint as opposed to a more hard deadline > guarantee, switch to using u64 ns values in UABI (still absolute > CLOCK_MONOTONIC values), drop syncobj related cap and driver > feature flag in favor of allowing count_handles==0 for probing > kernel support. > v6: Re-work vblank helper to calculate time of _start_ of vblank, > and work correctly if the last vblank event was more than a > frame ago. Add (mostly unrelated) drm/msm patch which also > uses the vblank helper. Use dma_fence_chain_contained(). More > verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > v7: Fix kbuild complaints about vblank helper. Add more docs. > v8: Add patch to surface sync_file UAPI, and more docs updates. > v9: Drop (E)POLLPRI support.. I still like it, but not essential and > it can always be revived later. Fix doc build warning. > v10: Update 11/15 to handle multiple CRTCs > > Rob Clark (15): > dma-buf/dma-fence: Add deadline awareness > dma-buf/fence-array: Add fence deadline support > dma-buf/fence-chain: Add fence deadline support > dma-buf/dma-resv: Add a way to set fence deadline > dma-buf/sync_file: Surface sync-file uABI > dma-buf/sync_file: Add SET_DEADLINE ioctl > dma-buf/sw_sync: Add fence deadline support > drm/scheduler: Add fence deadline support > drm/syncobj: Add deadline support for syncobj waits > drm/vblank: Add helper to get next vblank time > drm/atomic-helper: Set fence deadline for vblank > drm/msm: Add deadline based boost support > drm/msm: Add wait-boost support > drm/msm/atomic: Switch to vblank_start helper > drm/i915: Add deadline based boost support > > Rob Clark (15): > dma-buf/dma-fence: Add deadline awareness > dma-buf/fence-array: Add fence deadline support > dma-buf/fence-chain: Add fence deadline support > dma-buf/dma-resv: Add a way to set fence deadline > dma-buf/sync_file: Surface sync-file uABI > dma-buf/sync_file: Add SET_DEADLINE ioctl > dma-buf/sw_sync: Add fence deadline support > drm/scheduler: Add fence deadline support > drm/syncobj: Add deadline support for syncobj waits > drm/vblank: Add helper to get next vblank time > drm/atomic-helper: Set fence deadline for vblank > drm/msm: Add deadline based boost support > drm/msm: Add wait-boost support > drm/msm/atomic: Switch to vblank_start helper > drm/i915: Add deadline based boost support > > Documentation/driver-api/dma-buf.rst| 16 - > drivers/dma-buf/dma-fence-array.c | 11 > drivers/dma-buf/dma-fence-chain.c | 12 > drivers/dma-buf/dma-fence.c | 60 ++ > drivers/dma-buf/dma-resv.c | 22 +++ > drivers/dma-buf/sw_sync.c | 81 + > drivers/dma-buf/sync_debug.h| 2 + > drivers/dma-buf/sync_file.c | 19 ++ > drivers/gpu/drm/drm_atomic_helper.c | 37 +++ > drivers/gpu/drm/drm_syncobj.c | 64 +++ > drivers/gpu/drm/drm_vblank.c| 53 +--- > drivers/gpu/drm/i915/i915_request.c | 20 ++ > drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 - > drivers/gpu/drm/msm/msm_atomic.c| 8 ++- > drivers/gpu/drm/msm/msm_drv.c | 12 ++-- > drivers/gpu/drm/msm/msm_fence.c | 74 ++ > drivers/gpu/drm/msm/msm_fence.h | 20 ++ > drivers/gpu/drm/msm/msm_gem.c | 5 ++ > drivers/gpu/drm/msm/msm_kms.h | 8 --- >
Re: [Intel-gfx] [PATCH 5.4.y] drm/i915: Don't use BAR mappings for ring buffers with LLC
On 3/15/2023 10:57, Greg KH wrote:
On Wed, Mar 15, 2023 at 10:07:53AM -0700, John Harrison wrote:
On 3/15/2023 00:51, Greg KH wrote:
On Mon, Mar 13, 2023 at 07:22:11PM -0700, john.c.harri...@intel.com wrote:
From: John Harrison
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
Signed-off-by: John Harrison
Fixes: 9d80841ea4c9 ("drm/i915: Allow ringbuffers to be bound anywhere")
Cc: Chris Wilson
Cc: Joonas Lahtinen
Cc: Jani Nikula
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-gfx@lists.freedesktop.org
Cc: # v4.9+
Tested-by: Jouni Högander
Reviewed-by: Daniele Ceraolo Spurio
Link:
https://patchwork.freedesktop.org/patch/msgid/20230216011101.1909009-3-john.c.harri...@intel.com
(cherry picked from commit 65c08339db1ada87afd6cfe7db8e60bb4851d919)
Signed-off-by: Jani Nikula
(cherry picked from commit 85636167e3206c3fbd52254fc432991cc4e90194)
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Also queued up for 5.10.y, you forgot that one :)
I'm still working through the backlog of them.
Note that these patches must all be applied as a pair. The 'don't use
stolen' can be applied in isolation but won't totally fix the problem.
However, applying 'don't use BAR mappings' without applying the stolen patch
first will results in problems such as the failure to boot that was recently
reported and resulted in a revert in one of the trees.
I do not understand, you only submitted 1 patch here, what is the
"pair"?
The original patch series was two patches -
https://patchwork.freedesktop.org/series/114080/. One to not use stolen
memory and the other to not use BAR mappings. If the anti-BAR patch is
applied without the anti-stolen patch then the i915 driver will attempt
to access stolen memory directly which will fail. So both patches must
be applied and in the correct order to fix the problem of cache aliasing
when using BAR accesses on LLC systems.
As above, I am working my way through the bunch of 'FAILED patch'
emails. The what-to-do instructions in those emails explicitly say to
send the patch individually in reply to the 'FAILED' message rather than
as part of any original series.
John.
[Intel-gfx] [PATCH dii-client v1.1] drm/i915/mtl: Extend Wa_22011802037 to MTL A-step
From: Madhumitha Tolakanahalli Pradeep
Wa_22011802037 was being applied to all graphics_ver 11 & 12. This patch
updates the if statement to apply the W/A to right platforms and extends
it to MTL-M:A0.
v1.1: Fix checkpatch warning.
Signed-off-by: Madhumitha Tolakanahalli Pradeep
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 88e881b100cf..a099406dcc38 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1629,7 +1629,9 @@ static void guc_reset_state(struct intel_context *ce, u32
head, bool scrub)
static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
{
- if (!IS_GRAPHICS_VER(engine->i915, 11, 12))
+ if (!(IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+ (GRAPHICS_VER(engine->i915) >= 11 &&
+ GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70
return;
intel_engine_stop_cs(engine);
--
2.34.1
[Intel-gfx] [PATCH 5/5] drm/i915/mtl: WA to clear RDOP clock gating
From: Haridhar Kalvala Workaround implementation to clear RDOP clock gating. Bspec: 33453 Signed-off-by: Haridhar Kalvala Signed-off-by: Radhakrishna Sripada --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index e7ee24bcad89..92cfc71324c4 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -1703,6 +1703,9 @@ xelpg_gt_workarounds_init(struct intel_gt *gt, struct i915_wa_list *wal) /* Wa_18018781329 */ wa_mcr_write_or(wal, RENDER_MOD_CTRL, FORCE_MISS_FTLB); wa_mcr_write_or(wal, COMP_MOD_CTRL, FORCE_MISS_FTLB); + + /* Wa_14015795083 */ + wa_write_clr(wal, GEN7_MISCCPCTL, GEN12_DOP_CLOCK_GATE_RENDER_ENABLE); } /* -- 2.34.1
[Intel-gfx] [PATCH 4/5] drm/i915/mtl: Synchronize i915/BIOS on C6 enabling
From: Vinay Belgaumkar
If BIOS enables/disables C6, i915 should do the same. Also, retain
this value across driver reloads. This is needed only for MTL as
of now due to an existing bug in OA which needs C6 disabled for
it to function. BIOS behavior is also different across platforms
in terms of how C6 is enabled.
v2: Review comments (Umesh)
v3: Cache the C6 enable value for all MTL. The OA WA is needed only
for A/B step, but we don't need to check for that here.
v4: Rename to mtl_check_bios_c6_setup()
Signed-off-by: Vinay Belgaumkar
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 21 +
drivers/gpu/drm/i915/gt/intel_rc6_types.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index f4150f61f39c..517d14e29aac 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -420,6 +420,15 @@ static void vlv_rc6_enable(struct intel_rc6 *rc6)
GEN7_RC_CTL_TO_MODE | VLV_RC_CTL_CTX_RST_PARALLEL;
}
+static bool mtl_check_bios_c6_setup(struct intel_rc6 *rc6)
+{
+ struct intel_uncore *uncore = rc6_to_uncore(rc6);
+
+ rc6->bios_rc_state = intel_uncore_read(uncore, GEN6_RC_STATE);
+
+ return rc6->bios_rc_state & RC_SW_TARGET_STATE_MASK;
+}
+
static bool bxt_check_bios_rc6_setup(struct intel_rc6 *rc6)
{
struct intel_uncore *uncore = rc6_to_uncore(rc6);
@@ -503,6 +512,13 @@ static bool rc6_supported(struct intel_rc6 *rc6)
return false;
}
+ if (IS_METEORLAKE(gt->i915) &&
+ !mtl_check_bios_c6_setup(rc6)) {
+ drm_notice(>drm,
+ "C6 disabled by BIOS\n");
+ return false;
+ }
+
if (IS_MTL_MEDIA_STEP(gt->i915, STEP_A0, STEP_B0) &&
gt->type == GT_MEDIA) {
drm_notice(>drm,
@@ -707,9 +723,14 @@ void intel_rc6_disable(struct intel_rc6 *rc6)
void intel_rc6_fini(struct intel_rc6 *rc6)
{
struct drm_i915_gem_object *pctx;
+ struct intel_uncore *uncore = rc6_to_uncore(rc6);
intel_rc6_disable(rc6);
+ /* We want the BIOS C6 state preserved across loads for MTL */
+ if (IS_METEORLAKE(rc6_to_i915(rc6)))
+ set(uncore, GEN6_RC_STATE, rc6->bios_rc_state);
+
pctx = fetch_and_zero(>pctx);
if (pctx)
i915_gem_object_put(pctx);
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6_types.h
b/drivers/gpu/drm/i915/gt/intel_rc6_types.h
index fa23c4dce00b..57bb437bcbbd 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_rc6_types.h
@@ -29,6 +29,7 @@ struct intel_rc6 {
u64 cur_residency[INTEL_RC6_RES_MAX];
u32 ctl_enable;
+ u32 bios_rc_state;
struct drm_i915_gem_object *pctx;
--
2.34.1
[Intel-gfx] [PATCH 3/5] drm/i915/mtl: Extend Wa_22011802037 to MTL A-step
From: Madhumitha Tolakanahalli Pradeep
Wa_22011802037 was being applied to all graphics_ver 11 & 12. This patch
updates the if statement to apply the W/A to right platforms and extends
it to MTL-M:A0.
Signed-off-by: Madhumitha Tolakanahalli Pradeep
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 88e881b100cf..e8c4fb9c4901 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1629,7 +1629,9 @@ static void guc_reset_state(struct intel_context *ce, u32
head, bool scrub)
static void guc_engine_reset_prepare(struct intel_engine_cs *engine)
{
- if (!IS_GRAPHICS_VER(engine->i915, 11, 12))
+ if (!(IS_MTL_GRAPHICS_STEP(engine->i915, M, STEP_A0, STEP_B0) ||
+ (GRAPHICS_VER(engine->i915) >= 11 &&
+GRAPHICS_VER_FULL(engine->i915) < IP_VER(12, 70
return;
intel_engine_stop_cs(engine);
--
2.34.1
[Intel-gfx] [PATCH 2/5] drm/i915/mtl: Re-use ADL-P's "DC off" power well
From: Matt Roper
As with ADL-P, MTL's "DC off" power well should be a dependency of the
PGC and PGD power wells, not the entire PG2 well. In fact, the DC5/DC6
requirements between the two platforms are the same, so the Xe_LPD "DC
off" well definition can just be re-used for Xe_LPD+.
Bspec: 49193
Signed-off-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
.../drm/i915/display/intel_display_power_map.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index d9e02cc9cf3c..452b6cbdfd98 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1456,15 +1456,6 @@ I915_DECL_PW_DOMAINS(xelpdp_pwdoms_pw_2,
XELPDP_PW_2_POWER_DOMAINS,
POWER_DOMAIN_INIT);
-I915_DECL_PW_DOMAINS(xelpdp_pwdoms_dc_off,
- XELPDP_PW_2_POWER_DOMAINS,
- POWER_DOMAIN_AUDIO_MMIO,
- POWER_DOMAIN_MODESET,
- POWER_DOMAIN_AUX_A,
- POWER_DOMAIN_AUX_B,
- POWER_DOMAIN_DC_OFF,
- POWER_DOMAIN_INIT);
-
I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc1,
POWER_DOMAIN_AUX_USBC1,
POWER_DOMAIN_AUX_TBT1);
@@ -1483,12 +1474,6 @@ I915_DECL_PW_DOMAINS(xelpdp_pwdoms_aux_tc4,
static const struct i915_power_well_desc xelpdp_power_wells_main[] = {
{
- .instances = _PW_INSTANCES(
- I915_PW("DC_off", _pwdoms_dc_off,
- .id = SKL_DISP_DC_OFF),
- ),
- .ops = _dc_off_power_well_ops,
- }, {
.instances = _PW_INSTANCES(
I915_PW("PW_2", _pwdoms_pw_2,
.hsw.idx = ICL_PW_CTL_IDX_PW_2,
@@ -1545,6 +1530,7 @@ static const struct i915_power_well_desc
xelpdp_power_wells_main[] = {
static const struct i915_power_well_desc_list xelpdp_power_wells[] = {
I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
+ I915_PW_DESCRIPTORS(xelpd_power_wells_dcoff),
I915_PW_DESCRIPTORS(xelpdp_power_wells_main),
};
--
2.34.1
[Intel-gfx] [PATCH 0/5] More MTL WA and powerwell patches
This series adds 2 MTL WA's, 2 patches to fix re-use "DC off" power wells and another patch to sync BIOS and driver for C6 enabling. Haridhar Kalvala (1): drm/i915/mtl: WA to clear RDOP clock gating Madhumitha Tolakanahalli Pradeep (1): drm/i915/mtl: Extend Wa_22011802037 to MTL A-step Matt Roper (2): drm/i915: Use separate "DC off" power well for ADL-P and DG2 drm/i915/mtl: Re-use ADL-P's "DC off" power well Vinay Belgaumkar (1): drm/i915/mtl: Synchronize i915/BIOS on C6 enabling .../i915/display/intel_display_power_map.c| 57 +-- drivers/gpu/drm/i915/gt/intel_rc6.c | 21 +++ drivers/gpu/drm/i915/gt/intel_rc6_types.h | 1 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 + .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 4 +- 5 files changed, 67 insertions(+), 19 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH 1/5] drm/i915: Use separate "DC off" power well for ADL-P and DG2
From: Matt Roper
Although ADL-P and DG2 both use the same general power well setup, the
DC5/DC6 requirements are slightly different which means each platform
should have its own "DC off" power well.
DG2 (i.e., Xe_HPD IP) requires that DC5 be disabled whenever PG2 is
active. However ADL-P (i.e., Xe_LPD IP) only requires DC5/DC6 to be
disabled when the PGC or PGD subwells are active; we should be able to
remain in these DC states when PGB and general PG2 functionality is in
use.
Bspec: 49193
Signed-off-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
---
.../i915/display/intel_display_power_map.c| 41 +--
1 file changed, 38 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_map.c
b/drivers/gpu/drm/i915/display/intel_display_power_map.c
index 6645eb1911d8..d9e02cc9cf3c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1301,7 +1301,8 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_pw_2,
*/
I915_DECL_PW_DOMAINS(xelpd_pwdoms_dc_off,
- XELPD_PW_2_POWER_DOMAINS,
+ XELPD_PW_C_POWER_DOMAINS,
+ XELPD_PW_D_POWER_DOMAINS,
POWER_DOMAIN_PORT_DSI,
POWER_DOMAIN_AUDIO_MMIO,
POWER_DOMAIN_AUX_A,
@@ -1310,14 +1311,38 @@ I915_DECL_PW_DOMAINS(xelpd_pwdoms_dc_off,
POWER_DOMAIN_DC_OFF,
POWER_DOMAIN_INIT);
-static const struct i915_power_well_desc xelpd_power_wells_main[] = {
+static const struct i915_power_well_desc xelpd_power_wells_dcoff[] = {
{
.instances = _PW_INSTANCES(
I915_PW("DC_off", _pwdoms_dc_off,
.id = SKL_DISP_DC_OFF),
),
.ops = _dc_off_power_well_ops,
- }, {
+ }
+};
+
+I915_DECL_PW_DOMAINS(xehpd_pwdoms_dc_off,
+ XELPD_PW_2_POWER_DOMAINS,
+ POWER_DOMAIN_PORT_DSI,
+ POWER_DOMAIN_AUDIO_MMIO,
+ POWER_DOMAIN_AUX_A,
+ POWER_DOMAIN_AUX_B,
+ POWER_DOMAIN_MODESET,
+ POWER_DOMAIN_DC_OFF,
+ POWER_DOMAIN_INIT);
+
+static const struct i915_power_well_desc xehpd_power_wells_dcoff[] = {
+ {
+ .instances = _PW_INSTANCES(
+ I915_PW("DC_off", _pwdoms_dc_off,
+ .id = SKL_DISP_DC_OFF),
+ ),
+ .ops = _dc_off_power_well_ops,
+ }
+};
+
+static const struct i915_power_well_desc xelpd_power_wells_main[] = {
+ {
.instances = _PW_INSTANCES(
I915_PW("PW_2", _pwdoms_pw_2,
.hsw.idx = ICL_PW_CTL_IDX_PW_2,
@@ -1400,6 +1425,14 @@ static const struct i915_power_well_desc
xelpd_power_wells_main[] = {
static const struct i915_power_well_desc_list xelpd_power_wells[] = {
I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
+ I915_PW_DESCRIPTORS(xelpd_power_wells_dcoff),
+ I915_PW_DESCRIPTORS(xelpd_power_wells_main),
+};
+
+static const struct i915_power_well_desc_list xehpd_power_wells[] = {
+ I915_PW_DESCRIPTORS(i9xx_power_wells_always_on),
+ I915_PW_DESCRIPTORS(icl_power_wells_pw_1),
+ I915_PW_DESCRIPTORS(xehpd_power_wells_dcoff),
I915_PW_DESCRIPTORS(xelpd_power_wells_main),
};
@@ -1624,6 +1657,8 @@ int intel_display_power_map_init(struct
i915_power_domains *power_domains)
if (DISPLAY_VER(i915) >= 14)
return set_power_wells(power_domains, xelpdp_power_wells);
+ else if (IS_DG2(i915))
+ return set_power_wells(power_domains, xehpd_power_wells);
else if (DISPLAY_VER(i915) >= 13)
return set_power_wells(power_domains, xelpd_power_wells);
else if (IS_DG1(i915))
--
2.34.1
[Intel-gfx] ✗ Fi.CI.BAT: failure for vfio: Make emulated devices prepared for vfio device cdev (rev3)
== Series Details == Series: vfio: Make emulated devices prepared for vfio device cdev (rev3) URL : https://patchwork.freedesktop.org/series/114846/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12871 -> Patchwork_114846v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_114846v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_114846v3, 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_114846v3/index.html Participating hosts (36 -> 35) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_114846v3: ### IGT changes ### Possible regressions * igt@dmabuf@all-tests@dma_fence_chain: - bat-rplp-1: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12871/bat-rplp-1/igt@dmabuf@all-tests@dma_fence_chain.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/bat-rplp-1/igt@dmabuf@all-tests@dma_fence_chain.html * igt@dmabuf@all-tests@dma_fence_unwrap: - bat-rplp-1: [PASS][3] -> [DMESG-FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12871/bat-rplp-1/igt@dmabuf@all-tests@dma_fence_unwrap.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/bat-rplp-1/igt@dmabuf@all-tests@dma_fence_unwrap.html Known issues Here are the changes found in Patchwork_114846v3 that come from known issues: ### CI changes ### Possible fixes * boot: - fi-rkl-11600: [FAIL][5] -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12871/fi-rkl-11600/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/boot.html ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#7456]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-rkl-11600: NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#3282]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#7561]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@kms_chamelium_hpd@dp-hpd-fast: - fi-rkl-11600: NOTRUN -> [SKIP][12] ([i915#7828]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#4103]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@sprite_plane_onoff: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-read: - fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] / [i915#3708]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114846v3/fi-rkl-11600/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-userptr: - fi-rkl-11600: NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3301] / [i915#3708]) [18]:
Re: [Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Wed, 15 Mar 2023 23:31:23 + "Tian, Kevin" wrote: > > From: Alex Williamson > > Sent: Thursday, March 16, 2023 6:53 AM > > > > On Wed, 8 Mar 2023 05:28:51 -0800 > > Yi Liu wrote: > > > > > This is another method to issue PCI hot reset for the users that bounds > > > device to a positive iommufd value. In such case, iommufd is a proof of > > > device ownership. By passing a zero-length fd array, user indicates kernel > > > to do ownership check with the bound iommufd. All the opened devices > > within > > > the affected dev_set should have been bound to the same iommufd. This is > > > simpler and faster as user does not need to pass a set of fds and kernel > > > no need to search the device within the given fds. > > > > Couldn't this same idea apply to containers? > > User is allowed to create multiple containers. Looks we don't have a way > to check whether multiple containers belong to the same user today. No, but a common configuration is that all devices are in the same container, ie. no-vIOMMU, and it's also rather common that when we have multi-function devices, all functions are within the same IOMMU group and therefore necessarily require the same address space and therefore container. > > I'm afraid this proposal reduces or eliminates the handshake we have > > with userspace between VFIO_DEVICE_GET_PCI_HOT_RESET_INFO and > > VFIO_DEVICE_PCI_HOT_RESET, which could promote userspace to ignore the > > _INFO ioctl altogether, resulting in drivers that don't understand the > > scope of the reset. Is it worth it? What do we really gain? > > Jason raised the concern whether GET_PCI_HOT_RESET_INFO is actually > useful today. > > It's an interface on opened device. So the tiny difference is whether the > user knows the device is resettable when calling GET_INFO or later when > actually calling PCI_HOT_RESET. No, GET_PCI_HOT_RESET_INFO conveys not only whether a PCI_HOT_RESET can be performed, but equally important the scope of the reset, ie. which devices are affected by the reset. If we de-emphasize the INFO portion, then this easily gets confused as just a variant of VFIO_DEVICE_RESET, which is explicitly a device-level cscope reset. In fact, I'd say the interface is not only trying to validate that the user has sufficient privileges for the reset, but that they explicitly acknowledge the scope of the reset. > and with this series we also allow reset on affected devices which are not > opened. Such dynamic cannot be reflected in static GET_INFO. More > suitable a try-and-fail style. Resets have side-effects, obviously, so this isn't the sort of thing we can simply ask the user to probe for. I agree that dynamics can change, the GET_PCI_HOT_RESET_INFO is a point in time, isolated functions on the same bus can change ownership. However, in practice, and in its primary use case with GPUs without isolation, it's sufficiently static. So I think this is a mischaracterization. Thanks, Alex
Re: [Intel-gfx] [PATCH] drm/i915/gem: Clarify seemingly unaccounted obj refcount inc
On 3/15/2023 11:54 AM, Nirmoy Das wrote:
Add a comment why there is a obj refcount inc before installing
the vm_ops for the mmap call. Also remove the invalid older comment
as drm API(drm_gem_prime_mmap()) will hold an obj reference before
calling this driver mmap callback so we can't have 0-refcnted
object here.
Cc: Matthew Auld
Cc: Andi Shyti
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d3c1dee16af2..0bc8c3818443 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -952,9 +952,10 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
vma_pages(vma));
if (node && drm_vma_node_is_allowed(node, priv)) {
/*
-* Skip 0-refcnted objects as it is in the process of being
-* destroyed and will be invalid when the vma manager lock
-* is released.
This valid. Matt pointed out a case when user close the obj and call
mmap and driver only have the fake offset to refer the object
and can end up calling this while driver is freeing the obj.
I will resend with keeping the valid comment.
Nirmoy
+* When we install vm_ops for mmap we are too late for
+* the vm_ops->open() which increases the ref_count of
+* this obj and then it gets decreased by the vm_ops->close().
+* To balance this increase the obj ref_count here.
*/
if (!node->driver_private) {
mmo = container_of(node, struct i915_mmap_offset,
vma_node);
Re: [Intel-gfx] [PATCH 1/2] drm/i915/psr: Fix Wa_16013835468 and Wa_14015648006
On Tue, Mar 14, 2023 at 11:01:41AM +0200, Jouni Högander wrote:
> PSR WM optimization should be disabled based on any wm level being
> disabled. Currently it's disabled always when using delayed vblank.
>
> Bspec: 71580
>
> Signed-off-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
> drivers/gpu/drm/i915/display/intel_psr.c | 12 +---
> drivers/gpu/drm/i915/display/skl_watermark.c | 7 +--
> 3 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index c32bfba06ca1..60504c390408 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1152,6 +1152,7 @@ struct intel_crtc_state {
> bool has_psr2;
> bool enable_psr2_sel_fetch;
> bool req_psr2_sdp_prior_scanline;
> + bool wm_level_disabled;
> u32 dc3co_exitline;
> u16 su_y_granularity;
> struct drm_dp_vsc_sdp psr_vsc;
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 44610b20cd29..a6edd65b8edb 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1177,13 +1177,11 @@ static void intel_psr_enable_source(struct intel_dp
> *intel_dp,
>* Wa_16013835468
>* Wa_14015648006
>*/
> - if (IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> - IS_DISPLAY_VER(dev_priv, 12, 13)) {
> - if (crtc_state->hw.adjusted_mode.crtc_vblank_start !=
> - crtc_state->hw.adjusted_mode.crtc_vdisplay)
That looks like something we want to keep. The delayed vblank w/a is
still supposedly necessary.
> - intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
> - wa_16013835468_bit_get(intel_dp));
> - }
> + if ((IS_MTL_DISPLAY_STEP(dev_priv, STEP_A0, STEP_B0) ||
> + IS_DISPLAY_VER(dev_priv, 12, 13)) &&
I think we need this for all KBL+.
> + crtc_state->wm_level_disabled)
> + intel_de_rmw(dev_priv, GEN8_CHICKEN_DCPR_1, 0,
> + wa_16013835468_bit_get(intel_dp));
>
> if (intel_dp->psr.psr2_enabled) {
> if (DISPLAY_VER(dev_priv) == 9)
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 50a9a6adbe32..afb751c024ba 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -2273,9 +2273,12 @@ static int skl_wm_check_vblank(struct intel_crtc_state
> *crtc_state)
> return level;
>
> /*
> - * FIXME PSR needs to toggle LATENCY_REPORTING_REMOVED_PIPE_*
> + * PSR needs to toggle LATENCY_REPORTING_REMOVED_PIPE_*
>* based on whether we're limited by the vblank duration.
> - *
> + */
> + crtc_state->wm_level_disabled = level < i915->display.wm.num_levels - 1;
> +
> + /*
>* FIXME also related to skl+ w/a 1136 (also unimplemented as of
>* now) perhaps?
>*/
And that is more or less corresponding w/a for SKL/BXT that did not yet have
these chicken bits.
> --
> 2.34.1
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v2] drm/i915/gt: prevent forcewake releases during BAR resize
On 08.03.2023 14:36, Andrzej Hajda wrote: Tests on DG2 machines show that releasing forcewakes during BAR resize results later in forcewake ack timeouts. Since forcewakes can be realeased asynchronously the simplest way to prevent it is to get all forcewakes for duration of BAR resizing. v2: hold rpm as well during resizing (Rodrigo) Signed-off-by: Andrzej Hajda Queued to drm-intel-gt-next. Regards Andrzej
Re: [Intel-gfx] [PATCH v6 0/2] drm/i915: add guard page to ggtt->error_capture
On 10.03.2023 10:23, Andrzej Hajda wrote: This patch tries to diminish plague of DMAR read errors present in CI for ADL*, RPL*, DG2 platforms, see for example [1] (grep DMAR). CI is usually tolerant for these errors, so the scale of the problem is not really visible. To show it I have counted lines containing DMAR read errors in dmesgs produced by CI for all three versions of the patch, but in contrast to v2 I have grepped only for lines containing "PTE Read access". Below stats for kernel w/o patchset vs patched one. v1: 210 vs 0 v2: 201 vs 0 v3: 214 vs 0 Apparently the patchset fixes all common PTE read errors. Changelog: v2: - modified commit message (I hope the diagnosis is correct), - added bug checks to ensure scratch is initialized on gen3 platforms. CI produces strange stacktrace for it suggesting scratch[0] is NULL, to be removed after resolving the issue with gen3 platforms. v3: - removed bug checks, replaced with gen check. v4: - change code for scratch page insertion to support all platforms, - add info in commit message there could be more similar issues v5: - changed to patchset adding nop_clear_range related code, - re-insert scratch PTEs on resume v6: - use scratch_range To: Jani Nikula To: Joonas Lahtinen To: Rodrigo Vivi To: Tvrtko Ursulin Cc: intel-gfx@lists.freedesktop.org Cc: dri-de...@lists.freedesktop.org Cc: linux-ker...@vger.kernel.org Cc: Andi Shyti Cc: Chris Wilson Cc: Nirmoy Das Signed-off-by: Andrzej Hajda Queued to drm-intel-gt-next Regards Andrzej --- - Link to v5: https://lore.kernel.org/r/20230308-guard_error_capture-v5-0-6d1410d13...@intel.com --- Andrzej Hajda (2): drm/i915/gt: introduce vm->scratch_range callback drm/i915: add guard page to ggtt->error_capture drivers/gpu/drm/i915/gt/intel_ggtt.c | 43 --- drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c | 1 + drivers/gpu/drm/i915/gt/intel_gtt.h | 2 ++ 3 files changed, 42 insertions(+), 4 deletions(-) --- base-commit: 3cd6c251f39c14df9ab711e3eb56e703b359ff54 change-id: 20230308-guard_error_capture-f3f334eec85f Best regards,
[Intel-gfx] [RFC PATCH 2/2] drm/i915/display: Implement fb_mmap callback function
If stolen memory allocation fails for fbdev, the driver will
fallback to system memory. Calculation of smem_start is wrong
for such framebuffer objs if the platform comes with no gmadr or
no aperture. Solve this by adding fb_mmap callback which will
use GTT if aperture is available otherwise will use cpu to access
the framebuffer.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/display/intel_fbdev.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 673bcdfb7ff6..51d6fa034b00 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -40,8 +40,10 @@
#include
#include
#include
+#include
#include "gem/i915_gem_lmem.h"
+#include "gem/i915_gem_mman.h"
#include "i915_drv.h"
#include "intel_display_types.h"
@@ -120,6 +122,16 @@ static int intel_fbdev_pan_display(struct
fb_var_screeninfo *var,
return ret;
}
+#define to_intel_fbdev(x) container_of(x, struct intel_fbdev, helper)
+static int intel_fbdev_mmap(struct fb_info *info, struct vm_area_struct *vma)
+{
+ struct intel_fbdev *fbdev = to_intel_fbdev(info->par);
+ struct drm_gem_object *bo = drm_gem_fb_get_obj(>fb->base, 0);
+ struct drm_i915_gem_object *obj = to_intel_bo(bo);
+
+ return i915_gem_fb_mmap(obj, vma);
+}
+
static const struct fb_ops intelfb_ops = {
.owner = THIS_MODULE,
DRM_FB_HELPER_DEFAULT_OPS,
@@ -131,6 +143,7 @@ static const struct fb_ops intelfb_ops = {
.fb_imageblit = drm_fb_helper_cfb_imageblit,
.fb_pan_display = intel_fbdev_pan_display,
.fb_blank = intel_fbdev_blank,
+ .fb_mmap = intel_fbdev_mmap,
};
static int intelfb_alloc(struct drm_fb_helper *helper,
--
2.39.0
[Intel-gfx] [RFC PATCH 1/2] drm/i915: Add a function to mmap framebuffer obj
Implement i915_gem_fb_mmap() to enable fb_ops.fb_mmap()
callback for i915's framebuffer objects.
v2: add a comment why i915_gem_object_get() needed(Andi).
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 127 +++
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 +-
2 files changed, 83 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index d3c1dee16af2..341e952d3510 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -927,53 +927,15 @@ static struct file *mmap_singleton(struct
drm_i915_private *i915)
return file;
}
-/*
- * This overcomes the limitation in drm_gem_mmap's assignment of a
- * drm_gem_object as the vma->vm_private_data. Since we need to
- * be able to resolve multiple mmap offsets which could be tied
- * to a single gem object.
- */
-int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+static int
+i915_gem_object_mmap(struct drm_i915_gem_object *obj,
+struct i915_mmap_offset *mmo,
+struct vm_area_struct *vma)
{
- struct drm_vma_offset_node *node;
- struct drm_file *priv = filp->private_data;
- struct drm_device *dev = priv->minor->dev;
- struct drm_i915_gem_object *obj = NULL;
- struct i915_mmap_offset *mmo = NULL;
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct drm_device *dev = >drm;
struct file *anon;
- if (drm_dev_is_unplugged(dev))
- return -ENODEV;
-
- rcu_read_lock();
- drm_vma_offset_lock_lookup(dev->vma_offset_manager);
- node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
- vma->vm_pgoff,
- vma_pages(vma));
- if (node && drm_vma_node_is_allowed(node, priv)) {
- /*
-* Skip 0-refcnted objects as it is in the process of being
-* destroyed and will be invalid when the vma manager lock
-* is released.
-*/
- if (!node->driver_private) {
- mmo = container_of(node, struct i915_mmap_offset,
vma_node);
- obj = i915_gem_object_get_rcu(mmo->obj);
-
- GEM_BUG_ON(obj && obj->ops->mmap_ops);
- } else {
- obj = i915_gem_object_get_rcu
- (container_of(node, struct drm_i915_gem_object,
- base.vma_node));
-
- GEM_BUG_ON(obj && !obj->ops->mmap_ops);
- }
- }
- drm_vma_offset_unlock_lookup(dev->vma_offset_manager);
- rcu_read_unlock();
- if (!obj)
- return node ? -EACCES : -EINVAL;
-
if (i915_gem_object_is_readonly(obj)) {
if (vma->vm_flags & VM_WRITE) {
i915_gem_object_put(obj);
@@ -1005,7 +967,7 @@ int i915_gem_mmap(struct file *filp, struct vm_area_struct
*vma)
if (obj->ops->mmap_ops) {
vma->vm_page_prot =
pgprot_decrypted(vm_get_page_prot(vma->vm_flags));
vma->vm_ops = obj->ops->mmap_ops;
- vma->vm_private_data = node->driver_private;
+ vma->vm_private_data = obj->base.vma_node.driver_private;
return 0;
}
@@ -1043,6 +1005,81 @@ int i915_gem_mmap(struct file *filp, struct
vm_area_struct *vma)
return 0;
}
+/*
+ * This overcomes the limitation in drm_gem_mmap's assignment of a
+ * drm_gem_object as the vma->vm_private_data. Since we need to
+ * be able to resolve multiple mmap offsets which could be tied
+ * to a single gem object.
+ */
+int i915_gem_mmap(struct file *filp, struct vm_area_struct *vma)
+{
+ struct drm_vma_offset_node *node;
+ struct drm_file *priv = filp->private_data;
+ struct drm_device *dev = priv->minor->dev;
+ struct drm_i915_gem_object *obj = NULL;
+ struct i915_mmap_offset *mmo = NULL;
+
+ if (drm_dev_is_unplugged(dev))
+ return -ENODEV;
+
+ rcu_read_lock();
+ drm_vma_offset_lock_lookup(dev->vma_offset_manager);
+ node = drm_vma_offset_exact_lookup_locked(dev->vma_offset_manager,
+ vma->vm_pgoff,
+ vma_pages(vma));
+ if (node && drm_vma_node_is_allowed(node, priv)) {
+ /*
+* Skip 0-refcnted objects as it is in the process of being
+* destroyed and will be invalid when the vma manager lock
+* is released.
+*/
+ if (!node->driver_private) {
+ mmo = container_of(node,
Re: [Intel-gfx] [PATCH] drm/i915/huc: Cancel HuC delayed load timer on reset.
Reviewed-by: Alan Previn
P.S. side note - while reviewing this, i wish we got rid of those
"ops_on/off->intel_uc_funcname" macro obsfucations since i couldnt find
intel_uc_sanitize but did find the direct
call - so inconsistent.
On Mon, 2023-03-13 at 13:55 -0700, Ceraolo Spurio, Daniele wrote:
> In the rare case where we do a full GT reset after starting the HuC
> load and before it completes (which basically boils down to i915 hanging
> during init), we need to cancel the delayed load fence, as it will be
> re-initialized in the post-reset recovery.
>
> Fixes: 27536e03271d ("drm/i915/huc: track delayed HuC load with a fence")
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Alan Previn
> ---
> drivers/gpu/drm/i915/gt/uc/intel_huc.c | 7 +++
> drivers/gpu/drm/i915/gt/uc/intel_huc.h | 7 +--
> 2 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> index 72884e21470b..aefdaa62da99 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.c
> @@ -241,6 +241,13 @@ static void delayed_huc_load_fini(struct intel_huc *huc)
> i915_sw_fence_fini(>delayed_load.fence);
> }
>
> +int intel_huc_sanitize(struct intel_huc *huc)
> +{
> + delayed_huc_load_complete(huc);
> + intel_uc_fw_sanitize(>fw);
> + return 0;
> +}
> +
> static bool vcs_supported(struct intel_gt *gt)
> {
> intel_engine_mask_t mask = gt->info.engine_mask;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
> index 52db03620c60..db555b3c1f56 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_huc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_huc.h
> @@ -41,6 +41,7 @@ struct intel_huc {
> } delayed_load;
> };
>
> +int intel_huc_sanitize(struct intel_huc *huc);
> void intel_huc_init_early(struct intel_huc *huc);
> int intel_huc_init(struct intel_huc *huc);
> void intel_huc_fini(struct intel_huc *huc);
> @@ -54,12 +55,6 @@ bool intel_huc_is_authenticated(struct intel_huc *huc);
> void intel_huc_register_gsc_notifier(struct intel_huc *huc, struct bus_type
> *bus);
> void intel_huc_unregister_gsc_notifier(struct intel_huc *huc, struct
> bus_type *bus);
>
> -static inline int intel_huc_sanitize(struct intel_huc *huc)
> -{
> - intel_uc_fw_sanitize(>fw);
> - return 0;
> -}
> -
> static inline bool intel_huc_is_supported(struct intel_huc *huc)
> {
> return intel_uc_fw_is_supported(>fw);
[Intel-gfx] [PATCH] drm/i915/gem: Flush lmem contents after construction
From: Chris Wilson
i915_gem_object_create_lmem_from_data() lacks the flush of the data
written to lmem to ensure the object is marked as dirty and the writes
flushed to the backing store. Once created, we can immediately release
the obj->mm.mapping caching of the vmap.
Fixes: 7acbbc7cf485 ("drm/i915/guc: put all guc objects in lmem when available")
Cc: Matthew Auld
Cc: Daniele Ceraolo Spurio
Cc: Andi Shyti
Cc: Matthew Brost
Cc: John Harrison
Signed-off-by: Chris Wilson
Cc: # v5.16+
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
index 8949fb0a944f..3198b64ad7db 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_lmem.c
@@ -127,7 +127,8 @@ i915_gem_object_create_lmem_from_data(struct
drm_i915_private *i915,
memcpy(map, data, size);
- i915_gem_object_unpin_map(obj);
+ i915_gem_object_flush_map(obj);
+ __i915_gem_object_release_map(obj);
return obj;
}
--
2.39.0
Re: [Intel-gfx] [PATCH 0/7] drm/i915/regs: split display regs by function
On 3/16/2023 2:29 PM, Jani Nikula wrote: Shave off 1.2k lines from i915_reg.h. Jani Nikula (7): drm/i915/pps: split out PPS regs to a separate file drm/i915/tv: split out TV regs to a separate file drm/i915/aux: split out DP AUX regs to a separate file drm/i915/fdi: split out FDI regs to a separate file drm/i915/wm: split out SKL+ watermark regs to a separate file drm/i915/psr: split out PSR regs to a separate file drm/i915/dsb: split out DSB regs to a separate file Some of the files are new to me but haven't seen any functional changes so I am confident say the series is Reviewed-by: Nirmoy Das Thanks, Nirmoy drivers/gpu/drm/i915/display/intel_crt.c |1 + .../drm/i915/display/intel_display_debugfs.c |1 + .../drm/i915/display/intel_display_power.c|2 + .../i915/display/intel_display_power_well.c |1 + drivers/gpu/drm/i915/display/intel_dp_aux.c |1 + .../gpu/drm/i915/display/intel_dp_aux_regs.h | 84 ++ drivers/gpu/drm/i915/display/intel_dsb.c |1 + drivers/gpu/drm/i915/display/intel_dsb_regs.h | 67 + drivers/gpu/drm/i915/display/intel_dsi_vbt.c |1 + drivers/gpu/drm/i915/display/intel_fdi.c |1 + drivers/gpu/drm/i915/display/intel_fdi_regs.h | 151 ++ drivers/gpu/drm/i915/display/intel_lvds.c |1 + .../gpu/drm/i915/display/intel_pch_display.c |1 + drivers/gpu/drm/i915/display/intel_pps.c |1 + drivers/gpu/drm/i915/display/intel_pps_regs.h | 78 ++ drivers/gpu/drm/i915/display/intel_psr.c |1 + drivers/gpu/drm/i915/display/intel_psr_regs.h | 260 drivers/gpu/drm/i915/display/intel_tv.c |3 +- drivers/gpu/drm/i915/display/intel_tv_regs.h | 490 +++ drivers/gpu/drm/i915/display/skl_watermark.c |1 + .../gpu/drm/i915/display/skl_watermark_regs.h | 165 +++ drivers/gpu/drm/i915/gvt/edid.c |1 + drivers/gpu/drm/i915/gvt/handlers.c |5 + drivers/gpu/drm/i915/i915_irq.c |2 + drivers/gpu/drm/i915/i915_reg.h | 1219 - drivers/gpu/drm/i915/intel_gvt_mmio_table.c |4 + 26 files changed, 1323 insertions(+), 1220 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dp_aux_regs.h create mode 100644 drivers/gpu/drm/i915/display/intel_dsb_regs.h create mode 100644 drivers/gpu/drm/i915/display/intel_fdi_regs.h create mode 100644 drivers/gpu/drm/i915/display/intel_pps_regs.h create mode 100644 drivers/gpu/drm/i915/display/intel_psr_regs.h create mode 100644 drivers/gpu/drm/i915/display/intel_tv_regs.h create mode 100644 drivers/gpu/drm/i915/display/skl_watermark_regs.h
Re: [Intel-gfx] [Freedreno] [RFC PATCH 1/2] drm/msm/dpu: add dsc helper functions
On 3/16/2023 9:23 AM, Dmitry Baryshkov wrote:
On 16/03/2023 18:13, Abhinav Kumar wrote:
On 3/16/2023 9:03 AM, Dmitry Baryshkov wrote:
Hi,
[removed previous conversation]
Hi Dmitry and Abhinav,
Just wanted to follow up on this thread. I've gone over the
MSM-specific
DSC params for DP and DSI and have found a few shared calculations and
variables between both DSI and DP paths:
- (as mentioned earlier in the thread) almost all the calculations in
dpu_dsc_populate_dsc_config() match dsi_populate_dsc_params() [1]. The
only difference in the math I'm seeing is initial_scale_value.
The value in dsi code is valid for initial_offset = 6144. Please use
the formula from the standard (= sde_dsc_populate_dsc_config) and add
it to drm_dsc_helper.c
If I remember correctly the last remaining item in
dsi_populate_dsc_params() (except mentioned initial_offset) was
line_buf_depth, see [3]. I'm not sure about setting it to bpc+1.
According to the standard it should come from a DSC decoder spec,
which means it should be set by the DSI panel driver or via
drm_dp_dsc_sink_line_buf_depth() in the case of DP output.
- dsc_extra_pclk_cycle_cnt and dce_bytes_per_line, which were
introduced
in Kuogee's v1 DSC series [2], are used for DSI, DP, and the DPU timing
engine. dsc_extra_pclk_cycle_cnt is calculated based on pclk_per_line
(which is calculated differently between DP and DSI), but
dce_bytes_per_line is calculated the same way between DP and DSI.
To avoid having to duplicate math in 2 different places, I think it
would help to have these calculations in some msm_dsc_helper.c file.
Any
thoughts on this?
dsc_extra_pclk_cycle_cnt and dce_bytes_per_line are used only in DPU
code, so they can stay in DPU driver.
They can stay in the dpu driver is fine but where?
Like Jessica wrote, this is computed and used in 3 places today :
1) DSI video engine computation
2) DP controller computation
3) timing engine programming
Please excuse me if I'm wrong. I checked both vendor techpack and the
Kuogee's patches. I see them being used only in the SDE / DPU driver
code. Could you please point me to the code path that we are discussing?
DSI code :
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/dsi/dsi_host.c#L868
DP code:
Refer to dp_panel_dsc_pclk_param_calc in
https://patchwork.freedesktop.org/patch/519837/?series=113240=1
Timing engine:
refer to https://patchwork.freedesktop.org/patch/519838/?series=113240=1
Probably confusion is due to the naming. bytes_per_line is nothing but
bytes_per_pkt * pkt_per_line but the concept is common for DP and DSI.
+ if (phys->comp_type == MSM_DISPLAY_COMPRESSION_DSC) {
+ phys->dsc_extra_pclk_cycle_cnt =
dsc_info->pclk_per_line;
+ phys->dsc_extra_disp_width = dsc_info->extra_width;
+ phys->dce_bytes_per_line =
+ dsc_info->bytes_per_pkt *
dsc_info->pkt_per_line;
So either we have a helper in a common location somewhere so that
these 3 modules can call that helper and use it OR each module
duplicates the computation code.
What should be the common location is the discussion here.
It cannot be dpu_encoder.c as the DSI/DP dont call into the encoder
methods.
Thanks,
Jessica Zhang
[1]
https://elixir.bootlin.com/linux/v6.3-rc2/source/drivers/gpu/drm/msm/dsi/dsi_host.c#L1756
[2] https://patchwork.freedesktop.org/patch/519845/?series=113240=1
[3] https://patchwork.freedesktop.org/patch/525441/?series=114472=2
Re: [Intel-gfx] [PATCH v10 01/15] dma-buf/dma-fence: Add deadline awareness
On Thu, Mar 16, 2023 at 2:26 AM Jonas Ådahl wrote: > > On Wed, Mar 15, 2023 at 09:19:49AM -0700, Rob Clark wrote: > > On Wed, Mar 15, 2023 at 6:53 AM Jonas Ådahl wrote: > > > > > > On Fri, Mar 10, 2023 at 09:38:18AM -0800, Rob Clark wrote: > > > > On Fri, Mar 10, 2023 at 7:45 AM Jonas Ådahl wrote: > > > > > > > > > > On Wed, Mar 08, 2023 at 07:52:52AM -0800, Rob Clark wrote: > > > > > > From: Rob Clark > > > > > > > > > > > > Add a way to hint to the fence signaler of an upcoming deadline, > > > > > > such as > > > > > > vblank, which the fence waiter would prefer not to miss. This is > > > > > > to aid > > > > > > the fence signaler in making power management decisions, like > > > > > > boosting > > > > > > frequency as the deadline approaches and awareness of missing > > > > > > deadlines > > > > > > so that can be factored in to the frequency scaling. > > > > > > > > > > > > v2: Drop dma_fence::deadline and related logic to filter duplicate > > > > > > deadlines, to avoid increasing dma_fence size. The > > > > > > fence-context > > > > > > implementation will need similar logic to track deadlines of all > > > > > > the fences on the same timeline. [ckoenig] > > > > > > v3: Clarify locking wrt. set_deadline callback > > > > > > v4: Clarify in docs comment that this is a hint > > > > > > v5: Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. > > > > > > v6: More docs > > > > > > v7: Fix typo, clarify past deadlines > > > > > > > > > > > > Signed-off-by: Rob Clark > > > > > > Reviewed-by: Christian König > > > > > > Acked-by: Pekka Paalanen > > > > > > Reviewed-by: Bagas Sanjaya > > > > > > --- > > > > > > > > > > Hi Rob! > > > > > > > > > > > Documentation/driver-api/dma-buf.rst | 6 +++ > > > > > > drivers/dma-buf/dma-fence.c | 59 > > > > > > > > > > > > include/linux/dma-fence.h| 22 +++ > > > > > > 3 files changed, 87 insertions(+) > > > > > > > > > > > > diff --git a/Documentation/driver-api/dma-buf.rst > > > > > > b/Documentation/driver-api/dma-buf.rst > > > > > > index 622b8156d212..183e480d8cea 100644 > > > > > > --- a/Documentation/driver-api/dma-buf.rst > > > > > > +++ b/Documentation/driver-api/dma-buf.rst > > > > > > @@ -164,6 +164,12 @@ DMA Fence Signalling Annotations > > > > > > .. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > :doc: fence signalling annotation > > > > > > > > > > > > +DMA Fence Deadline Hints > > > > > > + > > > > > > + > > > > > > +.. kernel-doc:: drivers/dma-buf/dma-fence.c > > > > > > + :doc: deadline hints > > > > > > + > > > > > > DMA Fences Functions Reference > > > > > > ~~ > > > > > > > > > > > > diff --git a/drivers/dma-buf/dma-fence.c > > > > > > b/drivers/dma-buf/dma-fence.c > > > > > > index 0de0482cd36e..f177c56269bb 100644 > > > > > > --- a/drivers/dma-buf/dma-fence.c > > > > > > +++ b/drivers/dma-buf/dma-fence.c > > > > > > @@ -912,6 +912,65 @@ dma_fence_wait_any_timeout(struct dma_fence > > > > > > **fences, uint32_t count, > > > > > > } > > > > > > EXPORT_SYMBOL(dma_fence_wait_any_timeout); > > > > > > > > > > > > +/** > > > > > > + * DOC: deadline hints > > > > > > + * > > > > > > + * In an ideal world, it would be possible to pipeline a workload > > > > > > sufficiently > > > > > > + * that a utilization based device frequency governor could arrive > > > > > > at a minimum > > > > > > + * frequency that meets the requirements of the use-case, in order > > > > > > to minimize > > > > > > + * power consumption. But in the real world there are many > > > > > > workloads which > > > > > > + * defy this ideal. For example, but not limited to: > > > > > > + * > > > > > > + * * Workloads that ping-pong between device and CPU, with > > > > > > alternating periods > > > > > > + * of CPU waiting for device, and device waiting on CPU. This > > > > > > can result in > > > > > > + * devfreq and cpufreq seeing idle time in their respective > > > > > > domains and in > > > > > > + * result reduce frequency. > > > > > > + * > > > > > > + * * Workloads that interact with a periodic time based deadline, > > > > > > such as double > > > > > > + * buffered GPU rendering vs vblank sync'd page flipping. In > > > > > > this scenario, > > > > > > + * missing a vblank deadline results in an *increase* in idle > > > > > > time on the GPU > > > > > > + * (since it has to wait an additional vblank period), sending a > > > > > > signal to > > > > > > + * the GPU's devfreq to reduce frequency, when in fact the > > > > > > opposite is what is > > > > > > + * needed. > > > > > > > > > > This is the use case I'd like to get some better understanding about > > > > > how > > > > > this series intends to work, as the problematic scheduling behavior > > > > > triggered by missed deadlines has plagued compositing display servers > > > > > for a long time. > > > > > > > > > > I apologize, I'm not a GPU driver
Re: [Intel-gfx] [Freedreno] [RFC PATCH 1/2] drm/msm/dpu: add dsc helper functions
On 16/03/2023 18:13, Abhinav Kumar wrote: On 3/16/2023 9:03 AM, Dmitry Baryshkov wrote: Hi, [removed previous conversation] Hi Dmitry and Abhinav, Just wanted to follow up on this thread. I've gone over the MSM-specific DSC params for DP and DSI and have found a few shared calculations and variables between both DSI and DP paths: - (as mentioned earlier in the thread) almost all the calculations in dpu_dsc_populate_dsc_config() match dsi_populate_dsc_params() [1]. The only difference in the math I'm seeing is initial_scale_value. The value in dsi code is valid for initial_offset = 6144. Please use the formula from the standard (= sde_dsc_populate_dsc_config) and add it to drm_dsc_helper.c If I remember correctly the last remaining item in dsi_populate_dsc_params() (except mentioned initial_offset) was line_buf_depth, see [3]. I'm not sure about setting it to bpc+1. According to the standard it should come from a DSC decoder spec, which means it should be set by the DSI panel driver or via drm_dp_dsc_sink_line_buf_depth() in the case of DP output. - dsc_extra_pclk_cycle_cnt and dce_bytes_per_line, which were introduced in Kuogee's v1 DSC series [2], are used for DSI, DP, and the DPU timing engine. dsc_extra_pclk_cycle_cnt is calculated based on pclk_per_line (which is calculated differently between DP and DSI), but dce_bytes_per_line is calculated the same way between DP and DSI. To avoid having to duplicate math in 2 different places, I think it would help to have these calculations in some msm_dsc_helper.c file. Any thoughts on this? dsc_extra_pclk_cycle_cnt and dce_bytes_per_line are used only in DPU code, so they can stay in DPU driver. They can stay in the dpu driver is fine but where? Like Jessica wrote, this is computed and used in 3 places today : 1) DSI video engine computation 2) DP controller computation 3) timing engine programming Please excuse me if I'm wrong. I checked both vendor techpack and the Kuogee's patches. I see them being used only in the SDE / DPU driver code. Could you please point me to the code path that we are discussing? So either we have a helper in a common location somewhere so that these 3 modules can call that helper and use it OR each module duplicates the computation code. What should be the common location is the discussion here. It cannot be dpu_encoder.c as the DSI/DP dont call into the encoder methods. Thanks, Jessica Zhang [1] https://elixir.bootlin.com/linux/v6.3-rc2/source/drivers/gpu/drm/msm/dsi/dsi_host.c#L1756 [2] https://patchwork.freedesktop.org/patch/519845/?series=113240=1 [3] https://patchwork.freedesktop.org/patch/525441/?series=114472=2 -- With best wishes Dmitry
Re: [Intel-gfx] [Freedreno] [RFC PATCH 1/2] drm/msm/dpu: add dsc helper functions
On 3/16/2023 9:03 AM, Dmitry Baryshkov wrote: Hi, [removed previous conversation] Hi Dmitry and Abhinav, Just wanted to follow up on this thread. I've gone over the MSM-specific DSC params for DP and DSI and have found a few shared calculations and variables between both DSI and DP paths: - (as mentioned earlier in the thread) almost all the calculations in dpu_dsc_populate_dsc_config() match dsi_populate_dsc_params() [1]. The only difference in the math I'm seeing is initial_scale_value. The value in dsi code is valid for initial_offset = 6144. Please use the formula from the standard (= sde_dsc_populate_dsc_config) and add it to drm_dsc_helper.c If I remember correctly the last remaining item in dsi_populate_dsc_params() (except mentioned initial_offset) was line_buf_depth, see [3]. I'm not sure about setting it to bpc+1. According to the standard it should come from a DSC decoder spec, which means it should be set by the DSI panel driver or via drm_dp_dsc_sink_line_buf_depth() in the case of DP output. - dsc_extra_pclk_cycle_cnt and dce_bytes_per_line, which were introduced in Kuogee's v1 DSC series [2], are used for DSI, DP, and the DPU timing engine. dsc_extra_pclk_cycle_cnt is calculated based on pclk_per_line (which is calculated differently between DP and DSI), but dce_bytes_per_line is calculated the same way between DP and DSI. To avoid having to duplicate math in 2 different places, I think it would help to have these calculations in some msm_dsc_helper.c file. Any thoughts on this? dsc_extra_pclk_cycle_cnt and dce_bytes_per_line are used only in DPU code, so they can stay in DPU driver. They can stay in the dpu driver is fine but where? Like Jessica wrote, this is computed and used in 3 places today : 1) DSI video engine computation 2) DP controller computation 3) timing engine programming So either we have a helper in a common location somewhere so that these 3 modules can call that helper and use it OR each module duplicates the computation code. What should be the common location is the discussion here. It cannot be dpu_encoder.c as the DSI/DP dont call into the encoder methods. Thanks, Jessica Zhang [1] https://elixir.bootlin.com/linux/v6.3-rc2/source/drivers/gpu/drm/msm/dsi/dsi_host.c#L1756 [2] https://patchwork.freedesktop.org/patch/519845/?series=113240=1 [3] https://patchwork.freedesktop.org/patch/525441/?series=114472=2
Re: [Intel-gfx] [PATCH v5 02/12] drm/i915/mtl: Synchronize i915/BIOS on C6 enabling
On Wed, Mar 15, 2023 at 05:09:22PM -0700, Umesh Nerlige Ramappa wrote:
From: Vinay Belgaumkar
If BIOS enables/disables C6, i915 should do the same. Also, retain
this value across driver reloads. This is needed only for MTL as
of now due to an existing bug in OA which needs C6 disabled for
it to function. BIOS behavior is also different across platforms
in terms of how C6 is enabled.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 28 +++
drivers/gpu/drm/i915/gt/intel_rc6.h | 2 ++
drivers/gpu/drm/i915/gt/intel_rc6_types.h | 2 ++
3 files changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index 5c91622dfca4..f760586f9f46 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -420,6 +420,21 @@ static void vlv_rc6_enable(struct intel_rc6 *rc6)
GEN7_RC_CTL_TO_MODE | VLV_RC_CTL_CTX_RST_PARALLEL;
}
+bool intel_check_bios_c6_setup(struct intel_rc6 *rc6)
+{
+ if (!rc6->bios_state_captured) {
+ struct intel_uncore *uncore = rc6_to_uncore(rc6);
+ intel_wakeref_t wakeref;
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ rc6->bios_rc_state = intel_uncore_read(uncore,
GEN6_RC_STATE);
+
+ rc6->bios_state_captured = true;
+ }
+
+ return rc6->bios_rc_state & RC_SW_TARGET_STATE_MASK;
+}
+
static bool bxt_check_bios_rc6_setup(struct intel_rc6 *rc6)
{
struct intel_uncore *uncore = rc6_to_uncore(rc6);
@@ -486,6 +501,7 @@ static bool bxt_check_bios_rc6_setup(struct intel_rc6 *rc6)
static bool rc6_supported(struct intel_rc6 *rc6)
{
struct drm_i915_private *i915 = rc6_to_i915(rc6);
+ struct intel_gt *gt = rc6_to_gt(rc6);
if (!HAS_RC6(i915))
return false;
@@ -502,6 +518,13 @@ static bool rc6_supported(struct intel_rc6 *rc6)
return false;
}
+ if (IS_METEORLAKE(gt->i915) &&
+ !intel_check_bios_c6_setup(rc6)) {
+ drm_notice(>drm,
+ "C6 disabled by BIOS\n");
+ return false;
+ }
+
return true;
}
@@ -699,9 +722,14 @@ void intel_rc6_disable(struct intel_rc6 *rc6)
void intel_rc6_fini(struct intel_rc6 *rc6)
{
struct drm_i915_gem_object *pctx;
+ struct intel_uncore *uncore = rc6_to_uncore(rc6);
intel_rc6_disable(rc6);
+ /* We want the BIOS C6 state preserved across loads for MTL */
+ if (IS_METEORLAKE(rc6_to_i915(rc6)) && rc6->bios_state_captured)
+ set(uncore, GEN6_RC_STATE, rc6->bios_rc_state);
+
Assuming bios_state_captured will be false on driver load because gt is
zalloc-ed. With that, this lgtm
Reviewed-by: Umesh Nerlige Ramappa
Regards,
Umesh
pctx = fetch_and_zero(>pctx);
if (pctx)
i915_gem_object_put(pctx);
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.h
b/drivers/gpu/drm/i915/gt/intel_rc6.h
index 456fa668a276..e137c2c397c2 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.h
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.h
@@ -27,4 +27,6 @@ u64 intel_rc6_residency_us(struct intel_rc6 *rc6, enum
intel_rc6_res_type id);
void intel_rc6_print_residency(struct seq_file *m, const char *title,
enum intel_rc6_res_type id);
+bool intel_check_bios_c6_setup(struct intel_rc6 *rc6);
+
#endif /* INTEL_RC6_H */
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6_types.h
b/drivers/gpu/drm/i915/gt/intel_rc6_types.h
index fa23c4dce00b..cd4587098162 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_rc6_types.h
@@ -29,6 +29,7 @@ struct intel_rc6 {
u64 cur_residency[INTEL_RC6_RES_MAX];
u32 ctl_enable;
+ u32 bios_rc_state;
struct drm_i915_gem_object *pctx;
@@ -36,6 +37,7 @@ struct intel_rc6 {
bool enabled : 1;
bool manual : 1;
bool wakeref : 1;
+ bool bios_state_captured : 1;
};
#endif /* INTEL_RC6_TYPES_H */
--
2.36.1
Re: [Intel-gfx] [Freedreno] [RFC PATCH 1/2] drm/msm/dpu: add dsc helper functions
Hi, [removed previous conversation] > > Hi Dmitry and Abhinav, > > Just wanted to follow up on this thread. I've gone over the MSM-specific > DSC params for DP and DSI and have found a few shared calculations and > variables between both DSI and DP paths: > > - (as mentioned earlier in the thread) almost all the calculations in > dpu_dsc_populate_dsc_config() match dsi_populate_dsc_params() [1]. The > only difference in the math I'm seeing is initial_scale_value. The value in dsi code is valid for initial_offset = 6144. Please use the formula from the standard (= sde_dsc_populate_dsc_config) and add it to drm_dsc_helper.c If I remember correctly the last remaining item in dsi_populate_dsc_params() (except mentioned initial_offset) was line_buf_depth, see [3]. I'm not sure about setting it to bpc+1. According to the standard it should come from a DSC decoder spec, which means it should be set by the DSI panel driver or via drm_dp_dsc_sink_line_buf_depth() in the case of DP output. > - dsc_extra_pclk_cycle_cnt and dce_bytes_per_line, which were introduced > in Kuogee's v1 DSC series [2], are used for DSI, DP, and the DPU timing > engine. dsc_extra_pclk_cycle_cnt is calculated based on pclk_per_line > (which is calculated differently between DP and DSI), but > dce_bytes_per_line is calculated the same way between DP and DSI. > > To avoid having to duplicate math in 2 different places, I think it > would help to have these calculations in some msm_dsc_helper.c file. Any > thoughts on this? dsc_extra_pclk_cycle_cnt and dce_bytes_per_line are used only in DPU code, so they can stay in DPU driver. > > Thanks, > > Jessica Zhang > > [1] > https://elixir.bootlin.com/linux/v6.3-rc2/source/drivers/gpu/drm/msm/dsi/dsi_host.c#L1756 > > [2] https://patchwork.freedesktop.org/patch/519845/?series=113240=1 [3] https://patchwork.freedesktop.org/patch/525441/?series=114472=2 -- With best wishes Dmitry
Re: [Intel-gfx] [PATCH] drm/i915: Simplify vcs/bsc engine selection
On 3/16/2023 3:27 PM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
No need to look at the mask of present engines when we already have a
count stored ever since e2d0ff3525b9 ("drm/i915: Count engine instances
per uabi class").
Signed-off-by: Tvrtko Ursulin
Cc: Jonathan Cavitt
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9dce2957b4e5..3aeede6aee4d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2449,11 +2449,6 @@ static int eb_submit(struct i915_execbuffer *eb)
return err;
}
-static int num_vcs_engines(struct drm_i915_private *i915)
-{
- return hweight_long(VDBOX_MASK(to_gt(i915)));
-}
-
/*
* Find one BSD ring to dispatch the corresponding BSD command.
* The engine index is returned.
@@ -2467,7 +2462,7 @@ gen8_dispatch_bsd_engine(struct drm_i915_private
*dev_priv,
/* Check whether the file_priv has already selected one ring. */
if ((int)file_priv->bsd_engine < 0)
file_priv->bsd_engine =
- get_random_u32_below(num_vcs_engines(dev_priv));
+
get_random_u32_below(dev_priv->engine_uabi_class_count[I915_ENGINE_CLASS_VIDEO]);
return file_priv->bsd_engine;
}
@@ -2655,7 +2650,8 @@ eb_select_legacy_ring(struct i915_execbuffer *eb)
return -1;
}
- if (user_ring_id == I915_EXEC_BSD && num_vcs_engines(i915) > 1) {
+ if (user_ring_id == I915_EXEC_BSD &&
+ i915->engine_uabi_class_count[I915_ENGINE_CLASS_VIDEO] > 1) {
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, Daniel,
Here's the new weekly pull request for v6.4-rc1.
I've omitted the diffstat, as it was huge because v6.3-rc1 was backmerged.
Cheers,
~Maarten
drm-misc-next-2023-03-16:
drm-misc-next for v6.4-rc1:
Cross-subsystem Changes:
- Add drm_bridge.h to drm_bridge maintainers.
Core Changes:
- Assorted fixes to TTM, tests, format-helper, accel.
- Assorted Makefile fixes to drivers and accel.
- Implement fbdev emulation for GEM DMA drivers, and convert a lot of
drivers to use it.
- Use tgid instead of pid for tracking clients.
Driver Changes:
- Assorted fixes in rockchip, vmwgfx, nouveau, cirrus.
- Add imx25 driver.
- Add Elida KD50T048A, Sony TD4353, Novatek NT36523, STARRY
2081101QFH032011-53G panels.
- Add 4K mode support to rockchip.
- Convert cirrus to use regular atomic helpers, and more cirrus
improvements.
- Add damage clipping to cirrus, virtio.
The following changes since commit 9228742caf899fa72230dd8da19ca4c7528badb8:
drm/nouveau/hwmon: Use sysfs_emit in show function callsbacks
(2023-03-06 19:42:50 -0500)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2023-03-16
for you to fetch changes up to b24343eaceedb902c1625854f85a193b0549d85f:
drm/nouveau/nvfw/acr: set wpr_generic_header_dump
storage-class-specifier to static (2023-03-16 14:53:15 +0100)
drm-misc-next for v6.4-rc1:
Cross-subsystem Changes:
- Add drm_bridge.h to drm_bridge maintainers.
Core Changes:
- Assorted fixes to TTM, tests, format-helper, accel.
- Assorted Makefile fixes to drivers and accel.
- Implement fbdev emulation for GEM DMA drivers, and convert a lot of
drivers to use it.
- Use tgid instead of pid for tracking clients.
Driver Changes:
- Assorted fixes in rockchip, vmwgfx, nouveau, cirrus.
- Add imx25 driver.
- Add Elida KD50T048A, Sony TD4353, Novatek NT36523, STARRY
2081101QFH032011-53G panels.
- Add 4K mode support to rockchip.
- Convert cirrus to use regular atomic helpers, and more cirrus
improvements.
- Add damage clipping to cirrus, virtio.
Fabio Estevam (2):
dt-bindings: display: seiko,43wvf1g: Add the 'enable-gpios' property
drm/panel: seiko-43wvf1g: Add the 'enable-gpios' property
Gerald Loacker (1):
drm/rockchip: vop2: add polarity flags to RGB output
Jacob Keller (1):
drm/rockchip: vop2: use struct_size() in vop2_bind
Javier Martinez Canillas (2):
drm/format-helper: Make conversion_buf_size() support sub-byte
pixel fmts
drm/virtio: Enable fb damage clips property for the primary plane
Jianhua Lu (2):
dt-bindings: display: panel: Add Novatek NT36523 bindings
drm/panel: Add driver for Novatek NT36523
Jiapeng Chong (1):
drm/rockchip: dsi: Remove the unused function dsi_read()
Konrad Dybcio (2):
dt-bindings: display/panel: Add Sony Tama TD4353 JDI display panel
gpu/drm/panel: Add Sony TD4353 JDI panel driver
Linus Walleij (1):
drm/mcde: Do not use dirty GEM FB handling
Liu Ying (1):
MAINTAINERS: Add include/drm/drm_bridge.h to DRM DRIVERS FOR
BRIDGE CHIPS
Marian Cichy (1):
drm/imx/lcdc: Implement DRM driver for imx25
Maya Matuszczyk (3):
dt-bindings: display: panel: sitronix,st7701: Add Elida KD50T048A
Panel
drm: panel: Add Elida KD50T048A to Sitronix ST7701 driver
drm: panel: Add orientation support for st7701
Ruihai Zhou (2):
dt-bindings: display: panel: Add compatible for Starry
2081101QFH032011-53G
drm/panel: support for STARRY 2081101QFH032011-53G MIPI-DSI panel
Sascha Hauer (4):
drm/rockchip: vop: limit maximum resolution to hardware capabilities
drm/rockchip: dw_hdmi: relax mode_valid hook
drm/rockchip: dw_hdmi: Add support for 4k@30 resolution
drm/rockchip: dw_hdmi: discard modes with unachievable pixelclocks
Stanislaw Gruszka (1):
accel: Build sub-directories based on config options
Thomas Hellström (3):
drm/ttm: Use the BIT macro for the TTM_TT_FLAGs
drm/ttm: Unexport ttm_global_swapout()
drm/ttm: Don't print error message if eviction was interrupted
Thomas Zimmermann (42):
Merge drm/drm-next into drm-misc-next
drm/cirrus: Compute blit destination offset in single location
drm/cirrus: Replace cpp value with format
drm/cirrus: Use drm_fb_blit() to update scanout buffer
drm/cirrus: Move drm_dev_{enter, exit}() into DRM helpers
drm/cirrus: Split cirrus_mode_set() into smaller functions
drm/cirrus: Integrate connector into pipeline code
drm/cirrus: Move primary-plane format arrays
drm/cirrus: Convert to regular atomic helpers
drm/cirrus: Enable damage clipping on primary plane
drm/cirrus: Inline cirrus_fb_blit_rect()
drm/cirrus: Remove format test from cirrus_fb_create()
drm/cirrus: Remove size test from cirrus_fb_create()
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for Provision to ignore long HPDs in CI systems (rev5)
On Wed, Feb 15, 2023 at 10:57:54PM +, Patchwork wrote:
> == Series Details ==
>
> Series: Provision to ignore long HPDs in CI systems (rev5)
> URL : https://patchwork.freedesktop.org/series/109475/
> State : success
Thanks for the patchset, pushed it to din.
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12741_full -> Patchwork_109475v5_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
>
> External URL:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/index.html
>
> Participating hosts (10 -> 10)
> --
>
> No changes in participating hosts
>
> Known issues
>
>
> Here are the changes found in Patchwork_109475v5_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_exec_fair@basic-throttle@rcs0:
> - shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842]) +1 similar
> issue
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-glk1/igt@gem_exec_fair@basic-throt...@rcs0.html
>
> * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt:
> - shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271]) +4 similar issues
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-glk1/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt.html
>
> * igt@kms_psr2_sf@plane-move-sf-dmg-area:
> - shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#658])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-glk6/igt@kms_psr2...@plane-move-sf-dmg-area.html
>
>
> Possible fixes
>
> * igt@drm_fdinfo@most-busy-check-all@rcs0:
> - {shard-rkl}:[FAIL][5] ([i915#7742]) -> [PASS][6]
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-rkl-1/igt@drm_fdinfo@most-busy-check-...@rcs0.html
>
> * igt@fbdev@pan:
> - {shard-rkl}:[SKIP][7] ([i915#2582]) -> [PASS][8]
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/shard-rkl-2/igt@fb...@pan.html
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-rkl-6/igt@fb...@pan.html
>
> * igt@feature_discovery@psr2:
> - {shard-rkl}:[SKIP][9] ([i915#658]) -> [PASS][10]
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/shard-rkl-2/igt@feature_discov...@psr2.html
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-rkl-6/igt@feature_discov...@psr2.html
>
> * igt@gem_ctx_exec@basic-nohangcheck:
> - {shard-tglu}: [FAIL][11] ([i915#6268]) -> [PASS][12]
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/shard-tglu-1/igt@gem_ctx_e...@basic-nohangcheck.html
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-tglu-6/igt@gem_ctx_e...@basic-nohangcheck.html
>
> * igt@gem_exec_fair@basic-none-solo@rcs0:
> - {shard-rkl}:[FAIL][13] ([i915#2842]) -> [PASS][14]
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/shard-rkl-5/igt@gem_exec_fair@basic-none-s...@rcs0.html
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-rkl-5/igt@gem_exec_fair@basic-none-s...@rcs0.html
>
> * igt@gem_exec_fair@basic-pace-solo@rcs0:
> - shard-apl: [FAIL][15] ([i915#2842]) -> [PASS][16]
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
>
> * igt@gem_exec_reloc@basic-write-read-noreloc:
> - {shard-rkl}:[SKIP][17] ([i915#3281]) -> [PASS][18] +5 similar
> issues
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/shard-rkl-2/igt@gem_exec_re...@basic-write-read-noreloc.html
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-rkl-5/igt@gem_exec_re...@basic-write-read-noreloc.html
>
> * igt@gem_exec_suspend@basic-s3@smem:
> - {shard-rkl}:[ABORT][19] ([i915#5122]) -> [PASS][20]
>[19]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/shard-rkl-4/igt@gem_exec_suspend@basic...@smem.html
>[20]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109475v5/shard-rkl-2/igt@gem_exec_suspend@basic...@smem.html
>
> * igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
> - {shard-rkl}:[SKIP][21] ([i915#3282]) -> [PASS][22] +2 similar
> issues
>[21]:
>
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave and Daniel, here's the weekly PR for drm-misc-fixes. Best regards Thomas drm-misc-fixes-2023-03-16: Short summary of fixes pull: * fix info leak in edid * build fix for accel/ * ref-counting fix for fbdev deferred I/O * driver fixes The following changes since commit eeac8ede17557680855031c6f305ece2378af326: Linux 6.3-rc2 (2023-03-12 16:36:44 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2023-03-16 for you to fetch changes up to 4028cbf867f70a3c599c9b0c9509334c56ed97d7: drm/meson: dw-hdmi: Fix devm_regulator_*get_enable*() conversion again (2023-03-15 10:06:46 +0100) Short summary of fixes pull: * fix info leak in edid * build fix for accel/ * ref-counting fix for fbdev deferred I/O * driver fixes Christian Hewitt (1): drm/meson: fix 1px pink line on GXM when scaling video overlay Dan Carpenter (1): fbdev: chipsfb: Fix error codes in chipsfb_pci_init() Dmitry Osipenko (3): drm/shmem-helper: Remove another errant put in error path drm/msm/gem: Prevent blocking within shrinker loop drm/panfrost: Don't sync rpm suspension after mmu flushing Johan Hovold (2): drm/edid: fix info leak when failing to get panel id drm/sun4i: fix missing component unbind on bind errors Liu Ying (1): drm/bridge: Fix returned array size name for atomic_get_input_bus_fmts kdoc Marek Szyprowski (1): drm/meson: dw-hdmi: Fix devm_regulator_*get_enable*() conversion again Oleksandr Tyshchenko (1): drm/virtio: Pass correct device to dma_sync_sgtable_for_device() Stanislaw Gruszka (1): accel: Build sub-directories based on config options Takashi Iwai (1): fbdev: Fix incorrect page mapping clearance at fb_deferred_io_release() Thomas Hellström (1): drm/ttm: Fix a NULL pointer dereference Thomas Zimmermann (1): Merge drm/drm-fixes into drm-misc-fixes drivers/accel/Makefile | 4 ++-- drivers/gpu/drm/drm_edid.c | 2 +- drivers/gpu/drm/drm_gem.c | 9 +++-- drivers/gpu/drm/drm_gem_shmem_helper.c | 9 ++--- drivers/gpu/drm/meson/meson_dw_hdmi.c | 2 +- drivers/gpu/drm/meson/meson_vpp.c | 2 ++ drivers/gpu/drm/msm/msm_gem_shrinker.c | 11 +-- drivers/gpu/drm/panfrost/panfrost_mmu.c | 2 +- drivers/gpu/drm/sun4i/sun4i_drv.c | 6 -- drivers/gpu/drm/ttm/ttm_device.c| 2 +- drivers/gpu/drm/virtio/virtgpu_vq.c | 4 ++-- drivers/video/fbdev/chipsfb.c | 14 ++ drivers/video/fbdev/core/fb_defio.c | 17 + include/drm/drm_bridge.h| 4 ++-- include/drm/drm_gem.h | 4 +++- include/linux/fb.h | 1 + 16 files changed, 65 insertions(+), 28 deletions(-) -- Thomas Zimmermann Graphics Driver Developer SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg, Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
[Intel-gfx] [PATCH] drm/i915: Simplify vcs/bsc engine selection
From: Tvrtko Ursulin
No need to look at the mask of present engines when we already have a
count stored ever since e2d0ff3525b9 ("drm/i915: Count engine instances
per uabi class").
Signed-off-by: Tvrtko Ursulin
Cc: Jonathan Cavitt
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9dce2957b4e5..3aeede6aee4d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2449,11 +2449,6 @@ static int eb_submit(struct i915_execbuffer *eb)
return err;
}
-static int num_vcs_engines(struct drm_i915_private *i915)
-{
- return hweight_long(VDBOX_MASK(to_gt(i915)));
-}
-
/*
* Find one BSD ring to dispatch the corresponding BSD command.
* The engine index is returned.
@@ -2467,7 +2462,7 @@ gen8_dispatch_bsd_engine(struct drm_i915_private
*dev_priv,
/* Check whether the file_priv has already selected one ring. */
if ((int)file_priv->bsd_engine < 0)
file_priv->bsd_engine =
- get_random_u32_below(num_vcs_engines(dev_priv));
+
get_random_u32_below(dev_priv->engine_uabi_class_count[I915_ENGINE_CLASS_VIDEO]);
return file_priv->bsd_engine;
}
@@ -2655,7 +2650,8 @@ eb_select_legacy_ring(struct i915_execbuffer *eb)
return -1;
}
- if (user_ring_id == I915_EXEC_BSD && num_vcs_engines(i915) > 1) {
+ if (user_ring_id == I915_EXEC_BSD &&
+ i915->engine_uabi_class_count[I915_ENGINE_CLASS_VIDEO] > 1) {
unsigned int bsd_idx = args->flags & I915_EXEC_BSD_MASK;
if (bsd_idx == I915_EXEC_BSD_DEFAULT) {
--
2.37.2
Re: [Intel-gfx] [PATCH] drm/i915/opregion: Fix CONFIG_ACPI=n builds adding missing intel_opregion_cleanup() prototype
On Tue, Mar 14, 2023 at 10:43:50AM +0100, Das, Nirmoy wrote:
>
> On 3/14/2023 10:27 AM, Imre Deak wrote:
> > Add the missing intel_opregion_cleanup() prototype fixing CONFIG_ACPI=n
> > builds.
> >
> > Fixes: 3e226e4a2180 ("drm/i915/opregion: Cleanup opregion after errors
> > during driver loading")
> > Cc: Jani Nikula
> > Reported-by: kernel test robot
> > Link:
> > https://lore.kernel.org/oe-kbuild-all/202303141610.6l1vo7gw-...@intel.com/
> > Signed-off-by: Imre Deak
>
> Reviewed-by: Nirmoy Das
Thanks for the review, pushed the patch to din.
> > ---
> > drivers/gpu/drm/i915/display/intel_opregion.h | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_opregion.h
> > b/drivers/gpu/drm/i915/display/intel_opregion.h
> > index 181eb3e9abbf3..fd2ea8ef0fa20 100644
> > --- a/drivers/gpu/drm/i915/display/intel_opregion.h
> > +++ b/drivers/gpu/drm/i915/display/intel_opregion.h
> > @@ -86,6 +86,10 @@ static inline int intel_opregion_setup(struct
> > drm_i915_private *dev_priv)
> > return 0;
> > }
> > +static inline void intel_opregion_cleanup(struct drm_i915_private *i915)
> > +{
> > +}
> > +
> > static inline void intel_opregion_register(struct drm_i915_private
> > *dev_priv)
> > {
> > }
[Intel-gfx] [PATCH 7/7] drm/i915/dsb: split out DSB regs to a separate file
Clean up i915_reg.h by splitting out DSB regs to display/intel_dsb_regs.h. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dsb.c | 1 + drivers/gpu/drm/i915/display/intel_dsb_regs.h | 67 +++ drivers/gpu/drm/i915/i915_reg.h | 56 3 files changed, 68 insertions(+), 56 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_dsb_regs.h diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c b/drivers/gpu/drm/i915/display/intel_dsb.c index 19e422da57dc..bed058d2c3ac 100644 --- a/drivers/gpu/drm/i915/display/intel_dsb.c +++ b/drivers/gpu/drm/i915/display/intel_dsb.c @@ -11,6 +11,7 @@ #include "intel_de.h" #include "intel_display_types.h" #include "intel_dsb.h" +#include "intel_dsb_regs.h" struct i915_vma; diff --git a/drivers/gpu/drm/i915/display/intel_dsb_regs.h b/drivers/gpu/drm/i915/display/intel_dsb_regs.h new file mode 100644 index ..12535d478775 --- /dev/null +++ b/drivers/gpu/drm/i915/display/intel_dsb_regs.h @@ -0,0 +1,67 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2023 Intel Corporation + */ + +#ifndef __INTEL_DSB_REGS_H__ +#define __INTEL_DSB_REGS_H__ + +#include "intel_display_reg_defs.h" + +/* This register controls the Display State Buffer (DSB) engines. */ +#define _DSBSL_INSTANCE_BASE 0x70B00 +#define DSBSL_INSTANCE(pipe, id) (_DSBSL_INSTANCE_BASE + \ +(pipe) * 0x1000 + (id) * 0x100) +#define DSB_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x0) +#define DSB_TAIL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x4) +#define DSB_CTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x8) +#define DSB_ENABLE REG_BIT(31) +#define DSB_BUF_REITERATEREG_BIT(29) +#define DSB_WAIT_FOR_VBLANK REG_BIT(28) +#define DSB_WAIT_FOR_LINE_IN REG_BIT(27) +#define DSB_HALT REG_BIT(16) +#define DSB_NON_POSTED REG_BIT(8) +#define DSB_STATUS_BUSY REG_BIT(0) +#define DSB_MMIOCTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0xc) +#define DSB_MMIO_DEAD_CLOCKS_ENABLE REG_BIT(31) +#define DSB_MMIO_DEAD_CLOCKS_COUNT_MASK REG_GENMASK(15, 8) +#define DSB_MMIO_DEAD_CLOCKS_COUNT(x) REG_FIELD_PREP(DSB_MMIO_DEAD_CLOCK_COUNT_MASK, (x)) +#define DSB_MMIO_CYCLES_MASK REG_GENMASK(7, 0) +#define DSB_MMIO_CYCLES(x) REG_FIELD_PREP(DSB_MMIO_CYCLES_MASK, (x)) +#define DSB_POLLFUNC(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x10) +#define DSB_POLL_ENABLE REG_BIT(31) +#define DSB_POLL_WAIT_MASK REG_GENMASK(30, 23) +#define DSB_POLL_WAIT(x) REG_FIELD_PREP(DSB_POLL_WAIT_MASK, (x)) /* usec */ +#define DSB_POLL_COUNT_MASK REG_GENMASK(22, 15) +#define DSB_POLL_COUNT(x)REG_FIELD_PREP(DSB_POLL_COUNT_MASK, (x)) +#define DSB_DEBUG(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id) + 0x14) +#define DSB_POLLMASK(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x1c) +#define DSB_STATUS(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x24) +#define DSB_INTERRUPT(pipe, id)_MMIO(DSBSL_INSTANCE(pipe, id) + 0x28) +#define DSB_ATS_FAULT_INT_EN REG_BIT(20) +#define DSB_GTT_FAULT_INT_EN REG_BIT(19) +#define DSB_RSPTIMEOUT_INT_ENREG_BIT(18) +#define DSB_POLL_ERR_INT_EN REG_BIT(17) +#define DSB_PROG_INT_EN REG_BIT(16) +#define DSB_ATS_FAULT_INT_STATUS REG_BIT(4) +#define DSB_GTT_FAULT_INT_STATUS REG_BIT(3) +#define DSB_RSPTIMEOUT_INT_STATUSREG_BIT(2) +#define DSB_POLL_ERR_INT_STATUS REG_BIT(1) +#define DSB_PROG_INT_STATUS REG_BIT(0) +#define DSB_CURRENT_HEAD(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x2c) +#define DSB_RM_TIMEOUT(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x30) +#define DSB_RM_CLAIM_TIMEOUT REG_BIT(31) +#define DSB_RM_READY_TIMEOUT REG_BIT(30) +#define DSB_RM_CLAIM_TIMEOUT_COUNT_MASK REG_GENMASK(23, 16) +#define DSB_RM_CLAIM_TIMEOUT_COUNT(x) REG_FIELD_PREP(DSB_RM_CLAIM_TIMEOUT_COUNT_MASK, (x)) /* clocks */ +#define DSB_RM_READY_TIMEOUT_VALUE_MASK REG_GENMASK(15, 0) +#define DSB_RM_READY_TIMEOUT_VALUE(x) REG_FIELD_PREP(DSB_RM_READY_TIMEOUT_VALUE, (x)) /* usec */ +#define DSB_RMTIMEOUTREG_CAPTURE(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x34) +#define DSB_PMCTRL(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x38) +#define DSB_PMCTRL_2(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x3c) +#define DSB_PF_LN_LOWER(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x40) +#define DSB_PF_LN_UPPER(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x44) +#define DSB_BUFRPT_CNT(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0x48) +#define DSB_CHICKEN(pipe, id) _MMIO(DSBSL_INSTANCE(pipe, id) + 0xf0) + +#endif /*
[Intel-gfx] [PATCH 6/7] drm/i915/psr: split out PSR regs to a separate file
Clean up i915_reg.h by splitting out PSR regs to display/intel_psr_regs.h. Signed-off-by: Jani Nikula --- .../drm/i915/display/intel_display_debugfs.c | 1 + drivers/gpu/drm/i915/display/intel_psr.c | 1 + drivers/gpu/drm/i915/display/intel_psr_regs.h | 260 ++ drivers/gpu/drm/i915/gvt/handlers.c | 1 + drivers/gpu/drm/i915/i915_irq.c | 1 + drivers/gpu/drm/i915/i915_reg.h | 249 - drivers/gpu/drm/i915/intel_gvt_mmio_table.c | 1 + 7 files changed, 265 insertions(+), 249 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_psr_regs.h diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index 65585f19c6c8..ab71aa85852d 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -28,6 +28,7 @@ #include "intel_hotplug.h" #include "intel_panel.h" #include "intel_psr.h" +#include "intel_psr_regs.h" #include "intel_sprite.h" #include "intel_wm.h" diff --git a/drivers/gpu/drm/i915/display/intel_psr.c b/drivers/gpu/drm/i915/display/intel_psr.c index 44610b20cd29..94863b39c274 100644 --- a/drivers/gpu/drm/i915/display/intel_psr.c +++ b/drivers/gpu/drm/i915/display/intel_psr.c @@ -34,6 +34,7 @@ #include "intel_dp_aux.h" #include "intel_hdmi.h" #include "intel_psr.h" +#include "intel_psr_regs.h" #include "intel_snps_phy.h" #include "skl_universal_plane.h" diff --git a/drivers/gpu/drm/i915/display/intel_psr_regs.h b/drivers/gpu/drm/i915/display/intel_psr_regs.h new file mode 100644 index ..958d8cabc44b --- /dev/null +++ b/drivers/gpu/drm/i915/display/intel_psr_regs.h @@ -0,0 +1,260 @@ +/* SPDX-License-Identifier: MIT */ +/* + * Copyright © 2023 Intel Corporation + */ + +#ifndef __INTEL_PSR_REGS_H__ +#define __INTEL_PSR_REGS_H__ + +#include "intel_display_reg_defs.h" + +#define TRANS_EXITLINE(trans) _MMIO_TRANS2((trans), _TRANS_EXITLINE_A) +#define EXITLINE_ENABLE REG_BIT(31) +#define EXITLINE_MASKREG_GENMASK(12, 0) +#define EXITLINE_SHIFT 0 + +/* + * HSW+ eDP PSR registers + * + * HSW PSR registers are relative to DDIA(_DDI_BUF_CTL_A + 0x800) with just one + * instance of it + */ +#define _SRD_CTL_A 0x60800 +#define _SRD_CTL_EDP 0x6f800 +#define EDP_PSR_CTL(tran) _MMIO_TRANS2(tran, _SRD_CTL_A) +#define EDP_PSR_ENABLE (1 << 31) +#define BDW_PSR_SINGLE_FRAME (1 << 30) +#define EDP_PSR_RESTORE_PSR_ACTIVE_CTX_MASK (1 << 29) /* SW can't modify */ +#define EDP_PSR_LINK_STANDBY (1 << 27) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_MASK (3 << 25) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES (0 << 25) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_4_LINES (1 << 25) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_2_LINES (2 << 25) +#define EDP_PSR_MIN_LINK_ENTRY_TIME_0_LINES (3 << 25) +#define EDP_PSR_MAX_SLEEP_TIME_SHIFT 20 +#define EDP_PSR_SKIP_AUX_EXIT(1 << 12) +#define EDP_PSR_TP1_TP2_SEL (0 << 11) +#define EDP_PSR_TP1_TP3_SEL (1 << 11) +#define EDP_PSR_CRC_ENABLE (1 << 10) /* BDW+ */ +#define EDP_PSR_TP2_TP3_TIME_500us (0 << 8) +#define EDP_PSR_TP2_TP3_TIME_100us (1 << 8) +#define EDP_PSR_TP2_TP3_TIME_2500us (2 << 8) +#define EDP_PSR_TP2_TP3_TIME_0us (3 << 8) +#define EDP_PSR_TP4_TIME_0US (3 << 6) /* ICL+ */ +#define EDP_PSR_TP1_TIME_500us (0 << 4) +#define EDP_PSR_TP1_TIME_100us (1 << 4) +#define EDP_PSR_TP1_TIME_2500us (2 << 4) +#define EDP_PSR_TP1_TIME_0us (3 << 4) +#define EDP_PSR_IDLE_FRAME_SHIFT 0 + +/* + * Until TGL, IMR/IIR are fixed at 0x648xx. On TGL+ those registers are relative + * to transcoder and bits defined for each one as if using no shift (i.e. as if + * it was for TRANSCODER_EDP) + */ +#define EDP_PSR_IMR_MMIO(0x64834) +#define EDP_PSR_IIR_MMIO(0x64838) +#define _PSR_IMR_A 0x60814 +#define _PSR_IIR_A 0x60818 +#define TRANS_PSR_IMR(tran)_MMIO_TRANS2(tran, _PSR_IMR_A) +#define TRANS_PSR_IIR(tran)_MMIO_TRANS2(tran, _PSR_IIR_A) +#define _EDP_PSR_TRANS_SHIFT(trans) ((trans) == TRANSCODER_EDP ? \ +0 : ((trans) - TRANSCODER_A + 1) * 8) +#define TGL_PSR_MASK REG_GENMASK(2, 0) +#define TGL_PSR_ERRORREG_BIT(2) +#define TGL_PSR_POST_EXITREG_BIT(1) +#define TGL_PSR_PRE_ENTRYREG_BIT(0) +#define EDP_PSR_MASK(trans) (TGL_PSR_MASK <<\ +
