Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+
On Thu, 1 Jul 2021 21:28:06 +0200
Daniel Vetter wrote:
> On Thu, Jul 1, 2021 at 8:27 PM Martin Peres wrote:
> >
> > On 01/07/2021 11:14, Pekka Paalanen wrote:
> > > On Wed, 30 Jun 2021 11:58:25 -0700
> > > John Harrison wrote:
> > >
> > >> On 6/30/2021 01:22, Martin Peres wrote:
> > >>> On 24/06/2021 10:05, Matthew Brost wrote:
> > From: Daniele Ceraolo Spurio
> >
> > Unblock GuC submission on Gen11+ platforms.
> >
> > Signed-off-by: Michal Wajdeczko
> > Signed-off-by: Daniele Ceraolo Spurio
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | 3 +--
> > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14
> > +-
> > 4 files changed, 19 insertions(+), 7 deletions(-)
> >
> > >
> > > ...
> > >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > index 7a69c3c027e9..61be0aa81492 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > @@ -34,8 +34,15 @@ static void uc_expand_default_options(struct
> > intel_uc *uc)
> > return;
> > }
> > -/* Default: enable HuC authentication only */
> > -i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
> > +/* Intermediate platforms are HuC authentication only */
> > +if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
> > +drm_dbg(&i915->drm, "Disabling GuC only due to old
> > platform\n");
> > >>>
> > >>> This comment does not seem accurate, given that DG1 is barely out, and
> > >>> ADL is not out yet. How about:
> > >>>
> > >>> "Disabling GuC on untested platforms"?
> > >>>
> > >> Just because something is not in the shops yet does not mean it is new.
> > >> Technology is always obsolete by the time it goes on sale.
> > >
> > > That is a very good reason to not use terminology like "new", "old",
> > > "current", "modern" etc. at all.
> > >
> > > End users like me definitely do not share your interpretation of "old".
> >
> > Yep, old and new is relative. In the end, what matters is the validation
> > effort, which is why I was proposing "untested platforms".
> >
> > Also, remember that you are not writing these messages for Intel
> > engineers, but instead are writing for Linux *users*.
>
> It's drm_dbg. Users don't read this stuff, at least not users with no
> clue what the driver does and stuff like that.
If I had a problem, I would read it, and I have no clue what anything
of that is.
Thanks,
pq
pgpv0LRdBO9KY.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: IRQ fixes (rev4)
== Series Details == Series: drm/i915: IRQ fixes (rev4) URL : https://patchwork.freedesktop.org/series/92053/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10301_full -> Patchwork_20514_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20514_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20514_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20514_full: ### IGT changes ### Possible regressions * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-async-flip: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-iclb4/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-iclb1/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html * igt@kms_draw_crc@draw-method-xrgb-render-ytiled: - shard-glk: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-glk6/igt@kms_draw_...@draw-method-xrgb-render-ytiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-glk7/igt@kms_draw_...@draw-method-xrgb-render-ytiled.html Known issues Here are the changes found in Patchwork_20514_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@flink: - shard-kbl: [PASS][5] -> [INCOMPLETE][6] ([i915#2369]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-kbl6/igt@drm_import_exp...@flink.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-kbl2/igt@drm_import_exp...@flink.html * igt@gem_create@create-clear: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#3160]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-skl1/igt@gem_cre...@create-clear.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-skl4/igt@gem_cre...@create-clear.html * igt@gem_eio@unwedge-stress: - shard-tglb: [PASS][9] -> [TIMEOUT][10] ([i915#2369] / [i915#3063] / [i915#3648]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-tglb7/igt@gem_...@unwedge-stress.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-tglb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-glk4/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-kbl: [PASS][13] -> [FAIL][14] ([i915#2842]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-kbl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-kbl4/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][15] -> [SKIP][16] ([fdo#109271]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-kbl7/igt@gem_exec_fair@basic-p...@vcs1.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-kbl6/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][17] ([i915#2658]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-apl3/igt@gem_pr...@exhaustion.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-apl3/igt@gem_workarou...@suspend-resume-context.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-apl6/igt@gem_workarou...@suspend-resume-context.html * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][20] -> [DMESG-WARN][21] ([i915#1436] / [i915#716]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-skl3/igt@gen9_exec_pa...@allowed-single.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-skl5/igt@gen9_exec_pa...@allowed-single.html * igt@gen9_exec_parse@bb-large: - shard-apl: NOTRUN -> [FAIL][22] ([i915#3296]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20514/shard-apl2/igt@gen9_exec_pa...@bb-large.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb:
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Use RUNTIME_INFO->stp for DMC
On Wed, 30 Jun 2021, Lucas De Marchi wrote:
> Typo: RUNTIME_INFO->stp
>
> On Wed, Jun 30, 2021 at 04:06:24PM -0700, Anusha Srivatsa wrote:
>>On the dmc side,we maintain a lookup table with different display
>>stepping-substepping combinations.
>>
>>Instead of adding new table for every new platform, lets ues
>>the stepping info from RUNTIME_INFO(dev_priv)->step
>>Adding the helper intel_get_display_step().
>>
>>Cc: Lucas De Marchi
>>Signed-off-by: Anusha Srivatsa
>>---
>> drivers/gpu/drm/i915/display/intel_dmc.c | 49 ++--
>> 1 file changed, 45 insertions(+), 4 deletions(-)
>>
>>diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
>>b/drivers/gpu/drm/i915/display/intel_dmc.c
>>index f8789d4543bf..c7ff7ff3f412 100644
>>--- a/drivers/gpu/drm/i915/display/intel_dmc.c
>>+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>>@@ -266,14 +266,55 @@ static const struct stepping_info icl_stepping_info[] =
>>{
>> };
>>
>> static const struct stepping_info no_stepping_info = { '*', '*' };
>>+struct stepping_info *display_step;
>>+
>>+static struct stepping_info *
>>+intel_get_display_stepping(struct intel_step_info step)
>>+{
>>+
>>+ switch (step.display_step) {
>>+ case STEP_A0:
>>+ display_step->stepping = 'A';
>>+ display_step->substepping = '0';
>>+ break;
>>+ case STEP_A2:
>>+ display_step->stepping = 'A';
>>+ display_step->substepping = '2';
>>+ break;
>>+ case STEP_B0:
>>+ display_step->stepping = 'B';
>>+ display_step->substepping = '0';
>>+ break;
>>+ case STEP_B1:
>>+ display_step->stepping = 'B';
>>+ display_step->substepping = '1';
>>+ break;
>>+ case STEP_C0:
>>+ display_step->stepping = 'C';
>>+ display_step->substepping = '0';
>>+ break;
>>+ case STEP_D0:
>>+ display_step->stepping = 'D';
>>+ display_step->substepping = '0';
>>+ break;
>>+ default:
>>+ display_step->stepping = '*';
>>+ display_step->substepping = '*';
>>+ break;
>>+ }
>
>
> "crazy" idea that would avoid this type of conversion:
> changing the step enum to be:
>
>
> #define make_step(letter, num) (int)(((letter) << 8 ) | (num))
>
> STEP_A0 = make_step('A', '0'),
> STEP_A1 = make_step('A', '1'),
>
> and adapt the rest of the code to play with u16 instead of u8, and
> handle the STEP_FUTURE/STEP_NONE/STEP_FOREVER.
> Maybe it is crazy, dunno.
>
> +Jani / +Jose. Thoughts?
Frankly, I think all of this should be incorporated to intel_step.[ch]
instead of having a semi-overlapping handling here. Just look at the
amount of duplication already.
BR,
Jani.
>
>
> For this version the next comment is probably more important.
>
>>+ return display_step;
>>+}
>>
>> static const struct stepping_info *
>> intel_get_stepping_info(struct drm_i915_private *dev_priv)
>> {
>> const struct stepping_info *si;
>>+ struct intel_step_info step = RUNTIME_INFO(dev_priv)->step;
>> unsigned int size;
>>
>>- if (IS_ICELAKE(dev_priv)) {
>>+ if (DISPLAY_VER(dev_priv) >= 12) {
>>+ si = intel_get_display_stepping(step);
>>+ } else if (IS_ICELAKE(dev_priv)) {
>> size = ARRAY_SIZE(icl_stepping_info);
>> si = icl_stepping_info;
>
> can we move the other ones too? Just use display_step for all platforms.
> Notice that before the separation we will have display_step ==
> graphics_step, so it should just work.
>
>
> Lucas De Marchi
>
>> } else if (IS_SKYLAKE(dev_priv)) {
>>@@ -287,10 +328,10 @@ intel_get_stepping_info(struct drm_i915_private
>>*dev_priv)
>> si = NULL;
>> }
>>
>>- if (INTEL_REVID(dev_priv) < size)
>>- return si + INTEL_REVID(dev_priv);
>>+ if (DISPLAY_VER(dev_priv) < 12)
>>+ return INTEL_REVID(dev_priv) < size ? si +
>>INTEL_REVID(dev_priv) : &no_stepping_info;
>>
>>- return &no_stepping_info;
>>+ return si;
>> }
>>
>> static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)
>>--
>>2.32.0
>>
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: address potential UAF bugs with drm_master ptrs
== Series Details == Series: drm: address potential UAF bugs with drm_master ptrs URL : https://patchwork.freedesktop.org/series/92131/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10301_full -> Patchwork_20515_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20515_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20515_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20515_full: ### IGT changes ### Possible regressions * igt@gem_eio@banned: - shard-skl: [PASS][1] -> [DMESG-WARN][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-skl4/igt@gem_...@banned.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-skl6/igt@gem_...@banned.html * igt@gem_exec_reloc@basic-gtt-read: - shard-apl: NOTRUN -> [DMESG-WARN][3] +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-apl7/igt@gem_exec_re...@basic-gtt-read.html * igt@kms_big_fb@linear-max-hw-stride-32bpp-rotate-180: - shard-snb: [PASS][4] -> [DMESG-WARN][5] +10 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-snb5/igt@kms_big...@linear-max-hw-stride-32bpp-rotate-180.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-snb5/igt@kms_big...@linear-max-hw-stride-32bpp-rotate-180.html * igt@kms_big_fb@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip: - shard-tglb: [PASS][6] -> [DMESG-WARN][7] +15 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-tglb1/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-tglb7/igt@kms_big...@y-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html * igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_ccs: - shard-iclb: [PASS][8] -> [DMESG-WARN][9] +15 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-iclb5/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_ccs.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-iclb2/igt@kms_ccs@pipe-a-crc-primary-basic-y_tiled_ccs.html * igt@kms_cursor_crc@pipe-c-cursor-dpms: - shard-glk: [PASS][10] -> [DMESG-WARN][11] +11 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-glk8/igt@kms_cursor_...@pipe-c-cursor-dpms.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-glk6/igt@kms_cursor_...@pipe-c-cursor-dpms.html * igt@kms_plane_cursor@pipe-b-overlay-size-64: - shard-kbl: [PASS][12] -> [DMESG-WARN][13] +13 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-kbl1/igt@kms_plane_cur...@pipe-b-overlay-size-64.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-kbl4/igt@kms_plane_cur...@pipe-b-overlay-size-64.html * igt@kms_vblank@pipe-b-query-forked: - shard-apl: [PASS][14] -> [DMESG-WARN][15] +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-apl6/igt@kms_vbl...@pipe-b-query-forked.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-apl3/igt@kms_vbl...@pipe-b-query-forked.html * igt@kms_vblank@pipe-b-wait-forked-busy-hang: - shard-glk: [PASS][16] -> [INCOMPLETE][17] +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-glk8/igt@kms_vbl...@pipe-b-wait-forked-busy-hang.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-glk2/igt@kms_vbl...@pipe-b-wait-forked-busy-hang.html * igt@kms_vblank@pipe-c-query-forked-busy-hang: - shard-tglb: [PASS][18] -> [INCOMPLETE][19] +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-tglb3/igt@kms_vbl...@pipe-c-query-forked-busy-hang.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20515/shard-tglb6/igt@kms_vbl...@pipe-c-query-forked-busy-hang.html Warnings * igt@runner@aborted: - shard-iclb: ([FAIL][20], [FAIL][21], [FAIL][22]) ([i915#1814] / [i915#3002]) -> ([FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], [FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], [FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [FAIL][46], [FAIL][47]) ([i915#1814]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-iclb5/igt@run...@aborted.html [21]
Re: [Intel-gfx] [PATCH 16/53] drm/i915/xehpsdv: add initial XeHP SDV definitions
On Thu, 01 Jul 2021, Matt Roper wrote:
> From: Lucas De Marchi
>
> XeHP SDV is a Intel® dGPU without display. This is just the definition
> of some basic platform macros, by large a copy of current state of
> Tigerlake which does not reflect the end state of this platform.
>
> Bspec: 44467, 48077
> Cc: Rodrigo Vivi
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Daniele Ceraolo Spurio
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Stuart Summers
> Signed-off-by: Tomas Winkler
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_drv.h | 10 ++
> drivers/gpu/drm/i915/i915_pci.c | 20
> drivers/gpu/drm/i915/intel_device_info.c | 1 +
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> 4 files changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c02600850246..63bed18a2be7 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1406,6 +1406,7 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define IS_DG1(dev_priv)IS_PLATFORM(dev_priv, INTEL_DG1)
> #define IS_ALDERLAKE_S(dev_priv) IS_PLATFORM(dev_priv, INTEL_ALDERLAKE_S)
> #define IS_ALDERLAKE_P(dev_priv) IS_PLATFORM(dev_priv, INTEL_ALDERLAKE_P)
> +#define IS_XEHPSDV(dev_priv) IS_PLATFORM(dev_priv, INTEL_XEHPSDV)
> #define IS_HSW_EARLY_SDV(dev_priv) (IS_HASWELL(dev_priv) && \
> (INTEL_DEVID(dev_priv) & 0xFF00) == 0x0C00)
> #define IS_BDW_ULT(dev_priv) \
> @@ -1564,6 +1565,15 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> (IS_ALDERLAKE_P(__i915) && \
>IS_GT_STEP(__i915, since, until))
>
> +#define XEHPSDV_REVID_A0 0x0
> +#define XEHPSDV_REVID_A1 0x1
> +#define XEHPSDV_REVID_A_LAST XEHPSDV_REVID_A1
> +#define XEHPSDV_REVID_B0 0x4
> +#define XEHPSDV_REVID_C0 0x8
> +
> +#define IS_XEHPSDV_REVID(p, since, until) \
> + (IS_XEHPSDV(p) && IS_REVID(p, since, until))
For new platforms we should be using the mechanisms in
intel_step.[ch]. As well as converting the old ones.
BR,
Jani.
> +
> #define IS_LP(dev_priv) (INTEL_INFO(dev_priv)->is_lp)
> #define IS_GEN9_LP(dev_priv) (GRAPHICS_VER(dev_priv) == 9 && IS_LP(dev_priv))
> #define IS_GEN9_BC(dev_priv) (GRAPHICS_VER(dev_priv) == 9 &&
> !IS_LP(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index 88b279452b87..046309e95f43 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1020,6 +1020,26 @@ static const struct intel_device_info adl_p_info = {
> .ppgtt_size = 48, \
> .ppgtt_type = INTEL_PPGTT_FULL
>
> +#define XE_HPM_FEATURES \
> + .media_ver = 12, \
> + .media_ver_release = 50
> +
> +__maybe_unused
> +static const struct intel_device_info xehpsdv_info = {
> + XE_HP_FEATURES,
> + XE_HPM_FEATURES,
> + DGFX_FEATURES,
> + PLATFORM(INTEL_XEHPSDV),
> + .display = { },
> + .pipe_mask = 0,
> + .platform_engine_mask =
> + BIT(RCS0) | BIT(BCS0) |
> + BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
> + BIT(VCS0) | BIT(VCS1) | BIT(VCS2) | BIT(VCS3) |
> + BIT(VCS4) | BIT(VCS5) | BIT(VCS6) | BIT(VCS7),
> + .require_force_probe = 1,
> +};
> +
> #undef PLATFORM
>
> /*
> diff --git a/drivers/gpu/drm/i915/intel_device_info.c
> b/drivers/gpu/drm/i915/intel_device_info.c
> index e8ad14f002c1..7b37b68f4548 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.c
> +++ b/drivers/gpu/drm/i915/intel_device_info.c
> @@ -68,6 +68,7 @@ static const char * const platform_names[] = {
> PLATFORM_NAME(DG1),
> PLATFORM_NAME(ALDERLAKE_S),
> PLATFORM_NAME(ALDERLAKE_P),
> + PLATFORM_NAME(XEHPSDV),
> };
> #undef PLATFORM_NAME
>
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index f824de632cfe..e8684199b0c9 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -88,6 +88,7 @@ enum intel_platform {
> INTEL_DG1,
> INTEL_ALDERLAKE_S,
> INTEL_ALDERLAKE_P,
> + INTEL_XEHPSDV,
> INTEL_MAX_PLATFORMS
> };
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+
On 02/07/2021 10:29, Pekka Paalanen wrote:
On Thu, 1 Jul 2021 21:28:06 +0200
Daniel Vetter wrote:
On Thu, Jul 1, 2021 at 8:27 PM Martin Peres wrote:
On 01/07/2021 11:14, Pekka Paalanen wrote:
On Wed, 30 Jun 2021 11:58:25 -0700
John Harrison wrote:
On 6/30/2021 01:22, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | 3 +--
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14 +-
4 files changed, 19 insertions(+), 7 deletions(-)
...
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7a69c3c027e9..61be0aa81492 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -34,8 +34,15 @@ static void uc_expand_default_options(struct
intel_uc *uc)
return;
}
-/* Default: enable HuC authentication only */
-i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+/* Intermediate platforms are HuC authentication only */
+if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
+drm_dbg(&i915->drm, "Disabling GuC only due to old
platform\n");
This comment does not seem accurate, given that DG1 is barely out, and
ADL is not out yet. How about:
"Disabling GuC on untested platforms"?
Just because something is not in the shops yet does not mean it is new.
Technology is always obsolete by the time it goes on sale.
That is a very good reason to not use terminology like "new", "old",
"current", "modern" etc. at all.
End users like me definitely do not share your interpretation of "old".
Yep, old and new is relative. In the end, what matters is the validation
effort, which is why I was proposing "untested platforms".
Also, remember that you are not writing these messages for Intel
engineers, but instead are writing for Linux *users*.
It's drm_dbg. Users don't read this stuff, at least not users with no
clue what the driver does and stuff like that.
If I had a problem, I would read it, and I have no clue what anything
of that is.
Exactly.
This level of defense for what is clearly a bad *debug* message (at the
very least, the grammar) makes no sense at all!
I don't want to hear arguments like "Not my patch" from a developer
literally sending the patch to the ML and who added his SoB to the
patch, playing with words, or minimizing the problem of having such a
message.
All of the above are just clear signals for the community to get off
your playground, which is frankly unacceptable. Your email address does
not matter.
In the spirit of collaboration, your response should have been "Good
catch, how about or ?". This would not have wasted everyone's
time in an attempt to just have it your way.
My level of confidence in this GuC transition was already low, but you
guys are working hard to shoot yourself in the foot. Trust should be earned!
Martin
Thanks,
pq
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+
On 01/07/2021 21:24, Martin Peres wrote: [...] + i915->params.enable_guc = ENABLE_GUC_LOAD_HUC; + return; + } + + /* Default: enable HuC authentication and GuC submission */ + i915->params.enable_guc = ENABLE_GUC_LOAD_HUC | ENABLE_GUC_SUBMISSION; This seems to be in contradiction with the GuC submission plan which states: "Not enabled by default on any current platforms but can be enabled via modparam enable_guc". I don't believe any current platform gets this point where GuC submission would be enabled by default. The first would be ADL-P which isn't out yet. Isn't that exactly what the line above does? In case you missed this crucial part of the review. Please answer the above question. Cheers, Martin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 44/53] drm/i915/dg2: Add vswing programming for SNPS phys
On Thu, 01 Jul 2021, Matt Roper wrote:
> Vswing programming for SNPS PHYs is just a single step -- look up the
> value that corresponds to the voltage level from a table and program it
> into the SNPS_PHY_TX_EQ register.
I've got some patches to turn this to the same ddi buf trans mechanism
that everything else uses. Seems like this patch tries to bypass it
because it's simple, but then we end up using encoder->get_buf_trans()
anyway, for example in intel_ddi_dp_voltage_max(), and it returns some
tgl buf trans tables... I guess it works by coincidence. :|
Anyway, as I said, I've got the patches, and I can fix this up
afterwards.
BR,
Jani.
>
> Bspec: 53920
> Cc: Matt Atwood
> Signed-off-by: Matt Roper
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 23 ++--
> drivers/gpu/drm/i915/display/intel_snps_phy.c | 54 +++
> drivers/gpu/drm/i915/display/intel_snps_phy.h | 4 ++
> drivers/gpu/drm/i915/i915_reg.h | 5 ++
> 4 files changed, 83 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 929a95ddb316..ade03cf41caa 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -1496,6 +1496,16 @@ static int intel_ddi_dp_level(struct intel_dp
> *intel_dp)
> return translate_signal_level(intel_dp, signal_levels);
> }
>
> +static void
> +dg2_set_signal_levels(struct intel_dp *intel_dp,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct intel_encoder *encoder = &dp_to_dig_port(intel_dp)->base;
> + int level = intel_ddi_dp_level(intel_dp);
> +
> + intel_snps_phy_ddi_vswing_sequence(encoder, level);
> +}
> +
> static void
> tgl_set_signal_levels(struct intel_dp *intel_dp,
> const struct intel_crtc_state *crtc_state)
> @@ -2563,7 +2573,10 @@ static void tgl_ddi_pre_enable_dp(struct
> intel_atomic_state *state,
>*/
>
> /* 7.e Configure voltage swing and related IO settings */
> - tgl_ddi_vswing_sequence(encoder, crtc_state, level);
> + if (IS_DG2(dev_priv))
> + intel_snps_phy_ddi_vswing_sequence(encoder, level);
> + else
> + tgl_ddi_vswing_sequence(encoder, crtc_state, level);
>
> /*
>* 7.f Combo PHY: Configure PORT_CL_DW10 Static Power Down to power up
> @@ -3102,7 +3115,9 @@ static void intel_enable_ddi_hdmi(struct
> intel_atomic_state *state,
> "[CONNECTOR:%d:%s] Failed to configure sink
> scrambling/TMDS bit clock ratio\n",
> connector->base.id, connector->name);
>
> - if (DISPLAY_VER(dev_priv) >= 12)
> + if (IS_DG2(dev_priv))
> + intel_snps_phy_ddi_vswing_sequence(encoder, U32_MAX);
> + else if (DISPLAY_VER(dev_priv) >= 12)
> tgl_ddi_vswing_sequence(encoder, crtc_state, level);
> else if (DISPLAY_VER(dev_priv) == 11)
> icl_ddi_vswing_sequence(encoder, crtc_state, level);
> @@ -4075,7 +4090,9 @@ intel_ddi_init_dp_connector(struct intel_digital_port
> *dig_port)
> dig_port->dp.set_link_train = intel_ddi_set_link_train;
> dig_port->dp.set_idle_link_train = intel_ddi_set_idle_link_train;
>
> - if (DISPLAY_VER(dev_priv) >= 12)
> + if (IS_DG2(dev_priv))
> + dig_port->dp.set_signal_levels = dg2_set_signal_levels;
> + else if (DISPLAY_VER(dev_priv) >= 12)
> dig_port->dp.set_signal_levels = tgl_set_signal_levels;
> else if (DISPLAY_VER(dev_priv) >= 11)
> dig_port->dp.set_signal_levels = icl_set_signal_levels;
> diff --git a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> index 1317b4e94b50..77759bda98a4 100644
> --- a/drivers/gpu/drm/i915/display/intel_snps_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_snps_phy.c
> @@ -21,6 +21,60 @@
> * since it is not handled by the shared DPLL framework as on other
> platforms.
> */
>
> +static const u32 dg2_ddi_translations[] = {
> + /* VS 0, pre-emph 0 */
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_MAIN, 26),
> +
> + /* VS 0, pre-emph 1 */
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_MAIN, 33) |
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_POST, 6),
> +
> + /* VS 0, pre-emph 2 */
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_MAIN, 38) |
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_POST, 12),
> +
> + /* VS 0, pre-emph 3 */
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_MAIN, 43) |
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_POST, 19),
> +
> + /* VS 1, pre-emph 0 */
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_MAIN, 39),
> +
> + /* VS 1, pre-emph 1 */
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_MAIN, 44) |
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_POST, 8),
> +
> + /* VS 1, pre-emph 2 */
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_MAIN, 47) |
> + REG_FIELD_PREP(SNPS_PHY_TX_EQ_POST, 15),
> +
Re: [Intel-gfx] [PATCH 45/53] drm/i915/dg2: Update modeset sequences
On Thu, 01 Jul 2021, Matt Roper wrote:
> DG2 has some changes to the expected modesetting sequences when compared
> to gen12. Adjust our driver logic accordingly. Although the DP
> sequence is pretty similar to TGL's, there are some steps that change,
> so let's split the handling for that out into a separate function.
>
> Bspec: 54128
> Cc: Lucas De Marchi
> Cc: Anusha Srivatsa
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 135 +--
> 1 file changed, 127 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index ade03cf41caa..5499a2975a0e 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -172,14 +172,22 @@ void intel_wait_ddi_buf_idle(struct drm_i915_private
> *dev_priv,
> static void intel_wait_ddi_buf_active(struct drm_i915_private *dev_priv,
> enum port port)
> {
> + int ret;
> +
> /* Wait > 518 usecs for DDI_BUF_CTL to be non idle */
> if (DISPLAY_VER(dev_priv) < 10) {
> usleep_range(518, 1000);
> return;
> }
>
> - if (wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
> - DDI_BUF_IS_IDLE), 500))
> + if (IS_DG2(dev_priv))
> + ret = wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
> + DDI_BUF_IS_IDLE), 1200);
> + else
> + ret = wait_for_us(!(intel_de_read(dev_priv, DDI_BUF_CTL(port)) &
> + DDI_BUF_IS_IDLE), 500);
Nitpick, this should really parametetrized the delay, 500 vs. 1200, not
add duplicate the code.
BR,
Jani.
> +
> + if (ret)
> drm_err(&dev_priv->drm, "Timeout waiting for DDI BUF %c to get
> active\n",
> port_name(port));
> }
> @@ -2207,7 +2215,7 @@ void intel_ddi_sanitize_encoder_pll_mapping(struct
> intel_encoder *encoder)
> ddi_clk_needed = false;
> }
>
> - if (ddi_clk_needed || !encoder->disable_clock ||
> + if (ddi_clk_needed || !encoder->is_clock_enabled ||
> !encoder->is_clock_enabled(encoder))
> return;
>
> @@ -2488,6 +2496,116 @@ static void intel_ddi_mso_configure(const struct
> intel_crtc_state *crtc_state)
>OVERLAP_PIXELS_MASK, dss1);
> }
>
> +static void dg2_ddi_pre_enable_dp(struct intel_atomic_state *state,
> + struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + const struct drm_connector_state *conn_state)
> +{
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> + bool is_mst = intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST);
> + int level = intel_ddi_dp_level(intel_dp);
> +
> + intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
> + crtc_state->lane_count);
> +
> + /*
> + * 1. Enable Power Wells
> + *
> + * This was handled at the beginning of intel_atomic_commit_tail(),
> + * before we called down into this function.
> + */
> +
> + /* 2. Enable Panel Power if PPS is required */
> + intel_pps_on(intel_dp);
> +
> + /*
> + * 3. Enable the port PLL.
> + */
> + intel_ddi_enable_clock(encoder, crtc_state);
> +
> + /* 4. Enable IO power */
> + if (!intel_phy_is_tc(dev_priv, phy) ||
> + dig_port->tc_mode != TC_PORT_TBT_ALT)
> + dig_port->ddi_io_wakeref = intel_display_power_get(dev_priv,
> +
> dig_port->ddi_io_power_domain);
> +
> + /*
> + * 5. The rest of the below are substeps under the bspec's "Enable and
> + * Train Display Port" step. Note that steps that are specific to
> + * MST will be handled by intel_mst_pre_enable_dp() before/after it
> + * calls into this function. Also intel_mst_pre_enable_dp() only calls
> + * us when active_mst_links==0, so any steps designated for "single
> + * stream or multi-stream master transcoder" can just be performed
> + * unconditionally here.
> + */
> +
> + /*
> + * 5.a Configure Transcoder Clock Select to direct the Port clock to the
> + * Transcoder.
> + */
> + intel_ddi_enable_pipe_clock(encoder, crtc_state);
> +
> + /* 5.b Not relevant to i915 for now */
> +
> + /*
> + * 5.c Configure TRANS_DDI_FUNC_CTL DDI Select, DDI Mode Select & MST
> + * Transport Select
> + */
> + intel_ddi_config_transcoder_func(encoder, crtc_state);
> +
> + /*
> + * 5.d Configure &
Re: [Intel-gfx] [PATCH 50/53] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable
On Thu, 01 Jul 2021, Matt Roper wrote:
> From: Anusha Srivatsa
>
> DSC can be supported per DP connector. This patch creates
> a per connector debugfs node to expose the Input and
> Compressed BPP.
>
> The same node can be used from userspace to force
> DSC to a certain BPP.
>
> force_dsc_bpp is written through this debugfs
> node to force DSC BPP to all accepted values
I think this patch needs rework, and it's independent of the rest of the
series. Please just drop this one and the next.
BR,
Jani.
>
> Cc: Vandita Kulkarni
> Cc: Manasi Navare
> Signed-off-by: Anusha Srivatsa
> Signed-off-by: Patnana Venkata Sai
> Signed-off-by: Matt Roper
> ---
> .../drm/i915/display/intel_display_debugfs.c | 103 +-
> .../drm/i915/display/intel_display_types.h| 1 +
> 2 files changed, 103 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index af9e58619667..1805d70ea817 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2389,6 +2389,100 @@ static const struct file_operations
> i915_dsc_fec_support_fops = {
> .write = i915_dsc_fec_support_write
> };
>
> +static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
> +{
> + struct drm_connector *connector = m->private;
> + struct drm_device *dev = connector->dev;
> + struct drm_crtc *crtc;
> + struct intel_dp *intel_dp;
> + struct drm_modeset_acquire_ctx ctx;
> + struct intel_crtc_state *crtc_state = NULL;
> + int ret = 0;
> + bool try_again = false;
> +
> + drm_modeset_acquire_init(&ctx, DRM_MODESET_ACQUIRE_INTERRUPTIBLE);
> +
> + do {
> + try_again = false;
> + ret = drm_modeset_lock(&dev->mode_config.connection_mutex,
> +&ctx);
> + if (ret) {
> + ret = -EINTR;
> + break;
> + }
> + crtc = connector->state->crtc;
> + if (connector->status != connector_status_connected || !crtc) {
> + ret = -ENODEV;
> + break;
> + }
> + ret = drm_modeset_lock(&crtc->mutex, &ctx);
> + if (ret == -EDEADLK) {
> + ret = drm_modeset_backoff(&ctx);
> + if (!ret) {
> + try_again = true;
> + continue;
> + }
> + break;
> + } else if (ret) {
> + break;
> + }
> + intel_dp = intel_attached_dp(to_intel_connector(connector));
> + crtc_state = to_intel_crtc_state(crtc->state);
> + seq_printf(m, "Input_BPP: %d\n", crtc_state->pipe_bpp);
> + seq_printf(m, "Compressed_BPP: %d\n",
> + crtc_state->dsc.compressed_bpp);
> + } while (try_again);
> +
> + drm_modeset_drop_locks(&ctx);
> + drm_modeset_acquire_fini(&ctx);
> +
> + return ret;
> +}
> +
> +static ssize_t i915_dsc_bpp_support_write(struct file *file,
> + const char __user *ubuf,
> + size_t len, loff_t *offp)
> +{
> + int dsc_bpp = 0;
> + int ret;
> + struct drm_connector *connector =
> + ((struct seq_file *)file->private_data)->private;
> + struct intel_encoder *encoder =
> intel_attached_encoder(to_intel_connector(connector));
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + if (len == 0)
> + return 0;
> +
> + drm_dbg(&i915->drm,
> + "Copied %zu bytes from user to force BPP\n", len);
> +
> + ret = kstrtoint_from_user(ubuf, len, 0, &dsc_bpp);
> +
> + intel_dp->force_dsc_bpp = dsc_bpp;
> + if (ret < 0)
> + return ret;
> +
> + *offp += len;
> + return len;
> +}
> +
> +static int i915_dsc_bpp_support_open(struct inode *inode,
> +struct file *file)
> +{
> + return single_open(file, i915_dsc_bpp_support_show,
> +inode->i_private);
> +}
> +
> +static const struct file_operations i915_dsc_bpp_support_fops = {
> + .owner = THIS_MODULE,
> + .open = i915_dsc_bpp_support_open,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = single_release,
> + .write = i915_dsc_bpp_support_write
> +};
> +
> /**
> * intel_connector_debugfs_add - add i915 specific connector debugfs files
> * @connector: pointer to a registered drm_connector
> @@ -2427,9 +2521,16 @@ int intel_connector_debugfs_add(struct drm_connector
> *connector)
> connector, &i915_hdcp_sink_capability_fops);
> }
>
> - if ((DISPLA
[Intel-gfx] [drm-intel:drm-intel-gt-next 8/14] drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized symbol 'rq'.
tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
head: 5cd57f676bb946a00275408f0dd0d75dbc466d25
commit: cf586021642d8017cde111b7dd1ba86224e9da51 [8/14] drm/i915/gt: Pipelined
page migration
config: x86_64-randconfig-m001-20210630 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized
symbol 'rq'.
drivers/gpu/drm/i915/gt/selftest_migrate.c:113 copy() error: uninitialized
symbol 'vaddr'.
Old smatch warnings:
drivers/gpu/drm/i915/gem/i915_gem_object.h:182 __i915_gem_object_lock() error:
we previously assumed 'ww' could be null (see line 171)
vim +/rq +102 drivers/gpu/drm/i915/gt/selftest_migrate.c
cf586021642d80 Chris Wilson 2021-06-17 32 static int copy(struct
intel_migrate *migrate,
cf586021642d80 Chris Wilson 2021-06-17 33 int (*fn)(struct
intel_migrate *migrate,
cf586021642d80 Chris Wilson 2021-06-17 34 struct
i915_gem_ww_ctx *ww,
cf586021642d80 Chris Wilson 2021-06-17 35 struct
drm_i915_gem_object *src,
cf586021642d80 Chris Wilson 2021-06-17 36 struct
drm_i915_gem_object *dst,
cf586021642d80 Chris Wilson 2021-06-17 37 struct
i915_request **out),
cf586021642d80 Chris Wilson 2021-06-17 38 u32 sz, struct
rnd_state *prng)
cf586021642d80 Chris Wilson 2021-06-17 39 {
cf586021642d80 Chris Wilson 2021-06-17 40 struct drm_i915_private *i915 =
migrate->context->engine->i915;
cf586021642d80 Chris Wilson 2021-06-17 41 struct drm_i915_gem_object
*src, *dst;
cf586021642d80 Chris Wilson 2021-06-17 42 struct i915_request *rq;
cf586021642d80 Chris Wilson 2021-06-17 43 struct i915_gem_ww_ctx ww;
cf586021642d80 Chris Wilson 2021-06-17 44 u32 *vaddr;
cf586021642d80 Chris Wilson 2021-06-17 45 int err = 0;
One way to silence these warnings would be to initialize err = -EINVAL.
Then Smatch would know that we goto err_out for an empty list.
cf586021642d80 Chris Wilson 2021-06-17 46 int i;
cf586021642d80 Chris Wilson 2021-06-17 47
cf586021642d80 Chris Wilson 2021-06-17 48 src =
create_lmem_or_internal(i915, sz);
cf586021642d80 Chris Wilson 2021-06-17 49 if (IS_ERR(src))
cf586021642d80 Chris Wilson 2021-06-17 50 return 0;
cf586021642d80 Chris Wilson 2021-06-17 51
cf586021642d80 Chris Wilson 2021-06-17 52 dst =
i915_gem_object_create_internal(i915, sz);
cf586021642d80 Chris Wilson 2021-06-17 53 if (IS_ERR(dst))
cf586021642d80 Chris Wilson 2021-06-17 54 goto err_free_src;
cf586021642d80 Chris Wilson 2021-06-17 55
cf586021642d80 Chris Wilson 2021-06-17 56 for_i915_gem_ww(&ww, err, true)
{
cf586021642d80 Chris Wilson 2021-06-17 57 err =
i915_gem_object_lock(src, &ww);
cf586021642d80 Chris Wilson 2021-06-17 58 if (err)
cf586021642d80 Chris Wilson 2021-06-17 59 continue;
cf586021642d80 Chris Wilson 2021-06-17 60
cf586021642d80 Chris Wilson 2021-06-17 61 err =
i915_gem_object_lock(dst, &ww);
cf586021642d80 Chris Wilson 2021-06-17 62 if (err)
cf586021642d80 Chris Wilson 2021-06-17 63 continue;
cf586021642d80 Chris Wilson 2021-06-17 64
cf586021642d80 Chris Wilson 2021-06-17 65 vaddr =
i915_gem_object_pin_map(src, I915_MAP_WC);
cf586021642d80 Chris Wilson 2021-06-17 66 if (IS_ERR(vaddr)) {
cf586021642d80 Chris Wilson 2021-06-17 67 err =
PTR_ERR(vaddr);
cf586021642d80 Chris Wilson 2021-06-17 68 continue;
cf586021642d80 Chris Wilson 2021-06-17 69 }
cf586021642d80 Chris Wilson 2021-06-17 70
cf586021642d80 Chris Wilson 2021-06-17 71 for (i = 0; i < sz /
sizeof(u32); i++)
cf586021642d80 Chris Wilson 2021-06-17 72 vaddr[i] = i;
cf586021642d80 Chris Wilson 2021-06-17 73
i915_gem_object_flush_map(src);
cf586021642d80 Chris Wilson 2021-06-17 74
cf586021642d80 Chris Wilson 2021-06-17 75 vaddr =
i915_gem_object_pin_map(dst, I915_MAP_WC);
cf586021642d80 Chris Wilson 2021-06-17 76 if (IS_ERR(vaddr)) {
cf586021642d80 Chris Wilson 2021-06-17 77 err =
PTR_ERR(vaddr);
cf586021642d80 Chris Wilson 2021-06-17 78 goto unpin_src;
cf586021642d80 Chris Wilson 2021-06-17 79 }
cf586021642d80 Chris Wilson 2021-06-17 80
cf586021642d80 Chris Wilson 2021-06-17 81 for (i = 0; i < sz /
sizeof(u32); i++)
cf586021642d80 Chris Wilson 2021-06-17 82 vaddr[i] = ~i;
cf586021642d80 Chris Wilson 2021-06-17 83
i915_gem_object_flush_map(dst);
cf586021642d80 Chris Wilson 2021-06-17 84
[Intel-gfx] ✓ Fi.CI.IGT: success for Begin enabling Xe_HP SDV and DG2 platforms
== Series Details == Series: Begin enabling Xe_HP SDV and DG2 platforms URL : https://patchwork.freedesktop.org/series/92135/ State : success == Summary == CI Bug Log - changes from CI_DRM_10301_full -> Patchwork_20518_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20518_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@preservation-s3@rcs0: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#180]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-apl8/igt@gem_ctx_isolation@preservation...@rcs0.html * igt@gem_ctx_persistence@legacy-engines-hostile@bsd: - shard-apl: [PASS][2] -> [FAIL][3] ([i915#2410]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-apl3/igt@gem_ctx_persistence@legacy-engines-host...@bsd.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-apl2/igt@gem_ctx_persistence@legacy-engines-host...@bsd.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][4] -> [FAIL][5] ([i915#2410]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-tglb5/igt@gem_ctx_persiste...@many-contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-tglb2/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-apl: [PASS][6] -> [SKIP][7] ([fdo#109271]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-apl3/igt@gem_exec_fair@basic-none-sh...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-apl2/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-iclb: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-iclb4/igt@gem_exec_fair@basic-pace-s...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-iclb2/igt@gem_exec_fair@basic-pace-s...@rcs0.html - shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-glk7/igt@gem_exec_fair@basic-pace-s...@rcs0.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][12] -> [FAIL][13] ([i915#2842]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-kbl7/igt@gem_exec_fair@basic-p...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-kbl3/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][14] ([i915#2658]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-apl6/igt@gem_pr...@exhaustion.html * igt@gen9_exec_parse@bb-large: - shard-apl: NOTRUN -> [FAIL][15] ([i915#3296]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-apl7/igt@gen9_exec_pa...@bb-large.html * igt@i915_selftest@mock@requests: - shard-skl: [PASS][16] -> [INCOMPLETE][17] ([i915#198]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-skl7/igt@i915_selftest@m...@requests.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-skl8/igt@i915_selftest@m...@requests.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][18] ([fdo#110725] / [fdo#111614]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-iclb4/igt@kms_big...@x-tiled-16bpp-rotate-270.html * igt@kms_color@pipe-c-ctm-0-25: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10301/shard-skl7/igt@kms_co...@pipe-c-ctm-0-25.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-skl9/igt@kms_co...@pipe-c-ctm-0-25.html * igt@kms_color_chamelium@pipe-a-ctm-limited-range: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +18 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-apl6/igt@kms_color_chamel...@pipe-a-ctm-limited-range.html * igt@kms_color_chamelium@pipe-c-gamma: - shard-glk: NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111827]) +2 similar issues [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-glk3/igt@kms_color_chamel...@pipe-c-gamma.html * igt@kms_content_protection@atomic-dpms: - shard-apl: NOTRUN -> [TIMEOUT][23] ([i915#1319]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20518/shard-apl8/igt@kms_content_protect...@atomic-dpms.html * igt@kms_cursor_crc@p
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dmc: Use RUNTIME_INFO->step for DMC
Hi Anusha,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on next-20210701]
[cannot apply to drm-intel/for-linux-next v5.13]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Anusha-Srivatsa/Stepping-substepping-reorg-for-DMC/20210702-033236
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: x86_64-randconfig-a015-20210630 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
9eb613b2de3163686b1a4bd1160f15ac56a4b083)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
#
https://github.com/0day-ci/linux/commit/5d13218aefcba8e3bc4c4d4371988e08e0cf8bd3
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review
Anusha-Srivatsa/Stepping-substepping-reorg-for-DMC/20210702-033236
git checkout 5d13218aefcba8e3bc4c4d4371988e08e0cf8bd3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All warnings (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_dmc.c:250:35: warning: unused variable
>> 'no_stepping_info' [-Wunused-const-variable]
static const struct stepping_info no_stepping_info = { '*', '*' };
^
1 warning generated.
vim +/no_stepping_info +250 drivers/gpu/drm/i915/display/intel_dmc.c
03256487fee340 drivers/gpu/drm/i915/display/intel_dmc.c Anusha Srivatsa
2021-05-26 249
1bb4308e713042 drivers/gpu/drm/i915/intel_csr.c Chris Wilson
2016-03-07 @250 static const struct stepping_info no_stepping_info = { '*',
'*' };
5d13218aefcba8 drivers/gpu/drm/i915/display/intel_dmc.c Anusha Srivatsa
2021-07-01 251 struct stepping_info *display_step;
1bb4308e713042 drivers/gpu/drm/i915/intel_csr.c Chris Wilson
2016-03-07 252
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 31/53] drm/i915/dg2: Report INSTDONE_GEOM values in error state
On 01/07/2021 23:24, Matt Roper wrote:
Xe_HPG adds some additional INSTDONE_GEOM debug registers; the Mesa team
has indicated that having these reported in the error state would be
useful for debugging GPU hangs. These registers are replicated per-DSS
with gslice steering.
Cc: Lionel Landwerlin
Signed-off-by: Matt Roper
Thanks,
Acked-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 7 +++
drivers/gpu/drm/i915/gt/intel_engine_types.h | 3 +++
drivers/gpu/drm/i915/i915_gpu_error.c| 10 --
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index e1302e9c168b..b3c002e4ae9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1220,6 +1220,13 @@ void intel_engine_get_instdone(const struct
intel_engine_cs *engine,
GEN7_ROW_INSTDONE);
}
}
+
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 55)) {
+ for_each_instdone_gslice_dss_xehp(i915, sseu, iter,
slice, subslice)
+ instdone->geom_svg[slice][subslice] =
+ read_subslice_reg(engine, slice,
subslice,
+
XEHPG_INSTDONE_GEOM_SVG);
+ }
} else if (GRAPHICS_VER(i915) >= 7) {
instdone->instdone =
intel_uncore_read(uncore, RING_INSTDONE(mmio_base));
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index e917b7519f2b..93609d797ac2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -80,6 +80,9 @@ struct intel_instdone {
u32 slice_common_extra[2];
u32 sampler[GEN_MAX_GSLICES][I915_MAX_SUBSLICES];
u32 row[GEN_MAX_GSLICES][I915_MAX_SUBSLICES];
+
+ /* Added in XeHPG */
+ u32 geom_svg[GEN_MAX_GSLICES][I915_MAX_SUBSLICES];
};
/*
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c
b/drivers/gpu/drm/i915/i915_gpu_error.c
index c1e744b5ab47..4de7edc451ef 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -431,6 +431,7 @@ static void error_print_instdone(struct
drm_i915_error_state_buf *m,
const struct sseu_dev_info *sseu = &ee->engine->gt->info.sseu;
int slice;
int subslice;
+ int iter;
err_printf(m, " INSTDONE: 0x%08x\n",
ee->instdone.instdone);
@@ -445,8 +446,6 @@ static void error_print_instdone(struct
drm_i915_error_state_buf *m,
return;
if (GRAPHICS_VER_FULL(m->i915) >= IP_VER(12, 50)) {
- int iter;
-
for_each_instdone_gslice_dss_xehp(m->i915, sseu, iter, slice,
subslice)
err_printf(m, " SAMPLER_INSTDONE[%d][%d]: 0x%08x\n",
slice, subslice,
@@ -471,6 +470,13 @@ static void error_print_instdone(struct
drm_i915_error_state_buf *m,
if (GRAPHICS_VER(m->i915) < 12)
return;
+ if (GRAPHICS_VER_FULL(m->i915) >= IP_VER(12, 55)) {
+ for_each_instdone_gslice_dss_xehp(m->i915, sseu, iter, slice,
subslice)
+ err_printf(m, " GEOM_SVGUNIT_INSTDONE[%d][%d]:
0x%08x\n",
+ slice, subslice,
+ ee->instdone.geom_svg[slice][subslice]);
+ }
+
err_printf(m, " SC_INSTDONE_EXTRA: 0x%08x\n",
ee->instdone.slice_common_extra[0]);
err_printf(m, " SC_INSTDONE_EXTRA2: 0x%08x\n",
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 35a42df1f2aa..d58864c7adc6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2686,6 +2686,7 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define GEN12_SC_INSTDONE_EXTRA2 _MMIO(0x7108)
#define GEN7_SAMPLER_INSTDONE _MMIO(0xe160)
#define GEN7_ROW_INSTDONE _MMIO(0xe164)
+#define XEHPG_INSTDONE_GEOM_SVG_MMIO(0x666c)
#define MCFG_MCR_SELECTOR _MMIO(0xfd0)
#define SF_MCR_SELECTOR _MMIO(0xfd8)
#define GEN8_MCR_SELECTOR _MMIO(0xfdc)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/53] drm/i915: Fork DG1 interrupt handler
On Thu, Jul 1, 2021 at 10:26 PM Matt Roper wrote:
>
> From: Paulo Zanoni
>
> The current interrupt handler is getting increasingly complicated and
> Xe_HP changes will bring even more complexity. Let's split off a new
> interrupt handler starting with DG1 (i.e., when the master tile
> interrupt register was added to the design) and use that as the basis
> for the new Xe_HP changes.
>
> Now that we track the hardware IP's release number as well as the
> version number, we can also properly define DG1 has version "12.10" and
> replace the has_master_unit_irq feature flag with an IP version test.
>
> Bspec: 50875
> Cc: Daniele Spurio Ceraolo
> Cc: Stuart Summers
> Signed-off-by: Paulo Zanoni
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Tomasz Lis
> Signed-off-by: Matt Roper
So I know DG1 upstream is decidedly non-smooth, but basic
infrastructure we've had since forever ...
Why was this prep work not upstreamed earlier with some benign commit
message that doesn't mention DG2? There's zero DG2 stuff in here, this
could have landed months/years ago even. Bringing this up since right
this moment we have an internal chat about trees diverging a bit much.
-Daniel
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 -
> drivers/gpu/drm/i915/i915_irq.c | 139 +++
> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> drivers/gpu/drm/i915/i915_reg.h | 4 +-
> drivers/gpu/drm/i915/intel_device_info.h | 1 -
> 5 files changed, 95 insertions(+), 53 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 9639800485b9..519cce702f4b 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1601,8 +1601,6 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
> #define HAS_LOGICAL_RING_ELSQ(dev_priv) \
> (INTEL_INFO(dev_priv)->has_logical_ring_elsq)
>
> -#define HAS_MASTER_UNIT_IRQ(dev_priv)
> (INTEL_INFO(dev_priv)->has_master_unit_irq)
> -
> #define HAS_EXECLISTS(dev_priv) HAS_LOGICAL_RING_CONTEXTS(dev_priv)
>
> #define INTEL_PPGTT(dev_priv) (INTEL_INFO(dev_priv)->ppgtt_type)
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 7d0ce8b9f8ed..9d47ffa39093 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2699,11 +2699,9 @@ gen11_display_irq_handler(struct drm_i915_private
> *i915)
> enable_rpm_wakeref_asserts(&i915->runtime_pm);
> }
>
> -static __always_inline irqreturn_t
> -__gen11_irq_handler(struct drm_i915_private * const i915,
> - u32 (*intr_disable)(void __iomem * const regs),
> - void (*intr_enable)(void __iomem * const regs))
> +static irqreturn_t gen11_irq_handler(int irq, void *arg)
> {
> + struct drm_i915_private *i915 = arg;
> void __iomem * const regs = i915->uncore.regs;
> struct intel_gt *gt = &i915->gt;
> u32 master_ctl;
> @@ -2712,9 +2710,9 @@ __gen11_irq_handler(struct drm_i915_private * const
> i915,
> if (!intel_irqs_enabled(i915))
> return IRQ_NONE;
>
> - master_ctl = intr_disable(regs);
> + master_ctl = gen11_master_intr_disable(regs);
> if (!master_ctl) {
> - intr_enable(regs);
> + gen11_master_intr_enable(regs);
> return IRQ_NONE;
> }
>
> @@ -2727,7 +2725,7 @@ __gen11_irq_handler(struct drm_i915_private * const
> i915,
>
> gu_misc_iir = gen11_gu_misc_irq_ack(gt, master_ctl);
>
> - intr_enable(regs);
> + gen11_master_intr_enable(regs);
>
> gen11_gu_misc_irq_handler(gt, gu_misc_iir);
>
> @@ -2736,51 +2734,69 @@ __gen11_irq_handler(struct drm_i915_private * const
> i915,
> return IRQ_HANDLED;
> }
>
> -static irqreturn_t gen11_irq_handler(int irq, void *arg)
> -{
> - return __gen11_irq_handler(arg,
> - gen11_master_intr_disable,
> - gen11_master_intr_enable);
> -}
> -
> -static u32 dg1_master_intr_disable_and_ack(void __iomem * const regs)
> +static inline u32 dg1_master_intr_disable(void __iomem * const regs)
> {
> u32 val;
>
> /* First disable interrupts */
> - raw_reg_write(regs, DG1_MSTR_UNIT_INTR, 0);
> + raw_reg_write(regs, DG1_MSTR_TILE_INTR, 0);
>
> /* Get the indication levels and ack the master unit */
> - val = raw_reg_read(regs, DG1_MSTR_UNIT_INTR);
> + val = raw_reg_read(regs, DG1_MSTR_TILE_INTR);
> if (unlikely(!val))
> return 0;
>
> - raw_reg_write(regs, DG1_MSTR_UNIT_INTR, val);
> -
> - /*
> -* Now with master disabled, get a sample of level indications
> -* for this interrupt and ack them right away - we keep
> GEN11_MASTER_IRQ
> -* out as this bit doesn't exist anymore for DG1
> -*/
> - val = raw_reg_read(regs, GEN11_GFX_MSTR_IRQ) & ~GEN11_MASTER
[Intel-gfx] [PATCH v5 0/2] drm/i915/display/dsc: Set BPP in the kernel
From: Patnana Venkata Sai DSC can be supported per DP connector. This patch creates a per connector debugfs node to expose the Input and Compressed BPP. The same node can be used from userspace to force DSC to a certain BPP. force_dsc_bpp is written through this debugfs node to force DSC BPP to all accepted values Test-with: <20210622102454.8922-1-venkata.sai.patn...@intel.com> Anusha Srivatsa (1): drm/i915/display/dsc: Set BPP in the kernel Patnana Venkata Sai (1): drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable .../drm/i915/display/intel_display_debugfs.c | 99 ++- .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 23 - 3 files changed, 117 insertions(+), 6 deletions(-) -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v5 1/2] drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable
From: Patnana Venkata Sai
[What]:
This patch creates a per connector debugfs node to expose
the Input and Compressed BPP.
The same node can be used from userspace to force
DSC to a certain BPP(all accepted values).
[Why]:
Useful to verify all supported/requested compression bpp's
through IGT
v2: Remove unnecessary logic (Jani)
v3: Drop pipe bpp in debugfs node (Vandita)
v4: Minor cleanups (Vandita)
Cc: Vandita Kulkarni
Cc: Navare Manasi D
Signed-off-by: Anusha Srivatsa
Signed-off-by: Patnana Venkata Sai
---
.../drm/i915/display/intel_display_debugfs.c | 99 ++-
.../drm/i915/display/intel_display_types.h| 1 +
2 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index af9e58619667d..6329907f440b9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -2389,6 +2389,96 @@ static const struct file_operations
i915_dsc_fec_support_fops = {
.write = i915_dsc_fec_support_write
};
+static int i915_dsc_bpp_support_show(struct seq_file *m, void *data)
+{
+ struct drm_connector *connector = m->private;
+ struct drm_device *dev = connector->dev;
+ struct drm_crtc *crtc;
+ struct intel_crtc_state *crtc_state = NULL;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ int ret = 0;
+
+ if (!encoder)
+ return -ENODEV;
+
+ if (connector->status != connector_status_connected)
+ return -ENODEV;
+
+ ret =
drm_modeset_lock_single_interruptible(&dev->mode_config.connection_mutex);
+ if (ret)
+ return ret;
+
+ crtc = connector->state->crtc;
+ crtc_state = to_intel_crtc_state(crtc->state);
+ seq_printf(m, "Compressed_BPP: %d\n", crtc_state->dsc.compressed_bpp);
+
+ drm_modeset_unlock(&dev->mode_config.connection_mutex);
+
+ return ret;
+}
+
+static ssize_t i915_dsc_bpp_support_write(struct file *file,
+ const char __user *ubuf,
+ size_t len, loff_t *offp)
+{
+ int dsc_bpp = 0;
+ int ret;
+ struct drm_connector *connector =
+ ((struct seq_file *)file->private_data)->private;
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+ struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
+ struct drm_crtc *crtc;
+ struct intel_crtc_state *crtc_state = NULL;
+
+ if (len == 0)
+ return 0;
+
+ ret = kstrtoint_from_user(ubuf, len, 0, &dsc_bpp);
+ if (ret < 0)
+ return ret;
+
+ ret =
drm_modeset_lock_single_interruptible(&i915->drm.mode_config.connection_mutex);
+ if (ret)
+ return ret;
+
+ crtc = connector->state->crtc;
+ crtc_state = to_intel_crtc_state(crtc->state);
+
+ if (dsc_bpp <= 8 || dsc_bpp >= crtc_state->pipe_bpp) {
+ drm_modeset_unlock(&i915->drm.mode_config.connection_mutex);
+ drm_dbg(&i915->drm, "Compressed_BPP should be with in the
limits\n");
+
+ return -EINVAL;
+ }
+
+ drm_modeset_unlock(&i915->drm.mode_config.connection_mutex);
+
+ drm_dbg(&i915->drm,
+ "Copied %zu bytes from user to force BPP\n", len);
+
+ intel_dp->force_dsc_bpp = dsc_bpp;
+ *offp += len;
+
+ return len;
+}
+
+static int i915_dsc_bpp_support_open(struct inode *inode,
+ struct file *file)
+{
+ return single_open(file, i915_dsc_bpp_support_show,
+ inode->i_private);
+}
+
+static const struct file_operations i915_dsc_bpp_support_fops = {
+ .owner = THIS_MODULE,
+ .open = i915_dsc_bpp_support_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+ .write = i915_dsc_bpp_support_write
+};
+
/**
* intel_connector_debugfs_add - add i915 specific connector debugfs files
* @connector: pointer to a registered drm_connector
@@ -2427,9 +2517,16 @@ int intel_connector_debugfs_add(struct drm_connector
*connector)
connector, &i915_hdcp_sink_capability_fops);
}
- if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
!to_intel_connector(connector)->mst_port) || connector->connector_type ==
DRM_MODE_CONNECTOR_eDP))
+ if ((DISPLAY_VER(dev_priv) >= 11 || IS_CANNONLAKE(dev_priv)) &&
+ ((connector->connector_type == DRM_MODE_CONNECTOR_DisplayPort &&
+ !to_intel_connector(connector)->mst_port) ||
+connector->connector_type == DRM_MODE_CONNECTOR_e
[Intel-gfx] [PATCH v5 2/2] drm/i915/display/dsc: Set BPP in the kernel
From: Anusha Srivatsa
Set compress BPP in kernel while connector DP or eDP
Cc: Vandita Kulkarni
Cc: Navare Manasi D
Signed-off-by: Anusha Srivatsa
Signed-off-by: Patnana Venkata Sai
---
drivers/gpu/drm/i915/display/intel_dp.c | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5b52beaddada0..4ce15da3e33ce 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1241,9 +1241,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
pipe_config->lane_count = limits->max_lane_count;
if (intel_dp_is_edp(intel_dp)) {
- pipe_config->dsc.compressed_bpp =
- min_t(u16,
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
- pipe_config->pipe_bpp);
+ if (intel_dp->force_dsc_bpp) {
+ drm_dbg_kms(&dev_priv->drm,
+ "DSC BPP forced to %d",
intel_dp->force_dsc_bpp);
+ pipe_config->dsc.compressed_bpp =
intel_dp->force_dsc_bpp;
+ } else {
+ pipe_config->dsc.compressed_bpp =
+ min_t(u16,
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
+ pipe_config->pipe_bpp);
+ }
pipe_config->dsc.slice_count =
drm_dp_dsc_sink_max_slice_count(intel_dp->dsc_dpcd,
true);
@@ -1269,9 +1275,15 @@ static int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
"Compressed BPP/Slice Count not
supported\n");
return -EINVAL;
}
- pipe_config->dsc.compressed_bpp = min_t(u16,
+ if (intel_dp->force_dsc_bpp) {
+ drm_dbg_kms(&dev_priv->drm,
+ "DSC BPP forced to %d\n",
intel_dp->force_dsc_bpp);
+ pipe_config->dsc.compressed_bpp =
intel_dp->force_dsc_bpp;
+ } else {
+ pipe_config->dsc.compressed_bpp = min_t(u16,
dsc_max_output_bpp >> 4,
pipe_config->pipe_bpp);
+ }
pipe_config->dsc.slice_count = dsc_dp_slice_count;
}
/*
@@ -1374,7 +1386,8 @@ intel_dp_compute_link_config(struct intel_encoder
*encoder,
* Pipe joiner needs compression upto display12 due to BW limitation.
DG2
* onwards pipe joiner can be enabled without compression.
*/
- drm_dbg_kms(&i915->drm, "Force DSC en = %d\n", intel_dp->force_dsc_en);
+ drm_dbg_kms(&i915->drm, "Force DSC en = %d\n Force DSC BPP = %d\n",
+ intel_dp->force_dsc_en, intel_dp->force_dsc_bpp);
if (ret || intel_dp->force_dsc_en || (DISPLAY_VER(i915) < 13 &&
pipe_config->bigjoiner)) {
ret = intel_dp_dsc_compute_config(intel_dp, pipe_config,
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [drm-intel:drm-intel-gt-next 7/8] drivers/gpu/drm/i915/selftests/intel_memory_region.c:227 igt_mock_reserve() error: 'mem' dereferencing possible ERR_PTR()
tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
head: 13c2ceb6addb6b14468e09b75832c98909eed8e7
commit: d53ec322dc7de32a59bf1c2a56b93e90fc2f1c28 [7/8] drm/i915/ttm: switch
over to ttm_buddy_man
config: x86_64-randconfig-m001-20210630 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
Reported-by: Dan Carpenter
New smatch warnings:
drivers/gpu/drm/i915/selftests/intel_memory_region.c:227 igt_mock_reserve()
error: 'mem' dereferencing possible ERR_PTR()
vim +/mem +227 drivers/gpu/drm/i915/selftests/intel_memory_region.c
adeca641bcb64f Abdiel Janulgue 2021-01-27 153 static int
igt_mock_reserve(void *arg)
adeca641bcb64f Abdiel Janulgue 2021-01-27 154 {
adeca641bcb64f Abdiel Janulgue 2021-01-27 155 struct
intel_memory_region *mem = arg;
d53ec322dc7de3 Matthew Auld2021-06-16 156 struct drm_i915_private
*i915 = mem->i915;
adeca641bcb64f Abdiel Janulgue 2021-01-27 157 resource_size_t avail =
resource_size(&mem->region);
adeca641bcb64f Abdiel Janulgue 2021-01-27 158 struct
drm_i915_gem_object *obj;
adeca641bcb64f Abdiel Janulgue 2021-01-27 159 const u32 chunk_size =
SZ_32M;
adeca641bcb64f Abdiel Janulgue 2021-01-27 160 u32 i, offset, count,
*order;
adeca641bcb64f Abdiel Janulgue 2021-01-27 161 u64 allocated,
cur_avail;
adeca641bcb64f Abdiel Janulgue 2021-01-27 162 I915_RND_STATE(prng);
adeca641bcb64f Abdiel Janulgue 2021-01-27 163 LIST_HEAD(objects);
adeca641bcb64f Abdiel Janulgue 2021-01-27 164 int err = 0;
adeca641bcb64f Abdiel Janulgue 2021-01-27 165
adeca641bcb64f Abdiel Janulgue 2021-01-27 166 count = avail /
chunk_size;
adeca641bcb64f Abdiel Janulgue 2021-01-27 167 order =
i915_random_order(count, &prng);
adeca641bcb64f Abdiel Janulgue 2021-01-27 168 if (!order)
adeca641bcb64f Abdiel Janulgue 2021-01-27 169 return 0;
adeca641bcb64f Abdiel Janulgue 2021-01-27 170
d53ec322dc7de3 Matthew Auld2021-06-16 171 mem =
mock_region_create(i915, 0, SZ_2G, I915_GTT_PAGE_SIZE_4K, 0);
d53ec322dc7de3 Matthew Auld2021-06-16 172 if (IS_ERR(mem)) {
d53ec322dc7de3 Matthew Auld2021-06-16 173 pr_err("failed
to create memory region\n");
d53ec322dc7de3 Matthew Auld2021-06-16 174 err =
PTR_ERR(mem);
d53ec322dc7de3 Matthew Auld2021-06-16 175 goto out_close;
"mem" is an error pointer.
d53ec322dc7de3 Matthew Auld2021-06-16 176 }
d53ec322dc7de3 Matthew Auld2021-06-16 177
adeca641bcb64f Abdiel Janulgue 2021-01-27 178 /* Reserve a bunch of
ranges within the region */
adeca641bcb64f Abdiel Janulgue 2021-01-27 179 for (i = 0; i < count;
++i) {
adeca641bcb64f Abdiel Janulgue 2021-01-27 180 u64 start =
order[i] * chunk_size;
adeca641bcb64f Abdiel Janulgue 2021-01-27 181 u64 size =
i915_prandom_u32_max_state(chunk_size, &prng);
adeca641bcb64f Abdiel Janulgue 2021-01-27 182
adeca641bcb64f Abdiel Janulgue 2021-01-27 183 /* Allow for
some really big holes */
adeca641bcb64f Abdiel Janulgue 2021-01-27 184 if (!size)
adeca641bcb64f Abdiel Janulgue 2021-01-27 185
continue;
adeca641bcb64f Abdiel Janulgue 2021-01-27 186
adeca641bcb64f Abdiel Janulgue 2021-01-27 187 size =
round_up(size, PAGE_SIZE);
adeca641bcb64f Abdiel Janulgue 2021-01-27 188 offset =
igt_random_offset(&prng, 0, chunk_size, size,
adeca641bcb64f Abdiel Janulgue 2021-01-27 189
PAGE_SIZE);
adeca641bcb64f Abdiel Janulgue 2021-01-27 190
adeca641bcb64f Abdiel Janulgue 2021-01-27 191 err =
intel_memory_region_reserve(mem, start + offset, size);
adeca641bcb64f Abdiel Janulgue 2021-01-27 192 if (err) {
adeca641bcb64f Abdiel Janulgue 2021-01-27 193
pr_err("%s failed to reserve range", __func__);
adeca641bcb64f Abdiel Janulgue 2021-01-27 194 goto
out_close;
adeca641bcb64f Abdiel Janulgue 2021-01-27 195 }
adeca641bcb64f Abdiel Janulgue 2021-01-27 196
adeca641bcb64f Abdiel Janulgue 2021-01-27 197 /* XXX: maybe
sanity check the block range here? */
adeca641bcb64f Abdiel Janulgue 2021-01-27 198 avail -= size;
adeca641bcb64f Abdiel Janulgue 2021-01-27 199 }
adeca641bcb64f Abdiel Janulgue 2021-01-27 200
adeca641bcb64f Abdiel Janulgue 2021-01-27 201 /* Try to see if we can
allocate from the remaining space */
adeca641bcb64f Abdiel Janulgue 2021-01-27 202 allocated = 0;
adeca641bcb64f Abdiel Janulgue 2021-01-27 203 cur_avail = avail;
adeca641bcb64f Abdiel Janulgue 2021-01-27 204
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display/dsc: Set BPP in the kernel (rev5)
== Series Details ==
Series: drm/i915/display/dsc: Set BPP in the kernel (rev5)
URL : https://patchwork.freedesktop.org/series/91917/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
31d490bc229f drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP
enable
-:64: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#64: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2421:
+static ssize_t i915_dsc_bpp_support_write(struct file *file,
+ const char __user *ubuf,
-:110: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#110: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2467:
+static int i915_dsc_bpp_support_open(struct inode *inode,
+ struct file *file)
-:139: WARNING:SYMBOLIC_PERMS: Symbolic permissions 'S_IRUGO' are not
preferred. Consider using octal permissions '0444'.
#139: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:2526:
+ debugfs_create_file("i915_dsc_bpp_support", S_IRUGO,
total: 0 errors, 1 warnings, 2 checks, 120 lines checked
2523c215fa2c drm/i915/display/dsc: Set BPP in the kernel
-:26: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#26: FILE: drivers/gpu/drm/i915/display/intel_dp.c:1246:
+ drm_dbg_kms(&dev_priv->drm,
+ "DSC BPP forced to %d",
intel_dp->force_dsc_bpp);
-:31: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#31: FILE: drivers/gpu/drm/i915/display/intel_dp.c:1251:
+ min_t(u16,
drm_edp_dsc_sink_output_bpp(intel_dp->dsc_dpcd) >> 4,
+ pipe_config->pipe_bpp);
-:47: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#47: FILE: drivers/gpu/drm/i915/display/intel_dp.c:1284:
+ pipe_config->dsc.compressed_bpp = min_t(u16,
dsc_max_output_bpp >> 4,
total: 0 errors, 0 warnings, 3 checks, 43 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display/dsc: Set BPP in the kernel (rev5)
== Series Details == Series: drm/i915/display/dsc: Set BPP in the kernel (rev5) URL : https://patchwork.freedesktop.org/series/91917/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read64' - different lock contexts for basic block +./include/linux/spinlock.h:
Re: [Intel-gfx] [drm-intel:drm-intel-gt-next 8/14] drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized symbol 'rq'.
On Fri, 2 Jul 2021 at 09:45, Dan Carpenter wrote:
>
> tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
> head: 5cd57f676bb946a00275408f0dd0d75dbc466d25
> commit: cf586021642d8017cde111b7dd1ba86224e9da51 [8/14] drm/i915/gt:
> Pipelined page migration
> config: x86_64-randconfig-m001-20210630 (attached as .config)
> compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot
> Reported-by: Dan Carpenter
>
> New smatch warnings:
> drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized
> symbol 'rq'.
> drivers/gpu/drm/i915/gt/selftest_migrate.c:113 copy() error: uninitialized
> symbol 'vaddr'.
>
> Old smatch warnings:
> drivers/gpu/drm/i915/gem/i915_gem_object.h:182 __i915_gem_object_lock()
> error: we previously assumed 'ww' could be null (see line 171)
>
> vim +/rq +102 drivers/gpu/drm/i915/gt/selftest_migrate.c
>
> cf586021642d80 Chris Wilson 2021-06-17 32 static int copy(struct
> intel_migrate *migrate,
> cf586021642d80 Chris Wilson 2021-06-17 33 int (*fn)(struct
> intel_migrate *migrate,
> cf586021642d80 Chris Wilson 2021-06-17 34 struct
> i915_gem_ww_ctx *ww,
> cf586021642d80 Chris Wilson 2021-06-17 35 struct
> drm_i915_gem_object *src,
> cf586021642d80 Chris Wilson 2021-06-17 36 struct
> drm_i915_gem_object *dst,
> cf586021642d80 Chris Wilson 2021-06-17 37 struct
> i915_request **out),
> cf586021642d80 Chris Wilson 2021-06-17 38 u32 sz, struct
> rnd_state *prng)
> cf586021642d80 Chris Wilson 2021-06-17 39 {
> cf586021642d80 Chris Wilson 2021-06-17 40 struct drm_i915_private *i915
> = migrate->context->engine->i915;
> cf586021642d80 Chris Wilson 2021-06-17 41 struct drm_i915_gem_object
> *src, *dst;
> cf586021642d80 Chris Wilson 2021-06-17 42 struct i915_request *rq;
> cf586021642d80 Chris Wilson 2021-06-17 43 struct i915_gem_ww_ctx ww;
> cf586021642d80 Chris Wilson 2021-06-17 44 u32 *vaddr;
> cf586021642d80 Chris Wilson 2021-06-17 45 int err = 0;
>
> One way to silence these warnings would be to initialize err = -EINVAL.
> Then Smatch would know that we goto err_out for an empty list.
>
> cf586021642d80 Chris Wilson 2021-06-17 46 int i;
> cf586021642d80 Chris Wilson 2021-06-17 47
> cf586021642d80 Chris Wilson 2021-06-17 48 src =
> create_lmem_or_internal(i915, sz);
> cf586021642d80 Chris Wilson 2021-06-17 49 if (IS_ERR(src))
> cf586021642d80 Chris Wilson 2021-06-17 50 return 0;
> cf586021642d80 Chris Wilson 2021-06-17 51
> cf586021642d80 Chris Wilson 2021-06-17 52 dst =
> i915_gem_object_create_internal(i915, sz);
> cf586021642d80 Chris Wilson 2021-06-17 53 if (IS_ERR(dst))
> cf586021642d80 Chris Wilson 2021-06-17 54 goto err_free_src;
> cf586021642d80 Chris Wilson 2021-06-17 55
> cf586021642d80 Chris Wilson 2021-06-17 56 for_i915_gem_ww(&ww, err,
> true) {
> cf586021642d80 Chris Wilson 2021-06-17 57 err =
> i915_gem_object_lock(src, &ww);
> cf586021642d80 Chris Wilson 2021-06-17 58 if (err)
> cf586021642d80 Chris Wilson 2021-06-17 59 continue;
> cf586021642d80 Chris Wilson 2021-06-17 60
> cf586021642d80 Chris Wilson 2021-06-17 61 err =
> i915_gem_object_lock(dst, &ww);
> cf586021642d80 Chris Wilson 2021-06-17 62 if (err)
> cf586021642d80 Chris Wilson 2021-06-17 63 continue;
> cf586021642d80 Chris Wilson 2021-06-17 64
> cf586021642d80 Chris Wilson 2021-06-17 65 vaddr =
> i915_gem_object_pin_map(src, I915_MAP_WC);
> cf586021642d80 Chris Wilson 2021-06-17 66 if (IS_ERR(vaddr)) {
> cf586021642d80 Chris Wilson 2021-06-17 67 err =
> PTR_ERR(vaddr);
> cf586021642d80 Chris Wilson 2021-06-17 68 continue;
> cf586021642d80 Chris Wilson 2021-06-17 69 }
> cf586021642d80 Chris Wilson 2021-06-17 70
> cf586021642d80 Chris Wilson 2021-06-17 71 for (i = 0; i < sz /
> sizeof(u32); i++)
> cf586021642d80 Chris Wilson 2021-06-17 72 vaddr[i] = i;
> cf586021642d80 Chris Wilson 2021-06-17 73
> i915_gem_object_flush_map(src);
> cf586021642d80 Chris Wilson 2021-06-17 74
> cf586021642d80 Chris Wilson 2021-06-17 75 vaddr =
> i915_gem_object_pin_map(dst, I915_MAP_WC);
> cf586021642d80 Chris Wilson 2021-06-17 76 if (IS_ERR(vaddr)) {
> cf586021642d80 Chris Wilson 2021-06-17 77 err =
> PTR_ERR(vaddr);
> cf586021642d80 Chris Wilson 2021-06-17 78 goto
> unpin_src;
> cf586021642d80 Chris Wilson 2021-06-17 79 }
> cf586021642d80 Chris Wilson 2021-06-17 80
> cf586021642d80 Chris Wilson 2021-06-17 81 for (i = 0; i < sz /
> siz
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display/dsc: Set BPP in the kernel (rev5)
== Series Details == Series: drm/i915/display/dsc: Set BPP in the kernel (rev5) URL : https://patchwork.freedesktop.org/series/91917/ State : success == Summary == CI Bug Log - changes from CI_DRM_10302 -> Patchwork_20519 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/index.html Known issues Here are the changes found in Patchwork_20519 that come from known issues: ### IGT changes ### Issues hit * igt@core_hotunplug@unbind-rebind: - fi-bwr-2160:[PASS][1] -> [FAIL][2] ([i915#3194]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/fi-bwr-2160/igt@core_hotunp...@unbind-rebind.html * igt@i915_selftest@live@hangcheck: - fi-icl-y: [PASS][3] -> [INCOMPLETE][4] ([i915#2782]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/fi-icl-y/igt@i915_selftest@l...@hangcheck.html - fi-snb-2600:[PASS][5] -> [INCOMPLETE][6] ([i915#2782]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@runner@aborted: - fi-icl-y: NOTRUN -> [FAIL][7] ([i915#2782]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/fi-icl-y/igt@run...@aborted.html [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#3194]: https://gitlab.freedesktop.org/drm/intel/issues/3194 Participating hosts (40 -> 35) -- Missing(5): fi-bsw-cyan bat-adls-4 bat-adls-3 bat-jsl-1 fi-bdw-samus Build changes - * IGT: IGT_6128 -> IGTPW_5971 * Linux: CI_DRM_10302 -> Patchwork_20519 CI-20190529: 20190529 CI_DRM_10302: 403c15e48caac46206e92d703408fe07d83c6bf4 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_5971: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_5971/index.html IGT_6128: b24e5949af7e51f0af484d2ce4cb4c5a41ac5358 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20519: 2523c215fa2c5fa2c8a111bf9b8673ee459e89b4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2523c215fa2c drm/i915/display/dsc: Set BPP in the kernel 31d490bc229f drm/i915/display/dsc: Add Per connector debugfs node for DSC BPP enable == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/selftests: fix smatch warning in igt_check_blocks
The block here can't be NULL, especially since we already dereferenced
it earlier, so remove the redundant check.
igt_check_blocks() warn: variable dereferenced before check 'block' (see line
126)
Reported-by: Dan Carpenter
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/i915_buddy.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_buddy.c
b/drivers/gpu/drm/i915/selftests/i915_buddy.c
index f0f5c4df8dbc..d61ec9c951bf 100644
--- a/drivers/gpu/drm/i915/selftests/i915_buddy.c
+++ b/drivers/gpu/drm/i915/selftests/i915_buddy.c
@@ -166,10 +166,8 @@ static int igt_check_blocks(struct i915_buddy_mm *mm,
igt_dump_block(mm, prev);
}
- if (block) {
- pr_err("bad block, dump:\n");
- igt_dump_block(mm, block);
- }
+ pr_err("bad block, dump:\n");
+ igt_dump_block(mm, block);
return err;
}
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/selftests: fix smatch warning in mock_reserve
If mock_region_create fails then mem will be an error pointer. Instead
we just need to use the correct ordering for the onion unwind.
igt_mock_reserve() error: 'mem' dereferencing possible ERR_PTR()
Reported-by: kernel test robot
Reported-by: Dan Carpenter
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/selftests/intel_memory_region.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
index 1aaccb9841a0..418caae84759 100644
--- a/drivers/gpu/drm/i915/selftests/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/selftests/intel_memory_region.c
@@ -173,7 +173,7 @@ static int igt_mock_reserve(void *arg)
if (IS_ERR(mem)) {
pr_err("failed to create memory region\n");
err = PTR_ERR(mem);
- goto out_close;
+ goto out_free_order;
}
/* Reserve a bunch of ranges within the region */
@@ -224,9 +224,10 @@ static int igt_mock_reserve(void *arg)
}
out_close:
- kfree(order);
close_objects(mem, &objects);
intel_memory_region_put(mem);
+out_free_order:
+ kfree(order);
return err;
}
--
2.26.3
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:drm-intel-gt-next 8/14] drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized symbol 'rq'.
On Fri, Jul 02, 2021 at 11:32:45AM +0100, Matthew Auld wrote:
> On Fri, 2 Jul 2021 at 09:45, Dan Carpenter wrote:
> >
> > tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
> > head: 5cd57f676bb946a00275408f0dd0d75dbc466d25
> > commit: cf586021642d8017cde111b7dd1ba86224e9da51 [8/14] drm/i915/gt:
> > Pipelined page migration
> > config: x86_64-randconfig-m001-20210630 (attached as .config)
> > compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> >
> > If you fix the issue, kindly add following tag as appropriate
> > Reported-by: kernel test robot
> > Reported-by: Dan Carpenter
> >
> > New smatch warnings:
> > drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized
> > symbol 'rq'.
> > drivers/gpu/drm/i915/gt/selftest_migrate.c:113 copy() error: uninitialized
> > symbol 'vaddr'.
> >
> > Old smatch warnings:
> > drivers/gpu/drm/i915/gem/i915_gem_object.h:182 __i915_gem_object_lock()
> > error: we previously assumed 'ww' could be null (see line 171)
> >
> > vim +/rq +102 drivers/gpu/drm/i915/gt/selftest_migrate.c
> >
> > cf586021642d80 Chris Wilson 2021-06-17 32 static int copy(struct
> > intel_migrate *migrate,
> > cf586021642d80 Chris Wilson 2021-06-17 33 int (*fn)(struct
> > intel_migrate *migrate,
> > cf586021642d80 Chris Wilson 2021-06-17 34 struct
> > i915_gem_ww_ctx *ww,
> > cf586021642d80 Chris Wilson 2021-06-17 35 struct
> > drm_i915_gem_object *src,
> > cf586021642d80 Chris Wilson 2021-06-17 36 struct
> > drm_i915_gem_object *dst,
> > cf586021642d80 Chris Wilson 2021-06-17 37 struct
> > i915_request **out),
> > cf586021642d80 Chris Wilson 2021-06-17 38 u32 sz, struct
> > rnd_state *prng)
> > cf586021642d80 Chris Wilson 2021-06-17 39 {
> > cf586021642d80 Chris Wilson 2021-06-17 40 struct drm_i915_private
> > *i915 = migrate->context->engine->i915;
> > cf586021642d80 Chris Wilson 2021-06-17 41 struct drm_i915_gem_object
> > *src, *dst;
> > cf586021642d80 Chris Wilson 2021-06-17 42 struct i915_request *rq;
> > cf586021642d80 Chris Wilson 2021-06-17 43 struct i915_gem_ww_ctx ww;
> > cf586021642d80 Chris Wilson 2021-06-17 44 u32 *vaddr;
> > cf586021642d80 Chris Wilson 2021-06-17 45 int err = 0;
> >
> > One way to silence these warnings would be to initialize err = -EINVAL.
> > Then Smatch would know that we goto err_out for an empty list.
> >
> > cf586021642d80 Chris Wilson 2021-06-17 46 int i;
> > cf586021642d80 Chris Wilson 2021-06-17 47
> > cf586021642d80 Chris Wilson 2021-06-17 48 src =
> > create_lmem_or_internal(i915, sz);
> > cf586021642d80 Chris Wilson 2021-06-17 49 if (IS_ERR(src))
> > cf586021642d80 Chris Wilson 2021-06-17 50 return 0;
> > cf586021642d80 Chris Wilson 2021-06-17 51
> > cf586021642d80 Chris Wilson 2021-06-17 52 dst =
> > i915_gem_object_create_internal(i915, sz);
> > cf586021642d80 Chris Wilson 2021-06-17 53 if (IS_ERR(dst))
> > cf586021642d80 Chris Wilson 2021-06-17 54 goto err_free_src;
> > cf586021642d80 Chris Wilson 2021-06-17 55
> > cf586021642d80 Chris Wilson 2021-06-17 56 for_i915_gem_ww(&ww, err,
> > true) {
> > cf586021642d80 Chris Wilson 2021-06-17 57 err =
> > i915_gem_object_lock(src, &ww);
> > cf586021642d80 Chris Wilson 2021-06-17 58 if (err)
> > cf586021642d80 Chris Wilson 2021-06-17 59 continue;
> > cf586021642d80 Chris Wilson 2021-06-17 60
> > cf586021642d80 Chris Wilson 2021-06-17 61 err =
> > i915_gem_object_lock(dst, &ww);
> > cf586021642d80 Chris Wilson 2021-06-17 62 if (err)
> > cf586021642d80 Chris Wilson 2021-06-17 63 continue;
> > cf586021642d80 Chris Wilson 2021-06-17 64
> > cf586021642d80 Chris Wilson 2021-06-17 65 vaddr =
> > i915_gem_object_pin_map(src, I915_MAP_WC);
> > cf586021642d80 Chris Wilson 2021-06-17 66 if (IS_ERR(vaddr)) {
> > cf586021642d80 Chris Wilson 2021-06-17 67 err =
> > PTR_ERR(vaddr);
> > cf586021642d80 Chris Wilson 2021-06-17 68 continue;
> > cf586021642d80 Chris Wilson 2021-06-17 69 }
> > cf586021642d80 Chris Wilson 2021-06-17 70
> > cf586021642d80 Chris Wilson 2021-06-17 71 for (i = 0; i < sz
> > / sizeof(u32); i++)
> > cf586021642d80 Chris Wilson 2021-06-17 72 vaddr[i] =
> > i;
> > cf586021642d80 Chris Wilson 2021-06-17 73
> > i915_gem_object_flush_map(src);
> > cf586021642d80 Chris Wilson 2021-06-17 74
> > cf586021642d80 Chris Wilson 2021-06-17 75 vaddr =
> > i915_gem_object_pin_map(dst, I915_MAP_WC);
> > cf586021642d80 Chris Wilson 2021-06-17 76 if (IS_ERR(vaddr)) {
> > cf586021642d80 Chris Wilson 2021-06-17 77 err =
> > PTR_ERR(vaddr);
> > cf586021642d80
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/2] drm/i915/selftests: fix smatch warning in igt_check_blocks
== Series Details == Series: series starting with [1/2] drm/i915/selftests: fix smatch warning in igt_check_blocks URL : https://patchwork.freedesktop.org/series/92150/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0da2bc133432 drm/i915/selftests: fix smatch warning in igt_check_blocks -:4: WARNING:EMAIL_SUBJECT: A patch subject line should describe the change not the tool that found it #4: Subject: [PATCH] drm/i915/selftests: fix smatch warning in igt_check_blocks -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #9: igt_check_blocks() warn: variable dereferenced before check 'block' (see line 126) total: 0 errors, 2 warnings, 0 checks, 12 lines checked 337f0543a04c drm/i915/selftests: fix smatch warning in mock_reserve -:4: WARNING:EMAIL_SUBJECT: A patch subject line should describe the change not the tool that found it #4: Subject: [PATCH] drm/i915/selftests: fix smatch warning in mock_reserve total: 0 errors, 1 warnings, 0 checks, 19 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:drm-intel-gt-next 8/14] drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized symbol 'rq'.
On Fri, Jul 02, 2021 at 02:07:27PM +0300, Dan Carpenter wrote: > On Fri, Jul 02, 2021 at 11:32:45AM +0100, Matthew Auld wrote: > > On Fri, 2 Jul 2021 at 09:45, Dan Carpenter wrote: > > > cf586021642d80 Chris Wilson 2021-06-17 84 > > > cf586021642d80 Chris Wilson 2021-06-17 85 err = fn(migrate, > > > &ww, src, dst, &rq); > > > cf586021642d80 Chris Wilson 2021-06-17 86 if (!err) > > > cf586021642d80 Chris Wilson 2021-06-17 87 continue; > > > > > > Does fn() initialize "rq" on the success path? Anyway Smatch would > > > complain anyway because it thinks the list could be empty or that we > > > might hit and early continue for everything. > > > > The fn() will always first initialize the rq to NULL. If it returns > > success then rq will always be a valid rq. If it returns an err then > > the rq might be NULL, or a valid rq depending on how far the copy/fn > > got. > > > > And for_i915_gem_ww() will always run at least once, since ww->loop = > > true, so this looks like a false positive? > > You don't think i915_gem_object_lock(), i915_gem_object_pin_map() or > i915_gem_object_pin_map() can fail? Btw, I sincerely hope that we will re-enable GCC's uninitialized variable checks. Will GCC be able to verify that this is initialized? regards, dan carpenter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:drm-intel-gt-next 8/14] drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized symbol 'rq'.
On Fri, 2 Jul 2021 at 12:07, Dan Carpenter wrote:
>
> On Fri, Jul 02, 2021 at 11:32:45AM +0100, Matthew Auld wrote:
> > On Fri, 2 Jul 2021 at 09:45, Dan Carpenter wrote:
> > >
> > > tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
> > > head: 5cd57f676bb946a00275408f0dd0d75dbc466d25
> > > commit: cf586021642d8017cde111b7dd1ba86224e9da51 [8/14] drm/i915/gt:
> > > Pipelined page migration
> > > config: x86_64-randconfig-m001-20210630 (attached as .config)
> > > compiler: gcc-9 (Debian 9.3.0-22) 9.3.0
> > >
> > > If you fix the issue, kindly add following tag as appropriate
> > > Reported-by: kernel test robot
> > > Reported-by: Dan Carpenter
> > >
> > > New smatch warnings:
> > > drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error:
> > > uninitialized symbol 'rq'.
> > > drivers/gpu/drm/i915/gt/selftest_migrate.c:113 copy() error:
> > > uninitialized symbol 'vaddr'.
> > >
> > > Old smatch warnings:
> > > drivers/gpu/drm/i915/gem/i915_gem_object.h:182 __i915_gem_object_lock()
> > > error: we previously assumed 'ww' could be null (see line 171)
> > >
> > > vim +/rq +102 drivers/gpu/drm/i915/gt/selftest_migrate.c
> > >
> > > cf586021642d80 Chris Wilson 2021-06-17 32 static int copy(struct
> > > intel_migrate *migrate,
> > > cf586021642d80 Chris Wilson 2021-06-17 33 int (*fn)(struct
> > > intel_migrate *migrate,
> > > cf586021642d80 Chris Wilson 2021-06-17 34 struct
> > > i915_gem_ww_ctx *ww,
> > > cf586021642d80 Chris Wilson 2021-06-17 35 struct
> > > drm_i915_gem_object *src,
> > > cf586021642d80 Chris Wilson 2021-06-17 36 struct
> > > drm_i915_gem_object *dst,
> > > cf586021642d80 Chris Wilson 2021-06-17 37 struct
> > > i915_request **out),
> > > cf586021642d80 Chris Wilson 2021-06-17 38 u32 sz, struct
> > > rnd_state *prng)
> > > cf586021642d80 Chris Wilson 2021-06-17 39 {
> > > cf586021642d80 Chris Wilson 2021-06-17 40 struct drm_i915_private
> > > *i915 = migrate->context->engine->i915;
> > > cf586021642d80 Chris Wilson 2021-06-17 41 struct
> > > drm_i915_gem_object *src, *dst;
> > > cf586021642d80 Chris Wilson 2021-06-17 42 struct i915_request *rq;
> > > cf586021642d80 Chris Wilson 2021-06-17 43 struct i915_gem_ww_ctx ww;
> > > cf586021642d80 Chris Wilson 2021-06-17 44 u32 *vaddr;
> > > cf586021642d80 Chris Wilson 2021-06-17 45 int err = 0;
> > >
> > > One way to silence these warnings would be to initialize err = -EINVAL.
> > > Then Smatch would know that we goto err_out for an empty list.
> > >
> > > cf586021642d80 Chris Wilson 2021-06-17 46 int i;
> > > cf586021642d80 Chris Wilson 2021-06-17 47
> > > cf586021642d80 Chris Wilson 2021-06-17 48 src =
> > > create_lmem_or_internal(i915, sz);
> > > cf586021642d80 Chris Wilson 2021-06-17 49 if (IS_ERR(src))
> > > cf586021642d80 Chris Wilson 2021-06-17 50 return 0;
> > > cf586021642d80 Chris Wilson 2021-06-17 51
> > > cf586021642d80 Chris Wilson 2021-06-17 52 dst =
> > > i915_gem_object_create_internal(i915, sz);
> > > cf586021642d80 Chris Wilson 2021-06-17 53 if (IS_ERR(dst))
> > > cf586021642d80 Chris Wilson 2021-06-17 54 goto err_free_src;
> > > cf586021642d80 Chris Wilson 2021-06-17 55
> > > cf586021642d80 Chris Wilson 2021-06-17 56 for_i915_gem_ww(&ww, err,
> > > true) {
> > > cf586021642d80 Chris Wilson 2021-06-17 57 err =
> > > i915_gem_object_lock(src, &ww);
> > > cf586021642d80 Chris Wilson 2021-06-17 58 if (err)
> > > cf586021642d80 Chris Wilson 2021-06-17 59 continue;
> > > cf586021642d80 Chris Wilson 2021-06-17 60
> > > cf586021642d80 Chris Wilson 2021-06-17 61 err =
> > > i915_gem_object_lock(dst, &ww);
> > > cf586021642d80 Chris Wilson 2021-06-17 62 if (err)
> > > cf586021642d80 Chris Wilson 2021-06-17 63 continue;
> > > cf586021642d80 Chris Wilson 2021-06-17 64
> > > cf586021642d80 Chris Wilson 2021-06-17 65 vaddr =
> > > i915_gem_object_pin_map(src, I915_MAP_WC);
> > > cf586021642d80 Chris Wilson 2021-06-17 66 if
> > > (IS_ERR(vaddr)) {
> > > cf586021642d80 Chris Wilson 2021-06-17 67 err =
> > > PTR_ERR(vaddr);
> > > cf586021642d80 Chris Wilson 2021-06-17 68 continue;
> > > cf586021642d80 Chris Wilson 2021-06-17 69 }
> > > cf586021642d80 Chris Wilson 2021-06-17 70
> > > cf586021642d80 Chris Wilson 2021-06-17 71 for (i = 0; i <
> > > sz / sizeof(u32); i++)
> > > cf586021642d80 Chris Wilson 2021-06-17 72 vaddr[i]
> > > = i;
> > > cf586021642d80 Chris Wilson 2021-06-17 73
> > > i915_gem_object_flush_map(src);
> > > cf586021642d80 Chris Wilson 2021-06-17 74
> > > cf586021642d80 Chris Wilson 2021-06-17 75 vaddr
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: fix smatch warning in igt_check_blocks
== Series Details == Series: series starting with [1/2] drm/i915/selftests: fix smatch warning in igt_check_blocks URL : https://patchwork.freedesktop.org/series/92150/ State : success == Summary == CI Bug Log - changes from CI_DRM_10302 -> Patchwork_20520 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/index.html Known issues Here are the changes found in Patchwork_20520 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[PASS][1] -> [INCOMPLETE][2] ([i915#2782]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 Participating hosts (40 -> 34) -- Missing(6): fi-kbl-soraka fi-bsw-cyan bat-adls-4 bat-adls-3 fi-bdw-samus bat-jsl-1 Build changes - * Linux: CI_DRM_10302 -> Patchwork_20520 CI-20190529: 20190529 CI_DRM_10302: 403c15e48caac46206e92d703408fe07d83c6bf4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6128: b24e5949af7e51f0af484d2ce4cb4c5a41ac5358 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20520: 337f0543a04c2c79c40f7602b5b3f19d278b3ab0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 337f0543a04c drm/i915/selftests: fix smatch warning in mock_reserve 0da2bc133432 drm/i915/selftests: fix smatch warning in igt_check_blocks == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:drm-intel-gt-next 8/14] drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized symbol 'rq'.
On Fri, 2 Jul 2021 at 12:14, Dan Carpenter wrote:
>
> On Fri, Jul 02, 2021 at 02:07:27PM +0300, Dan Carpenter wrote:
> > On Fri, Jul 02, 2021 at 11:32:45AM +0100, Matthew Auld wrote:
> > > On Fri, 2 Jul 2021 at 09:45, Dan Carpenter
> > > wrote:
> > > > cf586021642d80 Chris Wilson 2021-06-17 84
> > > > cf586021642d80 Chris Wilson 2021-06-17 85 err =
> > > > fn(migrate, &ww, src, dst, &rq);
> > > > cf586021642d80 Chris Wilson 2021-06-17 86 if (!err)
> > > > cf586021642d80 Chris Wilson 2021-06-17 87
> > > > continue;
> > > >
> > > > Does fn() initialize "rq" on the success path? Anyway Smatch would
> > > > complain anyway because it thinks the list could be empty or that we
> > > > might hit and early continue for everything.
> > >
> > > The fn() will always first initialize the rq to NULL. If it returns
> > > success then rq will always be a valid rq. If it returns an err then
> > > the rq might be NULL, or a valid rq depending on how far the copy/fn
> > > got.
> > >
> > > And for_i915_gem_ww() will always run at least once, since ww->loop =
> > > true, so this looks like a false positive?
> >
> > You don't think i915_gem_object_lock(), i915_gem_object_pin_map() or
> > i915_gem_object_pin_map() can fail?
>
> Btw, I sincerely hope that we will re-enable GCC's uninitialized
> variable checks. Will GCC be able to verify that this is initialized?
34b07d47dd00 ("drm/i915: Enable -Wuninitialized")
GCC doesn't complain AFAIK.
>
> regards,
> dan carpenter
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/53] drm/i915/gen12: Use fuse info to enable SFC
On 01/07/2021 21:23, Matt Roper wrote:
From: Venkata Sandeep Dhanalakota
In Gen12 there are various fuse combinations and in each configuration
vdbox engine may be connected to SFC depending on which engines are
available, so we need to set the SFC capability based on fuse value from
the hardware. Even numbered phyical instance always have SFC, odd
physical
numbered physical instances have SFC only if previous even instance is
fused off.
Just a few nits.
Bspec: 48028
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 30 ++-
1 file changed, 24 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 151870d8fdd3..4ab2c9abb943 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -442,6 +442,28 @@ void intel_engines_free(struct intel_gt *gt)
}
}
+static inline
Inline is not desired here.
+bool vdbox_has_sfc(struct drm_i915_private *i915, unsigned int physical_vdbox,
+ unsigned int logical_vdbox, u16 vdbox_mask)
+{
I'd be tempted to prefix the function name with gen11_ so it is clearer
it does not apply to earlier gens. Because if looking just at the diff
out of context below, one can wonder if there is a functional change or
not. There isn't, because there is a bailout for gen < 11 early in
init_engine_mask(), but perhaps gen11 function name prefix would make
this a bit more self-documenting.
+ /*
+* In Gen11, only even numbered logical VDBOXes are hooked
+* up to an SFC (Scaler & Format Converter) unit.
+* In Gen12, Even numbered phyical instance always are connected
physical
+* to an SFC. Odd numbered physical instances have SFC only if
+* previous even instance is fused off.
+*/
+ if (GRAPHICS_VER(i915) == 12) {
+ return (physical_vdbox % 2 == 0) ||
+ !(BIT(physical_vdbox - 1) & vdbox_mask);
+ } else if (GRAPHICS_VER(i915) == 11) {
+ return logical_vdbox % 2 == 0;
+ }
Not need for curlies on these branches.
+
+ MISSING_CASE(GRAPHICS_VER(i915));
+ return false;
+}
+
/*
* Determine which engines are fused off in our particular hardware.
* Note that we have a catch-22 situation where we need to be able to access
@@ -493,13 +515,9 @@ static intel_engine_mask_t init_engine_mask(struct
intel_gt *gt)
continue;
}
- /*
-* In Gen11, only even numbered logical VDBOXes are
-* hooked up to an SFC (Scaler & Format Converter) unit.
-* In TGL each VDBOX has access to an SFC.
-*/
- if (GRAPHICS_VER(i915) >= 12 || logical_vdbox++ % 2 == 0)
+ if (vdbox_has_sfc(i915, i, logical_vdbox, vdbox_mask))
gt->info.vdbox_sfc_access |= BIT(i);
+ logical_vdbox++;
}
drm_dbg(&i915->drm, "vdbox enable: %04x, instances: %04lx\n",
vdbox_mask, VDBOX_MASK(gt));
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [drm-intel:drm-intel-gt-next 8/14] drivers/gpu/drm/i915/gt/selftest_migrate.c:102 copy() error: uninitialized symbol 'rq'.
On Fri, Jul 02, 2021 at 12:34:33PM +0100, Matthew Auld wrote: > > > > cf586021642d80 Chris Wilson 2021-06-17 85 err = > > > > fn(migrate, &ww, src, dst, &rq); > > > > cf586021642d80 Chris Wilson 2021-06-17 86 if (!err) > > > > cf586021642d80 Chris Wilson 2021-06-17 87 > > > > continue; > > > > > > > > Does fn() initialize "rq" on the success path? Anyway Smatch would > > > > complain anyway because it thinks the list could be empty or that we > > > > might hit and early continue for everything. > > > > > > The fn() will always first initialize the rq to NULL. If it returns > > > success then rq will always be a valid rq. If it returns an err then > > > the rq might be NULL, or a valid rq depending on how far the copy/fn > > > got. > > > > > > And for_i915_gem_ww() will always run at least once, since ww->loop = > > > true, so this looks like a false positive? > > > > You don't think i915_gem_object_lock(), i915_gem_object_pin_map() or > > i915_gem_object_pin_map() can fail? > > Yeah, they can totally fail but then we mostly likely just hit the > err_out. The for_i915_gem_ww() is a little strange since it's not > really looping over anything, it's just about retrying the block if we > see -EDEADLK(which involves dropping some locks), if we see any other > error then the loop is terminated with ww->loop = false, which then > hits the goto err_out. > Ah, yeah, you're right. False positive. I hadn't looked at this code in context (I only had reviewed the email). Now that I've pulled the tree and looked at the code, then I'm sort of surprised that Smatch generates a warning... I will investigate some more. Thanks! regards, dan carpenter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/53] drm/i915/xehp: Extra media engines - Part 1 (engine definitions)
On 01/07/2021 21:23, Matt Roper wrote:
From: John Harrison
Xe_HP can have a lot of extra media engines. This patch adds the basic
definitions for them.
Cc: Tvrtko Ursulin
Signed-off-by: John Harrison
Signed-off-by: Tomas Winkler
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 7 ++-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 50
drivers/gpu/drm/i915/gt/intel_engine_types.h | 14 --
drivers/gpu/drm/i915/i915_reg.h | 6 +++
4 files changed, 69 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
index 87b06572fd2e..35edc55720f4 100644
--- a/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/gen8_engine_cs.c
@@ -279,7 +279,7 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
if (mode & EMIT_INVALIDATE)
aux_inv = rq->engine->mask & ~BIT(BCS0);
if (aux_inv)
- cmd += 2 * hweight8(aux_inv) + 2;
+ cmd += 2 * hweight32(aux_inv) + 2;
cs = intel_ring_begin(rq, cmd);
if (IS_ERR(cs))
@@ -313,9 +313,8 @@ int gen12_emit_flush_xcs(struct i915_request *rq, u32 mode)
struct intel_engine_cs *engine;
unsigned int tmp;
- *cs++ = MI_LOAD_REGISTER_IMM(hweight8(aux_inv));
- for_each_engine_masked(engine, rq->engine->gt,
- aux_inv, tmp) {
+ *cs++ = MI_LOAD_REGISTER_IMM(hweight32(aux_inv));
+ for_each_engine_masked(engine, rq->engine->gt, aux_inv, tmp) {
*cs++ = i915_mmio_reg_offset(aux_inv_reg(engine));
*cs++ = AUX_INV;
}
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 4ab2c9abb943..6e2aa1acc4d4 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -104,6 +104,38 @@ static const struct engine_info intel_engines[] = {
{ .graphics_ver = 11, .base = GEN11_BSD4_RING_BASE }
},
},
+ [VCS4] = {
+ .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+ .class = VIDEO_DECODE_CLASS,
+ .instance = 4,
+ .mmio_bases = {
+ { .graphics_ver = 11, .base = XEHP_BSD5_RING_BASE }
+ },
+ },
+ [VCS5] = {
+ .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+ .class = VIDEO_DECODE_CLASS,
+ .instance = 5,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHP_BSD6_RING_BASE }
+ },
+ },
+ [VCS6] = {
+ .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+ .class = VIDEO_DECODE_CLASS,
+ .instance = 6,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHP_BSD7_RING_BASE }
+ },
+ },
+ [VCS7] = {
+ .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+ .class = VIDEO_DECODE_CLASS,
+ .instance = 7,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHP_BSD8_RING_BASE }
+ },
+ },
[VECS0] = {
.hw_id = VECS0_HW,
.class = VIDEO_ENHANCEMENT_CLASS,
@@ -121,6 +153,22 @@ static const struct engine_info intel_engines[] = {
{ .graphics_ver = 11, .base = GEN11_VEBOX2_RING_BASE }
},
},
+ [VECS2] = {
+ .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+ .class = VIDEO_ENHANCEMENT_CLASS,
+ .instance = 2,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHP_VEBOX3_RING_BASE }
+ },
+ },
+ [VECS3] = {
+ .hw_id = 0, /* not used in GEN12+, see MI_SEMAPHORE_SIGNAL */
+ .class = VIDEO_ENHANCEMENT_CLASS,
+ .instance = 3,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = XEHP_VEBOX4_RING_BASE }
+ },
+ },
};
/**
@@ -269,6 +317,8 @@ static int intel_engine_setup(struct intel_gt *gt, enum
intel_engine_id id)
BUILD_BUG_ON(MAX_ENGINE_CLASS >= BIT(GEN11_ENGINE_CLASS_WIDTH));
BUILD_BUG_ON(MAX_ENGINE_INSTANCE >= BIT(GEN11_ENGINE_INSTANCE_WIDTH));
+ BUILD_BUG_ON(I915_MAX_VCS > (MAX_ENGINE_INSTANCE + 1));
+ BUILD_BUG_ON(I915_MAX_VECS > (MAX_ENGINE_INSTANCE + 1));
if (GEM_DEBUG_WARN_ON(id >= ARRAY_SIZE(gt->engine)))
return -EINVAL;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 5b91068ab277..b25f594a7e4b 100644
--- a/driver
Re: [Intel-gfx] [PATCH 01/53] drm/i915: Add "release id" version
On 01/07/2021 21:23, Matt Roper wrote:
From: Lucas De Marchi
Besides the arch version returned by GRAPHICS_VER(), new platforms
contain a "release id" to make clear the difference from one platform to
another. Although for the first ones we may use them as if they were a
What does "first ones" refer to here?
major/minor version, that is not true for all platforms: we may have a
`release_id == n` that is closer to `n - 2` than to `n - 1`.
Hm this is a bit confusing. Is the sentence simply trying to say that,
as the release id number is growing, hw capabilities are not simply
accumulating but can be removed as well? Otherwise I am not sure how the
user of these macros is supposed to act on this sentence.
However the release id number is not defined by hardware until we start
using the GMD_ID register. For the platforms before that register is
useful we will set the values in software and we can set them as we
please. So the plan is to set them so we can group different features
under a single GRAPHICS_VER_FULL() check.
After GMD_ID is used, the usefulness of a "full version check" will be
greatly reduced and will be mostly used for deciding workarounds and a
few code paths. So it makes sense to keep it as a separate field from
graphics_ver.
Also, currently there is not much use for the release id in media and
display, so keep them out.
This is a mix of 2 independent changes: one by me and the other by Matt
Roper.
Cc: Matt Roper
Signed-off-by: Lucas De Marchi
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/intel_device_info.c | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 2 ++
3 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6dff4ca01241..9639800485b9 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1258,11 +1258,17 @@ static inline struct drm_i915_private
*pdev_to_i915(struct pci_dev *pdev)
*/
#define IS_GEN(dev_priv, n) (GRAPHICS_VER(dev_priv) == (n))
+#define IP_VER(ver, release) ((ver) << 8 | (release))
+
#define GRAPHICS_VER(i915)(INTEL_INFO(i915)->graphics_ver)
+#define GRAPHICS_VER_FULL(i915)
IP_VER(INTEL_INFO(i915)->graphics_ver, \
+
INTEL_INFO(i915)->graphics_ver_release)
#define IS_GRAPHICS_VER(i915, from, until) \
(GRAPHICS_VER(i915) >= (from) && GRAPHICS_VER(i915) <= (until))
#define MEDIA_VER(i915) (INTEL_INFO(i915)->media_ver)
+#define MEDIA_VER_FULL(i915) IP_VER(INTEL_INFO(i915)->media_ver, \
+
INTEL_INFO(i915)->media_ver_release)
#define IS_MEDIA_VER(i915, from, until) \
(MEDIA_VER(i915) >= (from) && MEDIA_VER(i915) <= (until))
diff --git a/drivers/gpu/drm/i915/intel_device_info.c b/drivers/gpu/drm/i915/intel_device_info.c
index 7eaa92fee421..e8ad14f002c1 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -97,7 +97,9 @@ void intel_device_info_print_static(const struct
intel_device_info *info,
struct drm_printer *p)
{
drm_printf(p, "graphics_ver: %u\n", info->graphics_ver);
+ drm_printf(p, "graphics_ver_release: %u\n", info->graphics_ver_release);
I get the VER and VER_FULL in the macros but could 'ver' and
'ver_release' here and in the code simply be renamed to 'ver'/'version'
and 'release'? Maybe it is just me but don't think I encountered the
term "version release" before.
Regards,
Tvrtko
drm_printf(p, "media_ver: %u\n", info->media_ver);
+ drm_printf(p, "media_ver_release: %u\n", info->media_ver_release);
drm_printf(p, "display_ver: %u\n", info->display.ver);
drm_printf(p, "gt: %d\n", info->gt);
drm_printf(p, "iommu: %s\n", iommu_name());
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index b326aff65cd6..944a5ff4df49 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -162,7 +162,9 @@ enum intel_ppgtt_type {
struct intel_device_info {
u8 graphics_ver;
+ u8 graphics_ver_release;
u8 media_ver;
+ u8 media_ver_release;
u8 gt; /* GT number, 0 if undefined */
intel_engine_mask_t platform_engine_mask; /* Engines supported by the
HW */
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/53] drm/i915/xehp: Extra media engines - Part 2 (interrupts)
On 01/07/2021 21:23, Matt Roper wrote:
From: John Harrison
Xe_HP can have a lot of extra media engines. This patch adds the
interrupt handler support for them.
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: John Harrison
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 -
drivers/gpu/drm/i915/i915_reg.h| 3 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index c13462274fe8..b2de83be4d97 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -184,7 +184,13 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
intel_uncore_write(uncore, GEN11_BCS_RSVD_INTR_MASK,~0);
intel_uncore_write(uncore, GEN11_VCS0_VCS1_INTR_MASK, ~0);
intel_uncore_write(uncore, GEN11_VCS2_VCS3_INTR_MASK, ~0);
+ if (HAS_ENGINE(gt, VCS4) || HAS_ENGINE(gt, VCS5))
+ intel_uncore_write(uncore, GEN12_VCS4_VCS5_INTR_MASK, ~0);
+ if (HAS_ENGINE(gt, VCS6) || HAS_ENGINE(gt, VCS7))
+ intel_uncore_write(uncore, GEN12_VCS6_VCS7_INTR_MASK, ~0);
intel_uncore_write(uncore, GEN11_VECS0_VECS1_INTR_MASK, ~0);
+ if (HAS_ENGINE(gt, VECS2) || HAS_ENGINE(gt, VECS3))
+ intel_uncore_write(uncore, GEN12_VECS2_VECS3_INTR_MASK, ~0);
intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_MASK, ~0);
@@ -218,8 +224,13 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
intel_uncore_write(uncore, GEN11_BCS_RSVD_INTR_MASK, ~smask);
intel_uncore_write(uncore, GEN11_VCS0_VCS1_INTR_MASK, ~dmask);
intel_uncore_write(uncore, GEN11_VCS2_VCS3_INTR_MASK, ~dmask);
+ if (HAS_ENGINE(gt, VCS4) || HAS_ENGINE(gt, VCS5))
+ intel_uncore_write(uncore, GEN12_VCS4_VCS5_INTR_MASK, ~dmask);
+ if (HAS_ENGINE(gt, VCS6) || HAS_ENGINE(gt, VCS7))
+ intel_uncore_write(uncore, GEN12_VCS6_VCS7_INTR_MASK, ~dmask);
intel_uncore_write(uncore, GEN11_VECS0_VECS1_INTR_MASK, ~dmask);
Poor 0-1 sandwiched between 4-7 and 2-3. ;) With hopefully order restored:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
-
+ if (HAS_ENGINE(gt, VECS2) || HAS_ENGINE(gt, VECS3))
+ intel_uncore_write(uncore, GEN12_VECS2_VECS3_INTR_MASK, ~dmask);
/*
* RPS interrupts will get enabled/disabled on demand when RPS itself
* is enabled/disabled.
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d4546e871833..cb1716b6ce72 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8076,7 +8076,10 @@ enum {
#define GEN11_BCS_RSVD_INTR_MASK _MMIO(0x1900a0)
#define GEN11_VCS0_VCS1_INTR_MASK _MMIO(0x1900a8)
#define GEN11_VCS2_VCS3_INTR_MASK _MMIO(0x1900ac)
+#define GEN12_VCS4_VCS5_INTR_MASK _MMIO(0x1900b0)
+#define GEN12_VCS6_VCS7_INTR_MASK _MMIO(0x1900b4)
#define GEN11_VECS0_VECS1_INTR_MASK _MMIO(0x1900d0)
+#define GEN12_VECS2_VECS3_INTR_MASK_MMIO(0x1900d4)
#define GEN11_GUC_SG_INTR_MASK_MMIO(0x1900e8)
#define GEN11_GPM_WGBOXPERF_INTR_MASK _MMIO(0x1900ec)
#define GEN11_CRYPTO_RSVD_INTR_MASK _MMIO(0x1900f0)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+
On 02.07.2021 10:13, Martin Peres wrote:
> On 01/07/2021 21:24, Martin Peres wrote:
> [...]
>>>
> + i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
> + return;
> + }
> +
> + /* Default: enable HuC authentication and GuC submission */
> + i915->params.enable_guc = ENABLE_GUC_LOAD_HUC |
> ENABLE_GUC_SUBMISSION;
This seems to be in contradiction with the GuC submission plan which
states:
"Not enabled by default on any current platforms but can be enabled via
modparam enable_guc".
>>>
>>> I don't believe any current platform gets this point where GuC
>>> submission would be enabled by default. The first would be ADL-P which
>>> isn't out yet.
>>
>> Isn't that exactly what the line above does?
>
> In case you missed this crucial part of the review. Please answer the
> above question.
I guess there is some misunderstanding here, and I must admit I had
similar doubt, but if you look beyond patch diff and check function code
you will find that the very condition is:
/* Don't enable GuC/HuC on pre-Gen12 */
if (GRAPHICS_VER(i915) < 12) {
i915->params.enable_guc = 0;
return;
}
so all pre-Gen12 platforms will continue to have GuC/HuC disabled.
Thanks,
Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+
On 02/07/2021 16:06, Michal Wajdeczko wrote:
On 02.07.2021 10:13, Martin Peres wrote:
On 01/07/2021 21:24, Martin Peres wrote:
[...]
+ i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+ return;
+ }
+
+ /* Default: enable HuC authentication and GuC submission */
+ i915->params.enable_guc = ENABLE_GUC_LOAD_HUC |
ENABLE_GUC_SUBMISSION;
This seems to be in contradiction with the GuC submission plan which
states:
"Not enabled by default on any current platforms but can be enabled via
modparam enable_guc".
I don't believe any current platform gets this point where GuC
submission would be enabled by default. The first would be ADL-P which
isn't out yet.
Isn't that exactly what the line above does?
In case you missed this crucial part of the review. Please answer the
above question.
I guess there is some misunderstanding here, and I must admit I had
similar doubt, but if you look beyond patch diff and check function code
you will find that the very condition is:
/* Don't enable GuC/HuC on pre-Gen12 */
if (GRAPHICS_VER(i915) < 12) {
i915->params.enable_guc = 0;
return;
}
so all pre-Gen12 platforms will continue to have GuC/HuC disabled.
Thanks Michal, but then the problem is the other way: how can one enable
it on gen11?
I like what Daniele was going for here: separating the capability from
the user-requested value, but then it seems the patch stopped half way.
How about never touching the parameter, and having a AND between the two
values to get the effective enable_guc?
Right now, the code is really confusing :s
Thanks,
Martin
Thanks,
Michal
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/uapi: reject set_domain for discrete
On Thu, 1 Jul 2021 at 16:10, Matthew Auld wrote: > > The CPU domain should be static for discrete, and on DG1 we don't need > any flushing since everything is already coherent, so really all this > does is an object wait, for which we have an ioctl. Longer term the > desired caching should be an immutable creation time property for the > BO, which can be set with something like gem_create_ext. > > One other user is iris + userptr, which uses the set_domain to probe all > the pages to check if the GUP succeeds, however keeping the set_domain > around just for that seems rather scuffed. We could equally just submit > a dummy batch, which should hopefully be good enough, otherwise adding a > new creation time flag for userptr might be an option. Although longer > term we will also have vm_bind, which should also be a nice fit for > this, so adding a whole new flag is likely overkill. Kenneth, do you have a preference for the iris + userptr use case? Adding the flag shouldn't be much work, if you feel the dummy batch is too ugly. I don't mind either way. > > Suggested-by: Daniel Vetter > Signed-off-by: Matthew Auld > Cc: Thomas Hellström > Cc: Maarten Lankhorst > Cc: Jordan Justen > Cc: Kenneth Graunke > Cc: Jason Ekstrand > Cc: Daniel Vetter > Cc: Ramalingam C > --- > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c > b/drivers/gpu/drm/i915/gem/i915_gem_domain.c > index 43004bef55cb..b684a62bf3b0 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c > @@ -490,6 +490,9 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void > *data, > u32 write_domain = args->write_domain; > int err; > > + if (IS_DGFX(to_i915(dev))) > + return -ENODEV; > + > /* Only handle setting domains to types used by the CPU. */ > if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS) > return -EINVAL; > -- > 2.26.3 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/display/dsc: Set BPP in the kernel (rev5)
== Series Details ==
Series: drm/i915/display/dsc: Set BPP in the kernel (rev5)
URL : https://patchwork.freedesktop.org/series/91917/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_10302_full -> Patchwork_20519_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_20519_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_20519_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_20519_full:
### IGT changes ###
Possible regressions
* igt@debugfs_test@read_all_entries_display_off:
- shard-iclb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-iclb6/igt@debugfs_test@read_all_entries_display_off.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/shard-iclb3/igt@debugfs_test@read_all_entries_display_off.html
- shard-tglb: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-tglb3/igt@debugfs_test@read_all_entries_display_off.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/shard-tglb1/igt@debugfs_test@read_all_entries_display_off.html
* {igt@kms_dp_dsc@dsc-15bpp-compression-xrgb} (NEW):
- shard-tglb: NOTRUN -> [SKIP][5] +14 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/shard-tglb3/igt@kms_dp_...@dsc-15bpp-compression-xrgb.html
* {igt@kms_dp_dsc@dsc-22bpp-compression-xrgb} (NEW):
- shard-iclb: NOTRUN -> [SKIP][6] +14 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20519/shard-iclb2/igt@kms_dp_...@dsc-22bpp-compression-xrgb.html
### Piglit changes ###
Possible regressions
* spec@glsl-1.30@execution@tex-miplevel-selection texture(bias) 1d (NEW):
- pig-snb-2600: NOTRUN -> [FAIL][7]
[7]: None
New tests
-
New tests have been introduced between CI_DRM_10302_full and
Patchwork_20519_full:
### New IGT tests (21) ###
* igt@kms_dp_dsc@basic-dsc-enable:
- Statuses : 5 skip(s)
- Exec time: [0.0, 0.00] s
* igt@kms_dp_dsc@basic-dsc-enable@edp-1-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [1.49] s
* igt@kms_dp_dsc@basic-dsc-enable@edp-1-pipe-b:
- Statuses : 1 pass(s)
- Exec time: [1.14] s
* igt@kms_dp_dsc@basic-dsc-enable@edp-1-pipe-c:
- Statuses : 1 pass(s)
- Exec time: [1.15] s
* igt@kms_dp_dsc@basic-dsc-enable@edp-1-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [1.16] s
* igt@kms_dp_dsc@dsc-10bpp-compression-xrgb:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-11bpp-compression-xrgb:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-12bpp-compression-xrgb:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-13bpp-compression-xrgb:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-14bpp-compression-xrgb:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-15bpp-compression-xrgb:
- Statuses : 5 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-16bpp-compression-xrgb:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-17bpp-compression-xrgb:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-18bpp-compression-xrgb:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-19bpp-compression-xrgb:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-20bpp-compression-xrgb:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-21bpp-compression-xrgb:
- Statuses : 4 skip(s)
- Exec time: [0.0, 0.00] s
* igt@kms_dp_dsc@dsc-22bpp-compression-xrgb:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-23bpp-compression-xrgb:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-8bpp-compression-xrgb:
- Statuses : 6 skip(s)
- Exec time: [0.0] s
* igt@kms_dp_dsc@dsc-9bpp-compression-xrgb:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
### New Piglit tests (1) ###
* spec@glsl-1.30@execution@tex-miplevel-selection texture(bias) 1d:
- Statuses : 1 fail(s)
- Exec time: [7.31] s
Known issues
Here are the changes found in Patchwork_20519_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@drm_import_export@prime:
- shard-kbl: [PASS][8] -> [INCOMPLETE][9] ([i915#2895] /
[i915#2944])
[8]:
https://intel-gf
Re: [Intel-gfx] [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
On 7/2/21 6:18 AM, Will Deacon wrote:
On Fri, Jul 02, 2021 at 12:39:41PM +0100, Robin Murphy wrote:
On 2021-07-02 04:08, Guenter Roeck wrote:
On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
If a device is not behind an IOMMU, we look up the device node and set
up the restricted DMA when the restricted-dma-pool is presented.
Signed-off-by: Claire Chang
Tested-by: Stefano Stabellini
Tested-by: Will Deacon
With this patch in place, all sparc and sparc64 qemu emulations
fail to boot. Symptom is that the root file system is not found.
Reverting this patch fixes the problem. Bisect log is attached.
Ah, OF_ADDRESS depends on !SPARC, so of_dma_configure_id() is presumably
returning an unexpected -ENODEV from the of_dma_set_restricted_buffer()
stub. That should probably be returning 0 instead, since either way it's not
an error condition for it to simply do nothing.
Something like below?
Yes, that does the trick.
Will
--->8
From 4d9dcb9210c1f37435b6088284e04b6b36ee8c4d Mon Sep 17 00:00:00 2001
From: Will Deacon
Date: Fri, 2 Jul 2021 14:13:28 +0100
Subject: [PATCH] of: Return success from of_dma_set_restricted_buffer() when
!OF_ADDRESS
When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV
and breaks the boot for sparc[64] machines. Return 0 instead, since the
function is essentially a glorified NOP in this configuration.
Cc: Claire Chang
Cc: Konrad Rzeszutek Wilk
Reported-by: Guenter Roeck
Suggested-by: Robin Murphy
Link: https://lore.kernel.org/r/20210702030807.ga2685...@roeck-us.net
Signed-off-by: Will Deacon
Tested-by: Guenter Roeck
---
drivers/of/of_private.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 8fde97565d11..34dd548c5eac 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -173,7 +173,8 @@ static inline int of_dma_get_range(struct device_node *np,
static inline int of_dma_set_restricted_buffer(struct device *dev,
struct device_node *np)
{
- return -ENODEV;
+ /* Do nothing, successfully. */
+ return 0;
}
#endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/selftests: fix smatch warning in igt_check_blocks
== Series Details == Series: series starting with [1/2] drm/i915/selftests: fix smatch warning in igt_check_blocks URL : https://patchwork.freedesktop.org/series/92150/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10302_full -> Patchwork_20520_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20520_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20520_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20520_full: ### IGT changes ### Possible regressions * igt@gem_ctx_engines@execute-one: - shard-glk: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-glk8/igt@gem_ctx_engi...@execute-one.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-glk9/igt@gem_ctx_engi...@execute-one.html * igt@kms_draw_crc@draw-method-xrgb-mmap-cpu-ytiled: - shard-skl: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-skl5/igt@kms_draw_...@draw-method-xrgb-mmap-cpu-ytiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-skl8/igt@kms_draw_...@draw-method-xrgb-mmap-cpu-ytiled.html Known issues Here are the changes found in Patchwork_20520_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#1888] / [i915#3160]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-glk2/igt@gem_cre...@create-clear.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-glk8/igt@gem_cre...@create-clear.html * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][7] ([i915#3002]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-apl6/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@engines-cleanup: - shard-snb: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#1099]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-snb5/igt@gem_ctx_persiste...@engines-cleanup.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2846]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-glk2/igt@gem_exec_f...@basic-deadline.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-glk8/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-none@vecs0: - shard-apl: [PASS][11] -> [FAIL][12] ([i915#2842] / [i915#3468]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-apl7/igt@gem_exec_fair@basic-n...@vecs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-apl7/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-tglb6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-glk6/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gen9_exec_parse@bb-large: - shard-apl: NOTRUN -> [FAIL][17] ([i915#3296]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-apl3/igt@gen9_exec_pa...@bb-large.html * igt@i915_suspend@debugfs-reader: - shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#180]) +2 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-apl2/igt@i915_susp...@debugfs-reader.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-apl6/igt@i915_susp...@debugfs-reader.html * igt@i915_suspend@sysfs-reader: - shard-kbl: [PASS][20] -> [DMESG-WARN][21] ([i915#180]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-kbl6/igt@i915_susp...@sysfs-reader.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20520/shard-kbl4/igt@i915_susp...@sysfs-reader.html * igt@kms_async_flips@alternate-sync-async-flip: - shard-kbl: [PASS][22] -> [FAIL][23] ([i915#2521]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10302/shard-kbl1/igt@kms_async_fl...@alternate-sync-async-flip.html
Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+
On 02.07.2021 15:12, Martin Peres wrote:
> On 02/07/2021 16:06, Michal Wajdeczko wrote:
>>
>>
>> On 02.07.2021 10:13, Martin Peres wrote:
>>> On 01/07/2021 21:24, Martin Peres wrote:
>>> [...]
>
>>
>>> + i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
>>> + return;
>>> + }
>>> +
>>> + /* Default: enable HuC authentication and GuC submission */
>>> + i915->params.enable_guc = ENABLE_GUC_LOAD_HUC |
>>> ENABLE_GUC_SUBMISSION;
>>
>> This seems to be in contradiction with the GuC submission plan which
>> states:
>>
>> "Not enabled by default on any current platforms but can be
>> enabled via
>> modparam enable_guc".
>>
>
> I don't believe any current platform gets this point where GuC
> submission would be enabled by default. The first would be ADL-P which
> isn't out yet.
Isn't that exactly what the line above does?
>>>
>>> In case you missed this crucial part of the review. Please answer the
>>> above question.
>>
>> I guess there is some misunderstanding here, and I must admit I had
>> similar doubt, but if you look beyond patch diff and check function code
>> you will find that the very condition is:
>>
>> /* Don't enable GuC/HuC on pre-Gen12 */
>> if (GRAPHICS_VER(i915) < 12) {
>> i915->params.enable_guc = 0;
>> return;
>> }
>>
>> so all pre-Gen12 platforms will continue to have GuC/HuC disabled.
>
> Thanks Michal, but then the problem is the other way: how can one enable
> it on gen11?
this code here converts default GuC auto mode (enable_guc=-1) into per
platform desired (tested) GuC/HuC enables.
to override that default, you may still use enable_guc=1 to explicitly
enable GuC submission and since we also have this code:
+static bool __guc_submission_supported(struct intel_guc *guc)
+{
+ /* GuC submission is unavailable for pre-Gen11 */
+ return intel_guc_is_supported(guc) &&
+ INTEL_GEN(guc_to_gt(guc)->i915) >= 11;
+}
it should work on any Gen11+.
Michal
>
> I like what Daniele was going for here: separating the capability from
> the user-requested value, but then it seems the patch stopped half way.
> How about never touching the parameter, and having a AND between the two
> values to get the effective enable_guc?
>
> Right now, the code is really confusing :s
>
> Thanks,
> Martin
>
>>
>> Thanks,
>> Michal
>>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/uapi: reject set_domain for discrete
On 01/07/2021 16:10, Matthew Auld wrote: The CPU domain should be static for discrete, and on DG1 we don't need any flushing since everything is already coherent, so really all this Knowledge of the write combine buffer is assumed to be had by anyone involved? does is an object wait, for which we have an ioctl. Longer term the desired caching should be an immutable creation time property for the BO, which can be set with something like gem_create_ext. One other user is iris + userptr, which uses the set_domain to probe all the pages to check if the GUP succeeds, however keeping the set_domain around just for that seems rather scuffed. We could equally just submit a dummy batch, which should hopefully be good enough, otherwise adding a new creation time flag for userptr might be an option. Although longer term we will also have vm_bind, which should also be a nice fit for this, so adding a whole new flag is likely overkill. Execbuf sounds horrible. But it all reminds me of past work by Chris which is surprisingly hard to find in the archives. Patches like: commit 7706a433388016983052a27c0fd74a64b1897ae7 Author: Chris Wilson Date: Wed Nov 8 17:04:07 2017 + drm/i915/userptr: Probe existence of backing struct pages upon creation Jason Ekstrand requested a more efficient method than userptr+set-domain to determine if the userptr object was backed by a complete set of pages upon creation. To be more efficient than simply populating the userptr using get_user_pages() (as done by the call to set-domain or execbuf), we can walk the tree of vm_area_struct and check for gaps or vma not backed by struct page (VM_PFNMAP). The question is how to handle VM_MIXEDMAP which may be either struct page or pfn backed... commit 7ca21d3390eec23db99b8131ed18bc036efaba18 Author: Chris Wilson Date: Wed Nov 8 17:48:22 2017 + drm/i915/userptr: Add a flag to populate the userptr on creation Acquiring the backing struct pages for the userptr range is not free; the first client for userptr would insist on frequently creating userptr objects ahead of time and not use them. For that first client, deferring the cost of populating the userptr (calling get_user_pages()) to the actual execbuf was a substantial improvement. However, not all clients are the same, and most would like to validate that the userptr is valid and backed by struct pages upon creation, so offer a I915_USERPTR_POPULATE flag to do just that. Note that big difference between I915_USERPTR_POPULATE and the deferred scheme is that POPULATE is guaranteed to be synchronous, the result is known before the ioctl returns (and the handle exposed). However, due to system memory pressure, the object may be paged out before use, requiring them to be paged back in on execbuf (as may always happen). At least with the first one I think I was skeptical, since probing at point A makes a weak test versus userptr getting used at point B. Populate is kind of same really when user controls the backing store. At least these two arguments I think stand if we are trying to sell these flags as validation. But if the idea is limited to pure preload, with no guarantees that it keeps working by time of real use, then I guess it may be passable. Disclaimer that I haven't been following the story on why it is desirable to abandon set domain. Only judging from this series, mmap caching mode is implied from the object? Should set domain availability be driven by the object backing store instead of outright rejection? Regards, Tvrtko Suggested-by: Daniel Vetter Signed-off-by: Matthew Auld Cc: Thomas Hellström Cc: Maarten Lankhorst Cc: Jordan Justen Cc: Kenneth Graunke Cc: Jason Ekstrand Cc: Daniel Vetter Cc: Ramalingam C --- drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c b/drivers/gpu/drm/i915/gem/i915_gem_domain.c index 43004bef55cb..b684a62bf3b0 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c @@ -490,6 +490,9 @@ i915_gem_set_domain_ioctl(struct drm_device *dev, void *data, u32 write_domain = args->write_domain; int err; + if (IS_DGFX(to_i915(dev))) + return -ENODEV; + /* Only handle setting domains to types used by the CPU. */ if ((write_domain | read_domains) & I915_GEM_GPU_DOMAINS) return -EINVAL; ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 47/47] drm/i915/guc: Unblock GuC submission on Gen11+
On 02.07.2021 10:09, Martin Peres wrote:
> On 02/07/2021 10:29, Pekka Paalanen wrote:
>> On Thu, 1 Jul 2021 21:28:06 +0200
>> Daniel Vetter wrote:
>>
>>> On Thu, Jul 1, 2021 at 8:27 PM Martin Peres
>>> wrote:
On 01/07/2021 11:14, Pekka Paalanen wrote:
> On Wed, 30 Jun 2021 11:58:25 -0700
> John Harrison wrote:
>
>> On 6/30/2021 01:22, Martin Peres wrote:
>>> On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 8
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.h | 3 +--
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 14
+-
4 files changed, 19 insertions(+), 7 deletions(-)
>
> ...
>
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 7a69c3c027e9..61be0aa81492 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -34,8 +34,15 @@ static void uc_expand_default_options(struct
intel_uc *uc)
return;
}
- /* Default: enable HuC authentication only */
- i915->params.enable_guc = ENABLE_GUC_LOAD_HUC;
+ /* Intermediate platforms are HuC authentication only */
+ if (IS_DG1(i915) || IS_ALDERLAKE_S(i915)) {
+ drm_dbg(&i915->drm, "Disabling GuC only due to old
platform\n");
>>>
>>> This comment does not seem accurate, given that DG1 is barely
>>> out, and
>>> ADL is not out yet. How about:
>>>
>>> "Disabling GuC on untested platforms"?
>>>
>> Just because something is not in the shops yet does not mean it is
>> new.
>> Technology is always obsolete by the time it goes on sale.
>
> That is a very good reason to not use terminology like "new", "old",
> "current", "modern" etc. at all.
>
> End users like me definitely do not share your interpretation of
> "old".
Yep, old and new is relative. In the end, what matters is the
validation
effort, which is why I was proposing "untested platforms".
Also, remember that you are not writing these messages for Intel
engineers, but instead are writing for Linux *users*.
>>>
>>> It's drm_dbg. Users don't read this stuff, at least not users with no
>>> clue what the driver does and stuff like that.
>>
>> If I had a problem, I would read it, and I have no clue what anything
>> of that is.
>
> Exactly.
>
> This level of defense for what is clearly a bad *debug* message (at the
> very least, the grammar) makes no sense at all!
>
> I don't want to hear arguments like "Not my patch" from a developer
> literally sending the patch to the ML and who added his SoB to the
> patch, playing with words, or minimizing the problem of having such a
> message.
Agree that 'not my patch' is never a good excuse, but equally we can't
blame original patch author as patch was updated few times since then.
Maybe to avoid confusions and simplify reviews, we could split this
patch into two smaller: first one that really unblocks GuC submission on
all Gen11+ (see __guc_submission_supported) and second one that updates
defaults for Gen12+ (see uc_expand_default_options), as original patch
(from ~2019) evolved more than what title/commit message says.
Then we can fix all messaging and make sure it's clear and understood.
Thanks,
Michal
>
> All of the above are just clear signals for the community to get off
> your playground, which is frankly unacceptable. Your email address does
> not matter.
>
> In the spirit of collaboration, your response should have been "Good
> catch, how about or ?". This would not have wasted everyone's
> time in an attempt to just have it your way.
>
> My level of confidence in this GuC transition was already low, but you
> guys are working hard to shoot yourself in the foot. Trust should be
> earned!
>
> Martin
>
>>
>>
>> Thanks,
>> pq
>>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
Hi Nathan, On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote: > On 7/1/2021 12:40 AM, Will Deacon wrote: > > On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote: > > > On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote: > > > > On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote: > > > > > `BUG: unable to handle page fault for address: 003a8290` and > > > > > the fact it crashed at `_raw_spin_lock_irqsave` look like the memory > > > > > (maybe dev->dma_io_tlb_mem) was corrupted? > > > > > The dev->dma_io_tlb_mem should be set here > > > > > (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/pci/probe.c#n2528) > > > > > through device_initialize. > > > > > > > > I'm less sure about this. 'dma_io_tlb_mem' should be pointing at > > > > 'io_tlb_default_mem', which is a page-aligned allocation from memblock. > > > > The spinlock is at offset 0x24 in that structure, and looking at the > > > > register dump from the crash: > > > > > > > > Jun 29 18:28:42 hp-4300G kernel: RSP: 0018:adb4013db9e8 EFLAGS: > > > > 00010006 > > > > Jun 29 18:28:42 hp-4300G kernel: RAX: 003a8290 RBX: > > > > RCX: 8900572ad580 > > > > Jun 29 18:28:42 hp-4300G kernel: RDX: 89005653f024 RSI: > > > > 000c RDI: 1d17 > > > > Jun 29 18:28:42 hp-4300G kernel: RBP: 0a20d000 R08: > > > > 000c R09: > > > > Jun 29 18:28:42 hp-4300G kernel: R10: 0a20d000 R11: > > > > 89005653f000 R12: 0212 > > > > Jun 29 18:28:42 hp-4300G kernel: R13: 1000 R14: > > > > 0002 R15: 0020 > > > > Jun 29 18:28:42 hp-4300G kernel: FS: 7f1f8898ea40() > > > > GS:89005728() knlGS: > > > > Jun 29 18:28:42 hp-4300G kernel: CS: 0010 DS: ES: CR0: > > > > 80050033 > > > > Jun 29 18:28:42 hp-4300G kernel: CR2: 003a8290 CR3: > > > > 0001020d CR4: 00350ee0 > > > > Jun 29 18:28:42 hp-4300G kernel: Call Trace: > > > > Jun 29 18:28:42 hp-4300G kernel: _raw_spin_lock_irqsave+0x39/0x50 > > > > Jun 29 18:28:42 hp-4300G kernel: swiotlb_tbl_map_single+0x12b/0x4c0 > > > > > > > > Then that correlates with R11 holding the 'dma_io_tlb_mem' pointer and > > > > RDX pointing at the spinlock. Yet RAX is holding junk :/ > > > > > > > > I agree that enabling KASAN would be a good idea, but I also think we > > > > probably need to get some more information out of > > > > swiotlb_tbl_map_single() > > > > to see see what exactly is going wrong in there. > > > > > > I can certainly enable KASAN and if there is any debug print I can add > > > or dump anything, let me know! > > > > I bit the bullet and took v5.13 with swiotlb/for-linus-5.14 merged in, built > > x86 defconfig and ran it on my laptop. However, it seems to work fine! > > > > Please can you share your .config? > > Sure thing, it is attached. It is just Arch Linux's config run through > olddefconfig. The original is below in case you need to diff it. > > https://raw.githubusercontent.com/archlinux/svntogit-packages/9045405dc835527164f3034b3ceb9a67c7a53cd4/trunk/config > > If there is anything more that I can provide, please let me know. I eventually got this booting (for some reason it was causing LD to SEGV trying to link it for a while...) and sadly it works fine on my laptop. Hmm. Did you manage to try again with KASAN? It might also be worth taking the IOMMU out of the equation, since that interfaces differently with SWIOTLB and I couldn't figure out the code path from the log you provided. What happens if you boot with "amd_iommu=off swiotlb=force"? (although word of warning here: i915 dies horribly on my laptop if I pass swiotlb=force, even with the distro 5.10 kernel) Will ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
On Fri, Jul 02, 2021 at 12:39:41PM +0100, Robin Murphy wrote:
> On 2021-07-02 04:08, Guenter Roeck wrote:
> > On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote:
> > > If a device is not behind an IOMMU, we look up the device node and set
> > > up the restricted DMA when the restricted-dma-pool is presented.
> > >
> > > Signed-off-by: Claire Chang
> > > Tested-by: Stefano Stabellini
> > > Tested-by: Will Deacon
> >
> > With this patch in place, all sparc and sparc64 qemu emulations
> > fail to boot. Symptom is that the root file system is not found.
> > Reverting this patch fixes the problem. Bisect log is attached.
>
> Ah, OF_ADDRESS depends on !SPARC, so of_dma_configure_id() is presumably
> returning an unexpected -ENODEV from the of_dma_set_restricted_buffer()
> stub. That should probably be returning 0 instead, since either way it's not
> an error condition for it to simply do nothing.
Something like below?
Will
--->8
>From 4d9dcb9210c1f37435b6088284e04b6b36ee8c4d Mon Sep 17 00:00:00 2001
From: Will Deacon
Date: Fri, 2 Jul 2021 14:13:28 +0100
Subject: [PATCH] of: Return success from of_dma_set_restricted_buffer() when
!OF_ADDRESS
When CONFIG_OF_ADDRESS=n, of_dma_set_restricted_buffer() returns -ENODEV
and breaks the boot for sparc[64] machines. Return 0 instead, since the
function is essentially a glorified NOP in this configuration.
Cc: Claire Chang
Cc: Konrad Rzeszutek Wilk
Reported-by: Guenter Roeck
Suggested-by: Robin Murphy
Link: https://lore.kernel.org/r/20210702030807.ga2685...@roeck-us.net
Signed-off-by: Will Deacon
---
drivers/of/of_private.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/of/of_private.h b/drivers/of/of_private.h
index 8fde97565d11..34dd548c5eac 100644
--- a/drivers/of/of_private.h
+++ b/drivers/of/of_private.h
@@ -173,7 +173,8 @@ static inline int of_dma_get_range(struct device_node *np,
static inline int of_dma_set_restricted_buffer(struct device *dev,
struct device_node *np)
{
- return -ENODEV;
+ /* Do nothing, successfully. */
+ return 0;
}
#endif
--
2.32.0.93.g670b81a890-goog
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v15 12/12] of: Add plumbing for restricted DMA pool
On 2021-07-02 04:08, Guenter Roeck wrote: Hi, On Thu, Jun 24, 2021 at 11:55:26PM +0800, Claire Chang wrote: If a device is not behind an IOMMU, we look up the device node and set up the restricted DMA when the restricted-dma-pool is presented. Signed-off-by: Claire Chang Tested-by: Stefano Stabellini Tested-by: Will Deacon With this patch in place, all sparc and sparc64 qemu emulations fail to boot. Symptom is that the root file system is not found. Reverting this patch fixes the problem. Bisect log is attached. Ah, OF_ADDRESS depends on !SPARC, so of_dma_configure_id() is presumably returning an unexpected -ENODEV from the of_dma_set_restricted_buffer() stub. That should probably be returning 0 instead, since either way it's not an error condition for it to simply do nothing. Robin. Guenter --- # bad: [fb0ca446157a86b75502c1636b0d81e642fe6bf1] Add linux-next specific files for 20210701 # good: [62fb9874f5da54fdb243003b386128037319b219] Linux 5.13 git bisect start 'HEAD' 'v5.13' # bad: [f63c4fda987a19b1194cc45cb72fd5bf968d9d90] Merge remote-tracking branch 'rdma/for-next' git bisect bad f63c4fda987a19b1194cc45cb72fd5bf968d9d90 # good: [46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4] Merge remote-tracking branch 'ipsec/master' git bisect good 46bb5dd1d2a63e906e374e97dfd4a5e33934b1c4 # good: [43ba6969cfb8185353a7a6fc79070f13b9e3d6d3] Merge remote-tracking branch 'clk/clk-next' git bisect good 43ba6969cfb8185353a7a6fc79070f13b9e3d6d3 # good: [1ca5eddcf8dca1d6345471c6404e7364af0d7019] Merge remote-tracking branch 'fuse/for-next' git bisect good 1ca5eddcf8dca1d6345471c6404e7364af0d7019 # good: [8f6d7b3248705920187263a4e7147b0752ec7dcf] Merge remote-tracking branch 'pci/next' git bisect good 8f6d7b3248705920187263a4e7147b0752ec7dcf # good: [df1885a755784da3ef285f36d9230c1d090ef186] RDMA/rtrs_clt: Alloc less memory with write path fast memory registration git bisect good df1885a755784da3ef285f36d9230c1d090ef186 # good: [93d31efb58c8ad4a66bbedbc2d082df458c04e45] Merge remote-tracking branch 'cpufreq-arm/cpufreq/arm/linux-next' git bisect good 93d31efb58c8ad4a66bbedbc2d082df458c04e45 # good: [46308965ae6fdc7c25deb2e8c048510ae51bbe66] RDMA/irdma: Check contents of user-space irdma_mem_reg_req object git bisect good 46308965ae6fdc7c25deb2e8c048510ae51bbe66 # good: [6de7a1d006ea9db235492b288312838d6878385f] thermal/drivers/int340x/processor_thermal: Split enumeration and processing part git bisect good 6de7a1d006ea9db235492b288312838d6878385f # good: [081bec2577cda3d04f6559c60b6f4e2242853520] dt-bindings: of: Add restricted DMA pool git bisect good 081bec2577cda3d04f6559c60b6f4e2242853520 # good: [bf95ac0bcd69979af146852f6a617a60285ebbc1] Merge remote-tracking branch 'thermal/thermal/linux-next' git bisect good bf95ac0bcd69979af146852f6a617a60285ebbc1 # good: [3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc] RDMA/core: Always release restrack object git bisect good 3d8287544223a3d2f37981c1f9ffd94d0b5e9ffc # bad: [cff1f23fad6e0bd7d671acce0d15285c709f259c] Merge remote-tracking branch 'swiotlb/linux-next' git bisect bad cff1f23fad6e0bd7d671acce0d15285c709f259c # bad: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool git bisect bad b655006619b7bccd0dc1e055bd72de5d613e7b5c # first bad commit: [b655006619b7bccd0dc1e055bd72de5d613e7b5c] of: Add plumbing for restricted DMA pool ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v15 06/12] swiotlb: Use is_swiotlb_force_bounce for swiotlb data bouncing
On 2021-07-02 14:58, Will Deacon wrote: Hi Nathan, On Thu, Jul 01, 2021 at 12:52:20AM -0700, Nathan Chancellor wrote: On 7/1/2021 12:40 AM, Will Deacon wrote: On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote: On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote: On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote: `BUG: unable to handle page fault for address: 003a8290` and the fact it crashed at `_raw_spin_lock_irqsave` look like the memory (maybe dev->dma_io_tlb_mem) was corrupted? The dev->dma_io_tlb_mem should be set here (https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/pci/probe.c#n2528) through device_initialize. I'm less sure about this. 'dma_io_tlb_mem' should be pointing at 'io_tlb_default_mem', which is a page-aligned allocation from memblock. The spinlock is at offset 0x24 in that structure, and looking at the register dump from the crash: Jun 29 18:28:42 hp-4300G kernel: RSP: 0018:adb4013db9e8 EFLAGS: 00010006 Jun 29 18:28:42 hp-4300G kernel: RAX: 003a8290 RBX: RCX: 8900572ad580 Jun 29 18:28:42 hp-4300G kernel: RDX: 89005653f024 RSI: 000c RDI: 1d17 Jun 29 18:28:42 hp-4300G kernel: RBP: 0a20d000 R08: 000c R09: Jun 29 18:28:42 hp-4300G kernel: R10: 0a20d000 R11: 89005653f000 R12: 0212 Jun 29 18:28:42 hp-4300G kernel: R13: 1000 R14: 0002 R15: 0020 Jun 29 18:28:42 hp-4300G kernel: FS: 7f1f8898ea40() GS:89005728() knlGS: Jun 29 18:28:42 hp-4300G kernel: CS: 0010 DS: ES: CR0: 80050033 Jun 29 18:28:42 hp-4300G kernel: CR2: 003a8290 CR3: 0001020d CR4: 00350ee0 Jun 29 18:28:42 hp-4300G kernel: Call Trace: Jun 29 18:28:42 hp-4300G kernel: _raw_spin_lock_irqsave+0x39/0x50 Jun 29 18:28:42 hp-4300G kernel: swiotlb_tbl_map_single+0x12b/0x4c0 Then that correlates with R11 holding the 'dma_io_tlb_mem' pointer and RDX pointing at the spinlock. Yet RAX is holding junk :/ I agree that enabling KASAN would be a good idea, but I also think we probably need to get some more information out of swiotlb_tbl_map_single() to see see what exactly is going wrong in there. I can certainly enable KASAN and if there is any debug print I can add or dump anything, let me know! I bit the bullet and took v5.13 with swiotlb/for-linus-5.14 merged in, built x86 defconfig and ran it on my laptop. However, it seems to work fine! Please can you share your .config? Sure thing, it is attached. It is just Arch Linux's config run through olddefconfig. The original is below in case you need to diff it. https://raw.githubusercontent.com/archlinux/svntogit-packages/9045405dc835527164f3034b3ceb9a67c7a53cd4/trunk/config If there is anything more that I can provide, please let me know. I eventually got this booting (for some reason it was causing LD to SEGV trying to link it for a while...) and sadly it works fine on my laptop. Hmm. Did you manage to try again with KASAN? It might also be worth taking the IOMMU out of the equation, since that interfaces differently with SWIOTLB and I couldn't figure out the code path from the log you provided. What happens if you boot with "amd_iommu=off swiotlb=force"? Oh, now there's a thing... the chat from the IOMMU API in the boot log implies that the IOMMU *should* be in the picture - we see that default domains are IOMMU_DOMAIN_DMA default and the GPU :0c:00.0 was added to a group. That means dev->dma_ops should be set and DMA API calls should be going through iommu-dma, yet the callstack in the crash says we've gone straight from dma_map_page_attrs() to swiotlb_map(), implying the inline dma_direct_map_page() path. If dev->dma_ops didn't look right in the first place, it's perhaps less surprising that dev->dma_io_tlb_mem might be wild as well. It doesn't seem plausible that we should have a race between initialising the device and probing its driver, so maybe the whole dev pointer is getting trampled earlier in the callchain (or is fundamentally wrong to begin with, but from a quick skim of the amdgpu code it did look like adev->dev and adev->pdev are appropriately set early on by amdgpu_pci_probe()). (although word of warning here: i915 dies horribly on my laptop if I pass swiotlb=force, even with the distro 5.10 kernel) FWIW I'd imagine you probably need to massively increase the SWIOTLB buffer size to have hope of that working. Robin. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Restricted DMA (rev2)
== Series Details == Series: Restricted DMA (rev2) URL : https://patchwork.freedesktop.org/series/91883/ State : failure == Summary == Applying: swiotlb: Refactor swiotlb init functions Applying: swiotlb: Refactor swiotlb_create_debugfs Applying: swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used error: sha1 information is lacking or useless (kernel/dma/swiotlb.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 swiotlb: Set dev->dma_io_tlb_mem to the swiotlb pool used When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gem: Correct the locking and pin pattern for dma-buf
On Thu, Jul 1, 2021 at 4:24 PM Michael J. Ruhl wrote:
>
> From: Thomas Hellström
>
> If our exported dma-bufs are imported by another instance of our driver,
> that instance will typically have the imported dma-bufs locked during
> dma_buf_map_attachment(). But the exporter also locks the same reservation
> object in the map_dma_buf() callback, which leads to recursive locking.
>
> So taking the lock inside _pin_pages_unlocked() is incorrect.
>
> Additionally, the current pinning code path is contrary to the defined
> way that pinning should occur.
>
> Remove the explicit pin/unpin from the map/umap functions and move them
> to the attach/detach allowing correct locking to occur, and to match
> the static dma-buf drm_prime pattern.
>
> Add a live selftest to exercise both dynamic and non-dynamic
> exports.
>
> v2:
> - Extend the selftest with a fake dynamic importer.
> - Provide real pin and unpin callbacks to not abuse the interface.
> v3: (ruhl)
> - Remove the dynamic export support and move the pinning into the
> attach/detach path.
>
> Reported-by: Michael J. Ruhl
> Signed-off-by: Thomas Hellström
> Signed-off-by: Michael J. Ruhl
CI splat is because I got the locking rules wrong, I thought
->attach/detach are called under the dma_resv_lock, because when we
used the old dma_buf->lock those calls where protected by that lock
under the same critical section as adding/removing from the list. But
we changed that in
f45f57cce584 ("dma-buf: stop using the dmabuf->lock so much v2")
15fd552d186c ("dma-buf: change DMA-buf locking convention v3")
Because keeping dma_resv_lock over ->attach/detach would go boom on
all the ttm drivers, which pin/unpin the buffer in there. Iow we need
the unlocked version there, but also having this split up is a bit
awkward and might be good to patch up so that it's atomic again. Would
mean updating a bunch of drivers. Christian, any thoughts?
Mike, for now I'd just keep using the _unlocked variants and we should be fine.
-Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c| 46 ++--
> .../drm/i915/gem/selftests/i915_gem_dmabuf.c | 111 +-
> 2 files changed, 143 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index 616c3a2f1baf..00338c8d3739 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -12,6 +12,8 @@
> #include "i915_gem_object.h"
> #include "i915_scatterlist.h"
>
> +I915_SELFTEST_DECLARE(static bool force_different_devices;)
> +
> static struct drm_i915_gem_object *dma_buf_to_obj(struct dma_buf *buf)
> {
> return to_intel_bo(buf->priv);
> @@ -25,15 +27,11 @@ static struct sg_table *i915_gem_map_dma_buf(struct
> dma_buf_attachment *attachme
> struct scatterlist *src, *dst;
> int ret, i;
>
> - ret = i915_gem_object_pin_pages_unlocked(obj);
> - if (ret)
> - goto err;
> -
> /* Copy sg so that we make an independent mapping */
> st = kmalloc(sizeof(struct sg_table), GFP_KERNEL);
> if (st == NULL) {
> ret = -ENOMEM;
> - goto err_unpin_pages;
> + goto err;
> }
>
> ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
> @@ -58,8 +56,6 @@ static struct sg_table *i915_gem_map_dma_buf(struct
> dma_buf_attachment *attachme
> sg_free_table(st);
> err_free:
> kfree(st);
> -err_unpin_pages:
> - i915_gem_object_unpin_pages(obj);
> err:
> return ERR_PTR(ret);
> }
> @@ -68,13 +64,9 @@ static void i915_gem_unmap_dma_buf(struct
> dma_buf_attachment *attachment,
>struct sg_table *sg,
>enum dma_data_direction dir)
> {
> - struct drm_i915_gem_object *obj = dma_buf_to_obj(attachment->dmabuf);
> -
> dma_unmap_sgtable(attachment->dev, sg, dir, DMA_ATTR_SKIP_CPU_SYNC);
> sg_free_table(sg);
> kfree(sg);
> -
> - i915_gem_object_unpin_pages(obj);
> }
>
> static int i915_gem_dmabuf_vmap(struct dma_buf *dma_buf, struct dma_buf_map
> *map)
> @@ -168,7 +160,32 @@ static int i915_gem_end_cpu_access(struct dma_buf
> *dma_buf, enum dma_data_direct
> return err;
> }
>
> +/**
> + * i915_gem_dmabuf_attach - Do any extra attach work necessary
> + * @dmabuf: imported dma-buf
> + * @attach: new attach to do work on
> + *
> + */
> +static int i915_gem_dmabuf_attach(struct dma_buf *dmabuf,
> + struct dma_buf_attachment *attach)
> +{
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf);
> +
> + assert_object_held(obj);
> + return i915_gem_object_pin_pages(obj);
> +}
> +
> +static void i915_gem_dmabuf_detach(struct dma_buf *dmabuf,
> + struct dma_buf_attachment *attach)
> +{
> + struct drm_i915_gem_object *obj = dma_buf_to_obj(dmabuf
Re: [Intel-gfx] [PATCH v7 0/5] drm: address potential UAF bugs with drm_master ptrs
On Fri, Jul 02, 2021 at 12:53:53AM +0800, Desmond Cheong Zhi Xi wrote: > This patch series addresses potential use-after-free errors when > dereferencing pointers to struct drm_master. These were identified after one > such bug was caught by Syzbot in drm_getunique(): > https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803 > > The series is broken up into five patches: > > 1. Move a call to drm_is_current_master() out from a section locked by > &dev->mode_config.mutex in drm_mode_getconnector(). This patch does not apply > to stable. > > 2. Move a call to _drm_lease_held() out from the section locked by > &dev->mode_config.idr_mutex in __drm_mode_object_find(). > > 3. Implement a locked version of drm_is_current_master() function that's used > within drm_auth.c. > > 4. Serialize drm_file.master by introducing a new lock that's held whenever > the value of drm_file.master changes. > > 5. Identify areas in drm_lease.c where pointers to struct drm_master are > dereferenced, and ensure that the master pointers are not freed during use. > > Changes in v6 -> v7: > - Patch 2: > Modify code alignment as suggested by the intel-gfx CI. > > Update commit message based on the changes to patch 5. > > - Patch 4: > Add patch 4 to the series. This patch adds a new lock to serialize > drm_file.master, in response to the lockdep splat by the intel-gfx CI. > > - Patch 5: > Move kerneldoc comment about protecting drm_file.master with > drm_device.master_mutex into patch 4. > > Update drm_file_get_master to use the new drm_file.master_lock instead of > drm_device.master_mutex, in response to the lockdep splat by the intel-gfx CI. So there's another one now because master->leases is protected by the mode_config.idr_mutex, and that's a bit awkward to untangle. Also I'm really surprised that there was now lockdep through the atomic code anywhere. The reason seems to be that somehow CI reboot first before it managed to run any of the kms_atomic tests, and we can only hit this when we go through the atomic kms ioctl, the legacy kms ioctl don't have that specific issue. Anyway I think this approach doesn't look too workable, and we need something new. But first things first: Are you still on board working on this? You started with a simple patch to fix a UAF bug, now we're deep into reworking tricky locking ... If you feel like you want out I'm totally fine with that. Anyway, I think we need to split drm_device->master_mutex up into two parts: - One part that protects the actual access/changes, which I think for simplicity we'll just leave as the current lock. That lock is a very inner lock, since for the drm_lease.c stuff it has to nest within mode_config.idr_mutex even. - Now the issue with checking master status/leases/whatever as an innermost lock is that you can race, it's a classic time of check vs time of use race: By the time we actually use the thing we validate we'er allowed to use, we might now have access anymore. There's two reasons for that: * DROPMASTER ioctl could remove the master rights, which removes access rights also for all leases * REVOKE_LEASE ioctl can do the same but only for a specific lease This is the thing we're trying to protect against in fbcon code, but that's very spotty protection because all the ioctls by other users aren't actually protected against this. So I think for this we need some kind of big reader lock. Now for the implementation, there's a few things: - I think best option for this big reader lock would be to just use srcu. We only need to flush out all current readers when we drop master or revoke a lease, so synchronize_srcu is perfectly good enough for this purpose. - The fbdev code would switch over to srcu in drm_master_internal_acquire() and drm_master_internal_release(). Ofc within drm_master_internal_acquire we'd still need to check master status with the normal master_mutex. - While we revamp all this we should fix the ioctl checks in drm_ioctl.c. Just noticed that drm_ioctl_permit() could and should be unexported, last user was removed. Within drm_ioctl_kernel we'd then replace the check for drm_is_current_master with the drm_master_internal_acquire/release. - This alone does nothing, we still need to make sure that dropmaster and revoke_lease ioctl flush out all other access before they return to userspace. We can't just call synchronize_srcu because due to the ioctl code in drm_ioctl_kernel we're in that sruc section, we'd need to add a DRM_MASTER_FLUSH ioctl flag which we'd check only when DRM_MASTER is set, and use to call synchronize_srcu. Maybe wrap that in a drm_master_flush or so, or perhaps a drm_master_internal_release_flush. - Also maybe we should drop the _internal_ from that name. Feels a bit wrong when we're also going to use this in the ioctl handler. Thoughts? Totally silly and overkill? Cheers, Daniel > Changes in v5 -> v6: > - Pa
Re: [Intel-gfx] [PATCH v4 0/2] drm/i915: IRQ fixes
On Thu, Jul 01, 2021 at 10:58:31AM +0200, Thomas Zimmermann wrote: > Fix a bug in the usage of IRQs and cleanup references to the DRM > IRQ midlayer. > > Preferably this patchset would be merged through drm-misc-next. > > v4: > * switch IRQ code to intel_synchronize_irq() (Daniel) > v3: > * also use intel_synchronize_hardirq() from other callsite > v2: > * split patch > * also fix comment > * add intel_synchronize_hardirq() (Ville) > * update Fixes tag (Daniel) > > Thomas Zimmermann (2): > drm/i915: Use the correct IRQ during resume > drm/i915: Drop all references to DRM IRQ midlayer Both pushed to drm-intel-gt-next, thanks for your patches. -Daniel > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- > drivers/gpu/drm/i915/gt/intel_ring_submission.c | 2 +- > drivers/gpu/drm/i915/i915_drv.c | 1 - > drivers/gpu/drm/i915/i915_irq.c | 5 - > 4 files changed, 2 insertions(+), 8 deletions(-) > > > base-commit: 67f5a18128770817e4218a9e496d2bf5047c51e8 > -- > 2.32.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915/uapi: reject caching ioctls for discrete
On Thu, Jul 01, 2021 at 03:36:49PM +0100, Matthew Auld wrote:
> It's a noop on DG1, and in the future when need to support other devices
> which let us control the coherency, then it should be an immutable
> creation time property for the BO.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> Cc: Maarten Lankhorst
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Daniel Vetter
> Cc: Ramalingam C
For this and the next can you pls add kerneldoc for the uapi structs and
then add a note there that on dgfx they're disallowed? Same for the next
one.
At least I'd like if we can document uapi here as we go, so that we have
something to point people to when they as "what has changed? what should I
do in my userspace driver?".
Also please make sure these two have acks from mesa devs before you land
them.
Thanks, Daniel
> ---
> drivers/gpu/drm/i915/gem/i915_gem_domain.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> index 7d1400b13429..43004bef55cb 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
> @@ -268,6 +268,9 @@ int i915_gem_get_caching_ioctl(struct drm_device *dev,
> void *data,
> struct drm_i915_gem_object *obj;
> int err = 0;
>
> + if (IS_DGFX(to_i915(dev)))
> + return -ENODEV;
> +
> rcu_read_lock();
> obj = i915_gem_object_lookup_rcu(file, args->handle);
> if (!obj) {
> @@ -303,6 +306,9 @@ int i915_gem_set_caching_ioctl(struct drm_device *dev,
> void *data,
> enum i915_cache_level level;
> int ret = 0;
>
> + if (IS_DGFX(i915))
> + return -ENODEV;
> +
> switch (args->caching) {
> case I915_CACHING_NONE:
> level = I915_CACHE_NONE;
> --
> 2.26.3
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/uapi: reject set_domain for discrete
On Fri, Jul 02, 2021 at 03:31:08PM +0100, Tvrtko Ursulin wrote: > > On 01/07/2021 16:10, Matthew Auld wrote: > > The CPU domain should be static for discrete, and on DG1 we don't need > > any flushing since everything is already coherent, so really all this > > Knowledge of the write combine buffer is assumed to be had by anyone involved? > > > does is an object wait, for which we have an ioctl. Longer term the > > desired caching should be an immutable creation time property for the > > BO, which can be set with something like gem_create_ext. > > > > One other user is iris + userptr, which uses the set_domain to probe all > > the pages to check if the GUP succeeds, however keeping the set_domain > > around just for that seems rather scuffed. We could equally just submit > > a dummy batch, which should hopefully be good enough, otherwise adding a > > new creation time flag for userptr might be an option. Although longer > > term we will also have vm_bind, which should also be a nice fit for > > this, so adding a whole new flag is likely overkill. > > Execbuf sounds horrible. But it all reminds me of past work by Chris which is > surprisingly hard to find in the archives. Patches like: > > commit 7706a433388016983052a27c0fd74a64b1897ae7 > Author: Chris Wilson > Date: Wed Nov 8 17:04:07 2017 + > > drm/i915/userptr: Probe existence of backing struct pages upon creation > Jason Ekstrand requested a more efficient method than userptr+set-domain > to determine if the userptr object was backed by a complete set of pages > upon creation. To be more efficient than simply populating the userptr > using get_user_pages() (as done by the call to set-domain or execbuf), > we can walk the tree of vm_area_struct and check for gaps or vma not > backed by struct page (VM_PFNMAP). The question is how to handle > VM_MIXEDMAP which may be either struct page or pfn backed... > > commit 7ca21d3390eec23db99b8131ed18bc036efaba18 > Author: Chris Wilson > Date: Wed Nov 8 17:48:22 2017 + > > drm/i915/userptr: Add a flag to populate the userptr on creation > Acquiring the backing struct pages for the userptr range is not free; > the first client for userptr would insist on frequently creating userptr > objects ahead of time and not use them. For that first client, deferring > the cost of populating the userptr (calling get_user_pages()) to the > actual execbuf was a substantial improvement. However, not all clients > are the same, and most would like to validate that the userptr is valid > and backed by struct pages upon creation, so offer a > I915_USERPTR_POPULATE flag to do just that. > Note that big difference between I915_USERPTR_POPULATE and the deferred > scheme is that POPULATE is guaranteed to be synchronous, the result is > known before the ioctl returns (and the handle exposed). However, due to > system memory pressure, the object may be paged out before use, > requiring them to be paged back in on execbuf (as may always happen). > > At least with the first one I think I was skeptical, since probing at > point A makes a weak test versus userptr getting used at point B. > Populate is kind of same really when user controls the backing store. At > least these two arguments I think stand if we are trying to sell these > flags as validation. But if the idea is limited to pure preload, with no > guarantees that it keeps working by time of real use, then I guess it > may be passable. Well we've thrown this out again because there was no userspace. But if this is requested by mesa, then the _PROBE flag should be entirely sufficient. Since I don't want to hold up dg1 pciids on this it'd be nice if we could just go ahead with the dummy batch, if Ken/Jordan don't object - iris is the only umd that needs this. > Disclaimer that I haven't been following the story on why it is > desirable to abandon set domain. Only judging from this series, mmap > caching mode is implied from the object? Should set domain availability > be driven by the object backing store instead of outright rejection? In theory yes. In practice umd have allowed and all the api are now allocating objects with static properties, and the only reason we ever call set_domain is due to slightly outdated buffer caching schemes dating back to og libdrm from 12+ years ago. The other practical reason is that clflush is simply the slowest way to upload data of all the ones we have :-) So even when this comes back I don't expect this ioctl will come back. > > Regards, > > Tvrtko > > Suggested-by: Daniel Vetter > > Signed-off-by: Matthew Auld > > Cc: Thomas Hellström > > Cc: Maarten Lankhorst > > Cc: Jordan Justen > > Cc: Kenneth Graunke > > Cc: Jason Ekstrand > > Cc: Daniel Vetter > > Cc: Ramalingam C > > --- > > drivers/gpu/drm/i915/gem/i915_gem_domain.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gem/i9
Re: [Intel-gfx] [PATCH v5 0/2] drm/i915: IRQ fixes
On Thu, Jul 01, 2021 at 07:36:16PM +0200, Thomas Zimmermann wrote: > Fix a bug in the usage of IRQs and cleanup references to the DRM > IRQ midlayer. > > Preferably this patchset would be merged through drm-misc-next. > > v5: > * go back to _hardirq() after CI tests reported atomic > context in PCI probe; add rsp comment > v4: > * switch IRQ code to intel_synchronize_irq() (Daniel) > v3: > * also use intel_synchronize_hardirq() from other callsite > v2: > * split patch > * also fix comment > * add intel_synchronize_hardirq() (Ville) > * update Fixes tag (Daniel) Ok now I actually pushed the right patch set. -Daniel > > Thomas Zimmermann (2): > drm/i915: Use the correct IRQ during resume > drm/i915: Drop all references to DRM IRQ midlayer > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +- > drivers/gpu/drm/i915/gt/intel_ring_submission.c | 7 +-- > drivers/gpu/drm/i915/i915_drv.c | 1 - > drivers/gpu/drm/i915/i915_irq.c | 10 +- > drivers/gpu/drm/i915/i915_irq.h | 1 + > 5 files changed, 12 insertions(+), 9 deletions(-) > > > base-commit: 67f5a18128770817e4218a9e496d2bf5047c51e8 > prerequisite-patch-id: c2b2f08f0eccc9f5df0c0da49fa1d36267deb11d > prerequisite-patch-id: c67e5d886a47b7d0266d81100837557fda34cb24 > prerequisite-patch-id: 0cca17365e65370fa95d193ed2f1c88917ee1aef > prerequisite-patch-id: 12b9894350a0b56579d29542943465ef5134751c > prerequisite-patch-id: 3e1c37d3425f4820fe36ea3da57c65e166fe0ee5 > prerequisite-patch-id: 1017c860a0bf95ce370d82b8db1745f5548fb321 > prerequisite-patch-id: dcc022baab7c172978de9809702c2f4f54323047 > prerequisite-patch-id: 0d05ee247042b43d5ab8f3af216e708a8e09bee8 > prerequisite-patch-id: 110c411161bed6072c32185940fcd052d0bdb09a > prerequisite-patch-id: d2d1aeccffdfadf2b951487b8605f59c795d84cf > prerequisite-patch-id: 85fe31e27ca13adc0d1bcc7c19b1ce238a77ee6a > prerequisite-patch-id: c61fdacbe035ba5c17f1ff393bc9087f16aaea7b > prerequisite-patch-id: c4821af5dbba4d121769f1da85d91fbb53020ec0 > prerequisite-patch-id: 0b20ef3302abfe6dc123dbc54b9dd087865f935b > prerequisite-patch-id: d34eb96cbbdeb91870ace4250ea75920b1653dc2 > prerequisite-patch-id: 7f64fce347d15232134d7636ca7a8d9f5bf1a3a0 > prerequisite-patch-id: c83be7a285eb6682cdae0df401ab5d4c208f036b > prerequisite-patch-id: eb1a44d2eb2685cea154dd3f17f5f463dfafd39a > prerequisite-patch-id: 92a8c37dae4b8394fd6702f4af58ac7815ac3069 > prerequisite-patch-id: f0237988fe4ae6eba143432d1ace8beb52d935f8 > prerequisite-patch-id: bcf4d29437ed7cb78225dec4c99249eb40c18302 > prerequisite-patch-id: 6407b4c7f1b80af8d329d5f796b30da11959e936 > prerequisite-patch-id: 4a69e6e49d691b555f0e0874d638cd204dcb0c48 > prerequisite-patch-id: be09cfa8a67dd435a25103b85bd4b1649c5190a3 > prerequisite-patch-id: 813ecc9f94251c3d669155faf64c0c9e6a458393 > prerequisite-patch-id: beb2b5000a1682cbd74a7e2ab1566fcae5bccbf0 > prerequisite-patch-id: 754c8878611864475a0b75fd49ff38e71a21c795 > prerequisite-patch-id: d7d4bac3c19f94ba9593143b3c147d83d82cb71f > prerequisite-patch-id: 983d1efbe060743f5951e474961fa431d886d757 > prerequisite-patch-id: 3c78b20c3b9315cd39e0ae9ea1510c6121bf9ca9 > -- > 2.32.0 > -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Improve debug Kconfig texts a bit
We're not consistently recommending these for developers only. I stumbled over this due to DRM_I915_LOW_LEVEL_TRACEPOINTS, which was added in commit 354d036fcf70654cff2e2cbdda54a835d219b9d2 Author: Tvrtko Ursulin Date: Tue Feb 21 11:01:42 2017 + drm/i915/tracepoints: Add request submit and execute tracepoints to "alleviate the performance impact concerns." Which is nonsense. Tvrtko and Joonas pointed out on irc that the real (but undocumented reason) was stable abi concerns for tracepoints, see https://lwn.net/Articles/705270/ and the specific change that was blocked around tracepoints: https://lwn.net/Articles/442113/ Anyway to make it a notch clearer why we have this Kconfig option consistly add the "Recommended for driver developers only." to it and all the other debug options we have. Cc: Tvrtko Ursulin Cc: Joonas Lahtinen Cc: Matthew Brost Signed-off-by: Daniel Vetter --- drivers/gpu/drm/i915/Kconfig.debug | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/i915/Kconfig.debug b/drivers/gpu/drm/i915/Kconfig.debug index 2ca88072d30f..f27c0b5873f7 100644 --- a/drivers/gpu/drm/i915/Kconfig.debug +++ b/drivers/gpu/drm/i915/Kconfig.debug @@ -215,6 +215,8 @@ config DRM_I915_LOW_LEVEL_TRACEPOINTS This provides the ability to precisely monitor engine utilisation and also analyze the request dependency resolving timeline. + Recommended for driver developers only. + If in doubt, say "N". config DRM_I915_DEBUG_VBLANK_EVADE @@ -228,6 +230,8 @@ config DRM_I915_DEBUG_VBLANK_EVADE is exceeded, even if there isn't an actual risk of missing the vblank. + Recommended for driver developers only. + If in doubt, say "N". config DRM_I915_DEBUG_RUNTIME_PM @@ -240,4 +244,6 @@ config DRM_I915_DEBUG_RUNTIME_PM runtime PM functionality. This may introduce overhead during driver loading, suspend and resume operations. + Recommended for driver developers only. + If in doubt, say "N" -- 2.32.0.rc2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/i915/fbc: Rewrite the FBC tiling check a bit
From: Ville Syrjälä
Write the tiling check in a nicer form. No functional
changes due to Y-tile scanout being a gen9+ feature.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 82effb64a3b9..85cfb0da8576 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -675,11 +675,9 @@ static bool tiling_is_valid(struct drm_i915_private
*dev_priv,
{
switch (modifier) {
case DRM_FORMAT_MOD_LINEAR:
- if (DISPLAY_VER(dev_priv) >= 9)
- return true;
- return false;
- case I915_FORMAT_MOD_X_TILED:
case I915_FORMAT_MOD_Y_TILED:
+ return DISPLAY_VER(dev_priv) >= 9;
+ case I915_FORMAT_MOD_X_TILED:
return true;
default:
return false;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] drm/i915/fbc: Rework CFB stride/size calculations
From: Ville Syrjälä The way we calculate the CFB stride/size is kind of a mess, and I'm not sure if we're even allocating enough stolen memory always. Let's make it all more straightforward, and add some new related workarounds as well. Ville Syrjälä (8): drm/i915/fbc: Rewrite the FBC tiling check a bit drm/i915/fbc: Extract intel_fbc_update() drm/i915/fbc: Move the "recompress on activate" to a central place drm/i915/fbc: Polish the skl+ FBC stride override handling drm/i915/fbc: Rework cfb stride/size calculations drm/i915/fbc: Align FBC segments to 512B on glk+ drm/i915/fbc: Implement Wa_16011863758 for icl+ drm/i915/fbc: Allow higher compression limits on FBC1 drivers/gpu/drm/i915/display/intel_display.c | 5 +- drivers/gpu/drm/i915/display/intel_fbc.c | 242 --- drivers/gpu/drm/i915/display/intel_fbc.h | 2 +- drivers/gpu/drm/i915/i915_drv.h | 6 +- drivers/gpu/drm/i915/i915_reg.h | 9 +- 5 files changed, 168 insertions(+), 96 deletions(-) -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/8] drm/i915/fbc: Extract intel_fbc_update()
From: Ville Syrjälä
Pull the fbc enable vs. disable stuff into a small helper so
we don't have to have it pollute the higher level modeset code.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 5 +---
drivers/gpu/drm/i915/display/intel_fbc.c | 26 ++--
drivers/gpu/drm/i915/display/intel_fbc.h | 2 +-
3 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 026c28c612f0..ab395d61963c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10252,10 +10252,7 @@ static void intel_update_crtc(struct
intel_atomic_state *state,
intel_encoders_update_pipe(state, crtc);
}
- if (new_crtc_state->update_pipe && !new_crtc_state->enable_fbc)
- intel_fbc_disable(crtc);
- else
- intel_fbc_enable(state, crtc);
+ intel_fbc_update(state, crtc);
/* Perform vblank evasion around commit operation */
intel_pipe_update_start(new_crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 85cfb0da8576..8b721c8cdd6c 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -1244,8 +1244,8 @@ void intel_fbc_choose_crtc(struct drm_i915_private
*dev_priv,
* intel_fbc_enable multiple times for the same pipe without an
* intel_fbc_disable in the middle, as long as it is deactivated.
*/
-void intel_fbc_enable(struct intel_atomic_state *state,
- struct intel_crtc *crtc)
+static void intel_fbc_enable(struct intel_atomic_state *state,
+struct intel_crtc *crtc)
{
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
struct intel_plane *plane = to_intel_plane(crtc->base.primary);
@@ -1320,6 +1320,28 @@ void intel_fbc_disable(struct intel_crtc *crtc)
mutex_unlock(&fbc->lock);
}
+/**
+ * intel_fbc_update: enable/disable FBC on the CRTC
+ * @state: atomic state
+ * @crtc: the CRTC
+ *
+ * This function checks if the given CRTC was chosen for FBC, then enables it
if
+ * possible. Notice that it doesn't activate FBC. It is valid to call
+ * intel_fbc_update multiple times for the same pipe without an
+ * intel_fbc_disable in the middle.
+ */
+void intel_fbc_update(struct intel_atomic_state *state,
+ struct intel_crtc *crtc)
+{
+ const struct intel_crtc_state *crtc_state =
+ intel_atomic_get_new_crtc_state(state, crtc);
+
+ if (crtc_state->update_pipe && !crtc_state->enable_fbc)
+ intel_fbc_disable(crtc);
+ else
+ intel_fbc_enable(state, crtc);
+}
+
/**
* intel_fbc_global_disable - globally disable FBC
* @dev_priv: i915 device instance
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.h
b/drivers/gpu/drm/i915/display/intel_fbc.h
index 6dc1edefe81b..b97d908738e6 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.h
+++ b/drivers/gpu/drm/i915/display/intel_fbc.h
@@ -24,7 +24,7 @@ bool intel_fbc_pre_update(struct intel_atomic_state *state,
void intel_fbc_post_update(struct intel_atomic_state *state,
struct intel_crtc *crtc);
void intel_fbc_init(struct drm_i915_private *dev_priv);
-void intel_fbc_enable(struct intel_atomic_state *state,
+void intel_fbc_update(struct intel_atomic_state *state,
struct intel_crtc *crtc);
void intel_fbc_disable(struct intel_crtc *crtc);
void intel_fbc_global_disable(struct drm_i915_private *dev_priv);
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/i915/fbc: Move the "recompress on activate" to a central place
From: Ville Syrjälä
On ILK+ we current do a nuke right after activating FBC. If my
memory isn't playing tricks on me this is actially required if
FBC didn't stay disabled for a full frame. In that case the
deactivate+reactivate may not invalidate the cfb. I'd have to
double chekc to be sure though.
So let's keep the nuke, and just extend it backwards to cover
all the platforms by doing it a bit higher up.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 8b721c8cdd6c..c9cde96f330b 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -232,16 +232,16 @@ static void i965_fbc_recompress(struct drm_i915_private
*dev_priv)
/* This function forces a CFB recompression through the nuke operation. */
static void snb_fbc_recompress(struct drm_i915_private *dev_priv)
{
- struct intel_fbc *fbc = &dev_priv->fbc;
-
- trace_intel_fbc_nuke(fbc->crtc);
-
intel_de_write(dev_priv, MSG_FBC_REND_STATE, FBC_REND_NUKE);
intel_de_posting_read(dev_priv, MSG_FBC_REND_STATE);
}
static void intel_fbc_recompress(struct drm_i915_private *dev_priv)
{
+ struct intel_fbc *fbc = &dev_priv->fbc;
+
+ trace_intel_fbc_nuke(fbc->crtc);
+
if (DISPLAY_VER(dev_priv) >= 6)
snb_fbc_recompress(dev_priv);
else if (DISPLAY_VER(dev_priv) >= 4)
@@ -280,8 +280,6 @@ static void ilk_fbc_activate(struct drm_i915_private
*dev_priv)
params->fence_y_offset);
/* enable it... */
intel_de_write(dev_priv, ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
-
- intel_fbc_recompress(dev_priv);
}
static void ilk_fbc_deactivate(struct drm_i915_private *dev_priv)
@@ -339,8 +337,6 @@ static void gen7_fbc_activate(struct drm_i915_private
*dev_priv)
dpfc_ctl |= FBC_CTL_FALSE_COLOR;
intel_de_write(dev_priv, ILK_DPFC_CONTROL, dpfc_ctl | DPFC_CTL_EN);
-
- intel_fbc_recompress(dev_priv);
}
static bool intel_fbc_hw_is_active(struct drm_i915_private *dev_priv)
@@ -402,6 +398,12 @@ bool intel_fbc_is_active(struct drm_i915_private *dev_priv)
return dev_priv->fbc.active;
}
+static void intel_fbc_activate(struct drm_i915_private *dev_priv)
+{
+ intel_fbc_hw_activate(dev_priv);
+ intel_fbc_recompress(dev_priv);
+}
+
static void intel_fbc_deactivate(struct drm_i915_private *dev_priv,
const char *reason)
{
@@ -1088,7 +1090,7 @@ static void __intel_fbc_post_update(struct intel_crtc
*crtc)
return;
if (!fbc->busy_bits)
- intel_fbc_hw_activate(dev_priv);
+ intel_fbc_activate(dev_priv);
else
intel_fbc_deactivate(dev_priv, "frontbuffer write");
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/8] drm/i915/fbc: Polish the skl+ FBC stride override handling
From: Ville Syrjälä
Polish the FBC stride override stuff:
- just call it override_cfb_stride since it'll be used on
more gens later
- Use REG_BIT() & co. for the registers and give everything
CHICKEN_ prefix since glk+ will have a different register
for this
- Use intel_de_rmw() for the RMW
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 27
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
drivers/gpu/drm/i915/i915_reg.h | 5 +++--
3 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index c9cde96f330b..f5cbbc53837c 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -306,14 +306,15 @@ static void gen7_fbc_activate(struct drm_i915_private
*dev_priv)
/* Display WA #0529: skl, kbl, bxt. */
if (DISPLAY_VER(dev_priv) == 9) {
- u32 val = intel_de_read(dev_priv, CHICKEN_MISC_4);
+ u32 val = 0;
- val &= ~(FBC_STRIDE_OVERRIDE | FBC_STRIDE_MASK);
+ if (params->override_cfb_stride)
+ val |= CHICKEN_FBC_STRIDE_OVERRIDE |
+ CHICKEN_FBC_STRIDE(params->override_cfb_stride);
- if (params->gen9_wa_cfb_stride)
- val |= FBC_STRIDE_OVERRIDE | params->gen9_wa_cfb_stride;
-
- intel_de_write(dev_priv, CHICKEN_MISC_4, val);
+ intel_de_rmw(dev_priv, CHICKEN_MISC_4,
+CHICKEN_FBC_STRIDE_OVERRIDE |
+CHICKEN_FBC_STRIDE_MASK, val);
}
dpfc_ctl = 0;
@@ -749,7 +750,7 @@ static bool intel_fbc_cfb_size_changed(struct
drm_i915_private *dev_priv)
fbc->compressed_fb.size * fbc->limit;
}
-static u16 intel_fbc_gen9_wa_cfb_stride(struct drm_i915_private *dev_priv)
+static u16 intel_fbc_override_cfb_stride(struct drm_i915_private *dev_priv)
{
struct intel_fbc *fbc = &dev_priv->fbc;
struct intel_fbc_state_cache *cache = &fbc->state_cache;
@@ -761,11 +762,11 @@ static u16 intel_fbc_gen9_wa_cfb_stride(struct
drm_i915_private *dev_priv)
return 0;
}
-static bool intel_fbc_gen9_wa_cfb_stride_changed(struct drm_i915_private
*dev_priv)
+static bool intel_fbc_override_cfb_stride_changed(struct drm_i915_private
*dev_priv)
{
struct intel_fbc *fbc = &dev_priv->fbc;
- return fbc->params.gen9_wa_cfb_stride !=
intel_fbc_gen9_wa_cfb_stride(dev_priv);
+ return fbc->params.override_cfb_stride !=
intel_fbc_override_cfb_stride(dev_priv);
}
static bool intel_fbc_can_enable(struct drm_i915_private *dev_priv)
@@ -950,7 +951,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc
*crtc,
params->cfb_size = intel_fbc_calculate_cfb_size(dev_priv, cache);
- params->gen9_wa_cfb_stride = cache->gen9_wa_cfb_stride;
+ params->override_cfb_stride = cache->override_cfb_stride;
params->plane_visible = cache->plane.visible;
}
@@ -984,7 +985,7 @@ static bool intel_fbc_can_flip_nuke(const struct
intel_crtc_state *crtc_state)
if (params->cfb_size != intel_fbc_calculate_cfb_size(dev_priv, cache))
return false;
- if (params->gen9_wa_cfb_stride != cache->gen9_wa_cfb_stride)
+ if (params->override_cfb_stride != cache->override_cfb_stride)
return false;
return true;
@@ -1266,7 +1267,7 @@ static void intel_fbc_enable(struct intel_atomic_state
*state,
if (fbc->crtc) {
if (fbc->crtc != crtc ||
(!intel_fbc_cfb_size_changed(dev_priv) &&
-!intel_fbc_gen9_wa_cfb_stride_changed(dev_priv)))
+!intel_fbc_override_cfb_stride_changed(dev_priv)))
goto out;
__intel_fbc_disable(dev_priv);
@@ -1288,7 +1289,7 @@ static void intel_fbc_enable(struct intel_atomic_state
*state,
goto out;
}
- cache->gen9_wa_cfb_stride = intel_fbc_gen9_wa_cfb_stride(dev_priv);
+ cache->override_cfb_stride = intel_fbc_override_cfb_stride(dev_priv);
drm_dbg_kms(&dev_priv->drm, "Enabling FBC on pipe %c\n",
pipe_name(crtc->pipe));
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6dff4ca01241..91a2d2425fd3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -401,7 +401,7 @@ struct intel_fbc {
} fb;
unsigned int fence_y_offset;
- u16 gen9_wa_cfb_stride;
+ u16 override_cfb_stride;
u16 interval;
s8 fence_id;
bool psr2_active;
@@ -428,7 +428,7 @@ struct intel_fbc {
int cfb_size;
unsigned int fence_y_offset;
- u16 gen9_wa_cfb_stride;
+
[Intel-gfx] [PATCH 5/8] drm/i915/fbc: Rework cfb stride/size calculations
From: Ville Syrjälä
The code to calculate the cfb stride/size is a bit of mess.
The cfb size is getting calculated based purely on the plane
stride and plane height. That doesn't account for extra
alignment we want for the cfb stride. The gen9 override
stride OTOH is just calculated based on the plane width, and
it does try to make things more aligned but any extra alignment
added there is not considered in the cfb size calculations.
So not at all convinced this is working as intended. Additionally
the compression limit handling is split between the cfb allocation
code and g4x_dpfc_ctl_limit() (for the 16bpp case), which is just
confusing.
Let's streamline the whole thing:
- Start with the plane stride, convert that into cfb stride (cfb is
always 4 bytes per pixel). All the calculations will assume 1:1
compression limit since that will give us the max values, and we
don't yet know how much stolen memory we will be able to allocate
- Align the cfb stride to 512 bytes on modern platforms. This guarantees
the 4 line segment will be 512 byte aligned regardles of the final
compression limit we choose later. The 512 byte alignment for the
segment is required by at least some of the platforms, and just doing
it always seems like the easiest option
- Figure out if we need to use the override stride or not. For X-tiled
it's never needed since the plane stride is already 512 byte aligned,
for Y-tiled it will be needed if the plane stride is not a multiple
of 512 bytes, and for linear it's apparently always needed because the
hardware miscalculates the cfb stride as PLANE_STRIDE*512 instead of
the PLANE_STRIDE*64 that it use with linear.
- The cfb size will be calculated based on the aligned cfb stride to
guarantee we actually reserved enough stolen memory and the FBC hw
won't end up scribbling over whatever else is allocated in stolen
- The compression limit handling we just do fully in the cfb allocation
code to make things less confusing
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 141 ++-
drivers/gpu/drm/i915/i915_drv.h | 4 +-
2 files changed, 90 insertions(+), 55 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index f5cbbc53837c..2baf58af016c 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -62,19 +62,54 @@ static void intel_fbc_get_plane_source_size(const struct
intel_fbc_state_cache *
*height = cache->plane.src_h;
}
-static int intel_fbc_calculate_cfb_size(struct drm_i915_private *dev_priv,
- const struct intel_fbc_state_cache
*cache)
+/* plane stride in pixels */
+static unsigned int intel_fbc_plane_stride(const struct intel_plane_state
*plane_state)
{
- int lines;
+ const struct drm_framebuffer *fb = plane_state->hw.fb;
+ unsigned int stride;
+
+ stride = plane_state->view.color_plane[0].stride;
+ if (!drm_rotation_90_or_270(plane_state->hw.rotation))
+ stride /= fb->format->cpp[0];
+
+ return stride;
+}
+
+/* plane stride based cfb stride in bytes, assuming 1:1 compression limit */
+static unsigned int _intel_fbc_cfb_stride(const struct intel_fbc_state_cache
*cache)
+{
+ /* FBC always 4 bytes per pixel internally */
+ return cache->fb.stride * 4;
+}
+
+/* properly aligned cfb stride in bytes, assuming 1:1 compression limit */
+static unsigned int intel_fbc_cfb_stride(struct drm_i915_private *i915,
+const struct intel_fbc_state_cache
*cache)
+{
+ unsigned int stride = _intel_fbc_cfb_stride(cache);
+
+ /*
+* At least some of the platforms require each 4 line segment to
+* be 512 byte aligned. Aligning each line to 512 bytes guarantees
+* that regardless of the compression limit we choose later.
+*/
+ if (DISPLAY_VER(i915) == 9)
+ return ALIGN(stride, 512);
+ else
+ return stride;
+}
+
+static unsigned int intel_fbc_cfb_size(struct drm_i915_private *dev_priv,
+ const struct intel_fbc_state_cache
*cache)
+{
+ int lines = cache->plane.src_h;
- intel_fbc_get_plane_source_size(cache, NULL, &lines);
if (DISPLAY_VER(dev_priv) == 7)
lines = min(lines, 2048);
else if (DISPLAY_VER(dev_priv) >= 8)
lines = min(lines, 2560);
- /* Hardware needs the full buffer stride, not just the active area. */
- return lines * cache->fb.stride;
+ return lines * intel_fbc_cfb_stride(dev_priv, cache);
}
static void i8xx_fbc_deactivate(struct drm_i915_private *dev_priv)
@@ -150,15 +185,9 @@ static bool i8xx_fbc_is_active(struct drm_i915_private
*dev_priv)
static u32 g4x_dpfc_ctl_limit(struct drm_i915_private *i915)
{
- const struct intel_fbc_reg_p
[Intel-gfx] [PATCH 6/8] drm/i915/fbc: Align FBC segments to 512B on glk+
From: Ville Syrjälä
Apply the same 512 byte FBC segment alignment to glk+ as we use
on skl+. The only real difference is that we now have a dedicated
register for the FBC override stride. Not 100% sure which
platforms really need the 512B alignment, but it's easieest
to just do it on everything.
Also the hardware no longer seems to misclaculate the CFB stride
for linear, so we can omit the use of the override stride for
linear unless the stride is misaligned.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 14 +++---
drivers/gpu/drm/i915/i915_reg.h | 4
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 2baf58af016c..2da5295092e7 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -93,7 +93,7 @@ static unsigned int intel_fbc_cfb_stride(struct
drm_i915_private *i915,
* be 512 byte aligned. Aligning each line to 512 bytes guarantees
* that regardless of the compression limit we choose later.
*/
- if (DISPLAY_VER(i915) == 9)
+ if (DISPLAY_VER(i915) >= 9)
return ALIGN(stride, 512);
else
return stride;
@@ -334,10 +334,18 @@ static void gen7_fbc_activate(struct drm_i915_private
*dev_priv)
const struct intel_fbc_reg_params *params = &fbc->params;
u32 dpfc_ctl;
- /* Display WA #0529: skl, kbl, bxt. */
- if (DISPLAY_VER(dev_priv) == 9) {
+ if (DISPLAY_VER(dev_priv) >= 10) {
u32 val = 0;
+ if (params->override_cfb_stride)
+ val |= FBC_STRIDE_OVERRIDE |
+ FBC_STRIDE(params->override_cfb_stride /
fbc->limit);
+
+ intel_de_write(dev_priv, GLK_FBC_STRIDE, val);
+ } else if (DISPLAY_VER(dev_priv) == 9) {
+ u32 val = 0;
+
+ /* Display WA #0529: skl, kbl, bxt. */
if (params->override_cfb_stride)
val |= CHICKEN_FBC_STRIDE_OVERRIDE |
CHICKEN_FBC_STRIDE(params->override_cfb_stride
/ fbc->limit);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ab2bd4837efd..7cf318d84d81 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3334,6 +3334,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg)
#define ILK_DPFC_DISABLE_DUMMY0 (1 << 8)
#define ILK_DPFC_CHICKEN_COMP_DUMMY_PIXEL(1 << 14)
#define ILK_DPFC_NUKE_ON_ANY_MODIFICATION(1 << 23)
+#define GLK_FBC_STRIDE _MMIO(0x43228)
+#define FBC_STRIDE_OVERRIDE REG_BIT(15)
+#define FBC_STRIDE_MASK REG_GENMASK(14, 0)
+#define FBC_STRIDE(x)REG_FIELD_PREP(FBC_STRIDE_MASK, (x))
#define ILK_FBC_RT_BASE_MMIO(0x2128)
#define ILK_FBC_RT_VALID (1 << 0)
#define SNB_FBC_FRONT_BUFFER (1 << 1)
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] drm/i915/fbc: Implement Wa_16011863758 for icl+
From: Ville Syrjälä
There's some kind of weird corner cases in FBC which requires
FBC segments to be separated by at least one extra cacheline.
Make sure that is present.
TODO: the formula laid out in the spec seem to be semi-nonsense
so this is mostly my interpretation on what it is actually trying
to say. Need to wait for clarification from the hw folks to know
for sure.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 2da5295092e7..daf2191dd3f6 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -88,6 +88,16 @@ static unsigned int intel_fbc_cfb_stride(struct
drm_i915_private *i915,
{
unsigned int stride = _intel_fbc_cfb_stride(cache);
+ /*
+* Wa_16011863758: icl+
+* CFB segment stride needs at least one extra cacheline.
+* We make sure each line has an extra cacheline so that
+* the 4 line segment will have one regarless of the
+* compression limit we choose later.
+*/
+ if (DISPLAY_VER(i915) >= 11)
+ stride = max(stride, cache->plane.src_w * 4 + 64u);
+
/*
* At least some of the platforms require each 4 line segment to
* be 512 byte aligned. Aligning each line to 512 bytes guarantees
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 8/8] drm/i915/fbc: Allow higher compression limits on FBC1
From: Ville Syrjälä
On FBC1 we can specify an arbitrary cfb stride. The hw will
simply throw away any compressed line that would exceed the
specified limit and keep using the uncompressed data instead.
Thus we can allow arbitrary compression limits.
The one thing we have to keep in mind though is that the cfb
stride is specified in units of 32B (gen2) or 64B (gen3+).
Fortunately X-tile is already 128B (gen2) or 512B (gen3+) wide
so as long as we limit outselves to the same 4x compression
limit that FBC2 has we are guaranteed to have a sufficiently
aligned cfb stride.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_fbc.c | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index daf2191dd3f6..d46ee7b49d68 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -144,15 +144,13 @@ static void i8xx_fbc_deactivate(struct drm_i915_private
*dev_priv)
static void i8xx_fbc_activate(struct drm_i915_private *dev_priv)
{
- struct intel_fbc_reg_params *params = &dev_priv->fbc.params;
+ struct intel_fbc *fbc = &dev_priv->fbc;
+ const struct intel_fbc_reg_params *params = &fbc->params;
int cfb_pitch;
int i;
u32 fbc_ctl;
- /* Note: fbc.limit == 1 for i8xx */
- cfb_pitch = params->cfb_size / FBC_LL_SIZE;
- if (params->fb.stride < cfb_pitch)
- cfb_pitch = params->fb.stride;
+ cfb_pitch = params->cfb_stride / fbc->limit;
/* FBC_CTL wants 32B or 64B units */
if (DISPLAY_VER(dev_priv) == 2)
@@ -498,18 +496,14 @@ static int intel_fbc_min_limit(int fb_cpp)
static int intel_fbc_max_limit(struct drm_i915_private *dev_priv)
{
- /*
-* FIXME: FBC1 can have arbitrary cfb stride,
-* so we could support different compression ratios.
-*/
- if (DISPLAY_VER(dev_priv) < 5 && !IS_G4X(dev_priv))
- return 1;
-
/* WaFbcOnly1to1Ratio:ctg */
if (IS_G4X(dev_priv))
return 1;
- /* FBC2 can only do 1:1, 1:2, 1:4 */
+ /*
+* FBC2 can only do 1:1, 1:2, 1:4, we limit
+* FBC1 to the same out of convenience.
+*/
return 4;
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Improve debug Kconfig texts a bit
== Series Details ==
Series: drm/i915: Improve debug Kconfig texts a bit
URL : https://patchwork.freedesktop.org/series/92161/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
770403e058ed drm/i915: Improve debug Kconfig texts a bit
-:11: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 354d036fcf70
("drm/i915/tracepoints: Add request submit and execute tracepoints")'
#11:
commit 354d036fcf70654cff2e2cbdda54a835d219b9d2
-:67: WARNING:FROM_SIGN_OFF_MISMATCH: From:/Signed-off-by: email address
mismatch: 'From: Daniel Vetter ' != 'Signed-off-by:
Daniel Vetter '
total: 1 errors, 1 warnings, 0 checks, 22 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Improve debug Kconfig texts a bit
== Series Details ==
Series: drm/i915: Improve debug Kconfig texts a bit
URL : https://patchwork.freedesktop.org/series/92161/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10304 -> Patchwork_20522
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/index.html
Known issues
Here are the changes found in Patchwork_20522 that come from known issues:
### IGT changes ###
Possible fixes
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-kbl-7500u: [FAIL][1] ([i915#3449]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@dp-crc-fast:
- fi-kbl-7500u: [FAIL][3] ([i915#1372]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372
[i915#3303]: https://gitlab.freedesktop.org/drm/intel/issues/3303
[i915#3449]: https://gitlab.freedesktop.org/drm/intel/issues/3449
[i915#3717]: https://gitlab.freedesktop.org/drm/intel/issues/3717
Participating hosts (36 -> 35)
--
Missing(1): fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_10304 -> Patchwork_20522
CI-20190529: 20190529
CI_DRM_10304: 3d3b5479895dd6dd133571ded4318adf595708ba @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6128: b24e5949af7e51f0af484d2ce4cb4c5a41ac5358 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_20522: 770403e058ed103b4ac30f8e9ec43b46675205af @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
770403e058ed drm/i915: Improve debug Kconfig texts a bit
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/fbc: Rework CFB stride/size calculations
== Series Details == Series: drm/i915/fbc: Rework CFB stride/size calculations URL : https://patchwork.freedesktop.org/series/92163/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1896:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1896:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1896:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1210:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/fbc: Rework CFB stride/size calculations
== Series Details == Series: drm/i915/fbc: Rework CFB stride/size calculations URL : https://patchwork.freedesktop.org/series/92163/ State : success == Summary == CI Bug Log - changes from CI_DRM_10304 -> Patchwork_20523 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/index.html Known issues Here are the changes found in Patchwork_20523 that come from known issues: ### IGT changes ### Issues hit * igt@amdgpu/amd_cs_nop@sync-fork-compute0: - fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html Possible fixes * igt@i915_selftest@live@hangcheck: - fi-snb-2600:[INCOMPLETE][2] ([i915#2782]) -> [PASS][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-kbl-7500u: [FAIL][4] ([i915#3449]) -> [PASS][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/fi-kbl-7500u/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-kbl-7500u: [FAIL][6] ([i915#1372]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/fi-kbl-7500u/igt@kms_chamel...@dp-crc-fast.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1372]: https://gitlab.freedesktop.org/drm/intel/issues/1372 [i915#2782]: https://gitlab.freedesktop.org/drm/intel/issues/2782 [i915#3449]: https://gitlab.freedesktop.org/drm/intel/issues/3449 Participating hosts (36 -> 34) -- Missing(2): fi-bsw-cyan fi-bsw-n3050 Build changes - * Linux: CI_DRM_10304 -> Patchwork_20523 CI-20190529: 20190529 CI_DRM_10304: 3d3b5479895dd6dd133571ded4318adf595708ba @ git://anongit.freedesktop.org/gfx-ci/linux IGT_6128: b24e5949af7e51f0af484d2ce4cb4c5a41ac5358 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_20523: 1a6338102e7402b04550d6d1ba533ad8f5ad6410 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1a6338102e74 drm/i915/fbc: Allow higher compression limits on FBC1 c43b5d4d5ee5 drm/i915/fbc: Implement Wa_16011863758 for icl+ e7a875531eb4 drm/i915/fbc: Align FBC segments to 512B on glk+ 9fce51c1d980 drm/i915/fbc: Rework cfb stride/size calculations 1c684d0e6024 drm/i915/fbc: Polish the skl+ FBC stride override handling fc475b3b46e9 drm/i915/fbc: Move the "recompress on activate" to a central place faaa5f8aa77e drm/i915/fbc: Extract intel_fbc_update() df6e25b7503e drm/i915/fbc: Rewrite the FBC tiling check a bit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Improve debug Kconfig texts a bit
== Series Details == Series: drm/i915: Improve debug Kconfig texts a bit URL : https://patchwork.freedesktop.org/series/92161/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10304_full -> Patchwork_20522_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20522_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20522_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20522_full: ### IGT changes ### Possible regressions * igt@kms_draw_crc@draw-method-xrgb-render-ytiled: - shard-glk: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-glk6/igt@kms_draw_...@draw-method-xrgb-render-ytiled.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-glk7/igt@kms_draw_...@draw-method-xrgb-render-ytiled.html Known issues Here are the changes found in Patchwork_20522_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][3] -> [FAIL][4] ([i915#2842]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-none-vip@rcs0: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-kbl4/igt@gem_exec_fair@basic-none-...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-kbl7/igt@gem_exec_fair@basic-none-...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-none@vecs0: - shard-apl: NOTRUN -> [FAIL][8] ([i915#2842] / [i915#3468]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-apl2/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-kbl: [PASS][9] -> [SKIP][10] ([fdo#109271]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-kbl2/igt@gem_exec_fair@basic-p...@rcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-kbl6/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-tglb: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-tglb2/igt@gem_exec_fair@basic-p...@vcs1.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-tglb5/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#2190]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-skl1/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][14] ([i915#2658]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-apl3/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@dmabuf-sync: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#3323]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-apl2/igt@gem_userptr_bl...@dmabuf-sync.html - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3323]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-skl1/igt@gem_userptr_bl...@dmabuf-sync.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][17] -> [FAIL][18] ([i915#454]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-iclb2/igt@i915_pm...@dc6-psr.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@i915_selftest@live@hangcheck: - shard-snb: [PASS][19] -> [INCOMPLETE][20] ([i915#2782]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-snb7/igt@i915_selftest@l...@hangcheck.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-snb5/igt@i915_selftest@l...@hangcheck.html * igt@kms_big_fb@linear-16bpp-rotate-90: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271]) +287 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20522/shard-apl3/igt@kms_big...@linear-16bpp-rotate-90.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: -
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/fbc: Rework CFB stride/size calculations
== Series Details == Series: drm/i915/fbc: Rework CFB stride/size calculations URL : https://patchwork.freedesktop.org/series/92163/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10304_full -> Patchwork_20523_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20523_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20523_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_20523_full: ### IGT changes ### Possible regressions * igt@gem_eio@in-flight-10ms: - shard-iclb: [PASS][1] -> [TIMEOUT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-iclb6/igt@gem_...@in-flight-10ms.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-iclb2/igt@gem_...@in-flight-10ms.html * igt@kms_draw_crc@draw-method-xrgb-render-ytiled: - shard-glk: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-glk6/igt@kms_draw_...@draw-method-xrgb-render-ytiled.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-glk3/igt@kms_draw_...@draw-method-xrgb-render-ytiled.html Known issues Here are the changes found in Patchwork_20523_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-tglb6/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none-rrul@rcs0: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-glk5/igt@gem_exec_fair@basic-none-r...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-glk2/igt@gem_exec_fair@basic-none-r...@rcs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: NOTRUN -> [FAIL][9] ([i915#2842]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-kbl: [PASS][10] -> [SKIP][11] ([fdo#109271]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-kbl2/igt@gem_exec_fair@basic-p...@vcs1.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-kbl4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-iclb: [PASS][12] -> [FAIL][13] ([i915#2849]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-iclb5/igt@gem_exec_fair@basic-throt...@rcs0.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#2190]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-skl9/igt@gem_huc_c...@huc-copy.html * igt@gem_pread@exhaustion: - shard-apl: NOTRUN -> [WARN][15] ([i915#2658]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-apl1/igt@gem_pr...@exhaustion.html * igt@gem_userptr_blits@dmabuf-sync: - shard-skl: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#3323]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-skl8/igt@gem_userptr_bl...@dmabuf-sync.html * igt@i915_suspend@forcewake: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([i915#636]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-skl10/igt@i915_susp...@forcewake.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-skl8/igt@i915_susp...@forcewake.html * igt@kms_big_fb@x-tiled-16bpp-rotate-270: - shard-iclb: NOTRUN -> [SKIP][19] ([fdo#110725] / [fdo#111614]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-iclb1/igt@kms_big...@x-tiled-16bpp-rotate-270.html * igt@kms_big_fb@x-tiled-32bpp-rotate-180: - shard-glk: [PASS][20] -> [DMESG-WARN][21] ([i915#118] / [i915#95]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10304/shard-glk9/igt@kms_big...@x-tiled-32bpp-rotate-180.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20523/shard-glk5/igt@kms_big...@x-tiled-32bpp-rotate-180.html * igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-180-async-flip: - shard-skl: NOTRUN -
