Re: [Intel-gfx] [PATCH 5/5] drm/i915/mtl: don't expose GSC command streamer to the user
On Thu, Oct 27, 2022 at 03:15:54PM -0700, Daniele Ceraolo Spurio wrote: > There is no userspace user for this CS yet, we only need it for internal > kernel ops (e.g. HuC, PXP), so don't expose it. > > Signed-off-by: Daniele Ceraolo Spurio > Cc: Matt Roper Since we never expose it to userspace, we also never get to the point of doing an engine rename and removing the apostrophe. I assume we're okay with this engine continuing to show up as "other'6" in debug logs? Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_engine_user.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c > b/drivers/gpu/drm/i915/gt/intel_engine_user.c > index 79312b734690..ca795daca116 100644 > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c > @@ -211,6 +211,10 @@ void intel_engines_driver_register(struct > drm_i915_private *i915) > if (intel_gt_has_unrecoverable_error(engine->gt)) > continue; /* ignore incomplete engines */ > > + /* don't expose GSC engine to user */ > + if (engine->class == OTHER_CLASS) > + continue; > + > GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes)); > engine->uabi_class = uabi_classes[engine->class]; > > -- > 2.37.3 > -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation
Re: [Intel-gfx] [PATCH 4/5] drm/i915/mtl: add GSC CS reset support
On Thu, Oct 27, 2022 at 03:15:53PM -0700, Daniele Ceraolo Spurio wrote: > The GSC CS has its own dedicated bit in the GDRST register. > > Signed-off-by: Daniele Ceraolo Spurio > Cc: Matt Roper Bspec: 52549 Reviewed-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 + > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c > index e0fbfac03979..f63829abf66c 100644 > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c > @@ -423,6 +423,7 @@ static u32 get_reset_domain(u8 ver, enum intel_engine_id > id) > [CCS1] = GEN11_GRDOM_RENDER, > [CCS2] = GEN11_GRDOM_RENDER, > [CCS3] = GEN11_GRDOM_RENDER, > + [GSC0] = GEN12_GRDOM_GSC, > }; > GEM_BUG_ON(id >= ARRAY_SIZE(engine_reset_domains) || > !engine_reset_domains[id]); > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index 23844ba7e824..16cf90306085 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -640,6 +640,7 @@ > #define XEHPC_GRDOM_BLT3 REG_BIT(26) > #define XEHPC_GRDOM_BLT2 REG_BIT(25) > #define XEHPC_GRDOM_BLT1 REG_BIT(24) > +#define GEN12_GRDOM_GSCREG_BIT(21) > #define GEN11_GRDOM_SFC3 REG_BIT(20) > #define GEN11_GRDOM_SFC2 REG_BIT(19) > #define GEN11_GRDOM_SFC1 REG_BIT(18) > -- > 2.37.3 > -- Matt Roper Graphics Software Engineer VTT-OSGC Platform Enablement Intel Corporation
Re: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on Linear buffers
Gentle Reminder!
> -Original Message-
> From: Murthy, Arun R
> Sent: Monday, October 10, 2022 1:24 PM
> To: 'intel-gfx@lists.freedesktop.org'
> Cc: Syrjala, Ville
> Subject: RE: [PATCHv3] drm/i915: Support Async Flip on Linear buffers
>
> Ville,
> Gentle reminder!
>
> Thanks and Regards,
> Arun R Murthy
>
>
> > -Original Message-
> > From: Murthy, Arun R
> > Sent: Monday, September 19, 2022 10:38 AM
> > To: 'intel-gfx@lists.freedesktop.org'
> >
> > Cc: Syrjala, Ville
> > Subject: RE: [PATCHv3] drm/i915: Support Async Flip on Linear buffers
> >
> > If no comments, can anyone merge the patch!
> >
> > Thanks and Regards,
> > Arun R Murthy
> >
> >
> > > -Original Message-
> > > From: Murthy, Arun R
> > > Sent: Wednesday, September 14, 2022 4:21 PM
> > > To: Murthy, Arun R ; intel-
> > > g...@lists.freedesktop.org
> > > Cc: Syrjala, Ville
> > > Subject: RE: [PATCHv3] drm/i915: Support Async Flip on Linear
> > > buffers
> > >
> > > Gentle Reminder!
> > > Any comments?
> > >
> > > Thanks and Regards,
> > > Arun R Murthy
> > >
> > >
> > > > -Original Message-
> > > > From: Intel-gfx On
> > > > Behalf Of Murthy, Arun R
> > > > Sent: Friday, September 9, 2022 9:17 AM
> > > > To: intel-gfx@lists.freedesktop.org
> > > > Cc: Syrjala, Ville
> > > > Subject: Re: [Intel-gfx] [PATCHv3] drm/i915: Support Async Flip on
> > > > Linear buffers
> > > >
> > > > Gentle Reminder!
> > > >
> > > > > -Original Message-
> > > > > From: Murthy, Arun R
> > > > > Sent: Tuesday, September 6, 2022 9:18 AM
> > > > > To: intel-gfx@lists.freedesktop.org
> > > > > Cc: ville.syrj...@linux.intel.com; Murthy, Arun R
> > > > >
> > > > > Subject: [PATCHv3] drm/i915: Support Async Flip on Linear
> > > > > buffers
> > > > >
> > > > > Starting from Gen12 Async Flip is supported on linear buffers.
> > > > > This patch enables support for async on linear buffer.
> > > > >
> > > > > UseCase: In Hybrid graphics, for hardware unsupported pixel
> > > > > formats it will be converted to linear memory and then composed.
> > > > >
> > > > > v2: Added use case
> > > > > v3: Added FIXME for ICL indicating the restrictions
> > > > >
> > > > > Signed-off-by: Arun R Murthy
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 14
> > > > > ++
> > > > > 1 file changed, 14 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index be7cff722196..1880cfe70a7d 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -6610,6 +6610,20 @@ static int
> > > > > intel_async_flip_check_hw(struct intel_atomic_state *state, struct in
> > > > >* this selectively if required.
> > > > >*/
> > > > > switch (new_plane_state->hw.fb->modifier) {
> > > > > + case DRM_FORMAT_MOD_LINEAR:
> > > > > + /*
> > > > > + * FIXME: Async on Linear buffer is supported
> on ICL
> > > > > as
> > > > > + * but with additional alignment and fbc
> restrictions
> > > > > + * need to be taken care of. These aren't
> applicable
> > > > > for
> > > > > + * gen12+.
> > > > > + */
> > > > > + if (DISPLAY_VER(i915) < 12) {
> > > > > + drm_dbg_kms(>drm,
> > > > > + "[PLANE:%d:%s] Modifier
> does not
> > > > > support async flips\n",
> > > > > + plane->base.base.id, plane-
> > > > > >base.name);
> > > > > + return -EINVAL;
> > > > > + }
> > > > > +
> > > > > case I915_FORMAT_MOD_X_TILED:
> > > > > case I915_FORMAT_MOD_Y_TILED:
> > > > > case I915_FORMAT_MOD_Yf_TILED:
> > > > > --
> > > > > 2.25.1
Re: [Intel-gfx] [PATCH 3/5] drm/i915/mtl: add GSC CS interrupt support
On Thu, Oct 27, 2022 at 03:15:52PM -0700, Daniele Ceraolo Spurio wrote:
> The GSC CS re-uses the same interrupt bits that the GSC used in older
> platforms. This means that we can now have an engine interrupt coming
> out of OTHER_CLASS, so we need to handle that appropriately.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_gt_irq.c | 78 ++
> 1 file changed, 43 insertions(+), 35 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> index f26882fdc24c..34ff1ee7e931 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
> @@ -81,35 +81,27 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
> instance,
> instance, iir);
> }
>
> -static void
> -gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
> - const u8 instance, const u16 iir)
> +static struct intel_gt *pick_gt(struct intel_gt *gt, u8 class, u8 instance)
> {
> - struct intel_engine_cs *engine;
> -
> - /*
> - * Platforms with standalone media have their media engines in another
> - * GT.
> - */
> - if (MEDIA_VER(gt->i915) >= 13 &&
> - (class == VIDEO_DECODE_CLASS || class == VIDEO_ENHANCEMENT_CLASS)) {
> - if (!gt->i915->media_gt)
> - goto err;
> + struct intel_gt *media_gt = gt->i915->media_gt;
>
> - gt = gt->i915->media_gt;
> + /* we expect the non-media gt to be passed in */
> + GEM_BUG_ON(gt == media_gt);
> +
> + if (!media_gt)
> + return gt;
> +
> + switch (class) {
> + case VIDEO_DECODE_CLASS:
> + case VIDEO_ENHANCEMENT_CLASS:
> + return media_gt;
> + case OTHER_CLASS:
> + if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
> GSC0))
> + return media_gt;
> + fallthrough;
> + default:
> + return gt;
> }
> -
> - if (instance <= MAX_ENGINE_INSTANCE)
> - engine = gt->engine_class[class][instance];
> - else
> - engine = NULL;
> -
> - if (likely(engine))
> - return intel_engine_cs_irq(engine, iir);
> -
> -err:
> - WARN_ONCE(1, "unhandled engine interrupt class=0x%x, instance=0x%x\n",
> - class, instance);
> }
>
> static void
> @@ -118,12 +110,24 @@ gen11_gt_identity_handler(struct intel_gt *gt, const
> u32 identity)
> const u8 class = GEN11_INTR_ENGINE_CLASS(identity);
> const u8 instance = GEN11_INTR_ENGINE_INSTANCE(identity);
> const u16 intr = GEN11_INTR_ENGINE_INTR(identity);
> + struct intel_engine_cs *engine;
>
> if (unlikely(!intr))
> return;
>
> - if (class <= COPY_ENGINE_CLASS || class == COMPUTE_CLASS)
> - return gen11_engine_irq_handler(gt, class, instance, intr);
> + /*
> + * Platforms with standalone media have the media and GSC engines in
> + * another GT.
> + */
> + gt = pick_gt(gt, class, instance);
> +
> + if (class <= MAX_ENGINE_CLASS && instance <= MAX_ENGINE_INSTANCE)
> + engine = gt->engine_class[class][instance];
> + else
> + engine = NULL;
> +
> + if (engine)
> + return intel_engine_cs_irq(engine, intr);
>
> if (class == OTHER_CLASS)
> return gen11_other_irq_handler(gt, instance, intr);
> @@ -206,7 +210,7 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> intel_uncore_write(uncore, GEN11_VCS_VECS_INTR_ENABLE,0);
> if (CCS_MASK(gt))
> intel_uncore_write(uncore, GEN12_CCS_RSVD_INTR_ENABLE, 0);
> - if (HAS_HECI_GSC(gt->i915))
> + if (HAS_HECI_GSC(gt->i915) || HAS_ENGINE(gt, GSC0))
> intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE, 0);
>
> /* Restore masks irqs on RCS, BCS, VCS and VECS engines. */
> @@ -233,7 +237,7 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
> intel_uncore_write(uncore, GEN12_CCS0_CCS1_INTR_MASK, ~0);
> if (HAS_ENGINE(gt, CCS2) || HAS_ENGINE(gt, CCS3))
> intel_uncore_write(uncore, GEN12_CCS2_CCS3_INTR_MASK, ~0);
> - if (HAS_HECI_GSC(gt->i915))
> + if (HAS_HECI_GSC(gt->i915) || HAS_ENGINE(gt, GSC0))
> intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_MASK, ~0);
>
> intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
> @@ -249,7 +253,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
> {
> struct intel_uncore *uncore = gt->uncore;
> u32 irqs = GT_RENDER_USER_INTERRUPT;
> - const u32 gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
> + u32 gsc_mask = 0;
> u32 dmask;
> u32 smask;
>
> @@ -261,6 +265,11 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
> dmask = irqs << 16 | irqs;
> smask = irqs << 16;
>
> + if (HAS_ENGINE(gt,
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/hdmi: SPD infoframe updated for discrete (rev3)
== Series Details ==
Series: drm/i915/hdmi: SPD infoframe updated for discrete (rev3)
URL : https://patchwork.freedesktop.org/series/109908/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12313 -> Patchwork_109908v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_109908v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_109908v3, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/index.html
Participating hosts (37 -> 39)
--
Additional (3): fi-blb-e6850 fi-rkl-11600 fi-apl-guc
Missing(1): fi-ctg-p8600
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_109908v3:
### CI changes ###
Possible regressions
* boot:
- fi-ilk-650: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12313/fi-ilk-650/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-ilk-650/boot.html
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12313/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/bat-adlp-6/igt@i915_selftest@l...@migrate.html
Known issues
Here are the changes found in Patchwork_109908v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#2190])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#3282])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][9] ([i915#3012])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@module-reload:
- fi-blb-e6850: NOTRUN -> [SKIP][10] ([fdo#109271]) +43 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-blb-e6850/igt@i915_pm_...@module-reload.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][11] ([i915#4817])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bdw-5557u: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-bdw-5557u/igt@kms_chamel...@common-hpd-after-suspend.html
- fi-rkl-guc: NOTRUN -> [SKIP][13] ([fdo#111827])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-rkl-guc/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111827]) +8
similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([fdo#111827]) +7 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-rkl-11600/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#4103])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_109908v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-kefka: [PASS][17] -> [FAIL][18] ([i915#6298])
[17]:
Re: [Intel-gfx] [PATCH 2/5] drm/i915/mtl: pass the GSC CS info to the GuC
On Thu, Oct 27, 2022 at 03:15:51PM -0700, Daniele Ceraolo Spurio wrote:
> We need to tell the GuC that the GSC CS is there. The GuC interface
> swaps COMPUTE and OTHER class, so we also need to handle that.
When I first read the second sentence here, I thought you were saying
that the GuC interface had changed and redefined its own enums, but
that's not the case. I think you just meant that the FOO_CLASS and
GUC_FOO_CLASS enums are nearly the same except that they order COMPUTE
and OTHER classes differently. Honestly I think that's already pretty
clear from the existing values and mapping tables, even before this
patch, so I'd just leave this sentence off to avoid confusion.
Otherwise,
Reviewed-by: Matt Roper
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 11 +--
> drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 7 +--
> 2 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> index 34ef4f36e660..63e3d98788bd 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> @@ -478,6 +478,11 @@ static void fill_engine_enable_masks(struct intel_gt *gt,
> info_map_write(info_map, engine_enabled_masks[GUC_BLITTER_CLASS],
> BCS_MASK(gt));
> info_map_write(info_map, engine_enabled_masks[GUC_VIDEO_CLASS],
> VDBOX_MASK(gt));
> info_map_write(info_map, engine_enabled_masks[GUC_VIDEOENHANCE_CLASS],
> VEBOX_MASK(gt));
> +
> + /* The GSC engine is an instance (6) of OTHER_CLASS */
> + if (gt->engine[GSC0])
> + info_map_write(info_map,
> engine_enabled_masks[GUC_GSC_OTHER_CLASS],
> +BIT(gt->engine[GSC0]->instance));
> }
>
> #define LR_HW_CONTEXT_SIZE (80 * sizeof(u32))
> @@ -519,9 +524,6 @@ static int guc_prep_golden_context(struct intel_guc *guc)
> }
>
> for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS;
> ++engine_class) {
> - if (engine_class == OTHER_CLASS)
> - continue;
> -
> guc_class = engine_class_to_guc_class(engine_class);
>
> if (!info_map_read(_map, engine_enabled_masks[guc_class]))
> @@ -599,9 +601,6 @@ static void guc_init_golden_context(struct intel_guc *guc)
> addr_ggtt = intel_guc_ggtt_offset(guc, guc->ads_vma) + offset;
>
> for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS;
> ++engine_class) {
> - if (engine_class == OTHER_CLASS)
> - continue;
> -
> guc_class = engine_class_to_guc_class(engine_class);
> if (!ads_blob_read(guc,
> system_info.engine_enabled_masks[guc_class]))
> continue;
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> index 968ebd79dce7..4ae5fc2f6002 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
> @@ -47,7 +47,8 @@
> #define GUC_VIDEOENHANCE_CLASS 2
> #define GUC_BLITTER_CLASS3
> #define GUC_COMPUTE_CLASS4
> -#define GUC_LAST_ENGINE_CLASSGUC_COMPUTE_CLASS
> +#define GUC_GSC_OTHER_CLASS 5
> +#define GUC_LAST_ENGINE_CLASSGUC_GSC_OTHER_CLASS
> #define GUC_MAX_ENGINE_CLASSES 16
> #define GUC_MAX_INSTANCES_PER_CLASS 32
>
> @@ -169,6 +170,7 @@ static u8 engine_class_guc_class_map[] = {
> [COPY_ENGINE_CLASS] = GUC_BLITTER_CLASS,
> [VIDEO_DECODE_CLASS] = GUC_VIDEO_CLASS,
> [VIDEO_ENHANCEMENT_CLASS] = GUC_VIDEOENHANCE_CLASS,
> + [OTHER_CLASS] = GUC_GSC_OTHER_CLASS,
> [COMPUTE_CLASS] = GUC_COMPUTE_CLASS,
> };
>
> @@ -178,12 +180,13 @@ static u8 guc_class_engine_class_map[] = {
> [GUC_VIDEO_CLASS]= VIDEO_DECODE_CLASS,
> [GUC_VIDEOENHANCE_CLASS] = VIDEO_ENHANCEMENT_CLASS,
> [GUC_COMPUTE_CLASS] = COMPUTE_CLASS,
> + [GUC_GSC_OTHER_CLASS]= OTHER_CLASS,
> };
>
> static inline u8 engine_class_to_guc_class(u8 class)
> {
> BUILD_BUG_ON(ARRAY_SIZE(engine_class_guc_class_map) != MAX_ENGINE_CLASS
> + 1);
> - GEM_BUG_ON(class > MAX_ENGINE_CLASS || class == OTHER_CLASS);
> + GEM_BUG_ON(class > MAX_ENGINE_CLASS);
>
> return engine_class_guc_class_map[class];
> }
> --
> 2.37.3
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce the GSC CS
== Series Details ==
Series: Introduce the GSC CS
URL : https://patchwork.freedesktop.org/series/110237/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12313 -> Patchwork_110237v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/index.html
Participating hosts (37 -> 38)
--
Additional (4): fi-blb-e6850 fi-rkl-11600 bat-adls-5 fi-apl-guc
Missing(3): fi-ctg-p8600 fi-hsw-4770 bat-adlp-6
Known issues
Here are the changes found in Patchwork_110237v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-apl-guc: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3
similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-apl-guc/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3282])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#3012])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@module-reload:
- fi-blb-e6850: NOTRUN -> [SKIP][6] ([fdo#109271]) +43 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-blb-e6850/igt@i915_pm_...@module-reload.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][7] ([i915#4817])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-rkl-guc: NOTRUN -> [SKIP][8] ([fdo#111827])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-guc/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-crc-fast:
- fi-apl-guc: NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827]) +8
similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-apl-guc/igt@kms_chamel...@hdmi-crc-fast.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][10] ([fdo#111827]) +7 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#4103])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-apl-guc: NOTRUN -> [SKIP][12] ([fdo#109271]) +13 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-apl-guc/igt@kms_force_connector_ba...@force-connector-state.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([fdo#109285] / [i915#4098])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@sprite_plane_onoff:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#1072]) +3 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#3555] / [i915#4098])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-read:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3301] /
[i915#3708])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110237v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@gem_huc_copy@huc-copy:
- {bat-dg2-8}:[FAIL][18] ([i915#7029]) -> [PASS][19]
[18]:
Re: [Intel-gfx] [PATCH 1/5] drm/i915/mtl: add initial definitions for GSC CS
On Thu, Oct 27, 2022 at 03:15:50PM -0700, Daniele Ceraolo Spurio wrote:
> Starting on MTL, the GSC is no longer managed with direct MMIO access,
> but we instead have a dedicated command streamer for it. As a first step
> for adding support for this CS, add the required definitions.
> Note that, although it is now a CS, the GSC retains its old
> class:instance value (OTHER_CLASS instance 6)
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Matt Roper
Maybe add "Bspec: 65308, 45605" as a reference?
Otherwise,
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 4 files changed, 11 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 3b7d750ad054..e0fbfac03979 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -244,6 +244,13 @@ static const struct engine_info intel_engines[] = {
> { .graphics_ver = 12, .base = GEN12_COMPUTE3_RING_BASE }
> }
> },
> + [GSC0] = {
> + .class = OTHER_CLASS,
> + .instance = OTHER_GSC_INSTANCE,
> + .mmio_bases = {
> + { .graphics_ver = 12, .base = MTL_GSC_RING_BASE }
> + }
> + },
> };
>
> /**
> @@ -324,6 +331,7 @@ u32 intel_engine_context_size(struct intel_gt *gt, u8
> class)
> case VIDEO_DECODE_CLASS:
> case VIDEO_ENHANCEMENT_CLASS:
> case COPY_ENGINE_CLASS:
> + case OTHER_CLASS:
> if (GRAPHICS_VER(gt->i915) < 8)
> return 0;
> return GEN8_LR_CONTEXT_OTHER_SIZE;
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 6b5d4ea22b67..4fd54fb8810f 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -136,6 +136,7 @@ enum intel_engine_id {
> CCS2,
> CCS3,
> #define _CCS(n) (CCS0 + (n))
> + GSC0,
> I915_NUM_ENGINES
> #define INVALID_ENGINE ((enum intel_engine_id)-1)
> };
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 46a174f8aa00..79312b734690 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -140,6 +140,7 @@ const char *intel_engine_class_repr(u8 class)
> [COPY_ENGINE_CLASS] = "bcs",
> [VIDEO_DECODE_CLASS] = "vcs",
> [VIDEO_ENHANCEMENT_CLASS] = "vecs",
> + [OTHER_CLASS] = "other",
> [COMPUTE_CLASS] = "ccs",
> };
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1c0da50c0dc7..d056c3117ef2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -970,6 +970,7 @@
> #define GEN11_VEBOX2_RING_BASE 0x1d8000
> #define XEHP_VEBOX3_RING_BASE0x1e8000
> #define XEHP_VEBOX4_RING_BASE0x1f8000
> +#define MTL_GSC_RING_BASE0x11a000
> #define GEN12_COMPUTE0_RING_BASE 0x1a000
> #define GEN12_COMPUTE1_RING_BASE 0x1c000
> #define GEN12_COMPUTE2_RING_BASE 0x1e000
> --
> 2.37.3
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Introduce the GSC CS
== Series Details == Series: Introduce the GSC CS URL : https://patchwork.freedesktop.org/series/110237/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Introduce the GSC CS
== Series Details == Series: Introduce the GSC CS URL : https://patchwork.freedesktop.org/series/110237/ State : warning == Summary == Error: dim checkpatch failed 9a055873a680 drm/i915/mtl: add initial definitions for GSC CS ddb719782376 drm/i915/mtl: pass the GSC CS info to the GuC -:81: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #81: FILE: drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:189: + GEM_BUG_ON(class > MAX_ENGINE_CLASS); total: 0 errors, 1 warnings, 0 checks, 59 lines checked e62d625db085 drm/i915/mtl: add GSC CS interrupt support -:40: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #40: FILE: drivers/gpu/drm/i915/gt/intel_gt_irq.c:89: + GEM_BUG_ON(gt == media_gt); total: 0 errors, 1 warnings, 0 checks, 133 lines checked 4f9506c1fa4d drm/i915/mtl: add GSC CS reset support 237e5c9277d0 drm/i915/mtl: don't expose GSC command streamer to the user
[Intel-gfx] [PATCH v3] drm/i915/hdmi: SPD infoframe update for discrete
Replace internal with discrete of dgfx platforms.
v2: commit title reword (Jani)
v3: use variable name i915 (Jani)
Cc: Jani Nikula
Signed-off-by: Taylor, Clinton A
---
drivers/gpu/drm/i915/display/intel_hdmi.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index 02f8374ea51f..7c5133871897 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -766,6 +766,7 @@ intel_hdmi_compute_spd_infoframe(struct intel_encoder
*encoder,
struct intel_crtc_state *crtc_state,
struct drm_connector_state *conn_state)
{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
struct hdmi_spd_infoframe *frame = _state->infoframes.spd.spd;
int ret;
@@ -775,7 +776,10 @@ intel_hdmi_compute_spd_infoframe(struct intel_encoder
*encoder,
crtc_state->infoframes.enable |=
intel_hdmi_infoframe_enable(HDMI_INFOFRAME_TYPE_SPD);
- ret = hdmi_spd_infoframe_init(frame, "Intel", "Integrated gfx");
+ if (IS_DGFX(i915))
+ ret = hdmi_spd_infoframe_init(frame, "Intel", "Discrete gfx");
+ else
+ ret = hdmi_spd_infoframe_init(frame, "Intel", "Integrated gfx");
if (drm_WARN_ON(encoder->base.dev, ret))
return false;
--
2.25.1
[Intel-gfx] [PATCH 5/5] drm/i915/mtl: don't expose GSC command streamer to the user
There is no userspace user for this CS yet, we only need it for internal kernel ops (e.g. HuC, PXP), so don't expose it. Signed-off-by: Daniele Ceraolo Spurio Cc: Matt Roper --- drivers/gpu/drm/i915/gt/intel_engine_user.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c b/drivers/gpu/drm/i915/gt/intel_engine_user.c index 79312b734690..ca795daca116 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c @@ -211,6 +211,10 @@ void intel_engines_driver_register(struct drm_i915_private *i915) if (intel_gt_has_unrecoverable_error(engine->gt)) continue; /* ignore incomplete engines */ + /* don't expose GSC engine to user */ + if (engine->class == OTHER_CLASS) + continue; + GEM_BUG_ON(engine->class >= ARRAY_SIZE(uabi_classes)); engine->uabi_class = uabi_classes[engine->class]; -- 2.37.3
[Intel-gfx] [PATCH 4/5] drm/i915/mtl: add GSC CS reset support
The GSC CS has its own dedicated bit in the GDRST register. Signed-off-by: Daniele Ceraolo Spurio Cc: Matt Roper --- drivers/gpu/drm/i915/gt/intel_engine_cs.c | 1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c index e0fbfac03979..f63829abf66c 100644 --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c @@ -423,6 +423,7 @@ static u32 get_reset_domain(u8 ver, enum intel_engine_id id) [CCS1] = GEN11_GRDOM_RENDER, [CCS2] = GEN11_GRDOM_RENDER, [CCS3] = GEN11_GRDOM_RENDER, + [GSC0] = GEN12_GRDOM_GSC, }; GEM_BUG_ON(id >= ARRAY_SIZE(engine_reset_domains) || !engine_reset_domains[id]); diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index 23844ba7e824..16cf90306085 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -640,6 +640,7 @@ #define XEHPC_GRDOM_BLT3 REG_BIT(26) #define XEHPC_GRDOM_BLT2 REG_BIT(25) #define XEHPC_GRDOM_BLT1 REG_BIT(24) +#define GEN12_GRDOM_GSC REG_BIT(21) #define GEN11_GRDOM_SFC3 REG_BIT(20) #define GEN11_GRDOM_SFC2 REG_BIT(19) #define GEN11_GRDOM_SFC1 REG_BIT(18) -- 2.37.3
[Intel-gfx] [PATCH 2/5] drm/i915/mtl: pass the GSC CS info to the GuC
We need to tell the GuC that the GSC CS is there. The GuC interface
swaps COMPUTE and OTHER class, so we also need to handle that.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 11 +--
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 7 +--
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
index 34ef4f36e660..63e3d98788bd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
@@ -478,6 +478,11 @@ static void fill_engine_enable_masks(struct intel_gt *gt,
info_map_write(info_map, engine_enabled_masks[GUC_BLITTER_CLASS],
BCS_MASK(gt));
info_map_write(info_map, engine_enabled_masks[GUC_VIDEO_CLASS],
VDBOX_MASK(gt));
info_map_write(info_map, engine_enabled_masks[GUC_VIDEOENHANCE_CLASS],
VEBOX_MASK(gt));
+
+ /* The GSC engine is an instance (6) of OTHER_CLASS */
+ if (gt->engine[GSC0])
+ info_map_write(info_map,
engine_enabled_masks[GUC_GSC_OTHER_CLASS],
+ BIT(gt->engine[GSC0]->instance));
}
#define LR_HW_CONTEXT_SIZE (80 * sizeof(u32))
@@ -519,9 +524,6 @@ static int guc_prep_golden_context(struct intel_guc *guc)
}
for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS;
++engine_class) {
- if (engine_class == OTHER_CLASS)
- continue;
-
guc_class = engine_class_to_guc_class(engine_class);
if (!info_map_read(_map, engine_enabled_masks[guc_class]))
@@ -599,9 +601,6 @@ static void guc_init_golden_context(struct intel_guc *guc)
addr_ggtt = intel_guc_ggtt_offset(guc, guc->ads_vma) + offset;
for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS;
++engine_class) {
- if (engine_class == OTHER_CLASS)
- continue;
-
guc_class = engine_class_to_guc_class(engine_class);
if (!ads_blob_read(guc,
system_info.engine_enabled_masks[guc_class]))
continue;
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
index 968ebd79dce7..4ae5fc2f6002 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h
@@ -47,7 +47,8 @@
#define GUC_VIDEOENHANCE_CLASS 2
#define GUC_BLITTER_CLASS 3
#define GUC_COMPUTE_CLASS 4
-#define GUC_LAST_ENGINE_CLASS GUC_COMPUTE_CLASS
+#define GUC_GSC_OTHER_CLASS5
+#define GUC_LAST_ENGINE_CLASS GUC_GSC_OTHER_CLASS
#define GUC_MAX_ENGINE_CLASSES 16
#define GUC_MAX_INSTANCES_PER_CLASS32
@@ -169,6 +170,7 @@ static u8 engine_class_guc_class_map[] = {
[COPY_ENGINE_CLASS] = GUC_BLITTER_CLASS,
[VIDEO_DECODE_CLASS] = GUC_VIDEO_CLASS,
[VIDEO_ENHANCEMENT_CLASS] = GUC_VIDEOENHANCE_CLASS,
+ [OTHER_CLASS] = GUC_GSC_OTHER_CLASS,
[COMPUTE_CLASS] = GUC_COMPUTE_CLASS,
};
@@ -178,12 +180,13 @@ static u8 guc_class_engine_class_map[] = {
[GUC_VIDEO_CLASS]= VIDEO_DECODE_CLASS,
[GUC_VIDEOENHANCE_CLASS] = VIDEO_ENHANCEMENT_CLASS,
[GUC_COMPUTE_CLASS] = COMPUTE_CLASS,
+ [GUC_GSC_OTHER_CLASS]= OTHER_CLASS,
};
static inline u8 engine_class_to_guc_class(u8 class)
{
BUILD_BUG_ON(ARRAY_SIZE(engine_class_guc_class_map) != MAX_ENGINE_CLASS
+ 1);
- GEM_BUG_ON(class > MAX_ENGINE_CLASS || class == OTHER_CLASS);
+ GEM_BUG_ON(class > MAX_ENGINE_CLASS);
return engine_class_guc_class_map[class];
}
--
2.37.3
[Intel-gfx] [PATCH 1/5] drm/i915/mtl: add initial definitions for GSC CS
Starting on MTL, the GSC is no longer managed with direct MMIO access,
but we instead have a dedicated command streamer for it. As a first step
for adding support for this CS, add the required definitions.
Note that, although it is now a CS, the GSC retains its old
class:instance value (OTHER_CLASS instance 6)
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 8
drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 +
drivers/gpu/drm/i915/gt/intel_engine_user.c | 1 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 3b7d750ad054..e0fbfac03979 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -244,6 +244,13 @@ static const struct engine_info intel_engines[] = {
{ .graphics_ver = 12, .base = GEN12_COMPUTE3_RING_BASE }
}
},
+ [GSC0] = {
+ .class = OTHER_CLASS,
+ .instance = OTHER_GSC_INSTANCE,
+ .mmio_bases = {
+ { .graphics_ver = 12, .base = MTL_GSC_RING_BASE }
+ }
+ },
};
/**
@@ -324,6 +331,7 @@ u32 intel_engine_context_size(struct intel_gt *gt, u8 class)
case VIDEO_DECODE_CLASS:
case VIDEO_ENHANCEMENT_CLASS:
case COPY_ENGINE_CLASS:
+ case OTHER_CLASS:
if (GRAPHICS_VER(gt->i915) < 8)
return 0;
return GEN8_LR_CONTEXT_OTHER_SIZE;
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 6b5d4ea22b67..4fd54fb8810f 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -136,6 +136,7 @@ enum intel_engine_id {
CCS2,
CCS3,
#define _CCS(n) (CCS0 + (n))
+ GSC0,
I915_NUM_ENGINES
#define INVALID_ENGINE ((enum intel_engine_id)-1)
};
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 46a174f8aa00..79312b734690 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -140,6 +140,7 @@ const char *intel_engine_class_repr(u8 class)
[COPY_ENGINE_CLASS] = "bcs",
[VIDEO_DECODE_CLASS] = "vcs",
[VIDEO_ENHANCEMENT_CLASS] = "vecs",
+ [OTHER_CLASS] = "other",
[COMPUTE_CLASS] = "ccs",
};
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1c0da50c0dc7..d056c3117ef2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -970,6 +970,7 @@
#define GEN11_VEBOX2_RING_BASE 0x1d8000
#define XEHP_VEBOX3_RING_BASE 0x1e8000
#define XEHP_VEBOX4_RING_BASE 0x1f8000
+#define MTL_GSC_RING_BASE 0x11a000
#define GEN12_COMPUTE0_RING_BASE 0x1a000
#define GEN12_COMPUTE1_RING_BASE 0x1c000
#define GEN12_COMPUTE2_RING_BASE 0x1e000
--
2.37.3
[Intel-gfx] [PATCH 3/5] drm/i915/mtl: add GSC CS interrupt support
The GSC CS re-uses the same interrupt bits that the GSC used in older
platforms. This means that we can now have an engine interrupt coming
out of OTHER_CLASS, so we need to handle that appropriately.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 78 ++
1 file changed, 43 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index f26882fdc24c..34ff1ee7e931 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -81,35 +81,27 @@ gen11_other_irq_handler(struct intel_gt *gt, const u8
instance,
instance, iir);
}
-static void
-gen11_engine_irq_handler(struct intel_gt *gt, const u8 class,
-const u8 instance, const u16 iir)
+static struct intel_gt *pick_gt(struct intel_gt *gt, u8 class, u8 instance)
{
- struct intel_engine_cs *engine;
-
- /*
-* Platforms with standalone media have their media engines in another
-* GT.
-*/
- if (MEDIA_VER(gt->i915) >= 13 &&
- (class == VIDEO_DECODE_CLASS || class == VIDEO_ENHANCEMENT_CLASS)) {
- if (!gt->i915->media_gt)
- goto err;
+ struct intel_gt *media_gt = gt->i915->media_gt;
- gt = gt->i915->media_gt;
+ /* we expect the non-media gt to be passed in */
+ GEM_BUG_ON(gt == media_gt);
+
+ if (!media_gt)
+ return gt;
+
+ switch (class) {
+ case VIDEO_DECODE_CLASS:
+ case VIDEO_ENHANCEMENT_CLASS:
+ return media_gt;
+ case OTHER_CLASS:
+ if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
+ return media_gt;
+ fallthrough;
+ default:
+ return gt;
}
-
- if (instance <= MAX_ENGINE_INSTANCE)
- engine = gt->engine_class[class][instance];
- else
- engine = NULL;
-
- if (likely(engine))
- return intel_engine_cs_irq(engine, iir);
-
-err:
- WARN_ONCE(1, "unhandled engine interrupt class=0x%x, instance=0x%x\n",
- class, instance);
}
static void
@@ -118,12 +110,24 @@ gen11_gt_identity_handler(struct intel_gt *gt, const u32
identity)
const u8 class = GEN11_INTR_ENGINE_CLASS(identity);
const u8 instance = GEN11_INTR_ENGINE_INSTANCE(identity);
const u16 intr = GEN11_INTR_ENGINE_INTR(identity);
+ struct intel_engine_cs *engine;
if (unlikely(!intr))
return;
- if (class <= COPY_ENGINE_CLASS || class == COMPUTE_CLASS)
- return gen11_engine_irq_handler(gt, class, instance, intr);
+ /*
+* Platforms with standalone media have the media and GSC engines in
+* another GT.
+*/
+ gt = pick_gt(gt, class, instance);
+
+ if (class <= MAX_ENGINE_CLASS && instance <= MAX_ENGINE_INSTANCE)
+ engine = gt->engine_class[class][instance];
+ else
+ engine = NULL;
+
+ if (engine)
+ return intel_engine_cs_irq(engine, intr);
if (class == OTHER_CLASS)
return gen11_other_irq_handler(gt, instance, intr);
@@ -206,7 +210,7 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
intel_uncore_write(uncore, GEN11_VCS_VECS_INTR_ENABLE,0);
if (CCS_MASK(gt))
intel_uncore_write(uncore, GEN12_CCS_RSVD_INTR_ENABLE, 0);
- if (HAS_HECI_GSC(gt->i915))
+ if (HAS_HECI_GSC(gt->i915) || HAS_ENGINE(gt, GSC0))
intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_ENABLE, 0);
/* Restore masks irqs on RCS, BCS, VCS and VECS engines. */
@@ -233,7 +237,7 @@ void gen11_gt_irq_reset(struct intel_gt *gt)
intel_uncore_write(uncore, GEN12_CCS0_CCS1_INTR_MASK, ~0);
if (HAS_ENGINE(gt, CCS2) || HAS_ENGINE(gt, CCS3))
intel_uncore_write(uncore, GEN12_CCS2_CCS3_INTR_MASK, ~0);
- if (HAS_HECI_GSC(gt->i915))
+ if (HAS_HECI_GSC(gt->i915) || HAS_ENGINE(gt, GSC0))
intel_uncore_write(uncore, GEN11_GUNIT_CSME_INTR_MASK, ~0);
intel_uncore_write(uncore, GEN11_GPM_WGBOXPERF_INTR_ENABLE, 0);
@@ -249,7 +253,7 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
{
struct intel_uncore *uncore = gt->uncore;
u32 irqs = GT_RENDER_USER_INTERRUPT;
- const u32 gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
+ u32 gsc_mask = 0;
u32 dmask;
u32 smask;
@@ -261,6 +265,11 @@ void gen11_gt_irq_postinstall(struct intel_gt *gt)
dmask = irqs << 16 | irqs;
smask = irqs << 16;
+ if (HAS_ENGINE(gt, GSC0))
+ gsc_mask = irqs;
+ else if (HAS_HECI_GSC(gt->i915))
+ gsc_mask = GSC_IRQ_INTF(0) | GSC_IRQ_INTF(1);
+
BUILD_BUG_ON(irqs & 0x);
/*
[Intel-gfx] [PATCH 0/5] Introduce the GSC CS
Starting on MTL, the GSC microcontroller resides inside the media GT and the driver can communicate with it via a new Command Streamer, the GSC CS. As a first step in supporting the GSC integration within the media GT, this series adds the required defines and basic support for this CS. Note that, given that the only user of this CS is i915 itself, we don't need to expose it to userspace. The CS has been purposely not added to the engine mask for MTL yet, because it is only used in conjunction with the GSC FW, so there is nothing we can do with it until we add support for the FW, which will come as a separate next step. Cc: Matt Roper Cc: Rodrigo Vivi Daniele Ceraolo Spurio (5): drm/i915/mtl: add initial definitions for GSC CS drm/i915/mtl: pass the GSC CS info to the GuC drm/i915/mtl: add GSC CS interrupt support drm/i915/mtl: add GSC CS reset support drm/i915/mtl: don't expose GSC command streamer to the user drivers/gpu/drm/i915/gt/intel_engine_cs.c| 9 +++ drivers/gpu/drm/i915/gt/intel_engine_types.h | 1 + drivers/gpu/drm/i915/gt/intel_engine_user.c | 5 ++ drivers/gpu/drm/i915/gt/intel_gt_irq.c | 78 +++- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 11 ++- drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 7 +- drivers/gpu/drm/i915/i915_reg.h | 1 + 8 files changed, 70 insertions(+), 43 deletions(-) -- 2.37.3
Re: [Intel-gfx] [PATCH v1 1/7] vfio/ccw: create a parent struct
On Wed, 2022-10-19 at 18:21 +0200, Eric Farman wrote:
> Move the stuff associated with the mdev parent (and thus the
> subchannel struct) into its own struct, and leave the rest in
> the existing private structure.
>
> The subchannel will point to the parent, and the parent will point
> to the private, for the areas where one or both are needed. Further
> separation of these structs will follow.
>
> Signed-off-by: Eric Farman
> ---
> drivers/s390/cio/vfio_ccw_drv.c | 104 --
> --
> drivers/s390/cio/vfio_ccw_ops.c | 9 ++-
> drivers/s390/cio/vfio_ccw_parent.h | 28
> drivers/s390/cio/vfio_ccw_private.h | 5 --
> 4 files changed, 112 insertions(+), 34 deletions(-)
> create mode 100644 drivers/s390/cio/vfio_ccw_parent.h
>
> diff --git a/drivers/s390/cio/vfio_ccw_drv.c
> b/drivers/s390/cio/vfio_ccw_drv.c
> index 7f5402fe857a..634760ca0dea 100644
> --- a/drivers/s390/cio/vfio_ccw_drv.c
> +++ b/drivers/s390/cio/vfio_ccw_drv.c
...snip...
> @@ -213,18 +241,28 @@ static int vfio_ccw_sch_probe(struct subchannel
> *sch)
> return -ENODEV;
> }
>
> + parent = kzalloc(sizeof(*parent), GFP_KERNEL);
> + if (IS_ERR(parent))
> + return PTR_ERR(parent);
> +
> + parent->dev.release = _ccw_free_parent;
> + device_initialize(>dev);
> +
Oops. This should either be device_register, or I needed a device_add
somewhere along the way. There's no need to separate them, so the
former is probably better, but I still need some additional logic to
link this back to the css driver.
> private = vfio_ccw_alloc_private(sch);
> - if (IS_ERR(private))
> + if (IS_ERR(private)) {
> + put_device(>dev);
> return PTR_ERR(private);
> + }
>
> - dev_set_drvdata(>dev, private);
> + dev_set_drvdata(>dev, parent);
> + dev_set_drvdata(>dev, private);
>
> - private->mdev_type.sysfs_name = "io";
> - private->mdev_type.pretty_name = "I/O subchannel (Non-QDIO)";
> - private->mdev_types[0] = >mdev_type;
> - ret = mdev_register_parent(>parent, >dev,
> + parent->mdev_type.sysfs_name = "io";
> + parent->mdev_type.pretty_name = "I/O subchannel (Non-QDIO)";
> + parent->mdev_types[0] = >mdev_type;
> + ret = mdev_register_parent(>parent, >dev,
> _ccw_mdev_driver,
> - private->mdev_types, 1);
> + parent->mdev_types, 1);
> if (ret)
> goto out_free;
>
> @@ -234,20 +272,24 @@ static int vfio_ccw_sch_probe(struct subchannel
> *sch)
> return 0;
>
> out_free:
> + dev_set_drvdata(>dev, NULL);
> dev_set_drvdata(>dev, NULL);
> vfio_ccw_free_private(private);
> + put_device(>dev);
> return ret;
> }
>
> static void vfio_ccw_sch_remove(struct subchannel *sch)
> {
> - struct vfio_ccw_private *private = dev_get_drvdata(
> >dev);
> + struct vfio_ccw_parent *parent = dev_get_drvdata(>dev);
> + struct vfio_ccw_private *private = dev_get_drvdata(
> >dev);
>
> - mdev_unregister_parent(>parent);
> + mdev_unregister_parent(>parent);
>
> dev_set_drvdata(>dev, NULL);
>
> vfio_ccw_free_private(private);
> + put_device(>dev);
>
> VFIO_CCW_MSG_EVENT(4, "unbound from subchannel %x.%x.%04x\n",
> sch->schid.cssid, sch->schid.ssid,
> @@ -256,7 +298,11 @@ static void vfio_ccw_sch_remove(struct
> subchannel *sch)
>
> static void vfio_ccw_sch_shutdown(struct subchannel *sch)
> {
> - struct vfio_ccw_private *private = dev_get_drvdata(
> >dev);
> + struct vfio_ccw_parent *parent = dev_get_drvdata(>dev);
> + struct vfio_ccw_private *private = dev_get_drvdata(
> >dev);
> +
> + if (WARN_ON(!private))
> + return;
>
> vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_CLOSE);
> vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_NOT_OPER);
> @@ -274,7 +320,8 @@ static void vfio_ccw_sch_shutdown(struct
> subchannel *sch)
> */
> static int vfio_ccw_sch_event(struct subchannel *sch, int process)
> {
> - struct vfio_ccw_private *private = dev_get_drvdata(
> >dev);
> + struct vfio_ccw_parent *parent = dev_get_drvdata(>dev);
> + struct vfio_ccw_private *private = dev_get_drvdata(
> >dev);
> unsigned long flags;
> int rc = -EAGAIN;
>
> @@ -287,8 +334,10 @@ static int vfio_ccw_sch_event(struct subchannel
> *sch, int process)
>
> rc = 0;
>
> - if (cio_update_schib(sch))
> - vfio_ccw_fsm_event(private, VFIO_CCW_EVENT_NOT_OPER);
> + if (cio_update_schib(sch)) {
> + if (private)
> + vfio_ccw_fsm_event(private,
> VFIO_CCW_EVENT_NOT_OPER);
> + }
>
> out_unlock:
> spin_unlock_irqrestore(sch->lock, flags);
> @@ -326,7 +375,8 @@ static void
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk (rev2)
== Series Details ==
Series: series starting with [1/2] drm/i915/display: Do both crawl and squash
when changing cdclk (rev2)
URL : https://patchwork.freedesktop.org/series/110199/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12311 -> Patchwork_110199v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/index.html
Participating hosts (43 -> 40)
--
Missing(3): fi-kbl-soraka fi-ctg-p8600 bat-atsm-1
Known issues
Here are the changes found in Patchwork_110199v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_hotunplug@unbind-rebind:
- fi-icl-u2: NOTRUN -> [DMESG-WARN][1] ([i915#4890])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-icl-u2/igt@core_hotunp...@unbind-rebind.html
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [PASS][2] -> [DMESG-FAIL][3] ([i915#62])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@guc_multi_lrc:
- fi-cfl-8109u: [PASS][4] -> [DMESG-WARN][5] ([i915#5904] /
[i915#7174]) +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-cfl-8109u/igt@i915_selftest@live@guc_multi_lrc.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-cfl-8109u/igt@i915_selftest@live@guc_multi_lrc.html
* igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u: [PASS][6] -> [DMESG-WARN][7] ([i915#5904]) +27
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8109u: [PASS][8] -> [DMESG-WARN][9] ([i915#5904] / [i915#62])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_addfb_basic@too-high:
- fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#62]) +80
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-cfl-8109u/igt@kms_addfb_ba...@too-high.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-cfl-8109u/igt@kms_addfb_ba...@too-high.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#109285])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-icl-u2: NOTRUN -> [SKIP][14] ([i915#3555])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-icl-u2: NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#3301])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-icl-u2/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlm-1}: [DMESG-WARN][16] ([i915#2867]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][18] ([i915#4785]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@migrate:
- {bat-dg2-11}: [DMESG-WARN][20] -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/bat-dg2-11/igt@i915_selftest@l...@migrate.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v2/bat-dg2-11/igt@i915_selftest@l...@migrate.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][22] ([i915#6367] / [i915#6997]) ->
[PASS][23]
[22]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/dmabuf: fix sg_table handling in map_dma_buf
== Series Details == Series: series starting with [1/2] drm/i915/dmabuf: fix sg_table handling in map_dma_buf URL : https://patchwork.freedesktop.org/series/110229/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12311 -> Patchwork_110229v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_110229v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110229v1, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/index.html Participating hosts (43 -> 41) -- Missing(2): fi-ctg-p8600 fi-icl-u2 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110229v1: ### IGT changes ### Possible regressions * igt@i915_selftest@live@dmabuf: - fi-hsw-g3258: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-hsw-g3258/igt@i915_selftest@l...@dmabuf.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-hsw-g3258/igt@i915_selftest@l...@dmabuf.html - fi-hsw-4770:[PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-hsw-4770/igt@i915_selftest@l...@dmabuf.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-hsw-4770/igt@i915_selftest@l...@dmabuf.html - fi-ivb-3770:[PASS][5] -> [INCOMPLETE][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-ivb-3770/igt@i915_selftest@l...@dmabuf.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-ivb-3770/igt@i915_selftest@l...@dmabuf.html - fi-elk-e7500: [PASS][7] -> [INCOMPLETE][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-elk-e7500/igt@i915_selftest@l...@dmabuf.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-elk-e7500/igt@i915_selftest@l...@dmabuf.html - fi-pnv-d510:[PASS][9] -> [INCOMPLETE][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-pnv-d510/igt@i915_selftest@l...@dmabuf.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-pnv-d510/igt@i915_selftest@l...@dmabuf.html - fi-ilk-650: [PASS][11] -> [INCOMPLETE][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-ilk-650/igt@i915_selftest@l...@dmabuf.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-ilk-650/igt@i915_selftest@l...@dmabuf.html - fi-blb-e6850: [PASS][13] -> [INCOMPLETE][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-blb-e6850/igt@i915_selftest@l...@dmabuf.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-blb-e6850/igt@i915_selftest@l...@dmabuf.html - fi-snb-2520m: [PASS][15] -> [INCOMPLETE][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-snb-2520m/igt@i915_selftest@l...@dmabuf.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-snb-2520m/igt@i915_selftest@l...@dmabuf.html * igt@i915_selftest@live@gem_contexts: - fi-kbl-soraka: [PASS][17] -> [INCOMPLETE][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-kbl-soraka/igt@i915_selftest@live@gem_contexts.html Known issues Here are the changes found in Patchwork_110229v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@gt_heartbeat: - fi-apl-guc: [PASS][19] -> [DMESG-FAIL][20] ([i915#5334]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html - fi-kbl-soraka: [PASS][21] -> [DMESG-FAIL][22] ([i915#5334]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_suspend@basic-s3-without-i915: - fi-bdw-5557u: [PASS][23] -> [INCOMPLETE][24] ([i915#146]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110229v1/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html * igt@runner@aborted: - fi-ivb-3770:NOTRUN -> [FAIL][25] ([fdo#109271] / [i915#4312]) [25]:
Re: [Intel-gfx] [PATCH v7 0/9] dyndbg: drm.debug adaptation
On Thu, Oct 27, 2022 at 01:55:39PM -0600, jim.cro...@gmail.com wrote:
> On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
> wrote:
> >
> > On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> > > On Thu, Oct 27, 2022 at 9:08 AM Jason Baron wrote:
> > > >
> > > >
> > > >
> > > > On 10/21/22 05:18, Jani Nikula wrote:
> > > > > On Thu, 20 Oct 2022, Ville Syrjälä
> > > > > wrote:
> > > > >> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
> > > > >>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
> > > > hi Greg, Dan, Jason, DRM-folk,
> > > >
> > > > heres follow-up to V6:
> > > > rebased on driver-core/driver-core-next for -v6 applied bits
> > > > (thanks)
> > > > rework drm_debug_enabled{_raw,_instrumented,} per Dan.
> > > >
> > > > It excludes:
> > > > nouveau parts (immature)
> > > > tracefs parts (I missed --to=Steve on v6)
> > > > split _ddebug_site and de-duplicate experiment (way unready)
> > > >
> > > > IOW, its the remaining commits of V6 on which Dan gave his
> > > > Reviewed-by.
> > > >
> > > > If these are good to apply, I'll rebase and repost the rest
> > > > separately.
> > > > >>>
> > > > >>> All now queued up, thanks.
> > > > >>
> > > > >> This stuff broke i915 debugs. When I first load i915 no debug prints
> > > > >> are
> > > > >> produced. If I then go fiddle around in
> > > > >> /sys/module/drm/parameters/debug
> > > > >> the debug prints start to suddenly work.
> > > > >
> > > > > Wait what? I always assumed the default behaviour would stay the same,
> > > > > which is usually how we roll. It's a regression in my books. We've
> > > > > got a
> > > > > CI farm that's not very helpful in terms of dmesg logging right now
> > > > > because of this.
> > > > >
> > > > > BR,
> > > > > Jani.
> > > > >
> > > > >
> > > >
> > > > That doesn't sound good - so you are saying that prior to this change
> > > > some
> > > > of the drm debugs were default enabled. But now you have to manually
> > > > enable
> > > > them?
> > > >
> > > > Thanks,
> > > >
> > > > -Jason
> > >
> > >
> > > Im just seeing this now.
> > > Any new details ?
> >
> > No. We just disabled it as BROKEN for now. I was just today thinking
> > about sending that patch out if no solutin is forthcoming soon since
> > we need this working before 6.1 is released.
> >
> > Pretty sure you should see the problem immediately with any driver
> > (at least if it's built as a module, didn't try builtin). Or at least
> > can't think what would make i915 any more special.
> >
>
> So, I should note -
> 99% of my time & energy on this dyndbg + drm patchset
> has been done using virtme,
> so my world-view (and dev-hack-test env) has been smaller, simpler
> maybe its been fatally simplistic.
>
> ive just rebuilt v6.0 (before the trouble)
> and run it thru my virtual home box,
> I didnt see any unfamiliar drm-debug output
> that I might have inadvertently altered somehow
>
> I have some real HW I can put a reference kernel on,0
> to look for the missing output, but its all gonna take some time,
> esp to tighten up my dev-test-env
>
> in the meantime, there is:
>
> config DRM_USE_DYNAMIC_DEBUG
> bool "use dynamic debug to implement drm.debug"
> default y
> depends on DRM
> depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
> depends on JUMP_LABEL
> help
> Use dynamic-debug to avoid drm_debug_enabled() runtime overheads.
> Due to callsite counts in DRM drivers (~4k in amdgpu) and 56
> bytes per callsite, the .data costs can be substantial, and
> are therefore configurable.
>
> Does changing the default fix things for i915 dmesg ?
I think we want to mark it BROKEN in addition to make sure no one
enables it by accident. We already got one bug report where I had to
ask the reporter to rebuild their kernel since this had gotten
enabled and we didn't get any debugs from the driver probe.
> or is the problem deeper ?
>
> theres also this Makefile addition, which I might have oversimplified
>
> CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH v7 0/9] dyndbg: drm.debug adaptation
On Thu, Oct 27, 2022 at 9:59 AM Ville Syrjälä
wrote:
>
> On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> > On Thu, Oct 27, 2022 at 9:08 AM Jason Baron wrote:
> > >
> > >
> > >
> > > On 10/21/22 05:18, Jani Nikula wrote:
> > > > On Thu, 20 Oct 2022, Ville Syrjälä
> > > > wrote:
> > > >> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
> > > >>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
> > > hi Greg, Dan, Jason, DRM-folk,
> > >
> > > heres follow-up to V6:
> > > rebased on driver-core/driver-core-next for -v6 applied bits
> > > (thanks)
> > > rework drm_debug_enabled{_raw,_instrumented,} per Dan.
> > >
> > > It excludes:
> > > nouveau parts (immature)
> > > tracefs parts (I missed --to=Steve on v6)
> > > split _ddebug_site and de-duplicate experiment (way unready)
> > >
> > > IOW, its the remaining commits of V6 on which Dan gave his
> > > Reviewed-by.
> > >
> > > If these are good to apply, I'll rebase and repost the rest
> > > separately.
> > > >>>
> > > >>> All now queued up, thanks.
> > > >>
> > > >> This stuff broke i915 debugs. When I first load i915 no debug prints
> > > >> are
> > > >> produced. If I then go fiddle around in
> > > >> /sys/module/drm/parameters/debug
> > > >> the debug prints start to suddenly work.
> > > >
> > > > Wait what? I always assumed the default behaviour would stay the same,
> > > > which is usually how we roll. It's a regression in my books. We've got a
> > > > CI farm that's not very helpful in terms of dmesg logging right now
> > > > because of this.
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > >
> > >
> > > That doesn't sound good - so you are saying that prior to this change some
> > > of the drm debugs were default enabled. But now you have to manually
> > > enable
> > > them?
> > >
> > > Thanks,
> > >
> > > -Jason
> >
> >
> > Im just seeing this now.
> > Any new details ?
>
> No. We just disabled it as BROKEN for now. I was just today thinking
> about sending that patch out if no solutin is forthcoming soon since
> we need this working before 6.1 is released.
>
> Pretty sure you should see the problem immediately with any driver
> (at least if it's built as a module, didn't try builtin). Or at least
> can't think what would make i915 any more special.
>
So, I should note -
99% of my time & energy on this dyndbg + drm patchset
has been done using virtme,
so my world-view (and dev-hack-test env) has been smaller, simpler
maybe its been fatally simplistic.
ive just rebuilt v6.0 (before the trouble)
and run it thru my virtual home box,
I didnt see any unfamiliar drm-debug output
that I might have inadvertently altered somehow
I have some real HW I can put a reference kernel on,0
to look for the missing output, but its all gonna take some time,
esp to tighten up my dev-test-env
in the meantime, there is:
config DRM_USE_DYNAMIC_DEBUG
bool "use dynamic debug to implement drm.debug"
default y
depends on DRM
depends on DYNAMIC_DEBUG || DYNAMIC_DEBUG_CORE
depends on JUMP_LABEL
help
Use dynamic-debug to avoid drm_debug_enabled() runtime overheads.
Due to callsite counts in DRM drivers (~4k in amdgpu) and 56
bytes per callsite, the .data costs can be substantial, and
are therefore configurable.
Does changing the default fix things for i915 dmesg ?
or is the problem deeper ?
theres also this Makefile addition, which I might have oversimplified
CFLAGS-$(CONFIG_DRM_USE_DYNAMIC_DEBUG) += -DDYNAMIC_DEBUG_MODULE
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add DG2 OA support (rev11)
On Thu, Oct 27, 2022 at 12:34:06PM -0700, Umesh Nerlige Ramappa wrote:
On Thu, Oct 27, 2022 at 03:08:41PM +, Patchwork wrote:
Patch Details
Series: Add DG2 OA support (rev11)
URL: [1]https://patchwork.freedesktop.org/series/107584/
State: failure
Details:
[2]https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/index.html
CI Bug Log - changes from CI_DRM_12304_full -> Patchwork_107584v11_full
Summary
FAILURE
Serious unknown changes coming with Patchwork_107584v11_full absolutely
need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_107584v11_full, please notify your bug team to
allow them
to document this new failure mode, which will reduce false positives in
CI.
Participating hosts (11 -> 11)
No changes in participating hosts
Possible new issues
Here are the unknown changes that may have been introduced in
Patchwork_107584v11_full:
IGT changes
Possible regressions
* igt@perf@global-sseu-config:
* shard-tglb: [3]PASS -> [4]SKIP
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@perf@global-sseu-config:
* {shard-rkl}: [5]PASS -> [6]SKIP
* {shard-dg1}: [7]PASS -> [8]SKIP
The sseu-config feature is only applicable to ICL, for all other
platforms, these tests are expected to skip.
Revisiting this, I see that the IGT series needs to be fixed to allow
these tests to run on gen12. Only gen12.5 onwards these tests are
supposed to skip.
Thanks,
Umesh
Thanks,
Umesh
Known issues
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Add DG2 OA support (rev11)
On Thu, Oct 27, 2022 at 03:08:41PM +, Patchwork wrote:
Patch Details
Series: Add DG2 OA support (rev11)
URL: [1]https://patchwork.freedesktop.org/series/107584/
State: failure
Details:
[2]https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/index.html
CI Bug Log - changes from CI_DRM_12304_full -> Patchwork_107584v11_full
Summary
FAILURE
Serious unknown changes coming with Patchwork_107584v11_full absolutely
need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_107584v11_full, please notify your bug team to
allow them
to document this new failure mode, which will reduce false positives in
CI.
Participating hosts (11 -> 11)
No changes in participating hosts
Possible new issues
Here are the unknown changes that may have been introduced in
Patchwork_107584v11_full:
IGT changes
Possible regressions
* igt@perf@global-sseu-config:
* shard-tglb: [3]PASS -> [4]SKIP
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@perf@global-sseu-config:
* {shard-rkl}: [5]PASS -> [6]SKIP
* {shard-dg1}: [7]PASS -> [8]SKIP
The sseu-config feature is only applicable to ICL, for all other
platforms, these tests are expected to skip.
Thanks,
Umesh
Known issues
Re: [Intel-gfx] [PATCH v6 00/16] Add DG2 OA support
Thanks Umesh, Is it looking good to land? Looking forward to have this in Mesa upstream. -Lionel On 27/10/2022 01:20, Umesh Nerlige Ramappa wrote: Add OA format support for DG2 and various fixes for DG2. This series has 2 uapi changes listed below: 1) drm/i915/perf: Add OAG and OAR formats for DG2 DG2 has new OA formats defined that can be selected by the user. The UMD changes that are consumed by GPUvis are: https://patchwork.freedesktop.org/patch/504456/?series=107633=5 Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18893 2) drm/i915/perf: Apply Wa_18013179988 DG2 has a bug where the OA timestamp does not tick at the CS timestamp frequency. Instead it ticks at a multiple that is determined from the CTC_SHIFT value in RPM_CONFIG. Since the timestamp is used by UMD to make sense of all the counters in the report, expose the OA timestamp frequency to the user. The interface is generic and applies to all platforms. On platforms where the bug is not present, this returns the CS timestamp frequency. UMD specific changes consumed by GPUvis are: https://patchwork.freedesktop.org/patch/504464/?series=107633=5 Mesa MR: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18893 v2: - Add review comments - Update uapi changes in cover letter - Drop patches for non-production platforms drm/i915/perf: Use helpers to process reports w.r.t. OA buffer size drm/i915/perf: Add Wa_16010703925:dg2 - Drop 64-bit OA format changes for now drm/i915/perf: Parse 64bit report header formats correctly drm/i915/perf: Add Wa_1608133521:dg2 v3: - Add review comments to patches 02, 04, 05, 14 - Drop Acks v4: - Add review comments to patch 04 - Update R-bs - Add MR links to patches 02 and 12 v5: - Drop unrelated comment - Rebase and fix MCR reg write - On pre-gen12, EU flex config is saved/restored in the context image, so save/restore EU flex config only for gen12. v6: - Fix checkpatch issues Test-with: 20221025200709.83314-1-umesh.nerlige.rama...@intel.com Signed-off-by: Umesh Nerlige Ramappa Lionel Landwerlin (1): drm/i915/perf: complete programming whitelisting for XEHPSDV Umesh Nerlige Ramappa (14): drm/i915/perf: Fix OA filtering logic for GuC mode drm/i915/perf: Add 32-bit OAG and OAR formats for DG2 drm/i915/perf: Fix noa wait predication for DG2 drm/i915/perf: Determine gen12 oa ctx offset at runtime drm/i915/perf: Enable bytes per clock reporting in OA drm/i915/perf: Simply use stream->ctx drm/i915/perf: Move gt-specific data from i915->perf to gt->perf drm/i915/perf: Replace gt->perf.lock with stream->lock for file ops drm/i915/perf: Use gt-specific ggtt for OA and noa-wait buffers drm/i915/perf: Store a pointer to oa_format in oa_buffer drm/i915/perf: Add Wa_1508761755:dg2 drm/i915/perf: Apply Wa_18013179988 drm/i915/perf: Save/restore EU flex counters across reset drm/i915/perf: Enable OA for DG2 Vinay Belgaumkar (1): drm/i915/guc: Support OA when Wa_16011777198 is enabled drivers/gpu/drm/i915/gt/intel_engine_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 4 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/gt/intel_lrc.h | 2 + drivers/gpu/drm/i915/gt/intel_sseu.c | 4 +- .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 9 + drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c| 10 + drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 66 ++ drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 2 + drivers/gpu/drm/i915/i915_drv.h | 5 + drivers/gpu/drm/i915/i915_getparam.c | 3 + drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_perf.c | 576 ++ drivers/gpu/drm/i915/i915_perf.h | 2 + drivers/gpu/drm/i915/i915_perf_oa_regs.h | 6 +- drivers/gpu/drm/i915/i915_perf_types.h| 47 +- drivers/gpu/drm/i915/intel_device_info.h | 2 + drivers/gpu/drm/i915/selftests/i915_perf.c| 16 +- include/uapi/drm/i915_drm.h | 10 + 20 files changed, 630 insertions(+), 141 deletions(-)
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
On Thu, 27 Oct 2022 10:16:47 -0700, Nick Desaulniers wrote:
>
Hi Nick,
> Thanks, I can repro now.
>
> I haven't detangled the macro soup, but I noticed:
>
> 1. FIELD_PREP is defined in include/linux/bitfield.h which has the
> following comment:
> 18 * Mask must be a compilation time constant.
I had comments about this here:
https://lore.kernel.org/intel-gfx/87ilk7pwrw.wl-ashutosh.di...@intel.com/
The relevant part being:
{quote}
> > > ./include/linux/bitfield.h:71:53: note: expanded from macro
> > > '__BF_FIELD_CHECK'
> > > BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) > \
So clang seems to break here at this line in __BF_FIELD_CHECK (note ~0ull
also occurs here):
BUILD_BUG_ON_MSG(__bf_cast_unsigned(_mask, _mask) > \
__bf_cast_unsigned(_reg, ~0ull), \
_pfx "type of reg too small for mask"); \
So it goes through previous checks including the "mask is not constant"
check. As Nick Desaulniers mentions "__builtin_constant_p is evaluated
after most optimizations have run" so by that time both compilers (gcc and
clang) have figured out that even though _mask is coming in as function
argument it is really the constant below:
#define PKG_PWR_LIM_1 REG_GENMASK(14, 0)
But it is not clear why clang chokes on this "type of reg too small for
mask" check (and gcc doesn't) since everything is u32.
{end quote}
>
> 2. hwm_field_scale_and_write only has one callsite.
>
> The following patch works:
If we need to fix it at our end yes we can come up with one of these
patches. But we were hoping someone from clang/llvm can comment about the
"type of reg too small for mask" stuff. If this is something which needs to
be fixed in clang/llvm we probably don't want to hide the issue.
>
> ```
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 9e9781493025..6ac29d90b92a 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
> i915_reg_t rgadr,
>
> static void
> hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> - u32 field_msk, int nshift,
> + int nshift,
> unsigned int scale_factor, long lval)
> {
> u32 nval;
> @@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
> *ddat, i915_reg_t rgadr,
> /* Computation in 64-bits to avoid overflow. Round to nearest. */
> nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
>
> - bits_to_clear = field_msk;
> - bits_to_set = FIELD_PREP(field_msk, nval);
> + bits_to_clear = PKG_PWR_LIM_1;
> + bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
>
> hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> bits_to_clear, bits_to_set);
> @@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
> attr, int chan, long val)
> case hwmon_power_max:
> hwm_field_scale_and_write(ddat,
> hwmon->rg.pkg_rapl_limit,
> - PKG_PWR_LIM_1,
> hwmon->scl_shift_power,
> SF_POWER, val);
> return 0;
> ```
> Though I'm not sure if you're planning to add further callsites of
> hwm_field_scale_and_write with different field_masks?
I have reasons for keeping it this way, it's there in the link above if you
are interested.
>
> Alternatively, (without the above diff),
>
> ```
> diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> index c9be1657f03d..6f40f12bcf89 100644
> --- a/include/linux/bitfield.h
> +++ b/include/linux/bitfield.h
> @@ -8,6 +8,7 @@
> #define _LINUX_BITFIELD_H
>
> #include
> +#include
> #include
>
> /*
> @@ -62,7 +63,7 @@
>
> #define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx) \
> ({ \
> - BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \
> + BUILD_BUG_ON_MSG(!__is_constexpr(_mask),\
> _pfx "mask is not constant"); \
> BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");\
> BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \
> ```
> will produce:
> error: call to __compiletime_assert_407 declared with 'error'
> attribute: FIELD_PREP: mask is not constant
>
> I haven't tested if that change is also feasible (on top of fixing
> this specific instance), but I think it might help avoid more of these
> subtleties wrt. __builtin_constant_p that depende heavily on compiler,
> compiler version, optimization level.
Not disagreeing, can do
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/hwmon: Fix a build error used with clang compiler (rev2)
== Series Details == Series: drm/i915/hwmon: Fix a build error used with clang compiler (rev2) URL : https://patchwork.freedesktop.org/series/110094/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/110094/revisions/2/mbox/ not applied Applying: drm/i915/hwmon: Fix a build error used with clang compiler error: git diff header lacks filename information when removing 1 leading pathname component (line 2) error: could not build fake ancestor hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/i915/hwmon: Fix a build error used with clang compiler 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".
Re: [Intel-gfx] [PATCH 2/8] drm/i915/sdvo: Setup DDC fully before output init
On Thu, 27 Oct 2022, Ville Syrjälä wrote:
> On Thu, Oct 27, 2022 at 05:49:53PM +0300, Ville Syrjälä wrote:
>> On Thu, Oct 27, 2022 at 05:36:24PM +0300, Jani Nikula wrote:
>> > On Wed, 26 Oct 2022, Ville Syrjala wrote:
>> > > From: Ville Syrjälä
>> > >
>> > > Call intel_sdvo_select_ddc_bus() before initializing any
>> > > of the outputs. And before that is functional (assuming no VBT)
>> > > we have to set up the controlled_outputs thing. Otherwise DDC
>> > > won't be functional during the output init but LVDS really
>> > > needs it for the fixed mode setup.
>> > >
>> > > Note that the whole multi output support still looks very
>> > > bogus, and more work will be needed to make it correct.
>> > > But for now this should at least fix the LVDS EDID fixed mode
>> > > setup.
>> > >
>> > > Cc: sta...@vger.kernel.org
>> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
>> > > Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
>> > > Signed-off-by: Ville Syrjälä
>> > > ---
>> > > drivers/gpu/drm/i915/display/intel_sdvo.c | 31 +--
>> > > 1 file changed, 12 insertions(+), 19 deletions(-)
>> > >
>> > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
>> > > b/drivers/gpu/drm/i915/display/intel_sdvo.c
>> > > index c6200a91a777..ccf81d616cb4 100644
>> > > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
>> > > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
>> > > @@ -2746,13 +2746,10 @@ intel_sdvo_dvi_init(struct intel_sdvo
>> > > *intel_sdvo, int device)
>> > > if (!intel_sdvo_connector)
>> > > return false;
>> > >
>> > > -if (device == 0) {
>> > > -intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
>> > > +if (device == 0)
>> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS0;
>> > > -} else if (device == 1) {
>> > > -intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
>> > > +else if (device == 1)
>> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS1;
>> > > -}
>> > >
>> > > intel_connector = _sdvo_connector->base;
>> > > connector = _connector->base;
>> > > @@ -2807,7 +2804,6 @@ intel_sdvo_tv_init(struct intel_sdvo *intel_sdvo,
>> > > int type)
>> > > encoder->encoder_type = DRM_MODE_ENCODER_TVDAC;
>> > > connector->connector_type = DRM_MODE_CONNECTOR_SVIDEO;
>> > >
>> > > -intel_sdvo->controlled_output |= type;
>> > > intel_sdvo_connector->output_flag = type;
>> > >
>> > > if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo)
>> > > < 0) {
>> > > @@ -2848,13 +2844,10 @@ intel_sdvo_analog_init(struct intel_sdvo
>> > > *intel_sdvo, int device)
>> > > encoder->encoder_type = DRM_MODE_ENCODER_DAC;
>> > > connector->connector_type = DRM_MODE_CONNECTOR_VGA;
>> > >
>> > > -if (device == 0) {
>> > > -intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
>> > > +if (device == 0)
>> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB0;
>> > > -} else if (device == 1) {
>> > > -intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
>> > > +else if (device == 1)
>> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB1;
>> > > -}
>> > >
>> > > if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo)
>> > > < 0) {
>> > > kfree(intel_sdvo_connector);
>> > > @@ -2884,13 +2877,10 @@ intel_sdvo_lvds_init(struct intel_sdvo
>> > > *intel_sdvo, int device)
>> > > encoder->encoder_type = DRM_MODE_ENCODER_LVDS;
>> > > connector->connector_type = DRM_MODE_CONNECTOR_LVDS;
>> > >
>> > > -if (device == 0) {
>> > > -intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
>> > > +if (device == 0)
>> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS0;
>> > > -} else if (device == 1) {
>> > > -intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
>> > > +else if (device == 1)
>> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS1;
>> > > -}
>> > >
>> > > if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo)
>> > > < 0) {
>> > > kfree(intel_sdvo_connector);
>> > > @@ -2945,8 +2935,14 @@ static u16 intel_sdvo_filter_output_flags(u16
>> > > flags)
>> > > static bool
>> > > intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
>> > > {
>> > > +struct drm_i915_private *i915 =
>> > > to_i915(intel_sdvo->base.base.dev);
>> > > +
>> > > flags = intel_sdvo_filter_output_flags(flags);
>> > >
>> > > +intel_sdvo->controlled_output = flags;
>> > > +
>> > > +intel_sdvo_select_ddc_bus(i915, intel_sdvo);
>> >
>> > AFAICT the ->controlled_outputs member could now be removed and just
Re: [Intel-gfx] [PATCH 2/2] drm/i915/dg2: Introduce Wa_18019271663
On Tue, Oct 25, 2022 at 11:03:35AM -0700, Matt Atwood wrote: > Wa_18019271663 applies to all DG2 steppings and skus. > > Bspec:45809 Could we also add the reference to the BSpec containing the WA description? > > Signed-off-by: Matt Atwood > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 7 --- > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++ > 2 files changed, 7 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index e8372d4cd548..46035503068c 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -421,9 +421,10 @@ > #define RC_OP_FLUSH_ENABLE (1 << 0) > #define HIZ_RAW_STALL_OPT_DISABLE (1 << 2) > #define CACHE_MODE_1 _MMIO(0x7004) /* IVB+ */ > -#define PIXEL_SUBSPAN_COLLECT_OPT_DISABLE (1 << 6) > -#define GEN8_4x4_STC_OPTIMIZATION_DISABLE (1 << 6) > -#define GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE (1 << 1) > +#define MSAA_OPTIMIZATION_REDUC_DISABLEREG_BIT(11) > +#define PIXEL_SUBSPAN_COLLECT_OPT_DISABLE REG_BIT(6) > +#define GEN8_4x4_STC_OPTIMIZATION_DISABLE REG_BIT(6) > +#define GEN9_PARTIAL_RESOLVE_IN_VC_DISABLE REG_BIT(1) > > #define GEN7_GT_MODE _MMIO(0x7008) > #define GEN9_IZ_HASHING_MASK(slice)(0x3 << ((slice) * 2)) > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index ced3a26cf7e7..9f39b7758ff3 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -750,6 +750,9 @@ static void dg2_ctx_workarounds_init(struct > intel_engine_cs *engine, > > /* Wa_15010599737:dg2 */ > wa_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN); > + > + /* Wa_18019271663:dg2 */ > + wa_masked_en(wal, CACHE_MODE_1, MSAA_OPTIMIZATION_REDUC_DISABLE); > } > > static void fakewa_disable_nestedbb_mode(struct intel_engine_cs *engine, > -- > 2.37.3 >
Re: [Intel-gfx] [PATCH 1/2] drm/i915/dg2: Introduce Wa_18018764978
On Tue, Oct 25, 2022 at 11:03:34AM -0700, Matt Atwood wrote: > Wa_18018764978 applies to specific steppings of DG2 (G11 C0+, I believe you mean "G10 C0+"? > G11 and G12 A0+). > > Bspec: 66622 > > Signed-off-by: Matt Atwood > --- > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++ > drivers/gpu/drm/i915/gt/intel_workarounds.c | 5 + > 2 files changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index 36d95b79022c..e8372d4cd548 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -448,6 +448,9 @@ > #define GEN8_L3CNTLREG _MMIO(0x7034) > #define GEN8_ERRDETBCTRL (1 << 9) > > +#define PSS_MODE2_MMIO(0x703c) > +#define SCOREBOARD_STALL_FLUSH_CONTROL REG_BIT(5) > + > #define GEN7_SC_INSTDONE _MMIO(0x7100) > #define GEN12_SC_INSTDONE_EXTRA _MMIO(0x7104) > #define GEN12_SC_INSTDONE_EXTRA2 _MMIO(0x7108) > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c > b/drivers/gpu/drm/i915/gt/intel_workarounds.c > index 63e1e6becf34..ced3a26cf7e7 100644 > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c > @@ -743,6 +743,11 @@ static void dg2_ctx_workarounds_init(struct > intel_engine_cs *engine, > IS_DG2_G11(engine->i915) || IS_DG2_G12(engine->i915)) > wa_masked_field_set(wal, VF_PREEMPTION, > PREEMPTION_VERTEX_COUNT, 0x4000); > > + /* Wa_18018764978:dg2 */ > + if (IS_DG2_GRAPHICS_STEP(engine->i915, G10, STEP_C0, STEP_FOREVER) || > + IS_DG2_G11(engine->i915) || IS_DG2_G12(engine->i915)) Checkpatch is complaining about the alignment here. -- Gustavo Sousa > + wa_masked_en(wal, PSS_MODE2, SCOREBOARD_STALL_FLUSH_CONTROL); > + > /* Wa_15010599737:dg2 */ > wa_masked_en(wal, CHICKEN_RASTER_1, DIS_SF_ROUND_NEAREST_EVEN); > } > -- > 2.37.3 >
Re: [Intel-gfx] [PATCH v2] drm/i915: Fix CFI violations in gt_sysfs
Hi Nathan,
pushed in drm-intel-gt-next.
Thanks!
Andi
On Thu, Oct 13, 2022 at 01:59:10PM -0700, Nathan Chancellor wrote:
> When booting with CONFIG_CFI_CLANG, there are numerous violations when
> accessing the files under
> /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
>
> $ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
>
> $ grep . *
> id:0
> punit_req_freq_mhz:350
> rc6_enable:1
> rc6_residency_ms:214934
> rps_act_freq_mhz:1300
> rps_boost_freq_mhz:1300
> rps_cur_freq_mhz:350
> rps_max_freq_mhz:1300
> rps_min_freq_mhz:350
> rps_RP0_freq_mhz:1300
> rps_RP1_freq_mhz:350
> rps_RPn_freq_mhz:350
> throttle_reason_pl1:0
> throttle_reason_pl2:0
> throttle_reason_pl4:0
> throttle_reason_prochot:0
> throttle_reason_ratl:0
> throttle_reason_status:0
> throttle_reason_thermal:0
> throttle_reason_vr_tdc:0
> throttle_reason_vr_thermalert:0
>
> $ sudo dmesg &| grep "CFI failure at"
> [ 214.595903] CFI failure at kobj_attr_show+0x19/0x30 (target:
> id_show+0x0/0x70 [i915]; expected type: 0xc527b809)
> [ 214.596064] CFI failure at kobj_attr_show+0x19/0x30 (target:
> punit_req_freq_mhz_show+0x0/0x40 [i915]; expected type: 0xc527b809)
> [ 214.596407] CFI failure at kobj_attr_show+0x19/0x30 (target:
> rc6_enable_show+0x0/0x40 [i915]; expected type: 0xc527b809)
> [ 214.596528] CFI failure at kobj_attr_show+0x19/0x30 (target:
> rc6_residency_ms_show+0x0/0x270 [i915]; expected type: 0xc527b809)
> [ 214.596682] CFI failure at kobj_attr_show+0x19/0x30 (target:
> act_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> [ 214.596792] CFI failure at kobj_attr_show+0x19/0x30 (target:
> boost_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> [ 214.596893] CFI failure at kobj_attr_show+0x19/0x30 (target:
> cur_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> [ 214.596996] CFI failure at kobj_attr_show+0x19/0x30 (target:
> max_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> [ 214.597099] CFI failure at kobj_attr_show+0x19/0x30 (target:
> min_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> [ 214.597198] CFI failure at kobj_attr_show+0x19/0x30 (target:
> RP0_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> [ 214.597301] CFI failure at kobj_attr_show+0x19/0x30 (target:
> RP1_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> [ 214.597405] CFI failure at kobj_attr_show+0x19/0x30 (target:
> RPn_freq_mhz_show+0x0/0xe0 [i915]; expected type: 0xc527b809)
> [ 214.597538] CFI failure at kobj_attr_show+0x19/0x30 (target:
> throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> [ 214.597701] CFI failure at kobj_attr_show+0x19/0x30 (target:
> throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> [ 214.597836] CFI failure at kobj_attr_show+0x19/0x30 (target:
> throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> [ 214.597952] CFI failure at kobj_attr_show+0x19/0x30 (target:
> throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> [ 214.598071] CFI failure at kobj_attr_show+0x19/0x30 (target:
> throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> [ 214.598177] CFI failure at kobj_attr_show+0x19/0x30 (target:
> throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> [ 214.598307] CFI failure at kobj_attr_show+0x19/0x30 (target:
> throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> [ 214.598439] CFI failure at kobj_attr_show+0x19/0x30 (target:
> throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
> [ 214.598542] CFI failure at kobj_attr_show+0x19/0x30 (target:
> throttle_reason_bool_show+0x0/0x50 [i915]; expected type: 0xc527b809)
>
> With kCFI, indirect calls are validated against their expected type
> versus actual type and failures occur when the two types do not match.
> The ultimate issue is that these sysfs functions are expecting to be
> called via dev_attr_show() but they may also be called via
> kobj_attr_show(), as certain files are created under two different
> kobjects that have two different sysfs_ops in intel_gt_sysfs_register(),
> hence the warnings above. When accessing the gt_ files under
> /sys/devices/pci:00/:00:02.0/drm/card0, which are using the same
> sysfs functions, there are no violations, meaning the functions are
> being called with the proper type.
>
> To make everything work properly, adjust certain functions to match the
> type of the ->show() and ->store() members in 'struct kobj_attribute'.
> Add a macro to generate functions for that can be called via both
> dev_attr_{show,store}() or kobj_attr_{show,store}() so that they can be
> called through both kobject locations without violating kCFI and adjust
> the attribute groups to account for this.
>
> Link: https://github.com/ClangBuiltLinux/linux/issues/1716
> Reviewed-by: Andi Shyti
>
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
On Thu, Oct 27, 2022 at 9:53 AM Dixit, Ashutosh
wrote:
>
> On Thu, 27 Oct 2022 09:35:24 -0700, Nick Desaulniers wrote:
> >
>
> Hi Nick,
>
> > On Tue, Oct 25, 2022 at 5:18 PM Andi Shyti
> > wrote:
> > >
> > > Hi Ashutosh,
> > >
> > > > But I'd wait to hear from clang/llvm folks first.
> > >
> > > Yeah! Looking forward to getting some ideas :)
> >
> > Gwan-gyeong, which tree and set of configs are necessary to reproduce
> > the observed warning?
> >
> > Warnings are treated as errors, so I don't want this breaking our CI.
>
> The following or equivalent should do it:
>
> git clone https://anongit.freedesktop.org/git/drm/drm-tip
> git checkout drm-tip
>
> Kernel config:
> CONFIG_DRM_I915=m
> CONFIG_HWMON=y
>
> Files:
> drivers/gpu/drm/i915/i915_hwmon.c/.h
>
> Thanks for taking a look.
Thanks, I can repro now.
I haven't detangled the macro soup, but I noticed:
1. FIELD_PREP is defined in include/linux/bitfield.h which has the
following comment:
18 * Mask must be a compilation time constant.
2. hwm_field_scale_and_write only has one callsite.
The following patch works:
```
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 9e9781493025..6ac29d90b92a 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -101,7 +101,7 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
i915_reg_t rgadr,
static void
hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
- u32 field_msk, int nshift,
+ int nshift,
unsigned int scale_factor, long lval)
{
u32 nval;
@@ -111,8 +111,8 @@ hwm_field_scale_and_write(struct hwm_drvdata
*ddat, i915_reg_t rgadr,
/* Computation in 64-bits to avoid overflow. Round to nearest. */
nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
- bits_to_clear = field_msk;
- bits_to_set = FIELD_PREP(field_msk, nval);
+ bits_to_clear = PKG_PWR_LIM_1;
+ bits_to_set = FIELD_PREP(PKG_PWR_LIM_1, nval);
hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
bits_to_clear, bits_to_set);
@@ -406,7 +406,6 @@ hwm_power_write(struct hwm_drvdata *ddat, u32
attr, int chan, long val)
case hwmon_power_max:
hwm_field_scale_and_write(ddat,
hwmon->rg.pkg_rapl_limit,
- PKG_PWR_LIM_1,
hwmon->scl_shift_power,
SF_POWER, val);
return 0;
```
Though I'm not sure if you're planning to add further callsites of
hwm_field_scale_and_write with different field_masks?
Alternatively, (without the above diff),
```
diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
index c9be1657f03d..6f40f12bcf89 100644
--- a/include/linux/bitfield.h
+++ b/include/linux/bitfield.h
@@ -8,6 +8,7 @@
#define _LINUX_BITFIELD_H
#include
+#include
#include
/*
@@ -62,7 +63,7 @@
#define __BF_FIELD_CHECK(_mask, _reg, _val, _pfx) \
({ \
- BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \
+ BUILD_BUG_ON_MSG(!__is_constexpr(_mask),\
_pfx "mask is not constant"); \
BUILD_BUG_ON_MSG((_mask) == 0, _pfx "mask is zero");\
BUILD_BUG_ON_MSG(__builtin_constant_p(_val) ? \
```
will produce:
error: call to __compiletime_assert_407 declared with 'error'
attribute: FIELD_PREP: mask is not constant
I haven't tested if that change is also feasible (on top of fixing
this specific instance), but I think it might help avoid more of these
subtleties wrt. __builtin_constant_p that depende heavily on compiler,
compiler version, optimization level.
--
Thanks,
~Nick Desaulniers
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/display: Do both crawl and squash when changing cdclk
== Series Details ==
Series: series starting with [1/2] drm/i915/display: Do both crawl and squash
when changing cdclk
URL : https://patchwork.freedesktop.org/series/110199/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12304_full -> Patchwork_110199v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110199v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110199v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110199v1_full:
### IGT changes ###
Possible regressions
* igt@gem_create@hog-create@smem0:
- shard-apl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-apl3/igt@gem_create@hog-cre...@smem0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v1/shard-apl1/igt@gem_create@hog-cre...@smem0.html
Warnings
* igt@i915_pm_lpsp@screens-disabled:
- shard-tglb: [SKIP][3] ([i915#1902]) -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-tglb2/igt@i915_pm_l...@screens-disabled.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v1/shard-tglb8/igt@i915_pm_l...@screens-disabled.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_cursor_legacy@short-flip-before-cursor:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110199v1/shard-dg1-16/igt@kms_cursor_leg...@short-flip-before-cursor.html
Known issues
Here are the changes found in Patchwork_110199v1_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-glk: ([PASS][6], [PASS][7], [PASS][8], [PASS][9],
[PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15],
[PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21],
[PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27],
[PASS][28], [PASS][29], [PASS][30]) -> ([PASS][31], [PASS][32], [PASS][33],
[PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39],
[PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45],
[PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51],
[FAIL][52], [PASS][53], [PASS][54], [PASS][55]) ([i915#4392])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk9/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk9/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk9/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk8/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk8/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk8/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk7/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk7/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk7/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk6/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk6/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk6/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk5/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk5/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk5/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk3/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk3/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk3/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk3/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk2/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk2/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk2/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-glk1/boot.html
[30]:
Re: [Intel-gfx] [PATCH v3 6/6] freezer, sched: Rewrite core freezer logic
On Thu, Oct 27, 2022 at 04:09:01PM +0300, Ville Syrjälä wrote: > On Wed, Oct 26, 2022 at 01:43:00PM +0200, Peter Zijlstra wrote: > > Could you please give the below a spin? > > Thanks. I've added this to our CI branch. I'll try to keep and eye > on it in the coming days and let you know if anything still trips. > And I'll report back maybe ~middle of next week if we haven't caught > anything by then. Thanks!
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
On Thu, 27 Oct 2022 09:35:24 -0700, Nick Desaulniers wrote: > Hi Nick, > On Tue, Oct 25, 2022 at 5:18 PM Andi Shyti wrote: > > > > Hi Ashutosh, > > > > > But I'd wait to hear from clang/llvm folks first. > > > > Yeah! Looking forward to getting some ideas :) > > Gwan-gyeong, which tree and set of configs are necessary to reproduce > the observed warning? > > Warnings are treated as errors, so I don't want this breaking our CI. The following or equivalent should do it: git clone https://anongit.freedesktop.org/git/drm/drm-tip git checkout drm-tip Kernel config: CONFIG_DRM_I915=m CONFIG_HWMON=y Files: drivers/gpu/drm/i915/i915_hwmon.c/.h Thanks for taking a look. -- Ashutosh
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed helper
On Thu, Sep 29, 2022 at 05:56:36AM +, Gupta, Anshuman wrote:
>
> Quoting Tilak.
> > -Original Message-
> > From: Vivi, Rodrigo
> > Sent: Wednesday, September 28, 2022 8:00 PM
> > To: Nikula, Jani ; Gupta, Anshuman
> > ; Tangudu, Tilak
> > Cc: Wilson, Chris P ; Gupta, saurabhg
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed helper
> >
> > On Wed, 2022-09-28 at 12:31 +, Tangudu, Tilak wrote:
> > > +
> > >
> > > > -Original Message-
> > > > From: Tangudu, Tilak
> > > > Sent: Wednesday, September 28, 2022 5:46 PM
> > > > To: Tangudu, Tilak ; Vivi, Rodrigo
> > > > ; Nikula, Jani
> > > > Cc: Wilson, Chris P ; Gupta, saurabhg
> > > > ; intel-gfx@lists.freedesktop.org
> > > > Subject: RE: [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed helper
> > > >
> > > > @Nikula, Jani,
> > > >
> > > > As you know we have reused i915_gem_backup_suspend,
> > > > i915_gem_suspend_late and i915_gem_resume in
> > > > runtime_pm_suspend/resume callbacks ,they use runtime pm helpers
> > > > (intel_runtime_pm_get/put).
> > > > These need to be avoided in callbacks as they lead to deadlock.
> > > >
> > > > This can be done in two ways
> > > > 1) push runtime pm helpers usage at higher level functions, Which
> > > > requires code refactoring
> AFAIK pushing runtime PM to higher level need to asses case by case,
> Moving runtime PM wakeref to higher level will also burn more power as
> Wakeref will be active for longer period.
> This has to be resolve case by case, as a simple rule of thumb we don't need
> any wakeref in suspend path.
> So refactoring based upon suspend specific function and general use function
> would be the correct approach.
> Rest Jani and Rodrigo can provide their input here.
Okay, I'm convinced now that the better path is to use the status.
But this patch needs some clean-up and split.
Hopefully we can get the runtime_is_transitioninig function in the
linux/pm_runtime.h directly later, but one way or another, this
part of the patch needs to be separated with the '-2' return.
And that one with a different explanation and probably some enums?!
>
> Thanks,
> Anshuman Gupta.
>
> > > > (https://patchwork.freedesktop.org/series/105427/#rev2 is
> > > > partially implemented following this)
> > > > 2) Add is_intel_rpm_allowed helper and avoid the runtime helpers
> > > > (https://patchwork.freedesktop.org/series/105427/#rev3 is completely
> > > > implemented following this)
> > > >
> > > > Hope I gave you the context,
> > > >
> > > > As per your review comment in rev2, the below is implemented in
> > > > rev3
> > > >
> > > >
> > > > v2: Return -2 if runtime pm is not allowed in runtime_pm_get and
> > > > skip wakeref release in runtime_pm_put if wakeref value is -2. -
> > > > Jani N
> > > > Signed-off-by: Tilak Tangudu
> > > > "
> > > >
> > > > Rodrigo and myself want to trigger a discussion, if 2) is a proper
> > > > approach or go with 1) which requires lot of code refactoring.
> > > > Or Is there any way we follow 1) with less code refactoring.?
> > > > Or Do you think there is any other proper approach ?
> > > >
> > > > (Please note rev3 is not clean, d3cold off support need to be
> > > > restricted to Headless clients for now , we see some Display related
> > > > warnings in headed case ).
> >
> > I believe this warnings shows that the solution 2 has some flaws or corner
> > cases that we don't fully understand.
> >
> > I honestly believe we need to go with option 1, moving the runtime_pm_
> > {get,put} to higher levels.
> >
> > One way or another, we should not go partial here, but with full
> > implementation so we can see if we are really covered.
> >
> > Jani, thoughts?
> >
> > > >
> > > > Thanks
> > > > Tilak
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Intel-gfx On
> > > > > Behalf Of Tangudu, Tilak
> > > > > Sent: Thursday, August 4, 2022 11:03 AM
> > > > > To: Vivi, Rodrigo
> > > > > Cc: Nikula, Jani ; Wilson, Chris P
> > > > > ; Gupta, saurabhg
> > > > > ; intel-gfx@lists.freedesktop.org
> > > > > Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915: Added
> > > > > is_intel_rpm_allowed helper
> > > > >
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Vivi, Rodrigo
> > > > > > Sent: Thursday, August 4, 2022 2:01 AM
> > > > > > To: Tangudu, Tilak
> > > > > > Cc: Ewins, Jon ; Belgaumkar, Vinay
> > > > > > ; Roper, Matthew D
> > > > > > ; Wilson, Chris P
> > > > > > ; Nikula, Jani
> > > > > > ; Gupta, saurabhg
> > > > > > ; Gupta, Anshuman
> > > > > > ; Nilawar, Badal
> > > > > > ; Deak, Imre ;
> > > > > > Iddamsetty, Aravind ;
> > > > > > intel-gfx@lists.freedesktop.org
> > > > > > Subject: Re: [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed
> > > > > > helper
> > > > > >
> > > > > > On Thu, Jul 21, 2022 at 03:29:48PM +0530,
> > > > > > tilak.tang...@intel.com
> > > > wrote:
> > > > > > > From: Tilak Tangudu
Re: [Intel-gfx] [PATCH 1/8] drm/i915: Added is_intel_rpm_allowed helper
+Rafael
On Thu, Jul 21, 2022 at 03:29:48PM +0530, tilak.tang...@intel.com wrote:
> From: Tilak Tangudu
>
> Added is_intel_rpm_allowed function to query the runtime_pm
> status and disllow during suspending and resuming.
>
> v2: Return -2 if runtime pm is not allowed in runtime_pm_get
> and skip wakeref release in runtime_pm_put if wakeref value
> is -2. - Jani N
> Signed-off-by: Tilak Tangudu
> ---
> drivers/gpu/drm/i915/intel_runtime_pm.c | 23 ++-
> drivers/gpu/drm/i915/intel_runtime_pm.h | 1 +
> 2 files changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 6ed5786bcd29..704beeeb560b 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -113,7 +113,7 @@ static void untrack_intel_runtime_pm_wakeref(struct
> intel_runtime_pm *rpm,
> unsigned long flags, n;
> bool found = false;
>
> - if (unlikely(stack == -1))
> + if (unlikely(stack == -1) || unlikely(stack == -2))
> return;
>
> spin_lock_irqsave(>debug.lock, flags);
> @@ -320,6 +320,21 @@ untrack_all_intel_runtime_pm_wakerefs(struct
> intel_runtime_pm *rpm)
> }
>
> #endif
> +static int intel_runtime_pm_status(struct intel_runtime_pm *rpm)
> +{
> + return rpm->kdev->power.runtime_status;
> +}
> +
> +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm)
> +{
> + int rpm_status;
> +
> + rpm_status = intel_runtime_pm_status(rpm);
> + if (rpm_status == RPM_RESUMING || rpm_status == RPM_SUSPENDING)
Rafael, do you believe we could add something like this to linux/pm_runtime.h :
static inline bool pm_runtime_is_transitioning(struct device *dev)
{
return dev->power.runtime_status == RPM_RESUMING ||
dev->power.runtime_status == RPM_SUSPENDING;
}
> + return false;
> + else
> + return true;
> +}
>
> static void
> intel_runtime_pm_acquire(struct intel_runtime_pm *rpm, bool wakelock)
> @@ -354,6 +369,9 @@ static intel_wakeref_t __intel_runtime_pm_get(struct
> intel_runtime_pm *rpm,
>runtime_pm);
> int ret;
>
> + if (!is_intel_rpm_allowed(rpm))
> + return -2;
> +
> ret = pm_runtime_get_sync(rpm->kdev);
> drm_WARN_ONCE(>drm, ret < 0,
> "pm_runtime_get_sync() failed: %d\n", ret);
> @@ -490,6 +508,9 @@ static void __intel_runtime_pm_put(struct
> intel_runtime_pm *rpm,
>
> untrack_intel_runtime_pm_wakeref(rpm, wref);
>
> + if (wref == -2)
> + return;
> +
> intel_runtime_pm_release(rpm, wakelock);
>
> pm_runtime_mark_last_busy(kdev);
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h
> b/drivers/gpu/drm/i915/intel_runtime_pm.h
> index d9160e3ff4af..99418c3a934a 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.h
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
> @@ -173,6 +173,7 @@ void intel_runtime_pm_init_early(struct intel_runtime_pm
> *rpm);
> void intel_runtime_pm_enable(struct intel_runtime_pm *rpm);
> void intel_runtime_pm_disable(struct intel_runtime_pm *rpm);
> void intel_runtime_pm_driver_release(struct intel_runtime_pm *rpm);
> +bool is_intel_rpm_allowed(struct intel_runtime_pm *rpm);
>
> intel_wakeref_t intel_runtime_pm_get(struct intel_runtime_pm *rpm);
> intel_wakeref_t intel_runtime_pm_get_if_in_use(struct intel_runtime_pm *rpm);
> --
> 2.25.1
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/psr: Send update also on invalidate (rev2)
== Series Details ==
Series: drm/i915/psr: Send update also on invalidate (rev2)
URL : https://patchwork.freedesktop.org/series/110037/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12311 -> Patchwork_110037v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_110037v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_110037v2, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/index.html
Participating hosts (43 -> 41)
--
Missing(2): fi-ctg-p8600 fi-hsw-4770
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_110037v2:
### CI changes ###
Possible regressions
* boot:
- fi-ilk-650: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-ilk-650/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-ilk-650/boot.html
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@migrate:
- {bat-adlp-6}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/bat-adlp-6/igt@i915_selftest@l...@migrate.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/bat-adlp-6/igt@i915_selftest@l...@migrate.html
Known issues
Here are the changes found in Patchwork_110037v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[PASS][5] -> [FAIL][6] ([i915#7229])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@gem_lmem_swapping@random-engines:
- fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html
* igt@gem_tiled_blits@basic:
- fi-pnv-d510:[PASS][8] -> [SKIP][9] ([fdo#109271])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
* igt@i915_selftest@live@client:
- fi-kbl-soraka: [PASS][10] -> [INCOMPLETE][11] ([i915#7100])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-kbl-soraka/igt@i915_selftest@l...@client.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-kbl-soraka/igt@i915_selftest@l...@client.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [PASS][12] -> [DMESG-FAIL][13] ([i915#5334])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@guc_multi_lrc:
- fi-cfl-8109u: [PASS][14] -> [DMESG-WARN][15] ([i915#5904] /
[i915#7174]) +2 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-cfl-8109u/igt@i915_selftest@live@guc_multi_lrc.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-cfl-8109u/igt@i915_selftest@live@guc_multi_lrc.html
* igt@i915_selftest@live@late_gt_pm:
- fi-cfl-8109u: [PASS][16] -> [DMESG-WARN][17] ([i915#5904]) +32
similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8109u: [PASS][18] -> [DMESG-WARN][19] ([i915#5904] /
[i915#62]) +3 similar issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12311/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: NOTRUN -> [SKIP][20] ([fdo#111827])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110037v2/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-icl-u2: NOTRUN -> [SKIP][21] ([fdo#109285])
[21]:
Re: [Intel-gfx] [PATCH] drm/i915/hwmon: Fix a build error used with clang compiler
On Tue, Oct 25, 2022 at 5:18 PM Andi Shyti wrote: > > Hi Ashutosh, > > > But I'd wait to hear from clang/llvm folks first. > > Yeah! Looking forward to getting some ideas :) Gwan-gyeong, which tree and set of configs are necessary to reproduce the observed warning? Warnings are treated as errors, so I don't want this breaking our CI. -- Thanks, ~Nick Desaulniers
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/dmabuf: fix sg_table handling in map_dma_buf
== Series Details == Series: series starting with [1/2] drm/i915/dmabuf: fix sg_table handling in map_dma_buf URL : https://patchwork.freedesktop.org/series/110229/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask'
Re: [Intel-gfx] [PATCH v7 0/9] dyndbg: drm.debug adaptation
On Thu, Oct 27, 2022 at 09:37:52AM -0600, jim.cro...@gmail.com wrote:
> On Thu, Oct 27, 2022 at 9:08 AM Jason Baron wrote:
> >
> >
> >
> > On 10/21/22 05:18, Jani Nikula wrote:
> > > On Thu, 20 Oct 2022, Ville Syrjälä wrote:
> > >> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
> > >>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
> > hi Greg, Dan, Jason, DRM-folk,
> >
> > heres follow-up to V6:
> > rebased on driver-core/driver-core-next for -v6 applied bits (thanks)
> > rework drm_debug_enabled{_raw,_instrumented,} per Dan.
> >
> > It excludes:
> > nouveau parts (immature)
> > tracefs parts (I missed --to=Steve on v6)
> > split _ddebug_site and de-duplicate experiment (way unready)
> >
> > IOW, its the remaining commits of V6 on which Dan gave his Reviewed-by.
> >
> > If these are good to apply, I'll rebase and repost the rest separately.
> > >>>
> > >>> All now queued up, thanks.
> > >>
> > >> This stuff broke i915 debugs. When I first load i915 no debug prints are
> > >> produced. If I then go fiddle around in /sys/module/drm/parameters/debug
> > >> the debug prints start to suddenly work.
> > >
> > > Wait what? I always assumed the default behaviour would stay the same,
> > > which is usually how we roll. It's a regression in my books. We've got a
> > > CI farm that's not very helpful in terms of dmesg logging right now
> > > because of this.
> > >
> > > BR,
> > > Jani.
> > >
> > >
> >
> > That doesn't sound good - so you are saying that prior to this change some
> > of the drm debugs were default enabled. But now you have to manually enable
> > them?
> >
> > Thanks,
> >
> > -Jason
>
>
> Im just seeing this now.
> Any new details ?
No. We just disabled it as BROKEN for now. I was just today thinking
about sending that patch out if no solutin is forthcoming soon since
we need this working before 6.1 is released.
Pretty sure you should see the problem immediately with any driver
(at least if it's built as a module, didn't try builtin). Or at least
can't think what would make i915 any more special.
>
> I didnt knowingly change something, but since its apparently happening,
> heres a 1st WAG at a possible cause
>
> commit ccc2b496324c13e917ef05f563626f4e7826bef1
> Author: Jim Cromie
> Date: Sun Sep 11 23:28:51 2022 -0600
>
> drm_print: prefer bare printk KERN_DEBUG on generic fn
>
> drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
> which is a generic/service fn. The callsite is compile-time enabled
> by DEBUG in both DYNAMIC_DEBUG=y/n builds.
>
> For dyndbg builds, reverting this callsite back to bare printk is
> correcting a few anti-features:
>
> 1- callsite is generic, serves multiple drm users.
>it is soft-wired on currently by #define DEBUG
>could accidentally: #> echo -p > /proc/dynamic_debug/control
>
> 2- optional "decorations" by dyndbg are unhelpful/misleading here,
>they describe only the generic site, not end users
>
> IOW, 1,2 are unhelpful at best, and possibly confusing.
>
> reverting yields a nominal data and text shrink:
>
>textdata bss dec hex filename
> 462583 36604 54592 553779 87333 /kernel/drivers/gpu/drm/drm.ko
> 462515 36532 54592 553639 872a7
> -dirty/kernel/drivers/gpu/drm/drm.ko
>
> Signed-off-by: Jim Cromie
> Link:
> https://lore.kernel.org/r/20220912052852.1123868-9-jim.cro...@gmail.com
> Signed-off-by: Greg Kroah-Hartman
--
Ville Syrjälä
Intel
[Intel-gfx] ✗ Fi.CI.IGT: failure for i915: CAGF and RC6 changes for MTL (rev11)
== Series Details == Series: i915: CAGF and RC6 changes for MTL (rev11) URL : https://patchwork.freedesktop.org/series/108156/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12288_full -> Patchwork_108156v11_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108156v11_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108156v11_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 11) -- Additional (2): shard-rkl shard-dg1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108156v11_full: ### IGT changes ### Possible regressions * igt@i915_pm_rps@waitboost: - shard-tglb: [PASS][1] -> [FAIL][2] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-tglb6/igt@i915_pm_...@waitboost.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v11/shard-tglb1/igt@i915_pm_...@waitboost.html * igt@kms_cursor_legacy@cursor-vs-flip@varying-size: - shard-skl: [PASS][3] -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl4/igt@kms_cursor_legacy@cursor-vs-f...@varying-size.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v11/shard-skl2/igt@kms_cursor_legacy@cursor-vs-f...@varying-size.html Known issues Here are the changes found in Patchwork_108156v11_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-skl: ([PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [FAIL][26], [PASS][27], [PASS][28], [PASS][29]) ([i915#5032]) -> ([PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl10/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl10/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl10/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl9/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl9/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl9/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl9/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl7/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl7/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl7/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl7/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl6/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl6/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl6/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl6/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl4/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl4/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl4/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl4/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl3/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl3/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl3/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl10/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12288/shard-skl10/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v11/shard-skl9/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v11/shard-skl9/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v11/shard-skl9/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108156v11/shard-skl7/boot.html [34]:
Re: [Intel-gfx] [PATCH v7 0/9] dyndbg: drm.debug adaptation
On Thu, Oct 27, 2022 at 9:08 AM Jason Baron wrote:
>
>
>
> On 10/21/22 05:18, Jani Nikula wrote:
> > On Thu, 20 Oct 2022, Ville Syrjälä wrote:
> >> On Sat, Sep 24, 2022 at 03:02:34PM +0200, Greg KH wrote:
> >>> On Sun, Sep 11, 2022 at 11:28:43PM -0600, Jim Cromie wrote:
> hi Greg, Dan, Jason, DRM-folk,
>
> heres follow-up to V6:
> rebased on driver-core/driver-core-next for -v6 applied bits (thanks)
> rework drm_debug_enabled{_raw,_instrumented,} per Dan.
>
> It excludes:
> nouveau parts (immature)
> tracefs parts (I missed --to=Steve on v6)
> split _ddebug_site and de-duplicate experiment (way unready)
>
> IOW, its the remaining commits of V6 on which Dan gave his Reviewed-by.
>
> If these are good to apply, I'll rebase and repost the rest separately.
> >>>
> >>> All now queued up, thanks.
> >>
> >> This stuff broke i915 debugs. When I first load i915 no debug prints are
> >> produced. If I then go fiddle around in /sys/module/drm/parameters/debug
> >> the debug prints start to suddenly work.
> >
> > Wait what? I always assumed the default behaviour would stay the same,
> > which is usually how we roll. It's a regression in my books. We've got a
> > CI farm that's not very helpful in terms of dmesg logging right now
> > because of this.
> >
> > BR,
> > Jani.
> >
> >
>
> That doesn't sound good - so you are saying that prior to this change some
> of the drm debugs were default enabled. But now you have to manually enable
> them?
>
> Thanks,
>
> -Jason
Im just seeing this now.
Any new details ?
I didnt knowingly change something, but since its apparently happening,
heres a 1st WAG at a possible cause
commit ccc2b496324c13e917ef05f563626f4e7826bef1
Author: Jim Cromie
Date: Sun Sep 11 23:28:51 2022 -0600
drm_print: prefer bare printk KERN_DEBUG on generic fn
drm_print.c calls pr_debug() just once, from __drm_printfn_debug(),
which is a generic/service fn. The callsite is compile-time enabled
by DEBUG in both DYNAMIC_DEBUG=y/n builds.
For dyndbg builds, reverting this callsite back to bare printk is
correcting a few anti-features:
1- callsite is generic, serves multiple drm users.
it is soft-wired on currently by #define DEBUG
could accidentally: #> echo -p > /proc/dynamic_debug/control
2- optional "decorations" by dyndbg are unhelpful/misleading here,
they describe only the generic site, not end users
IOW, 1,2 are unhelpful at best, and possibly confusing.
reverting yields a nominal data and text shrink:
textdata bss dec hex filename
462583 36604 54592 553779 87333 /kernel/drivers/gpu/drm/drm.ko
462515 36532 54592 553639 872a7 -dirty/kernel/drivers/gpu/drm/drm.ko
Signed-off-by: Jim Cromie
Link:
https://lore.kernel.org/r/20220912052852.1123868-9-jim.cro...@gmail.com
Signed-off-by: Greg Kroah-Hartman
[Intel-gfx] [PATCH 2/2] drm/i915/selftests: exercise GPU access from the importer
Using PAGE_SIZE here potentially hides issues so bump that to something
larger. This should also make it possible for iommu to coalesce entries
for us. With that in place verify we can write from the GPU using the
importers sg_table, followed by checking that our writes match when read
from the CPU side.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/7306
Signed-off-by: Matthew Auld
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Ville Syrjälä
---
.../drm/i915/gem/selftests/i915_gem_dmabuf.c | 37 ++-
1 file changed, 35 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
index f2f3cfad807b..e55b255f69f8 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_dmabuf.c
@@ -6,6 +6,7 @@
#include "i915_drv.h"
#include "i915_selftest.h"
+#include "gt/intel_migrate.h"
#include "mock_dmabuf.h"
#include "selftests/mock_gem_device.h"
@@ -148,13 +149,15 @@ static int igt_dmabuf_import_same_driver(struct
drm_i915_private *i915,
struct drm_gem_object *import;
struct dma_buf *dmabuf;
struct dma_buf_attachment *import_attach;
+ struct i915_request *rq;
struct sg_table *st;
+ u32 *vaddr;
long timeout;
- int err;
+ int err, i;
force_different_devices = true;
- obj = __i915_gem_object_create_user(i915, PAGE_SIZE,
+ obj = __i915_gem_object_create_user(i915, SZ_8M,
regions, num_regions);
if (IS_ERR(obj)) {
pr_err("__i915_gem_object_create_user failed with err=%ld\n",
@@ -194,6 +197,19 @@ static int igt_dmabuf_import_same_driver(struct
drm_i915_private *i915,
goto out_import;
}
+ err = intel_context_migrate_clear(to_gt(i915)->migrate.context, NULL,
+ import_obj->mm.pages->sgl,
+ import_obj->cache_level,
+ false,
+ 0xdeadbeaf, );
+ if (rq) {
+ err = dma_resv_reserve_fences(obj->base.resv, 1);
+ if (!err)
+ dma_resv_add_fence(obj->base.resv, >fence,
+ DMA_RESV_USAGE_KERNEL);
+ i915_request_put(rq);
+ }
+
/*
* If the exported object is not in system memory, something
* weird is going on. TODO: When p2p is supported, this is no
@@ -206,6 +222,23 @@ static int igt_dmabuf_import_same_driver(struct
drm_i915_private *i915,
i915_gem_object_unlock(import_obj);
+ if (err)
+ goto out_import;
+
+ vaddr = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
+ if (IS_ERR(vaddr)) {
+ err = PTR_ERR(vaddr);
+ goto out_import;
+ }
+
+ for (i = 0; i < obj->base.size / sizeof(u32); i++) {
+ if (vaddr[i] != 0xdeadbeaf) {
+ pr_err("Data mismatch [%d]=%u\n", i, vaddr[i]);
+ err = -EINVAL;
+ goto out_import;
+ }
+ }
+
/* Now try a fake an importer */
import_attach = dma_buf_attach(dmabuf, obj->base.dev->dev);
if (IS_ERR(import_attach)) {
--
2.37.3
[Intel-gfx] [PATCH 1/2] drm/i915/dmabuf: fix sg_table handling in map_dma_buf
We need to iterate over the original entries here for the sg_table,
pulling out the struct page for each one, to be remapped. However
currently this incorrectly iterates over the final dma mapped entries,
which is likely just one gigantic sg entry if the iommu is enabled,
leading to us only mapping the first struct page (and any physically
contiguous pages following it), even if there is potentially lots more
data to follow.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7306
Signed-off-by: Matthew Auld
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index 07eee1c09aaf..05ebbdfd3b3b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -40,13 +40,13 @@ static struct sg_table *i915_gem_map_dma_buf(struct
dma_buf_attachment *attachme
goto err;
}
- ret = sg_alloc_table(st, obj->mm.pages->nents, GFP_KERNEL);
+ ret = sg_alloc_table(st, obj->mm.pages->orig_nents, GFP_KERNEL);
if (ret)
goto err_free;
src = obj->mm.pages->sgl;
dst = st->sgl;
- for (i = 0; i < obj->mm.pages->nents; i++) {
+ for (i = 0; i < obj->mm.pages->orig_nents; i++) {
sg_set_page(dst, sg_page(src), src->length, 0);
dst = sg_next(dst);
src = sg_next(src);
--
2.37.3
Re: [Intel-gfx] [RFC][PATCH v2 13/31] timers: drm: Use del_timer_shutdown() before freeing timer
[ quilt mail --send still can't handle unicode characters. Here's the patch again ] From: "Steven Rostedt (Google)" Before a timer is freed, del_timer_shutdown() must be called. Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/ Cc: "Noralf Trønnes" Cc: David Airlie Cc: Daniel Vetter Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: dri-de...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Steven Rostedt (Google) --- drivers/gpu/drm/gud/gud_pipe.c | 2 +- drivers/gpu/drm/i915/i915_sw_fence.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c index 7c6dc2bcd14a..5117a24ca4b5 100644 --- a/drivers/gpu/drm/gud/gud_pipe.c +++ b/drivers/gpu/drm/gud/gud_pipe.c @@ -272,7 +272,7 @@ static int gud_usb_bulk(struct gud_device *gdrm, size_t len) usb_sg_wait(); - if (!del_timer_sync()) + if (!del_timer_shutdown()) ret = -ETIMEDOUT; else if (ctx.sgr.status < 0) ret = ctx.sgr.status; diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c b/drivers/gpu/drm/i915/i915_sw_fence.c index 6fc0d1b89690..c762e99c8fdf 100644 --- a/drivers/gpu/drm/i915/i915_sw_fence.c +++ b/drivers/gpu/drm/i915/i915_sw_fence.c @@ -465,7 +465,7 @@ static void irq_i915_sw_fence_work(struct irq_work *wrk) struct i915_sw_dma_fence_cb_timer *cb = container_of(wrk, typeof(*cb), work); - del_timer_sync(>timer); + del_timer_shutdown(>timer); dma_fence_put(cb->dma); kfree_rcu(cb, rcu); -- 2.35.1
[Intel-gfx] [RFC][PATCH v2 13/31] timers: drm: Use del_timer_shutdown() before freeing timer
From: "Steven Rostedt (Google)" Before a timer is freed, del_timer_shutdown() must be called. Link: https://lore.kernel.org/all/20220407161745.7d675...@gandalf.local.home/ Cc: "Noralf Trønnes" Cc: David Airlie Cc: Daniel Vetter Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: Tvrtko Ursulin Cc: dri-de...@lists.freedesktop.org Cc: intel-gfx@lists.freedesktop.org Signed-off-by: Steven Rostedt (Google) --- drivers/gpu/drm/gud/gud_pipe.c | 2 +- drivers/gpu/drm/i915/i915_sw_fence.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c index 7c6dc2bcd14a..5117a24ca4b5 100644 --- a/drivers/gpu/drm/gud/gud_pipe.c +++ b/drivers/gpu/drm/gud/gud_pipe.c @@ -272,7 +272,7 @@ static int gud_usb_bulk(struct gud_device *gdrm, size_t len) usb_sg_wait(); - if (!del_timer_sync()) + if (!del_timer_shutdown()) ret = -ETIMEDOUT; else if (ctx.sgr.status < 0) ret = ctx.sgr.status; diff --git a/drivers/gpu/drm/i915/i915_sw_fence.c b/drivers/gpu/drm/i915/i915_sw_fence.c index 6fc0d1b89690..c762e99c8fdf 100644 --- a/drivers/gpu/drm/i915/i915_sw_fence.c +++ b/drivers/gpu/drm/i915/i915_sw_fence.c @@ -465,7 +465,7 @@ static void irq_i915_sw_fence_work(struct irq_work *wrk) struct i915_sw_dma_fence_cb_timer *cb = container_of(wrk, typeof(*cb), work); - del_timer_sync(>timer); + del_timer_shutdown(>timer); dma_fence_put(cb->dma); kfree_rcu(cb, rcu); -- 2.35.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for Add DG2 OA support (rev11)
== Series Details ==
Series: Add DG2 OA support (rev11)
URL : https://patchwork.freedesktop.org/series/107584/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12304_full -> Patchwork_107584v11_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_107584v11_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_107584v11_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_107584v11_full:
### IGT changes ###
Possible regressions
* igt@perf@global-sseu-config:
- shard-tglb: [PASS][1] -> [SKIP][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-tglb7/igt@p...@global-sseu-config.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-tglb2/igt@p...@global-sseu-config.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@perf@global-sseu-config:
- {shard-rkl}:[PASS][3] -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-rkl-1/igt@p...@global-sseu-config.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-rkl-6/igt@p...@global-sseu-config.html
- {shard-dg1}:[PASS][5] -> [SKIP][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-dg1-12/igt@p...@global-sseu-config.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-dg1-17/igt@p...@global-sseu-config.html
Known issues
Here are the changes found in Patchwork_107584v11_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@crc32:
- shard-iclb: NOTRUN -> [SKIP][7] ([i915#6230])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-iclb6/igt@api_intel...@crc32.html
- shard-tglb: NOTRUN -> [SKIP][8] ([i915#6230])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-tglb2/igt@api_intel...@crc32.html
* igt@feature_discovery@display-4x:
- shard-iclb: NOTRUN -> [SKIP][9] ([i915#1839])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-iclb6/igt@feature_discov...@display-4x.html
- shard-tglb: NOTRUN -> [SKIP][10] ([i915#1839])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-tglb2/igt@feature_discov...@display-4x.html
* igt@gem_ccs@block-copy-inplace:
- shard-tglb: NOTRUN -> [SKIP][11] ([i915#3555] / [i915#5325])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-tglb5/igt@gem_...@block-copy-inplace.html
- shard-iclb: NOTRUN -> [SKIP][12] ([i915#5327])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-iclb3/igt@gem_...@block-copy-inplace.html
* igt@gem_ctx_exec@basic-nohangcheck:
- shard-tglb: [PASS][13] -> [FAIL][14] ([i915#6268])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-tglb2/igt@gem_ctx_e...@basic-nohangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-tglb8/igt@gem_ctx_e...@basic-nohangcheck.html
* igt@gem_ctx_persistence@legacy-engines-hostile:
- shard-snb: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#1099])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-snb2/igt@gem_ctx_persiste...@legacy-engines-hostile.html
* igt@gem_ctx_sseu@mmap-args:
- shard-tglb: NOTRUN -> [SKIP][16] ([i915#280])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-tglb5/igt@gem_ctx_s...@mmap-args.html
* igt@gem_exec_balancer@parallel-contexts:
- shard-iclb: [PASS][17] -> [SKIP][18] ([i915#4525])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-iclb2/igt@gem_exec_balan...@parallel-contexts.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-iclb3/igt@gem_exec_balan...@parallel-contexts.html
* igt@gem_exec_fair@basic-flow@rcs0:
- shard-tglb: [PASS][19] -> [FAIL][20] ([i915#2842])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12304/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107584v11/shard-tglb8/igt@gem_exec_fair@basic-f...@rcs0.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-tglb: NOTRUN -> [FAIL][21] ([i915#2842])
[21]:
Re: [Intel-gfx] [PATCH 2/8] drm/i915/sdvo: Setup DDC fully before output init
On Thu, Oct 27, 2022 at 05:49:53PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 27, 2022 at 05:36:24PM +0300, Jani Nikula wrote:
> > On Wed, 26 Oct 2022, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Call intel_sdvo_select_ddc_bus() before initializing any
> > > of the outputs. And before that is functional (assuming no VBT)
> > > we have to set up the controlled_outputs thing. Otherwise DDC
> > > won't be functional during the output init but LVDS really
> > > needs it for the fixed mode setup.
> > >
> > > Note that the whole multi output support still looks very
> > > bogus, and more work will be needed to make it correct.
> > > But for now this should at least fix the LVDS EDID fixed mode
> > > setup.
> > >
> > > Cc: sta...@vger.kernel.org
> > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
> > > Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/i915/display/intel_sdvo.c | 31 +--
> > > 1 file changed, 12 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > index c6200a91a777..ccf81d616cb4 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > > @@ -2746,13 +2746,10 @@ intel_sdvo_dvi_init(struct intel_sdvo
> > > *intel_sdvo, int device)
> > > if (!intel_sdvo_connector)
> > > return false;
> > >
> > > - if (device == 0) {
> > > - intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
> > > + if (device == 0)
> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS0;
> > > - } else if (device == 1) {
> > > - intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
> > > + else if (device == 1)
> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS1;
> > > - }
> > >
> > > intel_connector = _sdvo_connector->base;
> > > connector = _connector->base;
> > > @@ -2807,7 +2804,6 @@ intel_sdvo_tv_init(struct intel_sdvo *intel_sdvo,
> > > int type)
> > > encoder->encoder_type = DRM_MODE_ENCODER_TVDAC;
> > > connector->connector_type = DRM_MODE_CONNECTOR_SVIDEO;
> > >
> > > - intel_sdvo->controlled_output |= type;
> > > intel_sdvo_connector->output_flag = type;
> > >
> > > if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> > > @@ -2848,13 +2844,10 @@ intel_sdvo_analog_init(struct intel_sdvo
> > > *intel_sdvo, int device)
> > > encoder->encoder_type = DRM_MODE_ENCODER_DAC;
> > > connector->connector_type = DRM_MODE_CONNECTOR_VGA;
> > >
> > > - if (device == 0) {
> > > - intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
> > > + if (device == 0)
> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB0;
> > > - } else if (device == 1) {
> > > - intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
> > > + else if (device == 1)
> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB1;
> > > - }
> > >
> > > if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> > > kfree(intel_sdvo_connector);
> > > @@ -2884,13 +2877,10 @@ intel_sdvo_lvds_init(struct intel_sdvo
> > > *intel_sdvo, int device)
> > > encoder->encoder_type = DRM_MODE_ENCODER_LVDS;
> > > connector->connector_type = DRM_MODE_CONNECTOR_LVDS;
> > >
> > > - if (device == 0) {
> > > - intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
> > > + if (device == 0)
> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS0;
> > > - } else if (device == 1) {
> > > - intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
> > > + else if (device == 1)
> > > intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS1;
> > > - }
> > >
> > > if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> > > kfree(intel_sdvo_connector);
> > > @@ -2945,8 +2935,14 @@ static u16 intel_sdvo_filter_output_flags(u16
> > > flags)
> > > static bool
> > > intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
> > > {
> > > + struct drm_i915_private *i915 = to_i915(intel_sdvo->base.base.dev);
> > > +
> > > flags = intel_sdvo_filter_output_flags(flags);
> > >
> > > + intel_sdvo->controlled_output = flags;
> > > +
> > > + intel_sdvo_select_ddc_bus(i915, intel_sdvo);
> >
> > AFAICT the ->controlled_outputs member could now be removed and just
> > passed by value here.
>
> Hmm. True. Though the whole thing is utter garbage anyway.
> intel_sdvo_guess_ddc_bus() really expects controlled_outputs
> to contain only a single bit. I guess it kinda works by luck
> most or the time, at least for single output devices.
> I suppose I can still include the controlled_outputs nukage
> into this patch.
On second though I think I'll do it as a followup. Less chance
of backport conflicts that way.
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 2/8] drm/i915/sdvo: Setup DDC fully before output init
On Thu, Oct 27, 2022 at 05:36:24PM +0300, Jani Nikula wrote:
> On Wed, 26 Oct 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Call intel_sdvo_select_ddc_bus() before initializing any
> > of the outputs. And before that is functional (assuming no VBT)
> > we have to set up the controlled_outputs thing. Otherwise DDC
> > won't be functional during the output init but LVDS really
> > needs it for the fixed mode setup.
> >
> > Note that the whole multi output support still looks very
> > bogus, and more work will be needed to make it correct.
> > But for now this should at least fix the LVDS EDID fixed mode
> > setup.
> >
> > Cc: sta...@vger.kernel.org
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
> > Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/display/intel_sdvo.c | 31 +--
> > 1 file changed, 12 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > index c6200a91a777..ccf81d616cb4 100644
> > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> > @@ -2746,13 +2746,10 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
> > int device)
> > if (!intel_sdvo_connector)
> > return false;
> >
> > - if (device == 0) {
> > - intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
> > + if (device == 0)
> > intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS0;
> > - } else if (device == 1) {
> > - intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
> > + else if (device == 1)
> > intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS1;
> > - }
> >
> > intel_connector = _sdvo_connector->base;
> > connector = _connector->base;
> > @@ -2807,7 +2804,6 @@ intel_sdvo_tv_init(struct intel_sdvo *intel_sdvo, int
> > type)
> > encoder->encoder_type = DRM_MODE_ENCODER_TVDAC;
> > connector->connector_type = DRM_MODE_CONNECTOR_SVIDEO;
> >
> > - intel_sdvo->controlled_output |= type;
> > intel_sdvo_connector->output_flag = type;
> >
> > if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> > @@ -2848,13 +2844,10 @@ intel_sdvo_analog_init(struct intel_sdvo
> > *intel_sdvo, int device)
> > encoder->encoder_type = DRM_MODE_ENCODER_DAC;
> > connector->connector_type = DRM_MODE_CONNECTOR_VGA;
> >
> > - if (device == 0) {
> > - intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
> > + if (device == 0)
> > intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB0;
> > - } else if (device == 1) {
> > - intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
> > + else if (device == 1)
> > intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB1;
> > - }
> >
> > if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> > kfree(intel_sdvo_connector);
> > @@ -2884,13 +2877,10 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo,
> > int device)
> > encoder->encoder_type = DRM_MODE_ENCODER_LVDS;
> > connector->connector_type = DRM_MODE_CONNECTOR_LVDS;
> >
> > - if (device == 0) {
> > - intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
> > + if (device == 0)
> > intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS0;
> > - } else if (device == 1) {
> > - intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
> > + else if (device == 1)
> > intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS1;
> > - }
> >
> > if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> > kfree(intel_sdvo_connector);
> > @@ -2945,8 +2935,14 @@ static u16 intel_sdvo_filter_output_flags(u16 flags)
> > static bool
> > intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
> > {
> > + struct drm_i915_private *i915 = to_i915(intel_sdvo->base.base.dev);
> > +
> > flags = intel_sdvo_filter_output_flags(flags);
> >
> > + intel_sdvo->controlled_output = flags;
> > +
> > + intel_sdvo_select_ddc_bus(i915, intel_sdvo);
>
> AFAICT the ->controlled_outputs member could now be removed and just
> passed by value here.
Hmm. True. Though the whole thing is utter garbage anyway.
intel_sdvo_guess_ddc_bus() really expects controlled_outputs
to contain only a single bit. I guess it kinda works by luck
most or the time, at least for single output devices.
I suppose I can still include the controlled_outputs nukage
into this patch.
What we really need to do is to have a ddc adapter per each
connector, and then each one can properly figure out its
own ddc bus. Right now there is some kind of horrible hack
in intel_sdvo_tmds_sink_detect() that probes all the ddc
buses if it didn't find anything on the one that got
chosen initally.
Fixing intel_sdvo_guess_ddc_bus() for that is
Re: [Intel-gfx] [PATCH 8/8] drm/i915/sdvo: Fix debug print
On Wed, 26 Oct 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Correctly indicate which outputs we support in the debug print. > > Signed-off-by: Ville Syrjälä Could change that to str_yes_no() or str_enabled_disabled() while at it. Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/display/intel_sdvo.c | 7 +-- > 1 file changed, 5 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c > b/drivers/gpu/drm/i915/display/intel_sdvo.c > index 58d147cc7633..e46b1ee4439d 100644 > --- a/drivers/gpu/drm/i915/display/intel_sdvo.c > +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c > @@ -3403,9 +3403,12 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv, > (intel_sdvo->caps.sdvo_inputs_mask & 0x2) ? 'Y' : 'N', > /* check currently supported outputs */ > intel_sdvo->caps.output_flags & > - (SDVO_OUTPUT_TMDS0 | SDVO_OUTPUT_RGB0) ? 'Y' : 'N', > + (SDVO_OUTPUT_TMDS0 | SDVO_OUTPUT_RGB0 | > + SDVO_OUTPUT_LVDS0 | SDVO_OUTPUT_SVID0 | > + SDVO_OUTPUT_CVBS0 | SDVO_OUTPUT_YPRPB0) ? 'Y' : 'N', > intel_sdvo->caps.output_flags & > - (SDVO_OUTPUT_TMDS1 | SDVO_OUTPUT_RGB1) ? 'Y' : 'N'); > + (SDVO_OUTPUT_TMDS1 | SDVO_OUTPUT_RGB1 | > + SDVO_OUTPUT_LVDS1) ? 'Y' : 'N'); > return true; > > err_output: -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 7/8] drm/i915/sdvo: Reduce copy-pasta in output setup
On Wed, 26 Oct 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Avoid having to call the output init function for each
> output type separately. We can just call the right one
> based on the "class" of the output.
>
> Technically we could just walk the bits of the bitmask
> but that could change the order in which we initialize
> the outputs. To avoid any behavioural changes keep to
> the same explicit probe order as before.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 66 +++
> 1 file changed, 33 insertions(+), 33 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 4784c05a1b71..58d147cc7633 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2922,11 +2922,38 @@ static u16 intel_sdvo_filter_output_flags(u16 flags)
> return flags;
> }
>
> +static bool intel_sdvo_output_init(struct intel_sdvo *sdvo, u16 type)
> +{
> + if (type & SDVO_TMDS_MASK)
> + return intel_sdvo_dvi_init(sdvo, type);
> + else if (type & SDVO_TV_MASK)
> + return intel_sdvo_tv_init(sdvo, type);
> + else if (type & SDVO_RGB_MASK)
> + return intel_sdvo_analog_init(sdvo, type);
> + else if (type & SDVO_LVDS_MASK)
> + return intel_sdvo_lvds_init(sdvo, type);
> + else
> + return false;
> +}
> +
> static bool
> intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo)
> {
> + static const u16 probe_order[] = {
> + SDVO_OUTPUT_TMDS0,
> + SDVO_OUTPUT_TMDS1,
> + /* TV has no XXX1 function block */
> + SDVO_OUTPUT_SVID0,
> + SDVO_OUTPUT_CVBS0,
> + SDVO_OUTPUT_YPRPB0,
> + SDVO_OUTPUT_RGB0,
> + SDVO_OUTPUT_RGB1,
> + SDVO_OUTPUT_LVDS0,
> + SDVO_OUTPUT_LVDS1,
> + };
> struct drm_i915_private *i915 = to_i915(intel_sdvo->base.base.dev);
> u16 flags;
> + int i;
>
> flags = intel_sdvo_filter_output_flags(intel_sdvo->caps.output_flags);
>
> @@ -2940,42 +2967,15 @@ intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo)
>
> intel_sdvo_select_ddc_bus(i915, intel_sdvo);
>
> - if (flags & SDVO_OUTPUT_TMDS0)
> - if (!intel_sdvo_dvi_init(intel_sdvo, SDVO_OUTPUT_TMDS0))
> - return false;
> -
> - if (flags & SDVO_OUTPUT_TMDS1)
> - if (!intel_sdvo_dvi_init(intel_sdvo, SDVO_OUTPUT_TMDS1))
> - return false;
> -
> - /* TV has no XXX1 function block */
> - if (flags & SDVO_OUTPUT_SVID0)
> - if (!intel_sdvo_tv_init(intel_sdvo, SDVO_OUTPUT_SVID0))
> - return false;
> -
> - if (flags & SDVO_OUTPUT_CVBS0)
> - if (!intel_sdvo_tv_init(intel_sdvo, SDVO_OUTPUT_CVBS0))
> - return false;
> + for (i = 0; i < ARRAY_SIZE(probe_order); i++) {
> + u16 type = flags & probe_order[i];
>
> - if (flags & SDVO_OUTPUT_YPRPB0)
> - if (!intel_sdvo_tv_init(intel_sdvo, SDVO_OUTPUT_YPRPB0))
> - return false;
> -
> - if (flags & SDVO_OUTPUT_RGB0)
> - if (!intel_sdvo_analog_init(intel_sdvo, SDVO_OUTPUT_RGB0))
> - return false;
> -
> - if (flags & SDVO_OUTPUT_RGB1)
> - if (!intel_sdvo_analog_init(intel_sdvo, SDVO_OUTPUT_RGB1))
> - return false;
> -
> - if (flags & SDVO_OUTPUT_LVDS0)
> - if (!intel_sdvo_lvds_init(intel_sdvo, SDVO_OUTPUT_LVDS0))
> - return false;
> + if (!type)
> + continue;
>
> - if (flags & SDVO_OUTPUT_LVDS1)
> - if (!intel_sdvo_lvds_init(intel_sdvo, SDVO_OUTPUT_LVDS1))
> + if (!intel_sdvo_output_init(intel_sdvo, type))
> return false;
> + }
>
> intel_sdvo->base.pipe_mask = ~0;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [RFC 13/17] cgroup/drm: Ability to periodically scan cgroups for over budget GPU usage
On 21/10/2022 23:52, T.J. Mercier wrote:
On Wed, Oct 19, 2022 at 10:34 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Add a scanning worker, which if enabled, periodically queries the cgroup
for GPU usage and if over budget (as configured by it's relative weight
share) notifies the drm core about the fact.
This is off by default and can be enabled by configuring a scanning
period using the drm.period_us cgroup control file.
Signed-off-by: Tvrtko Ursulin
---
Documentation/admin-guide/cgroup-v2.rst | 35 +-
kernel/cgroup/drm.c | 426 +++-
2 files changed, 459 insertions(+), 2 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index 1f3cca4e2572..318f463a1316 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2401,7 +2401,8 @@ HugeTLB Interface Files
DRM
---
-The DRM controller allows configuring static hierarchical scheduling priority.
+The DRM controller allows configuring static hierarchical scheduling priority
+and scheduling soft limits.
DRM static priority control
~~~
@@ -2458,6 +2459,38 @@ DRM static priority interface files
Read only integer showing the current effective priority level for the
group. Effective meaning taking into account the chain of inherited
+DRM scheduling soft limits
+~~
+
+Because of the heterogenous hardware and driver DRM capabilities, soft limits
+are implemented as a loose co-operative (bi-directional) interface between the
+controller and DRM core.
+
+The controller configures the GPU time allowed per group and periodically scans
+the belonging tasks to detect the over budget condition, at which point it
+invokes a callback notifying the DRM core of the condition.
+
+DRM core provides an API to query per process GPU utilization and 2nd API to
+receive notification from the cgroup controller when the group enters or exits
+the over budget condition.
+
+Individual DRM drivers which implement the interface are expected to act on
this
+in the best-effort manner only. There are no guarantees that the soft limits
+will be respected.
+
+DRM scheduling soft limits interface files
+~~
+
+ drm.weight
+ Standard cgroup weight based control [1, 1] used to configure the
+ relative distributing of GPU time between the sibling groups.
+
+ drm.period_us
+ An integer representing the period with which the controller should look
+ at the GPU usage by the group and potentially send the over/under budget
+ signal.
+ Value of zero (defaul) disables the soft limit checking.
+
Misc
diff --git a/kernel/cgroup/drm.c b/kernel/cgroup/drm.c
index 48f1eaaa1c07..af50ead1564a 100644
--- a/kernel/cgroup/drm.c
+++ b/kernel/cgroup/drm.c
@@ -18,6 +18,29 @@ struct drm_cgroup_state {
int priority;
int effective_priority;
unsigned int weight;
+ unsigned int period_us;
+
+ bool scanning_suspended;
+ unsigned int suspended_period_us;
+
+ struct delayed_work scan_work;
+
+ /*
+* Below fields are owned and updated by the scan worker. Either the
+* worker accesses them, or worker needs to be suspended and synced
+* before they can be touched from the outside.
+*/
+ bool scanned;
+
+ ktime_t prev_timestamp;
+
+ u64 sum_children_weights;
+ u64 children_active_us;
+ u64 per_s_budget_ns;
+ u64 prev_active_us;
+ u64 active_us;
+
+ bool over_budget;
};
static DEFINE_MUTEX(drmcg_mutex);
@@ -33,6 +56,31 @@ static inline struct drm_cgroup_state *get_task_drmcs(struct
task_struct *task)
return css_to_drmcs(task_get_css(task, drm_cgrp_id));
}
+static u64 drmcs_get_active_time_us(struct drm_cgroup_state *drmcs)
+{
+ struct cgroup *cgrp = drmcs->css.cgroup;
+ struct task_struct *task;
+ struct css_task_iter it;
+ u64 total = 0;
+
+ css_task_iter_start(>self,
+ CSS_TASK_ITER_PROCS | CSS_TASK_ITER_THREADED,
+ );
+ while ((task = css_task_iter_next())) {
+ u64 time;
+
+ /* Ignore kernel threads here. */
+ if (task->flags & PF_KTHREAD)
+ continue;
+
+ time = drm_pid_get_active_time_us(task_pid(task));
+ total += time;
+ }
+ css_task_iter_end();
+
+ return total;
+}
+
int drmcgroup_lookup_effective_priority(struct task_struct *task)
{
struct drm_cgroup_state *drmcs = get_task_drmcs(task);
@@ -202,9 +250,301 @@ static int drmcs_online(struct cgroup_subsys_state *css)
return 0;
}
+static void
+signal_drm_budget(struct drm_cgroup_state *drmcs, u64 usage, u64 budget)
+{
+ struct cgroup *cgrp = drmcs->css.cgroup;
+ struct
Re: [Intel-gfx] [PATCH 6/8] drm/i915/sdvo: Get rid of the output type<->device index stuff
On Wed, 26 Oct 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of this silly output type<->device index back and
> forth and just pass the output type directly to the corresponding
> output init function. This was already being done for TV outputs
> anyway.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 47 +--
> 1 file changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index d7943f9a96e7..4784c05a1b71 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2622,7 +2622,7 @@ intel_sdvo_unselect_i2c_bus(struct intel_sdvo *sdvo)
> }
>
> static bool
> -intel_sdvo_is_hdmi_connector(struct intel_sdvo *intel_sdvo, int device)
> +intel_sdvo_is_hdmi_connector(struct intel_sdvo *intel_sdvo)
> {
> return intel_sdvo_check_supp_encode(intel_sdvo);
> }
> @@ -2727,7 +2727,7 @@ static struct intel_sdvo_connector
> *intel_sdvo_connector_alloc(void)
> }
>
> static bool
> -intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo, int device)
> +intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo, u16 type)
> {
> struct drm_encoder *encoder = _sdvo->base.base;
> struct drm_connector *connector;
> @@ -2735,16 +2735,13 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
> int device)
> struct intel_connector *intel_connector;
> struct intel_sdvo_connector *intel_sdvo_connector;
>
> - DRM_DEBUG_KMS("initialising DVI device %d\n", device);
> + DRM_DEBUG_KMS("initialising DVI type 0x%x\n", type);
>
> intel_sdvo_connector = intel_sdvo_connector_alloc();
> if (!intel_sdvo_connector)
> return false;
>
> - if (device == 0)
> - intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS0;
> - else if (device == 1)
> - intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS1;
> + intel_sdvo_connector->output_flag = type;
>
> intel_connector = _sdvo_connector->base;
> connector = _connector->base;
> @@ -2764,7 +2761,7 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo, int
> device)
> encoder->encoder_type = DRM_MODE_ENCODER_TMDS;
> connector->connector_type = DRM_MODE_CONNECTOR_DVID;
>
> - if (intel_sdvo_is_hdmi_connector(intel_sdvo, device)) {
> + if (intel_sdvo_is_hdmi_connector(intel_sdvo)) {
> connector->connector_type = DRM_MODE_CONNECTOR_HDMIA;
> intel_sdvo_connector->is_hdmi = true;
> }
> @@ -2781,14 +2778,14 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
> int device)
> }
>
> static bool
> -intel_sdvo_tv_init(struct intel_sdvo *intel_sdvo, int type)
> +intel_sdvo_tv_init(struct intel_sdvo *intel_sdvo, u16 type)
> {
> struct drm_encoder *encoder = _sdvo->base.base;
> struct drm_connector *connector;
> struct intel_connector *intel_connector;
> struct intel_sdvo_connector *intel_sdvo_connector;
>
> - DRM_DEBUG_KMS("initialising TV type %d\n", type);
> + DRM_DEBUG_KMS("initialising TV type 0x%x\n", type);
>
> intel_sdvo_connector = intel_sdvo_connector_alloc();
> if (!intel_sdvo_connector)
> @@ -2820,14 +2817,14 @@ intel_sdvo_tv_init(struct intel_sdvo *intel_sdvo, int
> type)
> }
>
> static bool
> -intel_sdvo_analog_init(struct intel_sdvo *intel_sdvo, int device)
> +intel_sdvo_analog_init(struct intel_sdvo *intel_sdvo, u16 type)
> {
> struct drm_encoder *encoder = _sdvo->base.base;
> struct drm_connector *connector;
> struct intel_connector *intel_connector;
> struct intel_sdvo_connector *intel_sdvo_connector;
>
> - DRM_DEBUG_KMS("initialising analog device %d\n", device);
> + DRM_DEBUG_KMS("initialising analog type 0x%x\n", type);
>
> intel_sdvo_connector = intel_sdvo_connector_alloc();
> if (!intel_sdvo_connector)
> @@ -2839,10 +2836,7 @@ intel_sdvo_analog_init(struct intel_sdvo *intel_sdvo,
> int device)
> encoder->encoder_type = DRM_MODE_ENCODER_DAC;
> connector->connector_type = DRM_MODE_CONNECTOR_VGA;
>
> - if (device == 0)
> - intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB0;
> - else if (device == 1)
> - intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB1;
> + intel_sdvo_connector->output_flag = type;
>
> if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> kfree(intel_sdvo_connector);
> @@ -2853,7 +2847,7 @@ intel_sdvo_analog_init(struct intel_sdvo *intel_sdvo,
> int device)
> }
>
> static bool
> -intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo, int device)
> +intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo, u16 type)
> {
> struct drm_encoder *encoder = _sdvo->base.base;
> struct drm_i915_private *i915 = to_i915(encoder->dev);
> @@ -2861,7 +2855,7 @@
Re: [Intel-gfx] [PATCH 5/8] drm/i915/sdvo: Don't add DDC modes for LVDS
On Wed, 26 Oct 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Stop enumerating the DDC modes for SDVO LVDS outputs (outside
> the initial fixed mode setup). intel_panel_mode_valid() will
> just reject most of them anyway, and any left over are entirely
> pointless as they'll match the fixed mode hdisp+vdisp+vrefresh
> so no user visible effect from using them instead of the fixed
> mode.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 7 +--
> 1 file changed, 1 insertion(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index d432f70001b7..d7943f9a96e7 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2290,17 +2290,12 @@ static int intel_sdvo_get_tv_modes(struct
> drm_connector *connector)
>
> static int intel_sdvo_get_lvds_modes(struct drm_connector *connector)
> {
> - struct intel_sdvo *intel_sdvo =
> intel_attached_sdvo(to_intel_connector(connector));
> struct drm_i915_private *dev_priv = to_i915(connector->dev);
> - int num_modes = 0;
>
> drm_dbg_kms(_priv->drm, "[CONNECTOR:%d:%s]\n",
> connector->base.id, connector->name);
>
> - num_modes += intel_panel_get_modes(to_intel_connector(connector));
> - num_modes += intel_ddc_get_modes(connector, _sdvo->ddc);
> -
> - return num_modes;
> + return intel_panel_get_modes(to_intel_connector(connector));
> }
>
> static int intel_sdvo_get_modes(struct drm_connector *connector)
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4)
== Series Details ==
Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4)
URL : https://patchwork.freedesktop.org/series/108972/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12310 -> Patchwork_108972v4
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_108972v4 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_108972v4, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/index.html
Participating hosts (42 -> 39)
--
Additional (1): fi-kbl-soraka
Missing(4): fi-ctg-p8600 fi-hsw-4770 fi-rkl-11600 fi-icl-u2
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108972v4:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@gem_migrate:
- fi-kbl-soraka: NOTRUN -> [INCOMPLETE][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-kbl-soraka/igt@i915_selftest@live@gem_migrate.html
Known issues
Here are the changes found in Patchwork_108972v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271]) +9 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-kbl-soraka/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3
similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_blits@basic:
- fi-pnv-d510:[PASS][5] -> [SKIP][6] ([fdo#109271]) +2 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12310/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-pnv-d510/igt@gem_tiled_bl...@basic.html
* igt@i915_module_load@reload:
- fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] ([i915#1982])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12310/fi-skl-guc/igt@i915_module_l...@reload.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-skl-guc/igt@i915_module_l...@reload.html
* igt@i915_selftest@live@gt_pm:
- fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#1886])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html
* igt@i915_selftest@live@hangcheck:
- fi-rkl-guc: [PASS][10] -> [INCOMPLETE][11] ([i915#4983])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12310/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-rkl-guc/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-soraka: NOTRUN -> [SKIP][12] ([fdo#109271] / [fdo#111827]) +7
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-kbl-soraka/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_exec_suspend@basic-s3@smem:
- {bat-rplp-1}: [DMESG-WARN][13] ([i915#2867]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12310/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/bat-rplp-1/igt@gem_exec_suspend@basic...@smem.html
- {bat-adlm-1}: [DMESG-WARN][15] ([i915#2867]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12310/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_huc_copy@huc-copy:
- {bat-atsm-1}: [FAIL][17] ([i915#7029]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12310/bat-atsm-1/igt@gem_huc_c...@huc-copy.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/bat-atsm-1/igt@gem_huc_c...@huc-copy.html
* igt@i915_pm_rpm@module-reload:
- fi-cfl-8109u: [DMESG-FAIL][19] ([i915#62]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12310/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108972v4/fi-cfl-8109u/igt@i915_pm_...@module-reload.html
*
Re: [Intel-gfx] [PATCH 3/8] drm/i915/sdvo: Grab mode_config.mutex during LVDS init to avoid WARNs
On Wed, 26 Oct 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_mode_probed_add() is unhappy about being called w/o
> mode_config.mutex. Grab it during LVDS fixed mode setup
> to silence the WARNs.
>
> Cc: sta...@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
> Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index ccf81d616cb4..1eaaa7ec580e 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2899,8 +2899,12 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo,
> int device)
> intel_panel_add_vbt_sdvo_fixed_mode(intel_connector);
>
> if (!intel_panel_preferred_fixed_mode(intel_connector)) {
> + mutex_lock(>drm.mode_config.mutex);
> +
> intel_ddc_get_modes(connector, _sdvo->ddc);
> intel_panel_add_edid_fixed_modes(intel_connector, false);
> +
> + mutex_unlock(>drm.mode_config.mutex);
> }
>
> intel_panel_init(intel_connector);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 2/8] drm/i915/sdvo: Setup DDC fully before output init
On Wed, 26 Oct 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Call intel_sdvo_select_ddc_bus() before initializing any
> of the outputs. And before that is functional (assuming no VBT)
> we have to set up the controlled_outputs thing. Otherwise DDC
> won't be functional during the output init but LVDS really
> needs it for the fixed mode setup.
>
> Note that the whole multi output support still looks very
> bogus, and more work will be needed to make it correct.
> But for now this should at least fix the LVDS EDID fixed mode
> setup.
>
> Cc: sta...@vger.kernel.org
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7301
> Fixes: aa2b88074a56 ("drm/i915/sdvo: Fix multi function encoder stuff")
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 31 +--
> 1 file changed, 12 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index c6200a91a777..ccf81d616cb4 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2746,13 +2746,10 @@ intel_sdvo_dvi_init(struct intel_sdvo *intel_sdvo,
> int device)
> if (!intel_sdvo_connector)
> return false;
>
> - if (device == 0) {
> - intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS0;
> + if (device == 0)
> intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS0;
> - } else if (device == 1) {
> - intel_sdvo->controlled_output |= SDVO_OUTPUT_TMDS1;
> + else if (device == 1)
> intel_sdvo_connector->output_flag = SDVO_OUTPUT_TMDS1;
> - }
>
> intel_connector = _sdvo_connector->base;
> connector = _connector->base;
> @@ -2807,7 +2804,6 @@ intel_sdvo_tv_init(struct intel_sdvo *intel_sdvo, int
> type)
> encoder->encoder_type = DRM_MODE_ENCODER_TVDAC;
> connector->connector_type = DRM_MODE_CONNECTOR_SVIDEO;
>
> - intel_sdvo->controlled_output |= type;
> intel_sdvo_connector->output_flag = type;
>
> if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> @@ -2848,13 +2844,10 @@ intel_sdvo_analog_init(struct intel_sdvo *intel_sdvo,
> int device)
> encoder->encoder_type = DRM_MODE_ENCODER_DAC;
> connector->connector_type = DRM_MODE_CONNECTOR_VGA;
>
> - if (device == 0) {
> - intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB0;
> + if (device == 0)
> intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB0;
> - } else if (device == 1) {
> - intel_sdvo->controlled_output |= SDVO_OUTPUT_RGB1;
> + else if (device == 1)
> intel_sdvo_connector->output_flag = SDVO_OUTPUT_RGB1;
> - }
>
> if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> kfree(intel_sdvo_connector);
> @@ -2884,13 +2877,10 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo,
> int device)
> encoder->encoder_type = DRM_MODE_ENCODER_LVDS;
> connector->connector_type = DRM_MODE_CONNECTOR_LVDS;
>
> - if (device == 0) {
> - intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS0;
> + if (device == 0)
> intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS0;
> - } else if (device == 1) {
> - intel_sdvo->controlled_output |= SDVO_OUTPUT_LVDS1;
> + else if (device == 1)
> intel_sdvo_connector->output_flag = SDVO_OUTPUT_LVDS1;
> - }
>
> if (intel_sdvo_connector_init(intel_sdvo_connector, intel_sdvo) < 0) {
> kfree(intel_sdvo_connector);
> @@ -2945,8 +2935,14 @@ static u16 intel_sdvo_filter_output_flags(u16 flags)
> static bool
> intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
> {
> + struct drm_i915_private *i915 = to_i915(intel_sdvo->base.base.dev);
> +
> flags = intel_sdvo_filter_output_flags(flags);
>
> + intel_sdvo->controlled_output = flags;
> +
> + intel_sdvo_select_ddc_bus(i915, intel_sdvo);
AFAICT the ->controlled_outputs member could now be removed and just
passed by value here.
Reviewed-by: Jani Nikula
> +
> if (flags & SDVO_OUTPUT_TMDS0)
> if (!intel_sdvo_dvi_init(intel_sdvo, 0))
> return false;
> @@ -2987,7 +2983,6 @@ intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo,
> u16 flags)
> if (flags == 0) {
> unsigned char bytes[2];
>
> - intel_sdvo->controlled_output = 0;
> memcpy(bytes, _sdvo->caps.output_flags, 2);
> DRM_DEBUG_KMS("%s: Unknown SDVO output type (0x%02x%02x)\n",
> SDVO_NAME(intel_sdvo),
> @@ -3399,8 +3394,6 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv,
>*/
> intel_sdvo->base.cloneable = 0;
>
> - intel_sdvo_select_ddc_bus(dev_priv, intel_sdvo);
> -
> /* Set the input timing to the screen. Assume always
Re: [Intel-gfx] [PATCH 4/8] drm/i915/sdvo: Simplify output setup debugs
On Wed, 26 Oct 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of this funny byte based dumping of invalid output
> flags and just dump it as a single hex numbers. Also do that
> early since all the rest is going to get skipped anyway of
> the thing is zero.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 25 ++-
> 1 file changed, 11 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index 1eaaa7ec580e..d432f70001b7 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -199,7 +199,7 @@ to_intel_sdvo_connector(struct drm_connector *connector)
> container_of((conn_state), struct intel_sdvo_connector_state, base.base)
>
> static bool
> -intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags);
> +intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo);
> static bool
> intel_sdvo_tv_create_property(struct intel_sdvo *intel_sdvo,
> struct intel_sdvo_connector *intel_sdvo_connector,
> @@ -2937,11 +2937,18 @@ static u16 intel_sdvo_filter_output_flags(u16 flags)
> }
>
> static bool
> -intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
> +intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo)
> {
> struct drm_i915_private *i915 = to_i915(intel_sdvo->base.base.dev);
> + u16 flags;
>
> - flags = intel_sdvo_filter_output_flags(flags);
> + flags = intel_sdvo_filter_output_flags(intel_sdvo->caps.output_flags);
> +
> + if (flags == 0) {
> + DRM_DEBUG_KMS("%s: Unknown SDVO output type (0x%04x)\n",
> + SDVO_NAME(intel_sdvo),
> intel_sdvo->caps.output_flags);
> + return false;
> + }
>
> intel_sdvo->controlled_output = flags;
>
> @@ -2984,15 +2991,6 @@ intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo,
> u16 flags)
> if (!intel_sdvo_lvds_init(intel_sdvo, 1))
> return false;
>
> - if (flags == 0) {
> - unsigned char bytes[2];
> -
> - memcpy(bytes, _sdvo->caps.output_flags, 2);
> - DRM_DEBUG_KMS("%s: Unknown SDVO output type (0x%02x%02x)\n",
> - SDVO_NAME(intel_sdvo),
> - bytes[0], bytes[1]);
> - return false;
> - }
> intel_sdvo->base.pipe_mask = ~0;
>
> return true;
> @@ -3368,8 +3366,7 @@ bool intel_sdvo_init(struct drm_i915_private *dev_priv,
> intel_sdvo->colorimetry_cap =
> intel_sdvo_get_colorimetry_cap(intel_sdvo);
>
> - if (intel_sdvo_output_setup(intel_sdvo,
> - intel_sdvo->caps.output_flags) != true) {
> + if (!intel_sdvo_output_setup(intel_sdvo)) {
> drm_dbg_kms(_priv->drm,
> "SDVO output failed to setup on %s\n",
> SDVO_NAME(intel_sdvo));
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [RFC 02/17] drm: Track clients per owning process
On 20/10/2022 12:33, Christian König wrote: Am 20.10.22 um 09:34 schrieb Tvrtko Ursulin: On 20/10/2022 07:40, Christian König wrote: Am 19.10.22 um 19:32 schrieb Tvrtko Ursulin: From: Tvrtko Ursulin To enable propagation of settings from the cgroup drm controller to drm we need to start tracking which processes own which drm clients. Implement that by tracking the struct pid pointer of the owning process in a new XArray, pointing to a structure containing a list of associated struct drm_file pointers. Clients are added and removed under the filelist mutex and RCU list operations are used below it to allow for lockless lookup. That won't work easily like this. The problem is that file_priv->pid is usually not accurate these days: From the debugfs clients file: systemd-logind 773 0 y y 0 0 Xorg 1639 128 n n 1000 0 Xorg 1639 128 n n 1000 0 Xorg 1639 128 n n 1000 0 firefox 2945 128 n n 1000 0 Xorg 1639 128 n n 1000 0 Xorg 1639 128 n n 1000 0 Xorg 1639 128 n n 1000 0 Xorg 1639 128 n n 1000 0 chrome 35940 128 n n 1000 0 chrome 35940 0 n y 1000 1 chrome 35940 0 n y 1000 2 Xorg 1639 128 n n 1000 0 Xorg 1639 128 n n 1000 0 Xorg 1639 128 n n 1000 0 This is with glxgears and a bunch other OpenGL applications running. The problem is that for most applications the X/Wayland server is now opening the render node. The only exceptions in this case are apps using DRI2 (VA-API?). I always wanted to fix this and actually track who is using the file descriptor instead of who opened it, but never had the time to do this. There's a patch later in the series which allows client records to be migrated to a new PID, and then i915 patch to do that when fd is used for context create. That approach I think worked well enough in the past. So maybe it could be done in the DRM core at some suitable entry point. Yeah, that makes some sense. I think you should wire that inside drm_ioctl(), as far as I know more or less all uses of a file descriptor would go through that function. And maybe make that a stand alone patch, cause that can go upstream as a bug fix independently if you ask me. I've put it on my todo list to try and come up with something standalone for this problem. Will see if I manage to send it separately or perhaps will start the next cgroup controller RFC with those patches. I think you need to fix this problem first. And BTW: and unsigned long doesn't work as PID either with containers. This I am not familiar with so would like to hear more if you could point me in the right direction at least. Uff, I'm the wrong person to ask stuff like that. I just can say from experience because I've ran into that trap as well. My assumption was that struct pid *, which is what I store in unsigned long, would be unique in a system where there is a single kernel running, so as long as lifetimes are correct (released from tracking here when fd is closed, which is implicit on process exit) would work. You are suggesting that is not so? I think you should have the pointer to struct pid directly here since that is a reference counted structure IIRC. But don't ask me what the semantics is how to get or put a reference. Yeah I think I have all that. I track struct pid, with a reference, in drm client, and release it when file descriptor is closed (indirectly via the DRM close hook). All I need, I think, is for that mapping to answer me "which drm_file objects" are in use by this struct pid pointer. I don't see a problem with lifetimes or scope yet. Regards, Tvrtko
Re: [Intel-gfx] [RFC 00/17] DRM scheduling cgroup controller
Hi Tejun,
On 19/10/2022 19:45, Tejun Heo wrote:
Hello,
On Wed, Oct 19, 2022 at 06:32:37PM +0100, Tvrtko Ursulin wrote:
...
DRM static priority interface files
~~~
drm.priority_levels
One of:
1) And integer representing the minimum number of discrete priority
levels for the whole group.
Optionally followed by an asterisk ('*') indicating some DRM clients
in the group support more than the minimum number.
2) '0'- indicating one or more DRM clients in the group has no support
for static priority control.
3) 'n/a' - when there are no DRM clients in the configured group.
drm.priority
A read-write integer between -1 and 1 (inclusive) representing
an abstract static priority level.
drm.effective_priority
Read only integer showing the current effective priority level for the
group. Effective meaning taking into account the chain of inherited
From interface POV, this is a lot worse than the second proposal and I'd
really like to avoid this. Even if we go with mapping user priority
configuration to per-driver priorities, I'd much prefer if the interface
presented to user is weight based and let each driver try to match the
resulting hierarchical weight (ie. the absolute proportion a given cgroup
should have at the point in time) as best as they can rather than exposing
opaque priority numbers to userspace whose meaning isn't defined at all.
I actually somewhat agree here and this proposal was mainly motivated by
my desire to come up with *something* which would allow similar
_external_ control as it exists in the CPU and IO world (nice/ionice).
Because currently priority of GPU workloads cannot be controlled from
the outside at all. And especially if we consider pipelines composed of
stages where part of the processing is done on the CPU and part on the
GPU (or AI/VPU accelerator), then I think it would be really useful to
be able to do so.
To this effect I proposed connecting CPU nice with GPU priority, same as
it is connected for IO priority (so only if it hasn't been explicitly
changed away from the defaults), but at that point I was getting
feedback nudging me into direction of cgroups.
Looking at what's available in cgroups world now, I have spotted the
blkio.prio.class control. For my current use case (lower GPU scheduling
of background/unfocused windows) that would also work. Even if starting
with just two possible values - 'no-change' and 'idle' (to follow the IO
controller naming).
How would you view that as a proposal? It would be a bit tougher "sell"
to the DRM community, perhaps, given that many drivers do have
scheduling priority, but the concept of scheduling class is not really
there. Nevertheless a concept of normal-vs-background could be plausible
in my mind. It could be easily implemented by using the priority
controls available in many drivers.
DRM scheduling soft limits interface files
~~
drm.weight
Standard cgroup weight based control [1, 1] used to configure the
relative distributing of GPU time between the sibling groups.
Please take a look at io.weight. This can follow the same convention to
express both global and per-device weights.
drm.period_us
An integer representing the period with which the controller should look
at the GPU usage by the group and potentially send the over/under budget
signal.
Value of zero (defaul) disables the soft limit checking.
Can we not do period_us or at least make it a per-driver tuning parameter
exposed as module param? Weight, users can easily understand and configure.
period_us is a lot more an implementation detail. If we want to express the
trade-off between latency and bandwidth at the interface, we prolly should
encode the latency requirement in a more canonical way but let's leave that
for the future.
Yes agreed - for the moment (while RFC) it is handy for me to have it
controllable per group. But I agree a kernel global (modparam) should be
sufficient in the final solution.
drm.budget_supported
One of:
1) 'yes' - when all DRM clients in the group support the functionality.
2) 'no' - when at least one of the DRM clients does not support the
functionality.
3) 'n/a' - when there are no DRM clients in the group.
Yeah, I'm not sure about this. This isn't a per-cgroup property to begin
with and I'm not sure 'no' meaning at least one device not supporting is
intuitive. The distinction between 'no' and 'n/a' is kinda weird too. Please
drop this.
The idea actually is for this to be per-cgroup and potentially change
dynamically. It implements the concept of "observability", how I have,
perhaps clumsily, named it.
This is because we can have a mix of DRM file descriptors in a
Re: [Intel-gfx] [PATCH 1/8] drm/i915/sdvo: Filter out invalid outputs more sensibly
On Wed, 26 Oct 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We try to filter out the corresponding xxx1 output
> if the xxx0 output is not present. But the way that is
> being done is pretty awkward. Make it less so.
>
> Cc: sta...@vger.kernel.org
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_sdvo.c | 29 ++-
> 1 file changed, 23 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_sdvo.c
> b/drivers/gpu/drm/i915/display/intel_sdvo.c
> index cf8e80936d8e..c6200a91a777 100644
> --- a/drivers/gpu/drm/i915/display/intel_sdvo.c
> +++ b/drivers/gpu/drm/i915/display/intel_sdvo.c
> @@ -2925,16 +2925,33 @@ intel_sdvo_lvds_init(struct intel_sdvo *intel_sdvo,
> int device)
> return false;
> }
>
> -static bool
> -intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
> +static u16 intel_sdvo_filter_output_flags(u16 flags)
> {
> + flags &= SDVO_OUTPUT_MASK;
> +
> /* SDVO requires XXX1 function may not exist unless it has XXX0
> function.*/
> + if (!(flags & SDVO_OUTPUT_TMDS0))
> + flags &= ~SDVO_OUTPUT_TMDS1;
> +
> + if (!(flags & SDVO_OUTPUT_RGB0))
> + flags &= ~SDVO_OUTPUT_RGB1;
> +
> + if (!(flags & SDVO_OUTPUT_LVDS0))
> + flags &= ~SDVO_OUTPUT_LVDS1;
> +
> + return flags;
> +}
> +
> +static bool
> +intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo, u16 flags)
> +{
> + flags = intel_sdvo_filter_output_flags(flags);
>
> if (flags & SDVO_OUTPUT_TMDS0)
> if (!intel_sdvo_dvi_init(intel_sdvo, 0))
> return false;
>
> - if ((flags & SDVO_TMDS_MASK) == SDVO_TMDS_MASK)
> + if (flags & SDVO_OUTPUT_TMDS1)
> if (!intel_sdvo_dvi_init(intel_sdvo, 1))
> return false;
>
> @@ -2955,7 +2972,7 @@ intel_sdvo_output_setup(struct intel_sdvo *intel_sdvo,
> u16 flags)
> if (!intel_sdvo_analog_init(intel_sdvo, 0))
> return false;
>
> - if ((flags & SDVO_RGB_MASK) == SDVO_RGB_MASK)
> + if (flags & SDVO_OUTPUT_RGB1)
> if (!intel_sdvo_analog_init(intel_sdvo, 1))
> return false;
>
> @@ -2963,11 +2980,11 @@ intel_sdvo_output_setup(struct intel_sdvo
> *intel_sdvo, u16 flags)
> if (!intel_sdvo_lvds_init(intel_sdvo, 0))
> return false;
>
> - if ((flags & SDVO_LVDS_MASK) == SDVO_LVDS_MASK)
> + if (flags & SDVO_OUTPUT_LVDS1)
> if (!intel_sdvo_lvds_init(intel_sdvo, 1))
> return false;
>
> - if ((flags & SDVO_OUTPUT_MASK) == 0) {
> + if (flags == 0) {
> unsigned char bytes[2];
>
> intel_sdvo->controlled_output = 0;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v3 6/6] freezer, sched: Rewrite core freezer logic
On Wed, Oct 26, 2022 at 01:43:00PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 26, 2022 at 01:32:31PM +0300, Ville Syrjälä wrote:
> > Short form looks to be this:
> > <4>[ 355.437846] 1 lock held by rs:main Q:Reg/359:
> > <4>[ 355.438418] #0: 88844693b758 (>__lock){-.-.}-{2:2}, at:
> > raw_spin_rq_lock_nested+0x1b/0x30
> > <4>[ 355.438432] rs:main Q:Reg/359 holding locks while freezing
>
> > <4>[ 355.438429] [ cut here ]
> > <4>[ 355.438432] rs:main Q:Reg/359 holding locks while freezing
> > <4>[ 355.438439] WARNING: CPU: 0 PID: 6211 at kernel/freezer.c:134
> > __set_task_frozen+0x86/0xb0
> > <4>[ 355.438447] Modules linked in: snd_hda_intel i915 mei_hdcp mei_pxp
> > drm_display_helper drm_kms_helper vgem drm_shmem_helper snd_hda_codec_hdmi
> > snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_intel_dspcfg
> > snd_hda_codec snd_hwdep snd_hda_core snd_pcm prime_numbers ttm drm_buddy
> > syscopyarea sysfillrect sysimgblt fb_sys_fops fuse x86_pkg_temp_thermal
> > coretemp kvm_intel btusb btrtl btbcm btintel kvm irqbypass bluetooth
> > crct10dif_pclmul crc32_pclmul ecdh_generic ghash_clmulni_intel ecc e1000e
> > mei_me i2c_i801 ptp mei i2c_smbus pps_core lpc_ich video wmi [last
> > unloaded: drm_kms_helper]
> > <4>[ 355.438521] CPU: 0 PID: 6211 Comm: rtcwake Tainted: G U
> > 6.1.0-rc2-CI_DRM_12295-g3844a56a0922+ #1
> > <4>[ 355.438526] Hardware name: /NUC5i7RYB, BIOS
> > RYBDWi35.86A.0385.2020.0519.1558 05/19/2020
> > <4>[ 355.438530] RIP: 0010:__set_task_frozen+0x86/0xb0
> > <4>[ 355.438536] Code: 83 60 09 00 00 85 c0 74 2a 48 89 df e8 ac 02 9b 00
> > 8b 93 38 05 00 00 48 8d b3 48 07 00 00 48 c7 c7 a0 62 2b 82 e8 ee c1 9a 00
> > <0f> 0b c6 05 51 75 e3 02 01 c7 43 18 00 80 00 00 b8 00 80 00 00 5b
> > <4>[ 355.438541] RSP: 0018:c900012cbcf0 EFLAGS: 00010086
> > <4>[ 355.438546] RAX: RBX: 88810d090040 RCX:
> > 0004
> > <4>[ 355.438550] RDX: 0004 RSI: f5de RDI:
> >
> > <4>[ 355.438553] RBP: R08: R09:
> > c000f5de
> > <4>[ 355.438557] R10: 002335f8 R11: c900012cbb88 R12:
> > 0246
> > <4>[ 355.438561] R13: 81165430 R14: R15:
> > 88810d090040
> > <4>[ 355.438565] FS: 7fcfa43c7740() GS:88844680()
> > knlGS:
> > <4>[ 355.438569] CS: 0010 DS: ES: CR0: 80050033
> > <4>[ 355.438582] CR2: 7fceb380f6b8 CR3: 000117c5c004 CR4:
> > 003706f0
> > <4>[ 355.438586] Call Trace:
> > <4>[ 355.438589]
> > <4>[ 355.438592] task_call_func+0xc4/0xe0
> > <4>[ 355.438600] freeze_task+0x84/0xe0
> > <4>[ 355.438607] try_to_freeze_tasks+0xac/0x260
> > <4>[ 355.438616] freeze_processes+0x56/0xb0
> > <4>[ 355.438622] pm_suspend.cold.7+0x1d9/0x31c
> > <4>[ 355.438629] state_store+0x7b/0xe0
> > <4>[ 355.438637] kernfs_fop_write_iter+0x124/0x1c0
> > <4>[ 355.438644] vfs_write+0x34f/0x4e0
> > <4>[ 355.438655] ksys_write+0x57/0xd0
> > <4>[ 355.438663] do_syscall_64+0x3a/0x90
> > <4>[ 355.438670] entry_SYSCALL_64_after_hwframe+0x63/0xcd
>
> Oh I think I see what's going on.
>
> It's a very narrow race between schedule() and task_call_func().
>
> CPU0CPU1
>
> __schedule()
> rq_lock();
> prev_state = READ_ONCE(prev->__state);
> if (... && prev_state) {
> deactivate_tasl(rq, prev, ...)
> prev->on_rq = 0;
>
> task_call_func()
>
> raw_spin_lock_irqsave(p->pi_lock);
> state = READ_ONCE(p->__state);
> smp_rmb();
> if (... || p->on_rq) //
> false!!!
> rq = __task_rq_lock()
>
> ret = func();
>
> next = pick_next_task();
> rq = context_switch(prev, next)
> prepare_lock_switch()
> spin_release(&__rq_lockp(rq)->dep_map...)
>
>
>
> So while the task is on it's way out, it still holds rq->lock for a
> little while, and right then task_call_func() comes in and figures it
> doesn't need rq->lock anymore (because the task is already dequeued --
> but still running there) and then the __set_task_frozen() thing observes
> it's holding rq->lock and yells murder.
>
> Could you please give the below a spin?
Thanks. I've added this to our CI branch. I'll try to keep and eye
on it in the coming days and let you know if anything still trips.
And I'll report back maybe ~middle of next week if we haven't caught
anything by then.
>
> ---
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index cb2aa2b54c7a..f519f44cd4c7 100644
> --- a/kernel/sched/core.c
> +++
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4)
== Series Details == Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4) URL : https://patchwork.freedesktop.org/series/108972/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4)
== Series Details == Series: drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual (rev4) URL : https://patchwork.freedesktop.org/series/108972/ State : warning == Summary == Error: dim checkpatch failed d83d4490c920 drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm -:69: WARNING:LONG_LINE: line length of 104 exceeds 100 columns #69: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1105: + list_add(>userfault_link, _i915(obj->base.dev)->runtime_pm.lmem_userfault_list); total: 0 errors, 1 warnings, 0 checks, 147 lines checked 721d116886f7 drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual -:44: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #44: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:564: + GEM_BUG_ON(!obj->userfault_count); -:155: CHECK:UNCOMMENTED_DEFINITION: spinlock_t definition without comment #155: FILE: drivers/gpu/drm/i915/intel_runtime_pm.h:67: + spinlock_t lmem_userfault_lock; total: 0 errors, 1 warnings, 1 checks, 109 lines checked
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/ttm: rework on ttm_resource to use size_t type (rev2)
== Series Details == Series: drm/ttm: rework on ttm_resource to use size_t type (rev2) URL : https://patchwork.freedesktop.org/series/110129/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/110129/revisions/2/mbox/ not applied Applying: drm/ttm: rework on ttm_resource to use size_t type Using index info to reconstruct a base tree... M drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c M drivers/gpu/drm/amd/amdgpu/amdgpu_object.c M drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h M drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h M drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c M drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c M drivers/gpu/drm/i915/gem/i915_gem_ttm.c M drivers/gpu/drm/i915/i915_scatterlist.c M drivers/gpu/drm/i915/i915_ttm_buddy_manager.c M drivers/gpu/drm/i915/intel_region_ttm.c M drivers/gpu/drm/nouveau/nouveau_bo.c M drivers/gpu/drm/nouveau/nouveau_bo0039.c M drivers/gpu/drm/nouveau/nouveau_bo5039.c M drivers/gpu/drm/nouveau/nouveau_bo74c1.c M drivers/gpu/drm/nouveau/nouveau_bo85b5.c M drivers/gpu/drm/nouveau/nouveau_bo9039.c M drivers/gpu/drm/nouveau/nouveau_bo90b5.c M drivers/gpu/drm/nouveau/nouveau_boa0b5.c M drivers/gpu/drm/nouveau/nouveau_gem.c M drivers/gpu/drm/nouveau/nouveau_mem.c M drivers/gpu/drm/nouveau/nouveau_ttm.c M drivers/gpu/drm/radeon/radeon_cs.c M drivers/gpu/drm/radeon/radeon_object.c M drivers/gpu/drm/radeon/radeon_trace.h M drivers/gpu/drm/radeon/radeon_ttm.c M drivers/gpu/drm/ttm/ttm_bo.c M drivers/gpu/drm/ttm/ttm_bo_util.c M drivers/gpu/drm/ttm/ttm_bo_vm.c M drivers/gpu/drm/ttm/ttm_range_manager.c M drivers/gpu/drm/ttm/ttm_resource.c M drivers/gpu/drm/vmwgfx/vmwgfx_blit.c M drivers/gpu/drm/vmwgfx/vmwgfx_bo.c M drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c M drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c M drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c M drivers/gpu/drm/vmwgfx/vmwgfx_kms.c M drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c M include/drm/ttm/ttm_resource.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/vmwgfx/vmwgfx_kms.c CONFLICT (content): Merge conflict in drivers/gpu/drm/vmwgfx/vmwgfx_kms.c Auto-merging drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c Auto-merging drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c Auto-merging drivers/gpu/drm/vmwgfx/vmwgfx_bo.c Auto-merging drivers/gpu/drm/i915/gem/i915_gem_ttm.c Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 drm/ttm: rework on ttm_resource to use size_t type 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".
Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 14:09, Rafael J. Wysocki wrote: > > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/27/22 11:52, Matthew Garrett wrote: > >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >>> > The *only* behavior which actually is new in 6.1 is the native GPU > drivers now doing the equivalent of: > > if (acpi_video_get_backlight_type() != acpi_backlight_native) > return; > > In their backlight register paths (i), which is causing the native > backlight to disappear on your custom laptop setup and on Chromebooks > (with the Chromebooks case being already solved I hope.). > >>> > >>> It's causing the backlight control to vanish on any machine that isn't > >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall > >>> into that are either weird or Chromebooks or old, but there are machines > >>> that fall into that. > >> > >> I acknowledge that their are machines that fall into this category, > >> but I expect / hope there to be so few of them that we can just DMI > >> quirk our way out if this. > >> > >> I believe the old group to be small because: > >> > >> 1. Generally speaking the "native" control method is usually not > >> present on the really old (pre ACPI video spec) mobile GPUs. > >> > >> 2. On most old laptops I would still expect there to be a vendor > >> interface too, and if both get registered standard desktop environments > >> will prefer the vendor one, so then we need a native DMI quirk to > >> disable the vendor interface anyways and we already have a bunch of > >> those, so some laptops in this group are already covered by DMI quirks. > >> > >> And a fix for the Chromebook case is already in Linus' tree, which > >> just leaves the weird case, of which there will hopefully be only > >> a few. > >> > >> I do share your worry that this might break some machines, but > >> the only way to really find out is to get this code out there > >> I'm afraid. > >> > >> I have just written a blog post asking for people to check if > >> their laptop might be affected; and to report various details > >> to me of their laptop is affected: > >> > >> https://hansdegoede.dreamwidth.org/26548.html > >> > >> Lets wait and see how this goes. If I get (too) many reports then > >> I will send a revert of the addition of the: > >> > >> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >> return; > >> > >> check to the i915 / radeon / amd / nouveau drivers. > >> > >> (And if I only get a couple of reports I will probably just submit > >> DMI quirks for the affected models). > > > > Sounds reasonable to me, FWIW. > > > > And IIUC the check above can be overridden by passing > > acpi_backlight=native in the kernel command line, right? > > Right, that can be used as a quick workaround, but we really do > want this to work OOTB everywhere. Sure. My point is that if it doesn't work OOTB for someone, and say it used to, they can use the above workaround and report back.
Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi, On 10/27/22 14:09, Rafael J. Wysocki wrote: > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: >> >> Hi, >> >> On 10/27/22 11:52, Matthew Garrett wrote: >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: >>> The *only* behavior which actually is new in 6.1 is the native GPU drivers now doing the equivalent of: if (acpi_video_get_backlight_type() != acpi_backlight_native) return; In their backlight register paths (i), which is causing the native backlight to disappear on your custom laptop setup and on Chromebooks (with the Chromebooks case being already solved I hope.). >>> >>> It's causing the backlight control to vanish on any machine that isn't >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall >>> into that are either weird or Chromebooks or old, but there are machines >>> that fall into that. >> >> I acknowledge that their are machines that fall into this category, >> but I expect / hope there to be so few of them that we can just DMI >> quirk our way out if this. >> >> I believe the old group to be small because: >> >> 1. Generally speaking the "native" control method is usually not >> present on the really old (pre ACPI video spec) mobile GPUs. >> >> 2. On most old laptops I would still expect there to be a vendor >> interface too, and if both get registered standard desktop environments >> will prefer the vendor one, so then we need a native DMI quirk to >> disable the vendor interface anyways and we already have a bunch of >> those, so some laptops in this group are already covered by DMI quirks. >> >> And a fix for the Chromebook case is already in Linus' tree, which >> just leaves the weird case, of which there will hopefully be only >> a few. >> >> I do share your worry that this might break some machines, but >> the only way to really find out is to get this code out there >> I'm afraid. >> >> I have just written a blog post asking for people to check if >> their laptop might be affected; and to report various details >> to me of their laptop is affected: >> >> https://hansdegoede.dreamwidth.org/26548.html >> >> Lets wait and see how this goes. If I get (too) many reports then >> I will send a revert of the addition of the: >> >> if (acpi_video_get_backlight_type() != acpi_backlight_native) >> return; >> >> check to the i915 / radeon / amd / nouveau drivers. >> >> (And if I only get a couple of reports I will probably just submit >> DMI quirks for the affected models). > > Sounds reasonable to me, FWIW. > > And IIUC the check above can be overridden by passing > acpi_backlight=native in the kernel command line, right? Right, that can be used as a quick workaround, but we really do want this to work OOTB everywhere. Regards, Hans
Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede wrote: > > Hi, > > On 10/27/22 11:52, Matthew Garrett wrote: > > On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > > > >> The *only* behavior which actually is new in 6.1 is the native GPU > >> drivers now doing the equivalent of: > >> > >> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >> return; > >> > >> In their backlight register paths (i), which is causing the native > >> backlight to disappear on your custom laptop setup and on Chromebooks > >> (with the Chromebooks case being already solved I hope.). > > > > It's causing the backlight control to vanish on any machine that isn't > > ((acpi_video || vendor interface) || !acpi). Most machines that fall > > into that are either weird or Chromebooks or old, but there are machines > > that fall into that. > > I acknowledge that their are machines that fall into this category, > but I expect / hope there to be so few of them that we can just DMI > quirk our way out if this. > > I believe the old group to be small because: > > 1. Generally speaking the "native" control method is usually not > present on the really old (pre ACPI video spec) mobile GPUs. > > 2. On most old laptops I would still expect there to be a vendor > interface too, and if both get registered standard desktop environments > will prefer the vendor one, so then we need a native DMI quirk to > disable the vendor interface anyways and we already have a bunch of > those, so some laptops in this group are already covered by DMI quirks. > > And a fix for the Chromebook case is already in Linus' tree, which > just leaves the weird case, of which there will hopefully be only > a few. > > I do share your worry that this might break some machines, but > the only way to really find out is to get this code out there > I'm afraid. > > I have just written a blog post asking for people to check if > their laptop might be affected; and to report various details > to me of their laptop is affected: > > https://hansdegoede.dreamwidth.org/26548.html > > Lets wait and see how this goes. If I get (too) many reports then > I will send a revert of the addition of the: > > if (acpi_video_get_backlight_type() != acpi_backlight_native) > return; > > check to the i915 / radeon / amd / nouveau drivers. > > (And if I only get a couple of reports I will probably just submit > DMI quirks for the affected models). Sounds reasonable to me, FWIW. And IIUC the check above can be overridden by passing acpi_backlight=native in the kernel command line, right?
Re: [Intel-gfx] [PATCH v6 22/23] drm/vc4: vec: Add support for more analog TV standards
Hi,
On Thu, Oct 27, 2022 at 12:32:50AM +0200, Mateusz Kwiatkowski wrote:
> I've seen that you've incorporated my PAL60 patch. Thanks!
>
> I still yet need to test your v6 changes, but looking at this code with just
> my
> mental static analysis, it seems to me that the vc4_vec_encoder_atomic_check()
> should have the tv_mode validation. I should've added it to the PAL60 patch,
> but it somehow slipped my mind then.
>
> Anyway, I mentioned it previously here:
> https://lore.kernel.org/dri-devel/0f2beec2-ae8e-5579-f0b6-a73d9dae1...@gmail.com/
>
> It would look something like this, inside vc4_vec_encoder_atomic_check():
>
> + const struct vc4_vec_tv_mode *tv_mode =
> + vc4_vec_tv_mode_lookup(conn_state->tv.mode);
> +
> + if (!tv_mode)
> + return -EINVAL;
>
> Without this, it's possible to set e.g. 480i mode and SECAM, which will fail -
> but with the current version it will only fail in vc4_vec_encoder_enable(),
> which cannot return an error, and in my experience that causes a rather
> lengthy
> lockup.
ACK, I'll add it.
> But, like I said, I still need to actually test that with this version.
>
> Anyway, I was also thinking about adding support for the more "exotic"
> non-standard modes. NTSC-50 is, unfortunately, impossible with VEC, but
> PAL-N-60 and PAL-M-50 should work. The necessary vc4_vec_tv_modes entries
> would
> look something like:
>
> @@ -325,12 +325,28 @@ static const struct vc4_vec_tv_mode vc4_vec_tv_modes[]
> = {
> .config0 = VEC_CONFIG0_PAL_M_STD,
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
> },
> + {
> + /* PAL-M-50 */
> + .mode = DRM_MODE_TV_MODE_PAL,
> + .expected_htotal = 864,
> + .config0 = VEC_CONFIG0_PAL_BDGHI_STD,
> + .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
> + .custom_freq = 0x21e6efe3,
> + },
> {
> .mode = DRM_MODE_TV_MODE_PAL_N,
> .expected_htotal = 864,
> .config0 = VEC_CONFIG0_PAL_N_STD,
> .config1 = VEC_CONFIG1_C_CVBS_CVBS,
> },
> + {
> + /* PAL-N-60 */
> + .mode = DRM_MODE_TV_MODE_PAL_N,
> + .expected_htotal = 858,
> + .config0 = VEC_CONFIG0_PAL_M_STD,
> + .config1 = VEC_CONFIG1_C_CVBS_CVBS | VEC_CONFIG1_CUSTOM_FREQ,
> + .custom_freq = 0x21f69446,
> + },
> {
> .mode = DRM_MODE_TV_MODE_SECAM,
> .expected_htotal = 864,
>
> I'm not sure if we actually want to add that. The two arguments for doing so
> I can think of is 1. it should work, so "why not", 2. it means that more modes
> will result in _some_ kind of a valid signal, rather than erroring out, which
> is always a plus in my book. I can also think of a hypothetical use case, like
> someone in South America with an old PAL-N-only set that would nevertheless
> still sync at 60 Hz (perhaps with the help of messing with vertical hold
> knob),
> who would like to play retro games at 60 Hz in color.
>
> But on the other hand, I admit that this scenario is likely a stretch and the
> number of people who would actually use it is probably close to the proverbial
> two ;) So it's your call, I'm just leaving those settings here just in case.
This series is already pretty massive and is difficult to merge, so I'd
rather avoid to add new stuff in at every version. The changes look easy
enough to be a follow-up patch, so I'd prefer to do it that way.
Maxime
signature.asc
Description: PGP signature
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Audio stuff (rev2)
== Series Details == Series: drm/i915: Audio stuff (rev2) URL : https://patchwork.freedesktop.org/series/110188/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12302_full -> Patchwork_110188v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_110188v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_110188v2_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 11) -- Additional (2): shard-rkl shard-dg1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_110188v2_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock@vma: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110188v2/shard-skl6/igt@i915_selftest@m...@vma.html * igt@kms_cursor_legacy@short-flip-after-cursor@atomic-transitions: - shard-skl: [PASS][2] -> [FAIL][3] +1 similar issue [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl1/igt@kms_cursor_legacy@short-flip-after-cur...@atomic-transitions.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110188v2/shard-skl3/igt@kms_cursor_legacy@short-flip-after-cur...@atomic-transitions.html Known issues Here are the changes found in Patchwork_110188v2_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-skl: ([PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [FAIL][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [FAIL][50], [PASS][51]) ([i915#5032]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl9/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl10/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl10/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110188v2/shard-skl4/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110188v2/shard-skl4/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110188v2/shard-skl3/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110188v2/shard-skl3/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110188v2/shard-skl3/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_110188v2/shard-skl1/boot.html [34]:
Re: [Intel-gfx] [PATCH] i915/i915_gem_context: Remove debug message in i915_gem_context_create_ioctl
Hi Karolina, On Tue, Oct 25, 2022 at 11:19:03AM +0200, Karolina Drobnik wrote: > We know that as long as GEM context create ioctl succeeds, a context was > created. There is no need to write about it, especially when such a message > heavily pollutes dmesg and makes debugging actual errors harder. > > Suggested-by: Chris Wilson > Signed-off-by: Karolina Drobnik > Cc: Andi Shyti pushed to drm-intel-gt-next. Thank you! Andi > --- > drivers/gpu/drm/i915/gem/i915_gem_context.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c > b/drivers/gpu/drm/i915/gem/i915_gem_context.c > index 1e29b1e6d186..1456ca87c04e 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c > @@ -2298,7 +2298,6 @@ int i915_gem_context_create_ioctl(struct drm_device > *dev, void *data, > } > > args->ctx_id = id; > - drm_dbg(>drm, "HW context %d created\n", args->ctx_id); > > return 0; > > -- > 2.25.1
Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi, On 10/27/22 11:52, Matthew Garrett wrote: > On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >> The *only* behavior which actually is new in 6.1 is the native GPU >> drivers now doing the equivalent of: >> >> if (acpi_video_get_backlight_type() != acpi_backlight_native) >> return; >> >> In their backlight register paths (i), which is causing the native >> backlight to disappear on your custom laptop setup and on Chromebooks >> (with the Chromebooks case being already solved I hope.). > > It's causing the backlight control to vanish on any machine that isn't > ((acpi_video || vendor interface) || !acpi). Most machines that fall > into that are either weird or Chromebooks or old, but there are machines > that fall into that. I acknowledge that their are machines that fall into this category, but I expect / hope there to be so few of them that we can just DMI quirk our way out if this. I believe the old group to be small because: 1. Generally speaking the "native" control method is usually not present on the really old (pre ACPI video spec) mobile GPUs. 2. On most old laptops I would still expect there to be a vendor interface too, and if both get registered standard desktop environments will prefer the vendor one, so then we need a native DMI quirk to disable the vendor interface anyways and we already have a bunch of those, so some laptops in this group are already covered by DMI quirks. And a fix for the Chromebook case is already in Linus' tree, which just leaves the weird case, of which there will hopefully be only a few. I do share your worry that this might break some machines, but the only way to really find out is to get this code out there I'm afraid. I have just written a blog post asking for people to check if their laptop might be affected; and to report various details to me of their laptop is affected: https://hansdegoede.dreamwidth.org/26548.html Lets wait and see how this goes. If I get (too) many reports then I will send a revert of the addition of the: if (acpi_video_get_backlight_type() != acpi_backlight_native) return; check to the i915 / radeon / amd / nouveau drivers. (And if I only get a couple of reports I will probably just submit DMI quirks for the affected models). Regards, Hans
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: prepare for uC loading on MTL (rev5)
== Series Details == Series: drm/i915: prepare for uC loading on MTL (rev5) URL : https://patchwork.freedesktop.org/series/108925/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12302_full -> Patchwork_108925v5_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108925v5_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108925v5_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (9 -> 11) -- Additional (2): shard-rkl shard-dg1 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108925v5_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock@vma: - shard-skl: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v5/shard-skl1/igt@i915_selftest@m...@vma.html Warnings * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size: - shard-iclb: [FAIL][2] ([i915#2346]) -> [FAIL][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v5/shard-iclb7/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html Known issues Here are the changes found in Patchwork_108925v5_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-skl: ([PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27]) -> ([PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [FAIL][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47]) ([i915#5032]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl7/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl9/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl9/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl7/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl7/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl6/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl6/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl5/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl4/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl3/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl3/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl3/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl1/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl1/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl1/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl10/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl10/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12302/shard-skl10/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v5/shard-skl3/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v5/shard-skl10/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v5/shard-skl1/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v5/shard-skl1/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v5/shard-skl4/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108925v5/shard-skl4/boot.html [34]:
[Intel-gfx] [PULL] drm-misc-fixes
drm-misc-fixes-2022-10-27: drm-misc-fixes for v6.1-rc3: - Fix HPD on bridge/ps8640. - Stop leaking fences when killing a sched entity. - Avoid uninitialized read in aperture_remove_conflicting_pci_device() The following changes since commit 247f34f7b80357943234f93f247a1ae6b6c3a740: Linux 6.1-rc2 (2022-10-23 15:27:33 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2022-10-27 for you to fetch changes up to e0ba1a39b8dfe4f005bebdd85daa89e7382e26b7: fbdev/core: Avoid uninitialized read in aperture_remove_conflicting_pci_device() (2022-10-27 09:20:05 +0200) drm-misc-fixes for v6.1-rc3: - Fix HPD on bridge/ps8640. - Stop leaking fences when killing a sched entity. - Avoid uninitialized read in aperture_remove_conflicting_pci_device() Christian König (1): drm/scheduler: fix fence ref counting Douglas Anderson (1): drm/bridge: ps8640: Add back the 50 ms mystery delay after HPD Maarten Lankhorst (1): Merge remote-tracking branch 'drm/drm-fixes' into drm-misc-fixes Michał Mirosław (1): fbdev/core: Avoid uninitialized read in aperture_remove_conflicting_pci_device() drivers/gpu/drm/bridge/parade-ps8640.c | 25 +++-- drivers/gpu/drm/scheduler/sched_entity.c | 6 +- drivers/video/aperture.c | 5 + 3 files changed, 29 insertions(+), 7 deletions(-)
Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > The *only* behavior which actually is new in 6.1 is the native GPU > drivers now doing the equivalent of: > > if (acpi_video_get_backlight_type() != acpi_backlight_native) > return; > > In their backlight register paths (i), which is causing the native > backlight to disappear on your custom laptop setup and on Chromebooks > (with the Chromebooks case being already solved I hope.). It's causing the backlight control to vanish on any machine that isn't ((acpi_video || vendor interface) || !acpi). Most machines that fall into that are either weird or Chromebooks or old, but there are machines that fall into that. (I wrote https://mjg59.livejournal.com/127103.html over 12 years ago, so please do assume that I'm familiar with the complexities here :) ) > I agree this is a possible solution if this turns out to break more > systems and there is no other easy/clean way to fix those. But I would > greatly prefer to keep this change and stop the IMHO bad kernel behavior > of "registering multiple backlight-devices for a single panel and then > let userspace sort it out". If we're not able to make a correct policy decision in the kernel then punting it to userland seems like the right thing to do? The kernel absolutely *should* make the right decision where it has enough information to do so, but in this case the code that's making that decision doesn't have the full set of information.
Re: [Intel-gfx] [PATCH v3] drm/ttm: rework on ttm_resource to use size_t type
Am 27.10.22 um 11:12 schrieb Somalapuram Amaranath:
Change ttm_resource structure from num_pages to size_t size in bytes.
v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages
v1 -> v2: change bo->resource->size to bo->base.size at some places
v1 -> v2: remove the local variable
v1 -> v2: cleanup cmp_size_smaller_first()
v2 -> v3: adding missing PFN_UP in ttm_bo_vm_fault_reserved
Signed-off-by: Somalapuram Amaranath
Pushed to drm-misc-next.
Thanks,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/drm/i915/i915_scatterlist.c| 4 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++--
drivers/gpu/drm/i915/intel_region_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_mem.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_cs.c | 7 +--
drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 3 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +-
drivers/gpu/drm/ttm/ttm_resource.c | 14 ++
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 6 +++---
include/drm/ttm/ttm_resource.h | 4 ++--
38 files changed, 79 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 1f3302aebeff..44367f03316f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -144,7 +144,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
node->base.start = node->mm_nodes[0].start;
} else {
node->mm_nodes[0].start = 0;
- node->mm_nodes[0].size = node->base.num_pages;
+ node->mm_nodes[0].size = PFN_UP(node->base.size);
node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 2e8f6cd7a729..974e85d8b6cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -542,6 +542,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
size <<= PAGE_SHIFT;
+
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
@@ -776,7 +777,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
return 0;
}
- r = ttm_bo_kmap(>tbo, 0, bo->tbo.resource->num_pages, >kmap);
+ r = ttm_bo_kmap(>tbo, 0, PFN_UP(bo->tbo.base.size), >kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 6546552e596c..5c4f93ee0c57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -62,7 +62,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
if (!res)
goto fallback;
- BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
+ BUG_ON(start + size > res->size);
cur->mem_type = res->mem_type;
@@ -110,7 +110,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
cur->size = size;
Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi Matthew, On 10/27/22 11:11, Matthew Garrett wrote: > On Thu, Oct 27, 2022 at 10:51:45AM +0200, Hans de Goede wrote: > >> In their backlight register paths and this has been present since >> circa 2015. >> >> So both before and after my 6.1 refactor vendor is only preferred >> on devices which don't implement the ACPI video bus control method. > > Sorry, yes, that's the case I meant. > >> Just because a vendor interface is present does not mean that it will >> work. Unfortunately for none of the 3 main native/acpi_video/vendor >> backlight control methods the control method being present also guarantees >> that it will work. Which completely sucks, but it is the reality we >> have to deal with. > > But traditionally that's been logic that we've encoded into the vendor > drivers, which can take other factors into account when determining > whether the exposed interface works. You've now discarded that > knowledge. As I already mentioned in my previous email, the vendor drivers have been using something like: if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return; In their backlight register paths *since 2015* and even before then most of them called some acpi_video helper function to determine if ACPI video backlight control was available and skipped registering their backlight device if that returned true. And calling that acpi_video helper is as smart as they traditionally were. That + DMI quirks and we still have all those quirks. I was very careful with the refactoring landing in 6.1 to *not* change any of this. The *only* behavior which actually is new in 6.1 is the native GPU drivers now doing the equivalent of: if (acpi_video_get_backlight_type() != acpi_backlight_native) return; In their backlight register paths (i), which is causing the native backlight to disappear on your custom laptop setup and on Chromebooks (with the Chromebooks case being already solved I hope.). I am fully aware that this may turn out to also impact other laptops. I'm keeping out an eye for this and I have specifically reached-out to the coreboot community asking them to test 6.1 . > The only way you can maintain the degree of functionality > that 6.0 had is to move that determination into core code, or > alternatively support dynamic reattachment of backlight interfaces based > on vendor drivers loading later. An alternative would be to just revert > all of this, and instead only use this logic for the output property > interface (which would still result in different outcomes, but only for > userland that's choosing to use the new interface, so that's a different > problem). Yes I am considering dropping the "acpi_video_get_backlight_type() != acpi_backlight_native" check from at least the i915 driver if we get more bug reports and then indeed only do the equivalent of that check in the code for the new output property. I agree this is a possible solution if this turns out to break more systems and there is no other easy/clean way to fix those. But I would greatly prefer to keep this change and stop the IMHO bad kernel behavior of "registering multiple backlight-devices for a single panel and then let userspace sort it out". Regards, Hans i) Before this, the kernel was relying on userspace preferring acpi_video or vendor backlight devices over native if both are present and the native backlight devices were registered unconditionally.
Re: [Intel-gfx] [PATCH v6 16/23] drm/probe-helper: Provide a TV get_modes helper
Hi Mateusz,
On Thu, Oct 27, 2022 at 12:02:24AM +0200, Mateusz Kwiatkowski wrote:
> First of all, nice idea with the helper function that can be reused by
> different drivers. This is neat!
Yeah, it looked to me that given how complex it is, we don't want to
duplicate it in each and every driver.
> But looking at this function, it feels a bit overcomplicated. You're
> creating the two modes,
If reported as supported by the connector, yes.
> then checking which one is the default, then set the preferred one and
> possibly reorder them. Maybe it can be simplified somehow?
Possibly, but I couldn't find something simpler. We should only expose
the modes that the driver reports as supported, so we can have 0-2
modes. Then the preferred flag needs to be set on the default one like
you suggested.
But also, EDIDs define the preferred mode as either the mode with the
flag set or the first mode listed. So a lot of program just use the
heuristic to just pick the first mode listed.
So it might be that I'm too careful, but it still seems useful to me.
> Although when I tried to refactor it myself, I ended up with something that's
> not better at all. Maybe it needs to be complicated, after all :(
Yeah, that was my conclusion too :/
> Anyway, the current version seems to have a couple of bugs:
>
> > + if (tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL) ||
> > + tv_mode_supported(connector, DRM_MODE_TV_MODE_PAL_N) ||
> > + tv_mode_supported(connector, DRM_MODE_TV_MODE_SECAM)) {
> > + mode = drm_mode_analog_pal_576i(connector->dev);
> > + if (!mode)
> > + return 0;
> > +
> > + tv_modes[count++] = mode;
> > + }
>
> If the 480i mode has been created properly, but there's an error creating the
> 576i one (we enter the if (!mode) clause), the 480i mode will leak.
>
> > + if (count == 1) {
>
> You're handling the count == 1 case specially, but if count == 0, the rest of
> the code will assume that two modes exist and probably segfault in the
> process.
>
> > + ret = drm_object_property_get_default_value(>base,
> > +
> > dev->mode_config.tv_mode_property,
> > + _mode);
> > + if (ret)
> > + return 0;
> > +
> > + if (cmdline->tv_mode_specified)
> > + default_mode = cmdline->tv_mode;
>
> In case of an error (ret != 0), the modes created so far in the tv_modes array
> will leak.
Thanks for the review, I'll fix these bugs
> Also, I wonder if maybe the if (cmdline->tv_mode_specified) clause should go
> first? If we're going to use the default from cmdline, there's no point in
> even
> querying the property default value.
Maybe, I don't know. I find the flow of the code more readable that way,
but if you disagree I'll change it.
Maxime
signature.asc
Description: PGP signature
[Intel-gfx] [PATCH v3 1/2] drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm
Runtime pm is not really per GT, therefore it make sense to
move lmem_userfault_list, lmem_userfault_lock and
userfault_wakeref from intel_gt to intel_runtime_pm structure,
which is embedded to i915.
No functional change.
v2:
- Fixes the code comment nit. [Matt Auld]
Signed-off-by: Anshuman Gupta
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 6 +++---
drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 8
drivers/gpu/drm/i915/gt/intel_gt.c | 3 ---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 17 -
drivers/gpu/drm/i915/i915_gem.c | 4 +---
drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +
drivers/gpu/drm/i915/intel_runtime_pm.h | 22 ++
8 files changed, 36 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 73d9eda1d6b7..fd29a9053582 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -413,7 +413,7 @@ static vm_fault_t vm_fault_gtt(struct vm_fault *vmf)
vma->mmo = mmo;
if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
- intel_wakeref_auto(_gt(i915)->userfault_wakeref,
+ intel_wakeref_auto(>runtime_pm.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
if (write) {
@@ -589,9 +589,9 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
spin_unlock(>mmo.lock);
if (obj->userfault_count) {
- mutex_lock(_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+
mutex_lock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
list_del(>userfault_link);
-
mutex_unlock(_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+
mutex_unlock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
obj->userfault_count = 0;
}
}
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index e5bfb6be9f7a..0d812f4d787d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -27,7 +27,7 @@ void i915_gem_suspend(struct drm_i915_private *i915)
GEM_TRACE("%s\n", dev_name(i915->drm.dev));
- intel_wakeref_auto(_gt(i915)->userfault_wakeref, 0);
+ intel_wakeref_auto(>runtime_pm.userfault_wakeref, 0);
flush_workqueue(i915->wq);
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 84c91a4228a1..50c70796ca38 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1101,13 +1101,13 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
/* ttm_bo_vm_reserve() already has dma_resv_lock */
if (ret == VM_FAULT_NOPAGE && wakeref && !obj->userfault_count) {
obj->userfault_count = 1;
- mutex_lock(_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
- list_add(>userfault_link,
_gt(to_i915(obj->base.dev))->lmem_userfault_list);
-
mutex_unlock(_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
+
mutex_lock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
+ list_add(>userfault_link,
_i915(obj->base.dev)->runtime_pm.lmem_userfault_list);
+
mutex_unlock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
}
if (wakeref & CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
-
intel_wakeref_auto(_gt(to_i915(obj->base.dev))->userfault_wakeref,
+
intel_wakeref_auto(_i915(obj->base.dev)->runtime_pm.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
i915_ttm_adjust_lru(obj);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 2e796ffad911..8e914c4066ed 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -40,8 +40,6 @@ void intel_gt_common_init_early(struct intel_gt *gt)
{
spin_lock_init(gt->irq_lock);
- INIT_LIST_HEAD(>lmem_userfault_list);
- mutex_init(>lmem_userfault_lock);
INIT_LIST_HEAD(>closed_vma);
spin_lock_init(>closed_lock);
@@ -859,7 +857,6 @@ static int intel_gt_tile_setup(struct intel_gt *gt,
phys_addr_t phys_addr)
}
intel_uncore_init_early(gt->uncore, gt);
- intel_wakeref_auto_init(>userfault_wakeref, gt->uncore->rpm);
ret = intel_uncore_setup_mmio(gt->uncore, phys_addr);
if (ret)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 64aa2ba624fc..ff9251807f5c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
[Intel-gfx] [PATCH v3 2/2] drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
We had already grabbed the rpm wakeref at obj destruction path,
but it also required to grab the wakeref when object moves.
When i915_gem_object_release_mmap_offset() gets called by
i915_ttm_move_notify(), it will release the mmap offset without
grabbing the wakeref. We want to avoid that therefore,
grab the wakeref at i915_ttm_unmap_virtual() accordingly.
While doing that also changed the lmem_userfault_lock from
mutex to spinlock, as spinlock widely used for list.
Also changed if (obj->userfault_count) to
GEM_BUG_ON(!obj->userfault_count).
v2:
- Removed lmem_userfault_{list,lock} from intel_gt. [Matt Auld]
Fixes: ad74457a6b5a ("drm/i915/dgfx: Release mmap on rpm suspend")
Suggested-by: Matthew Auld
Signed-off-by: Anshuman Gupta
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 19 +---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 38
drivers/gpu/drm/i915/intel_runtime_pm.c | 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +-
4 files changed, 35 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index fd29a9053582..e63329bc8065 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -557,11 +557,13 @@ void
i915_gem_object_runtime_pm_release_mmap_offset(struct drm_i915_gem_object *
drm_vma_node_unmap(>base.vma_node, bdev->dev_mapping);
- if (obj->userfault_count) {
- /* rpm wakeref provide exclusive access */
- list_del(>userfault_link);
- obj->userfault_count = 0;
- }
+ /*
+* We have exclusive access here via runtime suspend. All other callers
+* must first grab the rpm wakeref.
+*/
+ GEM_BUG_ON(!obj->userfault_count);
+ list_del(>userfault_link);
+ obj->userfault_count = 0;
}
void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
@@ -587,13 +589,6 @@ void i915_gem_object_release_mmap_offset(struct
drm_i915_gem_object *obj)
spin_lock(>mmo.lock);
}
spin_unlock(>mmo.lock);
-
- if (obj->userfault_count) {
-
mutex_lock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
- list_del(>userfault_link);
-
mutex_unlock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
- obj->userfault_count = 0;
- }
}
static struct i915_mmap_offset *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 50c70796ca38..93639b2dd04f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -509,18 +509,9 @@ static int i915_ttm_shrink(struct drm_i915_gem_object
*obj, unsigned int flags)
static void i915_ttm_delete_mem_notify(struct ttm_buffer_object *bo)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
- intel_wakeref_t wakeref = 0;
if (bo->resource && !i915_ttm_is_ghost_object(bo)) {
- /* ttm_bo_release() already has dma_resv_lock */
- if (i915_ttm_cpu_maps_iomem(bo->resource))
- wakeref =
intel_runtime_pm_get(_i915(obj->base.dev)->runtime_pm);
-
__i915_gem_object_pages_fini(obj);
-
- if (wakeref)
-
intel_runtime_pm_put(_i915(obj->base.dev)->runtime_pm, wakeref);
-
i915_ttm_free_cached_io_rsgt(obj);
}
}
@@ -1098,12 +1089,15 @@ static vm_fault_t vm_fault_ttm(struct vm_fault *vmf)
if (ret == VM_FAULT_RETRY && !(vmf->flags & FAULT_FLAG_RETRY_NOWAIT))
goto out_rpm;
- /* ttm_bo_vm_reserve() already has dma_resv_lock */
+ /*
+* ttm_bo_vm_reserve() already has dma_resv_lock.
+* userfault_count is protected by dma_resv lock and rpm wakeref.
+*/
if (ret == VM_FAULT_NOPAGE && wakeref && !obj->userfault_count) {
obj->userfault_count = 1;
-
mutex_lock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
+
spin_lock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
list_add(>userfault_link,
_i915(obj->base.dev)->runtime_pm.lmem_userfault_list);
-
mutex_unlock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
+
spin_unlock(_i915(obj->base.dev)->runtime_pm.lmem_userfault_lock);
}
if (wakeref & CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
@@ -1169,7 +1163,27 @@ static u64 i915_ttm_mmap_offset(struct
drm_i915_gem_object *obj)
static void i915_ttm_unmap_virtual(struct drm_i915_gem_object *obj)
{
+ struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+ intel_wakeref_t wakeref = 0;
+
+ assert_object_held_shared(obj);
+
+ if (i915_ttm_cpu_maps_iomem(bo->resource)) {
+ wakeref =
intel_runtime_pm_get(_i915(obj->base.dev)->runtime_pm);
+
+
[Intel-gfx] [PATCH v3 0/2] drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual
v3 series rev fixes the nit review comment. Anshuman Gupta (2): drm/i915: Encapsulate lmem rpm stuff in intel_runtime_pm drm/i915/dgfx: Grab wakeref at i915_ttm_unmap_virtual drivers/gpu/drm/i915/gem/i915_gem_mman.c | 21 +--- drivers/gpu/drm/i915/gem/i915_gem_pm.c | 2 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 42 drivers/gpu/drm/i915/gt/intel_gt.c | 3 -- drivers/gpu/drm/i915/gt/intel_gt_types.h | 17 -- drivers/gpu/drm/i915/i915_gem.c | 4 +-- drivers/gpu/drm/i915/intel_runtime_pm.c | 5 +++ drivers/gpu/drm/i915/intel_runtime_pm.h | 22 + 8 files changed, 65 insertions(+), 51 deletions(-) -- 2.38.0
[Intel-gfx] [PATCH v3] drm/ttm: rework on ttm_resource to use size_t type
Change ttm_resource structure from num_pages to size_t size in bytes.
v1 -> v2: change PFN_UP(dst_mem->size) to ttm->num_pages
v1 -> v2: change bo->resource->size to bo->base.size at some places
v1 -> v2: remove the local variable
v1 -> v2: cleanup cmp_size_smaller_first()
v2 -> v3: adding missing PFN_UP in ttm_bo_vm_fault_reserved
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_trace.h | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 6 +++---
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 8
drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 2 +-
drivers/gpu/drm/i915/i915_scatterlist.c| 4 ++--
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 12 ++--
drivers/gpu/drm/i915/intel_region_ttm.c| 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo0039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo5039.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo74c1.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo85b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo9039.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo90b5.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_boa0b5.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_gem.c | 5 ++---
drivers/gpu/drm/nouveau/nouveau_mem.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_ttm.c | 2 +-
drivers/gpu/drm/radeon/radeon_cs.c | 7 +--
drivers/gpu/drm/radeon/radeon_object.c | 4 ++--
drivers/gpu/drm/radeon/radeon_trace.h | 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_bo.c | 3 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 6 +++---
drivers/gpu/drm/ttm/ttm_bo_vm.c| 4 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c| 2 +-
drivers/gpu/drm/ttm/ttm_resource.c | 14 ++
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 6 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c| 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_page_dirty.c | 6 +++---
include/drm/ttm/ttm_resource.h | 4 ++--
38 files changed, 79 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 1f3302aebeff..44367f03316f 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -144,7 +144,7 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
node->base.start = node->mm_nodes[0].start;
} else {
node->mm_nodes[0].start = 0;
- node->mm_nodes[0].size = node->base.num_pages;
+ node->mm_nodes[0].size = PFN_UP(node->base.size);
node->base.start = AMDGPU_BO_INVALID_OFFSET;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 2e8f6cd7a729..974e85d8b6cc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -542,6 +542,7 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
size <<= PAGE_SHIFT;
+
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
@@ -776,7 +777,7 @@ int amdgpu_bo_kmap(struct amdgpu_bo *bo, void **ptr)
return 0;
}
- r = ttm_bo_kmap(>tbo, 0, bo->tbo.resource->num_pages, >kmap);
+ r = ttm_bo_kmap(>tbo, 0, PFN_UP(bo->tbo.base.size), >kmap);
if (r)
return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
index 6546552e596c..5c4f93ee0c57 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_res_cursor.h
@@ -62,7 +62,7 @@ static inline void amdgpu_res_first(struct ttm_resource *res,
if (!res)
goto fallback;
- BUG_ON(start + size > res->num_pages << PAGE_SHIFT);
+ BUG_ON(start + size > res->size);
cur->mem_type = res->mem_type;
@@ -110,7 +110,7 @@ static inline void amdgpu_res_first(struct ttm_resource
*res,
cur->size = size;
cur->remaining = size;
cur->node = NULL;
- WARN_ON(res && start + size > res->num_pages << PAGE_SHIFT);
+
Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
On Thu, Oct 27, 2022 at 10:51:45AM +0200, Hans de Goede wrote: > In their backlight register paths and this has been present since > circa 2015. > > So both before and after my 6.1 refactor vendor is only preferred > on devices which don't implement the ACPI video bus control method. Sorry, yes, that's the case I meant. > Just because a vendor interface is present does not mean that it will > work. Unfortunately for none of the 3 main native/acpi_video/vendor > backlight control methods the control method being present also guarantees > that it will work. Which completely sucks, but it is the reality we > have to deal with. But traditionally that's been logic that we've encoded into the vendor drivers, which can take other factors into account when determining whether the exposed interface works. You've now discarded that knowledge. The only way you can maintain the degree of functionality that 6.0 had is to move that determination into core code, or alternatively support dynamic reattachment of backlight interfaces based on vendor drivers loading later. An alternative would be to just revert all of this, and instead only use this logic for the output property interface (which would still result in different outcomes, but only for userland that's choosing to use the new interface, so that's a different problem).
Re: [Intel-gfx] [PATCH] drm/i915: stop abusing swiotlb_max_segment
On 20/10/2022 12:03, Christoph Hellwig wrote:
From: Robert Beckett
swiotlb_max_segment used to return either the maximum size that swiotlb
could bounce, or for Xen PV PAGE_SIZE even if swiotlb could bounce buffer
larger mappings. This made i915 on Xen PV work as it bypasses the
coherency aspect of the DMA API and can't cope with bounce buffering
and this avoided bounce buffering for the Xen/PV case.
So instead of adding this hack back, check for Xen/PV directly in i915
for the Xen case and otherwise use the proper DMA API helper to query
the maximum mapping size.
Replace swiotlb_max_segment() calls with dma_max_mapping_size().
In i915_gem_object_get_pages_internal() no longer consider max_segment
only if CONFIG_SWIOTLB is enabled. There can be other (iommu related)
causes of specific max segment sizes.
Fixes: a2daa27c0c61 ("swiotlb: simplify swiotlb_max_segment")
Reported-by: Marek Marczykowski-Górecki
Signed-off-by: Robert Beckett
Signed-off-by: Christoph Hellwig
[hch: added the Xen hack, rewrote the changelog]
Reviewed-by: Tvrtko Ursulin
I'll merge this in a minute - thanks again for the cleanup!
Regards,
Tvrtko
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 19 +++
drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 4 +--
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
drivers/gpu/drm/i915/i915_scatterlist.h | 34
5 files changed, 29 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index c698f95af15fe..629acb403a2c9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -6,7 +6,6 @@
#include
#include
-#include
#include "i915_drv.h"
#include "i915_gem.h"
@@ -38,22 +37,12 @@ static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
struct scatterlist *sg;
unsigned int sg_page_sizes;
unsigned int npages;
- int max_order;
+ int max_order = MAX_ORDER;
+ unsigned int max_segment;
gfp_t gfp;
- max_order = MAX_ORDER;
-#ifdef CONFIG_SWIOTLB
- if (is_swiotlb_active(obj->base.dev->dev)) {
- unsigned int max_segment;
-
- max_segment = swiotlb_max_segment();
- if (max_segment) {
- max_segment = max_t(unsigned int, max_segment,
- PAGE_SIZE) >> PAGE_SHIFT;
- max_order = min(max_order, ilog2(max_segment));
- }
- }
-#endif
+ max_segment = i915_sg_segment_size(i915->drm.dev) >> PAGE_SHIFT;
+ max_order = min(max_order, get_order(max_segment));
gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
if (IS_I965GM(i915) || IS_I965G(i915)) {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
index f42ca1179f373..11125c32dd35d 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_shmem.c
@@ -194,7 +194,7 @@ static int shmem_get_pages(struct drm_i915_gem_object *obj)
struct intel_memory_region *mem = obj->mm.region;
struct address_space *mapping = obj->base.filp->f_mapping;
const unsigned long page_count = obj->base.size / PAGE_SIZE;
- unsigned int max_segment = i915_sg_segment_size();
+ unsigned int max_segment = i915_sg_segment_size(i915->drm.dev);
struct sg_table *st;
struct sgt_iter sgt_iter;
struct page *page;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4f861782c3e85..a4aa9500fa179 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -189,7 +189,7 @@ static int i915_ttm_tt_shmem_populate(struct ttm_device
*bdev,
struct drm_i915_private *i915 = container_of(bdev, typeof(*i915), bdev);
struct intel_memory_region *mr = i915->mm.regions[INTEL_MEMORY_SYSTEM];
struct i915_ttm_tt *i915_tt = container_of(ttm, typeof(*i915_tt), ttm);
- const unsigned int max_segment = i915_sg_segment_size();
+ const unsigned int max_segment = i915_sg_segment_size(i915->drm.dev);
const size_t size = (size_t)ttm->num_pages << PAGE_SHIFT;
struct file *filp = i915_tt->filp;
struct sgt_iter sgt_iter;
@@ -538,7 +538,7 @@ static struct i915_refct_sgt *i915_ttm_tt_get_st(struct
ttm_tt *ttm)
ret = sg_alloc_table_from_pages_segment(st,
ttm->pages, ttm->num_pages,
0, (unsigned long)ttm->num_pages << PAGE_SHIFT,
- i915_sg_segment_size(), GFP_KERNEL);
+ i915_sg_segment_size(i915_tt->dev), GFP_KERNEL);
if (ret) {
st->sgl = NULL;
return ERR_PTR(ret);
diff --git
Re: [Intel-gfx] [PATCH v5 02/31] drm/i915: Don't register backlight when another backlight should be used (v2)
Hi,
On 10/26/22 22:49, Matthew Garrett wrote:
> On Wed, Oct 26, 2022 at 11:59:28AM +0200, Hans de Goede wrote:
>
>> Ok, so this is a local customization to what is already a custom BIOS
>> for a custom motherboard. There is a lot of custom in that sentence and
>> TBH at some point things might become too custom for them to be expected
>> to work OOTB.
>
> But it *did* work OOTB before. You broke it. I accept that I'm a
> ludicrously weird corner case here, but there are going to be other
> systems that are also affected by this.
>
>> I'm afraid things are not that simple. I assume that with
>> "if ACPI backlight control is expected to work" you mean don't
>> use ACPI backlight control when (acpi_osi_is_win8() && native_available)
>> evaluates to true because it is known to be broken on some of
>> those systems because Windows 8 stopped using it ?
>
> Correct.
>
>> Unfortunately something similar applies to vendor interfaces,
>> When Windows XP started using (and mandating for certification
>> IIRC) ACPI backlight control, vendors still kept their own
>> vendor specific EC/smbios/ACPI/WMI backlight interfaces around for
>> a long long time, except they were often no longer tested.
>
> The current situation (both before your patchset and with its current
> implementation) is that vendor is preferred to native, so if the vendor
> interface is present then we're already using it.
All vendor drivers that I'm aware of have:
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return;
In their backlight register paths and this has been present since
circa 2015.
So both before and after my 6.1 refactor vendor is only preferred
on devices which don't implement the ACPI video bus control method.
>>> The
>>> problem you're dealing with is that the knowledge of whether or not
>>> there's a vendor interface isn't something the core kernel code knows
>>> about. What you're proposing here is effectively for us to expose
>>> additional information about whether or not there's a vendor interface
>>> in the system firmware, but since we're talking in some cases about
>>> hardware that's almost 20 years old, we're not realistically going to
>>> get those old machines fixed.
>>
>> I don't understand why you keep talking about the old vendor interfaces,
>> at least for the chromebook part of this thread the issue is that
>> the i915 driver no longer registers the intel_backlight device which
>> is a native device type, which is caused by the patch this email
>> thread is about (and old vendor interfaces do not come into play
>> at all here). So AFAICT this is a native vs acpi backlight control
>> issue ?
>
> I'm referring to your proposed patch that changed the default from
> backlight_vendor to backlight_native, which would fix my machine and
> Chromebooks but break anything that relies on the vendor interfaces.
I see. I agree that preferring native over vendor on machines
which do not have ACPI video backlight control will cause issues
on older machines. Avoiding this scenario is exactly why currently
the native check is conditional on the presence of ACPI video
backlight control.
>> I really want to resolve your bug, but I still lack a lot of info,
>> like what backlight interface you were actually using in 6.0 ?
>
> Native.
>
>> {
>> .callback = video_detect_force_video,
>> /* ThinkPad X201s */
>> .matches = {
>> DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
>> DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"),
>> },
>> },
>>
>> will trigger.
>
> In this case you'd break anyone else running the system who isn't using
> the hacked EC and different ACPI tables - obviously there's ways round
> this, but realistically since I'm (as far as I know) the only person in
> this situation it makes more sense for me to add a kernel parameter than
> carry around an exceedingly niche DMI quirk. I'm fine with that. But the
> point I'm trying to make is that the machines *are* telling you whether
> they'd prefer vendor or native.
I wish that that ("telling you whether they'd prefer vendor or native")
were true. But that does not match my experience at all and I've been
working on making the kernel pick the right backlight interface on
laptops since 2014.
Just because a vendor interface is present does not mean that it will
work. Unfortunately for none of the 3 main native/acpi_video/vendor
backlight control methods the control method being present also guarantees
that it will work. Which completely sucks, but it is the reality we
have to deal with.
> , and you're not taking that into account
> in the video_detect code.
Regards,
Hans
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave, Daniel, Three fixes for the next release candidate: one display training fix, one new workaround and disabling of autosuspend for DG2 until things can get properly fixed. Regards, Tvrtko drm-intel-fixes-2022-10-27-1: - Extend Wa_1607297627 to Alderlake-P (José Roberto de Souza) - Keep PCI autosuspend control 'on' by default on all dGPU (Anshuman Gupta) - Reset frl trained flag before restarting FRL training (Ankit Nautiyal) The following changes since commit 247f34f7b80357943234f93f247a1ae6b6c3a740: Linux 6.1-rc2 (2022-10-23 15:27:33 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-10-27-1 for you to fetch changes up to 63720a561b3c98199adf0c73e152807f15cc3b7f: drm/i915/dp: Reset frl trained flag before restarting FRL training (2022-10-24 10:14:57 +0100) - Extend Wa_1607297627 to Alderlake-P (José Roberto de Souza) - Keep PCI autosuspend control 'on' by default on all dGPU (Anshuman Gupta) - Reset frl trained flag before restarting FRL training (Ankit Nautiyal) Ankit Nautiyal (1): drm/i915/dp: Reset frl trained flag before restarting FRL training Anshuman Gupta (1): drm/i915/dgfx: Keep PCI autosuspend control 'on' by default on all dGPU José Roberto de Souza (1): drm/i915: Extend Wa_1607297627 to Alderlake-P drivers/gpu/drm/i915/display/intel_dp.c | 2 ++ drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++-- drivers/gpu/drm/i915/intel_runtime_pm.c | 11 +-- 3 files changed, 13 insertions(+), 4 deletions(-)
Re: [Intel-gfx] [PATCH 20/20] drm/i915/mtl: Pin assignment for TypeC
> -Original Message-
> From: Deak, Imre
> Sent: Wednesday, October 26, 2022 5:27 PM
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org; Srivatsa, Anusha
> ; Roper, Matthew D
> ; Souza, Jose
> Subject: Re: [PATCH 20/20] drm/i915/mtl: Pin assignment for TypeC
>
> On Fri, Oct 14, 2022 at 03:47:40PM +0300, Mika Kahola wrote:
> > From: Anusha Srivatsa
> >
> > Unlike previous platforms that used PORT_TX_DFLEXDPSP for max_lane
> > calculation, MTL uses only PORT_TX_DFLEXPA1 from which the max_lanes
> > has to be calculated.
> >
> > Bspec: 50235, 65380
> > Cc: Mika Kahola
> > Cc: Imre Deak
> > Cc: Matt Roper
> > Signed-off-by: Anusha Srivatsa
> > Signed-off-by: Jose Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/display/intel_tc.c | 30
> > +
> > 1 file changed, 30 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
> > b/drivers/gpu/drm/i915/display/intel_tc.c
> > index dba10bcc6b66..1bc81adf1ad7 100644
> > --- a/drivers/gpu/drm/i915/display/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> > @@ -13,6 +13,10 @@
> > #include "intel_tc.h"
> > #include "intel_tc_phy_regs.h"
> >
> > +#define DP_PIN_ASSIGNMENT_C0x3
> > +#define DP_PIN_ASSIGNMENT_D0x4
> > +#define DP_PIN_ASSIGNMENT_E0x5
>
> The above are flags for the PORT_TX_DFLEXPA1 register, so should be defined
> next to it.
Ok. I will move these defines to the correct place.
>
> TGL handles a few more encodings, not sure if that's correct or the register
> description, opened a bspec ticket to clarify that.
>
> > +
> > static const char *tc_port_mode_name(enum tc_port_mode mode) {
> > static const char * const names[] = { @@ -149,6 +153,29 @@ u32
> > intel_tc_port_get_pin_assignment_mask(struct intel_digital_port *dig_port)
> >DP_PIN_ASSIGNMENT_SHIFT(dig_port->tc_phy_fia_idx);
> > }
> >
> > +static int mtl_tc_port_get_pin_assignment_mask(struct
> > +intel_digital_port *dig_port)
>
> The function returns the maximum number of lanes, so should be named
> accordingly.
Yes, I will figure out a different name for that function.
>
> > +{
> > + struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
> > + intel_wakeref_t wakeref;
> > + u32 pin_mask;
> > +
> > + assert_tc_cold_blocked(dig_port);
> > +
> > + with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE,
> wakeref)
> > + pin_mask = intel_tc_port_get_pin_assignment_mask(dig_port);
>
> The called function handles all the above, so it can be just:
>
> switch (intel_tc_port_get_pin_assignment_mask()):
Yes. This simplifies the code a bit.
Thanks for a review and comments!
Cheers,
Mika
>
> > +
> > + switch(pin_mask) {
> > + default:
> > + MISSING_CASE(pin_mask);
> > + fallthrough;
> > + case DP_PIN_ASSIGNMENT_D:
> > + return 2;
> > + case DP_PIN_ASSIGNMENT_C:
> > + case DP_PIN_ASSIGNMENT_E:
> > + return 4;
> > + }
> > +}
> > +
> > int intel_tc_port_fia_max_lane_count(struct intel_digital_port
> > *dig_port) {
> > struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev); @@
> > -158,6 +185,9 @@ int intel_tc_port_fia_max_lane_count(struct
> intel_digital_port *dig_port)
> > if (dig_port->tc_mode != TC_PORT_DP_ALT)
> > return 4;
> >
> > + if (DISPLAY_VER(i915) >= 14)
> > + return mtl_tc_port_get_pin_assignment_mask(dig_port);
> > +
> > assert_tc_cold_blocked(dig_port);
> >
> > lane_mask = 0;
> > --
> > 2.34.1
> >
Re: [Intel-gfx] [PATCH v3 6/6] freezer, sched: Rewrite core freezer logic
On Thu, Oct 27, 2022 at 01:58:09PM +0800, Chen Yu wrote:
> > It's a very narrow race between schedule() and task_call_func().
> >
> > CPU0 CPU1
> >
> > __schedule()
> > rq_lock();
> > prev_state = READ_ONCE(prev->__state);
> > if (... && prev_state) {
> > deactivate_tasl(rq, prev, ...)
> > prev->on_rq = 0;
> >
> > task_call_func()
> >
> > raw_spin_lock_irqsave(p->pi_lock);
> > state = READ_ONCE(p->__state);
> > smp_rmb();
> > if (... || p->on_rq) //
> > false!!!
> > rq = __task_rq_lock()
> >
> > ret = func();
> >
> > next = pick_next_task();
> > rq = context_switch(prev, next)
> > prepare_lock_switch()
> > spin_release(&__rq_lockp(rq)->dep_map...)
> >
> >
> >
> > So while the task is on it's way out, it still holds rq->lock for a
> > little while, and right then task_call_func() comes in and figures it
> > doesn't need rq->lock anymore (because the task is already dequeued --
> > but still running there) and then the __set_task_frozen() thing observes
> > it's holding rq->lock and yells murder.
> >
> > Could you please give the below a spin?
> >
> > ---
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index cb2aa2b54c7a..f519f44cd4c7 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -4200,6 +4200,37 @@ try_to_wake_up(struct task_struct *p, unsigned int
> > state, int wake_flags)
> > return success;
> > }
> >
> > +static bool __task_needs_rq_lock(struct task_struct *p)
> > +{
> > + unsigned int state = READ_ONCE(p->__state);
> > +
> > + /*
> > +* Since pi->lock blocks try_to_wake_up(), we don't need rq->lock when
> > +* the task is blocked. Make sure to check @state since ttwu() can drop
> > +* locks at the end, see ttwu_queue_wakelist().
> > +*/
> > + if (state == TASK_RUNNING || state == TASK_WAKING)
> > + return true;
> > +
> > + /*
> > +* Ensure we load p->on_rq after p->__state, otherwise it would be
> > +* possible to, falsely, observe p->on_rq == 0.
> > +*
> > +* See try_to_wake_up() for a longer comment.
> > +*/
> > + smp_rmb();
> > + if (p->on_rq)
> > + return true;
> > +
> > +#ifdef CONFIG_SMP
> > + smp_rmb();
> > + if (p->on_cpu)
> > + return true;
> > +#endif
> Should we also add p->on_cpu check to return 0 in __set_task_frozen()?
> Otherwise it might still warn that p is holding the lock?
With this, I don't think __set_task_frozen() should ever see
'p->on_cpu && !p->on_rq'. By forcing task_call_func() to acquire
rq->lock that window is closed. That is, this window only exits in
__schedule() while it holds rq->lock, since we're now serializing
against that, we should no longer observe it.
[Intel-gfx] [PULL] drm-misc-next
Hi, Here's this week drm-misc-next PR Maxime drm-misc-next-2022-10-27: drm-misc-next for 6.2: UAPI Changes: Cross-subsystem Changes: Core Changes: - connector: Send hotplug event on cleanup - edid: logging/debug improvements - plane_helper: Improve tests Driver Changes: - bridge: - it6505: Synchronization improvements - panel: - panel-edp: Add INX N116BGE-EA2 C2 and C4 support. - nouveau: Fix page-fault handling - vmwgfx: fb and cursor refactoring, convert to generic hashtable The following changes since commit 7c99616e3fe7f35fe25bf6f5797267da29b4751e: drm: Remove drm_mode_config::fb_base (2022-10-19 21:46:16 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2022-10-27 for you to fetch changes up to e1e7bc481d49c3e3ada11029ce0d9b85a0a539d7: drm/edid: convert to device specific logging (2022-10-26 11:30:45 +0300) drm-misc-next for 6.2: UAPI Changes: Cross-subsystem Changes: Core Changes: - connector: Send hotplug event on cleanup - edid: logging/debug improvements - plane_helper: Improve tests Driver Changes: - bridge: - it6505: Synchronization improvements - panel: - panel-edp: Add INX N116BGE-EA2 C2 and C4 support. - nouveau: Fix page-fault handling - vmwgfx: fb and cursor refactoring, convert to generic hashtable Alistair Popple (1): nouveau: Fix migrate_to_ram() for faulting page Colin Ian King (1): drm/vc4: Fix spelling mistake "mmaping" -> "mmapping" Dmitry Osipenko (1): drm/client: Switch drm_client_buffer_delete() to unlocked drm_gem_vunmap Jani Nikula (16): drm/i915/hdmi: do dual mode detect only if connected drm/i915/hdmi: stop using connector->override_edid drm/amd/display: stop using connector->override_edid drm/edid: debug log EDID override set/reset drm/edid: abstract debugfs override EDID show better drm/edid: rename drm_add_override_edid_modes() to drm_edid_override_connector_update() drm/edid: split drm_edid block count helper drm/edid: add function for checking drm_edid validity drm/edid: detach debugfs EDID override from EDID property update drm/edid/firmware: drop redundant connector_name variable/parameter drm/edid/firmware: rename drm_load_edid_firmware() to drm_edid_load_firmware() drm/edid: use struct drm_edid for override/firmware EDID drm/edid: move edid load declarations to internal header drm/edid/firmware: convert to drm device specific logging drm/edid: add [CONNECTOR:%d:%s] to debug logging drm/edid: convert to device specific logging Luben Tuikov (1): drm/scheduler: Set the FIFO scheduling policy as the default Maaz Mombasawala (5): drm/vmwgfx: Refactor resource manager's hashtable to use linux/hashtable implementation. drm/vmwgfx: Remove ttm object hashtable drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation. drm/vmwgfx: Refactor ttm reference object hashtable to use linux/hashtable. drm/vmwgfx: Remove vmwgfx_hashtab Martin Krastev (1): drm/vmwgfx: Fix frame-size warning in vmw_mksstat_add_ioctl Michael Banack (4): drm/vmwgfx: Clean up cursor mobs drm/vmwgfx: Start diffing new mob cursors against old ones drm/vmwgfx: Support cursor surfaces with mob cursor drm/vmwgfx: Diff cursors when using cmds Michał Winiarski (2): drm/plane_helper: Print actual/expected values on failure drm/plane_helper: Split into parameterized test cases Pin-yen Lin (3): drm/bridge: it6505: Initialize AUX channel in it6505_i2c_probe drm/bridge: it6505: Setup links in it6505_irq_hpd drm/bridge: it6505: Improve synchronization between extcon subsystem Sean Hong (2): drm/panel-edp: Add INX N116BGE-EA2 (HW: C2) drm/panel-edp: Add INX N116BGE-EA2 (HW: C4) Simon Ser (2): Revert "drm: hide unregistered connectors from GETCONNECTOR IOCTL" drm/connector: send hotplug uevent on connector cleanup Yang Li (1): nouveau/dmem: Remove duplicated include in nouveau_dmem.c Zack Rusin (8): drm/nouveau: Remove unused variable drm/vmwgfx: Write the driver id registers drm/vmwgfx: Do not allow invalid bpp's for dumb buffers drm/vmwgfx: Port the framebuffer code to drm fb helpers drm/vmwgfx: Remove explicit and broken vblank handling drm/vmwgfx: Add a mksstat counter for cotable resizes drm/vmwgfx: Optimize initial sizes of cotables drm/vmwgfx: Fix a sparse warning in kernel docs wangjianli (2): gpu/drm: fix repeated words in comments gpu/drm: fix repeated words in comments Documentation/gpu/todo.rst| 11 - drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 - drivers/gpu/drm/bridge/ite-it6505.c | 106 ++-
