[Intel-gfx] ✓ Fi.CI.BAT: success for i915: SSEU handling updates (rev2)
== Series Details ==
Series: i915: SSEU handling updates (rev2)
URL : https://patchwork.freedesktop.org/series/104244/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104244v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/index.html
Participating hosts (44 -> 45)
--
Additional (2): fi-icl-u2 fi-tgl-u2
Missing(1): fi-hsw-4770
Known issues
Here are the changes found in Patchwork_104244v2 that come from known issues:
### CI changes ###
Issues hit
* boot:
- fi-bdw-5557u: [PASS][1] -> [FAIL][2] ([i915#6074])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-bdw-5557u/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-bdw-5557u/boot.html
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-icl-u2: NOTRUN -> [INCOMPLETE][3] ([i915#4890])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-icl-u2/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-u2: NOTRUN -> [SKIP][4] ([i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] /
[i915#4957])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_busy@basic@flip:
- fi-tgl-u2: NOTRUN -> [DMESG-WARN][9] ([i915#402]) +3 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-tgl-u2: NOTRUN -> [SKIP][10] ([fdo#109284] / [fdo#111827]) +7
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-u2: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- bat-adlp-4: [PASS][12] -> [DMESG-WARN][13] ([i915#3576])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-u2: NOTRUN -> [SKIP][14] ([fdo#109285])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-u2: NOTRUN -> [SKIP][15] ([i915#3555])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-u2: NOTRUN -> [SKIP][16] ([i915#3301])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-icl-u2: NOTRUN -> [FAIL][17] ([i915#4312])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-icl-u2/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][18] ([i915#5122]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_flip@basic-plain-flip@a-edp1:
- bat-adlp-4: [DMESG-WARN][20] ([i915#3576]) -> [PASS][21] +2
similar issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109284]:
Re: [Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Add HWMON power sensor support
On Mon, 23 May 2022 04:08:39 -0700, Badal Nilawar wrote:
>
A few initial comments.
> +static void
> +i915_hwmon_get_preregistration_info(struct drm_i915_private *i915)
> +{
> + struct i915_hwmon *hwmon = i915->hwmon;
> + struct intel_uncore *uncore = >uncore;
> + struct i915_hwmon_drvdata *ddat = >ddat;
> + intel_wakeref_t wakeref;
> + u32 val_sku_unit;
> + __le32 le_sku_unit;
> +
> + if (IS_DG1(i915) || IS_DG2(i915)) {
> + hwmon->rg.pkg_power_sku_unit = PCU_PACKAGE_POWER_SKU_UNIT;
> + hwmon->rg.pkg_power_sku = INVALID_MMIO_REG;
> + hwmon->rg.pkg_rapl_limit = PCU_PACKAGE_RAPL_LIMIT;
> + } else {
> + hwmon->rg.pkg_power_sku_unit = INVALID_MMIO_REG;
> + hwmon->rg.pkg_power_sku = INVALID_MMIO_REG;
> + hwmon->rg.pkg_rapl_limit = INVALID_MMIO_REG;
> + }
> +
> + wakeref = intel_runtime_pm_get(uncore->rpm);
Let's just use with_intel_runtime_pm().
> +
> + /*
> + * The contents of register hwmon->rg.pkg_power_sku_unit do not change,
> + * so read it once and store the shift values.
> + *
> + * For some platforms, this value is defined as available "for all
> + * tiles", with the values consistent across all tiles.
> + * In this case, use the tile 0 value for all.
If we are going to introduce multiple tiles "later", let's introduce this
comment later too.
> + */
> + if (i915_mmio_reg_valid(hwmon->rg.pkg_power_sku_unit))
> + val_sku_unit = intel_uncore_read(uncore,
> + hwmon->rg.pkg_power_sku_unit);
> + else
> + val_sku_unit = 0;
> +
> + intel_runtime_pm_put(uncore->rpm, wakeref);
> +
> + le_sku_unit = cpu_to_le32(val_sku_unit);
> + hwmon->scl_shift_power = le32_get_bits(le_sku_unit, PKG_PWR_UNIT);
Do we need such endianness conversions, typically we don't do them?
> +
> + /*
> + * The value of power1_max is reset to the default on reboot, but is
> + * not reset by a module unload/load sequence. To allow proper
> + * functioning after a module reload, the value for power1_max is
> + * restored to its original value at module unload time in
> + * i915_hwmon_unregister().
> + */
Because on production systems typically modules are not reloaded, I am not
sure if we need to take care of this save/restore. Also there may be other
ways of doing this e.g.:
https://patchwork.freedesktop.org/patch/483988/?series=102665=3
That is above we just expose the default or init values but don't expose
them.
In order for such issues to be reviewed/debated, I would submit this
save/restore part as a separate patch, so decouple it from the
hwmon_power_max patch.
> +void i915_hwmon_register(struct drm_i915_private *i915);
> +void i915_hwmon_unregister(struct drm_i915_private *i915);
> +#endif
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d8579ab9384c..1c570c706ff8 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1866,6 +1866,21 @@
> #define POWER_LIMIT_4_MASK REG_BIT(9)
> #define POWER_LIMIT_1_MASK REG_BIT(11)
> #define POWER_LIMIT_2_MASK REG_BIT(12)
> +/*
> + * *_PACKAGE_POWER_SKU - SKU power and timing parameters.
> + * Used herein as a 64-bit register.
> + * These masks are defined using GENMASK_ULL as REG_GENMASK is limited to u32
> + * and as GENMASK is "long" and therefore 32-bits on a 32-bit system.
> + * PKG_PKG_TDP, PKG_MIN_PWR, and PKG_MAX_PWR are scaled in the same way as
> + * PKG_PWR_LIM_*, above.
> + * PKG_MAX_WIN has sub-fields for x and y, and has the value: is 1.x * 2^y.
> + */
> +#define PKG_PKG_TDPGENMASK_ULL(14, 0)
> +#define PKG_MIN_PWRGENMASK_ULL(30, 16)
> +#define PKG_MAX_PWRGENMASK_ULL(46, 32)
> +#define PKG_MAX_WINGENMASK_ULL(54, 48)
> +#define PKG_MAX_WIN_YGENMASK_ULL(54, 53)
> +#define PKG_MAX_WIN_XGENMASK_ULL(52, 48)
>
> #define CHV_CLK_CTL1 _MMIO(0x101100)
> #define VLV_CLK_CTL2 _MMIO(0x101104)
> diff --git a/drivers/gpu/drm/i915/intel_mchbar_regs.h
> b/drivers/gpu/drm/i915/intel_mchbar_regs.h
> index 2aad2f0cc8db..247561d7974c 100644
> --- a/drivers/gpu/drm/i915/intel_mchbar_regs.h
> +++ b/drivers/gpu/drm/i915/intel_mchbar_regs.h
> @@ -191,11 +191,20 @@
>
> #define GEN6_GT_PERF_STATUS _MMIO(MCHBAR_MIRROR_BASE_SNB +
> 0x5948)
> #define GEN6_RP_STATE_LIMITS _MMIO(MCHBAR_MIRROR_BASE_SNB +
> 0x5994)
> +#define PCU_PACKAGE_POWER_SKU_UNIT _MMIO(MCHBAR_MIRROR_BASE_SNB +
> 0x5938)
> +#define PKG_PWR_UNIT REG_GENMASK(3, 0)
> +#define PKG_TIME_UNIT REG_GENMASK(19, 16)
> +
> #define GEN6_RP_STATE_CAP
[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: SSEU handling updates (rev2)
== Series Details ==
Series: i915: SSEU handling updates (rev2)
URL : https://patchwork.freedesktop.org/series/104244/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104244v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_104244v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104244v2, 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_104244v2/index.html
Participating hosts (44 -> 45)
--
Additional (2): fi-icl-u2 fi-tgl-u2
Missing(1): fi-hsw-4770
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104244v2:
### CI changes ###
Possible regressions
* boot:
- fi-bdw-5557u: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-bdw-5557u/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-bdw-5557u/boot.html
Known issues
Here are the changes found in Patchwork_104244v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-icl-u2: NOTRUN -> [INCOMPLETE][3] ([i915#4890])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-icl-u2/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-u2: NOTRUN -> [SKIP][4] ([i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] /
[i915#4957])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_busy@basic@flip:
- fi-tgl-u2: NOTRUN -> [DMESG-WARN][9] ([i915#402]) +3 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-tgl-u2: NOTRUN -> [SKIP][10] ([fdo#109284] / [fdo#111827]) +7
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-u2: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- bat-adlp-4: [PASS][12] -> [DMESG-WARN][13] ([i915#3576])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-u2: NOTRUN -> [SKIP][14] ([fdo#109285])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-u2: NOTRUN -> [SKIP][15] ([i915#3555])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-u2: NOTRUN -> [SKIP][16] ([i915#3301])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-icl-u2: NOTRUN -> [FAIL][17] ([i915#4312])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-icl-u2/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][18] ([i915#5122]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_flip@basic-plain-flip@a-edp1:
- bat-adlp-4: [DMESG-WARN][20] ([i915#3576]) -> [PASS][21] +2
similar
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Add HWMON support
On Mon, 23 May 2022 04:08:38 -0700, Badal Nilawar wrote: > > This series adds the HWMON support for DG1, DG2 > > Dale B Stimson (2): > drm/i915/hwmon: Add HWMON power sensor support > drm/i915/hwmon: Add HWMON energy support I would suggest a slight reorganization of the series. I think the first patch should just add the HWMON infrastrusture into i915. Subsequent patches should add the various hwmon features exposed in sysfs, mostly one patch per feature. So at least for now I'd add a first patch adding the HWMON infra to i915. And follow on with the feature patches. Thanks. > Riana Tauro (1): > drm/i915/hwmon: Add HWMON current voltage support > > .../ABI/testing/sysfs-driver-intel-i915-hwmon | 43 ++ > drivers/gpu/drm/i915/Kconfig | 1 + > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 + > drivers/gpu/drm/i915/i915_driver.c| 5 + > drivers/gpu/drm/i915/i915_drv.h | 2 + > drivers/gpu/drm/i915/i915_hwmon.c | 620 ++ > drivers/gpu/drm/i915/i915_hwmon.h | 56 ++ > drivers/gpu/drm/i915/i915_reg.h | 15 + > drivers/gpu/drm/i915/intel_mchbar_regs.h | 11 + > 10 files changed, 758 insertions(+) > create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c > create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h > > -- > 2.25.1 >
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for i915: SSEU handling updates (rev2)
On Mon, May 23, 2022 at 09:23:33PM +, Patchwork wrote: > == Series Details == > > Series: i915: SSEU handling updates (rev2) > URL : https://patchwork.freedesktop.org/series/104244/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104244v2 > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_104244v2 absolutely need to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_104244v2, 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_104244v2/index.html > > Participating hosts (44 -> 45) > -- > > Additional (2): fi-icl-u2 fi-tgl-u2 > Missing(1): fi-hsw-4770 > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_104244v2: > > ### CI changes ### > > Possible regressions > > * boot: > - fi-bdw-5557u: [PASS][1] -> [FAIL][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-bdw-5557u/boot.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-bdw-5557u/boot.html I don't see a boot failure here? It looks like i915 loaded successfully, without errors. It also looks like more tests ran successfully on the machine after that as well. Matt > > > Known issues > > > Here are the changes found in Patchwork_104244v2 that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_exec_gttfill@basic: > - fi-icl-u2: NOTRUN -> [INCOMPLETE][3] ([i915#4890]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-icl-u2/igt@gem_exec_gttf...@basic.html > > * igt@gem_huc_copy@huc-copy: > - fi-tgl-u2: NOTRUN -> [SKIP][4] ([i915#2190]) >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html > > * igt@i915_selftest@live@hangcheck: > - bat-dg1-6: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] / > [i915#4957]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html > - fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html > > * igt@kms_busy@basic@flip: > - fi-tgl-u2: NOTRUN -> [DMESG-WARN][9] ([i915#402]) +3 similar > issues >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_busy@ba...@flip.html > > * igt@kms_chamelium@dp-hpd-fast: > - fi-tgl-u2: NOTRUN -> [SKIP][10] ([fdo#109284] / [fdo#111827]) > +7 similar issues >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html > > * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: > - fi-tgl-u2: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html > > * igt@kms_flip@basic-flip-vs-modeset@b-edp1: > - bat-adlp-4: [PASS][12] -> [DMESG-WARN][13] ([i915#3576]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html > > * igt@kms_force_connector_basic@force-load-detect: > - fi-tgl-u2: NOTRUN -> [SKIP][14] ([fdo#109285]) >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html > > * igt@kms_setmode@basic-clone-single-crtc: > - fi-tgl-u2: NOTRUN -> [SKIP][15] ([i915#3555]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_setm...@basic-clone-single-crtc.html > > * igt@prime_vgem@basic-userptr: > - fi-tgl-u2: NOTRUN -> [SKIP][16] ([i915#3301]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@prime_v...@basic-userptr.html > > * igt@runner@aborted: > - fi-icl-u2: NOTRUN -> [FAIL][17] ([i915#4312]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-icl-u2/igt@run...@aborted.html > >
[Intel-gfx] ✗ Fi.CI.BAT: failure for i915: SSEU handling updates (rev2)
== Series Details ==
Series: i915: SSEU handling updates (rev2)
URL : https://patchwork.freedesktop.org/series/104244/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11693 -> Patchwork_104244v2
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_104244v2 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104244v2, 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_104244v2/index.html
Participating hosts (44 -> 45)
--
Additional (2): fi-icl-u2 fi-tgl-u2
Missing(1): fi-hsw-4770
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104244v2:
### CI changes ###
Possible regressions
* boot:
- fi-bdw-5557u: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-bdw-5557u/boot.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-bdw-5557u/boot.html
Known issues
Here are the changes found in Patchwork_104244v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-icl-u2: NOTRUN -> [INCOMPLETE][3] ([i915#4890])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-icl-u2/igt@gem_exec_gttf...@basic.html
* igt@gem_huc_copy@huc-copy:
- fi-tgl-u2: NOTRUN -> [SKIP][4] ([i915#2190])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@hangcheck:
- bat-dg1-6: [PASS][5] -> [DMESG-FAIL][6] ([i915#4494] /
[i915#4957])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-dg1-6/igt@i915_selftest@l...@hangcheck.html
- fi-snb-2600:[PASS][7] -> [INCOMPLETE][8] ([i915#3921])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_busy@basic@flip:
- fi-tgl-u2: NOTRUN -> [DMESG-WARN][9] ([i915#402]) +3 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@dp-hpd-fast:
- fi-tgl-u2: NOTRUN -> [SKIP][10] ([fdo#109284] / [fdo#111827]) +7
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_chamel...@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic:
- fi-tgl-u2: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html
* igt@kms_flip@basic-flip-vs-modeset@b-edp1:
- bat-adlp-4: [PASS][12] -> [DMESG-WARN][13] ([i915#3576])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@b-edp1.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-tgl-u2: NOTRUN -> [SKIP][14] ([fdo#109285])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-tgl-u2: NOTRUN -> [SKIP][15] ([i915#3555])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-userptr:
- fi-tgl-u2: NOTRUN -> [SKIP][16] ([i915#3301])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-tgl-u2/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-icl-u2: NOTRUN -> [FAIL][17] ([i915#4312])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-icl-u2/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {fi-ehl-2}: [DMESG-WARN][18] ([i915#5122]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11693/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104244v2/fi-ehl-2/igt@gem_exec_suspend@basic...@smem.html
* igt@kms_flip@basic-plain-flip@a-edp1:
- bat-adlp-4: [DMESG-WARN][20] ([i915#3576]) -> [PASS][21] +2
similar
Re: [Intel-gfx] [PATCH] drm/i915/hwconfig: Report no hwconfig support on ADL-N
On Mon, May 23, 2022 at 01:21:16PM +0530, Balasubramani Vivekanandan wrote:
> ADL-N being a subplatform of ADL-P, it lacks support for hwconfig
> table. Explicit check added to skip ADL-N.
>
> Signed-off-by: Balasubramani Vivekanandan
>
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> index 79c66b6b51a3..5aaa3948de74 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
> @@ -94,7 +94,7 @@ static int guc_hwconfig_fill_buffer(struct intel_guc *guc,
> struct intel_hwconfig
>
> static bool has_table(struct drm_i915_private *i915)
> {
> - if (IS_ALDERLAKE_P(i915))
> + if (IS_ALDERLAKE_P(i915) && !IS_ADLP_N(i915))
> return true;
> if (IS_DG2(i915))
> return true;
> --
> 2.25.1
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for i915: SSEU handling updates (rev2)
== Series Details == Series: i915: SSEU handling updates (rev2) URL : https://patchwork.freedesktop.org/series/104244/ 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 i915: SSEU handling updates (rev2)
== Series Details ==
Series: i915: SSEU handling updates (rev2)
URL : https://patchwork.freedesktop.org/series/104244/
State : warning
== Summary ==
Error: dim checkpatch failed
65fb3ea005ad drm/i915/xehp: Use separate sseu init function
0299a3bc6a24 drm/i915/xehp: Drop GETPARAM lookups of I915_PARAM_[SUB]SLICE_MASK
07be465e9bf5 drm/i915/sseu: Simplify gen11+ SSEU handling
a779fdef7481 drm/i915/sseu: Don't try to store EU mask internally in UAPI format
6fc4ea291341 drm/i915/sseu: Disassociate internal subslice mask representation
from uapi
-:522: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#522: FILE: drivers/gpu/drm/i915/gt/intel_sseu.c:846:
+void intel_sseu_print_ss_info(const char* type,
-:610: WARNING:NEW_TYPEDEFS: do not add new typedefs
#610: FILE: drivers/gpu/drm/i915/gt/intel_sseu.h:59:
+typedef union {
-:715: ERROR:POINTER_LOCATION: "foo* bar" should be "foo *bar"
#715: FILE: drivers/gpu/drm/i915/gt/intel_sseu.h:175:
+void intel_sseu_print_ss_info(const char* type,
total: 2 errors, 1 warnings, 0 checks, 834 lines checked
fcd7226e193b drm/i915/pvc: Add SSEU changes
[Intel-gfx] [PATCH v5 5/6] drm/i915/sseu: Disassociate internal subslice mask representation from uapi
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed significantly with Xe_HP, we'll use a union
to choose between the old "hsw-style" subslice masks or the newer xehp
mask. HSW-style masks will be stored in an array of u8's, indexed by
slice (there's never more than 6 subslices per slice on older
platforms). For Xe_HP and beyond where slices no longer exist, we only
need a single bitmask. However we already know that this mask is
eventually going to grow too large for a simple u64 to hold, so we'll
represent it in a manner that can be operated on by the utilities in
linux/bitmap.h.
v2:
- Fix typo: BIT(s) -> BIT(ss) in gen9_sseu_device_status()
v3:
- Eliminate sseu->ss_stride and just calculate the stride while
specifically handling uapi. (Tvrtko)
- Use BITMAP_BITS() macro to refer to size of masks rather than
passing I915_MAX_SS_FUSE_BITS directly. (Tvrtko)
- Report compute/geometry DSS masks separately when dumping Xe_HP SSEU
info. (Tvrtko)
- Restore dropped range checks to intel_sseu_has_subslice(). (Tvrtko)
v4:
- Make the bitmap size macro check the size of the .xehp field rather
than the containing union. (Tvrtko)
- Don't add GEM_BUG_ON() intel_sseu_has_subslice()'s check for whether
slice or subslice ID exceed sseu->max_[sub]slices; various loops
in the driver are expected to exceed these, so we should just
silently return 'false.'
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 261 +++
drivers/gpu/drm/i915/gt/intel_sseu.h | 76 --
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
drivers/gpu/drm/i915/i915_getparam.c | 3 +-
drivers/gpu/drm/i915/i915_query.c| 13 +-
9 files changed, 241 insertions(+), 187 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ab4c5ab28e4d..a3bb73f5d53b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1875,6 +1875,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
{
const struct sseu_dev_info *device = >info.sseu;
struct drm_i915_private *i915 = gt->i915;
+ unsigned int dev_subslice_mask = intel_sseu_get_hsw_subslices(device,
0);
/* No zeros in any field. */
if (!user->slice_mask || !user->subslice_mask ||
@@ -1901,7 +1902,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
if (user->slice_mask & ~device->slice_mask)
return -EINVAL;
- if (user->subslice_mask & ~device->subslice_mask[0])
+ if (user->subslice_mask & ~dev_subslice_mask)
return -EINVAL;
if (user->max_eus_per_subslice > device->max_eus_per_subslice)
@@ -1915,7 +1916,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
/* Part specific restrictions. */
if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
- unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
+ unsigned int hw_ss_per_s = hweight8(dev_subslice_mask);
unsigned int req_s = hweight8(context->slice_mask);
unsigned int req_ss = hweight8(context->subslice_mask);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1adbf34c3632..f0acf8518a51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -674,8 +674,8 @@ static void engine_mask_apply_compute_fuses(struct intel_gt
*gt)
if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
return;
- ccs_mask =
intel_slicemask_from_dssmask(intel_sseu_get_compute_subslices(>sseu),
- ss_per_ccs);
+ ccs_mask =
intel_slicemask_from_xehp_dssmask(info->sseu.compute_subslice_mask,
+ss_per_ccs);
/*
* If all DSS in a quadrant are fused off, the corresponding CCS
* engine is not available for use.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 034182f85501..2921f510642f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -133,13 +133,6 @@ static const struct intel_mmio_range
dg2_lncf_steering_table[] = {
{},
};
-static u16 slicemask(struct intel_gt *gt, int count)
-{
- u64 dss_mask = intel_sseu_get_subslices(>info.sseu, 0);
-
-
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/hwconfig: Report no hwconfig support on ADL-N
== Series Details ==
Series: drm/i915/hwconfig: Report no hwconfig support on ADL-N
URL : https://patchwork.freedesktop.org/series/104270/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11690_full -> Patchwork_104270v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_104270v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104270v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (13 -> 12)
--
Missing(1): shard-rkl
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104270v1_full:
### IGT changes ###
Possible regressions
* igt@kms_cursor_crc@pipe-a-cursor-256x256-sliding:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/shard-tglb1/igt@kms_cursor_...@pipe-a-cursor-256x256-sliding.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-tglb8/igt@kms_cursor_...@pipe-a-cursor-256x256-sliding.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@kms_hdr@bpc-switch@pipe-a-hdmi-a-1}:
- {shard-dg1}:NOTRUN -> [SKIP][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-dg1-16/igt@kms_hdr@bpc-swi...@pipe-a-hdmi-a-1.html
New tests
-
New tests have been introduced between CI_DRM_11690_full and
Patchwork_104270v1_full:
### New IGT tests (7) ###
* igt@gem_busy@parallel:
- Statuses :
- Exec time: [None] s
* igt@kms_flip@modeset-vs-vblank-race@a-dp1:
- Statuses : 2 pass(s)
- Exec time: [4.03, 4.20] s
* igt@kms_flip@modeset-vs-vblank-race@b-dp1:
- Statuses : 2 pass(s)
- Exec time: [3.92, 4.06] s
* igt@kms_flip@modeset-vs-vblank-race@c-dp1:
- Statuses : 2 pass(s)
- Exec time: [3.99, 4.11] s
* igt@kms_flip@plain-flip-fb-recreate-interruptible@c-edp1:
- Statuses : 1 pass(s)
- Exec time: [11.53] s
* igt@perf_pmu@busy-accuracy-2:
- Statuses :
- Exec time: [None] s
* igt@perf_pmu@most-busy-idle-check-all:
- Statuses :
- Exec time: [None] s
Known issues
Here are the changes found in Patchwork_104270v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-2x:
- shard-iclb: NOTRUN -> [SKIP][4] ([i915#1839])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-iclb5/igt@feature_discov...@display-2x.html
* igt@gem_exec_fair@basic-deadline:
- shard-kbl: NOTRUN -> [FAIL][5] ([i915#2846])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-kbl6/igt@gem_exec_f...@basic-deadline.html
- shard-apl: NOTRUN -> [FAIL][6] ([i915#2846])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-apl2/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none@vecs0:
- shard-apl: [PASS][7] -> [FAIL][8] ([i915#2842]) +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/shard-apl6/igt@gem_exec_fair@basic-n...@vecs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-apl4/igt@gem_exec_fair@basic-n...@vecs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-iclb: NOTRUN -> [FAIL][9] ([i915#2842]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-iclb6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-pace@vcs0:
- shard-glk: [PASS][10] -> [FAIL][11] ([i915#2842])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/shard-glk8/igt@gem_exec_fair@basic-p...@vcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-glk3/igt@gem_exec_fair@basic-p...@vcs0.html
* igt@gem_lmem_swapping@basic:
- shard-iclb: NOTRUN -> [SKIP][12] ([i915#4613])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-iclb6/igt@gem_lmem_swapp...@basic.html
* igt@gem_lmem_swapping@heavy-random:
- shard-skl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#4613]) +6
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-skl10/igt@gem_lmem_swapp...@heavy-random.html
* igt@gem_lmem_swapping@verify:
- shard-kbl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#4613])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/shard-kbl6/igt@gem_lmem_swapp...@verify.html
* igt@gem_pwrite@basic-exhaustion:
- shard-skl: NOTRUN -> [WARN][15]
Re: [Intel-gfx] [RFC v3 3/3] drm/doc/rfc: VM_BIND uapi definition
On Thu, May 19, 2022 at 04:07:30PM -0700, Zanoni, Paulo R wrote:
On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote:
VM_BIND and related uapi definitions
v2: Ensure proper kernel-doc formatting with cross references.
Also add new uapi and documentation as per review comments
from Daniel.
Signed-off-by: Niranjana Vishwanathapura
---
Documentation/gpu/rfc/i915_vm_bind.h | 399 +++
1 file changed, 399 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_vm_bind.h
diff --git a/Documentation/gpu/rfc/i915_vm_bind.h
b/Documentation/gpu/rfc/i915_vm_bind.h
new file mode 100644
index ..589c0a009107
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_vm_bind.h
@@ -0,0 +1,399 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+/**
+ * DOC: I915_PARAM_HAS_VM_BIND
+ *
+ * VM_BIND feature availability.
+ * See typedef drm_i915_getparam_t param.
+ */
+#define I915_PARAM_HAS_VM_BIND 57
+
+/**
+ * DOC: I915_VM_CREATE_FLAGS_USE_VM_BIND
+ *
+ * Flag to opt-in for VM_BIND mode of binding during VM creation.
+ * See struct drm_i915_gem_vm_control flags.
+ *
+ * A VM in VM_BIND mode will not support the older execbuff mode of binding.
+ * In VM_BIND mode, execbuff ioctl will not accept any execlist (ie., the
+ * _i915_gem_execbuffer2.buffer_count must be 0).
+ * Also, _i915_gem_execbuffer2.batch_start_offset and
+ * _i915_gem_execbuffer2.batch_len must be 0.
+ * DRM_I915_GEM_EXECBUFFER_EXT_BATCH_ADDRESSES extension must be provided
+ * to pass in the batch buffer addresses.
+ *
+ * Additionally, I915_EXEC_NO_RELOC, I915_EXEC_HANDLE_LUT and
+ * I915_EXEC_BATCH_FIRST of _i915_gem_execbuffer2.flags must be 0
+ * (not used) in VM_BIND mode. I915_EXEC_USE_EXTENSIONS flag must always be
+ * set (See struct drm_i915_gem_execbuffer_ext_batch_addresses).
+ * The buffers_ptr, buffer_count, batch_start_offset and batch_len fields
+ * of struct drm_i915_gem_execbuffer2 are also not used and must be 0.
+ */
From that description, it seems we have:
struct drm_i915_gem_execbuffer2 {
__u64 buffers_ptr; -> must be 0 (new)
__u32 buffer_count; -> must be 0 (new)
__u32 batch_start_offset; -> must be 0 (new)
__u32 batch_len;-> must be 0 (new)
__u32 DR1; -> must be 0 (old)
__u32 DR4; -> must be 0 (old)
__u32 num_cliprects; (fences) -> must be 0 since using extensions
__u64 cliprects_ptr; (fences, extensions) -> contains an actual pointer!
__u64 flags;-> some flags must be 0 (new)
__u64 rsvd1; (context info) -> repurposed field (old)
__u64 rsvd2;-> unused
};
Based on that, why can't we just get drm_i915_gem_execbuffer3 instead
of adding even more complexity to an already abused interface? While
the Vulkan-like extension thing is really nice, I don't think what
we're doing here is extending the ioctl usage, we're completely
changing how the base struct should be interpreted based on how the VM
was created (which is an entirely different ioctl).
From Rusty Russel's API Design grading, drm_i915_gem_execbuffer2 is
already at -6 without these changes. I think after vm_bind we'll need
to create a -11 entry just to deal with this ioctl.
The only change here is removing the execlist support for VM_BIND
mode (other than natual extensions).
Adding a new execbuffer3 was considered, but I think we need to be careful
with that as that goes beyond the VM_BIND support, including any future
requirements (as we don't want an execbuffer4 after VM_BIND).
Niranjana
+#define I915_VM_CREATE_FLAGS_USE_VM_BIND (1 << 0)
+
+/**
+ * DOC: I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING
+ *
+ * Flag to declare context as long running.
+ * See struct drm_i915_gem_context_create_ext flags.
+ *
+ * Usage of dma-fence expects that they complete in reasonable amount of time.
+ * Compute on the other hand can be long running. Hence it is not appropriate
+ * for compute contexts to export request completion dma-fence to user.
+ * The dma-fence usage will be limited to in-kernel consumption only.
+ * Compute contexts need to use user/memory fence.
+ *
+ * So, long running contexts do not support output fences. Hence,
+ * I915_EXEC_FENCE_OUT (See _i915_gem_execbuffer2.flags and
+ * I915_EXEC_FENCE_SIGNAL (See _i915_gem_exec_fence.flags) are expected
+ * to be not used.
+ *
+ * DRM_I915_GEM_WAIT ioctl call is also not supported for objects mapped
+ * to long running contexts.
+ */
+#define I915_CONTEXT_CREATE_FLAGS_LONG_RUNNING (1u << 2)
+
+/* VM_BIND related ioctls */
+#define DRM_I915_GEM_VM_BIND 0x3d
+#define DRM_I915_GEM_VM_UNBIND 0x3e
+#define DRM_I915_GEM_WAIT_USER_FENCE 0x3f
+
+#define DRM_IOCTL_I915_GEM_VM_BIND DRM_IOWR(DRM_COMMAND_BASE +
DRM_I915_GEM_VM_BIND, struct drm_i915_gem_vm_bind)
+#define
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Mon, May 23, 2022 at 12:05:05PM -0700, Niranjana Vishwanathapura wrote: On Thu, May 19, 2022 at 03:52:01PM -0700, Zanoni, Paulo R wrote: On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote: VM_BIND design document with description of intended use cases. v2: Add more documentation and format as per review comments from Daniel. Signed-off-by: Niranjana Vishwanathapura --- diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst new file mode 100644 index ..f1be560d313c --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -0,0 +1,304 @@ +== +I915 VM_BIND feature design and use cases +== + +VM_BIND feature + +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a +specified address space (VM). These mappings (also referred to as persistent +mappings) will be persistent across multiple GPU submissions (execbuff calls) +issued by the UMD, without user having to provide a list of all required +mappings during each submission (as required by older execbuff mode). + +VM_BIND/UNBIND ioctls will support 'in' and 'out' fences to allow userpace +to specify how the binding/unbinding should sync with other operations +like the GPU job submission. These fences will be timeline 'drm_syncobj's +for non-Compute contexts (See struct drm_i915_vm_bind_ext_timeline_fences). +For Compute contexts, they will be user/memory fences (See struct +drm_i915_vm_bind_ext_user_fence). + +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. +User has to opt-in for VM_BIND mode of binding for an address space (VM) +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an +async worker. The binding and unbinding will work like a special GPU engine. +The binding and unbinding operations are serialized and will wait on specified +input fences before the operation and will signal the output fences upon the +completion of the operation. Due to serialization, completion of an operation +will also indicate that all previous operations are also complete. + +VM_BIND features include: + +* Multiple Virtual Address (VA) mappings can map to the same physical pages + of an object (aliasing). +* VA mapping can map to a partial section of the BO (partial binding). +* Support capture of persistent mappings in the dump upon GPU error. +* TLB is flushed upon unbind completion. Batching of TLB flushes in some + use cases will be helpful. +* Asynchronous vm_bind and vm_unbind support with 'in' and 'out' fences. +* Support for userptr gem objects (no special uapi is required for this). + +Execbuff ioctl in VM_BIND mode +--- +The execbuff ioctl handling in VM_BIND mode differs significantly from the +older method. A VM in VM_BIND mode will not support older execbuff mode of +binding. In VM_BIND mode, execbuff ioctl will not accept any execlist. Hence, +no support for implicit sync. It is expected that the below work will be able +to support requirements of object dependency setting in all use cases: + +"dma-buf: Add an API for exporting sync files" +(https://lwn.net/Articles/859290/) I would really like to have more details here. The link provided points to new ioctls and we're not very familiar with those yet, so I think you should really clarify the interaction between the new additions here. Having some sample code would be really nice too. For Mesa at least (and I believe for the other drivers too) we always have a few exported buffers in every execbuf call, and we rely on the implicit synchronization provided by execbuf to make sure everything works. The execbuf ioctl also has some code to flush caches during implicit synchronization AFAIR, so I would guess we rely on it too and whatever else the Kernel does. Is that covered by the new ioctls? In addition, as far as I remember, one of the big improvements of vm_bind was that it would help reduce ioctl latency and cpu overhead. But if making execbuf faster comes at the cost of requiring additional ioctls calls for implicit synchronization, which is required on ever execbuf call, then I wonder if we'll even get any faster at all. Comparing old execbuf vs plain new execbuf without the new required ioctls won't make sense. But maybe I'm wrong and we won't need to call these new ioctls around every single execbuf ioctl we submit? Again, more clarification and some code examples here would be really nice. This is a big change on an important part of the API, we should clarify the new expected usage. Thanks Paulo for the comments. In VM_BIND mode, the only reason we would need execlist support in execbuff path is for implicit synchronization. And AFAIK, this work from Jason is expected replace
Re: [Intel-gfx] [RFC v3 1/3] drm/doc/rfc: VM_BIND feature design document
On Thu, May 19, 2022 at 03:52:01PM -0700, Zanoni, Paulo R wrote: On Tue, 2022-05-17 at 11:32 -0700, Niranjana Vishwanathapura wrote: VM_BIND design document with description of intended use cases. v2: Add more documentation and format as per review comments from Daniel. Signed-off-by: Niranjana Vishwanathapura --- diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst b/Documentation/gpu/rfc/i915_vm_bind.rst new file mode 100644 index ..f1be560d313c --- /dev/null +++ b/Documentation/gpu/rfc/i915_vm_bind.rst @@ -0,0 +1,304 @@ +== +I915 VM_BIND feature design and use cases +== + +VM_BIND feature + +DRM_I915_GEM_VM_BIND/UNBIND ioctls allows UMD to bind/unbind GEM buffer +objects (BOs) or sections of a BOs at specified GPU virtual addresses on a +specified address space (VM). These mappings (also referred to as persistent +mappings) will be persistent across multiple GPU submissions (execbuff calls) +issued by the UMD, without user having to provide a list of all required +mappings during each submission (as required by older execbuff mode). + +VM_BIND/UNBIND ioctls will support 'in' and 'out' fences to allow userpace +to specify how the binding/unbinding should sync with other operations +like the GPU job submission. These fences will be timeline 'drm_syncobj's +for non-Compute contexts (See struct drm_i915_vm_bind_ext_timeline_fences). +For Compute contexts, they will be user/memory fences (See struct +drm_i915_vm_bind_ext_user_fence). + +VM_BIND feature is advertised to user via I915_PARAM_HAS_VM_BIND. +User has to opt-in for VM_BIND mode of binding for an address space (VM) +during VM creation time via I915_VM_CREATE_FLAGS_USE_VM_BIND extension. + +VM_BIND/UNBIND ioctl will immediately start binding/unbinding the mapping in an +async worker. The binding and unbinding will work like a special GPU engine. +The binding and unbinding operations are serialized and will wait on specified +input fences before the operation and will signal the output fences upon the +completion of the operation. Due to serialization, completion of an operation +will also indicate that all previous operations are also complete. + +VM_BIND features include: + +* Multiple Virtual Address (VA) mappings can map to the same physical pages + of an object (aliasing). +* VA mapping can map to a partial section of the BO (partial binding). +* Support capture of persistent mappings in the dump upon GPU error. +* TLB is flushed upon unbind completion. Batching of TLB flushes in some + use cases will be helpful. +* Asynchronous vm_bind and vm_unbind support with 'in' and 'out' fences. +* Support for userptr gem objects (no special uapi is required for this). + +Execbuff ioctl in VM_BIND mode +--- +The execbuff ioctl handling in VM_BIND mode differs significantly from the +older method. A VM in VM_BIND mode will not support older execbuff mode of +binding. In VM_BIND mode, execbuff ioctl will not accept any execlist. Hence, +no support for implicit sync. It is expected that the below work will be able +to support requirements of object dependency setting in all use cases: + +"dma-buf: Add an API for exporting sync files" +(https://lwn.net/Articles/859290/) I would really like to have more details here. The link provided points to new ioctls and we're not very familiar with those yet, so I think you should really clarify the interaction between the new additions here. Having some sample code would be really nice too. For Mesa at least (and I believe for the other drivers too) we always have a few exported buffers in every execbuf call, and we rely on the implicit synchronization provided by execbuf to make sure everything works. The execbuf ioctl also has some code to flush caches during implicit synchronization AFAIR, so I would guess we rely on it too and whatever else the Kernel does. Is that covered by the new ioctls? In addition, as far as I remember, one of the big improvements of vm_bind was that it would help reduce ioctl latency and cpu overhead. But if making execbuf faster comes at the cost of requiring additional ioctls calls for implicit synchronization, which is required on ever execbuf call, then I wonder if we'll even get any faster at all. Comparing old execbuf vs plain new execbuf without the new required ioctls won't make sense. But maybe I'm wrong and we won't need to call these new ioctls around every single execbuf ioctl we submit? Again, more clarification and some code examples here would be really nice. This is a big change on an important part of the API, we should clarify the new expected usage. Thanks Paulo for the comments. In VM_BIND mode, the only reason we would need execlist support in execbuff path is for implicit synchronization. And AFAIK, this work from Jason is expected replace implict synchronization with new ioctls. Hence, VM_BIND mode will not be
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev7)
== Series Details == Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev7) URL : https://patchwork.freedesktop.org/series/102665/ State : warning == Summary == Error: dim checkpatch failed 9e468bd7db66 drm/i915/gt: Add media freq factor to per-gt sysfs 10b8fc18842f drm/i915/pcode: Init pcode on different gt's e0f712fb7eab drm/i915/gt: Add media RP0/RPn to per-gt sysfs -:83: CHECK:CAMELCASE: Avoid CamelCase: #83: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:720: +static DEVICE_ATTR_RO(media_RPn_freq_mhz); -:89: CHECK:CAMELCASE: Avoid CamelCase: #89: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:726: + _attr_media_RPn_freq_mhz.attr, total: 0 errors, 0 warnings, 2 checks, 80 lines checked fc74c8104e52 drm/i915/gt: Fix memory leaks in per-gt sysfs
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Add HWMON support
== Series Details == Series: drm/i915: Add HWMON support URL : https://patchwork.freedesktop.org/series/104278/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11691 -> Patchwork_104278v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_104278v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_104278v1, 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_104278v1/index.html Participating hosts (45 -> 44) -- Additional (2): bat-dg2-8 fi-tgl-u2 Missing(3): fi-bsw-kefka fi-icl-u2 fi-bsw-n3050 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_104278v1: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-bsw-nick:[PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11691/fi-bsw-nick/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104278v1/fi-bsw-nick/igt@core_hotunp...@unbind-rebind.html New tests - New tests have been introduced between CI_DRM_11691 and Patchwork_104278v1: ### New IGT tests (112) ### * igt@dmabuf@all@dma_fence_chain: - Statuses : 36 pass(s) - Exec time: [5.22, 7.62] s * igt@gem_busy@busy: - Statuses : 1 skip(s) - Exec time: [0.0] s * igt@gem_busy@busy@all: - Statuses : 42 pass(s) - Exec time: [0.01, 0.32] s * igt@gem_exec_parallel@engines: - Statuses : 1 skip(s) - Exec time: [0.0] s * igt@gem_exec_parallel@engines@basic: - Statuses : 41 pass(s) 1 skip(s) - Exec time: [0.00, 10.67] s * igt@gem_exec_parallel@engines@contexts: - Statuses : 39 pass(s) 3 skip(s) - Exec time: [0.00, 16.30] s * igt@gem_exec_parallel@engines@fds: - Statuses : 37 pass(s) 5 skip(s) - Exec time: [0.0, 15.30] s * igt@gem_exec_store@basic: - Statuses : 41 pass(s) 2 skip(s) - Exec time: [0.0, 0.17] s * igt@gem_wait@busy: - Statuses : 1 skip(s) - Exec time: [0.0] s * igt@gem_wait@busy@all: - Statuses : 42 pass(s) - Exec time: [0.51, 0.60] s * igt@gem_wait@wait: - Statuses : 1 skip(s) - Exec time: [0.0] s * igt@gem_wait@wait@all: - Statuses : 42 pass(s) - Exec time: [1.01, 1.11] s * igt@kms_flip@basic-flip-vs-dpms@a-dp1: - Statuses : 3 pass(s) - Exec time: [0.70, 0.85] s * igt@kms_flip@basic-flip-vs-dpms@a-dp2: - Statuses : 3 pass(s) - Exec time: [0.61, 0.74] s * igt@kms_flip@basic-flip-vs-dpms@a-dsi1: - Statuses : 3 pass(s) - Exec time: [1.55, 2.11] s * igt@kms_flip@basic-flip-vs-dpms@a-edp1: - Statuses : 1 dmesg-warn(s) 8 pass(s) - Exec time: [2.66, 3.43] s * igt@kms_flip@basic-flip-vs-dpms@a-hdmi-a1: - Statuses : 9 pass(s) - Exec time: [0.64, 0.88] s * igt@kms_flip@basic-flip-vs-dpms@a-hdmi-a2: - Statuses : 5 pass(s) - Exec time: [0.65, 1.08] s * igt@kms_flip@basic-flip-vs-dpms@a-lvds1: - Statuses : 1 pass(s) - Exec time: [1.78] s * igt@kms_flip@basic-flip-vs-dpms@a-vga1: - Statuses : 10 pass(s) - Exec time: [0.68, 1.70] s * igt@kms_flip@basic-flip-vs-dpms@b-dp1: - Statuses : 3 pass(s) - Exec time: [0.70, 0.81] s * igt@kms_flip@basic-flip-vs-dpms@b-dp2: - Statuses : 3 pass(s) - Exec time: [0.60, 0.73] s * igt@kms_flip@basic-flip-vs-dpms@b-dsi1: - Statuses : 3 pass(s) - Exec time: [1.35, 1.67] s * igt@kms_flip@basic-flip-vs-dpms@b-edp1: - Statuses : 9 pass(s) - Exec time: [2.29, 2.51] s * igt@kms_flip@basic-flip-vs-dpms@b-hdmi-a1: - Statuses : 9 pass(s) - Exec time: [0.64, 0.85] s * igt@kms_flip@basic-flip-vs-dpms@b-hdmi-a2: - Statuses : 5 pass(s) - Exec time: [0.63, 1.02] s * igt@kms_flip@basic-flip-vs-dpms@b-lvds1: - Statuses : 1 pass(s) - Exec time: [1.41] s * igt@kms_flip@basic-flip-vs-dpms@b-vga1: - Statuses : 10 pass(s) - Exec time: [0.65, 1.37] s * igt@kms_flip@basic-flip-vs-dpms@c-dp1: - Statuses : 2 pass(s) - Exec time: [0.77, 0.81] s * igt@kms_flip@basic-flip-vs-dpms@c-dp2: - Statuses : 3 pass(s) - Exec time: [0.60, 0.72] s * igt@kms_flip@basic-flip-vs-dpms@c-dsi1: - Statuses : 3 pass(s) - Exec time: [1.34, 1.64] s * igt@kms_flip@basic-flip-vs-dpms@c-edp1: - Statuses : 9 pass(s) - Exec time: [2.30, 2.51] s * igt@kms_flip@basic-flip-vs-dpms@c-hdmi-a1: - Statuses : 7 pass(s) - Exec time: [0.65, 0.85] s * igt@kms_flip@basic-flip-vs-dpms@c-hdmi-a2: - Statuses : 5 pass(s) - Exec time: [0.61, 1.08] s * igt@kms_flip@basic-flip-vs-dpms@c-vga1: - Statuses : 3
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Add HWMON support
== Series Details == Series: drm/i915: Add HWMON support URL : https://patchwork.freedesktop.org/series/104278/ State : warning == Summary == Error: dim checkpatch failed 461a66ade2f0 drm/i915/hwmon: Add HWMON power sensor support Traceback (most recent call last): File "scripts/spdxcheck.py", line 10, in import git ModuleNotFoundError: No module named 'git' Traceback (most recent call last): File "scripts/spdxcheck.py", line 10, in import git ModuleNotFoundError: No module named 'git' -:15: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #15: new file mode 100644 -:135: CHECK:MACRO_ARG_REUSE: Macro argument reuse '__mask' - possible side-effects? #135: FILE: drivers/gpu/drm/i915/i915_hwmon.c:24: +#define FIELD_SHIFT(__mask)\ + (BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \ + BUILD_BUG_ON_ZERO((__mask) == 0) + \ + __bf_shf(__mask)) total: 0 errors, 1 warnings, 1 checks, 559 lines checked 14d8fb223c66 drm/i915/hwmon: Add HWMON energy support 629e24ca4b59 drm/i915/hwmon: Add HWMON current voltage support
Re: [Intel-gfx] [PATCH v3 1/1] vfio: remove VFIO_GROUP_NOTIFY_SET_KVM
Hi Zhi & Zhenyu,
Please review gvt changes below, I'd prefer to get your ack included.
Thanks!
Alex
On Thu, 19 May 2022 14:33:11 -0400
Matthew Rosato wrote:
> Rather than relying on a notifier for associating the KVM with
> the group, let's assume that the association has already been
> made prior to device_open. The first time a device is opened
> associate the group KVM with the device.
>
> This fixes a user-triggerable oops in GVT.
>
> Reviewed-by: Tony Krowiak
> Reviewed-by: Kevin Tian
> Reviewed-by: Christoph Hellwig
> Signed-off-by: Jason Gunthorpe
> Signed-off-by: Matthew Rosato
> ---
> drivers/gpu/drm/i915/gvt/gtt.c| 4 +-
> drivers/gpu/drm/i915/gvt/gvt.h| 3 -
> drivers/gpu/drm/i915/gvt/kvmgt.c | 82 ++
> drivers/s390/crypto/vfio_ap_ops.c | 35 ++-
> drivers/s390/crypto/vfio_ap_private.h | 3 -
> drivers/vfio/vfio.c | 83 ++-
> include/linux/vfio.h | 6 +-
> 7 files changed, 57 insertions(+), 159 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c
> index 9c5cc2800975..b4f69364f9a1 100644
> --- a/drivers/gpu/drm/i915/gvt/gtt.c
> +++ b/drivers/gpu/drm/i915/gvt/gtt.c
> @@ -51,7 +51,7 @@ static int preallocated_oos_pages = 8192;
>
> static bool intel_gvt_is_valid_gfn(struct intel_vgpu *vgpu, unsigned long
> gfn)
> {
> - struct kvm *kvm = vgpu->kvm;
> + struct kvm *kvm = vgpu->vfio_device.kvm;
> int idx;
> bool ret;
>
> @@ -1185,7 +1185,7 @@ static int is_2MB_gtt_possible(struct intel_vgpu *vgpu,
>
> if (!vgpu->attached)
> return -EINVAL;
> - pfn = gfn_to_pfn(vgpu->kvm, ops->get_pfn(entry));
> + pfn = gfn_to_pfn(vgpu->vfio_device.kvm, ops->get_pfn(entry));
> if (is_error_noslot_pfn(pfn))
> return -EINVAL;
> return PageTransHuge(pfn_to_page(pfn));
> diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
> index 2af4c83e733c..aee1a45da74b 100644
> --- a/drivers/gpu/drm/i915/gvt/gvt.h
> +++ b/drivers/gpu/drm/i915/gvt/gvt.h
> @@ -227,9 +227,6 @@ struct intel_vgpu {
> struct mutex cache_lock;
>
> struct notifier_block iommu_notifier;
> - struct notifier_block group_notifier;
> - struct kvm *kvm;
> - struct work_struct release_work;
> atomic_t released;
>
> struct kvm_page_track_notifier_node track_node;
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 7655ffa97d51..e2f6c56ab342 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -228,8 +228,6 @@ static void intel_gvt_cleanup_vgpu_type_groups(struct
> intel_gvt *gvt)
> }
> }
>
> -static void intel_vgpu_release_work(struct work_struct *work);
> -
> static void gvt_unpin_guest_page(struct intel_vgpu *vgpu, unsigned long gfn,
> unsigned long size)
> {
> @@ -761,23 +759,6 @@ static int intel_vgpu_iommu_notifier(struct
> notifier_block *nb,
> return NOTIFY_OK;
> }
>
> -static int intel_vgpu_group_notifier(struct notifier_block *nb,
> - unsigned long action, void *data)
> -{
> - struct intel_vgpu *vgpu =
> - container_of(nb, struct intel_vgpu, group_notifier);
> -
> - /* the only action we care about */
> - if (action == VFIO_GROUP_NOTIFY_SET_KVM) {
> - vgpu->kvm = data;
> -
> - if (!data)
> - schedule_work(>release_work);
> - }
> -
> - return NOTIFY_OK;
> -}
> -
> static bool __kvmgt_vgpu_exist(struct intel_vgpu *vgpu)
> {
> struct intel_vgpu *itr;
> @@ -789,7 +770,7 @@ static bool __kvmgt_vgpu_exist(struct intel_vgpu *vgpu)
> if (!itr->attached)
> continue;
>
> - if (vgpu->kvm == itr->kvm) {
> + if (vgpu->vfio_device.kvm == itr->vfio_device.kvm) {
> ret = true;
> goto out;
> }
> @@ -806,7 +787,6 @@ static int intel_vgpu_open_device(struct vfio_device
> *vfio_dev)
> int ret;
>
> vgpu->iommu_notifier.notifier_call = intel_vgpu_iommu_notifier;
> - vgpu->group_notifier.notifier_call = intel_vgpu_group_notifier;
>
> events = VFIO_IOMMU_NOTIFY_DMA_UNMAP;
> ret = vfio_register_notifier(vfio_dev, VFIO_IOMMU_NOTIFY, ,
> @@ -817,38 +797,32 @@ static int intel_vgpu_open_device(struct vfio_device
> *vfio_dev)
> goto out;
> }
>
> - events = VFIO_GROUP_NOTIFY_SET_KVM;
> - ret = vfio_register_notifier(vfio_dev, VFIO_GROUP_NOTIFY, ,
> - >group_notifier);
> - if (ret != 0) {
> - gvt_vgpu_err("vfio_register_notifier for group failed: %d\n",
> - ret);
> - goto undo_iommu;
> - }
> -
> ret = -EEXIST;
> if (vgpu->attached)
> - goto
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwconfig: Report no hwconfig support on ADL-N
== Series Details ==
Series: drm/i915/hwconfig: Report no hwconfig support on ADL-N
URL : https://patchwork.freedesktop.org/series/104270/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11690 -> Patchwork_104270v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/index.html
Participating hosts (47 -> 44)
--
Missing(3): bat-dg2-8 fi-hsw-4770 fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104270v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@hugepages:
- {bat-adln-1}: [DMESG-WARN][1] ([i915#5869]) -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/bat-adln-1/igt@i915_selftest@l...@hugepages.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/bat-adln-1/igt@i915_selftest@l...@hugepages.html
* igt@i915_suspend@basic-s3-without-i915:
- {bat-adln-1}: [SKIP][3] ([i915#5869]) -> [SKIP][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/bat-adln-1/igt@i915_susp...@basic-s3-without-i915.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/bat-adln-1/igt@i915_susp...@basic-s3-without-i915.html
New tests
-
New tests have been introduced between CI_DRM_11690 and Patchwork_104270v1:
### New IGT tests (2) ###
* igt@gem_softpin@allocator-basic:
- Statuses : 34 pass(s) 9 skip(s)
- Exec time: [0.0, 0.81] s
* igt@gem_softpin@allocator-basic-reserve:
- Statuses : 34 pass(s) 9 skip(s)
- Exec time: [0.0, 0.80] s
Known issues
Here are the changes found in Patchwork_104270v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@coherency:
- fi-bdw-5557u: [PASS][5] -> [INCOMPLETE][6] ([i915#5674] /
[i915#5685])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/fi-bdw-5557u/igt@i915_selftest@l...@coherency.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/fi-bdw-5557u/igt@i915_selftest@l...@coherency.html
* igt@i915_selftest@live@gt_engines:
- bat-dg1-5: [PASS][7] -> [INCOMPLETE][8] ([i915#4418])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/bat-dg1-5/igt@i915_selftest@live@gt_engines.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-icl-u2: NOTRUN -> [SKIP][9] ([i915#5903])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/fi-icl-u2/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_busy@basic@flip:
- bat-adlp-4: [PASS][10] -> [DMESG-WARN][11] ([i915#3576])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/bat-adlp-4/igt@kms_busy@ba...@flip.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/bat-adlp-4/igt@kms_busy@ba...@flip.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: NOTRUN -> [SKIP][12] ([fdo#111827])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_flip@basic-flip-vs-wf_vblank@a-edp1:
- fi-tgl-u2: [PASS][13] -> [DMESG-WARN][14] ([i915#402])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/fi-tgl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/fi-tgl-u2/igt@kms_flip@basic-flip-vs-wf_vbl...@a-edp1.html
Possible fixes
* igt@i915_pm_rpm@module-reload:
- {bat-adln-1}: [DMESG-WARN][15] ([i915#5869]) -> [PASS][16] +37
similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/bat-adln-1/igt@i915_pm_...@module-reload.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/bat-adln-1/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live@hangcheck:
- {fi-jsl-1}: [INCOMPLETE][17] ([i915#3921] / [i915#5153]) ->
[PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/fi-jsl-1/igt@i915_selftest@l...@hangcheck.html
- fi-icl-u2: [INCOMPLETE][19] ([i915#5153]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11690/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104270v1/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html
- bat-dg1-6: [DMESG-FAIL][21] ([i915#4494] / [i915#4957]) ->
[Intel-gfx] [PATCH 4/4] drm/i915/gt: Fix memory leaks in per-gt sysfs
All kmalloc'd kobjects need a kobject_put() to free memory. For example in
previous code, kobj_gt_release() never gets called. The requirement of
kobject_put() now results in a slightly different code organization.
v2: s/gtn/gt/ (Andi)
Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")
Signed-off-by: Ashutosh Dixit
Reviewed-by: Andi Shyti
Acked-by: Andrzej Hajda
---
drivers/gpu/drm/i915/gt/intel_gt.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 29 ++--
drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 6 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +++
drivers/gpu/drm/i915/i915_sysfs.c| 2 ++
5 files changed, 19 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 034182f85501..0a3931c011c6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -790,6 +790,7 @@ void intel_gt_driver_unregister(struct intel_gt *gt)
{
intel_wakeref_t wakeref;
+ intel_gt_sysfs_unregister(gt);
intel_rps_driver_unregister(>rps);
intel_gsc_fini(>gsc);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index 8ec8bc660c8c..9e4ebf53379b 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -24,7 +24,7 @@ bool is_object_gt(struct kobject *kobj)
static struct intel_gt *kobj_to_gt(struct kobject *kobj)
{
- return container_of(kobj, struct kobj_gt, base)->gt;
+ return container_of(kobj, struct intel_gt, sysfs_gt);
}
struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
@@ -72,9 +72,9 @@ static struct attribute *id_attrs[] = {
};
ATTRIBUTE_GROUPS(id);
+/* A kobject needs a release() method even if it does nothing */
static void kobj_gt_release(struct kobject *kobj)
{
- kfree(kobj);
}
static struct kobj_type kobj_gt_type = {
@@ -85,8 +85,6 @@ static struct kobj_type kobj_gt_type = {
void intel_gt_sysfs_register(struct intel_gt *gt)
{
- struct kobj_gt *kg;
-
/*
* We need to make things right with the
* ABI compatibility. The files were originally
@@ -98,25 +96,22 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
if (gt_is_root(gt))
intel_gt_sysfs_pm_init(gt, gt_get_parent_obj(gt));
- kg = kzalloc(sizeof(*kg), GFP_KERNEL);
- if (!kg)
+ /* init and xfer ownership to sysfs tree */
+ if (kobject_init_and_add(>sysfs_gt, _gt_type,
+gt->i915->sysfs_gt, "gt%d", gt->info.id))
goto exit_fail;
- kobject_init(>base, _gt_type);
- kg->gt = gt;
-
- /* xfer ownership to sysfs tree */
- if (kobject_add(>base, gt->i915->sysfs_gt, "gt%d", gt->info.id))
- goto exit_kobj_put;
-
- intel_gt_sysfs_pm_init(gt, >base);
+ intel_gt_sysfs_pm_init(gt, >sysfs_gt);
return;
-exit_kobj_put:
- kobject_put(>base);
-
exit_fail:
+ kobject_put(>sysfs_gt);
drm_warn(>i915->drm,
"failed to initialize gt%d sysfs root\n", gt->info.id);
}
+
+void intel_gt_sysfs_unregister(struct intel_gt *gt)
+{
+ kobject_put(>sysfs_gt);
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
index 9471b26752cf..a99aa7e8b01a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
@@ -13,11 +13,6 @@
struct intel_gt;
-struct kobj_gt {
- struct kobject base;
- struct intel_gt *gt;
-};
-
bool is_object_gt(struct kobject *kobj);
struct drm_i915_private *kobj_to_i915(struct kobject *kobj);
@@ -28,6 +23,7 @@ intel_gt_create_kobj(struct intel_gt *gt,
const char *name);
void intel_gt_sysfs_register(struct intel_gt *gt);
+void intel_gt_sysfs_unregister(struct intel_gt *gt);
struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
const char *name);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 097e10291f2d..993f003dad1d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -225,6 +225,9 @@ struct intel_gt {
} mocs;
struct intel_pxp pxp;
+
+ /* gt/gtN sysfs */
+ struct kobject sysfs_gt;
};
enum intel_gt_scratch_field {
diff --git a/drivers/gpu/drm/i915/i915_sysfs.c
b/drivers/gpu/drm/i915/i915_sysfs.c
index 8521daba212a..3f06106cdcf5 100644
--- a/drivers/gpu/drm/i915/i915_sysfs.c
+++ b/drivers/gpu/drm/i915/i915_sysfs.c
@@ -259,4 +259,6 @@ void i915_teardown_sysfs(struct drm_i915_private *dev_priv)
device_remove_bin_file(kdev, _attrs_1);
device_remove_bin_file(kdev, _attrs);
+
+ kobject_put(dev_priv->sysfs_gt);
}
--
2.34.1
[Intel-gfx] [PATCH 3/4] drm/i915/gt: Add media RP0/RPn to per-gt sysfs
From: Dale B Stimson
Retrieve RP0 and RPn freq for media IP from PCODE and display in per-gt
sysfs. This patch adds the following files to gt/gtN sysfs:
* media_RP0_freq_mhz
* media_RPn_freq_mhz
v2: Fixed commit author (Rodrigo)
v3: Convert to new uncore interface for pcode functions
v4: Adapt to intel_pcode.* function rename
v5: #include "intel_pcode.h" in alphabetical order (Tvrtko)
Cc: Tvrtko Ursulin
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 47 +
drivers/gpu/drm/i915/i915_reg.h | 8
2 files changed, 55 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index 081a17f5ca33..ae8a8f725f01 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -14,6 +14,7 @@
#include "intel_gt_regs.h"
#include "intel_gt_sysfs.h"
#include "intel_gt_sysfs_pm.h"
+#include "intel_pcode.h"
#include "intel_rc6.h"
#include "intel_rps.h"
@@ -670,13 +671,59 @@ static ssize_t media_freq_factor_store(struct device *dev,
return err ?: count;
}
+static ssize_t media_RP0_freq_mhz_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+ u32 val;
+ int err;
+
+ err = snb_pcode_read_p(gt->uncore, XEHPSDV_PCODE_FREQUENCY_CONFIG,
+ PCODE_MBOX_FC_SC_READ_FUSED_P0,
+ PCODE_MBOX_DOMAIN_MEDIAFF, );
+
+ if (err)
+ return err;
+
+ /* Fused media RP0 read from pcode is in units of 50 MHz */
+ val *= GT_FREQUENCY_MULTIPLIER;
+
+ return sysfs_emit(buff, "%u\n", val);
+}
+
+static ssize_t media_RPn_freq_mhz_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+ u32 val;
+ int err;
+
+ err = snb_pcode_read_p(gt->uncore, XEHPSDV_PCODE_FREQUENCY_CONFIG,
+ PCODE_MBOX_FC_SC_READ_FUSED_PN,
+ PCODE_MBOX_DOMAIN_MEDIAFF, );
+
+ if (err)
+ return err;
+
+ /* Fused media RPn read from pcode is in units of 50 MHz */
+ val *= GT_FREQUENCY_MULTIPLIER;
+
+ return sysfs_emit(buff, "%u\n", val);
+}
+
static DEVICE_ATTR_RW(media_freq_factor);
static struct device_attribute dev_attr_media_freq_factor_scale =
__ATTR(media_freq_factor.scale, 0444, freq_factor_scale_show, NULL);
+static DEVICE_ATTR_RO(media_RP0_freq_mhz);
+static DEVICE_ATTR_RO(media_RPn_freq_mhz);
static const struct attribute *media_perf_power_attrs[] = {
_attr_media_freq_factor.attr,
_attr_media_freq_factor_scale.attr,
+ _attr_media_RP0_freq_mhz.attr,
+ _attr_media_RPn_freq_mhz.attr,
NULL
};
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d8579ab9384c..0a5064e32284 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6804,6 +6804,14 @@
#define DG1_UNCORE_GET_INIT_STATUS 0x0
#define DG1_UNCORE_INIT_STATUS_COMPLETE0x1
#define GEN12_PCODE_READ_SAGV_BLOCK_TIME_US0x23
+#define XEHPSDV_PCODE_FREQUENCY_CONFIG 0x6e/* xehpsdv, pvc
*/
+/* XEHPSDV_PCODE_FREQUENCY_CONFIG sub-commands (param1) */
+#define PCODE_MBOX_FC_SC_READ_FUSED_P0 0x0
+#define PCODE_MBOX_FC_SC_READ_FUSED_PN 0x1
+/* PCODE_MBOX_DOMAIN_* - mailbox domain IDs */
+/* XEHPSDV_PCODE_FREQUENCY_CONFIG param2 */
+#define PCODE_MBOX_DOMAIN_NONE 0x0
+#define PCODE_MBOX_DOMAIN_MEDIAFF 0x3
#define GEN6_PCODE_DATA_MMIO(0x138128)
#define GEN6_PCODE_FREQ_IA_RATIO_SHIFT 8
#define GEN6_PCODE_FREQ_RING_RATIO_SHIFT 16
--
2.34.1
[Intel-gfx] [PATCH 2/4] drm/i915/pcode: Init pcode on different gt's
Extend pcode initialization to pcode on different gt's.
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Signed-off-by: Ashutosh Dixit
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index b47746152d97..d26dcca7e654 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -520,6 +520,22 @@ static int i915_set_dma_info(struct drm_i915_private *i915)
return ret;
}
+static int i915_pcode_init(struct drm_i915_private *i915)
+{
+ struct intel_gt *gt;
+ int id, ret;
+
+ for_each_gt(gt, i915, id) {
+ ret = intel_pcode_init(gt->uncore);
+ if (ret) {
+ drm_err(>i915->drm, "gt%d: intel_pcode_init failed
%d\n", id, ret);
+ return ret;
+ }
+ }
+
+ return 0;
+}
+
/**
* i915_driver_hw_probe - setup state requiring device access
* @dev_priv: device private
@@ -629,7 +645,7 @@ static int i915_driver_hw_probe(struct drm_i915_private
*dev_priv)
intel_opregion_setup(dev_priv);
- ret = intel_pcode_init(_priv->uncore);
+ ret = i915_pcode_init(dev_priv);
if (ret)
goto err_msi;
@@ -1251,7 +1267,7 @@ static int i915_drm_resume(struct drm_device *dev)
disable_rpm_wakeref_asserts(_priv->runtime_pm);
- ret = intel_pcode_init(_priv->uncore);
+ ret = i915_pcode_init(dev_priv);
if (ret)
return ret;
--
2.34.1
[Intel-gfx] [PATCH 1/4] drm/i915/gt: Add media freq factor to per-gt sysfs
Expose new sysfs to program and retrieve media freq factor. Factor values
of 0 (dynamic), 0.5 and 1.0 are supported via a u8.8 fixed point
representation (corresponding to integer values of 0, 128 and 256
respectively).
Media freq factor is converted to media_ratio_mode for GuC. It is
programmed into GuC using H2G SLPC interface. It is retrieved from GuC
through a register read. A cached media_ratio_mode is maintained to
preserve set values across GuC resets.
This patch adds the following sysfs files to gt/gtN sysfs:
* media_freq_factor
* media_freq_factor.scale
v2: Minor wording change in drm_warn (Tvrtko)
Cc: Tvrtko Ursulin
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Reviewed-by: Andi Shyti
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 +
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 130 ++
.../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 6 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 20 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 +
.../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 3 +
6 files changed, 161 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 7246eb870c7e..b4642dcc192f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -740,6 +740,7 @@
#define GEN6_AGGRESSIVE_TURBO(0 << 15)
#define GEN9_SW_REQ_UNSLICE_RATIO_SHIFT 23
#define GEN9_IGNORE_SLICE_RATIO (0 << 0)
+#define GEN12_MEDIA_FREQ_RATIO REG_BIT(13)
#define GEN6_RC_VIDEO_FREQ _MMIO(0xa00c)
#define GEN6_RC_CTL_RC6pp_ENABLE (1 << 16)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
index f76b6cf8040e..081a17f5ca33 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -558,6 +558,128 @@ static const struct attribute *freq_attrs[] = {
NULL
};
+/*
+ * Scaling for multipliers (aka frequency factors).
+ * The format of the value in the register is u8.8.
+ *
+ * The presentation to userspace is inspired by the perf event framework.
+ * See:
+ * Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+ * for description of:
+ * /sys/bus/event_source/devices//events/.scale
+ *
+ * Summary: Expose two sysfs files for each multiplier.
+ *
+ * 1. File contains a raw hardware value.
+ * 2. File .scale contains the multiplicative scale factor to be
+ *used by userspace to compute the actual value.
+ *
+ * So userspace knows that to get the frequency_factor it multiplies the
+ * provided value by the specified scale factor and vice-versa.
+ *
+ * That way there is no precision loss in the kernel interface and API
+ * is future proof should one day the hardware register change to u16.u16,
+ * on some platform. (Or any other fixed point representation.)
+ *
+ * Example:
+ * File contains the value 2.5, represented as u8.8 0x0280, which
+ * is comprised of:
+ * - an integer part of 2
+ * - a fractional part of 0x80 (representing 0x80 / 2^8 == 0x80 / 256).
+ * File .scale contains a string representation of floating point
+ * value 0.00390625 (which is (1 / 256)).
+ * Userspace computes the actual value:
+ * 0x0280 * 0.00390625 -> 2.5
+ * or converts an actual value to the value to be written into :
+ * 2.5 / 0.00390625 -> 0x0280
+ */
+
+#define U8_8_VAL_MASK 0x
+#define U8_8_SCALE_TO_VALUE "0.00390625"
+
+static ssize_t freq_factor_scale_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ return sysfs_emit(buff, "%s\n", U8_8_SCALE_TO_VALUE);
+}
+
+static u32 media_ratio_mode_to_factor(u32 mode)
+{
+ /* 0 -> 0, 1 -> 256, 2 -> 128 */
+ return !mode ? mode : 256 / mode;
+}
+
+static ssize_t media_freq_factor_show(struct device *dev,
+ struct device_attribute *attr,
+ char *buff)
+{
+ struct intel_gt *gt = intel_gt_sysfs_get_drvdata(dev, attr->attr.name);
+ struct intel_guc_slpc *slpc = >uc.guc.slpc;
+ intel_wakeref_t wakeref;
+ u32 mode;
+
+ /*
+* Retrieve media_ratio_mode from GEN6_RPNSWREQ bit 13 set by
+* GuC. GEN6_RPNSWREQ:13 value 0 represents 1:2 and 1 represents 1:1
+*/
+ if (IS_XEHPSDV(gt->i915) &&
+ slpc->media_ratio_mode == SLPC_MEDIA_RATIO_MODE_DYNAMIC_CONTROL) {
+ /*
+* For XEHPSDV dynamic mode GEN6_RPNSWREQ:13 does not contain
+* the media_ratio_mode, just return the cached media ratio
+*/
+ mode = slpc->media_ratio_mode;
+ } else {
+ with_intel_runtime_pm(gt->uncore->rpm, wakeref)
+ mode =
[Intel-gfx] [PATCH 0/4] drm/i915: Media freq factor and per-gt enhancements/fixes
Some recent Intel dGfx platforms allow media IP to work at a different frequency from the base GT. This patch series exposes sysfs controls for this functionality in the new per-gt sysfs. Some enhancements and fixes to previous per-gt functionality are also included to complete the new functionality: * Patches 1 and 2 implement basic sysfs controls for media freq * Patch 3 extends previous pcode functions for multiple gt's * Patch 4 inits pcode on different gt's * Patch 5 adds a couple of pcode helpers * Patch 6 uses the new pcode functions to retrieve media RP0/RPn freq * Patch 7 fixes memory leaks in the previous per-gt sysfs implementation and some code refactoring IGT tests for this new functionality have also been posted at: https://patchwork.freedesktop.org/series/103175/ Test-with: 20220513011500.73460-1-ashutosh.di...@intel.com v2: Fixed commit author on patches 5 and 6 (Rodrigo) Added new patch 4 v3: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo) v4: Retain previous pcode function names to eliminate needless #defines (Rodrigo) v5: Add new patch 4 and remove last two patches in the v4 series which will be submitted later. Other mostly minor fixes from code review v6: Identical to v5, only update "Test-with:" since CI did not pick up previous "Test-with:" probably because it was old v7: Rebase remaining patches after patches 1, 3 and 5 have been merged Ashutosh Dixit (3): drm/i915/gt: Add media freq factor to per-gt sysfs drm/i915/pcode: Init pcode on different gt's drm/i915/gt: Fix memory leaks in per-gt sysfs Dale B Stimson (1): drm/i915/gt: Add media RP0/RPn to per-gt sysfs drivers/gpu/drm/i915/gt/intel_gt.c| 1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 29 ++- drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 6 +- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 177 ++ drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 6 + drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 20 ++ drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 + .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 3 + drivers/gpu/drm/i915/i915_driver.c| 20 +- drivers/gpu/drm/i915/i915_reg.h | 8 + drivers/gpu/drm/i915/i915_sysfs.c | 2 + 13 files changed, 253 insertions(+), 24 deletions(-) -- 2.34.1
Re: [Intel-gfx] [PATCH 3/4] drm/i915: allow volatile buffers to use ttm pool allocator
On 11/05/2022 13:42, Thomas Hellström wrote:
Hi, Bob,
On Tue, 2022-05-03 at 19:13 +, Robert Beckett wrote:
internal buffers should be shmem backed.
if a volatile buffer is requested, allow ttm to use the pool
allocator
to provide volatile pages as backing
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4c25d9b2f138..fdb3a1c18cb6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -309,7 +309,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct
ttm_buffer_object *bo,
page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
caching = i915_ttm_select_tt_caching(obj);
- if (i915_gem_object_is_shrinkable(obj) && caching ==
ttm_cached) {
+ if (i915_gem_object_is_shrinkable(obj) && caching ==
ttm_cached &&
+ !i915_gem_object_is_volatile(obj)) {
page_flags |= TTM_TT_FLAG_EXTERNAL |
TTM_TT_FLAG_EXTERNAL_MAPPABLE;
i915_tt->is_shmem = true;
While this is ok, I think it also needs adjustment in the i915_ttm
shrink callback. If someone creates a volatile smem object which then
hits the shrinker, I think we might hit asserts that it's a is_shem
ttm?
In this case, the shrink callback should just i915_ttm_purge().
agreed. nice catch.
I'll fix for v2
looks like we could maybe do with some extra shrinker testing too? looks
like nothing caught this during CI testing
/Thomas
Re: [Intel-gfx] [PATCH 1/4] drm/i915: add gen6 ppgtt dummy creation function
On 11/05/2022 11:13, Thomas Hellström wrote:
Hi,
On Tue, 2022-05-03 at 19:13 +, Robert Beckett wrote:
Internal gem objects will soon just be volatile system memory region
objects.
To enable this, create a separate dummy object creation function
for gen6 ppgtt
It's not clear from the commit message why we need a special case for
this. Could you describe more in detail?
it always was a special case, that used the internal backend but
provided it's own ops, so actually had no benefit from using the
internal backend. See b0b0f2d225da6fe58417fae37e3f797e2db27b62
I'll add some further explanation in the commit message for v2.
Thanks,
Thomas
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 43
++--
1 file changed, 40 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 1bb766c79dcb..f3b660cfeb7f 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -372,6 +372,45 @@ static const struct drm_i915_gem_object_ops
pd_dummy_obj_ops = {
.put_pages = pd_dummy_obj_put_pages,
};
+static struct drm_i915_gem_object *
+i915_gem_object_create_dummy(struct drm_i915_private *i915,
phys_addr_t size)
+{
+ static struct lock_class_key lock_class;
+ struct drm_i915_gem_object *obj;
+ unsigned int cache_level;
+
+ GEM_BUG_ON(!size);
+ GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
+
+ if (overflows_type(size, obj->base.size))
+ return ERR_PTR(-E2BIG);
+
+ obj = i915_gem_object_alloc();
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ drm_gem_private_object_init(>drm, >base, size);
+ i915_gem_object_init(obj, _dummy_obj_ops, _class, 0);
+ obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
+
+ /*
+ * Mark the object as volatile, such that the pages are
marked as
+ * dontneed whilst they are still pinned. As soon as they are
unpinned
+ * they are allowed to be reaped by the shrinker, and the
caller is
+ * expected to repopulate - the contents of this object are
only valid
+ * whilst active and pinned.
+ */
+ i915_gem_object_set_volatile(obj);
+
+ obj->read_domains = I915_GEM_DOMAIN_CPU;
+ obj->write_domain = I915_GEM_DOMAIN_CPU;
+
+ cache_level = HAS_LLC(i915) ? I915_CACHE_LLC :
I915_CACHE_NONE;
+ i915_gem_object_set_cache_coherency(obj, cache_level);
+
+ return obj;
+}
+
static struct i915_page_directory *
gen6_alloc_top_pd(struct gen6_ppgtt *ppgtt)
{
@@ -383,9 +422,7 @@ gen6_alloc_top_pd(struct gen6_ppgtt *ppgtt)
if (unlikely(!pd))
return ERR_PTR(-ENOMEM);
- pd->pt.base = __i915_gem_object_create_internal(ppgtt-
base.vm.gt->i915,
-
_dummy_obj_o
ps,
- I915_PDES *
SZ_4K);
+ pd->pt.base = i915_gem_object_create_dummy(ppgtt->base.vm.gt-
i915, I915_PDES * SZ_4K);
if (IS_ERR(pd->pt.base)) {
err = PTR_ERR(pd->pt.base);
pd->pt.base = NULL;
Re: [Intel-gfx] [PATCH 4/4] drm/i915: internal buffers use ttm backend
On 11/05/2022 15:14, Thomas Hellström wrote:
On Tue, 2022-05-03 at 19:13 +, Robert Beckett wrote:
refactor internal buffer backend to allocate volatile pages via
ttm pool allocator
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 264 -
--
drivers/gpu/drm/i915/gem/i915_gem_internal.h | 5 -
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 12 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 12 +-
4 files changed, 125 insertions(+), 168 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index c698f95af15f..815ec9466cc0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -4,156 +4,119 @@
* Copyright © 2014-2016 Intel Corporation
*/
-#include
-#include
-#include
-
+#include
+#include
+#include "drm/ttm/ttm_bo_api.h"
+#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_region.h"
+#include "gem/i915_gem_ttm.h"
#include "i915_drv.h"
-#include "i915_gem.h"
-#include "i915_gem_internal.h"
-#include "i915_gem_object.h"
-#include "i915_scatterlist.h"
-#include "i915_utils.h"
-
-#define QUIET (__GFP_NORETRY | __GFP_NOWARN)
-#define MAYFAIL (__GFP_RETRY_MAYFAIL | __GFP_NOWARN)
-
-static void internal_free_pages(struct sg_table *st)
-{
- struct scatterlist *sg;
-
- for (sg = st->sgl; sg; sg = __sg_next(sg)) {
- if (sg_page(sg))
- __free_pages(sg_page(sg), get_order(sg-
length));
- }
-
- sg_free_table(st);
- kfree(st);
-}
-static int i915_gem_object_get_pages_internal(struct
drm_i915_gem_object *obj)
+static int i915_internal_get_pages(struct drm_i915_gem_object *obj)
{
- struct drm_i915_private *i915 = to_i915(obj->base.dev);
- struct sg_table *st;
- struct scatterlist *sg;
- unsigned int sg_page_sizes;
- unsigned int npages;
- int max_order;
- 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));
- }
+ struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
+ struct ttm_operation_ctx ctx = {
+ .interruptible = true,
+ .no_wait_gpu = false,
+ };
+ struct ttm_place place = {
+ .fpfn = 0,
+ .lpfn = 0,
+ .mem_type = I915_PL_SYSTEM,
+ .flags = 0,
+ };
+ struct ttm_placement placement = {
+ .num_placement = 1,
+ .placement = ,
+ .num_busy_placement = 0,
+ .busy_placement = NULL,
+ };
+ int ret;
+
+ ret = ttm_bo_validate(bo, , );
+ if (ret) {
+ ret = i915_ttm_err_to_gem(ret);
+ return ret;
}
-#endif
- gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
- if (IS_I965GM(i915) || IS_I965G(i915)) {
- /* 965gm cannot relocate objects above 4GiB. */
- gfp &= ~__GFP_HIGHMEM;
- gfp |= __GFP_DMA32;
It looks like we're losing this restriction?
There is a flag to ttm_device_init() to make TTM only do __GFP_DMA32
allocations.
agreed. will fix for v2
+ if (bo->ttm && !ttm_tt_is_populated(bo->ttm)) {
+ ret = ttm_tt_populate(bo->bdev, bo->ttm, );
+ if (ret)
+ return ret;
}
-create_st:
- st = kmalloc(sizeof(*st), GFP_KERNEL);
- if (!st)
- return -ENOMEM;
+ if (!i915_gem_object_has_pages(obj)) {
+ struct i915_refct_sgt *rsgt =
+ i915_ttm_resource_get_st(obj, bo->resource);
- npages = obj->base.size / PAGE_SIZE;
- if (sg_alloc_table(st, npages, GFP_KERNEL)) {
- kfree(st);
- return -ENOMEM;
- }
+ if (IS_ERR(rsgt))
+ return PTR_ERR(rsgt);
- sg = st->sgl;
- st->nents = 0;
- sg_page_sizes = 0;
-
- do {
- int order = min(fls(npages) - 1, max_order);
- struct page *page;
-
- do {
- page = alloc_pages(gfp | (order ? QUIET :
MAYFAIL),
- order);
- if (page)
- break;
- if (!order--)
- goto err;
-
- /* Limit subsequent allocations as well */
- max_order = order;
- } while (1);
-
-
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/d12+: Disable DMC firmware flip queue handlers (rev4)
On Sat, May 21, 2022 at 03:09:30PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/d12+: Disable DMC firmware flip queue handlers (rev4) > URL : https://patchwork.freedesktop.org/series/103888/ > State : success Pushed to drm-intel-next, thanks for the reviews. > == Summary == > > CI Bug Log - changes from CI_DRM_11682_full -> Patchwork_103888v4_full > > > Summary > --- > > **SUCCESS** > > No regressions found. > > > > Participating hosts (13 -> 13) > -- > > No changes in participating hosts > > Known issues > > > Here are the changes found in Patchwork_103888v4_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_eio@in-flight-immediate: > - shard-skl: [PASS][1] -> [TIMEOUT][2] ([i915#3063]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/shard-skl7/igt@gem_...@in-flight-immediate.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-skl5/igt@gem_...@in-flight-immediate.html > > * igt@gem_exec_fair@basic-flow@rcs0: > - shard-tglb: [PASS][3] -> [FAIL][4] ([i915#2842]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/shard-tglb5/igt@gem_exec_fair@basic-f...@rcs0.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-tglb1/igt@gem_exec_fair@basic-f...@rcs0.html > > * igt@gem_exec_fair@basic-none@rcs0: > - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#2842]) +1 similar > issue >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/shard-kbl1/igt@gem_exec_fair@basic-n...@rcs0.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-kbl4/igt@gem_exec_fair@basic-n...@rcs0.html > > * igt@gem_exec_fair@basic-throttle@rcs0: > - shard-iclb: [PASS][7] -> [FAIL][8] ([i915#2849]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/shard-iclb4/igt@gem_exec_fair@basic-throt...@rcs0.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-iclb7/igt@gem_exec_fair@basic-throt...@rcs0.html > > * igt@gem_exec_flush@basic-uc-pro-default: > - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271]) +1 similar > issue >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/shard-snb5/igt@gem_exec_fl...@basic-uc-pro-default.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-snb6/igt@gem_exec_fl...@basic-uc-pro-default.html > > * igt@gem_lmem_swapping@verify: > - shard-skl: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-skl2/igt@gem_lmem_swapp...@verify.html > > * igt@gem_lmem_swapping@verify-random: > - shard-apl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#4613]) >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-apl8/igt@gem_lmem_swapp...@verify-random.html > > * igt@i915_pm_dc@dc6-psr: > - shard-iclb: [PASS][13] -> [FAIL][14] ([i915#454]) >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/shard-iclb5/igt@i915_pm...@dc6-psr.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-iclb6/igt@i915_pm...@dc6-psr.html > > * igt@i915_pm_rpm@dpms-mode-unset-non-lpsp: > - shard-iclb: NOTRUN -> [SKIP][15] ([fdo#110892]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-iclb7/igt@i915_pm_...@dpms-mode-unset-non-lpsp.html > > * igt@i915_selftest@live@gt_pm: > - shard-skl: NOTRUN -> [DMESG-FAIL][16] ([i915#1886]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-skl9/igt@i915_selftest@live@gt_pm.html > > * igt@i915_suspend@fence-restore-tiled2untiled: > - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11682/shard-kbl1/igt@i915_susp...@fence-restore-tiled2untiled.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-kbl6/igt@i915_susp...@fence-restore-tiled2untiled.html > > * igt@kms_big_fb@4-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip: > - shard-iclb: NOTRUN -> [SKIP][19] ([i915#5286]) >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-iclb7/igt@kms_big...@4-tiled-max-hw-stride-64bpp-rotate-0-hflip-async-flip.html > > * igt@kms_big_fb@x-tiled-32bpp-rotate-90: > - shard-snb: NOTRUN -> [SKIP][20] ([fdo#109271]) +21 similar > issues >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103888v4/shard-snb2/igt@kms_big...@x-tiled-32bpp-rotate-90.html > > * igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-180-async-flip: > - shard-skl: NOTRUN -> [FAIL][21] ([i915#3743]) >
Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Add HWMON current voltage support
On Mon, 23 May 2022, Badal Nilawar wrote:
> From: Riana Tauro
>
> As part of the System Managemenent Interface (SMI), use the HWMON
> subsystem to display current voltage
>
> Cc: Anshuman Gupta
> Signed-off-by: Riana Tauro
> Signed-off-by: Badal Nilawar
> ---
> .../ABI/testing/sysfs-driver-intel-i915-hwmon | 8 +++
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++
> drivers/gpu/drm/i915/i915_hwmon.c | 57 +++
> drivers/gpu/drm/i915/i915_hwmon.h | 1 +
> 4 files changed, 70 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> index 7574421c326f..c70e06dd0333 100644
> --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> @@ -33,3 +33,11 @@ Contact: dri-de...@lists.freedesktop.org
> Description: RO. Card default power limit (default TDP setting).
>
> Only supported for particular Intel i915 graphics platforms.
> +
> +What:/sys/devices/.../hwmon/hwmon/in0_input
> +Date:May 2022
> +KernelVersion: 5.18
> +Contact: dri-de...@lists.freedesktop.org
> +Description: RO. Current Voltage in millivolt.
> +
> + Only supported for particular Intel i915 graphics platforms.
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> index 7246eb870c7e..0adeca083de1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> @@ -1475,6 +1475,10 @@
> #define GEN6_GT_GFX_RC6p _MMIO(0x13810c)
> #define GEN6_GT_GFX_RC6pp_MMIO(0x138110)
> #define VLV_RENDER_C0_COUNT _MMIO(0x138118)
> +
> +#define GEN12_RPSTAT1_MMIO(0x1381b4)
> +#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
> +
> #define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
>
> #define GEN11_GT_INTR_DW(x) _MMIO(0x190018 + ((x) * 4))
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index b35c4de73f30..e5f4293a8fdb 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -12,6 +12,7 @@
> #include
>
> #include "i915_drv.h"
> +#include "gt/intel_gt_regs.h"
> #include "i915_hwmon.h"
> #include "intel_mchbar_regs.h"
Sort order.
>
> @@ -301,8 +302,23 @@ static const struct hwmon_channel_info i915_power = {
> .config = i915_config_power,
> };
>
> +/*
> + * HWMON SENSOR TYPE = hwmon_in
> + * - Voltage Input value (in0_input)
> + */
> +static const u32 i915_config_in[] = {
> + HWMON_I_INPUT,
> + 0
> +};
> +
> +static const struct hwmon_channel_info i915_in = {
> + .type = hwmon_in,
> + .config = i915_config_in,
> +};
> +
> static const struct hwmon_channel_info *i915_info[] = {
> _power,
> + _in,
> NULL
> };
>
> @@ -370,6 +386,41 @@ i915_power_write(struct i915_hwmon_drvdata *ddat, u32
> attr, int chan, long val)
> return ret;
> }
>
> +static umode_t
> +i915_in_is_visible(const struct i915_hwmon_drvdata *ddat, u32 attr)
> +{
> + struct drm_i915_private *i915 = ddat->dd_uncore->i915;
> +
> + switch (attr) {
> + case hwmon_in_input:
> + return (IS_DG1(i915) || IS_DG2(i915)) ? 0444 : 0;
> + default:
> + return 0;
> + }
> +
> + return 0444;
> +}
> +
> +static int
> +i915_in_read(struct i915_hwmon_drvdata *ddat, u32 attr, long *val)
> +{
> + struct i915_hwmon *hwmon = ddat->dd_hwmon;
> + intel_wakeref_t wakeref;
> + u32 reg_value;
> +
> + switch (attr) {
> + case hwmon_in_input:
> + with_intel_runtime_pm(ddat->dd_uncore->rpm, wakeref)
> + reg_value = intel_uncore_read(ddat->dd_uncore,
> hwmon->rg.gt_perf_status);
> + *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK,
> reg_value) * 25, 10);
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> static umode_t
> i915_is_visible(const void *drvdata, enum hwmon_sensor_types type,
> u32 attr, int channel)
> @@ -379,6 +430,8 @@ i915_is_visible(const void *drvdata, enum
> hwmon_sensor_types type,
> switch (type) {
> case hwmon_power:
> return i915_power_is_visible(ddat, attr, channel);
> + case hwmon_in:
> + return i915_in_is_visible(ddat, attr);
> default:
> return 0;
> }
> @@ -393,6 +446,8 @@ i915_read(struct device *dev, enum hwmon_sensor_types
> type, u32 attr,
> switch (type) {
> case hwmon_power:
> return i915_power_read(ddat, attr, channel, val);
> + case hwmon_in:
> + return i915_in_read(ddat, attr, val);
> default:
> return -EOPNOTSUPP;
> }
Re: [Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Add HWMON power sensor support
On Mon, 23 May 2022, Badal Nilawar wrote:
> From: Dale B Stimson
>
> As part of the System Managemenent Interface (SMI), use the HWMON
> subsystem to display power utilization.
>
> Signed-off-by: Dale B Stimson
> Signed-off-by: Ashutosh Dixit
> Signed-off-by: Riana Tauro
> Signed-off-by: Badal Nilawar
> ---
> .../ABI/testing/sysfs-driver-intel-i915-hwmon | 19 +
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_driver.c| 5 +
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_hwmon.c | 410 ++
> drivers/gpu/drm/i915/i915_hwmon.h | 44 ++
> drivers/gpu/drm/i915/i915_reg.h | 15 +
> drivers/gpu/drm/i915/intel_mchbar_regs.h | 9 +
> 9 files changed, 506 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
> create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> new file mode 100644
> index ..c680dd842358
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> @@ -0,0 +1,19 @@
> +What:/sys/devices/.../hwmon/hwmon/power1_max
> +Date:June 2021
> +KernelVersion: 5.14
Please check the dates and versions in all these files.
> +Contact: dri-de...@lists.freedesktop.org
> +Description: RW. Card reactive sustained (PL1/Tau) power limit in
> microwatts.
> +
> + The power controller will throttle the operating frequency
> + if the power averaged over a window (typically seconds)
> + exceeds this limit.
> +
> + Only supported for particular Intel i915 graphics platforms.
> +
> +What:/sys/devices/.../hwmon/hwmon/power1_max_default
> +Date:June 2021
> +KernelVersion: 5.14
> +Contact: dri-de...@lists.freedesktop.org
> +Description: RO. Card default power limit (default TDP setting).
> +
> + Only supported for particular Intel i915 graphics platforms.
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 7ae3b7d67fcf..c60cfacd4c47 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -19,6 +19,7 @@ config DRM_I915
> select DRM_MIPI_DSI
> select RELAY
> select IRQ_WORK
> + select HWMON
> # i915 depends on ACPI_VIDEO when ACPI is enabled
> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> select BACKLIGHT_CLASS_DEVICE if ACPI
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index d2b18f03a33c..e1d5912ea879 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -36,6 +36,7 @@ i915-y += i915_driver.o \
> i915_drm_client.o \
> i915_config.o \
> i915_getparam.o \
> + i915_hwmon.o \
> i915_ioctl.o \
> i915_irq.o \
> i915_mitigations.o \
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index b47746152d97..6f678587a771 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -80,6 +80,7 @@
> #include "i915_drm_client.h"
> #include "i915_drv.h"
> #include "i915_getparam.h"
> +#include "i915_hwmon.h"
> #include "i915_ioc32.h"
> #include "i915_ioctl.h"
> #include "i915_irq.h"
> @@ -702,6 +703,8 @@ static void i915_driver_register(struct drm_i915_private
> *dev_priv)
>
> intel_gt_driver_register(to_gt(dev_priv));
>
> + i915_hwmon_register(dev_priv);
> +
> intel_display_driver_register(dev_priv);
>
> intel_power_domains_enable(dev_priv);
> @@ -728,6 +731,8 @@ static void i915_driver_unregister(struct
> drm_i915_private *dev_priv)
>
> intel_display_driver_unregister(dev_priv);
>
> + i915_hwmon_unregister(dev_priv);
> +
> intel_gt_driver_unregister(to_gt(dev_priv));
>
> i915_perf_unregister(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c5fc402d9c50..e16bedba2d84 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -769,6 +769,8 @@ struct drm_i915_private {
>
> struct i915_perf perf;
>
> + struct i915_hwmon *hwmon;
> +
> /* Abstract the submission mechanism (legacy ringbuffer or execlists)
> away */
> struct intel_gt gt0;
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> new file mode 100644
> index ..b94c11f2517f
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -0,0 +1,410 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2020 Intel Corporation
Re: [Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Add HWMON power sensor support
On Mon, 23 May 2022, Badal Nilawar wrote:
> From: Dale B Stimson
>
> As part of the System Managemenent Interface (SMI), use the HWMON
> subsystem to display power utilization.
>
> Signed-off-by: Dale B Stimson
> Signed-off-by: Ashutosh Dixit
> Signed-off-by: Riana Tauro
> Signed-off-by: Badal Nilawar
> ---
> .../ABI/testing/sysfs-driver-intel-i915-hwmon | 19 +
> drivers/gpu/drm/i915/Kconfig | 1 +
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/i915_driver.c| 5 +
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/i915/i915_hwmon.c | 410 ++
> drivers/gpu/drm/i915/i915_hwmon.h | 44 ++
> drivers/gpu/drm/i915/i915_reg.h | 15 +
> drivers/gpu/drm/i915/intel_mchbar_regs.h | 9 +
> 9 files changed, 506 insertions(+)
> create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
> create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> new file mode 100644
> index ..c680dd842358
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> @@ -0,0 +1,19 @@
> +What:/sys/devices/.../hwmon/hwmon/power1_max
> +Date:June 2021
> +KernelVersion: 5.14
> +Contact: dri-de...@lists.freedesktop.org
> +Description: RW. Card reactive sustained (PL1/Tau) power limit in
> microwatts.
> +
> + The power controller will throttle the operating frequency
> + if the power averaged over a window (typically seconds)
> + exceeds this limit.
> +
> + Only supported for particular Intel i915 graphics platforms.
> +
> +What:/sys/devices/.../hwmon/hwmon/power1_max_default
> +Date:June 2021
> +KernelVersion: 5.14
> +Contact: dri-de...@lists.freedesktop.org
> +Description: RO. Card default power limit (default TDP setting).
> +
> + Only supported for particular Intel i915 graphics platforms.
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 7ae3b7d67fcf..c60cfacd4c47 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -19,6 +19,7 @@ config DRM_I915
> select DRM_MIPI_DSI
> select RELAY
> select IRQ_WORK
> + select HWMON
Is this really what we want, though? Maybe depends on, or make it work
with either setting. See Documentation/kbuild/kconfig-language.rst on
select.
> # i915 depends on ACPI_VIDEO when ACPI is enabled
> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> select BACKLIGHT_CLASS_DEVICE if ACPI
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index d2b18f03a33c..e1d5912ea879 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -36,6 +36,7 @@ i915-y += i915_driver.o \
> i915_drm_client.o \
> i915_config.o \
> i915_getparam.o \
> + i915_hwmon.o \
> i915_ioctl.o \
> i915_irq.o \
> i915_mitigations.o \
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index b47746152d97..6f678587a771 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -80,6 +80,7 @@
> #include "i915_drm_client.h"
> #include "i915_drv.h"
> #include "i915_getparam.h"
> +#include "i915_hwmon.h"
> #include "i915_ioc32.h"
> #include "i915_ioctl.h"
> #include "i915_irq.h"
> @@ -702,6 +703,8 @@ static void i915_driver_register(struct drm_i915_private
> *dev_priv)
>
> intel_gt_driver_register(to_gt(dev_priv));
>
> + i915_hwmon_register(dev_priv);
> +
> intel_display_driver_register(dev_priv);
>
> intel_power_domains_enable(dev_priv);
> @@ -728,6 +731,8 @@ static void i915_driver_unregister(struct
> drm_i915_private *dev_priv)
>
> intel_display_driver_unregister(dev_priv);
>
> + i915_hwmon_unregister(dev_priv);
> +
> intel_gt_driver_unregister(to_gt(dev_priv));
>
> i915_perf_unregister(dev_priv);
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c5fc402d9c50..e16bedba2d84 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -769,6 +769,8 @@ struct drm_i915_private {
>
> struct i915_perf perf;
>
> + struct i915_hwmon *hwmon;
> +
That should need a forward declaration.
> /* Abstract the submission mechanism (legacy ringbuffer or execlists)
> away */
> struct intel_gt gt0;
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> new file mode 100644
> index ..b94c11f2517f
> --- /dev/null
> +++
Re: [Intel-gfx] [PATCH v1 2/2] drm/i915: Reject the atomic modeset if an associated Type-C port is disconnected
On Fri, May 20, 2022 at 10:28:31AM +0300, Kasireddy, Vivek wrote: > Hi Imre, > [...] > > > > > @@ -131,6 +137,20 @@ int intel_digital_connector_atomic_check(struct > > > > > drm_connector *conn, > > > > > > > > > > crtc_state = drm_atomic_get_new_crtc_state(state, > > > > > new_state->crtc); > > > > > > > > > > + /* > > > > > + * The spec says that it is not safe to use a disconnected > > > > > Type-C port. > > > > > + * Therefore, check to see if this connector is connected and > > > > > reject > > > > > + * the modeset if there is no sink detected. > > > > > + */ > > > > > + if (dig_port && !dig_port->connected(encoder) && > > > > > > > > This check is racy, as right after dig_port->connected() returns true, > > > > the port can become disconnected. > > > > > > [Kasireddy, Vivek] Given that, do you think the only way to reliably > > > determine > > > if the Type-C port has a sink is to check the live status and ignore > > > dig_port->tc_mode? > > > > > > If that is the case, should I just add a function pointer to dig_port to > > > call > > > tc_port_live_status_mask()? Or, should I just change > > > intel_tc_port_connected() > > > to ignore dig_port->tc_mode like below: > > > @@ -764,8 +764,7 @@ bool intel_tc_port_connected(struct intel_encoder > > > *encoder) > > > > > > intel_tc_port_lock(dig_port); > > > > > > - is_connected = tc_port_live_status_mask(dig_port) & > > > - BIT(dig_port->tc_mode); > > > + is_connected = tc_port_live_status_mask(dig_port); > > > > > > Or, are there any other elegant ways that you can think of to determine > > > whether > > > a tc port has a sink or not? > > > > I meant that I don't think there is a way to prevent a modeset on a > > disconnected port. > > But we need to find a way right given that the spec clearly states that the > driver > must not use or access (PHY/FIA registers of) a disconnected tc port. The driver does not access the PHY/FIA regs on a disconnected port/PHY. > > Live status is what provides the connected state, but > > it can change right after it is read out. > > Does this change happen after giving up the ownership (in > icl_tc_phy_disconnect)? The HPD live status changes whenever a user plugs/unplugs a sink. > But shouldn't we distinguish between the cases where we are > deliberately disconnecting the phy for power-savings reason vs when > the port actually becomes disconnected? The port can still be > considered connected in the former case right? The driver - based on the spec - needs to avoid accessing the PHY/FIA regs whenever the PHY is disconnected either by FW/HW (because the user unplugged the sink) or the driver (during the suspend, modeset disable sequence). > Under what other situations would the live status change or become > unreliable after the port has a connected sink? It's not unreliable, it reflects the state of a sink being plugged to the connector or not. > And, since we rely on SDEISR to detect the live status for tc legacy > ports, could this not be considered reliable? Changes in the HPD live status is used as a hint to user space to follow up with connector detection and modeset enable/disable requests as necessary. --Imre
[Intel-gfx] [PATCH 2/3] drm/i915/hwmon: Add HWMON energy support
From: Dale B Stimson
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display energy utilization
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 16 ++
drivers/gpu/drm/i915/i915_hwmon.c | 155 +-
drivers/gpu/drm/i915/i915_hwmon.h | 11 ++
drivers/gpu/drm/i915/intel_mchbar_regs.h | 2 +
4 files changed, 183 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index c680dd842358..7574421c326f 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -1,3 +1,19 @@
+What: /sys/devices/.../hwmon/hwmon/energy1_input
+Date: June 2021
+KernelVersion: 5.14
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Energy input of device in microjoules.
+
+ The returned textual representation is an unsigned integer
+ number that can be stored in 64-bits. Warning: The hardware
+ register is 32-bits wide and can overflow by wrapping around.
+ A single wrap-around between calls to read this value can
+ be detected and will be accounted for in the returned value.
+ At a power consumption of 1 watt, the 32-bit hardware register
+ would wrap-around approximately every 3 days.
+
+ Only supported for particular Intel i915 graphics platforms.
+
What: /sys/devices/.../hwmon/hwmon/power1_max
Date: June 2021
KernelVersion: 5.14
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index b94c11f2517f..b35c4de73f30 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -18,8 +18,10 @@
/*
* SF_* - scale factors for particular quantities according to hwmon spec.
* - power - microwatts
+ * - energy - microjoules
*/
#define SF_POWER 100
+#define SF_ENERGY 100
#define FIELD_SHIFT(__mask)\
(BUILD_BUG_ON_ZERO(!__builtin_constant_p(__mask)) + \
@@ -94,6 +96,136 @@ _field_scale_and_write(struct i915_hwmon_drvdata *ddat,
i915_reg_t rgadr,
bits_to_clear, bits_to_set);
}
+/*
+ * _i915_energy1_input_sub - A custom function to obtain energy1_input.
+ * Use a custom function instead of the usual hwmon helpers in order to
+ * guarantee 64-bits of result to user-space.
+ * Units are microjoules.
+ *
+ * The underlying hardware register is 32-bits and is subject to overflow.
+ * This function compensates for overflow of the 32-bit register by detecting
+ * wrap-around and incrementing an overflow counter.
+ * This only works if the register is sampled often enough to avoid
+ * missing an instance of overflow - achieved either by repeated
+ * queries through the API, or via a possible timer (future - TBD) that
+ * ensures values are read often enough to catch all overflows.
+ *
+ * How long before overflow? For example, with an example scaling bit
+ * shift of 14 bits (see register *PACKAGE_POWER_SKU_UNIT) and a power draw of
+ * 1000 watts, the 32-bit counter will overflow in approximately 4.36 minutes.
+ *
+ * Examples:
+ *1 watt: (2^32 >> 14) /1 W / (60 * 60 * 24) secs/day -> 3 days
+ * 1000 watts: (2^32 >> 14) / 1000 W / 60 secs/min -> 4.36 minutes
+ */
+static int
+_i915_energy1_input_sub(struct i915_hwmon_drvdata *ddat, u64 *energy)
+{
+ struct intel_uncore *uncore = ddat->dd_uncore;
+ struct i915_hwmon *hwmon = ddat->dd_hwmon;
+ struct i915_energy_info *pei = >dd_ei;
+ int nshift = hwmon->scl_shift_energy;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+ u64 vlo;
+ u64 vhi;
+ i915_reg_t rgaddr;
+
+ rgaddr = hwmon->rg.energy_status_all;
+
+ if (!i915_mmio_reg_valid(rgaddr))
+ return -EOPNOTSUPP;
+
+ mutex_lock(>hwmon_lock);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(uncore, rgaddr);
+
+ /*
+* The u32 register concatenated with the u32 overflow counter
+* gives an effective energy counter size of 64-bits. However, the
+* computations below are done modulo 2^96 to avoid overflow during
+* scaling in the conversion to microjoules.
+*
+* The low-order 64-bits of the resulting quantity are returned to
+* the caller in units of microjoules, encoded into a decimal string.
+*
+* For a power of 1000 watts, 64 bits in units of microjoules will
+* overflow after 584 years.
+*/
+
+ if (pei->energy_counter_prev > reg_value)
+ pei->energy_counter_overflow++;
+
+
[Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Add HWMON current voltage support
From: Riana Tauro
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display current voltage
Cc: Anshuman Gupta
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 8 +++
drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 ++
drivers/gpu/drm/i915/i915_hwmon.c | 57 +++
drivers/gpu/drm/i915/i915_hwmon.h | 1 +
4 files changed, 70 insertions(+)
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
index 7574421c326f..c70e06dd0333 100644
--- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -33,3 +33,11 @@ Contact: dri-de...@lists.freedesktop.org
Description: RO. Card default power limit (default TDP setting).
Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/in0_input
+Date: May 2022
+KernelVersion: 5.18
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Current Voltage in millivolt.
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 7246eb870c7e..0adeca083de1 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1475,6 +1475,10 @@
#define GEN6_GT_GFX_RC6p _MMIO(0x13810c)
#define GEN6_GT_GFX_RC6pp _MMIO(0x138110)
#define VLV_RENDER_C0_COUNT_MMIO(0x138118)
+
+#define GEN12_RPSTAT1 _MMIO(0x1381b4)
+#define GEN12_VOLTAGE_MASK REG_GENMASK(10, 0)
+
#define VLV_MEDIA_C0_COUNT _MMIO(0x13811c)
#define GEN11_GT_INTR_DW(x)_MMIO(0x190018 + ((x) * 4))
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index b35c4de73f30..e5f4293a8fdb 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -12,6 +12,7 @@
#include
#include "i915_drv.h"
+#include "gt/intel_gt_regs.h"
#include "i915_hwmon.h"
#include "intel_mchbar_regs.h"
@@ -301,8 +302,23 @@ static const struct hwmon_channel_info i915_power = {
.config = i915_config_power,
};
+/*
+ * HWMON SENSOR TYPE = hwmon_in
+ * - Voltage Input value (in0_input)
+ */
+static const u32 i915_config_in[] = {
+ HWMON_I_INPUT,
+ 0
+};
+
+static const struct hwmon_channel_info i915_in = {
+ .type = hwmon_in,
+ .config = i915_config_in,
+};
+
static const struct hwmon_channel_info *i915_info[] = {
_power,
+ _in,
NULL
};
@@ -370,6 +386,41 @@ i915_power_write(struct i915_hwmon_drvdata *ddat, u32
attr, int chan, long val)
return ret;
}
+static umode_t
+i915_in_is_visible(const struct i915_hwmon_drvdata *ddat, u32 attr)
+{
+ struct drm_i915_private *i915 = ddat->dd_uncore->i915;
+
+ switch (attr) {
+ case hwmon_in_input:
+ return (IS_DG1(i915) || IS_DG2(i915)) ? 0444 : 0;
+ default:
+ return 0;
+ }
+
+ return 0444;
+}
+
+static int
+i915_in_read(struct i915_hwmon_drvdata *ddat, u32 attr, long *val)
+{
+ struct i915_hwmon *hwmon = ddat->dd_hwmon;
+ intel_wakeref_t wakeref;
+ u32 reg_value;
+
+ switch (attr) {
+ case hwmon_in_input:
+ with_intel_runtime_pm(ddat->dd_uncore->rpm, wakeref)
+ reg_value = intel_uncore_read(ddat->dd_uncore,
hwmon->rg.gt_perf_status);
+ *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK,
reg_value) * 25, 10);
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ return 0;
+}
+
static umode_t
i915_is_visible(const void *drvdata, enum hwmon_sensor_types type,
u32 attr, int channel)
@@ -379,6 +430,8 @@ i915_is_visible(const void *drvdata, enum
hwmon_sensor_types type,
switch (type) {
case hwmon_power:
return i915_power_is_visible(ddat, attr, channel);
+ case hwmon_in:
+ return i915_in_is_visible(ddat, attr);
default:
return 0;
}
@@ -393,6 +446,8 @@ i915_read(struct device *dev, enum hwmon_sensor_types type,
u32 attr,
switch (type) {
case hwmon_power:
return i915_power_read(ddat, attr, channel, val);
+ case hwmon_in:
+ return i915_in_read(ddat, attr, val);
default:
return -EOPNOTSUPP;
}
@@ -440,12 +495,14 @@ i915_hwmon_get_preregistration_info(struct
drm_i915_private *i915)
hwmon->rg.pkg_rapl_limit = PCU_PACKAGE_RAPL_LIMIT;
hwmon->rg.energy_status_all = PCU_PACKAGE_ENERGY_STATUS;
[Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Add HWMON power sensor support
From: Dale B Stimson
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
Signed-off-by: Badal Nilawar
---
.../ABI/testing/sysfs-driver-intel-i915-hwmon | 19 +
drivers/gpu/drm/i915/Kconfig | 1 +
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/i915_driver.c| 5 +
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_hwmon.c | 410 ++
drivers/gpu/drm/i915/i915_hwmon.h | 44 ++
drivers/gpu/drm/i915/i915_reg.h | 15 +
drivers/gpu/drm/i915/intel_mchbar_regs.h | 9 +
9 files changed, 506 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c
create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h
diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
new file mode 100644
index ..c680dd842358
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
@@ -0,0 +1,19 @@
+What: /sys/devices/.../hwmon/hwmon/power1_max
+Date: June 2021
+KernelVersion: 5.14
+Contact: dri-de...@lists.freedesktop.org
+Description: RW. Card reactive sustained (PL1/Tau) power limit in
microwatts.
+
+ The power controller will throttle the operating frequency
+ if the power averaged over a window (typically seconds)
+ exceeds this limit.
+
+ Only supported for particular Intel i915 graphics platforms.
+
+What: /sys/devices/.../hwmon/hwmon/power1_max_default
+Date: June 2021
+KernelVersion: 5.14
+Contact: dri-de...@lists.freedesktop.org
+Description: RO. Card default power limit (default TDP setting).
+
+ Only supported for particular Intel i915 graphics platforms.
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 7ae3b7d67fcf..c60cfacd4c47 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -19,6 +19,7 @@ config DRM_I915
select DRM_MIPI_DSI
select RELAY
select IRQ_WORK
+ select HWMON
# i915 depends on ACPI_VIDEO when ACPI is enabled
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_CLASS_DEVICE if ACPI
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index d2b18f03a33c..e1d5912ea879 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -36,6 +36,7 @@ i915-y += i915_driver.o \
i915_drm_client.o \
i915_config.o \
i915_getparam.o \
+ i915_hwmon.o \
i915_ioctl.o \
i915_irq.o \
i915_mitigations.o \
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index b47746152d97..6f678587a771 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -80,6 +80,7 @@
#include "i915_drm_client.h"
#include "i915_drv.h"
#include "i915_getparam.h"
+#include "i915_hwmon.h"
#include "i915_ioc32.h"
#include "i915_ioctl.h"
#include "i915_irq.h"
@@ -702,6 +703,8 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
intel_gt_driver_register(to_gt(dev_priv));
+ i915_hwmon_register(dev_priv);
+
intel_display_driver_register(dev_priv);
intel_power_domains_enable(dev_priv);
@@ -728,6 +731,8 @@ static void i915_driver_unregister(struct drm_i915_private
*dev_priv)
intel_display_driver_unregister(dev_priv);
+ i915_hwmon_unregister(dev_priv);
+
intel_gt_driver_unregister(to_gt(dev_priv));
i915_perf_unregister(dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c5fc402d9c50..e16bedba2d84 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -769,6 +769,8 @@ struct drm_i915_private {
struct i915_perf perf;
+ struct i915_hwmon *hwmon;
+
/* Abstract the submission mechanism (legacy ringbuffer or execlists)
away */
struct intel_gt gt0;
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
new file mode 100644
index ..b94c11f2517f
--- /dev/null
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -0,0 +1,410 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2020 Intel Corporation
+ */
+
+/*
+ * Power-related hwmon entries.
+ */
+
+#include
+#include
+#include
+
+#include "i915_drv.h"
+#include "i915_hwmon.h"
+#include "intel_mchbar_regs.h"
+
+/*
+ * SF_* - scale factors for particular quantities according to hwmon spec.
+ * - power - microwatts
+ */
+#define SF_POWER 100
+
+#define
[Intel-gfx] [PATCH 0/3] drm/i915: Add HWMON support
This series adds the HWMON support for DG1, DG2 Dale B Stimson (2): drm/i915/hwmon: Add HWMON power sensor support drm/i915/hwmon: Add HWMON energy support Riana Tauro (1): drm/i915/hwmon: Add HWMON current voltage support .../ABI/testing/sysfs-driver-intel-i915-hwmon | 43 ++ drivers/gpu/drm/i915/Kconfig | 1 + drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 4 + drivers/gpu/drm/i915/i915_driver.c| 5 + drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_hwmon.c | 620 ++ drivers/gpu/drm/i915/i915_hwmon.h | 56 ++ drivers/gpu/drm/i915/i915_reg.h | 15 + drivers/gpu/drm/i915/intel_mchbar_regs.h | 11 + 10 files changed, 758 insertions(+) create mode 100644 Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon create mode 100644 drivers/gpu/drm/i915/i915_hwmon.c create mode 100644 drivers/gpu/drm/i915/i915_hwmon.h -- 2.25.1
Re: [Intel-gfx] [PATCH] drm/i915: Rename block_size()/block_offset()
On Thu, 19 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Give block_size()/block_offset() a "raw_" prefix since they
> both operate on the "raw" (as in not duplicated) BDB block
> contents.
>
> What actually spurred this was a conflict between intel_bios.c
> block_size() vs. block_size() from blkdev.h. That only
> happend to me on a custom tree where we somehow manage to
> include blkdev.h into intel_bios.c. But I think the rename
> makes sense anyway to clarify the purpose of these functions.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index 0c5638f5b72b..3ac1860a0b6e 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -123,7 +123,7 @@ find_raw_section(const void *_bdb, enum bdb_block_id
> section_id)
> * Offset from the start of BDB to the start of the
> * block data (just past the block header).
> */
> -static u32 block_offset(const void *bdb, enum bdb_block_id section_id)
> +static u32 raw_block_offset(const void *bdb, enum bdb_block_id section_id)
> {
> const void *block;
>
> @@ -135,7 +135,7 @@ static u32 block_offset(const void *bdb, enum
> bdb_block_id section_id)
> }
>
> /* size of the block excluding the header */
> -static u32 block_size(const void *bdb, enum bdb_block_id section_id)
> +static u32 raw_block_size(const void *bdb, enum bdb_block_id section_id)
> {
> const void *block;
>
> @@ -232,7 +232,7 @@ static bool validate_lfp_data_ptrs(const void *bdb,
> int data_block_size, lfp_data_size;
> int i;
>
> - data_block_size = block_size(bdb, BDB_LVDS_LFP_DATA);
> + data_block_size = raw_block_size(bdb, BDB_LVDS_LFP_DATA);
> if (data_block_size == 0)
> return false;
>
> @@ -309,7 +309,7 @@ static bool fixup_lfp_data_ptrs(const void *bdb, void
> *ptrs_block)
> u32 offset;
> int i;
>
> - offset = block_offset(bdb, BDB_LVDS_LFP_DATA);
> + offset = raw_block_offset(bdb, BDB_LVDS_LFP_DATA);
>
> for (i = 0; i < 16; i++) {
> if (ptrs->ptr[i].fp_timing.offset < offset ||
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v6 0/7] drm/i915: Media freq factor and per-gt enhancements/fixes
On 13/05/2022 02:36, Ashutosh Dixit wrote: Some recent Intel dGfx platforms allow media IP to work at a different frequency from the base GT. This patch series exposes sysfs controls for this functionality in the new per-gt sysfs. Some enhancements and fixes to previous per-gt functionality are also included to complete the new functionality: * Patches 1 and 2 implement basic sysfs controls for media freq * Patch 3 extends previous pcode functions for multiple gt's * Patch 4 inits pcode on different gt's * Patch 5 adds a couple of pcode helpers * Patch 6 uses the new pcode functions to retrieve media RP0/RPn freq * Patch 7 fixes memory leaks in the previous per-gt sysfs implementation and some code refactoring Patches 1, 3 and 5 have been merged to drm-intel-next, and then branch cross-merged into drm-intel-gt-next. You can try re-sending the rest of the series now and see if that goes smoothly. Regards, Tvrtko IGT tests for this new functionality have also been posted at: https://patchwork.freedesktop.org/series/103175/ Test-with: 20220513011500.73460-1-ashutosh.di...@intel.com v2: Fixed commit author on patches 5 and 6 (Rodrigo) Added new patch 4 v3: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo) v4: Retain previous pcode function names to eliminate needless #defines (Rodrigo) v5: Add new patch 4 and remove last two patches in the v4 series which will be submitted later. Other mostly minor fixes from code review v6: Identical to v5, only update "Test-with:" since CI did not pick up previous "Test-with:" probably because it was old Cc: Tvrtko Ursulin Cc: Andi Shyti Cc: Jani Nikula Ashutosh Dixit (5): drm/i915: Introduce has_media_ratio_mode drm/i915/gt: Add media freq factor to per-gt sysfs drm/i915/pcode: Extend pcode functions for multiple gt's drm/i915/pcode: Init pcode on different gt's drm/i915/gt: Fix memory leaks in per-gt sysfs Dale B Stimson (2): drm/i915/pcode: Add a couple of pcode helpers drm/i915/gt: Add media RP0/RPn to per-gt sysfs drivers/gpu/drm/i915/display/hsw_ips.c| 4 +- drivers/gpu/drm/i915/display/intel_bw.c | 6 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 16 +- .../drm/i915/display/intel_display_power.c| 2 +- .../i915/display/intel_display_power_well.c | 4 +- drivers/gpu/drm/i915/display/intel_hdcp.c | 2 +- drivers/gpu/drm/i915/gt/intel_gt.c| 1 + drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 4 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 29 ++- drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 6 +- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 177 ++ drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 + drivers/gpu/drm/i915/gt/intel_llc.c | 3 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +- drivers/gpu/drm/i915/gt/intel_rps.c | 4 +- drivers/gpu/drm/i915/gt/selftest_llc.c| 2 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 2 +- .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 6 + drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 20 ++ drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.h | 1 + .../gpu/drm/i915/gt/uc/intel_guc_slpc_types.h | 3 + drivers/gpu/drm/i915/i915_driver.c| 20 +- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_pci.c | 2 + drivers/gpu/drm/i915/i915_reg.h | 11 ++ drivers/gpu/drm/i915/i915_sysfs.c | 2 + drivers/gpu/drm/i915/intel_device_info.h | 1 + drivers/gpu/drm/i915/intel_dram.c | 2 +- drivers/gpu/drm/i915/intel_pcode.c| 93 + drivers/gpu/drm/i915/intel_pcode.h| 20 +- drivers/gpu/drm/i915/intel_pm.c | 10 +- 32 files changed, 363 insertions(+), 100 deletions(-)
Re: [Intel-gfx] [CI 0/3] Expose max and current bpc via debugfs
On Thu, 19 May 2022, Bhanuprakash Modem wrote: > This series will expose the Connector's max supported bpc via connector > debugfs and Crtc's current bpc via crtc debugfs. Also move the existing > vendor specific "output_bpc" logic to drm. Pushed the series to drm-misc-next, thanks for that patches, reviews and acks. BR, Jani. > > Bhanuprakash Modem (3): > drm/debug: Expose connector's max supported bpc via debugfs > drm/i915/display/debug: Expose crtc current bpc via debugfs > drm/amd/display: Move connector debugfs to drm > > .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 -- > .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 38 +++ > .../amd/display/amdgpu_dm/amdgpu_dm_debugfs.h | 2 - > drivers/gpu/drm/drm_debugfs.c | 21 ++ > .../drm/i915/display/intel_display_debugfs.c | 28 ++ > 5 files changed, 62 insertions(+), 31 deletions(-) > > -- > 2.35.1 > -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PULL] drm-intel-next -> drm-intel-gt-next cross-merge sync
On 20/05/2022 12:02, Jani Nikula wrote:
Hi all,
This is for Tvrtko to pull to cross-merge sync drm-intel-next to
drm-intel-gt-next.
Dave, Daniel, IIUC this is what you prefer over having topic branches
for all the small things that are needed between drm-intel branches. I
don't think we've done this direct cross-merge before, so decided to
send a pull request for transparency. Do you want us to do it this way
going forward, or can we just do direct merges in git branches without
tagged pull requests?
Looks like drm-intel-next is ahead wrt backmerges too, so this pulls in
some drm-next to drm-intel-gt-next too.
Pulled, thanks Jani for explaining the situation in detail.
Regards,
Tvrtko
BR,
Jani.
PS. For future reference, generated using:
$ dim pull-request drm-intel-next drm-intel/drm-intel-gt-next
The following changes since commit c54b39a565227538c52ead2349eb17d54aadd6f7:
Merge tag 'drm-intel-next-2022-04-13-1' of
git://anongit.freedesktop.org/drm/drm-intel into drm-next (2022-04-14 12:03:09
+1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2022-05-20
for you to fetch changes up to 5f38c3fb55ce3814b4353320d7a205068a420e48:
drm/i915/pcode: Add a couple of pcode helpers (2022-05-20 09:11:45 +0100)
drm/i915 drm-intel-next -> drm-intel-gt-next cross-merge sync
Anshuman Gupta (1):
drm/i915: Use drm_dbg for rpm logging
Anusha Srivatsa (2):
drm/i915/dmc: Load DMC on DG2
drm/i915/dmc: Add MMIO range restrictions
Arunpravin Paneer Selvam (2):
drm/amdgpu: add drm buddy support to amdgpu
drm: add a check to verify the size alignment
Ashutosh Dixit (2):
drm/i915: Introduce has_media_ratio_mode
drm/i915/pcode: Extend pcode functions for multiple gt's
Biju Das (1):
drm: bridge: adv7511: Enable DRM_BRIDGE_OP_HPD based on HPD interrupt
Changcheng Deng (1):
fbcon: use min() to make code cleaner
Chen-Yu Tsai (4):
dt-bindings: vendor-prefixes: Add prefix for SINO WEALTH Eletronics Ltd.
dt-bindings: display: ssd1307fb: Add entry for SINO WEALTH SH1106
drm/ssd130x: Support page addressing mode
drm/ssd130x: Add support for SINO WEALTH SH1106
Christian König (16):
dma-buf: add enum dma_resv_usage v4
dma-buf: specify usage while adding fences to dma_resv obj v7
dma-buf & drm/amdgpu: remove dma_resv workaround
dma-buf: add DMA_RESV_USAGE_KERNEL v3
drm/amdgpu: use DMA_RESV_USAGE_KERNEL
drm/radeon: use DMA_RESV_USAGE_KERNEL
RDMA: use DMA_RESV_USAGE_KERNEL
dma-buf: add DMA_RESV_USAGE_BOOKKEEP v3
dma-buf: wait for map to complete for static attachments
drm/i915: drop bo->moving dependency
drm/ttm: remove bo->moving
dma-buf: drop seq count based update
seqlock: drop seqcount_ww_mutex_t
futex: add missing rtmutex.h include
drm/ttm: fix logic inversion in ttm_eu_reserve_buffers
drm/ttm: fix kerneldoc for ttm_lru_bulk_move
Christoph Hellwig (27):
drm/i915/gvt: remove module refcounting in
intel_gvt_{,un}register_hypervisor
drm/i915/gvt: remove enum hypervisor_type
drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
drm/i915/gvt: move the gvt code into kvmgt.ko
drm/i915/gvt: remove intel_gvt_ops
drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
drm/i915/gvt: remove the unused from_virt_to_mfn op
drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
drm/i915/gvt: merge struct kvmgt_guest_info into strut intel_vgpu
drm/i915/gvt: remove vgpu->handle
drm/i915/gvt: devirtualize ->{read,write}_gpa
drm/i915/gvt: devirtualize ->{get,put}_vfio_device
drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
drm/i915/gvt: devirtualize ->detach_vgpu
drm/i915/gvt: devirtualize ->inject_msi
drm/i915/gvt: devirtualize ->is_valid_gfn
drm/i915/gvt: devirtualize ->gfn_to_mfn
drm/i915/gvt: devirtualize ->{enable,disable}_page_track
drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
drm/i915/gvt: devirtualize dma_pin_guest_page
drm/i915/gvt: remove struct intel_gvt_mpt
drm/i915/gvt: remove the extra vfio_device refcounting for dmabufs
drm/i915/gvt: streamline intel_vgpu_create
drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write helpers
drm/i915/gvt: remove kvmgt_guest_{init,exit}
drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
drm/i915/gvt: merge gvt.c into kvmgvt.c
Colin Ian King (1):
drm: sti: fix spelling mistake: rejec -> rejection
Dale B Stimson (1):
drm/i915/pcode: Add a couple of pcode helpers
Daniel Vetter (18):
fbcon: delete a few unneeded forward decl
Re: [Intel-gfx] [PATCH] drm/i915: Write zero wms if we disable planes for icl+
On Mon, May 23, 2022 at 11:06:05AM +0300, Govindapillai, Vinod wrote:
> Hi Stan
>
> Pls see some comments inline..
>
> BR
> Vinod
>
> On Wed, 2022-05-18 at 13:59 +0300, Stanislav Lisovskiy wrote:
> > Otherwise we seem to get FIFO underruns. It is being disabled
> > anyway, so kind of logical to write those as zeroes, even if
> > disabling is temporary.
> >
> > Signed-off-by: Stanislav Lisovskiy
> > ---
> > .../drm/i915/display/skl_universal_plane.c| 2 +-
> > drivers/gpu/drm/i915/intel_pm.c | 46 +++
> > drivers/gpu/drm/i915/intel_pm.h | 2 +
> > 3 files changed, 49 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > index caa03324a733..c0251189c042 100644
> > --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> > @@ -633,7 +633,7 @@ icl_plane_disable_arm(struct intel_plane *plane,
> > if (icl_is_hdr_plane(dev_priv, plane_id))
> > intel_de_write_fw(dev_priv, PLANE_CUS_CTL(pipe, plane_id), 0);
> >
> > - skl_write_plane_wm(plane, crtc_state);
> > + skl_write_zero_plane_wm(plane, crtc_state);
> >
> > intel_psr2_disable_plane_sel_fetch(plane, crtc_state);
> > intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0);
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index ee0047fdc95d..2470c037bfae 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -5885,6 +5885,52 @@ void skl_write_plane_wm(struct intel_plane *plane,
> > PLANE_NV12_BUF_CFG(pipe, plane_id),
> > ddb_y);
> > }
> >
> > +void skl_write_zero_plane_wm(struct intel_plane *plane,
> > + const struct intel_crtc_state *crtc_state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> > + int level, max_level = ilk_wm_max_level(dev_priv);
> > + enum plane_id plane_id = plane->id;
> > + enum pipe pipe = plane->pipe;
> > + struct skl_pipe_wm pipe_wm;
> > + const struct skl_ddb_entry *ddb =
> > + _state->wm.skl.plane_ddb[plane_id];
> > + const struct skl_ddb_entry *ddb_y =
> > + _state->wm.skl.plane_ddb_y[plane_id];
> > +
> > + for (level = 0; level <= max_level; level++) {
> > + pipe_wm.planes[plane_id].wm[level].blocks = 0;
> > + pipe_wm.planes[plane_id].wm[level].lines = 0;
> > + }
> > +
> > + pipe_wm.planes[plane_id].trans_wm.blocks = 0;
> > + pipe_wm.planes[plane_id].trans_wm.lines = 0;
>
> What about the other members of struct skl_plane_wm - uv_wm, sagv.wm,
> sagv.trans_wm?
> Or memset to 0 to the sizeof(skl_wm_level) better?
Yes, you are right the whole structure should be zeroed. However that seems to
be enough
in practice though..well theretically whatever we are writing here, shouldn't
even
matter because we would be disabling the plane soon rightaway.
>
> > +
> > + for (level = 0; level <= max_level; level++)
> > + skl_write_wm_level(dev_priv, PLANE_WM(pipe, plane_id, level),
> > +skl_plane_wm_level(_wm, plane_id,
> > level));
> > +
> > + skl_write_wm_level(dev_priv, PLANE_WM_TRANS(pipe, plane_id),
> > +skl_plane_trans_wm(_wm, plane_id));
> > +
> > + if (HAS_HW_SAGV_WM(dev_priv)) {
> > + const struct skl_plane_wm *wm = _wm.planes[plane_id];
> > +
> > + skl_write_wm_level(dev_priv, PLANE_WM_SAGV(pipe, plane_id),
> > +>sagv.wm0);
> > + skl_write_wm_level(dev_priv, PLANE_WM_SAGV_TRANS(pipe,
> > plane_id),
> > +>sagv.trans_wm);
> > + }
> > +
> > + skl_ddb_entry_write(dev_priv,
> > + PLANE_BUF_CFG(pipe, plane_id), ddb);
>
> As the plane wm values are hardcode to 0 just before this line, these ddb
> entries might not be
> representing the accurate information anymore. Does that even matter?
It shouldn't matter at all since the plane is disabled.
>
> Or is it better if we ignore/skip zero-ing the wm values during the disable
> planes completely if it
> doesnt matter and just rely on disabling the plane bit in plane_ctl?
I now tend to do the same. Writing zeroed struct doesn't seem to be correct
option
either, otherwise this should be reflected in state as well - otherwise we are
getting
state mismatches.
I think we shouldn't even touch wms here - it doesn't make sense to update
them if we are disabling the plane anyway.
If it was enabled before - I think it should have those correct wms already,
which we are writing here(those from the state).
And once it is enabled - we should anyway write new wm values there.
I will probably send a new version, where we don't write those at all,
when plane is
Re: [Intel-gfx] [PATCH] drm/i915/dsi: fix VBT send packet port selection for ICL+
On Fri, 20 May 2022, Ville Syrjälä wrote:
> On Fri, May 20, 2022 at 12:46:00PM +0300, Jani Nikula wrote:
>> The VBT send packet port selection was never updated for ICL+ where the
>> 2nd link is on port B instead of port C as in VLV+ DSI.
>>
>> First, single link DSI needs to use the configured port instead of
>> relying on the VBT sequence block port. Remove the hard-coded port C
>> check here and make it generic. For reference, see commit f915084edc5a
>> ("drm/i915: Changes related to the sequence port no for") for the
>> original VLV specific fix.
>>
>> Second, the sequence block port number is either 0 or 1, where 1
>> indicates the 2nd link. Remove the hard-coded port C here for 2nd
>> link. (This could be a "find second set bit" on DSI ports, but just
>> check the two possible options.)
>>
>> Third, sanity check the result with a warning to avoid a NULL pointer
>> dereference.
>>
>> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5984
>> Cc: sta...@vger.kernel.org # v4.19+
>> Cc: Ville Syrjala
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_dsi_vbt.c | 33 +---
>> 1 file changed, 22 insertions(+), 11 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> index f370e9c4350d..dd24aef925f2 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dsi_vbt.c
>> @@ -125,9 +125,25 @@ struct i2c_adapter_lookup {
>> #define ICL_GPIO_DDPA_CTRLCLK_28
>> #define ICL_GPIO_DDPA_CTRLDATA_2 9
>>
>> -static enum port intel_dsi_seq_port_to_port(u8 port)
>> +static enum port intel_dsi_seq_port_to_port(struct intel_dsi *intel_dsi,
>> +u8 seq_port)
>> {
>> -return port ? PORT_C : PORT_A;
>> +/*
>> + * If single link DSI is being used on any port, the VBT sequence block
>> + * send packet apparently always has 0 for the port. Just use the port
>> + * we have configured, and ignore the sequence block port.
>> + */
>> +if (hweight8(intel_dsi->ports) == 1)
>> +return ffs(intel_dsi->ports) - 1;
>> +
>> +if (seq_port) {
>> +if (intel_dsi->ports & PORT_B)
>> +return PORT_B;
>> +else if (intel_dsi->ports & PORT_C)
>> +return PORT_C;
>> +}
>> +
>> +return PORT_A;
>
> Hmm. I guess a bit more generic way to express that could be
> to just pick the Nth set bit from intel_dsi->ports, where N==seq_port.
> Assuming seq_port is just an index. But I guess we're not really
> expecting to grow more DSI ports any time soon, so this seems
> sufficient for the current situation.
>
> Reviewed-by: Ville Syrjälä
Thanks, pushed to drm-intel-next.
BR,
Jani.
>
>> }
>>
>> static const u8 *mipi_exec_send_packet(struct intel_dsi *intel_dsi,
>> @@ -149,15 +165,10 @@ static const u8 *mipi_exec_send_packet(struct
>> intel_dsi *intel_dsi,
>>
>> seq_port = (flags >> MIPI_PORT_SHIFT) & 3;
>>
>> -/* For DSI single link on Port A & C, the seq_port value which is
>> - * parsed from Sequence Block#53 of VBT has been set to 0
>> - * Now, read/write of packets for the DSI single link on Port A and
>> - * Port C will based on the DVO port from VBT block 2.
>> - */
>> -if (intel_dsi->ports == (1 << PORT_C))
>> -port = PORT_C;
>> -else
>> -port = intel_dsi_seq_port_to_port(seq_port);
>> +port = intel_dsi_seq_port_to_port(intel_dsi, seq_port);
>> +
>> +if (drm_WARN_ON(_priv->drm, !intel_dsi->dsi_hosts[port]))
>> +goto out;
>>
>> dsi_device = intel_dsi->dsi_hosts[port]->device;
>> if (!dsi_device) {
>> --
>> 2.30.2
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Write zero wms if we disable planes for icl+
Hi Stan
Pls see some comments inline..
BR
Vinod
On Wed, 2022-05-18 at 13:59 +0300, Stanislav Lisovskiy wrote:
> Otherwise we seem to get FIFO underruns. It is being disabled
> anyway, so kind of logical to write those as zeroes, even if
> disabling is temporary.
>
> Signed-off-by: Stanislav Lisovskiy
> ---
> .../drm/i915/display/skl_universal_plane.c| 2 +-
> drivers/gpu/drm/i915/intel_pm.c | 46 +++
> drivers/gpu/drm/i915/intel_pm.h | 2 +
> 3 files changed, 49 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> index caa03324a733..c0251189c042 100644
> --- a/drivers/gpu/drm/i915/display/skl_universal_plane.c
> +++ b/drivers/gpu/drm/i915/display/skl_universal_plane.c
> @@ -633,7 +633,7 @@ icl_plane_disable_arm(struct intel_plane *plane,
> if (icl_is_hdr_plane(dev_priv, plane_id))
> intel_de_write_fw(dev_priv, PLANE_CUS_CTL(pipe, plane_id), 0);
>
> - skl_write_plane_wm(plane, crtc_state);
> + skl_write_zero_plane_wm(plane, crtc_state);
>
> intel_psr2_disable_plane_sel_fetch(plane, crtc_state);
> intel_de_write_fw(dev_priv, PLANE_CTL(pipe, plane_id), 0);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ee0047fdc95d..2470c037bfae 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -5885,6 +5885,52 @@ void skl_write_plane_wm(struct intel_plane *plane,
> PLANE_NV12_BUF_CFG(pipe, plane_id), ddb_y);
> }
>
> +void skl_write_zero_plane_wm(struct intel_plane *plane,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(plane->base.dev);
> + int level, max_level = ilk_wm_max_level(dev_priv);
> + enum plane_id plane_id = plane->id;
> + enum pipe pipe = plane->pipe;
> + struct skl_pipe_wm pipe_wm;
> + const struct skl_ddb_entry *ddb =
> + _state->wm.skl.plane_ddb[plane_id];
> + const struct skl_ddb_entry *ddb_y =
> + _state->wm.skl.plane_ddb_y[plane_id];
> +
> + for (level = 0; level <= max_level; level++) {
> + pipe_wm.planes[plane_id].wm[level].blocks = 0;
> + pipe_wm.planes[plane_id].wm[level].lines = 0;
> + }
> +
> + pipe_wm.planes[plane_id].trans_wm.blocks = 0;
> + pipe_wm.planes[plane_id].trans_wm.lines = 0;
What about the other members of struct skl_plane_wm - uv_wm, sagv.wm,
sagv.trans_wm?
Or memset to 0 to the sizeof(skl_wm_level) better?
> +
> + for (level = 0; level <= max_level; level++)
> + skl_write_wm_level(dev_priv, PLANE_WM(pipe, plane_id, level),
> +skl_plane_wm_level(_wm, plane_id,
> level));
> +
> + skl_write_wm_level(dev_priv, PLANE_WM_TRANS(pipe, plane_id),
> +skl_plane_trans_wm(_wm, plane_id));
> +
> + if (HAS_HW_SAGV_WM(dev_priv)) {
> + const struct skl_plane_wm *wm = _wm.planes[plane_id];
> +
> + skl_write_wm_level(dev_priv, PLANE_WM_SAGV(pipe, plane_id),
> +>sagv.wm0);
> + skl_write_wm_level(dev_priv, PLANE_WM_SAGV_TRANS(pipe,
> plane_id),
> +>sagv.trans_wm);
> + }
> +
> + skl_ddb_entry_write(dev_priv,
> + PLANE_BUF_CFG(pipe, plane_id), ddb);
As the plane wm values are hardcode to 0 just before this line, these ddb
entries might not be
representing the accurate information anymore. Does that even matter?
Or is it better if we ignore/skip zero-ing the wm values during the disable
planes completely if it
doesnt matter and just rely on disabling the plane bit in plane_ctl?
> +
> + if (DISPLAY_VER(dev_priv) < 11)
> + skl_ddb_entry_write(dev_priv,
> + PLANE_NV12_BUF_CFG(pipe, plane_id), ddb_y);
> +}
> +
> +
> void skl_write_cursor_wm(struct intel_plane *plane,
>const struct intel_crtc_state *crtc_state)
> {
> diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
> index 50604cf7398c..fb0ac4f143ab 100644
> --- a/drivers/gpu/drm/i915/intel_pm.h
> +++ b/drivers/gpu/drm/i915/intel_pm.h
> @@ -61,6 +61,8 @@ bool skl_wm_level_equals(const struct skl_wm_level *l1,
> bool skl_ddb_allocation_overlaps(const struct skl_ddb_entry *ddb,
>const struct skl_ddb_entry *entries,
>int num_entries, int ignore_idx);
> +void skl_write_zero_plane_wm(struct intel_plane *plane,
> + const struct intel_crtc_state *crtc_state);
> void skl_write_plane_wm(struct intel_plane *plane,
> const struct intel_crtc_state *crtc_state);
> void skl_write_cursor_wm(struct intel_plane *plane,
Re: [Intel-gfx] [PATCH v4 5/6] drm/i915/sseu: Disassociate internal subslice mask representation from uapi
On 21/05/2022 00:04, Matt Roper wrote:
As with EU masks, it's easier to store subslice/DSS masks internally in
a format that's more natural for the driver to work with, and then only
covert into the u8[] uapi form when the query ioctl is invoked. Since
the hardware design changed significantly with Xe_HP, we'll use a union
to choose between the old "hsw-style" subslice masks or the newer xehp
mask. HSW-style masks will be stored in an array of u8's, indexed by
slice (there's never more than 6 subslices per slice on older
platforms). For Xe_HP and beyond where slices no longer exist, we only
need a single bitmask. However we already know that this mask is
eventually going to grow too large for a simple u64 to hold, so we'll
represent it in a manner that can be operated on by the utilities in
linux/bitmap.h.
v2:
- Fix typo: BIT(s) -> BIT(ss) in gen9_sseu_device_status()
v3:
- Eliminate sseu->ss_stride and just calculate the stride while
specifically handling uapi. (Tvrtko)
- Use BITMAP_BITS() macro to refer to size of masks rather than
passing I915_MAX_SS_FUSE_BITS directly. (Tvrtko)
- Report compute/geometry DSS masks separately when dumping Xe_HP SSEU
info. (Tvrtko)
- Restore dropped range checks to intel_sseu_has_subslice(). (Tvrtko)
Cc: Tvrtko Ursulin
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 5 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 4 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 12 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 261 +++
drivers/gpu/drm/i915/gt/intel_sseu.h | 81 +++---
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 30 +--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 24 +-
drivers/gpu/drm/i915/i915_getparam.c | 3 +-
drivers/gpu/drm/i915/i915_query.c| 13 +-
9 files changed, 244 insertions(+), 189 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ab4c5ab28e4d..a3bb73f5d53b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1875,6 +1875,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
{
const struct sseu_dev_info *device = >info.sseu;
struct drm_i915_private *i915 = gt->i915;
+ unsigned int dev_subslice_mask = intel_sseu_get_hsw_subslices(device,
0);
/* No zeros in any field. */
if (!user->slice_mask || !user->subslice_mask ||
@@ -1901,7 +1902,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
if (user->slice_mask & ~device->slice_mask)
return -EINVAL;
- if (user->subslice_mask & ~device->subslice_mask[0])
+ if (user->subslice_mask & ~dev_subslice_mask)
return -EINVAL;
if (user->max_eus_per_subslice > device->max_eus_per_subslice)
@@ -1915,7 +1916,7 @@ i915_gem_user_to_context_sseu(struct intel_gt *gt,
/* Part specific restrictions. */
if (GRAPHICS_VER(i915) == 11) {
unsigned int hw_s = hweight8(device->slice_mask);
- unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
+ unsigned int hw_ss_per_s = hweight8(dev_subslice_mask);
unsigned int req_s = hweight8(context->slice_mask);
unsigned int req_ss = hweight8(context->subslice_mask);
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 1adbf34c3632..f0acf8518a51 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -674,8 +674,8 @@ static void engine_mask_apply_compute_fuses(struct intel_gt
*gt)
if (GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
return;
- ccs_mask = intel_slicemask_from_dssmask(intel_sseu_get_compute_subslices(>sseu),
- ss_per_ccs);
+ ccs_mask =
intel_slicemask_from_xehp_dssmask(info->sseu.compute_subslice_mask,
+ss_per_ccs);
/*
* If all DSS in a quadrant are fused off, the corresponding CCS
* engine is not available for use.
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 034182f85501..2921f510642f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -133,13 +133,6 @@ static const struct intel_mmio_range
dg2_lncf_steering_table[] = {
{},
};
-static u16 slicemask(struct intel_gt *gt, int count)
-{
- u64 dss_mask = intel_sseu_get_subslices(>info.sseu, 0);
-
- return intel_slicemask_from_dssmask(dss_mask, count);
-}
-
int intel_gt_init_mmio(struct intel_gt *gt)
{
struct drm_i915_private *i915 = gt->i915;
@@ -155,9 +148,12 @@ int intel_gt_init_mmio(struct intel_gt *gt)
*/
if (HAS_MSLICES(i915)) {
[Intel-gfx] [PATCH] drm/i915/hwconfig: Report no hwconfig support on ADL-N
ADL-N being a subplatform of ADL-P, it lacks support for hwconfig
table. Explicit check added to skip ADL-N.
Signed-off-by: Balasubramani Vivekanandan
---
drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
index 79c66b6b51a3..5aaa3948de74 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_hwconfig.c
@@ -94,7 +94,7 @@ static int guc_hwconfig_fill_buffer(struct intel_guc *guc,
struct intel_hwconfig
static bool has_table(struct drm_i915_private *i915)
{
- if (IS_ALDERLAKE_P(i915))
+ if (IS_ALDERLAKE_P(i915) && !IS_ADLP_N(i915))
return true;
if (IS_DG2(i915))
return true;
--
2.25.1
Re: [Intel-gfx] [RFC PATCH v3 02/19] KVM: x86: inhibit APICv/AVIC when the guest and/or host changes apic id/base from the defaults.
On Sun, 2022-05-22 at 07:47 -0700, Jim Mattson wrote:
> On Sun, May 22, 2022 at 2:03 AM Maxim Levitsky wrote:
> > On Thu, 2022-05-19 at 16:06 +, Sean Christopherson wrote:
> > > On Wed, Apr 27, 2022, Maxim Levitsky wrote:
> > > > Neither of these settings should be changed by the guest and it is
> > > > a burden to support it in the acceleration code, so just inhibit
> > > > it instead.
> > > >
> > > > Also add a boolean 'apic_id_changed' to indicate if apic id ever
> > > > changed.
> > > >
> > > > Signed-off-by: Maxim Levitsky
> > > > ---
> > > > + return;
> > > > +
> > > > + pr_warn_once("APIC ID change is unsupported by KVM");
> > >
> > > It's supported (modulo x2APIC shenanigans), otherwise KVM wouldn't need
> > > to disable
> > > APICv.
> >
> > Here, as I said, it would be nice to see that warning if someone complains.
> > Fact is that AVIC code was totally broken in this regard, and there are
> > probably more,
> > so it would be nice to see if anybody complains.
> >
> > If you insist, I'll remove this warning.
>
> This may be fine for a hobbyist, but it's a terrible API in an
> enterprise environment. To be honest, I have no way of propagating
> this warning from /var/log/messages on a particular host to a
> potentially impacted customer. Worse, if they're not the first
> impacted customer since the last host reboot, there's no warning to
> propagate. I suppose I could just tell every later customer, "Your VM
> was scheduled to run on a host that previously reported, 'APIC ID
> change is unsupported by KVM.' If you notice any unusual behavior,
> that might be the reason for it," but that isn't going to inspire
> confidence. I could schedule a drain and reboot of the host, but that
> defeats the whole point of the "_once" suffix.
Mostly agree, and I read alrady few discussions about exactly this,
those warnings are mostly useless, but they are used in the
cases where we don't have the courage to just exit with KVM_EXIT_INTERNAL_ERROR.
I do not thing though that the warning is completely useless,
as we often have the kernel log of the target machine when things go wrong,
so *we* can notice it.
In other words a kernel warning is mostly useless but better that nothing.
About KVM_EXIT_WARNING, this is IMHO a very good idea, probably combined
with some form of taint flag, which could be read by qemu and then shown
over hmp/qmp interfaces.
Best regards,
Maxim levitsky
>
> I know that there's a long history of doing this in KVM, but I'd like
> to ask that we:
> a) stop piling on
> b) start fixing the existing uses
>
> If KVM cannot emulate a perfectly valid operation, an exit to
> userspace with KVM_EXIT_INTERNAL_ERROR is warranted. Perhaps for
> operations that we suspect KVM might get wrong, we should have a new
> userspace exit: KVM_EXIT_WARNING?
>
> I'm not saying that you should remove the warning. I'm just asking
> that it be augmented with a direct signal to userspace that KVM may no
> longer be reliable.
>
