Re: [Intel-gfx] [PATCH v5] drm/i915: Make IRQ reset and postinstall multi-gt aware
On 18.04.2023 01:53, Andi Shyti wrote:
In multi-gt systems IRQs need to be reset and enabled per GT.
This might add some redundancy when handling interrupts for
engines that might not exist in every tile, but helps to keep the
code cleaner and more understandable.
Signed-off-by: Andi Shyti
Cc: Tvrtko Ursulin
Reviewed-by: Matt Roper
---
Hi,
thanks Matt for the review.
Andi
Changelog
=
v4 -> v5
- Another little cosmetic on the variable declaration. Go back
to v3 but using "&dev_priv->uncore" instead of
"to_gt(dev_priv)->uncore", which is much cleaner.
- Add Matt's r-b.
v3 -> v4
- do not change the initial gt and uncore initialization in
order to gain a better understanding at a glance of the
purpose of all the local variables.
v2 -> v3
- keep GUnit irq initialization out of the for_each_gt() loop as
the media GT doesn't have a GUnit.
v1 -> v2
- improve description in the commit log.
drivers/gpu/drm/i915/i915_irq.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
drivers/gpu/drm/i915/i915_irq.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
Harmless duplication, I guess.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dea1a117f3fa1..eead067f18c7a 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2856,12 +2856,15 @@ static void gen11_irq_reset(struct drm_i915_private
*dev_priv)
static void dg1_irq_reset(struct drm_i915_private *dev_priv)
{
- struct intel_gt *gt = to_gt(dev_priv);
- struct intel_uncore *uncore = gt->uncore;
+ struct intel_uncore *uncore = &dev_priv->uncore;
+ struct intel_gt *gt;
+ unsigned int i;
dg1_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(gt);
+ for_each_gt(gt, dev_priv, i)
+ gen11_gt_irq_reset(gt);
+
gen11_display_irq_reset(dev_priv);
GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
@@ -3643,11 +3646,13 @@ static void gen11_irq_postinstall(struct
drm_i915_private *dev_priv)
static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
{
- struct intel_gt *gt = to_gt(dev_priv);
- struct intel_uncore *uncore = gt->uncore;
+ struct intel_uncore *uncore = &dev_priv->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+ struct intel_gt *gt;
+ unsigned int i;
- gen11_gt_irq_postinstall(gt);
+ for_each_gt(gt, dev_priv, i)
+ gen11_gt_irq_postinstall(gt);
GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
Re: [Intel-gfx] [PATCH] drm/i915/guc/slpc: Provide sysfs for efficient freq
Hi Vinay,
On Mon, Apr 17, 2023 at 11:04:31PM -0700, Belgaumkar, Vinay wrote:
>
> On 4/17/2023 6:39 PM, Andi Shyti wrote:
> > Hi Vinay,
> >
> > Looks good, just few minor comments below,
> >
> > [...]
> >
> > > @@ -267,13 +267,11 @@ static int run_test(struct intel_gt *gt, int
> > > test_type)
> > > }
> > > /*
> > > - * Set min frequency to RPn so that we can test the whole
> > > - * range of RPn-RP0. This also turns off efficient freq
> > > - * usage and makes results more predictable.
> > > + * Turn off efficient freq so RPn/RP0 ranges are obeyed
> > >*/
> > > - err = slpc_set_min_freq(slpc, slpc->min_freq);
> > > + err = intel_guc_slpc_set_ignore_eff_freq(slpc, true);
> > > if (err) {
> > > - pr_err("Unable to update min freq!");
> > > + pr_err("Unable to turn off efficient freq!");
> > drm_err()? or gt_err()? As we are here we can use a proper
> > printing.
> >
> > How is this change related to the scope of this patch?
> The selftest was relying on setting min freq < RP1 to disable efficient
> freq, now that we have an interface, the test should use that (former method
> will not work). Should this be a separate patch?
I would have placed it in a separate patch. But I'm not strong
with it, up to you.
Thanks,
Andi
[Intel-gfx] ✓ Fi.CI.IGT: success for fdinfo alternative memory stats proposal
== Series Details ==
Series: fdinfo alternative memory stats proposal
URL : https://patchwork.freedesktop.org/series/116581/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13022_full -> Patchwork_116581v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 8)
--
Additional (1): pig-kbl-iris
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116581v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip:
- {shard-dg1}:NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-dg1-14/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html
Known issues
Here are the changes found in Patchwork_116581v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [PASS][2] -> [FAIL][3] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-apl1/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.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_13022/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-glk3/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-glk7/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2346])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-glk7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-apl6/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-apl4/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271]) +29 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-glk7/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#658])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-glk7/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][13] ([i915#7742]) -> [PASS][14] +1 similar
issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-rkl-7/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-rkl-1/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_exec_fair@basic-pace@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#2842]) -> [PASS][16] +2 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-rkl-7/igt@gem_exec_fair@basic-p...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-rkl-7/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [ABORT][17] ([i915#5566]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-glk7/igt@gen9_exec_pa...@allowed-all.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-glk7/igt@gen9_exec_pa...@allowed-all.html
* igt@i915_pm_rpm@modeset-non-lpsp:
- {shard-rkl}:[SKIP][19] ([i915#1397]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-rkl-7/igt@i915_pm_...@modeset-non-lpsp.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116581v1/shard-rkl-1/igt
Re: [Intel-gfx] [PATCH] drm/i915/gt: Consider multi-gt at all places
On 17/04/2023 19:13, Upadhyay, Tejas wrote:
-Original Message-
From: Tvrtko Ursulin
Sent: Wednesday, April 5, 2023 2:01 PM
To: Upadhyay, Tejas ; Intel-
g...@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915/gt: Consider multi-gt at all places
On 05/04/2023 07:56, Upadhyay, Tejas wrote:
-int igt_live_test_end(struct igt_live_test *t)
+int igt_live_test_end(struct igt_live_test *t, struct intel_gt *gt)
{
- struct drm_i915_private *i915 = t->i915;
+ struct drm_i915_private *i915 = gt->i915;
struct intel_engine_cs *engine;
enum intel_engine_id id;
@@ -57,7 +57,7 @@ int igt_live_test_end(struct igt_live_test *t)
return -EIO;
}
- for_each_engine(engine, to_gt(i915), id) {
+ for_each_engine(engine, gt, id) {
if (t->reset_engine[id] ==
i915_reset_engine_count(&i915->gpu_error, engine))
continue;
diff --git a/drivers/gpu/drm/i915/selftests/igt_live_test.h
b/drivers/gpu/drm/i915/selftests/igt_live_test.h
index 36ed42736c52..209b0548c603 100644
--- a/drivers/gpu/drm/i915/selftests/igt_live_test.h
+++ b/drivers/gpu/drm/i915/selftests/igt_live_test.h
@@ -27,9 +27,9 @@ struct igt_live_test {
* e.g. if the GPU was reset.
*/
int igt_live_test_begin(struct igt_live_test *t,
- struct drm_i915_private *i915,
+ struct intel_gt *gt,
const char *func,
const char *name);
-int igt_live_test_end(struct igt_live_test *t);
+int igt_live_test_end(struct igt_live_test *t, struct intel_gt
+*gt);
Back in the day the plan was that live selftests are device focused
and then we also have intel_gt_live_subtests, which are obviously GT
focused. So in that sense adding a single GT parameter to
igt_live_test_begin isn't something I immediately understand.
Could you explain in one or two practical examples what is not
working properly and how is this patch fixing it?
For example you are running test "live_all_engines(void *arg)",
-- Below test begin, will reset counters for primary GT - Tile0 -- err
= igt_live_test_begin(&t, to_gt(i915), __func__, "");
if (err)
goto out_free;
--- Now we loop for all engines, note here for MTL vcs, vecs engines are not
on primary GT or tile 0,
So counters did not reset on test begin does not cover them. ---
In test_begin, below will not reset count for vcs, vecs engines on MTL,
for_each_engine(engine, gt, id)
t->reset_engine[id] =
i915_reset_engine_count(&i915->gpu_error,
engine);
--- Then below will end test, again for primary GT where above
mentioned engines are not there --- err = igt_live_test_end(&t,
to_gt(i915));
In short to me it looks like igt_live_test for device needs attention when we
have different engines on different GTs like MTL.
If you either add for_each_gt to that for_each_engine in igt_live_test_begin
and igt_live_test_end, or alternatively for_each_uabi_engine (maybe misses
some internal engines?), everything works? That would be much smaller
patch and wouldn't falsely associate live tests with a single gt.
Below would work, if you agree I will rearrange and send patch.
--- a/drivers/gpu/drm/i915/selftests/igt_live_test.c
+++ b/drivers/gpu/drm/i915/selftests/igt_live_test.c
@@ -16,28 +16,31 @@ int igt_live_test_begin(struct igt_live_test *t,
const char *func,
const char *name)
{
- struct intel_gt *gt = to_gt(i915);
+ struct intel_gt *gt;
struct intel_engine_cs *engine;
enum intel_engine_id id;
int err;
+ unsigned int i;
- t->i915 = i915;
- t->func = func;
- t->name = name;
+ for_each_gt(gt, i915, i) {
+ t->i915 = i915;
+ t->func = func;
+ t->name = name;
These three assignments should stay outside the outer loop.
- err = intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
- if (err) {
- pr_err("%s(%s): failed to idle before, with err=%d!",
- func, name, err);
- return err;
- }
+ err = intel_gt_wait_for_idle(gt, MAX_SCHEDULE_TIMEOUT);
+ if (err) {
+ pr_err("%s(%s): failed to idle before, with err=%d!",
+ func, name, err);
+ return err;
+ }
- t->reset_global = i915_reset_count(&i915->gpu_error);
+ t->reset_global = i915_reset_count(&i915->gpu_error);
Ditto.
Rest looks good to me.
Regards,
Tvrtko
- for_each_engine(engine, gt, id)
- t->reset_engine[id] =
+ for_each_engine(engine, gt, id)
+ t->reset_engine[id] =
i915_reset_engine_count(&i915->gpu_error, engine);
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/dp_mst: Clear MSG_RDY flag before sending new message
== Series Details == Series: drm/dp_mst: Clear MSG_RDY flag before sending new message URL : https://patchwork.freedesktop.org/series/116623/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13023 -> Patchwork_116623v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_116623v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_116623v1, 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_116623v1/index.html Participating hosts (38 -> 36) -- Missing(2): fi-kbl-soraka fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_116623v1: ### IGT changes ### Possible regressions * igt@gem_exec_suspend@basic-s0@smem: - fi-cfl-8700k: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/fi-cfl-8700k/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v1/fi-cfl-8700k/igt@gem_exec_suspend@basic...@smem.html Known issues Here are the changes found in Patchwork_116623v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_pm: - bat-rpls-2: [PASS][3] -> [DMESG-FAIL][4] ([i915#4258]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-2/igt@i915_selftest@live@gt_pm.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v1/bat-rpls-2/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@requests: - bat-rpls-1: [PASS][5] -> [ABORT][6] ([i915#7911] / [i915#7982]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-1/igt@i915_selftest@l...@requests.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v1/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@i915_selftest@live@reset: - bat-rpls-2: [PASS][7] -> [ABORT][8] ([i915#4983] / [i915#7913]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/bat-rpls-2/igt@i915_selftest@l...@reset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v1/bat-rpls-2/igt@i915_selftest@l...@reset.html [i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982 Build changes - * Linux: CI_DRM_13023 -> Patchwork_116623v1 CI-20190529: 20190529 CI_DRM_13023: 0c6c8e560ac78d000179e195e1280cc3479ebd58 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7258: ad2eb276eda849b7a7985229009a816c7608186c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116623v1: 0c6c8e560ac78d000179e195e1280cc3479ebd58 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 9c6a56132f18 drm/dp_mst: Clear MSG_RDY flag before sending new message == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v1/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Initialize dkl_phy spin lock from display code path (rev2)
== Series Details ==
Series: drm/i915: Initialize dkl_phy spin lock from display code path (rev2)
URL : https://patchwork.freedesktop.org/series/116325/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13022_full -> Patchwork_116325v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_116325v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-glk5/igt@gem_exec_f...@basic-deadline.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-glk8/igt@gem_exec_f...@basic-deadline.html
* igt@i915_selftest@live@dmabuf:
- shard-apl: [PASS][3] -> [DMESG-FAIL][4] ([i915#7562])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-apl3/igt@i915_selftest@l...@dmabuf.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-apl2/igt@i915_selftest@l...@dmabuf.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3886])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-glk9/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible@bc-hdmi-a1-hdmi-a2:
- shard-glk: [PASS][6] -> [FAIL][7] ([i915#79])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-glk6/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-glk5/igt@kms_flip@2x-flip-vs-expired-vblank-interrupti...@bc-hdmi-a1-hdmi-a2.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc:
- shard-glk: NOTRUN -> [SKIP][8] ([fdo#109271]) +29 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-glk9/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#658])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-glk9/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][10] ([i915#7742]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-rkl-6/igt@drm_fdinfo@most-busy-check-...@rcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-rkl-7/igt@drm_fdinfo@most-busy-check-...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][12] ([i915#6268]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-tglu-10/igt@gem_ctx_e...@basic-nohangcheck.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-tglu-3/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-rkl}:[FAIL][14] ([i915#2842]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-rkl-4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-rkl-2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [FAIL][16] ([i915#2842]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-apl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [ABORT][18] ([i915#5566]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-glk7/igt@gen9_exec_pa...@allowed-all.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-glk9/igt@gen9_exec_pa...@allowed-all.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-apl: [DMESG-FAIL][20] ([i915#5334]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-apl3/igt@i915_selftest@live@gt_heartbeat.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v2/shard-apl2/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_cursor_legacy@single-bo@pipe-b:
- {shard-dg1}:[INCOMPLETE][22] ([i915#8011] / [i915#8347]) ->
[PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13022/shard-dg1-14/igt@kms_cursor_legacy@single...@pipe-b.html
[23]:
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On 17/04/2023 20:39, Rob Clark wrote:
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Add support to dump GEM stats to fdinfo.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 12 +++
drivers/gpu/drm/drm_file.c| 52 +++
include/drm/drm_drv.h | 7
include/drm/drm_file.h| 8 +
4 files changed, 79 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index 2ab32c40e93c..8273a41b2fb0 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -21,6 +21,7 @@ File format specification
- File shall contain one key value pair per one line of text.
- Colon character (`:`) must be used to delimit keys and values.
+- Caret (`^`) is also a reserved character.
this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
Could you explain or remind me with a link to a previous explanation?
What tool barfs on it and how? Spirit of drm-usage-stats.pl is that for
both drm-engine-: and drm-memory-: generic userspace is
supposed to take the whole as opaque and just enumerate all it finds.
Gputop manages to do that with engines names it knows _nothing_ about.
If it worked with memory regions it would just show the list of new
regions as for example "system^resident", "system^active". Then tools
can be extended to understand it better and provide a sub-breakdown if
wanted.
Ugly not, we can change from caret to something nicer, unless I am
missing something it works, no?
Regards,
Tvrtko
(also, it is IMHO rather ugly)
BR,
-R
- All keys shall be prefixed with `drm-`.
- Whitespace between the delimiter and first non-whitespace character shall be
ignored when parsing.
@@ -105,6 +106,17 @@ object belong to this client, in the respective memory
region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
indicating kibi- or mebi-bytes.
+- drm-memory-^size: [KiB|MiB]
+- drm-memory-^shared: [KiB|MiB]
+- drm-memory-^resident: [KiB|MiB]
+- drm-memory-^purgeable: [KiB|MiB]
+- drm-memory-^active: [KiB|MiB]
+
+Resident category is identical to the drm-memory- key and two should be
+mutually exclusive.
+
+TODO more description text...
+
- drm-cycles-
Engine identifier string must be the same as the one specified in the
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 37b4f76a5191..e202f79e816d 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+static void
+print_stat(struct drm_printer *p, const char *stat, const char *region, u64 sz)
+{
+ const char *units[] = {"", " KiB", " MiB"};
+ unsigned int u;
+
+ if (sz == ~0ull) /* Not supported by the driver. */
+ return;
+
+ for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
+ if (sz < SZ_1K)
+ break;
+ sz = div_u64(sz, SZ_1K);
+ }
+
+ drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
+ region, stat, sz, units[u]);
+}
+
+static void print_memory_stats(struct drm_printer *p, struct drm_file *file)
+{
+ struct drm_device *dev = file->minor->dev;
+ struct drm_fdinfo_memory_stat *stats;
+ unsigned int num, i;
+ char **regions;
+
+ regions = dev->driver->query_fdinfo_memory_regions(dev, &num);
+
+ stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
+ if (!stats)
+ return;
+
+ dev->driver->query_fdinfo_memory_stats(file, stats);
+
+ for (i = 0; i < num; i++) {
+ if (!regions[i]) /* Allow sparse name arrays. */
+ continue;
+
+ print_stat(p, "size", regions[i], stats[i].size);
+ print_stat(p, "shared", regions[i], stats[i].shared);
+ print_stat(p, "resident", regions[i], stats[i].resident);
+ print_stat(p, "purgeable", regions[i], stats[i].purgeable);
+ print_stat(p, "active", regions[i], stats[i].active);
+ }
+
+ kfree(stats);
+}
+
/**
* drm_show_fdinfo - helper for drm file fops
* @seq_file: output stream
@@ -900,6 +949,9 @@ void drm_show_fdinfo(struct seq_file *m, struct file *f)
if (dev->driver->show_fdinfo)
dev->driver->show_fdinfo(&p, file);
+
+ if (dev->driver->query_fdinfo_memory_regions)
+ print_memory_stats(&p, file);
}
EXPORT_SYMBOL(drm_show_fdinfo);
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 89e2706cac56..ccc1cd98d2aa 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -35,6 +35,7 @@
Re: [Intel-gfx] [PATCH 1/1] drm/i915/debugfs: New debugfs for display clock frequencies
On Fri, 14 Apr 2023, Lucas De Marchi wrote:
> On Wed, Apr 12, 2023 at 12:22:51PM +0300, Jani Nikula wrote:
>>On Wed, 12 Apr 2023, Bhanuprakash Modem wrote:
>>> +
>>> static ssize_t i915_displayport_test_active_write(struct file *file,
>>> const char __user *ubuf,
>>> size_t len, loff_t *offp)
>>> @@ -1065,6 +1080,7 @@ static const struct drm_info_list
>>> intel_display_debugfs_list[] = {
>>> {"i915_dp_mst_info", i915_dp_mst_info, 0},
>>> {"i915_ddb_info", i915_ddb_info, 0},
>>> {"i915_lpsp_status", i915_lpsp_status, 0},
>>> + {"i915_disply_clock_info", i915_display_clock_info, 0},
>>
>>Maybe "i915_cdclk_info"? (Also, disply has a typo there.)
>
> hijacking this a little bit since I saw the new version of this commit
> applied without the display_ part. Should we consider moving all the
> display-related debugfs files to display/ directory? I think that would
> make it clearer for the xe integration while also cleaning up a little
> bit the various files on i915. Downside would be synchronizing this with
> the tools reading those files. I guess it's only igt and CI that care about
> them?
While I agree in principle, I see potential for inflicting a lot of
paper cuts here.
We've moved individual files in the past, and it's generally been
fine. The pain is manageable. But seems like moving tons of files needs
to have some transition period with symlinks in kernel or igt checking
both places or something. Imagine bisecting a kernel bug using an igt
test, and needing two different igt builds depending on where the file
is.
On the other hand, maybe display/ directory is something that should be
reserved for drm to create. Anythin driver specific should be
prefixed. So either you'd have files named i915_display/* or
display/i915_*. Needs consideration.
I'm just leaning towards avoiding trouble at this time.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v1 2/4] drm/i915: update the QGV point frequency calculations
On Sun, Apr 16, 2023 at 06:54:15PM +0300, Vinod Govindapillai wrote: > From MTL onwwards, pcode locks the QGV point based on peak BW of > the intended QGV point passed by the driver. So the peak BW > calculation must match the value expected by the pcode. Update > the calculations as per the Bspec. > > Bspec: 64636 > > Signed-off-by: Vinod Govindapillai > --- > drivers/gpu/drm/i915/display/intel_bw.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c > b/drivers/gpu/drm/i915/display/intel_bw.c > index 5fa599b04ca5..57f8204162dd 100644 > --- a/drivers/gpu/drm/i915/display/intel_bw.c > +++ b/drivers/gpu/drm/i915/display/intel_bw.c > @@ -179,7 +179,7 @@ static int mtl_read_qgv_point_info(struct > drm_i915_private *dev_priv, > val2 = intel_uncore_read(&dev_priv->uncore, >MTL_MEM_SS_INFO_QGV_POINT_HIGH(point)); > dclk = REG_FIELD_GET(MTL_DCLK_MASK, val); > - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000); > + sp->dclk = (16667 * dclk + 500) / 1000; Hmm, wonder does it at least partly now intersects with what I'm doing in https://patchwork.freedesktop.org/series/114982/ I remember we were discussing if this "+500" is actually also rounding up itself. The thing is that the way how rounding up is done for instance in DIV_ROUND_UP also, if you check, if you lets say want to divide n by d, however you want to round up the result, you add n = n + (d - 1) and then divide by d. This is how DIV_ROUND_UP works. That effectively means that if n would be anything more than m*d, result would be not m, but m + 1(note flooring would give m) Adding 500, when dividing by 1000 is also rouding up, however it is a bit weaker. In example above that would mean, if we want to divide n by d, we first add n = n + d / 2 and then divide by d. That effectively means that if n would be anything more than m*d + 500, result would not m, but again m + 1(again note, that true flooeing would have given m, not m + 1) So it is still rounding up, but just being weaker/less precise though. If we would want to truly floor that division, we would want to get m, but not m + 1 from above examples, which means that we should just divide n / d, without adding anything. So in my opinion, if we want to floor (16667 * dclk / 1000) result - it should not have both "DIV_ROUND_UP" and " + 500" things - thats what I've done in series which also was touching this code as well. I think it would be nice to raise issue and clarify from HW team, if it was initial intention, because adding + 500 is clearly doing rounding up as well, but it is just now on +-500(d/2) granularity now, while DIV_ROUND_UP worked with +-1 granularity. However both things are essentially "rounding up". So in that case I would really want to challenge or clarify, what is written in BSpec. Stan > sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val); > sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val); > > -- > 2.34.1 >
[Intel-gfx] [PATCH v3] drm/i915/display: Increase AUX timeout for Type-C
Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
Workaround: Increase the timeout.
WA_14017248603: adlp
Bspec: 55480
---v2
-change style on how we mention WA [Ankit]
-fix bat error by creating new func that is only called for aux power
well scenarios so we can avoid null pointer error as it is called
everywhere.
--v3
-Add non-default enable_timeout to power well descriptor which avoids
adding more platform checks [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display_power_map.c | 9 +
drivers/gpu/drm/i915/display/intel_display_power_well.c | 3 ++-
drivers/gpu/drm/i915/display/intel_display_power_well.h | 2 ++
3 files changed, 13 insertions(+), 1 deletion(-)
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..4b559de6d036 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1385,6 +1385,15 @@ static const struct i915_power_well_desc
xelpd_power_wells_main[] = {
),
.ops = &icl_aux_power_well_ops,
.fixed_enable_delay = true,
+ }, {
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC1),
+ I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC2),
+ I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC3),
+ I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC4),
+ ),
+ .ops = &icl_aux_power_well_ops,
+ .enable_timeout = true,
}, {
.instances = &I915_PW_INSTANCES(
I915_PW("AUX_TBT1", &icl_pwdoms_aux_tbt1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TBT1),
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index 62bafcbc7937..930a42c825c3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -253,6 +253,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
{
const struct i915_power_well_regs *regs = power_well->desc->ops->regs;
int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
+ int timeout = power_well->desc->enable_timeout ? : 1;
/*
* For some power wells we're not supposed to watch the status bit for
@@ -266,7 +267,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
/* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
if (intel_de_wait_for_set(dev_priv, regs->driver,
- HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
+ HSW_PWR_WELL_CTL_STATE(pw_idx), timeout)) {
drm_dbg_kms(&dev_priv->drm, "%s power well enable timeout\n",
intel_power_well_name(power_well));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
b/drivers/gpu/drm/i915/display/intel_display_power_well.h
index ba7cb977e7c7..e494df379e6c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
@@ -110,6 +110,8 @@ struct i915_power_well_desc {
* Thunderbolt mode.
*/
u16 is_tc_tbt:1;
+ /* Enable timeout if greater than the default 1ms */
+ u16 enable_timeout;
};
struct i915_power_well {
--
2.25.1
Re: [Intel-gfx] [PATCH v1 2/4] drm/i915: update the QGV point frequency calculations
On Tue, 2023-04-18 at 12:25 +0300, Lisovskiy, Stanislav wrote: > On Sun, Apr 16, 2023 at 06:54:15PM +0300, Vinod Govindapillai wrote: > > From MTL onwwards, pcode locks the QGV point based on peak BW of > > the intended QGV point passed by the driver. So the peak BW > > calculation must match the value expected by the pcode. Update > > the calculations as per the Bspec. > > > > Bspec: 64636 > > > > Signed-off-by: Vinod Govindapillai > > --- > > drivers/gpu/drm/i915/display/intel_bw.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c > > b/drivers/gpu/drm/i915/display/intel_bw.c > > index 5fa599b04ca5..57f8204162dd 100644 > > --- a/drivers/gpu/drm/i915/display/intel_bw.c > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c > > @@ -179,7 +179,7 @@ static int mtl_read_qgv_point_info(struct > > drm_i915_private *dev_priv, > > val2 = intel_uncore_read(&dev_priv->uncore, > > MTL_MEM_SS_INFO_QGV_POINT_HIGH(point)); > > dclk = REG_FIELD_GET(MTL_DCLK_MASK, val); > > - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000); > > + sp->dclk = (16667 * dclk + 500) / 1000; > > Hmm, wonder does it at least partly now intersects with what I'm doing in > https://patchwork.freedesktop.org/series/114982/ > > I remember we were discussing if this "+500" is actually also rounding up > itself. > > The thing is that the way how rounding up is done for instance in DIV_ROUND_UP > also, if you check, if you lets say want to divide n by d, however you want > to round > up the result, you add n = n + (d - 1) and then divide by d. This is how > DIV_ROUND_UP works. > That effectively means that if n would be anything more than m*d, result > would be not m, > but m + 1(note flooring would give m) > > Adding 500, when dividing by 1000 is also rouding up, however it is a bit > weaker. > In example above that would mean, if we want to divide n by d, we first add n > = n + d / 2 > and then divide by d. > That effectively means that if n would be anything more than m*d + 500, > result would not m, > but again m + 1(again note, that true flooeing would have given m, not m + 1) > > So it is still rounding up, but just being weaker/less precise though. > > If we would want to truly floor that division, we would want to get m, but > not m + 1 from > above examples, which means that we should just divide n / d, without adding > anything. > So in my opinion, if we want to floor (16667 * dclk / 1000) result - it > should not have > both "DIV_ROUND_UP" and " + 500" things - thats what I've done in series > which also was touching > this code as well. > > I think it would be nice to raise issue and clarify from HW team, if it was > initial intention, > because adding + 500 is clearly doing rounding up as well, but it is just now > on +-500(d/2) > granularity now, > while DIV_ROUND_UP worked with +-1 granularity. However both things are > essentially "rounding up". > So in that case I would really want to challenge or clarify, what is written > in BSpec. > > Stan Yes. Not much explanation about the addition of 500. I just blindly followed what was in that Bspec. Yes ideally div round_up is (n + d -1) / d. So what is the point of having 500 if the purpose is a rounding up unless it is accounting for some "other" factor. Anyway it is nice to get the clarification. So the "other" factor I assume is that pcode is using this formula to calculate QGV point peak BW. So in MTL as we pass this peak BW to pcode for compare and select the QGV point, driver and pcode calculations need to match. BR Vinod > > > sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val); > > sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val); > > > > -- > > 2.34.1 > >
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Fix CP current state
> -Original Message- > From: Kandpal, Suraj > Sent: Wednesday, April 12, 2023 9:18 AM > To: intel-gfx@lists.freedesktop.org > Cc: Gupta, Anshuman ; Nautiyal, Ankit K > ; Kandpal, Suraj > Subject: [PATCH] drm/i915/hdcp: Fix CP current state > > In many cases there is a need to change the CP property to desired even if > not modeset has been requested yet on such situation being lid gets closed > while DP is still connected in this case HDCP authentication needs to be > reenabled. > Remove Fix me as we now send a uevent via drm_hdcp_update_property. > > Signed-off-by: Suraj Kandpal > --- > drivers/gpu/drm/i915/display/intel_hdcp.c | 7 ++- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c > b/drivers/gpu/drm/i915/display/intel_hdcp.c > index 650232c4892b..7b0648e3499c 100644 > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c > @@ -2564,12 +2564,9 @@ void intel_hdcp_atomic_check(struct > drm_connector *connector, > new_state->crtc); > /* >* Fix the HDCP uapi content protection state in case of modeset. > - * FIXME: As per HDCP content protection property uapi doc, an > uevent() > - * need to be sent if there is transition from ENABLED->DESIRED. >*/ This comment was added because , we did not send uevent in intel_hdcp_atomic_check() function as it is not possible. > - if (drm_atomic_crtc_needs_modeset(crtc_state) && > - (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED && > - new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) > + if ((old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED && > + new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) > new_state->content_protection = > DRM_MODE_CONTENT_PROTECTION_DESIRED; This is overkill, for every display flip there will be HDCP authentication? Br, Anshuman Gupta. > > -- > 2.25.1
Re: [Intel-gfx] [PATCH v3] drm/i915/display: Increase AUX timeout for Type-C
On Tue, 18 Apr 2023, Suraj Kandpal wrote:
> Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
> Workaround: Increase the timeout.
>
> WA_14017248603: adlp
This needs to be in a comment, and removed from the commit message.
> Bspec: 55480
This needs to be moved down...
>
> ---v2
> -change style on how we mention WA [Ankit]
> -fix bat error by creating new func that is only called for aux power
> well scenarios so we can avoid null pointer error as it is called
> everywhere.
>
> --v3
> -Add non-default enable_timeout to power well descriptor which avoids
> adding more platform checks [Imre]
>
...here, right above the Cc: etc. tags.
> Cc: Jani Nikula
> Cc: Imre Deak
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_display_power_map.c | 9 +
> drivers/gpu/drm/i915/display/intel_display_power_well.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_display_power_well.h | 2 ++
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> 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..4b559de6d036 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> @@ -1385,6 +1385,15 @@ static const struct i915_power_well_desc
> xelpd_power_wells_main[] = {
> ),
> .ops = &icl_aux_power_well_ops,
> .fixed_enable_delay = true,
> + }, {
> + .instances = &I915_PW_INSTANCES(
> + I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC1),
> + I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC2),
> + I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC3),
> + I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC4),
> + ),
> + .ops = &icl_aux_power_well_ops,
> + .enable_timeout = true,
> }, {
> .instances = &I915_PW_INSTANCES(
> I915_PW("AUX_TBT1", &icl_pwdoms_aux_tbt1, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TBT1),
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> index 62bafcbc7937..930a42c825c3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> @@ -253,6 +253,7 @@ static void hsw_wait_for_power_well_enable(struct
> drm_i915_private *dev_priv,
> {
> const struct i915_power_well_regs *regs = power_well->desc->ops->regs;
> int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> + int timeout = power_well->desc->enable_timeout ? : 1;
>
> /*
>* For some power wells we're not supposed to watch the status bit for
> @@ -266,7 +267,7 @@ static void hsw_wait_for_power_well_enable(struct
> drm_i915_private *dev_priv,
>
> /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> if (intel_de_wait_for_set(dev_priv, regs->driver,
> - HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
> + HSW_PWR_WELL_CTL_STATE(pw_idx), timeout)) {
> drm_dbg_kms(&dev_priv->drm, "%s power well enable timeout\n",
> intel_power_well_name(power_well));
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> index ba7cb977e7c7..e494df379e6c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> @@ -110,6 +110,8 @@ struct i915_power_well_desc {
>* Thunderbolt mode.
>*/
> u16 is_tc_tbt:1;
> + /* Enable timeout if greater than the default 1ms */
> + u16 enable_timeout;
> };
>
> struct i915_power_well {
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v3] drm/i915/display: Increase AUX timeout for Type-C
On Tue, Apr 18, 2023 at 02:53:46PM +0530, Suraj Kandpal wrote:
> Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
> Workaround: Increase the timeout.
>
> WA_14017248603: adlp
> Bspec: 55480
>
> ---v2
> -change style on how we mention WA [Ankit]
> -fix bat error by creating new func that is only called for aux power
> well scenarios so we can avoid null pointer error as it is called
> everywhere.
>
> --v3
> -Add non-default enable_timeout to power well descriptor which avoids
> adding more platform checks [Imre]
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_display_power_map.c | 9 +
> drivers/gpu/drm/i915/display/intel_display_power_well.c | 3 ++-
> drivers/gpu/drm/i915/display/intel_display_power_well.h | 2 ++
> 3 files changed, 13 insertions(+), 1 deletion(-)
>
> 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..4b559de6d036 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> @@ -1385,6 +1385,15 @@ static const struct i915_power_well_desc
> xelpd_power_wells_main[] = {
> ),
> .ops = &icl_aux_power_well_ops,
> .fixed_enable_delay = true,
> + }, {
> + .instances = &I915_PW_INSTANCES(
> + I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC1),
> + I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC2),
> + I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC3),
> + I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC4),
> + ),
> + .ops = &icl_aux_power_well_ops,
> + .enable_timeout = true,
This should be the duration in ms.
Also .fixed_enable_delay = true is needed here as well, as DG2 is a
display 13 platform and uses TC1 requiring just waiting a fixed amount
of time instead of the regular polling (I forgot to mention this in my
previous feedback).
> }, {
> .instances = &I915_PW_INSTANCES(
> I915_PW("AUX_TBT1", &icl_pwdoms_aux_tbt1, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TBT1),
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> index 62bafcbc7937..930a42c825c3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> @@ -253,6 +253,7 @@ static void hsw_wait_for_power_well_enable(struct
> drm_i915_private *dev_priv,
> {
> const struct i915_power_well_regs *regs = power_well->desc->ops->regs;
> int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> + int timeout = power_well->desc->enable_timeout ? : 1;
>
> /*
>* For some power wells we're not supposed to watch the status bit for
> @@ -266,7 +267,7 @@ static void hsw_wait_for_power_well_enable(struct
> drm_i915_private *dev_priv,
>
> /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> if (intel_de_wait_for_set(dev_priv, regs->driver,
> - HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
> + HSW_PWR_WELL_CTL_STATE(pw_idx), timeout)) {
> drm_dbg_kms(&dev_priv->drm, "%s power well enable timeout\n",
> intel_power_well_name(power_well));
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> index ba7cb977e7c7..e494df379e6c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> @@ -110,6 +110,8 @@ struct i915_power_well_desc {
>* Thunderbolt mode.
>*/
> u16 is_tc_tbt:1;
> + /* Enable timeout if greater than the default 1ms */
> + u16 enable_timeout;
> };
>
> struct i915_power_well {
> --
> 2.25.1
>
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
> From: Jason Gunthorpe > Sent: Monday, April 17, 2023 9:39 PM > > On Fri, Apr 14, 2023 at 09:11:30AM +, Tian, Kevin wrote: > > > The only corner case with this option is when a user mixes group > > and cdev usages. iirc you mentioned it's a valid usage to be supported. > > In that case the kernel doesn't have sufficient knowledge to judge > > 'resettable' as it doesn't know which groups are opened by this user. > > IMHO we don't need to support this combination. Do you mean we don't support hot-reset for this combination or we don't support user using this combination. I guess the prior one. Right? > > We can say that to use the hot reset API the user must put all their > devices into the same iommufd_ctx and cover 100% of the known use > cases for this. > > There are already other situations, like nesting, that do force users > to put everything into one iommufd_ctx. > > No reason to make things harder and more complicated. Ditto. We just fail hot-reset for the multiple iommufds case. Is it? Otherwise, we need to prevent users from using multiple iommufds. > I'm coming to the feeling that we should put no-iommu devices in > iommufd_ctx's as well. They would be an iommufd_access like > mdevs. That would clean up the complications they cause here. Ok, the lucky thing is you have merged the patch series that creates iommufd_access for emulated devices in bind. So cdev series needs to handle noiommu case by creating iommufd_access. > > I suppose we should have done that from the beginning - no-iommu is an > IOMMUFD access, it just uses a crazy /proc based way to learn the > PFNs. Making it a proper access and making a real VFIO ioctl that > calls iommufd_access_pin_pages() and returns the DMA mapped addresses > to userspace would go a long way to making no-iommu work in a logical, > usable, way. This seems to be an improvement for noiommu mode. It can be done later. For now, generating access_id and binding noiommu devices with iommufdctx is enough for supporting noiommu hot-reset. Regards, Yi Liu
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
> From: Alex Williamson > Sent: Tuesday, April 18, 2023 12:11 PM > [...] > > We haven't discussed how it fails when called on a group-opened device > in a mixed environment. I'd propose that the INFO ioctl behaves > exactly as it does today, reporting group-id and BDF for each affected > device. However, the hot-reset ioctl itself is not extended to accept > devicefd because there is no proof-of-ownership model for cdevs. > Therefore even if the user could map group-id to devicefd, they get > -EINVAL calling HOT_RESET with a devicefd when the ioctl is called from > a group-opened device. Thanks, Will it be better to let userspace know it shall fail if invoking hot reset due to no proof-of-ownership as it also has cdev devices? Maybe the RESETTABLE flag should always be meaningful. Even if the calling device of _INFO is group-opened device. Old user applications does not need to check it as it will never have such mixed environment. But for new applications or the applications that have been updated per latest vfio uapi, it should strictly check this flag before going ahead to do hot-reset. Regards, Yi Liu
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Make IRQ reset and postinstall multi-gt aware (rev7)
== Series Details ==
Series: drm/i915: Make IRQ reset and postinstall multi-gt aware (rev7)
URL : https://patchwork.freedesktop.org/series/115465/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13023_full -> Patchwork_115465v7_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (8 -> 7)
--
Missing(1): shard-rkl0
Known issues
Here are the changes found in Patchwork_115465v7_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_barrier_race@remote-request@rcs0:
- shard-glk: NOTRUN -> [ABORT][1] ([i915#8211])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-glk9/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_persistence@legacy-engines-hostile-preempt:
- shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) +5
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-hostile-preempt.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl: NOTRUN -> [FAIL][3] ([i915#2846])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-apl6/igt@gem_exec_f...@basic-deadline.html
* igt@gem_pread@exhaustion:
- shard-snb: NOTRUN -> [WARN][4] ([i915#2658])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-snb4/igt@gem_pr...@exhaustion.html
* igt@gem_userptr_blits@vma-merge:
- shard-snb: NOTRUN -> [FAIL][5] ([i915#2724])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-snb4/igt@gem_userptr_bl...@vma-merge.html
* igt@i915_suspend@forcewake:
- shard-apl: [PASS][6] -> [ABORT][7] ([i915#180])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/shard-apl4/igt@i915_susp...@forcewake.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-apl6/igt@i915_susp...@forcewake.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-90:
- shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271]) +70 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-apl6/igt@kms_big...@x-tiled-32bpp-rotate-90.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#3886])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-apl3/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#3886])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-glk5/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-snb: NOTRUN -> [SKIP][11] ([fdo#109271]) +556 similar
issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-snb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271]) +20 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-glk9/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#658]) +1
similar issue
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-apl3/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
* igt@kms_setmode@basic@pipe-a-vga-1:
- shard-snb: NOTRUN -> [FAIL][14] ([i915#5465]) +1 similar issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-snb6/igt@kms_setmode@ba...@pipe-a-vga-1.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][15] ([i915#7742]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/shard-rkl-7/igt@drm_fdinfo@i...@rcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-rkl-4/igt@drm_fdinfo@i...@rcs0.html
* igt@gem_barrier_race@remote-request@rcs0:
- shard-apl: [ABORT][17] ([i915#8211] / [i915#8234]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/shard-apl6/igt@gem_barrier_race@remote-requ...@rcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v7/shard-apl3/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-rkl}:[FAIL][19] ([i915#6268]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/shard-rkl-2/igt@gem_ctx_e...@basic-nohang
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Fix CP current state
> > > -Original Message- > > From: Kandpal, Suraj > > Sent: Wednesday, April 12, 2023 9:18 AM > > To: intel-gfx@lists.freedesktop.org > > Cc: Gupta, Anshuman ; Nautiyal, Ankit K > > ; Kandpal, Suraj > > Subject: [PATCH] drm/i915/hdcp: Fix CP current state > > > > In many cases there is a need to change the CP property to desired > > even if not modeset has been requested yet on such situation being lid > > gets closed while DP is still connected in this case HDCP > > authentication needs to be reenabled. > > Remove Fix me as we now send a uevent via drm_hdcp_update_property. > > > > Signed-off-by: Suraj Kandpal > > --- > > drivers/gpu/drm/i915/display/intel_hdcp.c | 7 ++- > > 1 file changed, 2 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c > > b/drivers/gpu/drm/i915/display/intel_hdcp.c > > index 650232c4892b..7b0648e3499c 100644 > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c > > @@ -2564,12 +2564,9 @@ void intel_hdcp_atomic_check(struct > > drm_connector *connector, > >new_state->crtc); > > /* > > * Fix the HDCP uapi content protection state in case of modeset. > > -* FIXME: As per HDCP content protection property uapi doc, an > > uevent() > > -* need to be sent if there is transition from ENABLED->DESIRED. > > */ > This comment was added because , we did not send uevent in > intel_hdcp_atomic_check() function as it is not possible. Yes but now we do it from update_pipe or when there is a call to update_property which schedules Propwork and there we call drm_hdcp_update_property which sends a uevent > > - if (drm_atomic_crtc_needs_modeset(crtc_state) && > > - (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED && > > - new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) > > + if ((old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED && > > +new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) > > new_state->content_protection = > > DRM_MODE_CONTENT_PROTECTION_DESIRED; > This is overkill, for every display flip there will be HDCP authentication? True we are trying to see some other fix for this but as of now only this seems to fix the issue Regards, Suraj Kandpal > Br, > Anshuman Gupta. > > > > -- > > 2.25.1
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On 17/04/2023 17:20, Christian König wrote:
Am 17.04.23 um 17:56 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Add support to dump GEM stats to fdinfo.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 12 +++
drivers/gpu/drm/drm_file.c | 52 +++
include/drm/drm_drv.h | 7
include/drm/drm_file.h | 8 +
4 files changed, 79 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index 2ab32c40e93c..8273a41b2fb0 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -21,6 +21,7 @@ File format specification
- File shall contain one key value pair per one line of text.
- Colon character (`:`) must be used to delimit keys and values.
+- Caret (`^`) is also a reserved character.
- All keys shall be prefixed with `drm-`.
- Whitespace between the delimiter and first non-whitespace
character shall be
ignored when parsing.
@@ -105,6 +106,17 @@ object belong to this client, in the respective
memory region.
Default unit shall be bytes with optional unit specifiers of 'KiB'
or 'MiB'
indicating kibi- or mebi-bytes.
+- drm-memory-^size: [KiB|MiB]
+- drm-memory-^shared: [KiB|MiB]
+- drm-memory-^resident: [KiB|MiB]
+- drm-memory-^purgeable: [KiB|MiB]
+- drm-memory-^active: [KiB|MiB]
What exactly does size/shared/active mean here?
If it means what I think it does I don't see how TTM based drivers
should track that in the first place.
Size is an analogue to process VM size - maximum reachable/allocated
memory belonging to a client.
Shared could be IMO viewed as a bit dodgy and either could be dropped or
needs to be better defined. For now I simply followed the implementation
from Rob's RFC which is:
if (obj->handle_count > 1)
stats[0].shared += sz;
I can see some usefulness to it but haven't thought much about semantics
yet.
Similar story with active which I think is not very useful.
Implementation is like this:
if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
stats[0].active += sz;
For me it is too transient to bring much value over the resident
category. I supposed only advantage is that resident (as does purgeable)
needs driver cooperation while active can be done like about from DRM
core. Although I am not a big fan of counting these stats from the core
to begin with..
Regards,
Tvrtko
+Resident category is identical to the drm-memory- key and two
should be
+mutually exclusive.
+
+TODO more description text...
+
- drm-cycles-
Engine identifier string must be the same as the one specified in the
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 37b4f76a5191..e202f79e816d 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev,
struct drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+static void
+print_stat(struct drm_printer *p, const char *stat, const char
*region, u64 sz)
+{
+ const char *units[] = {"", " KiB", " MiB"};
+ unsigned int u;
+
+ if (sz == ~0ull) /* Not supported by the driver. */
+ return;
+
+ for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
+ if (sz < SZ_1K)
+ break;
+ sz = div_u64(sz, SZ_1K);
+ }
+
+ drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
+ region, stat, sz, units[u]);
+}
+
+static void print_memory_stats(struct drm_printer *p, struct drm_file
*file)
+{
+ struct drm_device *dev = file->minor->dev;
+ struct drm_fdinfo_memory_stat *stats;
+ unsigned int num, i;
+ char **regions;
+
+ regions = dev->driver->query_fdinfo_memory_regions(dev, &num);
+
+ stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
+ if (!stats)
+ return;
+
+ dev->driver->query_fdinfo_memory_stats(file, stats);
+
+ for (i = 0; i < num; i++) {
+ if (!regions[i]) /* Allow sparse name arrays. */
+ continue;
+
+ print_stat(p, "size", regions[i], stats[i].size);
+ print_stat(p, "shared", regions[i], stats[i].shared);
+ print_stat(p, "resident", regions[i], stats[i].resident);
+ print_stat(p, "purgeable", regions[i], stats[i].purgeable);
+ print_stat(p, "active", regions[i], stats[i].active);
+ }
+
+ kfree(stats);
+}
+
/**
* drm_show_fdinfo - helper for drm file fops
* @seq_file: output stream
@@ -900,6 +949,9 @@ void drm_show_fdinfo(struct seq_file *m, struct
file *f)
if (dev->driver->show_fdinfo)
dev->driver->show_fdinfo(&p, file);
+
+ if (dev->driver->query_fdinfo_memory_regions)
+ print_memory_stats(&p, file);
}
EXPORT_SYMBOL(drm_show_fdinfo);
diff --git a/include/drm/drm_drv.h b/
[Intel-gfx] [PATCH v4] drm/i915/display: Increase AUX timeout for Type-C
Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
Workaround: Increase the timeout.
---v2
-change style on how we mention WA [Ankit]
-fix bat error by creating new func that is only called for aux power
well scenarios so we can avoid null pointer error as it is called
everywhere.
--v3
-Add non-default enable_timeout to power well descriptor which avoids
adding more platform checks [Imre]
--v4
-Remove Bspec link from top to bottom remove WA link from commit put it
on comment [Jani]
-enable_timeout in ms and add .fixed_enable_delay too [Imre]
Bspec: 55480
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display_power_map.c | 10 ++
.../gpu/drm/i915/display/intel_display_power_well.c| 3 ++-
.../gpu/drm/i915/display/intel_display_power_well.h| 2 ++
3 files changed, 14 insertions(+), 1 deletion(-)
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..b065f86f89c9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1385,6 +1385,16 @@ static const struct i915_power_well_desc
xelpd_power_wells_main[] = {
),
.ops = &icl_aux_power_well_ops,
.fixed_enable_delay = true,
+ }, {
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC1),
+ I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC2),
+ I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC3),
+ I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC4),
+ ),
+ .ops = &icl_aux_power_well_ops,
+ /* WA_14017248603: adlp */
+ .enable_timeout = 500,
}, {
.instances = &I915_PW_INSTANCES(
I915_PW("AUX_TBT1", &icl_pwdoms_aux_tbt1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TBT1),
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index 62bafcbc7937..930a42c825c3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -253,6 +253,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
{
const struct i915_power_well_regs *regs = power_well->desc->ops->regs;
int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
+ int timeout = power_well->desc->enable_timeout ? : 1;
/*
* For some power wells we're not supposed to watch the status bit for
@@ -266,7 +267,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
/* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
if (intel_de_wait_for_set(dev_priv, regs->driver,
- HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
+ HSW_PWR_WELL_CTL_STATE(pw_idx), timeout)) {
drm_dbg_kms(&dev_priv->drm, "%s power well enable timeout\n",
intel_power_well_name(power_well));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
b/drivers/gpu/drm/i915/display/intel_display_power_well.h
index ba7cb977e7c7..e494df379e6c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
@@ -110,6 +110,8 @@ struct i915_power_well_desc {
* Thunderbolt mode.
*/
u16 is_tc_tbt:1;
+ /* Enable timeout if greater than the default 1ms */
+ u16 enable_timeout;
};
struct i915_power_well {
--
2.25.1
[Intel-gfx] [PATCH v4] drm/i915/display: Increase AUX timeout for Type-C
Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
Workaround: Increase the timeout.
---v2
-change style on how we mention WA [Ankit]
-fix bat error by creating new func that is only called for aux power
well scenarios so we can avoid null pointer error as it is called
everywhere.
--v3
-Add non-default enable_timeout to power well descriptor which avoids
adding more platform checks [Imre]
--v4
-Remove Bspec link from top to bottom remove WA link from commit put it
on comment [Jani]
-enable_timeout in ms and add .fixed_enable_delay too [Imre]
Bspec: 55480
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Suraj Kandpal
---
.../gpu/drm/i915/display/intel_display_power_map.c| 11 +++
.../gpu/drm/i915/display/intel_display_power_well.c | 3 ++-
.../gpu/drm/i915/display/intel_display_power_well.h | 2 ++
3 files changed, 15 insertions(+), 1 deletion(-)
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..f0d51a30430a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1385,6 +1385,17 @@ static const struct i915_power_well_desc
xelpd_power_wells_main[] = {
),
.ops = &icl_aux_power_well_ops,
.fixed_enable_delay = true,
+ }, {
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC1),
+ I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC2),
+ I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC3),
+ I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC4),
+ ),
+ .ops = &icl_aux_power_well_ops,
+ .fixed_enable_delay = true,
+ /* WA_14017248603: adlp */
+ .enable_timeout = 500,
}, {
.instances = &I915_PW_INSTANCES(
I915_PW("AUX_TBT1", &icl_pwdoms_aux_tbt1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TBT1),
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index 62bafcbc7937..930a42c825c3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -253,6 +253,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
{
const struct i915_power_well_regs *regs = power_well->desc->ops->regs;
int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
+ int timeout = power_well->desc->enable_timeout ? : 1;
/*
* For some power wells we're not supposed to watch the status bit for
@@ -266,7 +267,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
/* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
if (intel_de_wait_for_set(dev_priv, regs->driver,
- HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
+ HSW_PWR_WELL_CTL_STATE(pw_idx), timeout)) {
drm_dbg_kms(&dev_priv->drm, "%s power well enable timeout\n",
intel_power_well_name(power_well));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
b/drivers/gpu/drm/i915/display/intel_display_power_well.h
index ba7cb977e7c7..e494df379e6c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
@@ -110,6 +110,8 @@ struct i915_power_well_desc {
* Thunderbolt mode.
*/
u16 is_tc_tbt:1;
+ /* Enable timeout if greater than the default 1ms */
+ u16 enable_timeout;
};
struct i915_power_well {
--
2.25.1
Re: [Intel-gfx] [PATCH] drm/i915/hdcp: Fix CP current state
> -Original Message- > From: Kandpal, Suraj > Sent: Tuesday, April 18, 2023 4:16 PM > To: Gupta, Anshuman ; intel- > g...@lists.freedesktop.org > Cc: Nautiyal, Ankit K ; Shankar, Uma > > Subject: RE: [PATCH] drm/i915/hdcp: Fix CP current state > > > > > > -Original Message- > > > From: Kandpal, Suraj > > > Sent: Wednesday, April 12, 2023 9:18 AM > > > To: intel-gfx@lists.freedesktop.org > > > Cc: Gupta, Anshuman ; Nautiyal, Ankit K > > > ; Kandpal, Suraj > > > > > > Subject: [PATCH] drm/i915/hdcp: Fix CP current state > > > > > > In many cases there is a need to change the CP property to desired > > > even if not modeset has been requested yet on such situation being > > > lid gets closed while DP is still connected in this case HDCP > > > authentication needs to be reenabled. > > > Remove Fix me as we now send a uevent via > drm_hdcp_update_property. > > > > > > Signed-off-by: Suraj Kandpal > > > --- > > > drivers/gpu/drm/i915/display/intel_hdcp.c | 7 ++- > > > 1 file changed, 2 insertions(+), 5 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_hdcp.c > > > b/drivers/gpu/drm/i915/display/intel_hdcp.c > > > index 650232c4892b..7b0648e3499c 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_hdcp.c > > > +++ b/drivers/gpu/drm/i915/display/intel_hdcp.c > > > @@ -2564,12 +2564,9 @@ void intel_hdcp_atomic_check(struct > > > drm_connector *connector, > > > new_state->crtc); > > > /* > > >* Fix the HDCP uapi content protection state in case of modeset. > > > - * FIXME: As per HDCP content protection property uapi doc, an > > > uevent() > > > - * need to be sent if there is transition from ENABLED->DESIRED. > > >*/ > > This comment was added because , we did not send uevent in > > intel_hdcp_atomic_check() function as it is not possible. > > Yes but now we do it from update_pipe or when there is a call to > update_property which schedules Propwork and there we call > drm_hdcp_update_property which sends a uevent > > > > - if (drm_atomic_crtc_needs_modeset(crtc_state) && > > > - (old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED && > > > - new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) > > > + if ((old_cp == DRM_MODE_CONTENT_PROTECTION_ENABLED && > > > + new_cp != DRM_MODE_CONTENT_PROTECTION_UNDESIRED)) > > > new_state->content_protection = > > > DRM_MODE_CONTENT_PROTECTION_DESIRED; > > This is overkill, for every display flip there will be HDCP authentication? > > True we are trying to see some other fix for this but as of now only this > seems to fix the issue Please get a Ack from atomic commit POV, this impacts the display flip path and hdcp calls to content protection firmware may take longer time in display flips, have you tested it with higher refresh rate panels ? Br, Anshuman Gupta. > > Regards, > Suraj Kandpal > > Br, > > Anshuman Gupta. > > > > > > -- > > > 2.25.1
Re: [Intel-gfx] [PATCH v4] drm/i915/display: Increase AUX timeout for Type-C
On Tue, Apr 18, 2023 at 04:24:54PM +0530, Suraj Kandpal wrote:
> Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
> Workaround: Increase the timeout.
>
> ---v2
> -change style on how we mention WA [Ankit]
> -fix bat error by creating new func that is only called for aux power
> well scenarios so we can avoid null pointer error as it is called
> everywhere.
>
> --v3
> -Add non-default enable_timeout to power well descriptor which avoids
> adding more platform checks [Imre]
>
> --v4
> -Remove Bspec link from top to bottom remove WA link from commit put it
> on comment [Jani]
> -enable_timeout in ms and add .fixed_enable_delay too [Imre]
>
> Bspec: 55480
>
> Cc: Jani Nikula
> Cc: Imre Deak
> Signed-off-by: Suraj Kandpal
> ---
> .../gpu/drm/i915/display/intel_display_power_map.c| 11 +++
> .../gpu/drm/i915/display/intel_display_power_well.c | 3 ++-
> .../gpu/drm/i915/display/intel_display_power_well.h | 2 ++
> 3 files changed, 15 insertions(+), 1 deletion(-)
>
> 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..f0d51a30430a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> @@ -1385,6 +1385,17 @@ static const struct i915_power_well_desc
> xelpd_power_wells_main[] = {
> ),
> .ops = &icl_aux_power_well_ops,
> .fixed_enable_delay = true,
> + }, {
> + .instances = &I915_PW_INSTANCES(
> + I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC1),
> + I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC2),
> + I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC3),
> + I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TC4),
> + ),
Instead of duplicating the above 4 power wells the change should move
them to this group, as in the diff I provided.
> + .ops = &icl_aux_power_well_ops,
> + .fixed_enable_delay = true,
> + /* WA_14017248603: adlp */
> + .enable_timeout = 500,
> }, {
> .instances = &I915_PW_INSTANCES(
> I915_PW("AUX_TBT1", &icl_pwdoms_aux_tbt1, .hsw.idx =
> TGL_PW_CTL_IDX_AUX_TBT1),
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> index 62bafcbc7937..930a42c825c3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> @@ -253,6 +253,7 @@ static void hsw_wait_for_power_well_enable(struct
> drm_i915_private *dev_priv,
> {
> const struct i915_power_well_regs *regs = power_well->desc->ops->regs;
> int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> + int timeout = power_well->desc->enable_timeout ? : 1;
>
> /*
>* For some power wells we're not supposed to watch the status bit for
> @@ -266,7 +267,7 @@ static void hsw_wait_for_power_well_enable(struct
> drm_i915_private *dev_priv,
>
> /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> if (intel_de_wait_for_set(dev_priv, regs->driver,
> - HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
> + HSW_PWR_WELL_CTL_STATE(pw_idx), timeout)) {
> drm_dbg_kms(&dev_priv->drm, "%s power well enable timeout\n",
> intel_power_well_name(power_well));
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> index ba7cb977e7c7..e494df379e6c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
> @@ -110,6 +110,8 @@ struct i915_power_well_desc {
>* Thunderbolt mode.
>*/
> u16 is_tc_tbt:1;
> + /* Enable timeout if greater than the default 1ms */
> + u16 enable_timeout;
> };
>
> struct i915_power_well {
> --
> 2.25.1
>
[Intel-gfx] ✓ Fi.CI.IGT: success for Handle dma fences in dirtyfb ioctl
== Series Details ==
Series: Handle dma fences in dirtyfb ioctl
URL : https://patchwork.freedesktop.org/series/116620/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13023_full -> Patchwork_116620v1_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_116620v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@suspend:
- {shard-dg1}:[PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/shard-dg1-18/igt@gem_...@suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-dg1-16/igt@gem_...@suspend.html
Known issues
Here are the changes found in Patchwork_116620v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@engines-queued:
- shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#1099]) +8
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-snb1/igt@gem_ctx_persiste...@engines-queued.html
* igt@gem_eio@unwedge-stress:
- shard-snb: NOTRUN -> [FAIL][4] ([i915#3354])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-snb1/igt@gem_...@unwedge-stress.html
* igt@gem_exec_fair@basic-deadline:
- shard-apl: NOTRUN -> [FAIL][5] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-apl7/igt@gem_exec_f...@basic-deadline.html
* igt@gem_pread@exhaustion:
- shard-snb: NOTRUN -> [WARN][6] ([i915#2658])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-snb2/igt@gem_pr...@exhaustion.html
* igt@gem_userptr_blits@vma-merge:
- shard-snb: NOTRUN -> [FAIL][7] ([i915#2724])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-snb5/igt@gem_userptr_bl...@vma-merge.html
* igt@i915_selftest@live@gt_heartbeat:
- shard-glk: [PASS][8] -> [DMESG-FAIL][9] ([i915#5334])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13023/shard-glk7/igt@i915_selftest@live@gt_heartbeat.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-glk6/igt@i915_selftest@live@gt_heartbeat.html
* igt@kms_big_fb@x-tiled-32bpp-rotate-90:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271]) +70 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-apl7/igt@kms_big...@x-tiled-32bpp-rotate-90.html
* igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#3886])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-apl6/igt@kms_ccs@pipe-a-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs.html
* igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#3886]) +1
similar issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-glk8/igt@kms_ccs@pipe-c-random-ccs-data-y_tiled_gen12_mc_ccs.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc:
- shard-snb: NOTRUN -> [SKIP][13] ([fdo#109271]) +702 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-snb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-mmap-wc.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc:
- shard-glk: NOTRUN -> [SKIP][14] ([fdo#109271]) +42 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-glk1/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-spr-indfb-draw-mmap-wc.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-sf:
- shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#658]) +1
similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-apl6/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
- shard-glk: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#658])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-glk1/igt@kms_psr2...@overlay-plane-move-continuous-sf.html
* igt@kms_setmode@basic@pipe-a-vga-1:
- shard-snb: NOTRUN -> [FAIL][17] ([i915#5465]) +1 similar issue
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116620v1/shard-snb7/igt@kms_setmode@ba...@pipe-a-vga-1.html
Possible fixes
* igt@drm_fdinfo@most-busy-check-all@rcs0:
- {shard-rkl}:[FAIL][18] ([i915#7742]) -> [PASS][19]
[18]:
https://intel-
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/dp_mst: Clear MSG_RDY flag before sending new message (rev2)
== Series Details == Series: drm/dp_mst: Clear MSG_RDY flag before sending new message (rev2) URL : https://patchwork.freedesktop.org/series/116623/ State : success == Summary == CI Bug Log - changes from CI_DRM_13025 -> Patchwork_116623v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/index.html Participating hosts (37 -> 37) -- Additional (1): bat-adlm-1 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116623v2 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlm-1: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@eof: - bat-adlm-1: NOTRUN -> [SKIP][2] ([i915#2582]) +4 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@fb...@eof.html * igt@gem_exec_suspend@basic-s0@smem: - bat-rpls-2: NOTRUN -> [ABORT][3] ([i915#6687]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-rpls-2/igt@gem_exec_suspend@basic...@smem.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-adlm-1: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#3282]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-adlm-1: NOTRUN -> [SKIP][6] ([i915#7561]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@mman: - bat-rpls-2: [PASS][7] -> [TIMEOUT][8] ([i915#6794]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/bat-rpls-2/igt@i915_selftest@l...@mman.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-rpls-2/igt@i915_selftest@l...@mman.html * igt@kms_chamelium_frames@dp-crc-fast: - bat-adlm-1: NOTRUN -> [SKIP][9] ([i915#7828]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@kms_chamelium_fra...@dp-crc-fast.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-jsl-1: NOTRUN -> [SKIP][10] ([i915#7828]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-jsl-1/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-rpls-1: NOTRUN -> [SKIP][11] ([i915#7828]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size: - bat-adlm-1: NOTRUN -> [SKIP][12] ([i915#1845]) +15 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-varying-size.html * igt@kms_flip@basic-flip-vs-wf_vblank@c-hdmi-a2: - fi-bsw-n3050: [PASS][13] -> [FAIL][14] ([i915#2122]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/fi-bsw-n3050/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/fi-bsw-n3050/igt@kms_flip@basic-flip-vs-wf_vbl...@c-hdmi-a2.html * igt@kms_flip@basic-plain-flip: - bat-adlm-1: NOTRUN -> [SKIP][15] ([i915#3637]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@kms_f...@basic-plain-flip.html * igt@kms_force_connector_basic@force-load-detect: - bat-adlm-1: NOTRUN -> [SKIP][16] ([fdo#109285]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - bat-adlm-1: NOTRUN -> [SKIP][17] ([i915#1849]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@kms_frontbuffer_track...@basic.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-1: NOTRUN -> [SKIP][18] ([i915#1845]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html * igt@kms_psr@cursor_plane_move: - bat-adlm-1: NOTRUN -> [SKIP][19] ([i915#1072]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/bat-adlm-1/igt@kms_psr@cursor_plane_move.html * igt@kms_setmode@basic-clone-single-crtc: - bat-adlm-1: NOTRUN -> [SKIP][20] ([i915#3555]) [20]
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Increase AUX timeout for Type-C (rev6)
== Series Details ==
Series: drm/i915/display: Increase AUX timeout for Type-C (rev6)
URL : https://patchwork.freedesktop.org/series/116010/
State : warning
== Summary ==
Error: dim checkpatch failed
3f84391d7543 drm/i915/display: Increase AUX timeout for Type-C
-:39: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#39: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1389:
+ .instances = &I915_PW_INSTANCES(
-:40: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#40: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1390:
+ I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC1),
-:41: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#41: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1391:
+ I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC2),
-:42: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#42: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1392:
+ I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC3),
-:43: WARNING:LONG_LINE: line length of 103 exceeds 100 columns
#43: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1393:
+ I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC4),
total: 0 errors, 4 warnings, 1 checks, 40 lines checked
Re: [Intel-gfx] [PATCH v4] drm/i915/display: Increase AUX timeout for Type-C
> -Original Message-
> From: Deak, Imre
> Sent: Tuesday, April 18, 2023 4:34 PM
> To: Kandpal, Suraj
> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> Subject: Re: [PATCH v4] drm/i915/display: Increase AUX timeout for Type-C
>
> On Tue, Apr 18, 2023 at 04:24:54PM +0530, Suraj Kandpal wrote:
> > Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
> > Workaround: Increase the timeout.
> >
> > ---v2
> > -change style on how we mention WA [Ankit] -fix bat error by creating
> > new func that is only called for aux power well scenarios so we can
> > avoid null pointer error as it is called everywhere.
> >
> > --v3
> > -Add non-default enable_timeout to power well descriptor which avoids
> > adding more platform checks [Imre]
> >
> > --v4
> > -Remove Bspec link from top to bottom remove WA link from commit put
> > it on comment [Jani] -enable_timeout in ms and add .fixed_enable_delay
> > too [Imre]
> >
> > Bspec: 55480
> >
> > Cc: Jani Nikula
> > Cc: Imre Deak
> > Signed-off-by: Suraj Kandpal
> > ---
> > .../gpu/drm/i915/display/intel_display_power_map.c| 11 +++
> > .../gpu/drm/i915/display/intel_display_power_well.c | 3 ++-
> > .../gpu/drm/i915/display/intel_display_power_well.h | 2 ++
> > 3 files changed, 15 insertions(+), 1 deletion(-)
> >
> > 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..f0d51a30430a 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > @@ -1385,6 +1385,17 @@ static const struct i915_power_well_desc
> xelpd_power_wells_main[] = {
> > ),
> > .ops = &icl_aux_power_well_ops,
> > .fixed_enable_delay = true,
> > + }, {
> > + .instances = &I915_PW_INSTANCES(
> > + I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1,
> .hsw.idx = TGL_PW_CTL_IDX_AUX_TC1),
> > + I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2,
> .hsw.idx = TGL_PW_CTL_IDX_AUX_TC2),
> > + I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3,
> .hsw.idx = TGL_PW_CTL_IDX_AUX_TC3),
> > + I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4,
> .hsw.idx = TGL_PW_CTL_IDX_AUX_TC4),
> > + ),
>
> Instead of duplicating the above 4 power wells the change should move them
> to this group, as in the diff I provided.
>
You mean add the enable timeout in this instance itself
{
.instances = &I915_PW_INSTANCES(
I915_PW("AUX_A", &icl_pwdoms_aux_a, .hsw.idx =
ICL_PW_CTL_IDX_AUX_A),
I915_PW("AUX_B", &icl_pwdoms_aux_b, .hsw.idx =
ICL_PW_CTL_IDX_AUX_B),
I915_PW("AUX_C", &icl_pwdoms_aux_c, .hsw.idx =
ICL_PW_CTL_IDX_AUX_C),
I915_PW("AUX_D", &icl_pwdoms_aux_d, .hsw.idx =
XELPD_PW_CTL_IDX_AUX_D),
I915_PW("AUX_E", &icl_pwdoms_aux_e, .hsw.idx =
XELPD_PW_CTL_IDX_AUX_E),
I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC1),
I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC2),
I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC3),
I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC4),
),
.ops = &icl_aux_power_well_ops,
.fixed_enable_delay = true,
},
Regards,
Suraj Kandpal
> > + .ops = &icl_aux_power_well_ops,
> > + .fixed_enable_delay = true,
> > + /* WA_14017248603: adlp */
> > + .enable_timeout = 500,
> > }, {
> > .instances = &I915_PW_INSTANCES(
> > I915_PW("AUX_TBT1", &icl_pwdoms_aux_tbt1,
> .hsw.idx =
> > TGL_PW_CTL_IDX_AUX_TBT1), diff --git
> > a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > index 62bafcbc7937..930a42c825c3 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> > @@ -253,6 +253,7 @@ static void
> hsw_wait_for_power_well_enable(struct
> > drm_i915_private *dev_priv, {
> > const struct i915_power_well_regs *regs = power_well->desc->ops-
> >regs;
> > int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
> > + int timeout = power_well->desc->enable_timeout ? : 1;
> >
> > /*
> > * For some power wells we're not supposed to watch the status bit
> > for @@ -266,7 +267,7 @@ static void
> > hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
> >
> > /* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
> > if (intel_de_wait_for_set(dev_priv, regs->driver,
> > - HSW_PWR_WELL_CTL_STATE(pw_idx
Re: [Intel-gfx] [PATCH v1 2/4] drm/i915: update the QGV point frequency calculations
On Tue, Apr 18, 2023 at 12:47:33PM +0300, Govindapillai, Vinod wrote: > On Tue, 2023-04-18 at 12:25 +0300, Lisovskiy, Stanislav wrote: > > On Sun, Apr 16, 2023 at 06:54:15PM +0300, Vinod Govindapillai wrote: > > > From MTL onwwards, pcode locks the QGV point based on peak BW of > > > the intended QGV point passed by the driver. So the peak BW > > > calculation must match the value expected by the pcode. Update > > > the calculations as per the Bspec. > > > > > > Bspec: 64636 > > > > > > Signed-off-by: Vinod Govindapillai > > > --- > > > drivers/gpu/drm/i915/display/intel_bw.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c > > > b/drivers/gpu/drm/i915/display/intel_bw.c > > > index 5fa599b04ca5..57f8204162dd 100644 > > > --- a/drivers/gpu/drm/i915/display/intel_bw.c > > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c > > > @@ -179,7 +179,7 @@ static int mtl_read_qgv_point_info(struct > > > drm_i915_private *dev_priv, > > > val2 = intel_uncore_read(&dev_priv->uncore, > > > MTL_MEM_SS_INFO_QGV_POINT_HIGH(point)); > > > dclk = REG_FIELD_GET(MTL_DCLK_MASK, val); > > > - sp->dclk = DIV_ROUND_UP((16667 * dclk), 1000); > > > + sp->dclk = (16667 * dclk + 500) / 1000; > > > > Hmm, wonder does it at least partly now intersects with what I'm doing in > > https://patchwork.freedesktop.org/series/114982/ > > > > I remember we were discussing if this "+500" is actually also rounding up > > itself. > > > > The thing is that the way how rounding up is done for instance in > > DIV_ROUND_UP > > also, if you check, if you lets say want to divide n by d, however you want > > to round > > up the result, you add n = n + (d - 1) and then divide by d. This is how > > DIV_ROUND_UP works. > > That effectively means that if n would be anything more than m*d, result > > would be not m, > > but m + 1(note flooring would give m) > > > > Adding 500, when dividing by 1000 is also rouding up, however it is a bit > > weaker. > > In example above that would mean, if we want to divide n by d, we first add > > n = n + d / 2 > > and then divide by d. > > That effectively means that if n would be anything more than m*d + 500, > > result would not m, > > but again m + 1(again note, that true flooeing would have given m, not m + > > 1) > > > > So it is still rounding up, but just being weaker/less precise though. > > > > If we would want to truly floor that division, we would want to get m, but > > not m + 1 from > > above examples, which means that we should just divide n / d, without > > adding anything. > > So in my opinion, if we want to floor (16667 * dclk / 1000) result - it > > should not have > > both "DIV_ROUND_UP" and " + 500" things - thats what I've done in series > > which also was touching > > this code as well. > > > > I think it would be nice to raise issue and clarify from HW team, if it was > > initial intention, > > because adding + 500 is clearly doing rounding up as well, but it is just > > now on +-500(d/2) > > granularity now, > > while DIV_ROUND_UP worked with +-1 granularity. However both things are > > essentially "rounding up". > > So in that case I would really want to challenge or clarify, what is > > written in BSpec. > > > > Stan > > Yes. Not much explanation about the addition of 500. I just blindly followed > what was in that Bspec. > Yes ideally div round_up is (n + d -1) / d. So what is the point of having > 500 if the purpose is a > rounding up unless it is accounting for some "other" factor. Anyway it is > nice to get the > clarification. > > So the "other" factor I assume is that pcode is using this formula to > calculate QGV point peak BW. > So in MTL as we pass this peak BW to pcode for compare and select the QGV > point, driver and pcode > calculations need to match. Adding 500 here, essnetially means we get +1 to sp->dclk, whenever dclk has some reminder of that division which is >= 500. So kinda unclear: we are being instructed now to "floor" "rounded up" calculations! :)) So we are now doing something between flooring and DIV_ROUND_UP for sp->dclk * 16667 / 1000. What makes me think that there is some contradiction, or might be there is some hardware factor, which works with 500 granularity, so that it makes sense to round up only if delta is >= 500, otherwise floor. Stan > > BR > Vinod > > > > > sp->t_rp = REG_FIELD_GET(MTL_TRP_MASK, val); > > > sp->t_rcd = REG_FIELD_GET(MTL_TRCD_MASK, val); > > > > > > -- > > > 2.34.1 > > > >
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Increase AUX timeout for Type-C (rev6)
== Series Details == Series: drm/i915/display: Increase AUX timeout for Type-C (rev6) URL : https://patchwork.freedesktop.org/series/116010/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13025 -> Patchwork_116010v6 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_116010v6 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_116010v6, 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_116010v6/index.html Participating hosts (37 -> 38) -- Additional (2): fi-kbl-soraka bat-adlm-1 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_116010v6: ### IGT changes ### Possible regressions * igt@dmabuf@all-tests@dma_fence: - bat-adls-5: [PASS][1] -> [DMESG-FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/bat-adls-5/igt@dmabuf@all-tests@dma_fence.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/bat-adls-5/igt@dmabuf@all-tests@dma_fence.html * igt@dmabuf@all-tests@sanitycheck: - bat-adls-5: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/bat-adls-5/igt@dmabuf@all-te...@sanitycheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/bat-adls-5/igt@dmabuf@all-te...@sanitycheck.html Known issues Here are the changes found in Patchwork_116010v6 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adlm-1: NOTRUN -> [SKIP][5] ([i915#7456]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/bat-adlm-1/igt@debugfs_t...@basic-hwmon.html * igt@fbdev@eof: - bat-adlm-1: NOTRUN -> [SKIP][6] ([i915#2582]) +4 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/bat-adlm-1/igt@fb...@eof.html * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +3 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - bat-adlm-1: NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/bat-adlm-1/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - bat-adlm-1: NOTRUN -> [SKIP][10] ([i915#3282]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/bat-adlm-1/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - bat-adlm-1: NOTRUN -> [SKIP][11] ([i915#7561]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/bat-adlm-1/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][12] ([i915#1886]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@i915_selftest@live@hangcheck: - fi-skl-guc: [PASS][13] -> [DMESG-WARN][14] ([i915#8073]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/fi-skl-guc/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@requests: - bat-rpls-1: [PASS][15] -> [ABORT][16] ([i915#4983] / [i915#7911]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/bat-rpls-1/igt@i915_selftest@l...@requests.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/bat-rpls-1/igt@i915_selftest@l...@requests.html * igt@kms_chamelium_frames@dp-crc-fast: - bat-adlm-1: NOTRUN -> [SKIP][17] ([i915#7828]) +8 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/bat-adlm-1/igt@kms_chamelium_fra...@dp-crc-fast.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][18] ([fdo#109271]) +16 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v6/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][19] ([i915#7828]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Pat
Re: [Intel-gfx] [PATCH v4] drm/i915/display: Increase AUX timeout for Type-C
On Tue, Apr 18, 2023 at 02:45:27PM +0300, Kandpal, Suraj wrote:
> [...]
> > > 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..f0d51a30430a 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
> > > @@ -1385,6 +1385,17 @@ static const struct i915_power_well_desc
> > xelpd_power_wells_main[] = {
> > > ),
> > > .ops = &icl_aux_power_well_ops,
> > > .fixed_enable_delay = true,
> > > + }, {
> > > + .instances = &I915_PW_INSTANCES(
> > > + I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx
> > > = TGL_PW_CTL_IDX_AUX_TC1),
> > > + I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx
> > > = TGL_PW_CTL_IDX_AUX_TC2),
> > > + I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx
> > > = TGL_PW_CTL_IDX_AUX_TC3),
> > > + I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx
> > > = TGL_PW_CTL_IDX_AUX_TC4),
> > > + ),
> >
> > Instead of duplicating the above 4 power wells the change should move them
> > to this group, as in the diff I provided.
>
> You mean add the enable timeout in this instance itself
No, I meant moving the TC AUX power wells to a new group, as in the diff
I provided earlier. Attached is the updated patch.
>
> {
> .instances = &I915_PW_INSTANCES(
> I915_PW("AUX_A", &icl_pwdoms_aux_a, .hsw.idx =
> ICL_PW_CTL_IDX_AUX_A),
> I915_PW("AUX_B", &icl_pwdoms_aux_b, .hsw.idx =
> ICL_PW_CTL_IDX_AUX_B),
> I915_PW("AUX_C", &icl_pwdoms_aux_c, .hsw.idx =
> ICL_PW_CTL_IDX_AUX_C),
> I915_PW("AUX_D", &icl_pwdoms_aux_d, .hsw.idx =
> XELPD_PW_CTL_IDX_AUX_D),
> I915_PW("AUX_E", &icl_pwdoms_aux_e, .hsw.idx =
> XELPD_PW_CTL_IDX_AUX_E),
> I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx
> = TGL_PW_CTL_IDX_AUX_TC1),
> I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx
> = TGL_PW_CTL_IDX_AUX_TC2),
> I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx
> = TGL_PW_CTL_IDX_AUX_TC3),
> I915_PW("AUX_USBC4", &tgl_pwdoms_aux_usbc4, .hsw.idx
> = TGL_PW_CTL_IDX_AUX_TC4),
> ),
> .ops = &icl_aux_power_well_ops,
> .fixed_enable_delay = true,
> },
>
> Regards,
> Suraj Kandpal
> > > + .ops = &icl_aux_power_well_ops,
> > > + .fixed_enable_delay = true,
> > > + /* WA_14017248603: adlp */
> > > + .enable_timeout = 500,
> > > }, {
> > > .instances = &I915_PW_INSTANCES(
> > > I915_PW("AUX_TBT1", &icl_pwdoms_aux_tbt1,
>From 9408a63e59e513d71acdda81e58609c4c6d543aa Mon Sep 17 00:00:00 2001
From: Suraj Kandpal
Date: Tue, 18 Apr 2023 16:22:07 +0530
Subject: [PATCH] drm/i915/display: Increase AUX timeout for Type-C
Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
Workaround: Increase the timeout.
---v2
-change style on how we mention WA [Ankit]
-fix bat error by creating new func that is only called for aux power
well scenarios so we can avoid null pointer error as it is called
everywhere.
--v3
-Add non-default enable_timeout to power well descriptor which avoids
adding more platform checks [Imre]
--v4
-Remove Bspec link from top to bottom remove WA link from commit put it
on comment [Jani]
-enable_timeout in ms and add .fixed_enable_delay too [Imre]
Bspec: 55480
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display_power_map.c | 7 +++
drivers/gpu/drm/i915/display/intel_display_power_well.c | 3 ++-
drivers/gpu/drm/i915/display/intel_display_power_well.h | 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
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 6645eb1911d85..b4070845cd536 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1378,6 +1378,11 @@ static const struct i915_power_well_desc xelpd_power_wells_main[] = {
I915_PW("AUX_C", &icl_pwdoms_aux_c, .hsw.idx = ICL_PW_CTL_IDX_AUX_C),
I915_PW("AUX_D", &icl_pwdoms_aux_d, .hsw.idx = XELPD_PW_CTL_IDX_AUX_D),
I915_PW("AUX_E", &icl_pwdoms_aux_e, .hsw.idx = XELPD_PW_CTL_IDX_AUX_E),
+ ),
+ .ops = &icl_aux_power_well_ops,
+ .fixed_enable_delay = true,
+ }, {
+ .instances = &I915_PW_INSTANCES(
I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx = TGL_PW_CTL_IDX_AUX_TC1),
I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx = TGL_PW_CTL_IDX_AUX_TC2),
I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx = TGL_PW_CTL_IDX_A
Re: [Intel-gfx] [PATCH] drm/i915/display: Return correct err code for bpc < 0
On Mon, Apr 17, 2023 at 03:48:12PM -0700, Manasi Navare wrote: > Hi Ville, > > Could you suggest how to handle the intel_dp_link_compute_config() > when the max_bpp is returned as 0, currently > it just exits the loop and returns a -EINVAL and this triggers the DSC path. > While we should be completely failing the modeset and encoder_config > in this case instead of trying DSC, correct? The DSC path needs to handle the bpp limits correctly: 1. Take the baseline limits already computed 2. Further restrict them based on sink/source DSC capabilities/etc. 3. Make sure the uncompressed bpp value chosen is between the min/max > > Manasi > > On Thu, Apr 13, 2023 at 8:23 AM Manasi Navare > wrote: > > > > On Tue, Apr 11, 2023 at 10:22 PM Ville Syrjälä > > wrote: > > > > > > On Tue, Apr 11, 2023 at 05:07:01PM -0700, Manasi Navare wrote: > > > > On Tue, Apr 11, 2023 at 10:42 AM Ville Syrjälä > > > > wrote: > > > > > > > > > > On Tue, Apr 11, 2023 at 05:34:08PM +, Manasi Navare wrote: > > > > > > In the function intel_dp_max_bpp(), currently if bpc < 0 in case of > > > > > > error, > > > > > > we return 0 instead of returning an err code of -EINVAL. > > > > > > This throws off the logic in the calling function. > > > > > > > > > > What logic? The caller doesn't expect to get an error. > > > > > > > > If this returns a 0, we end up using limits.max_bpp = 0 and in > > > > intel_dp_compute_link_config_wide(), > > > > since max_bpp is 0, it exits this for loop: > > > > > > > > for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) and > > > > returns > > > > -EINVAL which then wrongly goes to enable DSC even when link BW is > > > > sufficient without DSC. > > > > > > And how woud max_bpp<0 prevent that? > > > > > > The real problem seems to be that the DSC code totally > > > ignores bpp limits. > > > > Hi Ville, > > > > So I see a few concerns/questions: > > - Why is the Max bpp value 0 in intel_dp_max_bpp, is that a valid case > > and how should our link configurations handle that case when max_bpp > > is 0? > > - This is happening in a bug I am looking at with HDMI PCON, @Ankit > > Nautiyal have we ever seen something similar where max_bpp for HDMi > > PCON > > is returned 0? > > - I dont think its a problem with DSC code, but rather > > intel_dp_compute_link_config() outer for loop where we vary > > from max_bpp to min_bpp and see if any bpp works with available link > > bw, how should we handle this when max_bpp = 0 if you are saying thats > > a valid case? > > - In this patch if I return -EINVAL instead of 0, then atleast the > > entire encoder_config will fail and that will fail the modeset, since > > it assumes max_bpp cannot be 0 > > > > Could you please help answer above concerns and how to handle max bpp > > = 0 case if that is valid? This patch is simply making that invalid > > resulting into modeset failure > > > > Manasi > > > > > > -- > > > Ville Syrjälä > > > Intel -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Mon, Apr 17, 2023 at 02:06:42PM -0600, Alex Williamson wrote:
> On Mon, 17 Apr 2023 16:31:56 -0300
> Jason Gunthorpe wrote:
>
> > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > mixing groups, cdevs, and multiple iommufd_ctxs as invalid. I think
> > > this means that regardless of which device calls INFO, there's only one
> > > answer (assuming same set of devices opened, all cdev, all within same
> > > iommufd_ctx). Based on what I explained about my understanding of INFO2
> > > and Jason agreed to, I think the output would be:
> > >
> > > flags: NOT_RESETABLE | DEV_ID
> > > {
> > > { valid devA-id, devA-BDF },
> > > { valid devC-id, devC-BDF },
> > > { valid devD-id, devD-BDF },
> > > { invalid dev-id, devE-BDF },
> > > }
> > >
> > > Here devB gets dropped because the kernel understands that devB is
> > > unopened, affected, and owned. It's therefore not a blocker for
> > > hot-reset.
> >
> > I don't think we want to drop anything because it makes the API
> > ill suited for the debugging purpose.
> >
> > devb should be returned with an invalid dev_id if I understand your
> > example. Maybe it should return with -1 as the dev_id instead of 0, to
> > make the debugging a bit better.
> >
> > Userspace should look at only NOT_RESETTABLE to determine if it
> > proceeds or not, and it should use the valid dev_id list to iterate
> > over the devices it has open to do the config stuff.
>
> If an affected device is owned, not opened, and not interfering with
> the reset, what is it adding to the API to report it for debugging
> purposes?
It lets it print the entire group of devices, this is the only way
something can learn the actual list of all BDFs affected.
dev_id can just return 0, we don't need a complex bitmap. Userspace
looks at the flag, if !NOT_RESETABLE then it ignores dev_id=0.
Jason
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Tue, Apr 18, 2023 at 05:02:44AM +, Tian, Kevin wrote: > Yes I chatted with Yi about it. > > If the calling device of the INFO ioctl is opened by group then behave > as it does today. > > If the calling device is opened via cdev then use dev_id scheme as > discussed above. > > in hot_reset ioctl the fd array only accepts group fd's. > > cdev can be reset only via null fd array. Agree > It remains a small open that null fd array could potentially work for > group-opened device too if vfio-compat is used. In that case devices > are in same iommufd ctx with valid dev_id even though they are opened > via group. But probably it's not worthy blocking it? IMHO not worth the complexity to block. Security is maintained if we use an iommufd_ctx check. Jason
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Tue, Apr 18, 2023 at 10:23:55AM +, Liu, Yi L wrote: > > From: Jason Gunthorpe > > Sent: Monday, April 17, 2023 9:39 PM > > > > On Fri, Apr 14, 2023 at 09:11:30AM +, Tian, Kevin wrote: > > > > > The only corner case with this option is when a user mixes group > > > and cdev usages. iirc you mentioned it's a valid usage to be supported. > > > In that case the kernel doesn't have sufficient knowledge to judge > > > 'resettable' as it doesn't know which groups are opened by this user. > > > > IMHO we don't need to support this combination. > > Do you mean we don't support hot-reset for this combination or we don't > support user using this combination. I guess the prior one. Right? Yes > Ditto. We just fail hot-reset for the multiple iommufds case. Is it? Yes > > I suppose we should have done that from the beginning - no-iommu is an > > IOMMUFD access, it just uses a crazy /proc based way to learn the > > PFNs. Making it a proper access and making a real VFIO ioctl that > > calls iommufd_access_pin_pages() and returns the DMA mapped addresses > > to userspace would go a long way to making no-iommu work in a logical, > > usable, way. > > This seems to be an improvement for noiommu mode. It can be done later. > For now, generating access_id and binding noiommu devices with iommufdctx > is enough for supporting noiommu hot-reset. Yes, I'm not sure there is much value in improving no-iommu unless someone also wants to go in and update dpdk. At some point we will need to revise dpdk to use iommufd, maybe that would be a good time to fix this too. The point is that using an access is actually a logical and sensible thing to do, no a hack to make hot reset work better. Jason
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/display: Increase AUX timeout for Type-C (rev7)
== Series Details == Series: drm/i915/display: Increase AUX timeout for Type-C (rev7) URL : https://patchwork.freedesktop.org/series/116010/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/116010/revisions/7/mbox/ not applied Patch is empty. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To record the empty patch as an empty commit, run "git am --allow-empty". To restore the original branch and stop patching, run "git am --abort". Build failed, no error log produced
[Intel-gfx] [PATCH v5] drm/i915/display: Increase AUX timeout for Type-C
Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
Workaround: Increase the timeout.
---v2
-change style on how we mention WA [Ankit]
-fix bat error by creating new func that is only called for aux power
well scenarios so we can avoid null pointer error as it is called
everywhere.
--v3
-Add non-default enable_timeout to power well descriptor which avoids
adding more platform checks [Imre]
--v4
-Remove Bspec link from top to bottom remove WA link from commit put it
on comment [Jani]
-enable_timeout in ms and add .fixed_enable_delay too [Imre]
--v5
-move power_wells instead of duplicating them [Imre]
Bspec: 55480
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/intel_display_power_map.c | 7 +++
drivers/gpu/drm/i915/display/intel_display_power_well.c | 3 ++-
drivers/gpu/drm/i915/display/intel_display_power_well.h | 2 ++
3 files changed, 11 insertions(+), 1 deletion(-)
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..b4070845cd53 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_map.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_map.c
@@ -1378,6 +1378,11 @@ static const struct i915_power_well_desc
xelpd_power_wells_main[] = {
I915_PW("AUX_C", &icl_pwdoms_aux_c, .hsw.idx =
ICL_PW_CTL_IDX_AUX_C),
I915_PW("AUX_D", &icl_pwdoms_aux_d, .hsw.idx =
XELPD_PW_CTL_IDX_AUX_D),
I915_PW("AUX_E", &icl_pwdoms_aux_e, .hsw.idx =
XELPD_PW_CTL_IDX_AUX_E),
+ ),
+ .ops = &icl_aux_power_well_ops,
+ .fixed_enable_delay = true,
+ }, {
+ .instances = &I915_PW_INSTANCES(
I915_PW("AUX_USBC1", &tgl_pwdoms_aux_usbc1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC1),
I915_PW("AUX_USBC2", &tgl_pwdoms_aux_usbc2, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC2),
I915_PW("AUX_USBC3", &tgl_pwdoms_aux_usbc3, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TC3),
@@ -1385,6 +1390,8 @@ static const struct i915_power_well_desc
xelpd_power_wells_main[] = {
),
.ops = &icl_aux_power_well_ops,
.fixed_enable_delay = true,
+ /* WA_14017248603: adlp */
+ .enable_timeout = 500,
}, {
.instances = &I915_PW_INSTANCES(
I915_PW("AUX_TBT1", &icl_pwdoms_aux_tbt1, .hsw.idx =
TGL_PW_CTL_IDX_AUX_TBT1),
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index 62bafcbc7937..930a42c825c3 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -253,6 +253,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
{
const struct i915_power_well_regs *regs = power_well->desc->ops->regs;
int pw_idx = i915_power_well_instance(power_well)->hsw.idx;
+ int timeout = power_well->desc->enable_timeout ? : 1;
/*
* For some power wells we're not supposed to watch the status bit for
@@ -266,7 +267,7 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
/* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
if (intel_de_wait_for_set(dev_priv, regs->driver,
- HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
+ HSW_PWR_WELL_CTL_STATE(pw_idx), timeout)) {
drm_dbg_kms(&dev_priv->drm, "%s power well enable timeout\n",
intel_power_well_name(power_well));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.h
b/drivers/gpu/drm/i915/display/intel_display_power_well.h
index ba7cb977e7c7..e494df379e6c 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.h
@@ -110,6 +110,8 @@ struct i915_power_well_desc {
* Thunderbolt mode.
*/
u16 is_tc_tbt:1;
+ /* Enable timeout if greater than the default 1ms */
+ u16 enable_timeout;
};
struct i915_power_well {
--
2.25.1
Re: [Intel-gfx] [PATCH] drm/i915/dp_mst: Fix active port PLL selection for secondary MST streams
> -Original Message-
> From: Deak, Imre
> Sent: Friday, April 14, 2023 8:38 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Kahola, Mika
> Subject: [PATCH] drm/i915/dp_mst: Fix active port PLL selection for secondary
> MST streams
>
> The port PLL selection needs to be up-to-date in the CRTC state of both the
> primary and all secondary MST streams. The commit removing the encoder
> update_prepare/complete hooks (see Fixes: below), stopped doing this for
> secondary streams, fix this up.
>
> Fixes: 0f752b2178c9 ("drm/i915: Remove the encoder
> update_prepare()/complete() hooks")
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8336
> Cc: Mika Kahola
Reviewed-by: Mika Kahola
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c| 27 +++--
> drivers/gpu/drm/i915/display/intel_ddi.h| 3 +++
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 ++
> 3 files changed, 30 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index ea012d7f378f3..29e4bfab46358 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3349,6 +3349,25 @@ void intel_ddi_update_pipe(struct
> intel_atomic_state *state,
> intel_hdcp_update_pipe(state, encoder, crtc_state, conn_state); }
>
> +void intel_ddi_update_active_dpll(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + struct intel_crtc *crtc)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + struct intel_crtc *slave_crtc;
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> +
> + if (!intel_phy_is_tc(i915, phy))
> + return;
> +
> + intel_update_active_dpll(state, crtc, encoder);
> + for_each_intel_crtc_in_pipe_mask(&i915->drm, slave_crtc,
> +
> intel_crtc_bigjoiner_slave_pipes(crtc_state))
> + intel_update_active_dpll(state, slave_crtc, encoder); }
> +
> static void
> intel_ddi_pre_pll_enable(struct intel_atomic_state *state,
>struct intel_encoder *encoder,
> @@ -3363,15 +3382,9 @@ intel_ddi_pre_pll_enable(struct intel_atomic_state
> *state,
> if (is_tc_port) {
> struct intel_crtc *master_crtc =
> to_intel_crtc(crtc_state->uapi.crtc);
> - struct intel_crtc *slave_crtc;
>
> intel_tc_port_get_link(dig_port, crtc_state->lane_count);
> -
> - intel_update_active_dpll(state, master_crtc, encoder);
> -
> - for_each_intel_crtc_in_pipe_mask(&dev_priv->drm, slave_crtc,
> -
> intel_crtc_bigjoiner_slave_pipes(crtc_state))
> - intel_update_active_dpll(state, slave_crtc, encoder);
> + intel_ddi_update_active_dpll(state, encoder, master_crtc);
> }
>
> main_link_aux_power_domain_get(dig_port, crtc_state); diff --git
> a/drivers/gpu/drm/i915/display/intel_ddi.h
> b/drivers/gpu/drm/i915/display/intel_ddi.h
> index c85e74ae68e4d..2bc034042a937 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.h
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.h
> @@ -72,5 +72,8 @@ void intel_ddi_sanitize_encoder_pll_mapping(struct
> intel_encoder *encoder); int intel_ddi_level(struct intel_encoder *encoder,
> const struct intel_crtc_state *crtc_state,
> int lane);
> +void intel_ddi_update_active_dpll(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + struct intel_crtc *crtc);
>
> #endif /* __INTEL_DDI_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index a88b852c437c4..2c49d9ab86a2a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -674,6 +674,13 @@ static void intel_mst_pre_pll_enable_dp(struct
> intel_atomic_state *state,
> if (intel_dp->active_mst_links == 0)
> dig_port->base.pre_pll_enable(state, &dig_port->base,
> pipe_config, NULL);
> + else
> + /*
> + * The port PLL state needs to get updated for secondary
> + * streams as for the primary stream.
> + */
> + intel_ddi_update_active_dpll(state, &dig_port->base,
> + to_intel_crtc(pipe_config-
> >uapi.crtc));
> }
>
> static void intel_mst_pre_enable_dp(struct intel_atomic_state *state,
> --
> 2.37.2
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
wrote:
>
>
> On 17/04/2023 20:39, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Add support to dump GEM stats to fdinfo.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> Documentation/gpu/drm-usage-stats.rst | 12 +++
> >> drivers/gpu/drm/drm_file.c| 52 +++
> >> include/drm/drm_drv.h | 7
> >> include/drm/drm_file.h| 8 +
> >> 4 files changed, 79 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >> b/Documentation/gpu/drm-usage-stats.rst
> >> index 2ab32c40e93c..8273a41b2fb0 100644
> >> --- a/Documentation/gpu/drm-usage-stats.rst
> >> +++ b/Documentation/gpu/drm-usage-stats.rst
> >> @@ -21,6 +21,7 @@ File format specification
> >>
> >> - File shall contain one key value pair per one line of text.
> >> - Colon character (`:`) must be used to delimit keys and values.
> >> +- Caret (`^`) is also a reserved character.
> >
> > this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
>
> Could you explain or remind me with a link to a previous explanation?
How is userspace supposed to know that "drm-memory-foo" is a memory
type "foo" but drm-memory-foo^size is not memory type "foo^size"?
BR,
-R
> What tool barfs on it and how? Spirit of drm-usage-stats.pl is that for
> both drm-engine-: and drm-memory-: generic userspace is
> supposed to take the whole as opaque and just enumerate all it finds.
>
> Gputop manages to do that with engines names it knows _nothing_ about.
> If it worked with memory regions it would just show the list of new
> regions as for example "system^resident", "system^active". Then tools
> can be extended to understand it better and provide a sub-breakdown if
> wanted.
>
> Ugly not, we can change from caret to something nicer, unless I am
> missing something it works, no?
>
> Regards,
>
> Tvrtko
>
> >
> > (also, it is IMHO rather ugly)
> >
> > BR,
> > -R
> >
> >> - All keys shall be prefixed with `drm-`.
> >> - Whitespace between the delimiter and first non-whitespace character
> >> shall be
> >> ignored when parsing.
> >> @@ -105,6 +106,17 @@ object belong to this client, in the respective
> >> memory region.
> >> Default unit shall be bytes with optional unit specifiers of 'KiB' or
> >> 'MiB'
> >> indicating kibi- or mebi-bytes.
> >>
> >> +- drm-memory-^size: [KiB|MiB]
> >> +- drm-memory-^shared: [KiB|MiB]
> >> +- drm-memory-^resident: [KiB|MiB]
> >> +- drm-memory-^purgeable: [KiB|MiB]
> >> +- drm-memory-^active: [KiB|MiB]
> >> +
> >> +Resident category is identical to the drm-memory- key and two should
> >> be
> >> +mutually exclusive.
> >> +
> >> +TODO more description text...
> >> +
> >> - drm-cycles-
> >>
> >> Engine identifier string must be the same as the one specified in the
> >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> >> index 37b4f76a5191..e202f79e816d 100644
> >> --- a/drivers/gpu/drm/drm_file.c
> >> +++ b/drivers/gpu/drm/drm_file.c
> >> @@ -42,6 +42,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >>
> >> #include "drm_crtc_internal.h"
> >> @@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct
> >> drm_pending_event *e)
> >> }
> >> EXPORT_SYMBOL(drm_send_event);
> >>
> >> +static void
> >> +print_stat(struct drm_printer *p, const char *stat, const char *region,
> >> u64 sz)
> >> +{
> >> + const char *units[] = {"", " KiB", " MiB"};
> >> + unsigned int u;
> >> +
> >> + if (sz == ~0ull) /* Not supported by the driver. */
> >> + return;
> >> +
> >> + for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> >> + if (sz < SZ_1K)
> >> + break;
> >> + sz = div_u64(sz, SZ_1K);
> >> + }
> >> +
> >> + drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
> >> + region, stat, sz, units[u]);
> >> +}
> >> +
> >> +static void print_memory_stats(struct drm_printer *p, struct drm_file
> >> *file)
> >> +{
> >> + struct drm_device *dev = file->minor->dev;
> >> + struct drm_fdinfo_memory_stat *stats;
> >> + unsigned int num, i;
> >> + char **regions;
> >> +
> >> + regions = dev->driver->query_fdinfo_memory_regions(dev, &num);
> >> +
> >> + stats = kcalloc(num, sizeof(*stats), GFP_KERNEL);
> >> + if (!stats)
> >> + return;
> >> +
> >> + dev->driver->query_fdinfo_memory_stats(file, stats);
> >> +
> >> + for (i = 0; i < num; i++) {
> >> + if (!regions[i]) /* Allow sparse name arrays. */
> >> + continue;
> >> +
> >> + print_stat(p, "size", regions[i], stats[i].size);
> >> + print_stat(p, "shared", regions[i], stats[i].shared);
> >> + print_stat(p, "resident"
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: Increase AUX timeout for Type-C (rev8)
== Series Details ==
Series: drm/i915/display: Increase AUX timeout for Type-C (rev8)
URL : https://patchwork.freedesktop.org/series/116010/
State : warning
== Summary ==
Error: dim checkpatch failed
a0f5885b6afe drm/i915/display: Increase AUX timeout for Type-C
-:45: CHECK:OPEN_ENDED_LINE: Lines should not end with a '('
#45: FILE: drivers/gpu/drm/i915/display/intel_display_power_map.c:1385:
+ .instances = &I915_PW_INSTANCES(
total: 0 errors, 0 warnings, 1 checks, 42 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Increase AUX timeout for Type-C (rev8)
== Series Details == Series: drm/i915/display: Increase AUX timeout for Type-C (rev8) URL : https://patchwork.freedesktop.org/series/116010/ State : success == Summary == CI Bug Log - changes from CI_DRM_13026 -> Patchwork_116010v8 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/index.html Participating hosts (38 -> 36) -- Missing(2): bat-mtlp-8 fi-snb-2520m Known issues Here are the changes found in Patchwork_116010v8 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_lrc: - bat-adln-1: [PASS][1] -> [INCOMPLETE][2] ([i915#4983] / [i915#7609]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-adln-1/igt@i915_selftest@live@gt_lrc.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/bat-adln-1/igt@i915_selftest@live@gt_lrc.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_13026/bat-rpls-1/igt@i915_selftest@l...@reset.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/bat-rpls-1/igt@i915_selftest@l...@reset.html * igt@i915_suspend@basic-s3-without-i915: - bat-rpls-2: [PASS][5] -> [ABORT][6] ([i915#6687] / [i915#7978]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/bat-rpls-2/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1: - bat-dg2-8: [PASS][7] -> [FAIL][8] ([i915#7932]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html Possible fixes * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][9] ([i915#7699]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-dg2-11/igt@i915_selftest@l...@migrate.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/bat-dg2-11/igt@i915_selftest@l...@migrate.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][11] ([i915#6367] / [i915#7913] / [i915#7996]) -> [DMESG-FAIL][12] ([i915#6367] / [i915#7913]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-rpls-2/igt@i915_selftest@l...@slpc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/bat-rpls-2/igt@i915_selftest@l...@slpc.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7609]: https://gitlab.freedesktop.org/drm/intel/issues/7609 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 Build changes - * Linux: CI_DRM_13026 -> Patchwork_116010v8 CI-20190529: 20190529 CI_DRM_13026: 45bed7de41ad8bd909a82382a8fc4cb65e04ad56 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7259: 3d3a7f1c041d3f8d84d7457abf96adef0ea071cb @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116010v8: 45bed7de41ad8bd909a82382a8fc4cb65e04ad56 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 69fc04abd6ed drm/i915/display: Increase AUX timeout for Type-C == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/index.html
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 3:47 AM Tvrtko Ursulin
wrote:
>
>
> On 17/04/2023 17:20, Christian König wrote:
> > Am 17.04.23 um 17:56 schrieb Tvrtko Ursulin:
> >> From: Tvrtko Ursulin
> >>
> >> Add support to dump GEM stats to fdinfo.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> Documentation/gpu/drm-usage-stats.rst | 12 +++
> >> drivers/gpu/drm/drm_file.c| 52 +++
> >> include/drm/drm_drv.h | 7
> >> include/drm/drm_file.h| 8 +
> >> 4 files changed, 79 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >> b/Documentation/gpu/drm-usage-stats.rst
> >> index 2ab32c40e93c..8273a41b2fb0 100644
> >> --- a/Documentation/gpu/drm-usage-stats.rst
> >> +++ b/Documentation/gpu/drm-usage-stats.rst
> >> @@ -21,6 +21,7 @@ File format specification
> >> - File shall contain one key value pair per one line of text.
> >> - Colon character (`:`) must be used to delimit keys and values.
> >> +- Caret (`^`) is also a reserved character.
> >> - All keys shall be prefixed with `drm-`.
> >> - Whitespace between the delimiter and first non-whitespace
> >> character shall be
> >> ignored when parsing.
> >> @@ -105,6 +106,17 @@ object belong to this client, in the respective
> >> memory region.
> >> Default unit shall be bytes with optional unit specifiers of 'KiB'
> >> or 'MiB'
> >> indicating kibi- or mebi-bytes.
> >> +- drm-memory-^size: [KiB|MiB]
> >> +- drm-memory-^shared: [KiB|MiB]
> >> +- drm-memory-^resident: [KiB|MiB]
> >> +- drm-memory-^purgeable: [KiB|MiB]
> >> +- drm-memory-^active: [KiB|MiB]
> >
> > What exactly does size/shared/active mean here?
> >
> > If it means what I think it does I don't see how TTM based drivers
> > should track that in the first place.
>
> Size is an analogue to process VM size - maximum reachable/allocated
> memory belonging to a client.
>
> Shared could be IMO viewed as a bit dodgy and either could be dropped or
> needs to be better defined. For now I simply followed the implementation
> from Rob's RFC which is:
>
> if (obj->handle_count > 1)
> stats[0].shared += sz;
>
> I can see some usefulness to it but haven't thought much about semantics
> yet.
>
> Similar story with active which I think is not very useful.
> Implementation is like this:
>
> if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
> stats[0].active += sz;
>
> For me it is too transient to bring much value over the resident
> category. I supposed only advantage is that resident (as does purgeable)
> needs driver cooperation while active can be done like about from DRM
> core. Although I am not a big fan of counting these stats from the core
> to begin with..
Maybe there is a better way to track it, like setting an age/time when
the buffer is last active (which could be made part of dma_resv to
make it automatic). The question I really want to answer is more like
"over the last T ms how many buffers were active". This is a useful
metric esp when you think about a use-case like the browser where you
might have a lot of textures/etc for your 80 different tabs but at any
given time only a small subset is active and the rest can be swapped
out to zram if needed.
BR,
-R
>
> Regards,
>
> Tvrtko
>
> >> +Resident category is identical to the drm-memory- key and two
> >> should be
> >> +mutually exclusive.
> >> +
> >> +TODO more description text...
> >> +
> >> - drm-cycles-
> >> Engine identifier string must be the same as the one specified in the
> >> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> >> index 37b4f76a5191..e202f79e816d 100644
> >> --- a/drivers/gpu/drm/drm_file.c
> >> +++ b/drivers/gpu/drm/drm_file.c
> >> @@ -42,6 +42,7 @@
> >> #include
> >> #include
> >> #include
> >> +#include
> >> #include
> >> #include "drm_crtc_internal.h"
> >> @@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev,
> >> struct drm_pending_event *e)
> >> }
> >> EXPORT_SYMBOL(drm_send_event);
> >> +static void
> >> +print_stat(struct drm_printer *p, const char *stat, const char
> >> *region, u64 sz)
> >> +{
> >> +const char *units[] = {"", " KiB", " MiB"};
> >> +unsigned int u;
> >> +
> >> +if (sz == ~0ull) /* Not supported by the driver. */
> >> +return;
> >> +
> >> +for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
> >> +if (sz < SZ_1K)
> >> +break;
> >> +sz = div_u64(sz, SZ_1K);
> >> +}
> >> +
> >> +drm_printf(p, "drm-memory-%s^%s:\t%llu%s\n",
> >> + region, stat, sz, units[u]);
> >> +}
> >> +
> >> +static void print_memory_stats(struct drm_printer *p, struct drm_file
> >> *file)
> >> +{
> >> +struct drm_device *dev = file->minor->dev;
> >> +struct drm_fdinfo_memory_stat *stats;
> >> +unsigned int num, i;
> >> +char **regions;
> >> +
> >> +regions = dev->driver->query_fdinfo_memory_regions
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On 18/04/2023 14:49, Rob Clark wrote:
On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
wrote:
On 17/04/2023 20:39, Rob Clark wrote:
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Add support to dump GEM stats to fdinfo.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 12 +++
drivers/gpu/drm/drm_file.c| 52 +++
include/drm/drm_drv.h | 7
include/drm/drm_file.h| 8 +
4 files changed, 79 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index 2ab32c40e93c..8273a41b2fb0 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -21,6 +21,7 @@ File format specification
- File shall contain one key value pair per one line of text.
- Colon character (`:`) must be used to delimit keys and values.
+- Caret (`^`) is also a reserved character.
this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
Could you explain or remind me with a link to a previous explanation?
How is userspace supposed to know that "drm-memory-foo" is a memory
type "foo" but drm-memory-foo^size is not memory type "foo^size"?
Are you referring to nvtop?
Indeed that one hardcodes:
static const char drm_amdgpu_vram[] = "drm-memory-vram";
And does brute strcmp on it:
} else if (!strcmp(key, drm_amdgpu_vram_old) || !strcmp(key,
drm_amdgpu_vram)) {
So okay for that one, if we need to keep it working I just change this in my
RFC:
"""
Resident category is identical to the drm-memory- key and two should be
mutually exclusive.
"""
Into this:
"""
Resident category is identical to the drm-memory- key and where the
categorized one is present the legacy one must be too in order to preserve backward
compatibility.
"""
Addition to my RFC:
...
for (i = 0; i < num; i++) {
if (!regions[i]) /* Allow sparse name arrays. */
continue;
print_stat(p, "size", regions[i], stats[i].size);
print_stat(p, "shared", regions[i], stats[i].shared);
+ print_stat(p, "", regions[i], stats[i].resident);
print_stat(p, "resident", regions[i], stats[i].resident);
print_stat(p, "purgeable", regions[i], stats[i].purgeable);
print_stat(p, "active", regions[i], stats[i].active);
}
...
Results in output like this (in theory, if/when amdgpu takes on the extended
format):
drm-memory-vram-size: ... KiB
drm-memory-vram: $same KiB
drm-memory-vram-resident: $same KiB
drm-memory-vram-...:
Regards,
Tvrtko
P.S. Would a slash instead of a caret be prettier?
What tool barfs on it and how? Spirit of drm-usage-stats.pl is that for
both drm-engine-: and drm-memory-: generic userspace is
supposed to take the whole as opaque and just enumerate all it finds.
Gputop manages to do that with engines names it knows _nothing_ about.
If it worked with memory regions it would just show the list of new
regions as for example "system^resident", "system^active". Then tools
can be extended to understand it better and provide a sub-breakdown if
wanted.
Ugly not, we can change from caret to something nicer, unless I am
missing something it works, no?
Regards,
Tvrtko
(also, it is IMHO rather ugly)
BR,
-R
- All keys shall be prefixed with `drm-`.
- Whitespace between the delimiter and first non-whitespace character shall
be
ignored when parsing.
@@ -105,6 +106,17 @@ object belong to this client, in the respective memory
region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
indicating kibi- or mebi-bytes.
+- drm-memory-^size: [KiB|MiB]
+- drm-memory-^shared: [KiB|MiB]
+- drm-memory-^resident: [KiB|MiB]
+- drm-memory-^purgeable: [KiB|MiB]
+- drm-memory-^active: [KiB|MiB]
+
+Resident category is identical to the drm-memory- key and two should be
+mutually exclusive.
+
+TODO more description text...
+
- drm-cycles-
Engine identifier string must be the same as the one specified in the
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 37b4f76a5191..e202f79e816d 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#include
#include "drm_crtc_internal.h"
@@ -871,6 +872,54 @@ void drm_send_event(struct drm_device *dev, struct
drm_pending_event *e)
}
EXPORT_SYMBOL(drm_send_event);
+static void
+print_stat(struct drm_printer *p, const char *stat, const char *region, u64 sz)
+{
+ const char *units[] = {"", " KiB", " MiB"};
+ unsigned int u;
+
+ if (sz == ~0ull) /* Not supported by the driver. */
+ return;
+
+ for (u = 0; u < ARRAY_SIZE(units) - 1; u++) {
+ if (sz < SZ_1K)
+ break;
+
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 14:49, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 17/04/2023 20:39, Rob Clark wrote:
> >>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> >>> wrote:
>
> From: Tvrtko Ursulin
>
> Add support to dump GEM stats to fdinfo.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> Documentation/gpu/drm-usage-stats.rst | 12 +++
> drivers/gpu/drm/drm_file.c| 52 +++
> include/drm/drm_drv.h | 7
> include/drm/drm_file.h| 8 +
> 4 files changed, 79 insertions(+)
>
> diff --git a/Documentation/gpu/drm-usage-stats.rst
> b/Documentation/gpu/drm-usage-stats.rst
> index 2ab32c40e93c..8273a41b2fb0 100644
> --- a/Documentation/gpu/drm-usage-stats.rst
> +++ b/Documentation/gpu/drm-usage-stats.rst
> @@ -21,6 +21,7 @@ File format specification
>
> - File shall contain one key value pair per one line of text.
> - Colon character (`:`) must be used to delimit keys and values.
> +- Caret (`^`) is also a reserved character.
> >>>
> >>> this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
> >>
> >> Could you explain or remind me with a link to a previous explanation?
> >
> > How is userspace supposed to know that "drm-memory-foo" is a memory
> > type "foo" but drm-memory-foo^size is not memory type "foo^size"?
>
> Are you referring to nvtop?
I'm not referring to any particular app. It could even be some app
that isn't even written yet but started with an already existing
kernel without this change. It is just a general point about forwards
compatibility of old userspace with new kernel. And it doesn't really
matter what special character you use. You can't retroactively define
some newly special characters.
BR,
-R
> Indeed that one hardcodes:
>
>static const char drm_amdgpu_vram[] = "drm-memory-vram";
>
> And does brute strcmp on it:
>
>} else if (!strcmp(key, drm_amdgpu_vram_old) || !strcmp(key,
> drm_amdgpu_vram)) {
>
> So okay for that one, if we need to keep it working I just change this in my
> RFC:
>
> """
> Resident category is identical to the drm-memory- key and two should be
> mutually exclusive.
> """
>
> Into this:
>
> """
> Resident category is identical to the drm-memory- key and where the
> categorized one is present the legacy one must be too in order to preserve
> backward compatibility.
> """
>
> Addition to my RFC:
>
> ...
> for (i = 0; i < num; i++) {
> if (!regions[i]) /* Allow sparse name arrays. */
> continue;
>
> print_stat(p, "size", regions[i], stats[i].size);
> print_stat(p, "shared", regions[i], stats[i].shared);
> + print_stat(p, "", regions[i], stats[i].resident);
> print_stat(p, "resident", regions[i], stats[i].resident);
> print_stat(p, "purgeable", regions[i], stats[i].purgeable);
> print_stat(p, "active", regions[i], stats[i].active);
> }
> ...
>
> Results in output like this (in theory, if/when amdgpu takes on the extended
> format):
>
> drm-memory-vram-size: ... KiB
> drm-memory-vram: $same KiB
> drm-memory-vram-resident: $same KiB
> drm-memory-vram-...:
>
> Regards,
>
> Tvrtko
>
> P.S. Would a slash instead of a caret be prettier?
>
> >> What tool barfs on it and how? Spirit of drm-usage-stats.pl is that for
> >> both drm-engine-: and drm-memory-: generic userspace is
> >> supposed to take the whole as opaque and just enumerate all it finds.
> >>
> >> Gputop manages to do that with engines names it knows _nothing_ about.
> >> If it worked with memory regions it would just show the list of new
> >> regions as for example "system^resident", "system^active". Then tools
> >> can be extended to understand it better and provide a sub-breakdown if
> >> wanted.
> >>
> >> Ugly not, we can change from caret to something nicer, unless I am
> >> missing something it works, no?
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
> >>>
> >>> (also, it is IMHO rather ugly)
> >>>
> >>> BR,
> >>> -R
> >>>
> - All keys shall be prefixed with `drm-`.
> - Whitespace between the delimiter and first non-whitespace character
> shall be
> ignored when parsing.
> @@ -105,6 +106,17 @@ object belong to this client, in the respective
> memory region.
> Default unit shall be bytes with optional unit specifiers of 'KiB' or
> 'MiB'
> indicating kibi- or mebi-bytes.
>
> +- drm-memory-^size: [KiB|MiB]
> +- drm-memory-^shared: [KiB|MiB]
> +- drm-memory-^resident: [KiB|MiB]
> +- drm-memory-^purgeable: [KiB|MiB]
> +- drm-memory-^active: [KiB|MiB]
> +
> +Resident category is identical to the drm-memory-
Re: [Intel-gfx] [PATCH] drm/i915/display: Return correct err code for bpc < 0
On 4/18/2023 6:16 PM, Ville Syrjälä wrote: On Mon, Apr 17, 2023 at 03:48:12PM -0700, Manasi Navare wrote: Hi Ville, Could you suggest how to handle the intel_dp_link_compute_config() when the max_bpp is returned as 0, currently it just exits the loop and returns a -EINVAL and this triggers the DSC path. While we should be completely failing the modeset and encoder_config in this case instead of trying DSC, correct? The DSC path needs to handle the bpp limits correctly: 1. Take the baseline limits already computed 2. Further restrict them based on sink/source DSC capabilities/etc. 3. Make sure the uncompressed bpp value chosen is between the min/max I have some older patch to try similar thing [1]. We try to iterate over bpc to find pipe_bpp in the limits, then try to find out compressed_bpp. But if intel_dp_max_bpp returns 0, limits.max_bpp is set to 0, so we discard this for dsc case and re-calculate the limits.max_bpp? [1] https://patchwork.freedesktop.org/patch/519346/?series=111391&rev=3 Manasi On Thu, Apr 13, 2023 at 8:23 AM Manasi Navare wrote: On Tue, Apr 11, 2023 at 10:22 PM Ville Syrjälä wrote: On Tue, Apr 11, 2023 at 05:07:01PM -0700, Manasi Navare wrote: On Tue, Apr 11, 2023 at 10:42 AM Ville Syrjälä wrote: On Tue, Apr 11, 2023 at 05:34:08PM +, Manasi Navare wrote: In the function intel_dp_max_bpp(), currently if bpc < 0 in case of error, we return 0 instead of returning an err code of -EINVAL. This throws off the logic in the calling function. What logic? The caller doesn't expect to get an error. If this returns a 0, we end up using limits.max_bpp = 0 and in intel_dp_compute_link_config_wide(), since max_bpp is 0, it exits this for loop: for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) and returns -EINVAL which then wrongly goes to enable DSC even when link BW is sufficient without DSC. And how woud max_bpp<0 prevent that? The real problem seems to be that the DSC code totally ignores bpp limits. Hi Ville, So I see a few concerns/questions: - Why is the Max bpp value 0 in intel_dp_max_bpp, is that a valid case and how should our link configurations handle that case when max_bpp is 0? - This is happening in a bug I am looking at with HDMI PCON, @Ankit Nautiyal have we ever seen something similar where max_bpp for HDMi PCON is returned 0? - I dont think its a problem with DSC code, but rather intel_dp_compute_link_config() outer for loop where we vary from max_bpp to min_bpp and see if any bpp works with available link bw, how should we handle this when max_bpp = 0 if you are saying thats a valid case? - In this patch if I return -EINVAL instead of 0, then atleast the entire encoder_config will fail and that will fail the modeset, since it assumes max_bpp cannot be 0 Could you please help answer above concerns and how to handle max bpp = 0 case if that is valid? This patch is simply making that invalid resulting into modeset failure Manasi -- Ville Syrjälä Intel
Re: [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Show how more driver specific set of memory stats could be shown,
> more specifically where object can reside in multiple regions, showing all
> the supported stats, and where there is more to show than just user visible
> objects.
>
> WIP...
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/i915_driver.c | 5 ++
> drivers/gpu/drm/i915/i915_drm_client.c | 102 +
> drivers/gpu/drm/i915/i915_drm_client.h | 8 ++
> drivers/gpu/drm/i915/i915_drv.h| 2 +
> 4 files changed, 117 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 6493548c69bf..4c70206cbc27 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver = {
> .dumb_create = i915_gem_dumb_create,
> .dumb_map_offset = i915_gem_dumb_mmap_offset,
>
> +#ifdef CONFIG_PROC_FS
> + .query_fdinfo_memory_regions = i915_query_fdinfo_memory_regions,
> + .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
> +#endif
> +
> .ioctls = i915_ioctls,
> .num_ioctls = ARRAY_SIZE(i915_ioctls),
> .fops = &i915_driver_fops,
> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> b/drivers/gpu/drm/i915/i915_drm_client.c
> index c654984189f7..65857c68bdb3 100644
> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> @@ -12,6 +12,7 @@
> #include
>
> #include "gem/i915_gem_context.h"
> +#include "intel_memory_region.h"
> #include "i915_drm_client.h"
> #include "i915_file_private.h"
> #include "i915_gem.h"
> @@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer *p,
> struct drm_file *file)
> for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> show_client_class(p, i915, file_priv->client, i);
> }
> +
> +char **
> +i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int *num)
> +{
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct intel_memory_region *mr;
> + enum intel_region_id id;
> +
> + /* FIXME move to init */
> + for_each_memory_region(mr, i915, id) {
> + if (!i915->mm.region_names[id])
> + i915->mm.region_names[id] = mr->name;
> + }
> +
> + *num = id;
> +
> + return i915->mm.region_names;
> +}
> +
> +static void
> +add_obj(struct drm_i915_gem_object *obj, struct drm_fdinfo_memory_stat
> *stats)
> +{
> +struct intel_memory_region *mr;
> + u64 sz = obj->base.size;
> +enum intel_region_id id;
> + unsigned int i;
> +
> + if (!obj)
> + return;
> +
> + /* Attribute size and shared to all possible memory regions. */
> + for (i = 0; i < obj->mm.n_placements; i++) {
> + mr = obj->mm.placements[i];
> + id = mr->id;
> +
> + stats[id].size += sz;
This implies that summing up all of the categories is not the same as
the toplevel stats that I was proposing
BR,
-R
> + if (obj->base.handle_count > 1)
> + stats[id].shared += sz;
> + }
> +
> + /* Attribute other categories to only the current region. */
> + mr = obj->mm.region;
> + if (mr)
> + id = mr->id;
> + else
> + id = INTEL_REGION_SMEM;
> +
> + if (!i915_gem_object_has_pages(obj))
> + return;
> +
> + stats[id].resident += sz;
> +
> + if (!dma_resv_test_signaled(obj->base.resv, dma_resv_usage_rw(true)))
> + stats[id].active += sz;
> + else if (i915_gem_object_is_shrinkable(obj) &&
> + obj->mm.madv == I915_MADV_DONTNEED)
> + stats[id].purgeable += sz;
> +}
> +
> +void
> +i915_query_fdinfo_memory_stats(struct drm_file *file,
> + struct drm_fdinfo_memory_stat *stats)
> +{
> + struct drm_i915_file_private *file_priv = file->driver_priv;
> + struct i915_drm_client *client = file_priv->client;
> + struct drm_gem_object *drm_obj;
> + struct i915_gem_context *ctx;
> + int id;
> +
> + /*
> +* FIXME - we can do this better and in fewer passes if we are to
> start
> +* exporting proper memory stats.
> +*/
> +
> + /* User created objects */
> + spin_lock(&file->table_lock);
> + idr_for_each_entry(&file->object_idr, drm_obj, id)
> + add_obj(to_intel_bo(drm_obj), stats);
> + spin_unlock(&file->table_lock);
> +
> + /* Contexts, rings, timelines, page tables, ... */
> + rcu_read_lock();
> + list_for_each_entry_rcu(ctx, &client->ctx_list, client_link) {
> + struct i915_gem_engines_iter it;
> + struct intel_context *ce;
> +
> + for_each_gem
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On 18/04/2023 15:36, Rob Clark wrote:
On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin
wrote:
On 18/04/2023 14:49, Rob Clark wrote:
On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
wrote:
On 17/04/2023 20:39, Rob Clark wrote:
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Add support to dump GEM stats to fdinfo.
Signed-off-by: Tvrtko Ursulin
---
Documentation/gpu/drm-usage-stats.rst | 12 +++
drivers/gpu/drm/drm_file.c| 52 +++
include/drm/drm_drv.h | 7
include/drm/drm_file.h| 8 +
4 files changed, 79 insertions(+)
diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index 2ab32c40e93c..8273a41b2fb0 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -21,6 +21,7 @@ File format specification
- File shall contain one key value pair per one line of text.
- Colon character (`:`) must be used to delimit keys and values.
+- Caret (`^`) is also a reserved character.
this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-)
Could you explain or remind me with a link to a previous explanation?
How is userspace supposed to know that "drm-memory-foo" is a memory
type "foo" but drm-memory-foo^size is not memory type "foo^size"?
Are you referring to nvtop?
I'm not referring to any particular app. It could even be some app
that isn't even written yet but started with an already existing
kernel without this change. It is just a general point about forwards
compatibility of old userspace with new kernel. And it doesn't really
matter what special character you use. You can't retroactively define
some newly special characters.
What you see does not work if we output both legacy and new key with
extra category? Userspace which hardcode the name keep working, and
userspace which parses region names as opaque strings also keeps working
just shows more entries.
Regards,
Tvrtko
BR,
-R
Indeed that one hardcodes:
static const char drm_amdgpu_vram[] = "drm-memory-vram";
And does brute strcmp on it:
} else if (!strcmp(key, drm_amdgpu_vram_old) || !strcmp(key,
drm_amdgpu_vram)) {
So okay for that one, if we need to keep it working I just change this in my
RFC:
"""
Resident category is identical to the drm-memory- key and two should be
mutually exclusive.
"""
Into this:
"""
Resident category is identical to the drm-memory- key and where the
categorized one is present the legacy one must be too in order to preserve backward
compatibility.
"""
Addition to my RFC:
...
for (i = 0; i < num; i++) {
if (!regions[i]) /* Allow sparse name arrays. */
continue;
print_stat(p, "size", regions[i], stats[i].size);
print_stat(p, "shared", regions[i], stats[i].shared);
+ print_stat(p, "", regions[i], stats[i].resident);
print_stat(p, "resident", regions[i], stats[i].resident);
print_stat(p, "purgeable", regions[i], stats[i].purgeable);
print_stat(p, "active", regions[i], stats[i].active);
}
...
Results in output like this (in theory, if/when amdgpu takes on the extended
format):
drm-memory-vram-size: ... KiB
drm-memory-vram: $same KiB
drm-memory-vram-resident: $same KiB
drm-memory-vram-...:
Regards,
Tvrtko
P.S. Would a slash instead of a caret be prettier?
What tool barfs on it and how? Spirit of drm-usage-stats.pl is that for
both drm-engine-: and drm-memory-: generic userspace is
supposed to take the whole as opaque and just enumerate all it finds.
Gputop manages to do that with engines names it knows _nothing_ about.
If it worked with memory regions it would just show the list of new
regions as for example "system^resident", "system^active". Then tools
can be extended to understand it better and provide a sub-breakdown if
wanted.
Ugly not, we can change from caret to something nicer, unless I am
missing something it works, no?
Regards,
Tvrtko
(also, it is IMHO rather ugly)
BR,
-R
- All keys shall be prefixed with `drm-`.
- Whitespace between the delimiter and first non-whitespace character shall
be
ignored when parsing.
@@ -105,6 +106,17 @@ object belong to this client, in the respective memory
region.
Default unit shall be bytes with optional unit specifiers of 'KiB' or 'MiB'
indicating kibi- or mebi-bytes.
+- drm-memory-^size: [KiB|MiB]
+- drm-memory-^shared: [KiB|MiB]
+- drm-memory-^resident: [KiB|MiB]
+- drm-memory-^purgeable: [KiB|MiB]
+- drm-memory-^active: [KiB|MiB]
+
+Resident category is identical to the drm-memory- key and two should be
+mutually exclusive.
+
+TODO more description text...
+
- drm-cycles-
Engine identifier string must be the same as the one specified in the
diff --git a/drivers/gpu/drm/drm_file.c
Re: [Intel-gfx] [PATCH] drm/i915/display: Return correct err code for bpc < 0
On Tue, Apr 18, 2023 at 08:09:16PM +0530, Nautiyal, Ankit K wrote: > > On 4/18/2023 6:16 PM, Ville Syrjälä wrote: > > On Mon, Apr 17, 2023 at 03:48:12PM -0700, Manasi Navare wrote: > >> Hi Ville, > >> > >> Could you suggest how to handle the intel_dp_link_compute_config() > >> when the max_bpp is returned as 0, currently > >> it just exits the loop and returns a -EINVAL and this triggers the DSC > >> path. > >> While we should be completely failing the modeset and encoder_config > >> in this case instead of trying DSC, correct? > > The DSC path needs to handle the bpp limits correctly: > > 1. Take the baseline limits already computed > > 2. Further restrict them based on sink/source DSC capabilities/etc. > > 3. Make sure the uncompressed bpp value chosen is between the min/max > > I have some older patch to try similar thing [1]. We try to iterate over > bpc to find pipe_bpp in the limits, then try to find out compressed_bpp. > > But if intel_dp_max_bpp returns 0, limits.max_bpp is set to 0, so we > discard this for dsc case and re-calculate the limits.max_bpp? You shouldn't discard anything. DSC should take the already computed limits and potentially just shrink them further based on DSC specific constraints. Or is there some weird case where DSC would allow lower/higher bpp than what our uncompressed bpp limits declare? > > > [1] https://patchwork.freedesktop.org/patch/519346/?series=111391&rev=3 > > > > >> Manasi > >> > >> On Thu, Apr 13, 2023 at 8:23 AM Manasi Navare > >> wrote: > >>> On Tue, Apr 11, 2023 at 10:22 PM Ville Syrjälä > >>> wrote: > On Tue, Apr 11, 2023 at 05:07:01PM -0700, Manasi Navare wrote: > > On Tue, Apr 11, 2023 at 10:42 AM Ville Syrjälä > > wrote: > >> On Tue, Apr 11, 2023 at 05:34:08PM +, Manasi Navare wrote: > >>> In the function intel_dp_max_bpp(), currently if bpc < 0 in case of > >>> error, > >>> we return 0 instead of returning an err code of -EINVAL. > >>> This throws off the logic in the calling function. > >> What logic? The caller doesn't expect to get an error. > > If this returns a 0, we end up using limits.max_bpp = 0 and in > > intel_dp_compute_link_config_wide(), > > since max_bpp is 0, it exits this for loop: > > > > for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) and > > returns > > -EINVAL which then wrongly goes to enable DSC even when link BW is > > sufficient without DSC. > And how woud max_bpp<0 prevent that? > > The real problem seems to be that the DSC code totally > ignores bpp limits. > >>> Hi Ville, > >>> > >>> So I see a few concerns/questions: > >>> - Why is the Max bpp value 0 in intel_dp_max_bpp, is that a valid case > >>> and how should our link configurations handle that case when max_bpp > >>> is 0? > >>> - This is happening in a bug I am looking at with HDMI PCON, @Ankit > >>> Nautiyal have we ever seen something similar where max_bpp for HDMi > >>> PCON > >>> is returned 0? > >>> - I dont think its a problem with DSC code, but rather > >>> intel_dp_compute_link_config() outer for loop where we vary > >>> from max_bpp to min_bpp and see if any bpp works with available link > >>> bw, how should we handle this when max_bpp = 0 if you are saying thats > >>> a valid case? > >>> - In this patch if I return -EINVAL instead of 0, then atleast the > >>> entire encoder_config will fail and that will fail the modeset, since > >>> it assumes max_bpp cannot be 0 > >>> > >>> Could you please help answer above concerns and how to handle max bpp > >>> = 0 case if that is valid? This patch is simply making that invalid > >>> resulting into modeset failure > >>> > >>> Manasi > -- > Ville Syrjälä > Intel -- Ville Syrjälä Intel
Re: [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing
On 18/04/2023 15:39, Rob Clark wrote:
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Show how more driver specific set of memory stats could be shown,
more specifically where object can reside in multiple regions, showing all
the supported stats, and where there is more to show than just user visible
objects.
WIP...
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 5 ++
drivers/gpu/drm/i915/i915_drm_client.c | 102 +
drivers/gpu/drm/i915/i915_drm_client.h | 8 ++
drivers/gpu/drm/i915/i915_drv.h| 2 +
4 files changed, 117 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 6493548c69bf..4c70206cbc27 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver = {
.dumb_create = i915_gem_dumb_create,
.dumb_map_offset = i915_gem_dumb_mmap_offset,
+#ifdef CONFIG_PROC_FS
+ .query_fdinfo_memory_regions = i915_query_fdinfo_memory_regions,
+ .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
+#endif
+
.ioctls = i915_ioctls,
.num_ioctls = ARRAY_SIZE(i915_ioctls),
.fops = &i915_driver_fops,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index c654984189f7..65857c68bdb3 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -12,6 +12,7 @@
#include
#include "gem/i915_gem_context.h"
+#include "intel_memory_region.h"
#include "i915_drm_client.h"
#include "i915_file_private.h"
#include "i915_gem.h"
@@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer *p, struct
drm_file *file)
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
show_client_class(p, i915, file_priv->client, i);
}
+
+char **
+i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int *num)
+{
+ struct drm_i915_private *i915 = to_i915(dev);
+ struct intel_memory_region *mr;
+ enum intel_region_id id;
+
+ /* FIXME move to init */
+ for_each_memory_region(mr, i915, id) {
+ if (!i915->mm.region_names[id])
+ i915->mm.region_names[id] = mr->name;
+ }
+
+ *num = id;
+
+ return i915->mm.region_names;
+}
+
+static void
+add_obj(struct drm_i915_gem_object *obj, struct drm_fdinfo_memory_stat *stats)
+{
+struct intel_memory_region *mr;
+ u64 sz = obj->base.size;
+enum intel_region_id id;
+ unsigned int i;
+
+ if (!obj)
+ return;
+
+ /* Attribute size and shared to all possible memory regions. */
+ for (i = 0; i < obj->mm.n_placements; i++) {
+ mr = obj->mm.placements[i];
+ id = mr->id;
+
+ stats[id].size += sz;
This implies that summing up all of the categories is not the same as
the toplevel stats that I was proposing
Correct, my categories are a bit different. You had private and shared as two
mutually exclusive buckets, and then resident as subset of either/both. I have
size as analogue to VmSize and resident as a subset of that, analogue to VmRss.
Shared is a bit wishy-washy, not sure about that one in either proposals. It
can be either imported or exported buffers, but in essence I think it fits
better as a subset of total size.
Regards,
Tvrtko
+ if (obj->base.handle_count > 1)
+ stats[id].shared += sz;
+ }
+
+ /* Attribute other categories to only the current region. */
+ mr = obj->mm.region;
+ if (mr)
+ id = mr->id;
+ else
+ id = INTEL_REGION_SMEM;
+
+ if (!i915_gem_object_has_pages(obj))
+ return;
+
+ stats[id].resident += sz;
+
+ if (!dma_resv_test_signaled(obj->base.resv, dma_resv_usage_rw(true)))
+ stats[id].active += sz;
+ else if (i915_gem_object_is_shrinkable(obj) &&
+ obj->mm.madv == I915_MADV_DONTNEED)
+ stats[id].purgeable += sz;
+}
+
+void
+i915_query_fdinfo_memory_stats(struct drm_file *file,
+ struct drm_fdinfo_memory_stat *stats)
+{
+ struct drm_i915_file_private *file_priv = file->driver_priv;
+ struct i915_drm_client *client = file_priv->client;
+ struct drm_gem_object *drm_obj;
+ struct i915_gem_context *ctx;
+ int id;
+
+ /*
+* FIXME - we can do this better and in fewer passes if we are to start
+* exporting proper memory stats.
+*/
+
+ /* User created objects */
+ spin_lock(&file->table_lock);
+ idr_for_each_entry(&file->object_idr, drm_obj, id)
+ add_obj(to_intel_bo(drm_obj), stats);
+ spin_unlock(&file->table_lock);
+
+ /* Contexts, rings, timelines, page tables,
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp_mst: Clear MSG_RDY flag before sending new message (rev2)
== Series Details ==
Series: drm/dp_mst: Clear MSG_RDY flag before sending new message (rev2)
URL : https://patchwork.freedesktop.org/series/116623/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13025_full -> Patchwork_116623v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116623v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_plane_lowres@tiling-y@pipe-a-hdmi-a-2:
- {shard-rkl}:[PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-rkl-3/igt@kms_plane_lowres@tilin...@pipe-a-hdmi-a-2.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-rkl-6/igt@kms_plane_lowres@tilin...@pipe-a-hdmi-a-2.html
Known issues
Here are the changes found in Patchwork_116623v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#2842])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-apl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-apl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@i915_pm_rps@reset:
- shard-snb: [PASS][5] -> [DMESG-FAIL][6] ([i915#8319])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-snb7/igt@i915_pm_...@reset.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-snb7/igt@i915_pm_...@reset.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#72])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-glk2/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
*
igt@kms_plane_scaling@planes-downscale-factor-0-5-unity-scaling@pipe-b-vga-1:
- shard-snb: NOTRUN -> [SKIP][9] ([fdo#109271]) +40 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-snb2/igt@kms_plane_scaling@planes-downscale-factor-0-5-unity-scal...@pipe-b-vga-1.html
* igt@kms_setmode@basic@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [FAIL][10] ([i915#5465]) +1 similar issue
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-snb1/igt@kms_setmode@ba...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][11] ([i915#7742]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-rkl-3/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-rkl-7/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_ctx_exec@basic-nohangcheck:
- {shard-tglu}: [FAIL][13] ([i915#6268]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-tglu-10/igt@gem_ctx_e...@basic-nohangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-tglu-10/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_exec_fair@basic-deadline:
- shard-glk: [FAIL][15] ([i915#2846]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-glk3/igt@gem_exec_f...@basic-deadline.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-glk4/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][17] ([i915#2842]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-rkl-4/igt@gem_exec_fair@basic-n...@vcs0.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-rkl-6/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-apl: [FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-apl6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2/shard-apl4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- {shard-dg1}:[SKIP][21] ([i915#1397]) -> [PASS][22] +1 similar
issue
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13025/shard-dg1-14/igt@i915_pm_...@dpms-mode-unset-non-lpsp.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116623v2
Re: [Intel-gfx] [RFC 6/6] drm/i915: Implement fdinfo memory stats printing
On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 15:39, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Show how more driver specific set of memory stats could be shown,
> >> more specifically where object can reside in multiple regions, showing all
> >> the supported stats, and where there is more to show than just user visible
> >> objects.
> >>
> >> WIP...
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> drivers/gpu/drm/i915/i915_driver.c | 5 ++
> >> drivers/gpu/drm/i915/i915_drm_client.c | 102 +
> >> drivers/gpu/drm/i915/i915_drm_client.h | 8 ++
> >> drivers/gpu/drm/i915/i915_drv.h| 2 +
> >> 4 files changed, 117 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> >> b/drivers/gpu/drm/i915/i915_driver.c
> >> index 6493548c69bf..4c70206cbc27 100644
> >> --- a/drivers/gpu/drm/i915/i915_driver.c
> >> +++ b/drivers/gpu/drm/i915/i915_driver.c
> >> @@ -1806,6 +1806,11 @@ static const struct drm_driver i915_drm_driver = {
> >> .dumb_create = i915_gem_dumb_create,
> >> .dumb_map_offset = i915_gem_dumb_mmap_offset,
> >>
> >> +#ifdef CONFIG_PROC_FS
> >> + .query_fdinfo_memory_regions = i915_query_fdinfo_memory_regions,
> >> + .query_fdinfo_memory_stats = i915_query_fdinfo_memory_stats,
> >> +#endif
> >> +
> >> .ioctls = i915_ioctls,
> >> .num_ioctls = ARRAY_SIZE(i915_ioctls),
> >> .fops = &i915_driver_fops,
> >> diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> >> b/drivers/gpu/drm/i915/i915_drm_client.c
> >> index c654984189f7..65857c68bdb3 100644
> >> --- a/drivers/gpu/drm/i915/i915_drm_client.c
> >> +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> >> @@ -12,6 +12,7 @@
> >> #include
> >>
> >> #include "gem/i915_gem_context.h"
> >> +#include "intel_memory_region.h"
> >> #include "i915_drm_client.h"
> >> #include "i915_file_private.h"
> >> #include "i915_gem.h"
> >> @@ -112,4 +113,105 @@ void i915_drm_client_fdinfo(struct drm_printer *p,
> >> struct drm_file *file)
> >> for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> >> show_client_class(p, i915, file_priv->client, i);
> >> }
> >> +
> >> +char **
> >> +i915_query_fdinfo_memory_regions(struct drm_device *dev, unsigned int
> >> *num)
> >> +{
> >> + struct drm_i915_private *i915 = to_i915(dev);
> >> + struct intel_memory_region *mr;
> >> + enum intel_region_id id;
> >> +
> >> + /* FIXME move to init */
> >> + for_each_memory_region(mr, i915, id) {
> >> + if (!i915->mm.region_names[id])
> >> + i915->mm.region_names[id] = mr->name;
> >> + }
> >> +
> >> + *num = id;
> >> +
> >> + return i915->mm.region_names;
> >> +}
> >> +
> >> +static void
> >> +add_obj(struct drm_i915_gem_object *obj, struct drm_fdinfo_memory_stat
> >> *stats)
> >> +{
> >> +struct intel_memory_region *mr;
> >> + u64 sz = obj->base.size;
> >> +enum intel_region_id id;
> >> + unsigned int i;
> >> +
> >> + if (!obj)
> >> + return;
> >> +
> >> + /* Attribute size and shared to all possible memory regions. */
> >> + for (i = 0; i < obj->mm.n_placements; i++) {
> >> + mr = obj->mm.placements[i];
> >> + id = mr->id;
> >> +
> >> + stats[id].size += sz;
> >
> > This implies that summing up all of the categories is not the same as
> > the toplevel stats that I was proposing
Sorry, I mis-spoke, I meant "summing up all of the regions is not..."
> Correct, my categories are a bit different. You had private and shared as two
> mutually exclusive buckets, and then resident as subset of either/both. I
> have size as analogue to VmSize and resident as a subset of that, analogue to
> VmRss.
>
I split shared because by definition shared buffers can be counted
against multiple drm_file's, whereas private is only counted against
the single drm_file. Driver or app changes are unlikely to change the
shared size, whereas private footprint is a thing you can optimize to
some degree.
> Shared is a bit wishy-washy, not sure about that one in either proposals. It
> can be either imported or exported buffers, but in essence I think it fits
> better as a subset of total size.
Imported vs exported doesn't really matter.. it is just an
implementation detail of the winsys. But I think it is useful to know
how much of an app's footprint is shared vs private. You could
express it different ways, but my proposal had private and shared,
from which you can calculate total:
total = private + shared
but you could flip the path around and advertise just total and
shared, and calculate private from that.
BR,
-R
> Regards,
>
> Tvrtko
>
> >> + if (obj->base.handle_count > 1)
> >> + stats[id].shared += sz;
> >> + }
>
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 7:46 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 15:36, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 18/04/2023 14:49, Rob Clark wrote:
> >>> On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin
> >>> wrote:
>
>
> On 17/04/2023 20:39, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> Add support to dump GEM stats to fdinfo.
> >>
> >> Signed-off-by: Tvrtko Ursulin
> >> ---
> >> Documentation/gpu/drm-usage-stats.rst | 12 +++
> >> drivers/gpu/drm/drm_file.c| 52
> >> +++
> >> include/drm/drm_drv.h | 7
> >> include/drm/drm_file.h| 8 +
> >> 4 files changed, 79 insertions(+)
> >>
> >> diff --git a/Documentation/gpu/drm-usage-stats.rst
> >> b/Documentation/gpu/drm-usage-stats.rst
> >> index 2ab32c40e93c..8273a41b2fb0 100644
> >> --- a/Documentation/gpu/drm-usage-stats.rst
> >> +++ b/Documentation/gpu/drm-usage-stats.rst
> >> @@ -21,6 +21,7 @@ File format specification
> >>
> >> - File shall contain one key value pair per one line of text.
> >> - Colon character (`:`) must be used to delimit keys and values.
> >> +- Caret (`^`) is also a reserved character.
> >
> > this doesn't solve the problem that led me to drm-$CATEGORY-memory...
> > ;-)
>
> Could you explain or remind me with a link to a previous explanation?
> >>>
> >>> How is userspace supposed to know that "drm-memory-foo" is a memory
> >>> type "foo" but drm-memory-foo^size is not memory type "foo^size"?
> >>
> >> Are you referring to nvtop?
> >
> > I'm not referring to any particular app. It could even be some app
> > that isn't even written yet but started with an already existing
> > kernel without this change. It is just a general point about forwards
> > compatibility of old userspace with new kernel. And it doesn't really
> > matter what special character you use. You can't retroactively define
> > some newly special characters.
>
> What you see does not work if we output both legacy and new key with
> extra category? Userspace which hardcode the name keep working, and
> userspace which parses region names as opaque strings also keeps working
> just shows more entries.
well, it shows nonsense entries.. I'd not call that "working"
But honestly we are wasting too many words on this.. we just can't
re-use the "drm-memory-" namespace, it is already burnt.
Full stop.
If you don't like the "drm-$CATEGORY-$REGION" workaround then we can
shorten to "drm-mem-$REGION-$CATEGORY" since that won't accidentally
match the existing "drm-memory-" pattern.
BR,
-R
> Regards,
>
> Tvrtko
>
> >
> > BR,
> > -R
> >
> >> Indeed that one hardcodes:
> >>
> >> static const char drm_amdgpu_vram[] = "drm-memory-vram";
> >>
> >> And does brute strcmp on it:
> >>
> >> } else if (!strcmp(key, drm_amdgpu_vram_old) || !strcmp(key,
> >> drm_amdgpu_vram)) {
> >>
> >> So okay for that one, if we need to keep it working I just change this in
> >> my RFC:
> >>
> >> """
> >> Resident category is identical to the drm-memory- key and two should
> >> be
> >> mutually exclusive.
> >> """
> >>
> >> Into this:
> >>
> >> """
> >> Resident category is identical to the drm-memory- key and where the
> >> categorized one is present the legacy one must be too in order to preserve
> >> backward compatibility.
> >> """
> >>
> >> Addition to my RFC:
> >>
> >> ...
> >> for (i = 0; i < num; i++) {
> >> if (!regions[i]) /* Allow sparse name arrays. */
> >> continue;
> >>
> >> print_stat(p, "size", regions[i], stats[i].size);
> >> print_stat(p, "shared", regions[i], stats[i].shared);
> >> + print_stat(p, "", regions[i], stats[i].resident);
> >> print_stat(p, "resident", regions[i], stats[i].resident);
> >> print_stat(p, "purgeable", regions[i],
> >> stats[i].purgeable);
> >> print_stat(p, "active", regions[i], stats[i].active);
> >> }
> >> ...
> >>
> >> Results in output like this (in theory, if/when amdgpu takes on the
> >> extended format):
> >>
> >> drm-memory-vram-size: ... KiB
> >> drm-memory-vram: $same KiB
> >> drm-memory-vram-resident: $same KiB
> >> drm-memory-vram-...:
> >>
> >> Regards,
> >>
> >> Tvrtko
> >>
> >> P.S. Would a slash instead of a caret be prettier?
> >>
> What tool barfs on it and how? Spirit of drm-usage-stats.pl is that for
> both drm-engine-: and drm-memory-: generic userspace is
> supposed to take the whole as opaque and just enumerate all it
> finds.
>
> Gputop manages to do that with engines names it knows _nothing_ about.
> If it worked with memory regions it would j
Re: [Intel-gfx] [PATCH 0/2] Add support for dumping error captures via kernel logging
On Tue, Apr 11, 2023 at 06:50:53PM +0200, Daniel Vetter wrote: > On Tue, Apr 11, 2023 at 09:41:04AM -0700, John Harrison wrote: > > On 4/11/2023 07:41, Rodrigo Vivi wrote: > > > On Mon, Apr 10, 2023 at 12:25:21PM -0700, john.c.harri...@intel.com wrote: > > > > From: John Harrison > > > > > > > > Sometimes, the only effective way to debug an issue is to dump all the > > > > interesting information at the point of failure. So add support for > > > > doing that. > > > No! Please no! > > > We have some of this on Xe and I'm hating it. I'm going to try to remove > > > from there soon. It is horrible when you lost the hability to use dmesg > > > directly because it goes over the number of lines it saves... or even > > > with dmesg -w it goes over the number of lines of your terminal... > > > or the ssh and serial slowness when printing a bunch of information. > > > > > > We probably want to be able to capture multiple error states and be > > > able to cross them with a kernel timeline, but definitely not overflood > > > our log terminals. > > I think you are missing the point. > > > > This is the emergency backup plan for when nothing else works. It is not on > > by default. It should never happen on an end user system unless we > > specifically request them to run with a patched kernel to enable a dump at a > > specific point. > > > > But there are (many) times when nothing else works. In those instances, it > > is extremely useful to be able to dump the system state in this manner. > > > > It is code we have been using internally for some time and it has helped > > resolve a number of different difficult to debug bugs. As our Xe generation > > platforms are now out in the wild and no longer just internal, it is also > > proving important to have this facility available in upstream trees as well. > > And having it merged rather than floating around as random patches passed > > from person to person is far easier to manage and would also help reduce the > > internal tree burden. Okay then. As long as it depends on some DEBUG config which depends on EXPERT I believe we have a good reason. I see the second patch is indeed protected by CONFIG_DRM_I915_DEBUG_GUC. It would be good to do something similar on the patch 1? > > Note that Xe needs to move over to devcoredump infrastructure, so if you > need dumping straight to dmesg that would be a patch for that subsystem in > the future. devcoredump is a nice thing and it does deserves a bit of improvements to be able to catch snapshots and all, but for this case here I believe that the current devcoredump infrastructure would already be enough. It would be only a matter of doing an immediate print to the dmesg at the moment that devcoredump is created and this is inside the driver. But yeap, that would need to be protected by debug/expert kconfig. > > Not sure how much you want to add fun here in the i915-gem deadend, I'll > leave that up to i915 maintainers. > > Just figured this is a good place to drop this aside :-) > -Daniel > > > > > John. > > > > > > Signed-off-by: John Harrison > > > > > > > > > > > > John Harrison (2): > > > >drm/i915: Dump error capture to kernel log > > > >drm/i915/guc: Dump error capture to dmesg on CTB error > > > > > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 53 + > > > > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 + > > > > drivers/gpu/drm/i915/i915_gpu_error.c | 130 ++ > > > > drivers/gpu/drm/i915/i915_gpu_error.h | 8 ++ > > > > 4 files changed, 197 insertions(+) > > > > > > > > -- > > > > 2.39.1 > > > > > > > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch
[Intel-gfx] [PATCH v4] drm/i915: Initialize dkl_phy spin lock from display code path
Start to move the initialization of display locks from i915_driver_early_probe(), this way it is also executed when running Xe kmd. This will fix a warning in Xe kmd: [ 201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] failed to retrieve link info, disabling eDP [ 202.136336] xe :00:02.0: [drm] *ERROR* Failed to write source OUI [ 202.175346] INFO: trying to register non-static key. [ 202.175347] irq event stamp: 754060 [ 202.175359] hardirqs last enabled at (754059): [] tick_nohz_idle_enter+0x59/0x80 [ 202.180294] The code is fine but needs lockdep annotation, or maybe [ 202.183774] hardirqs last disabled at (754060): [] do_idle+0x99/0x230 [ 202.192734] you didn't initialize this object before use? [ 202.198951] softirqs last enabled at (753948): [] irq_exit_rcu+0xbe/0x130 [ 202.206882] turning off the locking correctness validator. [ 202.212236] softirqs last disabled at (753943): [] irq_exit_rcu+0xbe/0x130 [ 202.220592] CPU: 2 PID: 1415 Comm: modprobe Tainted: GW 6.3.0-rc4+zeh-xe+ #909 [ 202.243002] Hardware name: Intel Corporation Raptor Lake Client Platform/RaptorLake-P LP5 RVP, BIOS RPLPFWI1.R00.3361.A14.2211151548 11/15/2022 [ 202.255737] Call Trace: [ 202.258179] [ 202.260275] dump_stack_lvl+0x58/0xc0 [ 202.263922] register_lock_class+0x756/0x7d0 [ 202.268165] ? find_held_lock+0x2b/0x80 [ 202.271975] __lock_acquire+0x72/0x28b0 [ 202.275786] ? debug_object_free+0xb4/0x160 [ 202.279946] lock_acquire+0xd1/0x2d0 [ 202.283503] ? intel_dkl_phy_read+0x18/0x60 [xe] [ 202.288181] _raw_spin_lock+0x2a/0x40 [ 202.291825] ? intel_dkl_phy_read+0x18/0x60 [xe] [ 202.296475] intel_dkl_phy_read+0x18/0x60 [xe] [ 202.300949] icl_aux_power_well_enable+0x2bd/0x400 [xe] [ 202.306202] ? intel_display_power_grab_async_put_ref+0x75/0x120 [xe] [ 202.312649] intel_power_well_enable+0x1c/0x70 [xe] [ 202.317543] __intel_display_power_get_domain.part.0+0x4d/0x70 [xe] [ 202.323812] intel_display_power_get+0x43/0x70 [xe] [ 202.328708] intel_tc_port_init+0x199/0x2a0 [xe] [ 202.63] intel_ddi_init+0x6ad/0xb00 [xe] [ 202.337678] intel_modeset_init_nogem+0x536/0x6d0 [xe] [ 202.342838] xe_display_init_noaccel+0x19/0x40 [xe] [ 202.347743] xe_device_probe+0x1f5/0x2a0 [xe] [ 202.352127] xe_pci_probe+0x28c/0x480 [xe] [ 202.356260] pci_device_probe+0x9d/0x150 [ 202.360164] really_probe+0x19a/0x400 [ 202.363809] ? __pfx___driver_attach+0x10/0x10 [ 202.368226] __driver_probe_device+0x73/0x170 [ 202.372558] driver_probe_device+0x1a/0x90 [ 202.376632] __driver_attach+0xcd/0x1c0 [ 202.380442] bus_for_each_dev+0x72/0xc0 [ 202.384253] bus_add_driver+0x110/0x210 [ 202.388063] driver_register+0x50/0x100 [ 202.391873] ? __pfx_init_module+0x10/0x10 [xe] [ 202.396431] do_one_initcall+0x55/0x260 [ 202.400245] ? rcu_is_watching+0xd/0x40 [ 202.404058] ? kmalloc_trace+0xa0/0xb0 [ 202.407786] do_init_module+0x45/0x1e0 [ 202.411512] __do_sys_finit_module+0xac/0x120 [ 202.415838] do_syscall_64+0x37/0x90 [ 202.419397] entry_SYSCALL_64_after_hwframe+0x72/0xdc [ 202.424409] RIP: 0033:0x7fd11291ea3d [ 202.427967] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d c3 a3 0f 00 f7 d8 64 89 01 48 [ 202.446530] RSP: 002b:7de11368 EFLAGS: 0246 ORIG_RAX: 0139 [ 202.454031] RAX: ffda RBX: 5616a617f210 RCX: 7fd11291ea3d [ 202.461106] RDX: RSI: 5616a617fe60 RDI: 000e [ 202.468182] RBP: 0004 R08: R09: 0002 [ 202.475250] R10: 000e R11: 0246 R12: 5616a617fe60 [ 202.482319] R13: 5616a617f340 R14: R15: 5616a6180650 [ 202.489396] v2: - added intel_display_locks_init() v3: - rebased v4: - drop intel_display_locks_init() Cc: intel-gfx@lists.freedesktop.org Cc: intel...@lists.freedesktop.org Cc: Rodrigo Vivi Cc: Ville Syrjälä Cc: Jani Nikula Cc: Maarten Lankhorst Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_display_driver.c | 2 ++ drivers/gpu/drm/i915/display/intel_dkl_phy.c| 5 + drivers/gpu/drm/i915/display/intel_dkl_phy.h| 1 + drivers/gpu/drm/i915/i915_driver.c | 1 - 4 files changed, 8 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c b/drivers/gpu/drm/i915/display/intel_display_driver.c index b3dbfe2a892e6..60ce10fc72058 100644 --- a/drivers/gpu/drm/i915/display/intel_display_driver.c +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c @@ -30,6 +30,7 @@ #include "intel_display_driver.h" #include "intel_display_power.h" #include "intel_display_types.h" +#include "intel_dkl_phy.h" #include "intel_dmc.h" #include "intel_dp.h" #include "intel_dpll.h" @@ -175,6 +176,7 @@ void intel_display_driver_early_probe(str
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On 18/04/2023 17:13, Rob Clark wrote: On Tue, Apr 18, 2023 at 7:46 AM Tvrtko Ursulin wrote: On 18/04/2023 15:36, Rob Clark wrote: On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin wrote: On 18/04/2023 14:49, Rob Clark wrote: On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin wrote: On 17/04/2023 20:39, Rob Clark wrote: On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin wrote: From: Tvrtko Ursulin Add support to dump GEM stats to fdinfo. Signed-off-by: Tvrtko Ursulin --- Documentation/gpu/drm-usage-stats.rst | 12 +++ drivers/gpu/drm/drm_file.c| 52 +++ include/drm/drm_drv.h | 7 include/drm/drm_file.h| 8 + 4 files changed, 79 insertions(+) diff --git a/Documentation/gpu/drm-usage-stats.rst b/Documentation/gpu/drm-usage-stats.rst index 2ab32c40e93c..8273a41b2fb0 100644 --- a/Documentation/gpu/drm-usage-stats.rst +++ b/Documentation/gpu/drm-usage-stats.rst @@ -21,6 +21,7 @@ File format specification - File shall contain one key value pair per one line of text. - Colon character (`:`) must be used to delimit keys and values. +- Caret (`^`) is also a reserved character. this doesn't solve the problem that led me to drm-$CATEGORY-memory... ;-) Could you explain or remind me with a link to a previous explanation? How is userspace supposed to know that "drm-memory-foo" is a memory type "foo" but drm-memory-foo^size is not memory type "foo^size"? Are you referring to nvtop? I'm not referring to any particular app. It could even be some app that isn't even written yet but started with an already existing kernel without this change. It is just a general point about forwards compatibility of old userspace with new kernel. And it doesn't really matter what special character you use. You can't retroactively define some newly special characters. What you see does not work if we output both legacy and new key with extra category? Userspace which hardcode the name keep working, and userspace which parses region names as opaque strings also keeps working just shows more entries. well, it shows nonsense entries.. I'd not call that "working" But honestly we are wasting too many words on this.. we just can't re-use the "drm-memory-" namespace, it is already burnt. Full stop. If you don't like the "drm-$CATEGORY-$REGION" workaround then we can shorten to "drm-mem-$REGION-$CATEGORY" since that won't accidentally match the existing "drm-memory-" pattern. I can live with that token reversal, it was not the primary motivation for my RFC as we have discussed that side of things already before I sketched my version up. But I also still don't get what doesn't work with what I described and you did not really address my specific questions with more than a "doesn't work" with not much details. Unless for you it starts and ends with "nonsense entries". If so then it seems there is no option than to disagree and move on. Again, I can accept the drm-$category-memory-$region. Regards, Tvrtko
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Tue, 18 Apr 2023 05:02:44 +
"Tian, Kevin" wrote:
> > From: Alex Williamson
> > Sent: Tuesday, April 18, 2023 12:11 PM
> >
> > On Tue, 18 Apr 2023 03:24:46 +
> > "Tian, Kevin" wrote:
> >
> > > > From: Alex Williamson
> > > > Sent: Tuesday, April 18, 2023 4:07 AM
> > > >
> > > > On Mon, 17 Apr 2023 16:31:56 -0300
> > > > Jason Gunthorpe wrote:
> > > >
> > > > > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > > > > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > > > > mixing groups, cdevs, and multiple iommufd_ctxs as invalid. I think
> > > > > > this means that regardless of which device calls INFO, there's only
> > > > > > one
> > > > > > answer (assuming same set of devices opened, all cdev, all within
> > same
> > > > > > iommufd_ctx). Based on what I explained about my understanding of
> > > > INFO2
> > > > > > and Jason agreed to, I think the output would be:
> > > > > >
> > > > > > flags: NOT_RESETABLE | DEV_ID
> > > > > > {
> > > > > > { valid devA-id, devA-BDF },
> > > > > > { valid devC-id, devC-BDF },
> > > > > > { valid devD-id, devD-BDF },
> > > > > > { invalid dev-id, devE-BDF },
> > > > > > }
> > > > > >
> > > > > > Here devB gets dropped because the kernel understands that devB is
> > > > > > unopened, affected, and owned. It's therefore not a blocker for
> > > > > > hot-reset.
> > > > >
> > > > > I don't think we want to drop anything because it makes the API
> > > > > ill suited for the debugging purpose.
> > > > >
> > > > > devb should be returned with an invalid dev_id if I understand your
> > > > > example. Maybe it should return with -1 as the dev_id instead of 0, to
> > > > > make the debugging a bit better.
> > > > >
> > > > > Userspace should look at only NOT_RESETTABLE to determine if it
> > > > > proceeds or not, and it should use the valid dev_id list to iterate
> > > > > over the devices it has open to do the config stuff.
> > > >
> > > > If an affected device is owned, not opened, and not interfering with
> > > > the reset, what is it adding to the API to report it for debugging
> > > > purposes? I'm afraid this leads into expanding "invalid dev-id" into
> > > > an
> > >
> > > consistent output before and after devB is opened.
> >
> > In the case where devB is not opened including it only provides
> > useless information. In the case where devB is opened it's necessary
> > to be reported as an opened, affected device.
> >
> > > > errno or bitmap of error conditions that the user needs to parse.
> > > >
> > >
> > > Not exactly.
> > >
> > > If RESETABLE invalid dev_id doesn't matter. The user only use the
> > > valid dev_id list to iterate as Jason pointed out.
> >
> > Yes, but...
> >
> > > If NOT_RESETTABLE due to devE not assigned to the VM one can
> > > easily figure out the fact by simply looking at the list of affected BDFs
> > > and the configuration of assigned devices of the VM. Then invalid
> > > dev_id also doesn't matter.
> >
> > Huh?
> >
> > Given:
> >
> > flags: NOT_RESETABLE | DEV_ID
> > {
> > { valid devA-id, devA-BDF },
> > { invalid dev-id, devB-BDF },
> > { valid devC-id, devC-BDF },
> > { valid devD-id, devD-BDF },
> > { invalid dev-id, devE-BDF },
> > }
> >
> > How does the user determine that devE is to blame and not devB based on
> > BDF? The user cannot rely on sysfs for help, they don't know the IOMMU
> > grouping, nor do they know the BDF except as inferred by matching valid
> > dev-ids in the above output.
>
> emmm aren't we talking about the 'person' who does diagnostic? This guy
> will look at the VM configuration file to know that devA/B/C/D have been
> assigned to the VM but not devE.
Actually the scenario is that devA/C/D are assigned, devB is implicitly
owned, and it's devE that blocks the reset. If you've followed any of
the community forums for vfio over the years, it should be readily
apparent that placing the burden solely on the end user to perform such
a diagnosis is an unreasonable expectation.
> > > If NOT_RESETTABLE while devE is already assigned to the VM then it's
> > > indication of mixing groups, cdevs or multiple iommufd_ctxs. Then
> > > people should debug with other means/hints to dig out the exact
> > > culprit.
> >
> > I don't know what situation you're trying to explain here. If devE
> > were opened within the same iommufd_ctx, this becomes:
>
> It's about a scenario where the mgmt.. stack has assigned all affected
> devices to Qemu but Qemu itself messed it up with mixed group/cdev
> or multiple iommufd_ctx so hitting the NON_RESETTABLE situation.
Is this a reasonable scenario? I expect the QEMU support to favor cdev
access where available and fd passing methods will only use cdev, so
QEMU should never mess up to create such an environment. There should
never be a case where a device is exclusively available via group
rather than cdev.
> > flags: RESETABLE | DEV_ID
> > {
> >
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Tue, 18 Apr 2023 10:34:45 + "Liu, Yi L" wrote: > > From: Alex Williamson > > Sent: Tuesday, April 18, 2023 12:11 PM > > > [...] > > > > We haven't discussed how it fails when called on a group-opened device > > in a mixed environment. I'd propose that the INFO ioctl behaves > > exactly as it does today, reporting group-id and BDF for each affected > > device. However, the hot-reset ioctl itself is not extended to accept > > devicefd because there is no proof-of-ownership model for cdevs. > > Therefore even if the user could map group-id to devicefd, they get > > -EINVAL calling HOT_RESET with a devicefd when the ioctl is called from > > a group-opened device. Thanks, > > Will it be better to let userspace know it shall fail if invoking hot > reset due to no proof-of-ownership as it also has cdev devices? Maybe > the RESETTABLE flag should always be meaningful. Even if the calling > device of _INFO is group-opened device. Old user applications does not > need to check it as it will never have such mixed environment. But for > new applications or the applications that have been updated per latest > vfio uapi, it should strictly check this flag before going ahead to do > hot-reset. The group-opened model cannot consistently predict whether the user can provide proof-of-ownership. I don't think we should define a flag simply because there's a case that we can predict, the definition of that flag becomes problematic. Let's not complicate the interface by trying to optimize a case that will likely never exist in practice and can be handled via the existing legacy API. Thanks, Alex
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Increase AUX timeout for Type-C (rev8)
== Series Details ==
Series: drm/i915/display: Increase AUX timeout for Type-C (rev8)
URL : https://patchwork.freedesktop.org/series/116010/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13026_full -> Patchwork_116010v8_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116010v8_full:
### IGT changes ###
Possible regressions
* {igt@kms_vblank} (NEW):
- {shard-tglu}: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-tglu-5/igt@kms_vblank.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_vblank@pipe-g-query-idle:
- {shard-dg1}:NOTRUN -> [SKIP][2] +31 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-dg1-16/igt@kms_vbl...@pipe-g-query-idle.html
* igt@kms_vblank@pipe-h-wait-idle:
- {shard-tglu}: NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-tglu-5/igt@kms_vbl...@pipe-h-wait-idle.html
New tests
-
New tests have been introduced between CI_DRM_13026_full and
Patchwork_116010v8_full:
### New IGT tests (1) ###
* igt@kms_vblank:
- Statuses : 1 incomplete(s)
- Exec time: [0.0] s
Known issues
Here are the changes found in Patchwork_116010v8_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [PASS][4] -> [FAIL][5] ([i915#2842])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-apl6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][6] -> [ABORT][7] ([i915#5566])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-glk8/igt@gen9_exec_pa...@allowed-single.html
*
igt@kms_plane_scaling@planes-downscale-factor-0-5-unity-scaling@pipe-b-vga-1:
- shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271]) +40 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-snb5/igt@kms_plane_scaling@planes-downscale-factor-0-5-unity-scal...@pipe-b-vga-1.html
Possible fixes
* igt@gem_barrier_race@remote-request@rcs0:
- {shard-tglu}: [ABORT][9] ([i915#8211]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/shard-tglu-9/igt@gem_barrier_race@remote-requ...@rcs0.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-tglu-5/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [FAIL][11] ([i915#2842]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-apl1/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- {shard-tglu}: [FAIL][13] ([i915#2842]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/shard-tglu-10/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-tglu-9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- {shard-rkl}:[SKIP][15] ([i915#1397]) -> [PASS][16] +4 similar
issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/shard-rkl-1/igt@i915_pm_...@dpms-mode-unset-lpsp.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-rkl-7/igt@i915_pm_...@dpms-mode-unset-lpsp.html
* igt@i915_pm_rpm@modeset-lpsp:
- {shard-dg1}:[SKIP][17] ([i915#1397]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/shard-dg1-16/igt@i915_pm_...@modeset-lpsp.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-dg1-14/igt@i915_pm_...@modeset-lpsp.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-apl: [FAIL][19] ([i915#2346]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116010v8/shard-apl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.htm
Re: [Intel-gfx] [RFC 3/6] drm: Add fdinfo memory stats
On Tue, Apr 18, 2023 at 9:44 AM Tvrtko Ursulin wrote: > > > On 18/04/2023 17:13, Rob Clark wrote: > > On Tue, Apr 18, 2023 at 7:46 AM Tvrtko Ursulin > > wrote: > >> On 18/04/2023 15:36, Rob Clark wrote: > >>> On Tue, Apr 18, 2023 at 7:19 AM Tvrtko Ursulin > >>> wrote: > > > On 18/04/2023 14:49, Rob Clark wrote: > > On Tue, Apr 18, 2023 at 2:00 AM Tvrtko Ursulin > > wrote: > >> > >> > >> On 17/04/2023 20:39, Rob Clark wrote: > >>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin > >>> wrote: > > From: Tvrtko Ursulin > > Add support to dump GEM stats to fdinfo. > > Signed-off-by: Tvrtko Ursulin > --- > Documentation/gpu/drm-usage-stats.rst | 12 +++ > drivers/gpu/drm/drm_file.c| 52 > +++ > include/drm/drm_drv.h | 7 > include/drm/drm_file.h| 8 + > 4 files changed, 79 insertions(+) > > diff --git a/Documentation/gpu/drm-usage-stats.rst > b/Documentation/gpu/drm-usage-stats.rst > index 2ab32c40e93c..8273a41b2fb0 100644 > --- a/Documentation/gpu/drm-usage-stats.rst > +++ b/Documentation/gpu/drm-usage-stats.rst > @@ -21,6 +21,7 @@ File format specification > > - File shall contain one key value pair per one line of text. > - Colon character (`:`) must be used to delimit keys and values. > +- Caret (`^`) is also a reserved character. > >>> > >>> this doesn't solve the problem that led me to drm-$CATEGORY-memory... > >>> ;-) > >> > >> Could you explain or remind me with a link to a previous explanation? > > > > How is userspace supposed to know that "drm-memory-foo" is a memory > > type "foo" but drm-memory-foo^size is not memory type "foo^size"? > > Are you referring to nvtop? > >>> > >>> I'm not referring to any particular app. It could even be some app > >>> that isn't even written yet but started with an already existing > >>> kernel without this change. It is just a general point about forwards > >>> compatibility of old userspace with new kernel. And it doesn't really > >>> matter what special character you use. You can't retroactively define > >>> some newly special characters. > >> > >> What you see does not work if we output both legacy and new key with > >> extra category? Userspace which hardcode the name keep working, and > >> userspace which parses region names as opaque strings also keeps working > >> just shows more entries. > > > > well, it shows nonsense entries.. I'd not call that "working" > > > > But honestly we are wasting too many words on this.. we just can't > > re-use the "drm-memory-" namespace, it is already burnt. > > Full stop. > > > > If you don't like the "drm-$CATEGORY-$REGION" workaround then we can > > shorten to "drm-mem-$REGION-$CATEGORY" since that won't accidentally > > match the existing "drm-memory-" pattern. > > I can live with that token reversal, it was not the primary motivation > for my RFC as we have discussed that side of things already before I > sketched my version up. > > But I also still don't get what doesn't work with what I described and > you did not really address my specific questions with more than a > "doesn't work" with not much details. > > Unless for you it starts and ends with "nonsense entries". If so then it > seems there is no option than to disagree and move on. Again, I can > accept the drm-$category-memory-$region. Yeah, it's about "nonsense entries".. and I am perhaps being a bit pedantic about compatibility with old userspace (not like there are 100's of apps parsing drm fdinfo), but it is the principle of the matter ;-) BR, -R
Re: [Intel-gfx] [RFC 4/6] drm: Add simple fdinfo memory helpers
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> For drivers who only wish to show one memory region called 'system,
> and only account the GEM buffer object handles under it.
>
> Signed-off-by: Tvrtko Ursulin
> ---
> drivers/gpu/drm/drm_file.c | 45 ++
> include/drm/drm_file.h | 6 +
> 2 files changed, 51 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index e202f79e816d..1e70669dddf7 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -872,6 +872,51 @@ void drm_send_event(struct drm_device *dev, struct
> drm_pending_event *e)
> }
> EXPORT_SYMBOL(drm_send_event);
>
> +static void
> +add_obj(struct drm_gem_object *obj, struct drm_fdinfo_memory_stat *stats)
> +{
> + u64 sz = obj->size;
> +
> + stats[0].size += sz;
> +
> + if (obj->handle_count > 1)
> + stats[0].shared += sz;
> +
> + if (!dma_resv_test_signaled(obj->resv, dma_resv_usage_rw(true)))
> + stats[0].active += sz;
> +
> + /* Not supported. */
> + stats[0].resident = ~0ull;
> + stats[0].purgeable = ~0ull;
Hmm, this kinda makes the simple helper not very useful. In my
version, you get something that is useful for all UMA drivers (which
all, IIRC, have some form of madv ioctl). I was kinda imagining that
for ttm drivers, my print_memory_stats() would just become a helper
and that TTM (or "multi-region") drivers would have their own thing.
BR,
-R
> +}
> +
> +char **
> +drm_query_fdinfo_system_region(struct drm_device *dev, unsigned int *num)
> +{
> + static char *region[] = {
> + "system",
> + };
> +
> + *num = 1;
> +
> + return region;
> +}
> +EXPORT_SYMBOL(drm_query_fdinfo_system_region);
> +
> +void
> +drm_query_fdinfo_system_memory(struct drm_file *file,
> + struct drm_fdinfo_memory_stat *stats)
> +{
> + struct drm_gem_object *obj;
> + int id;
> +
> + spin_lock(&file->table_lock);
> + idr_for_each_entry(&file->object_idr, obj, id)
> + add_obj(obj, stats);
> + spin_unlock(&file->table_lock);
> +}
> +EXPORT_SYMBOL(drm_query_fdinfo_system_memory);
> +
> static void
> print_stat(struct drm_printer *p, const char *stat, const char *region, u64
> sz)
> {
> diff --git a/include/drm/drm_file.h b/include/drm/drm_file.h
> index 00d48beeac5c..dd7c6fb2c975 100644
> --- a/include/drm/drm_file.h
> +++ b/include/drm/drm_file.h
> @@ -383,6 +383,12 @@ struct drm_fdinfo_memory_stat {
> u64 active;
> };
>
> +char **drm_query_fdinfo_system_region(struct drm_device *dev,
> + unsigned int *num);
> +void drm_query_fdinfo_system_memory(struct drm_file *file,
> + struct drm_fdinfo_memory_stat *stats);
> +
> +
> /**
> * drm_is_primary_client - is this an open file of the primary node
> * @file_priv: DRM file
> --
> 2.37.2
>
Re: [Intel-gfx] [PATCH 1/2] drm/i915/display: split out load detect to a separate file
On Mon, Apr 17, 2023 at 06:37:40PM +0300, Jani Nikula wrote:
> Load detect is shared between tv and crt but otherwise isolated in
> intel_display.c.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_crt.c | 5 +-
> drivers/gpu/drm/i915/display/intel_display.c | 215
> drivers/gpu/drm/i915/display/intel_display.h | 7 -
> .../drm/i915/display/intel_display_types.h| 4 -
> .../gpu/drm/i915/display/intel_load_detect.c | 229 ++
> .../gpu/drm/i915/display/intel_load_detect.h | 24 ++
> drivers/gpu/drm/i915/display/intel_tv.c | 5 +-
> 8 files changed, 260 insertions(+), 230 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_load_detect.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_load_detect.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 154986359169..9af76e376ca9 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -261,6 +261,7 @@ i915-y += \
> display/intel_hdcp_gsc.o \
> display/intel_hotplug.o \
> display/intel_hti.o \
> + display/intel_load_detect.o \
> display/intel_lpe_audio.o \
> display/intel_modeset_verify.o \
> display/intel_modeset_setup.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index 38e9c61c2344..96acdf98a0c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -48,6 +48,7 @@
> #include "intel_fifo_underrun.h"
> #include "intel_gmbus.h"
> #include "intel_hotplug.h"
> +#include "intel_load_detect.h"
> #include "intel_pch_display.h"
> #include "intel_pch_refclk.h"
>
> @@ -881,7 +882,7 @@ intel_crt_detect(struct drm_connector *connector,
> }
>
> /* for pre-945g platforms use load detect */
> - ret = intel_get_load_detect_pipe(connector, &tmp, ctx);
> + ret = intel_load_detect_get_pipe(connector, &tmp, ctx);
> if (ret > 0) {
> if (intel_crt_detect_ddc(connector))
> status = connector_status_connected;
> @@ -892,7 +893,7 @@ intel_crt_detect(struct drm_connector *connector,
> status = connector_status_disconnected;
> else
> status = connector_status_unknown;
> - intel_release_load_detect_pipe(connector, &tmp, ctx);
> + intel_load_detect_release_pipe(connector, &tmp, ctx);
> } else if (ret == 0) {
> status = connector_status_unknown;
> } else {
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 1c264c17b6e4..2d4a6936ab2b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -3821,221 +3821,6 @@ bool intel_crtc_get_pipe_config(struct
> intel_crtc_state *crtc_state)
> return true;
> }
>
> -/* VESA 640x480x72Hz mode to set on the pipe */
> -static const struct drm_display_mode load_detect_mode = {
> - DRM_MODE("640x480", DRM_MODE_TYPE_DEFAULT, 31500, 640, 664,
> - 704, 832, 0, 480, 489, 491, 520, 0, DRM_MODE_FLAG_NHSYNC |
> DRM_MODE_FLAG_NVSYNC),
> -};
> -
> -static int intel_modeset_disable_planes(struct drm_atomic_state *state,
> - struct drm_crtc *crtc)
> -{
> - struct drm_plane *plane;
> - struct drm_plane_state *plane_state;
> - int ret, i;
> -
> - ret = drm_atomic_add_affected_planes(state, crtc);
> - if (ret)
> - return ret;
> -
> - for_each_new_plane_in_state(state, plane, plane_state, i) {
> - if (plane_state->crtc != crtc)
> - continue;
> -
> - ret = drm_atomic_set_crtc_for_plane(plane_state, NULL);
> - if (ret)
> - return ret;
> -
> - drm_atomic_set_fb_for_plane(plane_state, NULL);
> - }
> -
> - return 0;
> -}
> -
> -int intel_get_load_detect_pipe(struct drm_connector *connector,
> -struct intel_load_detect_pipe *old,
> -struct drm_modeset_acquire_ctx *ctx)
> -{
> - struct intel_encoder *encoder =
> - intel_attached_encoder(to_intel_connector(connector));
> - struct intel_crtc *possible_crtc;
> - struct intel_crtc *crtc = NULL;
> - struct drm_device *dev = encoder->base.dev;
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct drm_mode_config *config = &dev->mode_config;
> - struct drm_atomic_state *state = NULL, *restore_state = NULL;
> - struct drm_connector_state *connector_state;
> - struct intel_crtc_state *crtc_state;
> - int ret;
> -
> - drm_dbg_kms(&dev_priv->drm, "[CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
> - connec
Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete
On Mon, 17 Apr 2023 22:35:58 -0700, Rodrigo Vivi wrote:
>
Hi Rodrigo,
> On Mon, Apr 10, 2023 at 03:35:09PM -0700, Ashutosh Dixit wrote:
> > Instead of erroring out when GuC reset is in progress, block waiting for
> > GuC reset to complete which is a more reasonable uapi behavior.
> >
> > v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
> >
> > Signed-off-by: Ashutosh Dixit
> > ---
> > drivers/gpu/drm/i915/i915_hwmon.c | 38 +++
> > 1 file changed, 33 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 9ab8971679fe3..8471a667dfc71 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -51,6 +51,7 @@ struct hwm_drvdata {
> > char name[12];
> > int gt_n;
> > bool reset_in_progress;
> > + wait_queue_head_t waitq;
> > };
> >
> > struct i915_hwmon {
> > @@ -395,16 +396,41 @@ hwm_power_max_read(struct hwm_drvdata *ddat, long
> > *val)
> > static int
> > hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> > {
> > +#define GUC_RESET_TIMEOUT msecs_to_jiffies(2000)
> > +
> > + int ret = 0, timeout = GUC_RESET_TIMEOUT;
> > struct i915_hwmon *hwmon = ddat->hwmon;
> > intel_wakeref_t wakeref;
> > - int ret = 0;
> > + DEFINE_WAIT(wait);
> > u32 nval;
> >
> > - mutex_lock(&hwmon->hwmon_lock);
> > - if (hwmon->ddat.reset_in_progress) {
> > - ret = -EAGAIN;
> > - goto unlock;
> > + /* Block waiting for GuC reset to complete when needed */
> > + for (;;) {
> > + mutex_lock(&hwmon->hwmon_lock);
>
> I'm really afraid of how this mutex is handled with the wait queue.
> some initial thought it looks like it is trying to reimplement ww_mutex?
Sorry, but I am missing the relation with ww_mutex. No such relation is
intended.
> all other examples of the wait_queue usages like this or didn't use
> locks or had it in a total different flow that I could not correlate.
Actually there are several examples of prepare_to_wait/finish_wait
sequences with both spinlock and mutex in the kernel. See
e.g. rpm_suspend(), wait_for_rtrs_disconnection(), softsynthx_read().
Also, as I mentioned, except for the lock, the sequence here is identical
to intel_guc_wait_for_pending_msg().
>
> > +
> > + prepare_to_wait(&ddat->waitq, &wait, TASK_INTERRUPTIBLE);
> > +
> > + if (!hwmon->ddat.reset_in_progress)
> > + break;
>
> If this breaks we never unlock it?
Correct, this is the original case in Patch 2 where the mutex is acquired
in the beginning of the function and released just before the final exit
from the function (so the mutex is held for the entire duration of the
function).
>
> > +
> > + if (signal_pending(current)) {
> > + ret = -EINTR;
> > + break;
> > + }
> > +
> > + if (!timeout) {
> > + ret = -ETIME;
> > + break;
> > + }
> > +
> > + mutex_unlock(&hwmon->hwmon_lock);
>
> do we need to lock the signal pending and timeout as well?
> or only wrapping it around the hwmon->ddat access would be
> enough?
Strictly, the mutex is only needed for the hwmon->ddat.reset_in_progress
flag. But because this is not a performance path, implementing it as done
in the patch simplifies the code flow (since there are several if/else,
goto's, mutex lock/unlock and prepare_to_wait/finish_wait to consider).
So if possible I *really* want to not try to over-optimize here (I did try
a few other things when writing the patch but it was getting ugly). The
only real requirement is to drop the lock before calling schedule_timeout()
below (and we are reacquiring the lock as soon as we are scheduled back in,
as you can see in the loop above).
>
> > +
> > + timeout = schedule_timeout(timeout);
> > }
> > + finish_wait(&ddat->waitq, &wait);
> > + if (ret)
> > + goto unlock;
> > +
> > wakeref = intel_runtime_pm_get(ddat->uncore->rpm);
> >
> > /* Disable PL1 limit and verify, because the limit cannot be disabled
> > on all platforms */
> > @@ -508,6 +534,7 @@ void i915_hwmon_power_max_restore(struct
> > drm_i915_private *i915, bool old)
> > intel_uncore_rmw(hwmon->ddat.uncore, hwmon->rg.pkg_rapl_limit,
> > PKG_PWR_LIM_1_EN, old ? PKG_PWR_LIM_1_EN : 0);
> > hwmon->ddat.reset_in_progress = false;
> > + wake_up_all(&hwmon->ddat.waitq);
> >
> > mutex_unlock(&hwmon->hwmon_lock);
> > }
> > @@ -784,6 +811,7 @@ void i915_hwmon_register(struct drm_i915_private *i915)
> > ddat->uncore = &i915->uncore;
> > snprintf(ddat->name, sizeof(ddat->name), "i915");
> > ddat->gt_n = -1;
> > + init_waitqueue_head(&ddat->waitq);
> >
> > for_each_gt(gt, i915, i) {
> > ddat_gt = hwmon->ddat_gt + i;
> > --
> > 2.38.0
> >
From what I understand is the locking above is fine and is
Re: [Intel-gfx] [PATCH 2/2] drm/i915/display: throw out struct intel_load_detect_pipe
On Mon, Apr 17, 2023 at 06:37:41PM +0300, Jani Nikula wrote:
> An error-valued pointer can handle all in one without the wrapper
> struct.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_crt.c | 18 -
> .../gpu/drm/i915/display/intel_load_detect.c | 20 ---
> .../gpu/drm/i915/display/intel_load_detect.h | 12 ---
> drivers/gpu/drm/i915/display/intel_tv.c | 16 +++
> 4 files changed, 29 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crt.c
> b/drivers/gpu/drm/i915/display/intel_crt.c
> index 96acdf98a0c0..13519f78cf9f 100644
> --- a/drivers/gpu/drm/i915/display/intel_crt.c
> +++ b/drivers/gpu/drm/i915/display/intel_crt.c
> @@ -822,9 +822,9 @@ intel_crt_detect(struct drm_connector *connector,
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> struct intel_crt *crt =
> intel_attached_crt(to_intel_connector(connector));
> struct intel_encoder *intel_encoder = &crt->base;
> + struct drm_atomic_state *state;
> intel_wakeref_t wakeref;
> - int status, ret;
> - struct intel_load_detect_pipe tmp;
> + int status;
>
> drm_dbg_kms(&dev_priv->drm, "[CONNECTOR:%d:%s] force=%d\n",
> connector->base.id, connector->name,
> @@ -882,8 +882,12 @@ intel_crt_detect(struct drm_connector *connector,
> }
>
> /* for pre-945g platforms use load detect */
> - ret = intel_load_detect_get_pipe(connector, &tmp, ctx);
> - if (ret > 0) {
> + state = intel_load_detect_get_pipe(connector, ctx);
> + if (IS_ERR(state)) {
> + status = PTR_ERR(state);
> + } else if (!state) {
> + status = connector_status_unknown;
> + } else {
> if (intel_crt_detect_ddc(connector))
> status = connector_status_connected;
> else if (DISPLAY_VER(dev_priv) < 4)
> @@ -893,11 +897,7 @@ intel_crt_detect(struct drm_connector *connector,
> status = connector_status_disconnected;
> else
> status = connector_status_unknown;
> - intel_load_detect_release_pipe(connector, &tmp, ctx);
> - } else if (ret == 0) {
> - status = connector_status_unknown;
> - } else {
> - status = ret;
> + intel_load_detect_release_pipe(connector, state, ctx);
I confess it took me a while to see that we have the same logic in place.
I think I need more coffee.
Reviewed-by: Rodrigo Vivi
> }
>
> out:
> diff --git a/drivers/gpu/drm/i915/display/intel_load_detect.c
> b/drivers/gpu/drm/i915/display/intel_load_detect.c
> index 5d6bb6d712bc..d5a0aecf3e8f 100644
> --- a/drivers/gpu/drm/i915/display/intel_load_detect.c
> +++ b/drivers/gpu/drm/i915/display/intel_load_detect.c
> @@ -44,9 +44,9 @@ static int intel_modeset_disable_planes(struct
> drm_atomic_state *state,
> return 0;
> }
>
> -int intel_load_detect_get_pipe(struct drm_connector *connector,
> -struct intel_load_detect_pipe *old,
> -struct drm_modeset_acquire_ctx *ctx)
> +struct drm_atomic_state *
> +intel_load_detect_get_pipe(struct drm_connector *connector,
> +struct drm_modeset_acquire_ctx *ctx)
> {
> struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> @@ -64,8 +64,6 @@ int intel_load_detect_get_pipe(struct drm_connector
> *connector,
> connector->base.id, connector->name,
> encoder->base.base.id, encoder->base.name);
>
> - old->restore_state = NULL;
> -
> drm_WARN_ON(dev, !drm_modeset_is_locked(&config->connection_mutex));
>
> /*
> @@ -179,13 +177,12 @@ int intel_load_detect_get_pipe(struct drm_connector
> *connector,
> goto fail;
> }
>
> - old->restore_state = restore_state;
> drm_atomic_state_put(state);
>
> /* let the connector get through one full cycle before testing */
> intel_crtc_wait_for_next_vblank(crtc);
>
> - return true;
> + return restore_state;
>
> fail:
> if (state) {
> @@ -198,27 +195,26 @@ int intel_load_detect_get_pipe(struct drm_connector
> *connector,
> }
>
> if (ret == -EDEADLK)
> - return ret;
> + return ERR_PTR(ret);
>
> - return false;
> + return NULL;
> }
>
> void intel_load_detect_release_pipe(struct drm_connector *connector,
> - struct intel_load_detect_pipe *old,
> + struct drm_atomic_state *state,
> struct drm_modeset_acquire_ctx *ctx)
> {
> struct intel_encoder *intel_encoder =
> intel_attached_encoder(to_intel_connector(connector));
> struct drm_i915_private *i915 = to_i915(intel_encoder->base.dev);
> struct drm_encoder *
[Intel-gfx] [PATCH 00/15] drm/i915: Scaler/pfit stuff
From: Ville Syrjälä One scaler bugfix, and a bunch of scaler/pfit cleanups/etc. Ville Syrjälä (15): drm/i915: Check pipe source size when using skl+ scalers drm/i915: Relocate VBLANK_EVASION_TIME_US drm/i915: Relocate intel_atomic_setup_scalers() drm/i915: Relocate skl_get_pfit_config() drm/i915: Use REG_BIT() & co for the pre-ilk pfit registers drm/i915: Namespace pfit registers properly drm/i915: Use REG_BIT() & co. for ilk+ pfit registers drm/i915: Drop a useless forward declararion drm/i915: Define bitmasks for ilk pfit window pos/size drm/i915: Remove dead scaler register defines drm/i915: Rename skl+ scaler binding bits drm/i915: s/PS_COEE_INDEX_AUTO_INC/PS_COEF_INDEX_AUTO_INC/ drm/i915: Define bitmasks for sik+ scaler window pos/size drm/i915: Use REG_BIT() & co. for pipe scaler registers drm/i915: Define more PS_CTRL bits drivers/gpu/drm/i915/display/intel_atomic.c | 256 -- drivers/gpu/drm/i915/display/intel_atomic.h | 4 - drivers/gpu/drm/i915/display/intel_crtc.h | 10 + drivers/gpu/drm/i915/display/intel_display.c | 82 ++--- .../drm/i915/display/intel_display_debugfs.c | 2 +- drivers/gpu/drm/i915/display/intel_lvds.c | 2 +- drivers/gpu/drm/i915/display/intel_overlay.c | 16 +- drivers/gpu/drm/i915/display/intel_panel.c| 33 +- drivers/gpu/drm/i915/display/intel_sprite.h | 10 - drivers/gpu/drm/i915/display/skl_scaler.c | 331 +- drivers/gpu/drm/i915/display/skl_scaler.h | 12 +- drivers/gpu/drm/i915/i915_reg.h | 210 ++- 12 files changed, 512 insertions(+), 456 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH 02/15] drm/i915: Relocate VBLANK_EVASION_TIME_US
From: Ville Syrjälä Move the VBLANK_EVASION_TIME_US definition to a slightly better place. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_crtc.h| 10 ++ drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +- drivers/gpu/drm/i915/display/intel_sprite.h | 10 -- 3 files changed, 11 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_crtc.h b/drivers/gpu/drm/i915/display/intel_crtc.h index 73077137fb99..51a4c8df9e65 100644 --- a/drivers/gpu/drm/i915/display/intel_crtc.h +++ b/drivers/gpu/drm/i915/display/intel_crtc.h @@ -16,6 +16,16 @@ struct intel_atomic_state; struct intel_crtc; struct intel_crtc_state; +/* + * FIXME: We should instead only take spinlocks once for the entire update + * instead of once per mmio. + */ +#if IS_ENABLED(CONFIG_PROVE_LOCKING) +#define VBLANK_EVASION_TIME_US 250 +#else +#define VBLANK_EVASION_TIME_US 100 +#endif + int intel_usecs_to_scanlines(const struct drm_display_mode *adjusted_mode, int usecs); u32 intel_crtc_max_vblank_count(const struct intel_crtc_state *crtc_state); diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c b/drivers/gpu/drm/i915/display/intel_display_debugfs.c index abd16a2b1f7a..e72288662f02 100644 --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c @@ -12,6 +12,7 @@ #include "i915_debugfs.h" #include "i915_irq.h" #include "i915_reg.h" +#include "intel_crtc.h" #include "intel_de.h" #include "intel_crtc_state_dump.h" #include "intel_display_debugfs.h" @@ -30,7 +31,6 @@ #include "intel_panel.h" #include "intel_psr.h" #include "intel_psr_regs.h" -#include "intel_sprite.h" #include "intel_wm.h" static inline struct drm_i915_private *node_to_i915(struct drm_info_node *node) diff --git a/drivers/gpu/drm/i915/display/intel_sprite.h b/drivers/gpu/drm/i915/display/intel_sprite.h index 4635c7ad23f9..91c6dca342b2 100644 --- a/drivers/gpu/drm/i915/display/intel_sprite.h +++ b/drivers/gpu/drm/i915/display/intel_sprite.h @@ -16,16 +16,6 @@ struct intel_crtc_state; struct intel_plane_state; enum pipe; -/* - * FIXME: We should instead only take spinlocks once for the entire update - * instead of once per mmio. - */ -#if IS_ENABLED(CONFIG_PROVE_LOCKING) -#define VBLANK_EVASION_TIME_US 250 -#else -#define VBLANK_EVASION_TIME_US 100 -#endif - struct intel_plane *intel_sprite_plane_create(struct drm_i915_private *dev_priv, enum pipe pipe, int plane); int intel_sprite_set_colorkey_ioctl(struct drm_device *dev, void *data, -- 2.39.2
[Intel-gfx] [PATCH 01/15] drm/i915: Check pipe source size when using skl+ scalers
From: Ville Syrjälä
The skl+ scalers only sample 12 bits of PIPESRC so we can't
do any plane scaling at all when the pipe source size is >4k.
Make sure the pipe source size is also below the scaler's src
size limits. Might not be 100% accurate, but should at least be
safe. We can refine the limits later if we discover that recent
hw is less restricted.
Cc: sta...@vger.kernel.org
Tested-by: Ross Zwisler
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8357
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index 473d53610b92..0e7e014fcc71 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -111,6 +111,8 @@ skl_update_scaler(struct intel_crtc_state *crtc_state, bool
force_detach,
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
const struct drm_display_mode *adjusted_mode =
&crtc_state->hw.adjusted_mode;
+ int pipe_src_w = drm_rect_width(&crtc_state->pipe_src);
+ int pipe_src_h = drm_rect_height(&crtc_state->pipe_src);
int min_src_w, min_src_h, min_dst_w, min_dst_h;
int max_src_w, max_src_h, max_dst_w, max_dst_h;
@@ -207,6 +209,21 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return -EINVAL;
}
+ /*
+* The pipe scaler does not use all the bits of PIPESRC, at least
+* on the earlier platforms. So even when we're scaling a plane
+* the *pipe* source size must not be too large. For simplicity
+* we assume the limits match the scaler source size limits. Might
+* not be 100% accurate on all platforms, but good enough for now.
+*/
+ if (pipe_src_w > max_src_w || pipe_src_h > max_src_h) {
+ drm_dbg_kms(&dev_priv->drm,
+ "scaler_user index %u.%u: pipe src size %ux%u "
+ "is out of scaler range\n",
+ crtc->pipe, scaler_user, pipe_src_w, pipe_src_h);
+ return -EINVAL;
+ }
+
/* mark this plane as a scaler user in crtc_state */
scaler_state->scaler_users |= (1 << scaler_user);
drm_dbg_kms(&dev_priv->drm, "scaler_user index %u.%u: "
--
2.39.2
[Intel-gfx] [PATCH 06/15] drm/i915: Namespace pfit registers properly
From: Ville Syrjälä
Give the PFIT_CONTROL bits a consistent namespace.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_lvds.c| 2 +-
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
drivers/gpu/drm/i915/display/intel_panel.c | 25 ++--
drivers/gpu/drm/i915/i915_reg.h | 14 +--
4 files changed, 22 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_lvds.c
b/drivers/gpu/drm/i915/display/intel_lvds.c
index 0de44b3631cd..8e9a3d72b83b 100644
--- a/drivers/gpu/drm/i915/display/intel_lvds.c
+++ b/drivers/gpu/drm/i915/display/intel_lvds.c
@@ -150,7 +150,7 @@ static void intel_lvds_get_config(struct intel_encoder
*encoder,
if (DISPLAY_VER(dev_priv) < 4) {
tmp = intel_de_read(dev_priv, PFIT_CONTROL);
- crtc_state->gmch_pfit.control |= tmp & PANEL_8TO6_DITHER_ENABLE;
+ crtc_state->gmch_pfit.control |= tmp &
PFIT_PANEL_8TO6_DITHER_ENABLE;
}
crtc_state->hw.adjusted_mode.crtc_clock = crtc_state->port_clock;
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index 1813ab5056a1..d6fe2bbabe55 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -948,7 +948,7 @@ static void update_pfit_vscale_ratio(struct intel_overlay
*overlay)
} else {
u32 tmp;
- if (intel_de_read(dev_priv, PFIT_CONTROL) & VERT_AUTO_SCALE)
+ if (intel_de_read(dev_priv, PFIT_CONTROL) &
PFIT_VERT_AUTO_SCALE)
tmp = intel_de_read(dev_priv, PFIT_AUTO_RATIOS);
else
tmp = intel_de_read(dev_priv, PFIT_PGM_RATIOS);
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 71cd08f44ed0..9232a305b1e6 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -567,8 +567,8 @@ static void i9xx_scale_aspect(struct intel_crtc_state
*crtc_state,
*pfit_pgm_ratios |= (PFIT_HORIZ_SCALE(bits) |
PFIT_VERT_SCALE(bits));
*pfit_control |= (PFIT_ENABLE |
- VERT_INTERP_BILINEAR |
- HORIZ_INTERP_BILINEAR);
+ PFIT_VERT_INTERP_BILINEAR |
+ PFIT_HORIZ_INTERP_BILINEAR);
}
} else if (scaled_width < scaled_height) { /* letter */
centre_vertically(adjusted_mode,
@@ -582,15 +582,16 @@ static void i9xx_scale_aspect(struct intel_crtc_state
*crtc_state,
*pfit_pgm_ratios |= (PFIT_HORIZ_SCALE(bits) |
PFIT_VERT_SCALE(bits));
*pfit_control |= (PFIT_ENABLE |
- VERT_INTERP_BILINEAR |
- HORIZ_INTERP_BILINEAR);
+ PFIT_VERT_INTERP_BILINEAR |
+ PFIT_HORIZ_INTERP_BILINEAR);
}
} else {
/* Aspects match, Let hw scale both directions */
*pfit_control |= (PFIT_ENABLE |
- VERT_AUTO_SCALE | HORIZ_AUTO_SCALE |
- VERT_INTERP_BILINEAR |
- HORIZ_INTERP_BILINEAR);
+ PFIT_VERT_AUTO_SCALE |
+ PFIT_HORIZ_AUTO_SCALE |
+ PFIT_VERT_INTERP_BILINEAR |
+ PFIT_HORIZ_INTERP_BILINEAR);
}
}
@@ -638,10 +639,10 @@ static int gmch_panel_fitting(struct intel_crtc_state
*crtc_state,
if (DISPLAY_VER(dev_priv) >= 4)
pfit_control |= PFIT_SCALING_AUTO;
else
- pfit_control |= (VERT_AUTO_SCALE |
-VERT_INTERP_BILINEAR |
-HORIZ_AUTO_SCALE |
-HORIZ_INTERP_BILINEAR);
+ pfit_control |= (PFIT_VERT_AUTO_SCALE |
+PFIT_VERT_INTERP_BILINEAR |
+PFIT_HORIZ_AUTO_SCALE |
+PFIT_HORIZ_INTERP_BILINEAR);
}
break;
default:
@@ -662,7 +663,7 @@ static int gmch_panel_fitting(struct intel_crtc_state
*crtc_state,
/* Make sure pre-965 set dither correctly for 18bpp panels. */
if (DISPLAY_VER(dev_priv) < 4 && crtc_state->pipe_bpp == 18)
- pfit_cont
[Intel-gfx] [PATCH 05/15] drm/i915: Use REG_BIT() & co for the pre-ilk pfit registers
From: Ville Syrjälä
Modernize the gmch pfit register definitions using REG_BIT/etc.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 15 +++---
drivers/gpu/drm/i915/display/intel_overlay.c | 16 +++---
drivers/gpu/drm/i915/display/intel_panel.c | 8 +--
drivers/gpu/drm/i915/i915_reg.h | 54 ++--
4 files changed, 48 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index a450d62e431c..ea1b0e87ae35 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2749,6 +2749,7 @@ static void i9xx_get_pfit_config(struct intel_crtc_state
*crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe;
u32 tmp;
if (!i9xx_has_pfit(dev_priv))
@@ -2759,13 +2760,13 @@ static void i9xx_get_pfit_config(struct
intel_crtc_state *crtc_state)
return;
/* Check whether the pfit is attached to our pipe. */
- if (DISPLAY_VER(dev_priv) < 4) {
- if (crtc->pipe != PIPE_B)
- return;
- } else {
- if ((tmp & PFIT_PIPE_MASK) != (crtc->pipe << PFIT_PIPE_SHIFT))
- return;
- }
+ if (DISPLAY_VER(dev_priv) >= 4)
+ pipe = REG_FIELD_GET(PFIT_PIPE_MASK, tmp);
+ else
+ pipe = PIPE_B;
+
+ if (pipe != crtc->pipe)
+ return;
crtc_state->gmch_pfit.control = tmp;
crtc_state->gmch_pfit.pgm_ratios =
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index c12bdca8da9b..1813ab5056a1 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -935,21 +935,25 @@ static int check_overlay_possible_on_crtc(struct
intel_overlay *overlay,
static void update_pfit_vscale_ratio(struct intel_overlay *overlay)
{
struct drm_i915_private *dev_priv = overlay->i915;
- u32 pfit_control = intel_de_read(dev_priv, PFIT_CONTROL);
u32 ratio;
/* XXX: This is not the same logic as in the xorg driver, but more in
* line with the intel documentation for the i965
*/
if (DISPLAY_VER(dev_priv) >= 4) {
+ u32 tmp = intel_de_read(dev_priv, PFIT_PGM_RATIOS);
+
/* on i965 use the PGM reg to read out the autoscaler values */
- ratio = intel_de_read(dev_priv, PFIT_PGM_RATIOS) >>
PFIT_VERT_SCALE_SHIFT_965;
+ ratio = REG_FIELD_GET(PFIT_VERT_SCALE_MASK_965, tmp);
} else {
- if (pfit_control & VERT_AUTO_SCALE)
- ratio = intel_de_read(dev_priv, PFIT_AUTO_RATIOS);
+ u32 tmp;
+
+ if (intel_de_read(dev_priv, PFIT_CONTROL) & VERT_AUTO_SCALE)
+ tmp = intel_de_read(dev_priv, PFIT_AUTO_RATIOS);
else
- ratio = intel_de_read(dev_priv, PFIT_PGM_RATIOS);
- ratio >>= PFIT_VERT_SCALE_SHIFT;
+ tmp = intel_de_read(dev_priv, PFIT_PGM_RATIOS);
+
+ ratio = REG_FIELD_GET(PFIT_VERT_SCALE_MASK, tmp);
}
overlay->pfit_vscale_ratio = ratio;
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
b/drivers/gpu/drm/i915/display/intel_panel.c
index 9acdd68b2dbc..71cd08f44ed0 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -564,8 +564,8 @@ static void i9xx_scale_aspect(struct intel_crtc_state
*crtc_state,
bits = panel_fitter_scaling(pipe_src_h,
adjusted_mode->crtc_vdisplay);
- *pfit_pgm_ratios |= (bits << PFIT_HORIZ_SCALE_SHIFT |
-bits << PFIT_VERT_SCALE_SHIFT);
+ *pfit_pgm_ratios |= (PFIT_HORIZ_SCALE(bits) |
+PFIT_VERT_SCALE(bits));
*pfit_control |= (PFIT_ENABLE |
VERT_INTERP_BILINEAR |
HORIZ_INTERP_BILINEAR);
@@ -579,8 +579,8 @@ static void i9xx_scale_aspect(struct intel_crtc_state
*crtc_state,
bits = panel_fitter_scaling(pipe_src_w,
adjusted_mode->crtc_hdisplay);
- *pfit_pgm_ratios |= (bits << PFIT_HORIZ_SCALE_SHIFT |
-bits << PFIT_VERT_SCALE_SHIFT);
+ *pfit_pgm_ratios |= (PFIT_HORIZ_SCALE(bits) |
+PFIT_VERT_SCALE(bits));
*pfit_control |= (PFIT_ENABLE |
[Intel-gfx] [PATCH 10/15] drm/i915: Remove dead scaler register defines
From: Ville Syrjälä We have some duplicated scaler register defines that are never used. Remove them. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 12 1 file changed, 12 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 75e1f30adda1..919d999a2345 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4041,18 +4041,6 @@ #define PF_VSCALE(pipe)_MMIO_PIPE(pipe, _PFA_VSCALE, _PFB_VSCALE) #define PF_HSCALE(pipe)_MMIO_PIPE(pipe, _PFA_HSCALE, _PFB_HSCALE) -#define _PSA_CTL 0x68180 -#define _PSB_CTL 0x68980 -#define PS_ENABLE (1 << 31) -#define _PSA_WIN_SZ0x68174 -#define _PSB_WIN_SZ0x68974 -#define _PSA_WIN_POS 0x68170 -#define _PSB_WIN_POS 0x68970 - -#define PS_CTL(pipe) _MMIO_PIPE(pipe, _PSA_CTL, _PSB_CTL) -#define PS_WIN_SZ(pipe)_MMIO_PIPE(pipe, _PSA_WIN_SZ, _PSB_WIN_SZ) -#define PS_WIN_POS(pipe) _MMIO_PIPE(pipe, _PSA_WIN_POS, _PSB_WIN_POS) - /* * Skylake scalers */ -- 2.39.2
[Intel-gfx] [PATCH 03/15] drm/i915: Relocate intel_atomic_setup_scalers()
From: Ville Syrjälä
Move intel_atomic_setup_scalers() next to the other scaler
code in skl_scaler.c.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_atomic.c | 256 ---
drivers/gpu/drm/i915/display/intel_atomic.h | 4 -
drivers/gpu/drm/i915/display/skl_scaler.c | 257
drivers/gpu/drm/i915/display/skl_scaler.h | 10 +-
4 files changed, 265 insertions(+), 262 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 61011641f6ab..7cf51dd8c056 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -310,262 +310,6 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
kfree(crtc_state);
}
-static int intel_atomic_setup_scaler(struct intel_crtc_scaler_state
*scaler_state,
-int num_scalers_need, struct intel_crtc
*intel_crtc,
-const char *name, int idx,
-struct intel_plane_state *plane_state,
-int *scaler_id)
-{
- struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
- int j;
- u32 mode;
-
- if (*scaler_id < 0) {
- /* find a free scaler */
- for (j = 0; j < intel_crtc->num_scalers; j++) {
- if (scaler_state->scalers[j].in_use)
- continue;
-
- *scaler_id = j;
- scaler_state->scalers[*scaler_id].in_use = 1;
- break;
- }
- }
-
- if (drm_WARN(&dev_priv->drm, *scaler_id < 0,
-"Cannot find scaler for %s:%d\n", name, idx))
- return -EINVAL;
-
- /* set scaler mode */
- if (plane_state && plane_state->hw.fb &&
- plane_state->hw.fb->format->is_yuv &&
- plane_state->hw.fb->format->num_planes > 1) {
- struct intel_plane *plane =
to_intel_plane(plane_state->uapi.plane);
- if (DISPLAY_VER(dev_priv) == 9) {
- mode = SKL_PS_SCALER_MODE_NV12;
- } else if (icl_is_hdr_plane(dev_priv, plane->id)) {
- /*
-* On gen11+'s HDR planes we only use the scaler for
-* scaling. They have a dedicated chroma upsampler, so
-* we don't need the scaler to upsample the UV plane.
-*/
- mode = PS_SCALER_MODE_NORMAL;
- } else {
- struct intel_plane *linked =
- plane_state->planar_linked_plane;
-
- mode = PS_SCALER_MODE_PLANAR;
-
- if (linked)
- mode |= PS_PLANE_Y_SEL(linked->id);
- }
- } else if (DISPLAY_VER(dev_priv) >= 10) {
- mode = PS_SCALER_MODE_NORMAL;
- } else if (num_scalers_need == 1 && intel_crtc->num_scalers > 1) {
- /*
-* when only 1 scaler is in use on a pipe with 2 scalers
-* scaler 0 operates in high quality (HQ) mode.
-* In this case use scaler 0 to take advantage of HQ mode
-*/
- scaler_state->scalers[*scaler_id].in_use = 0;
- *scaler_id = 0;
- scaler_state->scalers[0].in_use = 1;
- mode = SKL_PS_SCALER_MODE_HQ;
- } else {
- mode = SKL_PS_SCALER_MODE_DYN;
- }
-
- /*
-* FIXME: we should also check the scaler factors for pfit, so
-* this shouldn't be tied directly to planes.
-*/
- if (plane_state && plane_state->hw.fb) {
- const struct drm_framebuffer *fb = plane_state->hw.fb;
- const struct drm_rect *src = &plane_state->uapi.src;
- const struct drm_rect *dst = &plane_state->uapi.dst;
- int hscale, vscale, max_vscale, max_hscale;
-
- /*
-* FIXME: When two scalers are needed, but only one of
-* them needs to downscale, we should make sure that
-* the one that needs downscaling support is assigned
-* as the first scaler, so we don't reject downscaling
-* unnecessarily.
-*/
-
- if (DISPLAY_VER(dev_priv) >= 14) {
- /*
-* On versions 14 and up, only the first
-* scaler supports a vertical scaling factor
-* of more than 1.0, while a horizontal
-* scaling factor of 3.0 is supported.
-*/
- max_hscale = 0x3 - 1;
- if (*scaler_id == 0)
- max_vscale = 0x3 - 1;
-
[Intel-gfx] [PATCH 07/15] drm/i915: Use REG_BIT() & co. for ilk+ pfit registers
From: Ville Syrjälä Polish the ilk+ pfit registers with REG_BIT() & co., and also take the opportunity to unify the ivb/hsw vs. not checks in ilk_pfit_enable() and ilk_get_pfit_config(). Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 9 +++-- drivers/gpu/drm/i915/i915_reg.h | 20 ++-- 2 files changed, 17 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index ea1b0e87ae35..e9000ed15e7f 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -3230,11 +3230,17 @@ static void ilk_get_pfit_config(struct intel_crtc_state *crtc_state) struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc); struct drm_i915_private *dev_priv = to_i915(crtc->base.dev); u32 ctl, pos, size; + enum pipe pipe; ctl = intel_de_read(dev_priv, PF_CTL(crtc->pipe)); if ((ctl & PF_ENABLE) == 0) return; + if (IS_IVYBRIDGE(dev_priv) || IS_HASWELL(dev_priv)) + pipe = REG_FIELD_GET(PF_PIPE_SEL_MASK_IVB, ctl); + else + pipe = crtc->pipe; + crtc_state->pch_pfit.enabled = true; pos = intel_de_read(dev_priv, PF_WIN_POS(crtc->pipe)); @@ -3249,8 +3255,7 @@ static void ilk_get_pfit_config(struct intel_crtc_state *crtc_state) * ivb/hsw (since we don't use the higher upscaling modes which * differentiates them) so just WARN about this case for now. */ - drm_WARN_ON(&dev_priv->drm, DISPLAY_VER(dev_priv) == 7 && - (ctl & PF_PIPE_SEL_MASK_IVB) != PF_PIPE_SEL_IVB(crtc->pipe)); + drm_WARN_ON(&dev_priv->drm, pipe != crtc->pipe); } static bool ilk_get_pipe_config(struct intel_crtc *crtc, diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index eea739e0b48a..3c02f6c70733 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4008,16 +4008,16 @@ /* CPU panel fitter */ /* IVB+ has 3 fitters, 0 is 7x5 capable, the other two only 3x3 */ -#define _PFA_CTL_1 0x68080 -#define _PFB_CTL_1 0x68880 -#define PF_ENABLE (1 << 31) -#define PF_PIPE_SEL_MASK_IVB (3 << 29) -#define PF_PIPE_SEL_IVB(pipe) ((pipe) << 29) -#define PF_FILTER_MASK(3 << 23) -#define PF_FILTER_PROGRAMMED (0 << 23) -#define PF_FILTER_MED_3x3 (1 << 23) -#define PF_FILTER_EDGE_ENHANCE(2 << 23) -#define PF_FILTER_EDGE_SOFTEN (3 << 23) +#define _PFA_CTL_1 0x68080 +#define _PFB_CTL_1 0x68880 +#define PF_ENABLEREG_BIT(31) +#define PF_PIPE_SEL_MASK_IVB REG_GENMASK(30, 29) /* ivb/hsw */ +#define PF_PIPE_SEL_IVB(pipe) REG_FIELD_PREP(PF_PIPE_SEL_MASK_IVB, (pipe)) +#define PF_FILTER_MASK REG_GENMASK(24, 23) +#define PF_FILTER_PROGRAMMED REG_FIELD_PREP(PF_FILTER_MASK, 0) +#define PF_FILTER_MED_3x3REG_FIELD_PREP(PF_FILTER_MASK, 1) +#define PF_FILTER_EDGE_ENHANCE REG_FIELD_PREP(PF_FILTER_EDGE_MASK, 2) +#define PF_FILTER_EDGE_SOFTEN REG_FIELD_PREP(PF_FILTER_EDGE_MASK, 3) #define _PFA_WIN_SZ0x68074 #define _PFB_WIN_SZ0x68874 #define _PFA_WIN_POS 0x68070 -- 2.39.2
[Intel-gfx] [PATCH 08/15] drm/i915: Drop a useless forward declararion
From: Ville Syrjälä ilk_pfit_enable() is defined before the first use. No need for a forwared declaration. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index e9000ed15e7f..fb49d0ed61b4 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -123,7 +123,6 @@ static void intel_set_transcoder_timings(const struct intel_crtc_state *crtc_sta static void intel_set_pipe_src_size(const struct intel_crtc_state *crtc_state); static void hsw_set_transconf(const struct intel_crtc_state *crtc_state); static void bdw_set_pipe_misc(const struct intel_crtc_state *crtc_state); -static void ilk_pfit_enable(const struct intel_crtc_state *crtc_state); /* returns HPLL frequency in kHz */ int vlv_get_hpll_vco(struct drm_i915_private *dev_priv) -- 2.39.2
[Intel-gfx] [PATCH 13/15] drm/i915: Define bitmasks for sik+ scaler window pos/size
From: Ville Syrjälä Define and use the bitmasks for the x/y components of the skl+ scaler window pos/size registers. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/skl_scaler.c | 14 -- drivers/gpu/drm/i915/i915_reg.h | 8 2 files changed, 16 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c b/drivers/gpu/drm/i915/display/skl_scaler.c index 4437d130293a..1e7c97243fcf 100644 --- a/drivers/gpu/drm/i915/display/skl_scaler.c +++ b/drivers/gpu/drm/i915/display/skl_scaler.c @@ -754,9 +754,9 @@ void skl_pfit_enable(const struct intel_crtc_state *crtc_state) intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, id), PS_Y_PHASE(0) | PS_UV_RGB_PHASE(uv_rgb_hphase)); intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(pipe, id), - x << 16 | y); + PS_WIN_XPOS(x) | PS_WIN_YPOS(y)); intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(pipe, id), - width << 16 | height); + PS_WIN_XSIZE(width) | PS_WIN_YSIZE(height)); } void @@ -816,9 +816,9 @@ skl_program_plane_scaler(struct intel_plane *plane, intel_de_write_fw(dev_priv, SKL_PS_HPHASE(pipe, scaler_id), PS_Y_PHASE(y_hphase) | PS_UV_RGB_PHASE(uv_rgb_hphase)); intel_de_write_fw(dev_priv, SKL_PS_WIN_POS(pipe, scaler_id), - (crtc_x << 16) | crtc_y); + PS_WIN_XPOS(crtc_x) | PS_WIN_YPOS(crtc_y)); intel_de_write_fw(dev_priv, SKL_PS_WIN_SZ(pipe, scaler_id), - (crtc_w << 16) | crtc_h); + PS_WIN_XSIZE(crtc_w) | PS_WIN_YSIZE(crtc_h)); } static void skl_detach_scaler(struct intel_crtc *crtc, int id) @@ -880,8 +880,10 @@ void skl_scaler_get_config(struct intel_crtc_state *crtc_state) size = intel_de_read(dev_priv, SKL_PS_WIN_SZ(crtc->pipe, i)); drm_rect_init(&crtc_state->pch_pfit.dst, - pos >> 16, pos & 0x, - size >> 16, size & 0x); + REG_FIELD_GET(PS_WIN_XPOS_MASK, pos), + REG_FIELD_GET(PS_WIN_YPOS_MASK, pos), + REG_FIELD_GET(PS_WIN_XSIZE_MASK, size), + REG_FIELD_GET(PS_WIN_YSIZE_MASK, size)); scaler_state->scalers[i].in_use = true; break; diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index a5ae291de55b..68581864fb44 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4101,12 +4101,20 @@ #define _PS_WIN_POS_1B 0x68970 #define _PS_WIN_POS_2B 0x68A70 #define _PS_WIN_POS_1C 0x69170 +#define PS_WIN_XPOS_MASK REG_GENMASK(28, 16) +#define PS_WIN_XPOS(x) REG_FIELD_PREP(PS_WIN_XPOS_MASK, (x)) +#define PS_WIN_YPOS_MASK REG_GENMASK(12, 0) +#define PS_WIN_YPOS(y) REG_FIELD_PREP(PS_WIN_YPOS_MASK, (y)) #define _PS_WIN_SZ_1A 0x68174 #define _PS_WIN_SZ_2A 0x68274 #define _PS_WIN_SZ_1B 0x68974 #define _PS_WIN_SZ_2B 0x68A74 #define _PS_WIN_SZ_1C 0x69174 +#define PS_WIN_XSIZE_MASKREG_GENMASK(29, 16) +#define PS_WIN_XSIZE(w) REG_FIELD_PREP(PS_WIN_XSIZE_MASK, (w)) +#define PS_WIN_YSIZE_MASKREG_GENMASK(12, 0) +#define PS_WIN_YSIZE(h) REG_FIELD_PREP(PS_WIN_YSIZE_MASK, (h)) #define _PS_VSCALE_1A 0x68184 #define _PS_VSCALE_2A 0x68284 -- 2.39.2
[Intel-gfx] [PATCH 12/15] drm/i915: s/PS_COEE_INDEX_AUTO_INC/PS_COEF_INDEX_AUTO_INC/
From: Ville Syrjälä
Fix a typo in the PS_COEF_INDEX_AUTO_INC define.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index a96f8ecbeec1..4437d130293a 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -658,7 +658,7 @@ static void glk_program_nearest_filter_coefs(struct
drm_i915_private *dev_priv,
int i;
intel_de_write_fw(dev_priv, GLK_PS_COEF_INDEX_SET(pipe, id, set),
- PS_COEE_INDEX_AUTO_INC);
+ PS_COEF_INDEX_AUTO_INC);
for (i = 0; i < 17 * 7; i += 2) {
u32 tmp;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index f8e6b86facc3..a5ae291de55b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4146,7 +4146,7 @@
#define _PS_COEF_SET0_INDEX_2A0x68298
#define _PS_COEF_SET0_INDEX_1B0x68998
#define _PS_COEF_SET0_INDEX_2B0x68A98
-#define PS_COEE_INDEX_AUTO_INC(1 << 10)
+#define PS_COEF_INDEX_AUTO_INC(1 << 10)
#define _PS_COEF_SET0_DATA_1A 0x6819C
#define _PS_COEF_SET0_DATA_2A 0x6829C
--
2.39.2
[Intel-gfx] [PATCH 11/15] drm/i915: Rename skl+ scaler binding bits
From: Ville Syrjälä
Rename the scaler binding bits to match the spec more closely.
Also call the parameters 'plane_id' to make it a bit more clear
what to pass in.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 12 ++--
drivers/gpu/drm/i915/i915_reg.h | 9 +
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index ec930aec21c4..a96f8ecbeec1 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -396,7 +396,7 @@ static int intel_atomic_setup_scaler(struct
intel_crtc_scaler_state *scaler_stat
mode = PS_SCALER_MODE_PLANAR;
if (linked)
- mode |= PS_PLANE_Y_SEL(linked->id);
+ mode |= PS_BINDING_Y_PLANE(linked->id);
}
} else if (DISPLAY_VER(dev_priv) >= 10) {
mode = PS_SCALER_MODE_NORMAL;
@@ -741,8 +741,8 @@ void skl_pfit_enable(const struct intel_crtc_state
*crtc_state)
id = scaler_state->scaler_id;
- ps_ctrl = skl_scaler_get_filter_select(crtc_state->hw.scaling_filter,
0);
- ps_ctrl |= PS_SCALER_EN | scaler_state->scalers[id].mode;
+ ps_ctrl = PS_SCALER_EN | PS_BINDING_PIPE |
scaler_state->scalers[id].mode |
+ skl_scaler_get_filter_select(crtc_state->hw.scaling_filter, 0);
skl_scaler_setup_filter(dev_priv, pipe, id, 0,
crtc_state->hw.scaling_filter);
@@ -804,8 +804,8 @@ skl_program_plane_scaler(struct intel_plane *plane,
uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
}
- ps_ctrl = skl_scaler_get_filter_select(plane_state->hw.scaling_filter,
0);
- ps_ctrl |= PS_SCALER_EN | PS_PLANE_SEL(plane->id) | scaler->mode;
+ ps_ctrl = PS_SCALER_EN | PS_BINDING_PLANE(plane->id) | scaler->mode |
+ skl_scaler_get_filter_select(plane_state->hw.scaling_filter, 0);
skl_scaler_setup_filter(dev_priv, pipe, scaler_id, 0,
plane_state->hw.scaling_filter);
@@ -870,7 +870,7 @@ void skl_scaler_get_config(struct intel_crtc_state
*crtc_state)
u32 ctl, pos, size;
ctl = intel_de_read(dev_priv, SKL_PS_CTRL(crtc->pipe, i));
- if ((ctl & (PS_SCALER_EN | PS_PLANE_SEL_MASK)) != PS_SCALER_EN)
+ if ((ctl & (PS_SCALER_EN | PS_BINDING_MASK)) != (PS_SCALER_EN |
PS_BINDING_PIPE))
continue;
id = i;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 919d999a2345..f8e6b86facc3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4056,8 +4056,9 @@
#define SKL_PS_SCALER_MODE_NV12 (2 << 28)
#define PS_SCALER_MODE_PLANAR (1 << 29)
#define PS_SCALER_MODE_NORMAL (0 << 29)
-#define PS_PLANE_SEL_MASK (7 << 25)
-#define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
+#define PS_BINDING_MASK (7 << 25)
+#define PS_BINDING_PIPE (0 << 25)
+#define PS_BINDING_PLANE(plane_id) (((plane_id) + 1) << 25)
#define PS_FILTER_MASK (3 << 23)
#define PS_FILTER_MEDIUM (0 << 23)
#define PS_FILTER_PROGRAMMED (1 << 23)
@@ -4073,8 +4074,8 @@
#define PS_VADAPT_MODE_LEAST_ADAPT (0 << 5)
#define PS_VADAPT_MODE_MOD_ADAPT (1 << 5)
#define PS_VADAPT_MODE_MOST_ADAPT (3 << 5)
-#define PS_PLANE_Y_SEL_MASK (7 << 5)
-#define PS_PLANE_Y_SEL(plane) (((plane) + 1) << 5)
+#define PS_BINDING_Y_MASK (7 << 5)
+#define PS_BINDING_Y_PLANE(plane_id) (((plane_id) + 1) << 5)
#define PS_Y_VERT_FILTER_SELECT(set) ((set) << 4)
#define PS_Y_HORZ_FILTER_SELECT(set) ((set) << 3)
#define PS_UV_VERT_FILTER_SELECT(set) ((set) << 2)
--
2.39.2
[Intel-gfx] [PATCH 09/15] drm/i915: Define bitmasks for ilk pfit window pos/size
From: Ville Syrjälä Define and use the bitmasks for the x/y components of the ilk+ panel filter window pos/size registers. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 12 drivers/gpu/drm/i915/i915_reg.h | 8 2 files changed, 16 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index fb49d0ed61b4..626a5f41a1f1 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -812,8 +812,10 @@ static void ilk_pfit_enable(const struct intel_crtc_state *crtc_state) else intel_de_write_fw(dev_priv, PF_CTL(pipe), PF_ENABLE | PF_FILTER_MED_3x3); - intel_de_write_fw(dev_priv, PF_WIN_POS(pipe), x << 16 | y); - intel_de_write_fw(dev_priv, PF_WIN_SZ(pipe), width << 16 | height); + intel_de_write_fw(dev_priv, PF_WIN_POS(pipe), + PF_WIN_XPOS(x) | PF_WIN_YPOS(y)); + intel_de_write_fw(dev_priv, PF_WIN_SZ(pipe), + PF_WIN_XSIZE(width) | PF_WIN_YSIZE(height)); } static void intel_crtc_dpms_overlay_disable(struct intel_crtc *crtc) @@ -3246,8 +3248,10 @@ static void ilk_get_pfit_config(struct intel_crtc_state *crtc_state) size = intel_de_read(dev_priv, PF_WIN_SZ(crtc->pipe)); drm_rect_init(&crtc_state->pch_pfit.dst, - pos >> 16, pos & 0x, - size >> 16, size & 0x); + REG_FIELD_GET(PF_WIN_XPOS_MASK, pos), + REG_FIELD_GET(PF_WIN_YPOS_MASK, pos), + REG_FIELD_GET(PF_WIN_XSIZE_MASK, size), + REG_FIELD_GET(PF_WIN_YSIZE_MASK, size)); /* * We currently do not free assignements of panel fitters on diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 3c02f6c70733..75e1f30adda1 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4020,8 +4020,16 @@ #define PF_FILTER_EDGE_SOFTEN REG_FIELD_PREP(PF_FILTER_EDGE_MASK, 3) #define _PFA_WIN_SZ0x68074 #define _PFB_WIN_SZ0x68874 +#define PF_WIN_XSIZE_MASKREG_GENMASK(28, 16) +#define PF_WIN_XSIZE(w) REG_FIELD_PREP(PF_WIN_XSIZE_MASK, (w)) +#define PF_WIN_YSIZE_MASKREG_GENMASK(11, 0) +#define PF_WIN_YSIZE(h) REG_FIELD_PREP(PF_WIN_YSIZE_MASK, (h)) #define _PFA_WIN_POS 0x68070 #define _PFB_WIN_POS 0x68870 +#define PF_WIN_XPOS_MASK REG_GENMASK(28, 16) +#define PF_WIN_XPOS(x) REG_FIELD_PREP(PF_WIN_XPOS_MASK, (x)) +#define PF_WIN_YPOS_MASK REG_GENMASK(11, 0) +#define PF_WIN_YPOS(y) REG_FIELD_PREP(PF_WIN_YPOS_MASK, (y)) #define _PFA_VSCALE0x68084 #define _PFB_VSCALE0x68884 #define _PFA_HSCALE0x68090 -- 2.39.2
[Intel-gfx] [PATCH 14/15] drm/i915: Use REG_BIT() & co. for pipe scaler registers
From: Ville Syrjälä Pimp the skl+ scaler register bits with REG_BIT()/etc. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 98 ++--- 1 file changed, 53 insertions(+), 45 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 68581864fb44..9a6343d2e0fa 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4049,52 +4049,58 @@ #define _PS_1B_CTRL 0x68980 #define _PS_2B_CTRL 0x68A80 #define _PS_1C_CTRL 0x69180 -#define PS_SCALER_EN(1 << 31) -#define SKL_PS_SCALER_MODE_MASK (3 << 28) -#define SKL_PS_SCALER_MODE_DYN (0 << 28) -#define SKL_PS_SCALER_MODE_HQ (1 << 28) -#define SKL_PS_SCALER_MODE_NV12 (2 << 28) -#define PS_SCALER_MODE_PLANAR (1 << 29) -#define PS_SCALER_MODE_NORMAL (0 << 29) -#define PS_BINDING_MASK (7 << 25) -#define PS_BINDING_PIPE (0 << 25) -#define PS_BINDING_PLANE(plane_id) (((plane_id) + 1) << 25) -#define PS_FILTER_MASK (3 << 23) -#define PS_FILTER_MEDIUM (0 << 23) -#define PS_FILTER_PROGRAMMED (1 << 23) -#define PS_FILTER_EDGE_ENHANCE (2 << 23) -#define PS_FILTER_BILINEAR (3 << 23) -#define PS_VERT3TAP(1 << 21) -#define PS_VERT_INT_INVERT_FIELD1 (0 << 20) -#define PS_VERT_INT_INVERT_FIELD0 (1 << 20) -#define PS_PWRUP_PROGRESS (1 << 17) -#define PS_V_FILTER_BYPASS(1 << 8) -#define PS_VADAPT_EN (1 << 7) -#define PS_VADAPT_MODE_MASK(3 << 5) -#define PS_VADAPT_MODE_LEAST_ADAPT (0 << 5) -#define PS_VADAPT_MODE_MOD_ADAPT (1 << 5) -#define PS_VADAPT_MODE_MOST_ADAPT (3 << 5) -#define PS_BINDING_Y_MASK (7 << 5) -#define PS_BINDING_Y_PLANE(plane_id) (((plane_id) + 1) << 5) -#define PS_Y_VERT_FILTER_SELECT(set) ((set) << 4) -#define PS_Y_HORZ_FILTER_SELECT(set) ((set) << 3) -#define PS_UV_VERT_FILTER_SELECT(set) ((set) << 2) -#define PS_UV_HORZ_FILTER_SELECT(set) ((set) << 1) +#define PS_SCALER_EN REG_BIT(31) +#define SKL_PS_SCALER_MODE_MASK REG_GENMASK(29, 28) /* skl/bxt */ +#define SKL_PS_SCALER_MODE_DYN REG_FIELD_PREP(SKL_PS_SCALER_MODE_MASK, 0) +#define SKL_PS_SCALER_MODE_HQ REG_FIELD_PREP(SKL_PS_SCALER_MODE_MASK, 1) +#define SKL_PS_SCALER_MODE_NV12 REG_FIELD_PREP(SKL_PS_SCALER_MODE_MASK, 2) +#define PS_SCALER_MODE_MASK REG_BIT(29) /* glk-tgl */ +#define PS_SCALER_MODE_NORMAL REG_FIELD_PREP(PS_SCALER_MODE_MASK, 0) +#define PS_SCALER_MODE_PLANAR REG_FIELD_PREP(PS_SCALER_MODE_MASK, 1) +#define PS_BINDING_MASK REG_GENMASK(27, 25) +#define PS_BINDING_PIPE REG_FIELD_PREP(PS_BINDING_MASK, 0) +#define PS_BINDING_PLANE(plane_id) REG_FIELD_PREP(PS_BINDING_MASK, (plane_id) + 1) +#define PS_FILTER_MASK REG_GENMASK(24, 23) +#define PS_FILTER_MEDIUM REG_FIELD_PREP(PS_FILTER_MASK, 0) +#define PS_FILTER_PROGRAMMED REG_FIELD_PREP(PS_FILTER_MASK, 1) +#define PS_FILTER_EDGE_ENHANCE REG_FIELD_PREP(PS_FILTER_MASK, 2) +#define PS_FILTER_BILINEAR REG_FIELD_PREP(PS_FILTER_MASK, 3) +#define PS_VERT3TAP REG_BIT(21) /* skl/bxt */ +#define PS_VERT_INT_INVERT_FIELD REG_BIT(20) +#define PS_PWRUP_PROGRESSREG_BIT(17) +#define PS_V_FILTER_BYPASS REG_BIT(8) +#define PS_VADAPT_EN REG_BIT(7) /* skl/bxt */ +#define PS_VADAPT_MODE_MASK REG_GENMASK(6, 5) /* skl/bxt */ +#define PS_VADAPT_MODE_LEAST_ADAPT REG_FIELD_PREP(PS_VADAPT_MODE_MASK, 0) +#define PS_VADAPT_MODE_MOD_ADAPT REG_FIELD_PREP(PS_VADAPT_MODE_MASK, 1) +#define PS_VADAPT_MODE_MOST_ADAPT REG_FIELD_PREP(PS_VADAPT_MODE_MASK, 3) +#define PS_BINDING_Y_MASKREG_GENMASK(7, 5) /* icl-tgl */ +#define PS_BINDING_Y_PLANE(plane_id) REG_FIELD_PREP(PS_BINDING_Y_MASK, (plane_id) + 1) +#define PS_Y_VERT_FILTER_SELECT_MASK REG_BIT(4) /* glk+ */ +#define PS_Y_VERT_FILTER_SELECT(set) REG_FIELD_PREP(PS_Y_VERT_FILTER_SELECT_MASK, (set)) +#define PS_Y_HORZ_FILTER_SELECT_MASK REG_BIT(3) /* glk+ */ +#define PS_Y_HORZ_FILTER_SELECT(set) REG_FIELD_PREP(PS_Y_HORZ_FILTER_SELECT_MASK, (set)) +#define PS_UV_VERT_FILTER_SELECT_MASKREG_BIT(2) /* glk+ */ +#define PS_UV_VERT_FILTER_SELECT(set) REG_FIELD_PREP(PS_UV_VERT_FILTER_SELECT_MASK, (set)) +#define PS_UV_HORZ_FILTER_SELECT_MASKREG_BIT(1) /* glk+ */ +#define PS_UV_HORZ_FILTER_SELECT(set) REG_FIELD_PREP(PS_UV_HORZ_FILTER_SELECT_MASK, (set)) #define _PS_PWR_GATE_1A 0x68160 #define _PS_PWR_GATE_2A 0x68260 #define _PS_PWR_GATE_1B 0x68960 #define _PS_PWR_GATE_2B 0x
[Intel-gfx] [PATCH 15/15] drm/i915: Define more PS_CTRL bits
From: Ville Syrjälä To avoid annoying spec lookups let's define more PS_CTRL bits in the header. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_reg.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 9a6343d2e0fa..5baaf6df6951 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -4050,6 +4050,9 @@ #define _PS_2B_CTRL 0x68A80 #define _PS_1C_CTRL 0x69180 #define PS_SCALER_EN REG_BIT(31) +#define PS_SCALER_TYPE_MASK REG_BIT(30) /* icl+ */ +#define PS_SCALER_TYPE_NON_LINEAR REG_FIELD_PREP(PS_SCALER_TYPE_MASK, 0) +#define PS_SCALER_TYPE_LINEAR REG_FIELD_PREP(PS_SCALER_TYPE_MASK, 1) #define SKL_PS_SCALER_MODE_MASK REG_GENMASK(29, 28) /* skl/bxt */ #define SKL_PS_SCALER_MODE_DYN REG_FIELD_PREP(SKL_PS_SCALER_MODE_MASK, 0) #define SKL_PS_SCALER_MODE_HQ REG_FIELD_PREP(SKL_PS_SCALER_MODE_MASK, 1) @@ -4057,6 +4060,7 @@ #define PS_SCALER_MODE_MASK REG_BIT(29) /* glk-tgl */ #define PS_SCALER_MODE_NORMAL REG_FIELD_PREP(PS_SCALER_MODE_MASK, 0) #define PS_SCALER_MODE_PLANAR REG_FIELD_PREP(PS_SCALER_MODE_MASK, 1) +#define PS_ADAPTIVE_FILTERING_EN REG_BIT(28) /* icl+ */ #define PS_BINDING_MASK REG_GENMASK(27, 25) #define PS_BINDING_PIPE REG_FIELD_PREP(PS_BINDING_MASK, 0) #define PS_BINDING_PLANE(plane_id) REG_FIELD_PREP(PS_BINDING_MASK, (plane_id) + 1) @@ -4065,8 +4069,15 @@ #define PS_FILTER_PROGRAMMED REG_FIELD_PREP(PS_FILTER_MASK, 1) #define PS_FILTER_EDGE_ENHANCE REG_FIELD_PREP(PS_FILTER_MASK, 2) #define PS_FILTER_BILINEAR REG_FIELD_PREP(PS_FILTER_MASK, 3) +#define PS_ADAPTIVE_FILTER_MASK REG_BIT(22) /* icl+ */ +#define PS_ADAPTIVE_FILTER_MEDIUM REG_FIELD_PREP(PS_ADAPTIVE_FILTER_MASK, 0) +#define PS_ADAPTIVE_FILTER_EDGE_ENHANCE REG_FIELD_PREP(PS_ADAPTIVE_FILTER_MASK, 1) +#define PS_PIPE_SCALER_LOC_MASK REG_BIT(21) /* icl+ */ +#define PS_PIPE_SCALER_LOC_AFTER_OUTPUT_CSC REG_FIELD_PREP(PS_SCALER_LOCATION_MASK, 0) /* non-linear */ +#define PS_PIPE_SCALER_LOC_AFTER_CSC REG_FIELD_PREP(PS_SCALER_LOCATION_MASK, 1) /* linear */ #define PS_VERT3TAP REG_BIT(21) /* skl/bxt */ #define PS_VERT_INT_INVERT_FIELD REG_BIT(20) +#define PS_PROG_SCALE_FACTOR REG_BIT(19) /* tgl+ */ #define PS_PWRUP_PROGRESSREG_BIT(17) #define PS_V_FILTER_BYPASS REG_BIT(8) #define PS_VADAPT_EN REG_BIT(7) /* skl/bxt */ -- 2.39.2
[Intel-gfx] [PATCH 04/15] drm/i915: Relocate skl_get_pfit_config()
From: Ville Syrjälä
Move skl_get_pfit_config() next to the other skl+ scaler code
and rename it to skl_scaler_get_config() so that it has a consistnet
namespace.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 49 ++--
drivers/gpu/drm/i915/display/skl_scaler.c| 37 +++
drivers/gpu/drm/i915/display/skl_scaler.h| 2 +
3 files changed, 43 insertions(+), 45 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1c264c17b6e4..a450d62e431c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3224,49 +3224,6 @@ void intel_cpu_transcoder_get_m2_n2(struct intel_crtc
*crtc,
PIPE_LINK_M2(transcoder), PIPE_LINK_N2(transcoder));
}
-static void ilk_get_pfit_pos_size(struct intel_crtc_state *crtc_state,
- u32 pos, u32 size)
-{
- drm_rect_init(&crtc_state->pch_pfit.dst,
- pos >> 16, pos & 0x,
- size >> 16, size & 0x);
-}
-
-static void skl_get_pfit_config(struct intel_crtc_state *crtc_state)
-{
- struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_crtc_scaler_state *scaler_state =
&crtc_state->scaler_state;
- int id = -1;
- int i;
-
- /* find scaler attached to this pipe */
- for (i = 0; i < crtc->num_scalers; i++) {
- u32 ctl, pos, size;
-
- ctl = intel_de_read(dev_priv, SKL_PS_CTRL(crtc->pipe, i));
- if ((ctl & (PS_SCALER_EN | PS_PLANE_SEL_MASK)) != PS_SCALER_EN)
- continue;
-
- id = i;
- crtc_state->pch_pfit.enabled = true;
-
- pos = intel_de_read(dev_priv, SKL_PS_WIN_POS(crtc->pipe, i));
- size = intel_de_read(dev_priv, SKL_PS_WIN_SZ(crtc->pipe, i));
-
- ilk_get_pfit_pos_size(crtc_state, pos, size);
-
- scaler_state->scalers[i].in_use = true;
- break;
- }
-
- scaler_state->scaler_id = id;
- if (id >= 0)
- scaler_state->scaler_users |= (1 << SKL_CRTC_INDEX);
- else
- scaler_state->scaler_users &= ~(1 << SKL_CRTC_INDEX);
-}
-
static void ilk_get_pfit_config(struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -3282,7 +3239,9 @@ static void ilk_get_pfit_config(struct intel_crtc_state
*crtc_state)
pos = intel_de_read(dev_priv, PF_WIN_POS(crtc->pipe));
size = intel_de_read(dev_priv, PF_WIN_SZ(crtc->pipe));
- ilk_get_pfit_pos_size(crtc_state, pos, size);
+ drm_rect_init(&crtc_state->pch_pfit.dst,
+ pos >> 16, pos & 0x,
+ size >> 16, size & 0x);
/*
* We currently do not free assignements of panel fitters on
@@ -3773,7 +3732,7 @@ static bool hsw_get_pipe_config(struct intel_crtc *crtc,
if (intel_display_power_get_in_set_if_enabled(dev_priv,
&crtc->hw_readout_power_domains,
POWER_DOMAIN_PIPE_PANEL_FITTER(crtc->pipe))) {
if (DISPLAY_VER(dev_priv) >= 9)
- skl_get_pfit_config(pipe_config);
+ skl_scaler_get_config(pipe_config);
else
ilk_get_pfit_config(pipe_config);
}
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index 62443834f64e..ec930aec21c4 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -856,3 +856,40 @@ void skl_scaler_disable(const struct intel_crtc_state
*old_crtc_state)
for (i = 0; i < crtc->num_scalers; i++)
skl_detach_scaler(crtc, i);
}
+
+void skl_scaler_get_config(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_crtc_scaler_state *scaler_state =
&crtc_state->scaler_state;
+ int id = -1;
+ int i;
+
+ /* find scaler attached to this pipe */
+ for (i = 0; i < crtc->num_scalers; i++) {
+ u32 ctl, pos, size;
+
+ ctl = intel_de_read(dev_priv, SKL_PS_CTRL(crtc->pipe, i));
+ if ((ctl & (PS_SCALER_EN | PS_PLANE_SEL_MASK)) != PS_SCALER_EN)
+ continue;
+
+ id = i;
+ crtc_state->pch_pfit.enabled = true;
+
+ pos = intel_de_read(dev_priv, SKL_PS_WIN_POS(crtc->pipe, i));
+ size = intel_de_read(dev_priv, SKL_PS_WIN_SZ(crtc->pipe, i));
+
+ drm_rect_init(&crtc_state->pch_pfit.dst,
+ pos >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Initialize dkl_phy spin lock from display code path (rev3)
== Series Details == Series: drm/i915: Initialize dkl_phy spin lock from display code path (rev3) URL : https://patchwork.freedesktop.org/series/116325/ State : success == Summary == CI Bug Log - changes from CI_DRM_13026 -> Patchwork_116325v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v3/index.html Participating hosts (38 -> 36) -- Missing(2): bat-rpls-2 fi-snb-2520m Known issues Here are the changes found in Patchwork_116325v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v3/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [PASS][3] -> [DMESG-FAIL][4] ([i915#5334]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v3/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@hangcheck: - bat-dg2-9: [PASS][5] -> [ABORT][6] ([i915#7913] / [i915#7979]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-dg2-9/igt@i915_selftest@l...@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v3/bat-dg2-9/igt@i915_selftest@l...@hangcheck.html * igt@i915_selftest@live@migrate: - bat-adlp-9: [PASS][7] -> [DMESG-FAIL][8] ([i915#7699]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-adlp-9/igt@i915_selftest@l...@migrate.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v3/bat-adlp-9/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@mman: - bat-rpls-1: [PASS][9] -> [TIMEOUT][10] ([i915#6794]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-rpls-1/igt@i915_selftest@l...@mman.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v3/bat-rpls-1/igt@i915_selftest@l...@mman.html * igt@kms_pipe_crc_basic@read-crc: - bat-dg2-11: NOTRUN -> [SKIP][11] ([i915#5354]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v3/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc.html Possible fixes * igt@i915_selftest@live@migrate: - bat-dg2-11: [DMESG-WARN][12] ([i915#7699]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-dg2-11/igt@i915_selftest@l...@migrate.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#5354]: https://gitlab.freedesktop.org/drm/intel/issues/5354 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#6794]: https://gitlab.freedesktop.org/drm/intel/issues/6794 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#7979]: https://gitlab.freedesktop.org/drm/intel/issues/7979 Build changes - * Linux: CI_DRM_13026 -> Patchwork_116325v3 CI-20190529: 20190529 CI_DRM_13026: 45bed7de41ad8bd909a82382a8fc4cb65e04ad56 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7259: 3d3a7f1c041d3f8d84d7457abf96adef0ea071cb @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116325v3: 45bed7de41ad8bd909a82382a8fc4cb65e04ad56 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits cd6f69bc2c09 drm/i915: Initialize dkl_phy spin lock from display code path == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116325v3/index.html
Re: [Intel-gfx] [PATCH v7 6/8] drm/i915/uapi/pxp: Fix UAPI spec comments and add GET_PARAM for PXP
On 14/04/2023 18:17, Teres Alexis, Alan Previn wrote: Hi Lionel, does this patch work for you? Hi, Sorry for the late answer. That looks good : Acked-by: Lionel Landwerlin Thanks, -Lionel On Mon, 2023-04-10 at 10:22 -0700, Ceraolo Spurio, Daniele wrote: On 4/6/2023 10:44 AM, Alan Previn wrote: alan:snip +/* + * Query the status of PXP support in i915. + * + * The query can fail in the following scenarios with the listed error codes: + * -ENODEV = PXP support is not available on the GPU device or in the kernel + *due to missing component drivers or kernel configs. + * If the IOCTL is successful, the returned parameter will be set to one of the + * following values: + * 0 = PXP support maybe available but underlying SOC fusing, BIOS or firmware + * configuration is unknown and a PXP-context-creation would be required + * for final verification of feature availibility. Would it be useful to add: 1 = PXP support is available And start returning that after we've successfully created our first session? Not sure if userspace would use this though, since they still need to handle the 0 case anyway. I'm also ok with this patch as-is, as long as you get an ack from the userspace drivers for this interface behavior: Reviewed-by: Daniele Ceraolo Spurio Daniele alan:snip
[Intel-gfx] [PATCH v2 2/2] drm/i915/guc: Dump error capture to dmesg on CTB error
From: John Harrison
In the past, There have been sporadic CTB failures which proved hard
to reproduce manually. The most effective solution was to dump the GuC
log at the point of failure and let the CI system do the repro. It is
preferable not to dump the GuC log via dmesg for all issues as it is
not always necessary and is not helpful for end users. But rather than
trying to re-invent the code to do this each time it is wanted, commit
the code but for DEBUG_GUC builds only.
v2: Use IS_ENABLED for testing config options.
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 53 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 +++
2 files changed, 59 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
index 1803a633ed648..dc5cd712f1ff5 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
@@ -13,6 +13,30 @@
#include "intel_guc_ct.h"
#include "intel_guc_print.h"
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+enum {
+ CT_DEAD_ALIVE = 0,
+ CT_DEAD_SETUP,
+ CT_DEAD_WRITE,
+ CT_DEAD_DEADLOCK,
+ CT_DEAD_H2G_HAS_ROOM,
+ CT_DEAD_READ,
+ CT_DEAD_PROCESS_FAILED,
+};
+
+static void ct_dead_ct_worker_func(struct work_struct *w);
+
+#define CT_DEAD(ct, reason)\
+ do { \
+ if (!(ct)->dead_ct_reported) { \
+ (ct)->dead_ct_reason |= 1 << CT_DEAD_##reason; \
+ queue_work(system_unbound_wq, &(ct)->dead_ct_worker); \
+ } \
+ } while (0)
+#else
+#define CT_DEAD(ct, reason)do { } while (0)
+#endif
+
static inline struct intel_guc *ct_to_guc(struct intel_guc_ct *ct)
{
return container_of(ct, struct intel_guc, ct);
@@ -93,6 +117,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
spin_lock_init(&ct->requests.lock);
INIT_LIST_HEAD(&ct->requests.pending);
INIT_LIST_HEAD(&ct->requests.incoming);
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+ INIT_WORK(&ct->dead_ct_worker, ct_dead_ct_worker_func);
+#endif
INIT_WORK(&ct->requests.worker, ct_incoming_request_worker_func);
tasklet_setup(&ct->receive_tasklet, ct_receive_tasklet_func);
init_waitqueue_head(&ct->wq);
@@ -319,11 +346,16 @@ int intel_guc_ct_enable(struct intel_guc_ct *ct)
ct->enabled = true;
ct->stall_time = KTIME_MAX;
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+ ct->dead_ct_reported = false;
+ ct->dead_ct_reason = CT_DEAD_ALIVE;
+#endif
return 0;
err_out:
CT_PROBE_ERROR(ct, "Failed to enable CTB (%pe)\n", ERR_PTR(err));
+ CT_DEAD(ct, SETUP);
return err;
}
@@ -434,6 +466,7 @@ static int ct_write(struct intel_guc_ct *ct,
corrupted:
CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
desc->head, desc->tail, desc->status);
+ CT_DEAD(ct, WRITE);
ctb->broken = true;
return -EPIPE;
}
@@ -504,6 +537,7 @@ static inline bool ct_deadlocked(struct intel_guc_ct *ct)
CT_ERROR(ct, "Head: %u\n (Dwords)", ct->ctbs.recv.desc->head);
CT_ERROR(ct, "Tail: %u\n (Dwords)", ct->ctbs.recv.desc->tail);
+ CT_DEAD(ct, DEADLOCK);
ct->ctbs.send.broken = true;
}
@@ -552,6 +586,7 @@ static inline bool h2g_has_room(struct intel_guc_ct *ct,
u32 len_dw)
head, ctb->size);
desc->status |= GUC_CTB_STATUS_OVERFLOW;
ctb->broken = true;
+ CT_DEAD(ct, H2G_HAS_ROOM);
return false;
}
@@ -908,6 +943,7 @@ static int ct_read(struct intel_guc_ct *ct, struct
ct_incoming_msg **msg)
CT_ERROR(ct, "Corrupted descriptor head=%u tail=%u status=%#x\n",
desc->head, desc->tail, desc->status);
ctb->broken = true;
+ CT_DEAD(ct, READ);
return -EPIPE;
}
@@ -1057,6 +1093,7 @@ static bool ct_process_incoming_requests(struct
intel_guc_ct *ct)
if (unlikely(err)) {
CT_ERROR(ct, "Failed to process CT message (%pe) %*ph\n",
ERR_PTR(err), 4 * request->size, request->msg);
+ CT_DEAD(ct, PROCESS_FAILED);
ct_free_msg(request);
}
@@ -1233,3 +1270,19 @@ void intel_guc_ct_print_info(struct intel_guc_ct *ct,
drm_printf(p, "Tail: %u\n",
ct->ctbs.recv.desc->tail);
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GUC)
+static void ct_dead_ct_worker_func(struct work_struct *w)
+{
+ struct intel_guc_ct *ct = container_of(w, struct intel_guc_ct,
dead_ct_worker);
+ struct intel_guc *guc = ct_to_guc(ct);
+
+ if (ct->dead_ct_reported)
+ return;
+
+ ct->dead_ct_reported = true;
+
+ guc_info(guc, "CTB is dead - reason=0x%X\n", ct->dead_ct_reason);
+ intel_klog_error_capture(guc_to_gt(guc), (in
[Intel-gfx] [PATCH v2 0/2] Add support for dumping error captures via kernel logging
From: John Harrison Sometimes, the only effective way to debug an issue is to dump all the interesting information at the point of failure. So add support for doing that. v2: Extra CONFIG wrapping (review feedback from Rodrigo) Signed-off-by: John Harrison John Harrison (2): drm/i915: Dump error capture to kernel log drm/i915/guc: Dump error capture to dmesg on CTB error drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 53 + drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 6 + drivers/gpu/drm/i915/i915_gpu_error.c | 132 ++ drivers/gpu/drm/i915/i915_gpu_error.h | 10 ++ 4 files changed, 201 insertions(+) -- 2.39.1
[Intel-gfx] [PATCH v2 1/2] drm/i915: Dump error capture to kernel log
From: John Harrison
This is useful for getting debug information out in certain
situations, such as failing kernel selftests and CI runs that don't
log error captures. It is especially useful for things like retrieving
GuC logs as GuC operation can't be tracked by adding printk or ftrace
entries.
v2: Add CONFIG_DRM_I915_DEBUG_GEM wrapper (review feedback by Rodrigo).
Signed-off-by: John Harrison
---
drivers/gpu/drm/i915/i915_gpu_error.c | 132 ++
drivers/gpu/drm/i915/i915_gpu_error.h | 10 ++
2 files changed, 142 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index f020c0086fbcd..03d62c250c465 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -2219,3 +2219,135 @@ void i915_disable_error_state(struct drm_i915_private
*i915, int err)
i915->gpu_error.first_error = ERR_PTR(err);
spin_unlock_irq(&i915->gpu_error.lock);
}
+
+#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
+void intel_klog_error_capture(struct intel_gt *gt,
+ intel_engine_mask_t engine_mask)
+{
+ static int g_count;
+ struct drm_i915_private *i915 = gt->i915;
+ struct i915_gpu_coredump *error;
+ intel_wakeref_t wakeref;
+ size_t buf_size = PAGE_SIZE * 128;
+ size_t pos_err;
+ char *buf, *ptr, *next;
+ int l_count = g_count++;
+ int line = 0;
+
+ /* Can't allocate memory during a reset */
+ if (test_bit(I915_RESET_BACKOFF, >->reset.flags)) {
+ drm_err(>->i915->drm, "[Capture/%d.%d] Inside GT reset,
skipping error capture :(\n",
+ l_count, line++);
+ return;
+ }
+
+ error = READ_ONCE(i915->gpu_error.first_error);
+ if (error) {
+ drm_err(&i915->drm, "[Capture/%d.%d] Clearing existing error
capture first...\n",
+ l_count, line++);
+ i915_reset_error_state(i915);
+ }
+
+ with_intel_runtime_pm(&i915->runtime_pm, wakeref)
+ error = i915_gpu_coredump(gt, engine_mask, CORE_DUMP_FLAG_NONE);
+
+ if (IS_ERR(error)) {
+ drm_err(&i915->drm, "[Capture/%d.%d] Failed to capture error
capture: %ld!\n",
+ l_count, line++, PTR_ERR(error));
+ return;
+ }
+
+ buf = kvmalloc(buf_size, GFP_KERNEL);
+ if (!buf) {
+ drm_err(&i915->drm, "[Capture/%d.%d] Failed to allocate buffer
for error capture!\n",
+ l_count, line++);
+ i915_gpu_coredump_put(error);
+ return;
+ }
+
+ drm_info(&i915->drm, "[Capture/%d.%d] Dumping i915 error capture for
%ps...\n",
+l_count, line++, __builtin_return_address(0));
+
+ /* Largest string length safe to print via dmesg */
+# define MAX_CHUNK800
+
+ pos_err = 0;
+ while (1) {
+ ssize_t got = i915_gpu_coredump_copy_to_buffer(error, buf,
pos_err, buf_size - 1);
+
+ if (got <= 0)
+ break;
+
+ buf[got] = 0;
+ pos_err += got;
+
+ ptr = buf;
+ while (got > 0) {
+ size_t count;
+ char tag[2];
+
+ next = strnchr(ptr, got, '\n');
+ if (next) {
+ count = next - ptr;
+ *next = 0;
+ tag[0] = '>';
+ tag[1] = '<';
+ } else {
+ count = got;
+ tag[0] = '}';
+ tag[1] = '{';
+ }
+
+ if (count > MAX_CHUNK) {
+ size_t pos;
+ char *ptr2 = ptr;
+
+ for (pos = MAX_CHUNK; pos < count; pos +=
MAX_CHUNK) {
+ char chr = ptr[pos];
+
+ ptr[pos] = 0;
+ drm_info(&i915->drm, "[Capture/%d.%d]
}%s{\n",
+l_count, line++, ptr2);
+ ptr[pos] = chr;
+ ptr2 = ptr + pos;
+
+ /*
+* If spewing large amounts of data via
a serial console,
+* this can be a very slow process. So
be friendly and try
+* not to cause 'softlockup on CPU'
problems.
+*/
+ cond_resched();
+ }
+
+ if (ptr2 < (ptr + count))
+
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915: Scaler/pfit stuff
== Series Details ==
Series: drm/i915: Scaler/pfit stuff
URL : https://patchwork.freedesktop.org/series/116661/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
DESCEND objtool
INSTALL libsubcmd_headers
LD [M] drivers/gpu/drm/i915/i915.o
CC [M] drivers/gpu/drm/i915/gvt/handlers.o
drivers/gpu/drm/i915/gvt/handlers.c: In function ‘pf_write’:
drivers/gpu/drm/i915/gvt/handlers.c:1565:38: error: ‘PS_PLANE_SEL_MASK’
undeclared (first use in this function); did you mean ‘PS_PHASE_MASK’?
1565 | offset == _PS_1C_CTRL) && (val & PS_PLANE_SEL_MASK) != 0) {
| ^
| PS_PHASE_MASK
drivers/gpu/drm/i915/gvt/handlers.c:1565:38: note: each undeclared identifier
is reported only once for each function it appears in
make[5]: *** [scripts/Makefile.build:252: drivers/gpu/drm/i915/gvt/handlers.o]
Error 1
make[4]: *** [scripts/Makefile.build:494: drivers/gpu/drm/i915] Error 2
make[3]: *** [scripts/Makefile.build:494: drivers/gpu/drm] Error 2
make[2]: *** [scripts/Makefile.build:494: drivers/gpu] Error 2
make[1]: *** [scripts/Makefile.build:494: drivers] Error 2
make: *** [Makefile:2025: .] Error 2
Build failed, no error log produced
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with the mm-stable tree
On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote: > Note there was a ppc compile fail, which is why we pushed the ttm revert. > That /should/ be fixed now, but would be good if you can confirm? According to Nathan (CCed) there's still issues with the interaction with the PowerPC tree. signature.asc Description: PGP signature
Re: [Intel-gfx] [PATCH 2/5] drm/i915/guc: Print status register when waiting for GuC to load
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote: From: John Harrison If the GuC load is taking an excessively long time, the wait loop currently prints the GT frequency. Extend that to include the GuC status as well so we can see if the GuC is actually making progress or not. Signed-off-by: John Harrison Reviewed-by: Daniele Ceraolo Spurio Daniele --- drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 -- 1 file changed, 4 insertions(+), 2 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 0ff088a5e51a8..364d0d546ec82 100644 --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c @@ -191,8 +191,10 @@ static int guc_wait_ucode(struct intel_guc *guc) if (!ret || !success) break; - guc_dbg(guc, "load still in progress, count = %d, freq = %dMHz\n", - count, intel_rps_read_actual_frequency(&uncore->gt->rps)); + guc_dbg(guc, "load still in progress, count = %d, freq = %dMHz, status = 0x%08X [0x%02X/%02X]\n", + count, intel_rps_read_actual_frequency(&uncore->gt->rps), status, + REG_FIELD_GET(GS_BOOTROM_MASK, status), + REG_FIELD_GET(GS_UKERNEL_MASK, status)); } after = ktime_get(); delta = ktime_sub(after, before);
Re: [Intel-gfx] [PATCH v7 6/8] drm/i915/uapi/pxp: Fix UAPI spec comments and add GET_PARAM for PXP
On Tue, 2023-04-18 at 21:06 +0300, Landwerlin, Lionel G wrote: > On 14/04/2023 18:17, Teres Alexis, Alan Previn wrote: > > Hi Lionel, does this patch work for you? > > > Hi, Sorry for the late answer. > > That looks good : alan: Great - thanks Lionel! :) I'll help get the MESA side PR out in coming days. > > Acked-by: Lionel Landwerlin > > > Thanks, > > > -Lionel alan:snip
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Tue, 18 Apr 2023 09:57:32 -0300
Jason Gunthorpe wrote:
> On Mon, Apr 17, 2023 at 02:06:42PM -0600, Alex Williamson wrote:
> > On Mon, 17 Apr 2023 16:31:56 -0300
> > Jason Gunthorpe wrote:
> >
> > > On Mon, Apr 17, 2023 at 01:01:40PM -0600, Alex Williamson wrote:
> > > > Yes, it's not trivial, but Jason is now proposing that we consider
> > > > mixing groups, cdevs, and multiple iommufd_ctxs as invalid. I think
> > > > this means that regardless of which device calls INFO, there's only one
> > > > answer (assuming same set of devices opened, all cdev, all within same
> > > > iommufd_ctx). Based on what I explained about my understanding of INFO2
> > > > and Jason agreed to, I think the output would be:
> > > >
> > > > flags: NOT_RESETABLE | DEV_ID
> > > > {
> > > > { valid devA-id, devA-BDF },
> > > > { valid devC-id, devC-BDF },
> > > > { valid devD-id, devD-BDF },
> > > > { invalid dev-id, devE-BDF },
> > > > }
> > > >
> > > > Here devB gets dropped because the kernel understands that devB is
> > > > unopened, affected, and owned. It's therefore not a blocker for
> > > > hot-reset.
> > >
> > > I don't think we want to drop anything because it makes the API
> > > ill suited for the debugging purpose.
> > >
> > > devb should be returned with an invalid dev_id if I understand your
> > > example. Maybe it should return with -1 as the dev_id instead of 0, to
> > > make the debugging a bit better.
> > >
> > > Userspace should look at only NOT_RESETTABLE to determine if it
> > > proceeds or not, and it should use the valid dev_id list to iterate
> > > over the devices it has open to do the config stuff.
> >
> > If an affected device is owned, not opened, and not interfering with
> > the reset, what is it adding to the API to report it for debugging
> > purposes?
>
> It lets it print the entire group of devices, this is the only way
> something can learn the actual list of all BDFs affected.
If we do so, userspace must be able to differentiate which devices are
blocking, which necessitates at least a bi-modal invalid dev-id.
> dev_id can just return 0, we don't need a complex bitmap. Userspace
> looks at the flag, if !NOT_RESETABLE then it ignores dev_id=0.
I'm having trouble with a succinct definition of dev-id == 0, is it "A
device affected by the hot-reset reset, which does not directly
contribute to the availability of the hot-reset, ex. an unopened device
within the same IOMMU group as an opened device (ie. this is not the
device responsible if hot-reset is unavailable). Whereas dev-id < 0
(== -1) is an affected device which prevents hot-reset, ex. an un-owned
device, device configured within a different iommufd_ctx, or device
opened outside of the vfio cdev API." Is that about right? Thanks,
Alex
Re: [Intel-gfx] [PATCH 1/5] drm/i915/guc: Decode another GuC load failure case
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Explain another potential firmware failure mode and early exit the
long wait if hit.
Signed-off-by: John Harrison
Reviewed-by: Daniele Ceraolo Spurio
Daniele
---
drivers/gpu/drm/i915/gt/uc/abi/guc_errors_abi.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c | 6 ++
2 files changed, 7 insertions(+)
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 bcb1129b36102..dabeaf4f245f3 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
@@ -44,6 +44,7 @@ enum intel_guc_load_status {
enum intel_bootrom_load_status {
INTEL_BOOTROM_STATUS_NO_KEY_FOUND = 0x13,
INTEL_BOOTROM_STATUS_AES_PROD_KEY_FOUND = 0x1A,
+ INTEL_BOOTROM_STATUS_PROD_KEY_CHECK_FAILURE = 0x2B,
INTEL_BOOTROM_STATUS_RSA_FAILED = 0x50,
INTEL_BOOTROM_STATUS_PAVPC_FAILED = 0x73,
INTEL_BOOTROM_STATUS_WOPCM_FAILED = 0x74,
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 6fda3aec5c66a..0ff088a5e51a8 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c
@@ -129,6 +129,7 @@ static inline bool guc_load_done(struct intel_uncore
*uncore, u32 *status, bool
case INTEL_BOOTROM_STATUS_RC6CTXCONFIG_FAILED:
case INTEL_BOOTROM_STATUS_MPUMAP_INCORRECT:
case INTEL_BOOTROM_STATUS_EXCEPTION:
+ case INTEL_BOOTROM_STATUS_PROD_KEY_CHECK_FAILURE:
*success = false;
return true;
}
@@ -219,6 +220,11 @@ static int guc_wait_ucode(struct intel_guc *guc)
guc_info(guc, "firmware signature verification
failed\n");
ret = -ENOEXEC;
break;
+
+ case INTEL_BOOTROM_STATUS_PROD_KEY_CHECK_FAILURE:
+ guc_info(guc, "firmware production part check
failure\n");
+ ret = -ENOEXEC;
+ break;
}
switch (ukernel) {
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for dumping error captures via kernel logging (rev2)
== Series Details ==
Series: Add support for dumping error captures via kernel logging (rev2)
URL : https://patchwork.freedesktop.org/series/116280/
State : warning
== Summary ==
Error: dim checkpatch failed
0fdd3a06a2b6 drm/i915: Dump error capture to kernel log
-:64: WARNING:OOM_MESSAGE: Possible unnecessary 'out of memory' message
#64: FILE: drivers/gpu/drm/i915/i915_gpu_error.c:2262:
+ if (!buf) {
+ drm_err(&i915->drm, "[Capture/%d.%d] Failed to allocate buffer
for error capture!\n",
total: 0 errors, 1 warnings, 0 checks, 151 lines checked
adfdeee9f311 drm/i915/guc: Dump error capture to dmesg on CTB error
-:39: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'ct' - possible side-effects?
#39: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c:29:
+#define CT_DEAD(ct, reason)\
+ do { \
+ if (!(ct)->dead_ct_reported) { \
+ (ct)->dead_ct_reason |= 1 << CT_DEAD_##reason; \
+ queue_work(system_unbound_wq, &(ct)->dead_ct_worker); \
+ } \
+ } while (0)
total: 0 errors, 0 warnings, 1 checks, 121 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add support for dumping error captures via kernel logging (rev2)
== Series Details == Series: Add support for dumping error captures via kernel logging (rev2) URL : https://patchwork.freedesktop.org/series/116280/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for dumping error captures via kernel logging (rev2)
== Series Details ==
Series: Add support for dumping error captures via kernel logging (rev2)
URL : https://patchwork.freedesktop.org/series/116280/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13026 -> Patchwork_116280v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116280v2/index.html
Participating hosts (38 -> 36)
--
Missing(2): bat-rpls-2 fi-snb-2520m
Known issues
Here are the changes found in Patchwork_116280v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@reset:
- bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#4983] / [i915#7981])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-rpls-1/igt@i915_selftest@l...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116280v2/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@workarounds:
- bat-adlp-6: [PASS][3] -> [INCOMPLETE][4] ([i915#4983] /
[i915#7677] / [i915#7913])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116280v2/bat-adlp-6/igt@i915_selftest@l...@workarounds.html
* igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1:
- bat-dg2-8: [PASS][5] -> [FAIL][6] ([i915#7932])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116280v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html
Possible fixes
* igt@i915_selftest@live@migrate:
- bat-dg2-11: [DMESG-WARN][7] ([i915#7699]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13026/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116280v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#7677]: https://gitlab.freedesktop.org/drm/intel/issues/7677
[i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#7981]: https://gitlab.freedesktop.org/drm/intel/issues/7981
Build changes
-
* Linux: CI_DRM_13026 -> Patchwork_116280v2
CI-20190529: 20190529
CI_DRM_13026: 45bed7de41ad8bd909a82382a8fc4cb65e04ad56 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7259: 3d3a7f1c041d3f8d84d7457abf96adef0ea071cb @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116280v2: 45bed7de41ad8bd909a82382a8fc4cb65e04ad56 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
fd841c544085 drm/i915/guc: Dump error capture to dmesg on CTB error
725a11e64b63 drm/i915: Dump error capture to kernel log
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116280v2/index.html
[Intel-gfx] [PATCH v2 11/15] drm/i915: Rename skl+ scaler binding bits
From: Ville Syrjälä
Rename the scaler binding bits to match the spec more closely.
Also call the parameters 'plane_id' to make it a bit more clear
what to pass in.
v2: Don't break gvt
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/skl_scaler.c | 12 ++--
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
drivers/gpu/drm/i915/i915_reg.h | 9 +
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/skl_scaler.c
b/drivers/gpu/drm/i915/display/skl_scaler.c
index ec930aec21c4..a96f8ecbeec1 100644
--- a/drivers/gpu/drm/i915/display/skl_scaler.c
+++ b/drivers/gpu/drm/i915/display/skl_scaler.c
@@ -396,7 +396,7 @@ static int intel_atomic_setup_scaler(struct
intel_crtc_scaler_state *scaler_stat
mode = PS_SCALER_MODE_PLANAR;
if (linked)
- mode |= PS_PLANE_Y_SEL(linked->id);
+ mode |= PS_BINDING_Y_PLANE(linked->id);
}
} else if (DISPLAY_VER(dev_priv) >= 10) {
mode = PS_SCALER_MODE_NORMAL;
@@ -741,8 +741,8 @@ void skl_pfit_enable(const struct intel_crtc_state
*crtc_state)
id = scaler_state->scaler_id;
- ps_ctrl = skl_scaler_get_filter_select(crtc_state->hw.scaling_filter,
0);
- ps_ctrl |= PS_SCALER_EN | scaler_state->scalers[id].mode;
+ ps_ctrl = PS_SCALER_EN | PS_BINDING_PIPE |
scaler_state->scalers[id].mode |
+ skl_scaler_get_filter_select(crtc_state->hw.scaling_filter, 0);
skl_scaler_setup_filter(dev_priv, pipe, id, 0,
crtc_state->hw.scaling_filter);
@@ -804,8 +804,8 @@ skl_program_plane_scaler(struct intel_plane *plane,
uv_rgb_vphase = skl_scaler_calc_phase(1, vscale, false);
}
- ps_ctrl = skl_scaler_get_filter_select(plane_state->hw.scaling_filter,
0);
- ps_ctrl |= PS_SCALER_EN | PS_PLANE_SEL(plane->id) | scaler->mode;
+ ps_ctrl = PS_SCALER_EN | PS_BINDING_PLANE(plane->id) | scaler->mode |
+ skl_scaler_get_filter_select(plane_state->hw.scaling_filter, 0);
skl_scaler_setup_filter(dev_priv, pipe, scaler_id, 0,
plane_state->hw.scaling_filter);
@@ -870,7 +870,7 @@ void skl_scaler_get_config(struct intel_crtc_state
*crtc_state)
u32 ctl, pos, size;
ctl = intel_de_read(dev_priv, SKL_PS_CTRL(crtc->pipe, i));
- if ((ctl & (PS_SCALER_EN | PS_PLANE_SEL_MASK)) != PS_SCALER_EN)
+ if ((ctl & (PS_SCALER_EN | PS_BINDING_MASK)) != (PS_SCALER_EN |
PS_BINDING_PIPE))
continue;
id = i;
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 4b45a041ac5c..a9f7fa9b90bd 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -1562,7 +1562,7 @@ static int pf_write(struct intel_vgpu *vgpu,
if ((offset == _PS_1A_CTRL || offset == _PS_2A_CTRL ||
offset == _PS_1B_CTRL || offset == _PS_2B_CTRL ||
- offset == _PS_1C_CTRL) && (val & PS_PLANE_SEL_MASK) != 0) {
+ offset == _PS_1C_CTRL) && (val & PS_BINDING_MASK) !=
PS_BINDING_PIPE) {
drm_WARN_ONCE(&i915->drm, true,
"VM(%d): guest is trying to scaling a plane\n",
vgpu->id);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 919d999a2345..f8e6b86facc3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4056,8 +4056,9 @@
#define SKL_PS_SCALER_MODE_NV12 (2 << 28)
#define PS_SCALER_MODE_PLANAR (1 << 29)
#define PS_SCALER_MODE_NORMAL (0 << 29)
-#define PS_PLANE_SEL_MASK (7 << 25)
-#define PS_PLANE_SEL(plane) (((plane) + 1) << 25)
+#define PS_BINDING_MASK (7 << 25)
+#define PS_BINDING_PIPE (0 << 25)
+#define PS_BINDING_PLANE(plane_id) (((plane_id) + 1) << 25)
#define PS_FILTER_MASK (3 << 23)
#define PS_FILTER_MEDIUM (0 << 23)
#define PS_FILTER_PROGRAMMED (1 << 23)
@@ -4073,8 +4074,8 @@
#define PS_VADAPT_MODE_LEAST_ADAPT (0 << 5)
#define PS_VADAPT_MODE_MOD_ADAPT (1 << 5)
#define PS_VADAPT_MODE_MOST_ADAPT (3 << 5)
-#define PS_PLANE_Y_SEL_MASK (7 << 5)
-#define PS_PLANE_Y_SEL(plane) (((plane) + 1) << 5)
+#define PS_BINDING_Y_MASK (7 << 5)
+#define PS_BINDING_Y_PLANE(plane_id) (((plane_id) + 1) << 5)
#define PS_Y_VERT_FILTER_SELECT(set) ((set) << 4)
#define PS_Y_HORZ_FILTER_SELECT(set) ((set) << 3)
#define PS_UV_VERT_FILTER_SELECT(set) ((set) << 2)
--
2.39.2
[Intel-gfx] [PATCH v2 3/4] 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:A step.
v1.1: Fix checkpatch warning.
v2: Change the check to reflect the wa at other palces(Lucas)
Cc: Lucas De Marchi
Cc: Umesh Nerlige Ramappa
Signed-off-by: Madhumitha Tolakanahalli Pradeep
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 88e881b100cf..ee3e8352637f 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -1629,16 +1629,16 @@ 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))
- return;
-
- intel_engine_stop_cs(engine);
-
/*
* Wa_22011802037: In addition to stopping the cs, we need
* to wait for any pending mi force wakeups
*/
- intel_engine_wait_for_pending_mi_fw(engine);
+ 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))) {
+ intel_engine_stop_cs(engine);
+ intel_engine_wait_for_pending_mi_fw(engine);
+ }
}
static void guc_reset_nop(struct intel_engine_cs *engine)
--
2.34.1
[Intel-gfx] [PATCH v2 1/4] 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.
v2: Use dc_of as power well name.
Move xehpd power domain definitions near power well definition.(Imre)
Bspec: 49193
Signed-off-by: Matt Roper
Signed-off-by: Radhakrishna Sripada
Reviewed-by: Imre Deak
---
.../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..5906b62e79f1 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,18 @@ 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_dc_off[] = {
{
.instances = &I915_PW_INSTANCES(
I915_PW("DC_off", &xelpd_pwdoms_dc_off,
.id = SKL_DISP_DC_OFF),
),
.ops = &gen9_dc_off_power_well_ops,
- }, {
+ }
+};
+
+static const struct i915_power_well_desc xelpd_power_wells_main[] = {
+ {
.instances = &I915_PW_INSTANCES(
I915_PW("PW_2", &xelpd_pwdoms_pw_2,
.hsw.idx = ICL_PW_CTL_IDX_PW_2,
@@ -1400,6 +1405,34 @@ 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_dc_off),
+ I915_PW_DESCRIPTORS(xelpd_power_wells_main),
+};
+
+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_dc_off[] = {
+ {
+ .instances = &I915_PW_INSTANCES(
+ I915_PW("DC_off", &xehpd_pwdoms_dc_off,
+ .id = SKL_DISP_DC_OFF),
+ ),
+ .ops = &gen9_dc_off_power_well_ops,
+ }
+};
+
+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_dc_off),
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] [PATCH v2 2/4] 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
Reviewed-by: Imre Deak
---
.../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 5906b62e79f1..100582f10590 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 = &I915_PW_INSTANCES(
- I915_PW("DC_off", &xelpdp_pwdoms_dc_off,
- .id = SKL_DISP_DC_OFF),
- ),
- .ops = &gen9_dc_off_power_well_ops,
- }, {
.instances = &I915_PW_INSTANCES(
I915_PW("PW_2", &xelpdp_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_dc_off),
I915_PW_DESCRIPTORS(xelpdp_power_wells_main),
};
--
2.34.1
[Intel-gfx] [PATCH v2 0/4] More MTL WA and powerwell patches
This series adds 2 MTL WA's and 2 patches to fix re-use "DC off" power wells. v2: 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 .../i915/display/intel_display_power_map.c| 57 +-- drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 + .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 12 ++-- 3 files changed, 48 insertions(+), 24 deletions(-) -- 2.34.1
[Intel-gfx] [PATCH v2 4/4] 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 b925ef47304b..312eb8b5f949 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
Re: [Intel-gfx] [PATCH 11/15] drm/i915: Rename skl+ scaler binding bits
Hi Ville,
kernel test robot noticed the following build errors:
[auto build test ERROR on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Ville-Syrjala/drm-i915-Check-pipe-source-size-when-using-skl-scalers/20230419-015829
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
patch link:
https://lore.kernel.org/r/20230418175528.13117-12-ville.syrjala%40linux.intel.com
patch subject: [Intel-gfx] [PATCH 11/15] drm/i915: Rename skl+ scaler binding
bits
config: x86_64-allyesconfig
(https://download.01.org/0day-ci/archive/20230419/202304190547.olynaai3-...@intel.com/config)
compiler: gcc-11 (Debian 11.3.0-8) 11.3.0
reproduce (this is a W=1 build):
#
https://github.com/intel-lab-lkp/linux/commit/19871303e2971d47d4ac0557533295744c04cfd4
git remote add linux-review https://github.com/intel-lab-lkp/linux
git fetch --no-tags linux-review
Ville-Syrjala/drm-i915-Check-pipe-source-size-when-using-skl-scalers/20230419-015829
git checkout 19871303e2971d47d4ac0557533295744c04cfd4
# save the config file
mkdir build_dir && cp config build_dir/.config
make W=1 O=build_dir ARCH=x86_64 olddefconfig
make W=1 O=build_dir ARCH=x86_64 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/202304190547.olynaai3-...@intel.com/
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/gvt/handlers.c: In function 'pf_write':
>> drivers/gpu/drm/i915/gvt/handlers.c:1565:45: error: 'PS_PLANE_SEL_MASK'
>> undeclared (first use in this function); did you mean 'PS_PHASE_MASK'?
1565 |offset == _PS_1C_CTRL) && (val & PS_PLANE_SEL_MASK) != 0)
{
| ^
| PS_PHASE_MASK
drivers/gpu/drm/i915/gvt/handlers.c:1565:45: note: each undeclared
identifier is reported only once for each function it appears in
vim +1565 drivers/gpu/drm/i915/gvt/handlers.c
e39c5add322184 Zhi Wang 2016-09-02 1556
04d348ae3f0aea Zhi Wang 2016-04-25 1557 static int pf_write(struct
intel_vgpu *vgpu,
04d348ae3f0aea Zhi Wang 2016-04-25 1558unsigned int
offset, void *p_data, unsigned int bytes)
04d348ae3f0aea Zhi Wang 2016-04-25 1559 {
a61ac1e75105a0 Chris Wilson 2020-03-06 1560struct drm_i915_private
*i915 = vgpu->gvt->gt->i915;
04d348ae3f0aea Zhi Wang 2016-04-25 1561u32 val = *(u32
*)p_data;
04d348ae3f0aea Zhi Wang 2016-04-25 1562
04d348ae3f0aea Zhi Wang 2016-04-25 1563if ((offset ==
_PS_1A_CTRL || offset == _PS_2A_CTRL ||
04d348ae3f0aea Zhi Wang 2016-04-25 1564 offset ==
_PS_1B_CTRL || offset == _PS_2B_CTRL ||
04d348ae3f0aea Zhi Wang 2016-04-25 @1565 offset ==
_PS_1C_CTRL) && (val & PS_PLANE_SEL_MASK) != 0) {
12d5861973c70f Pankaj Bharadiya 2020-02-20 1566
drm_WARN_ONCE(&i915->drm, true,
12d5861973c70f Pankaj Bharadiya 2020-02-20 1567
"VM(%d): guest is trying to scaling a plane\n",
04d348ae3f0aea Zhi Wang 2016-04-25 1568
vgpu->id);
04d348ae3f0aea Zhi Wang 2016-04-25 1569return 0;
04d348ae3f0aea Zhi Wang 2016-04-25 1570}
04d348ae3f0aea Zhi Wang 2016-04-25 1571
04d348ae3f0aea Zhi Wang 2016-04-25 1572return
intel_vgpu_default_mmio_write(vgpu, offset, p_data, bytes);
04d348ae3f0aea Zhi Wang 2016-04-25 1573 }
04d348ae3f0aea Zhi Wang 2016-04-25 1574
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Scaler/pfit stuff (rev2)
== Series Details == Series: drm/i915: Scaler/pfit stuff (rev2) URL : https://patchwork.freedesktop.org/series/116661/ State : warning == Summary == Error: dim checkpatch failed 96742f02457a drm/i915: Check pipe source size when using skl+ scalers -:19: WARNING:COMMIT_LOG_USE_LINK: Unknown link reference 'Closes:', use 'Link:' instead #19: Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8357 total: 0 errors, 1 warnings, 0 checks, 29 lines checked 020b73ecaea1 drm/i915: Relocate VBLANK_EVASION_TIME_US 985d1c61ab4b drm/i915: Relocate intel_atomic_setup_scalers() d8119d553652 drm/i915: Relocate skl_get_pfit_config() abb5209c730e drm/i915: Use REG_BIT() & co for the pre-ilk pfit registers e661ff574bbc drm/i915: Namespace pfit registers properly 5f7ed896b1db drm/i915: Use REG_BIT() & co. for ilk+ pfit registers 8337eb734cde drm/i915: Drop a useless forward declararion 152fabebf7a4 drm/i915: Define bitmasks for ilk pfit window pos/size afe2b9bb87f3 drm/i915: Remove dead scaler register defines 500da878f1fb drm/i915: Rename skl+ scaler binding bits c4690f428705 drm/i915: s/PS_COEE_INDEX_AUTO_INC/PS_COEF_INDEX_AUTO_INC/ 73ea67a05509 drm/i915: Define bitmasks for sik+ scaler window pos/size dcfed7ebc951 drm/i915: Use REG_BIT() & co. for pipe scaler registers f9431f7d6815 drm/i915: Define more PS_CTRL bits -:44: WARNING:LONG_LINE_COMMENT: line length of 107 exceeds 100 columns #44: FILE: drivers/gpu/drm/i915/i915_reg.h:4076: +#define PS_PIPE_SCALER_LOC_AFTER_OUTPUT_CSC REG_FIELD_PREP(PS_SCALER_LOCATION_MASK, 0) /* non-linear */ -:45: WARNING:LONG_LINE_COMMENT: line length of 103 exceeds 100 columns #45: FILE: drivers/gpu/drm/i915/i915_reg.h:4077: +#define PS_PIPE_SCALER_LOC_AFTER_CSC REG_FIELD_PREP(PS_SCALER_LOCATION_MASK, 1) /* linear */ total: 0 errors, 2 warnings, 0 checks, 31 lines checked
