Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs
On Thu, 28 Apr 2022 07:36:14 -0700, Andrzej Hajda wrote:
> On 27.04.2022 22:46, Dixit, Ashutosh wrote:
> > On Sun, 24 Apr 2022 15:36:23 -0700, Andi Shyti wrote:
> >> Hi Andrzej and Ashutosh,
> >>
> >> b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> >> index 937b2e1a305e..4c72b4f983a6 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
> >> +++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
> >> @@ -222,6 +222,9 @@ struct intel_gt {
> >>} mocs;
> >>struct intel_pxp pxp;
> >> +
> >> + /* gt/gtN sysfs */
> >> + struct kobject sysfs_gtn;
> > If you put kobject as a part of intel_gt what assures you that lifetime
> > of
> > kobject is shorter than intel_gt? Ie its refcounter is 0 on removal of
> > intel_gt?
> Because we are explicitly doing a kobject_put() in
> intel_gt_sysfs_unregister(). Which is exactly what we are *not* doing in
> the previous code.
>
> Let me explain a bit about the previous code (but feel free to skip since
> the patch should speak for itself):
> * Previously we kzalloc a 'struct kobj_gt'
> * But we don't save a pointer to the 'struct kobj_gt' so we don't have
> the
> pointer to the kobject to be able to do a kobject_put() on it later
> * Therefore we need to store the pointer in 'struct intel_gt'
> * But if we have to put the pointer in 'struct intel_gt' we might as well
> put the kobject as part of 'struct intel_gt' and that also removes
> the
> need to have a 'struct kobj_gt' (kobj_to_gt() can just use
> container_of()
> to get gt from kobj).
> * So I think this patch simpler/cleaner than the original code if you
> take
> the requirement for kobject_put() into account.
> >> This is my oversight. This was something I completely forgot to
> >> fix but it was my intention to do and actually I had some fixes
> >> ongoing. But because this patch took too long to get in I
> >> completely forgot about it (Sujaritha was actually the first who
> >> pointed this out).
> >>
> >> Thanks, Ashutosh for taking this.
> >>
> >>> I fully agree that previous code is incorrect but I am not convinced
> >>> current
> >>> code is correct.
> >>> If some objects are kref-counted it means usually they can have multiple
> >>> concurrent users and kobject_put does not work as traditional
> >>> destructor/cleanup/unregister.
> >>> So in this particular case after calling kobject_init_and_add sysfs core
> >>> can
> >>> get multiple references on the object. Later, during driver unregistration
> >>> kobject_put is called, but if the object is still in use by sysfs core,
> >>> the
> >>> object will not be destroyed/released. If the driver unregistration
> >>> continues memory will be freed, leaving sysfs-core (or other users) with
> >>> dangling pointers. Unless there is some additional synchronization
> >>> mechanism
> >>> I am not aware of.
> >> Thanks Andrzej for summarizing this and what you said is actually
> >> what happens. I had a similar solution developed and I had wrong
> >> pointer reference happening.
> > Hi Andrzej/Andi,
> >
> > I did do some research into kobject's and such before writing this patch
> > and based on that I believe the patch is correct. Presenting some evidence
> > below.
> >
> > The patch is verified by:
> >
> > a. Putting a printk in the release() method when it exists (it does for
> > sysfs_gtn kobject)
> > b. Enabling dynamic prints for lib/kobject.c
> >
> > For example, with the following:
> >
> > # echo 'file kobject.c +p' > /sys/kernel/debug/dynamic_debug/control
> > # echo -n ":03:00.0" > /sys/bus/pci/drivers/i915/unbind
> >
> > We see this in dmesg (see kobject_cleanup() called from kobject_put()):
> >
> > [ 1034.930007] kobject: '.defaults' (88817130a640): kobject_cleanup,
> > parent 8882262b5778
> > [ 1034.930020] kobject: '.defaults' (88817130a640): auto cleanup
> > kobject_del
> > [ 1034.930336] kobject: '.defaults' (88817130a640): calling ktype
> > release
> > [ 1034.930340] kobject: (88817130a640): dynamic_kobj_release
> > [ 1034.930354] kobject: '.defaults': free name
> > [ 1034.930366] kobject: 'gt0' (8882262b5778): kobject_cleanup, parent
> > 88817130a240
> > [ 1034.930371] kobject: 'gt0' (8882262b5778): auto cleanup kobject_del
> > [ 1034.931930] kobject: 'gt0' (8882262b5778): calling ktype release
> > [ 1034.931936] kobject: 'gt0': free name
> > [ 1034.958004] kobject: 'i915__03_00.0' (88810e1f8800):
> > fill_kobj_path: path = '/devices/i915__03_00.0'
> > [ 1034.958155] kobject: 'i915__03_00.0' (88810e1f8800):
> > kobject_cleanup, parent
> > [ 1034.958162] kobject: 'i915__03_00.0' (88810e1f8800): calling
> > ktype release
> > [ 1034.958188] kobject: 'i915__03_00.0': free name
> > [ 1034.958729] kobject: 'gt' (88817130a240): kobject_cleanup, parent
Re: [Intel-gfx] [PATCH 5/9] drm/i915/pcode: Add a couple of pcode helpers
On Sun, 24 Apr 2022 15:00:24 -0700, Andi Shyti wrote: > > Hi Ashutosh, > > On Tue, Apr 19, 2022 at 11:25:05PM -0700, Ashutosh Dixit wrote: > > From: Dale B Stimson > > > > Add a couple of helpers to help formatting pcode commands and improve code > > readability. > > Can you please add some more details on the helpers? Done in v3, please take a look. > > +/* > > + * Helpers for dGfx PCODE mailbox command formatting > > + */ > > +int __intel_gt_pcode_read(struct intel_gt *gt, u32 mbcmd, u32 p1, u32 p2, > > u32 *val); > > +int __intel_gt_pcode_write(struct intel_gt *gt, u32 mbcmd, u32 p1, u32 p2, > > u32 val); > > + > > +#define __snb_pcode_read(i915, mbcmd, p1, p2, val) \ > > + __intel_gt_pcode_read(&(i915)->gt0, mbcmd, p1, p2, val) > > + > > +#define __snb_pcode_write(i915, mbcmd, p1, p2, val) \ > > + __intel_gt_pcode_write(&(i915)->gt0, mbcmd, p1, p2, val) > > to_gt(i915) > > Why do we need these defines? Looks hacky and lazy. Can't we just > replace all __snb_pcode_read/write()? You are right, I've removed the #define's in v3. Thanks. -- Ashutosh
Re: [Intel-gfx] [PATCH 3/9] drm/i915/pcode: Extend pcode functions for multiple gt's
On Sun, 24 Apr 2022 12:08:18 -0700, Andi Shyti wrote:
>
> Hi Ashutosh,
Hi Andi,
> [...]
>
> > -static bool skl_pcode_try_request(struct drm_i915_private *i915, u32 mbox,
> > - u32 request, u32 reply_mask, u32 reply,
> > - u32 *status)
> > +static bool __gt_pcode_try_request(struct intel_gt *gt, u32 mbox,
>
> why is this becoming a '__' function?
Fixed in v3.
> > int intel_pcode_init(struct drm_i915_private *i915)
> > {
> > - int ret = 0;
> > + struct intel_gt *gt;
> > + int i, ret = 0;
> >
> > if (!IS_DGFX(i915))
> > return ret;
>
> we can take some freedom, if you don't mind, and declare ret
> inside the for_each, and return 0 here. Just a small cosmetic.
Good idea, changed in v3.
> > +#define skl_pcode_request(i915, mbox, request, reply_mask, reply,
> > timeout_base_ms) \
> > + intel_gt_pcode_request(&(i915)->gt0, mbox, request, reply_mask, reply,
> > timeout_base_ms)
>
> to_gt(i915)
Not needed in v3 due to interface change to uncore.
> I guess this is just a replacement i915 to gt, I think it's all
> correct and with the latter changed:
>
> Reviewed-by: Andi Shyti
I've removed the R-b from this patch due to interface change to uncore
since it's a significant change. I have retained R-b on the following
patches since those changes are just s/gt/gt->uncore/ .
Thanks.
--
Ashutosh
Re: [Intel-gfx] [PATCH 4/9] drm/i915/gt: Convert callers to user per-gt pcode functions
On Sun, 24 Apr 2022 14:54:22 -0700, Andi Shyti wrote: > > Hi Ashutosh, > > On Tue, Apr 19, 2022 at 11:25:04PM -0700, Ashutosh Dixit wrote: > > Convert appropriate callers to use per-gt pcode functions. Callers using > > pcode functions at "global scope", including *all* display functions are > > not converted, they continue to use the legacy pcode interface. > > > > Cc: Andi Shyti > > Cc: Jani Nikula > > Cc: Rodrigo Vivi > > Signed-off-by: Ashutosh Dixit > > Reviewed-by: Andi Shyti Retaining the R-b since change in v3 is just s/gt/gt->uncore/.
Re: [Intel-gfx] [PATCH 6/9] drm/i915/gt: Add media RP0/RPn to per-gt sysfs
On Sun, 24 Apr 2022 15:05:47 -0700, Andi Shyti wrote:
>
> Hi Ashutosh,
>
> [...]
>
> > +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 = __intel_gt_pcode_read(gt, XEHPSDV_PCODE_FREQUENCY_CONFIG,
> > + PCODE_MBOX_FC_SC_READ_FUSED_P0,
> > + PCODE_MBOX_DOMAIN_MEDIAFF, );
> > +
> > + if (err)
> > + return err;
> > +
> > + /* data_out - Fused P0 for domain ID in units of 50 MHz */
>
> this comment doesn't say much, can we make it a bit clearer? The
> same for the one below.
Hopefully I've made it a bit clearer in v3.
>
> The rest looks good:
>
> Reviewed-by: Andi Shyti
Retaining the R-b, since change in v3 is just s/gt/gt->uncore/.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Media freq factor and per-gt enhancements/fixes (rev3)
== Series Details == Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev3) URL : https://patchwork.freedesktop.org/series/102665/ State : success == Summary == CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102665v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/index.html Participating hosts (43 -> 46) -- Additional (4): bat-adlm-1 fi-icl-u2 bat-dg1-6 bat-adlp-4 Missing(1): fi-bsw-cyan Known issues Here are the changes found in Patchwork_102665v3 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@smem: - bat-dg1-6: NOTRUN -> [INCOMPLETE][1] ([i915#5827]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html * igt@gem_exec_suspend@basic-s3@smem: - fi-bdw-5557u: [PASS][2] -> [INCOMPLETE][3] ([i915#146]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/fi-bdw-5557u/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-icl-u2: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/fi-icl-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/bat-adlp-4/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-icl-u2: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/fi-icl-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - bat-adlp-4: NOTRUN -> [SKIP][7] ([i915#3282]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/bat-adlp-4/igt@gem_tiled_pread_basic.html * igt@kms_chamelium@dp-crc-fast: - bat-adlp-4: NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - fi-icl-u2: NOTRUN -> [SKIP][10] ([fdo#109278]) +2 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/fi-icl-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html - bat-adlp-4: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/bat-adlp-4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_flip@basic-plain-flip@a-edp1: - bat-adlp-4: NOTRUN -> [DMESG-WARN][12] ([i915#3576]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html * igt@kms_force_connector_basic@force-load-detect: - fi-icl-u2: NOTRUN -> [SKIP][13] ([fdo#109285]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/fi-icl-u2/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-adlp-4: NOTRUN -> [SKIP][14] ([i915#4093]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/bat-adlp-4/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_setmode@basic-clone-single-crtc: - fi-icl-u2: NOTRUN -> [SKIP][15] ([i915#3555]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/fi-icl-u2/igt@kms_setm...@basic-clone-single-crtc.html - bat-adlp-4: NOTRUN -> [SKIP][16] ([i915#3555]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/bat-adlp-4/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-read: - bat-adlp-4: NOTRUN -> [SKIP][17] ([i915#3291] / [i915#3708]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/bat-adlp-4/igt@prime_v...@basic-fence-read.html * igt@prime_vgem@basic-userptr: - fi-icl-u2: NOTRUN -> [SKIP][18] ([i915#3301]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102665v3/fi-icl-u2/igt@prime_v...@basic-userptr.html - bat-adlp-4: NOTRUN -> [SKIP][19] ([i915#3301] / [i915#3708]) [19]:
Re: [Intel-gfx] linux-next: manual merge of the amdgpu tree with the drm-misc tree
Hi all,
On Wed, 13 Apr 2022 10:10:14 +1000 Stephen Rothwell
wrote:
>
> On Wed, 6 Apr 2022 10:34:05 +1000 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the amdgpu tree got a conflict in:
> >
> > drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> >
> > between commit:
> >
> > fee2ede15542 ("drm/ttm: rework bulk move handling v5")
> >
> > from the drm-misc tree and commit:
> >
> > 184a69ca4d41 ("drm/amdgpu: separate VM PT handling into amdgpu_vm_pt.c")
> >
> > from the amdgpu tree.
> >
> > I fixed it up (I used this file from the latter and added the following
> > patch) and can carry the fix as necessary. This is now fixed as far as
> > linux-next is concerned, but any non trivial conflicts should be mentioned
> > to your upstream maintainer when your tree is submitted for merging.
> > You may also want to consider cooperating with the maintainer of the
> > conflicting tree to minimise any particularly complex conflicts.
> >
> > From: Stephen Rothwell
> > Date: Wed, 6 Apr 2022 10:28:53 +1000
> > Subject: [PATCH] fix up for "drm/ttm: rework bulk move handling v5"
> >
> > Signed-off-by: Stephen Rothwell
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > index 958d7ed97882..a29933fa001f 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm_pt.c
> > @@ -630,7 +630,14 @@ static void amdgpu_vm_pt_free(struct amdgpu_vm_bo_base
> > *entry)
> >
> > if (!entry->bo)
> > return;
> > +
> > shadow = amdgpu_bo_shadowed(entry->bo);
> > + if (shadow) {
> > + ttm_bo_set_bulk_move(>tbo, NULL);
> > + amdgpu_bo_unref();
> > + }
> > +
> > + ttm_bo_set_bulk_move(>bo->tbo, NULL);
> > entry->bo->vm_bo = NULL;
> > list_del(>vm_status);
> > amdgpu_bo_unref();
> > @@ -653,8 +660,6 @@ static void amdgpu_vm_pt_free_dfs(struct amdgpu_device
> > *adev,
> > struct amdgpu_vm_pt_cursor cursor;
> > struct amdgpu_vm_bo_base *entry;
> >
> > - vm->bulk_moveable = false;
> > -
> > for_each_amdgpu_vm_pt_dfs_safe(adev, vm, start, cursor, entry)
> > amdgpu_vm_pt_free(entry);
> >
> > --
> > 2.35.1
>
> This is now a conflict between the drm tree and the amdgpu tree.
I noticed that commit 184a69ca4d41 was merged into the drm tree but
only the second hunk of this merge fixup was applied. So is the first
hunk above unnecessary?
--
Cheers,
Stephen Rothwell
pgpAnFbFYILee.pgp
Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev3)
== Series Details == Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev3) URL : https://patchwork.freedesktop.org/series/102665/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Media freq factor and per-gt enhancements/fixes (rev3)
== Series Details == Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev3) URL : https://patchwork.freedesktop.org/series/102665/ State : warning == Summary == Error: dim checkpatch failed 81e412ac8d3c drm/i915: Introduce has_media_ratio_mode 3ae6e0c36677 drm/i915/gt: Add media freq factor to per-gt sysfs cb59e532ad2f drm/i915/pcode: Extend pcode functions for multiple gt's ffa939c1df2e drm/i915/gt: Convert callers to use per-gt pcode functions eadafb081977 drm/i915/pcode: Add a couple of pcode helpers 143d0c2649d3 drm/i915/gt: Add media RP0/RPn to per-gt sysfs -:82: CHECK:CAMELCASE: Avoid CamelCase: #82: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:719: +static DEVICE_ATTR_RO(media_RPn_freq_mhz); -:88: CHECK:CAMELCASE: Avoid CamelCase: #88: FILE: drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c:725: + _attr_media_RPn_freq_mhz.attr, total: 0 errors, 0 warnings, 2 checks, 80 lines checked 00e534919070 drm/i915/gt: Fix memory leaks in per-gt sysfs d6f0646e5bbe drm/i915/gt: Expose per-gt RPS defaults in sysfs 2fcdeb9a4e8f drm/i915/gt: Expose default value for media_freq_factor in per-gt sysfs
[Intel-gfx] [PATCH 6/9] 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
Cc: Rodrigo Vivi
Cc: Joonas Lahtinen
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 2b1cd6a01724..1ec791239a65 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -12,6 +12,7 @@
#include "i915_sysfs.h"
#include "intel_gt.h"
#include "intel_gt_regs.h"
+#include "intel_pcode.h"
#include "intel_gt_sysfs.h"
#include "intel_gt_sysfs_pm.h"
#include "intel_rc6.h"
@@ -669,13 +670,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 = intel_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 = intel_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 5a4689171cc7..90a9922faffc 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6758,6 +6758,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 9/9] drm/i915/gt: Expose default value for media_freq_factor in per-gt sysfs
Add the following sysfs file to gt/gtN/.defaults:
* media_freq_factor
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 18 ++
drivers/gpu/drm/i915/gt/intel_gt_types.h| 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 2 ++
3 files changed, 21 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 bbf49613ecd0..3c84731e0eca 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -759,6 +759,18 @@ default_boost_freq_mhz_show(struct kobject *kobj, struct
kobj_attribute *attr, c
static struct kobj_attribute default_boost_freq_mhz =
__ATTR(rps_boost_freq_mhz, 0444, default_boost_freq_mhz_show, NULL);
+static ssize_t
+default_media_freq_factor_show(struct kobject *kobj, struct kobj_attribute
*attr, char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%d\n",
+
media_ratio_mode_to_factor(gt->rps_defaults.media_ratio_mode));
+}
+
+static struct kobj_attribute default_media_freq_factor =
+__ATTR(media_freq_factor, 0444, default_media_freq_factor_show, NULL);
+
static const struct attribute * const rps_defaults_attrs[] = {
_min_freq_mhz.attr,
_max_freq_mhz.attr,
@@ -819,6 +831,12 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
kobject *kobj)
drm_warn(>i915->drm,
"failed to create add gt%u
media_perf_power_attrs sysfs (%pe)\n",
gt->info.id, ERR_PTR(ret));
+
+ ret = sysfs_create_file(gt->sysfs_defaults,
_media_freq_factor.attr);
+ if (ret)
+ drm_warn(>i915->drm,
+"failed to add gt%u default_media_freq_factor
sysfs (%pe)\n",
+gt->info.id, ERR_PTR(ret));
}
ret = add_rps_defaults(gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 8b696669b846..07d368ca78ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -66,6 +66,7 @@ struct intel_rps_defaults {
u32 min_freq;
u32 max_freq;
u32 boost_freq;
+ u32 media_ratio_mode;
};
enum intel_submission_method {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
index cefd864c84eb..047c80838fcd 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c
@@ -260,7 +260,9 @@ int intel_guc_slpc_init(struct intel_guc_slpc *slpc)
slpc->boost_freq = 0;
atomic_set(>num_waiters, 0);
slpc->num_boosts = 0;
+
slpc->media_ratio_mode = SLPC_MEDIA_RATIO_MODE_DYNAMIC_CONTROL;
+ slpc_to_gt(slpc)->rps_defaults.media_ratio_mode =
slpc->media_ratio_mode;
mutex_init(>lock);
INIT_WORK(>boost_work, slpc_boost_work);
--
2.34.1
[Intel-gfx] [PATCH 8/9] drm/i915/gt: Expose per-gt RPS defaults in sysfs
Create a gt/gtN/.defaults directory (similar to
engine//.defaults) to expose default parameter values for each
gt in sysfs. Populate the .defaults directory with RPS parameter default
values in order to allow userspace to revert to default values when needed.
This patch adds the following sysfs files to gt/gtN/.defaults:
* default_min_freq_mhz
* default_max_freq_mhz
* default_boost_freq_mhz
Cc: Rodrigo Vivi
Cc: Andi Shyti
Cc: Joonas Lahtinen
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_gt_sysfs.c| 10 ++--
drivers/gpu/drm/i915/gt/intel_gt_sysfs.h| 6 +++
drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 51 +
drivers/gpu/drm/i915/gt/intel_gt_types.h| 10
drivers/gpu/drm/i915/gt/intel_rps.c | 3 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 17 +--
6 files changed, 87 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
index 9e4ebf53379b..d651ccd0ab20 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.c
@@ -22,11 +22,6 @@ bool is_object_gt(struct kobject *kobj)
return !strncmp(kobj->name, "gt", 2);
}
-static struct intel_gt *kobj_to_gt(struct kobject *kobj)
-{
- return container_of(kobj, struct intel_gt, sysfs_gt);
-}
-
struct intel_gt *intel_gt_sysfs_get_drvdata(struct device *dev,
const char *name)
{
@@ -101,6 +96,10 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
gt->i915->sysfs_gt, "gt%d", gt->info.id))
goto exit_fail;
+ gt->sysfs_defaults = kobject_create_and_add(".defaults", >sysfs_gt);
+ if (!gt->sysfs_defaults)
+ goto exit_fail;
+
intel_gt_sysfs_pm_init(gt, >sysfs_gt);
return;
@@ -113,5 +112,6 @@ void intel_gt_sysfs_register(struct intel_gt *gt)
void intel_gt_sysfs_unregister(struct intel_gt *gt)
{
+ kobject_put(gt->sysfs_defaults);
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 a99aa7e8b01a..6232923a420d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs.h
@@ -10,6 +10,7 @@
#include
#include "i915_gem.h" /* GEM_BUG_ON() */
+#include "intel_gt_types.h"
struct intel_gt;
@@ -22,6 +23,11 @@ intel_gt_create_kobj(struct intel_gt *gt,
struct kobject *dir,
const char *name);
+static inline struct intel_gt *kobj_to_gt(struct kobject *kobj)
+{
+ return container_of(kobj, struct intel_gt, sysfs_gt);
+}
+
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,
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 1ec791239a65..bbf49613ecd0 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -726,6 +726,51 @@ static const struct attribute *media_perf_power_attrs[] = {
NULL
};
+static ssize_t
+default_min_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%d\n", gt->rps_defaults.min_freq);
+}
+
+static struct kobj_attribute default_min_freq_mhz =
+__ATTR(rps_min_freq_mhz, 0444, default_min_freq_mhz_show, NULL);
+
+static ssize_t
+default_max_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%d\n", gt->rps_defaults.max_freq);
+}
+
+static struct kobj_attribute default_max_freq_mhz =
+__ATTR(rps_max_freq_mhz, 0444, default_max_freq_mhz_show, NULL);
+
+static ssize_t
+default_boost_freq_mhz_show(struct kobject *kobj, struct kobj_attribute *attr,
char *buf)
+{
+ struct intel_gt *gt = kobj_to_gt(kobj->parent);
+
+ return sysfs_emit(buf, "%d\n", gt->rps_defaults.boost_freq);
+}
+
+static struct kobj_attribute default_boost_freq_mhz =
+__ATTR(rps_boost_freq_mhz, 0444, default_boost_freq_mhz_show, NULL);
+
+static const struct attribute * const rps_defaults_attrs[] = {
+ _min_freq_mhz.attr,
+ _max_freq_mhz.attr,
+ _boost_freq_mhz.attr,
+ NULL
+};
+
+static int add_rps_defaults(struct intel_gt *gt)
+{
+ return sysfs_create_files(gt->sysfs_defaults, rps_defaults_attrs);
+}
+
static int intel_sysfs_rps_init(struct intel_gt *gt, struct kobject *kobj,
const struct attribute * const *attrs)
{
@@ -775,4 +820,10 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
kobject *kobj)
"failed to create add gt%u
media_perf_power_attrs sysfs (%pe)\n",
[Intel-gfx] [PATCH 5/9] drm/i915/pcode: Add a couple of pcode helpers
From: Dale B Stimson
Some dGfx pcode commands take additional sub-commands and parameters. Add a
couple of helpers to help formatting these commands to improve code
readability.
v2: Fixed commit author (Rodrigo)
v3: Function rename and convert to new uncore interface for pcode functions
Remove unnecessary #define's (Andi)
Cc: Andi Shyti
Cc: Rodrigo Vivi
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_reg.h| 3 +++
drivers/gpu/drm/i915/intel_pcode.c | 32 ++
drivers/gpu/drm/i915/intel_pcode.h | 6 ++
3 files changed, 41 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9ccb67eec1bd..5a4689171cc7 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6689,6 +6689,9 @@
#define GEN6_PCODE_MAILBOX _MMIO(0x138124)
#define GEN6_PCODE_READY (1 << 31)
+#define GEN6_PCODE_MB_PARAM2 REG_GENMASK(23, 16)
+#define GEN6_PCODE_MB_PARAM1 REG_GENMASK(15, 8)
+#define GEN6_PCODE_MB_COMMANDREG_GENMASK(7, 0)
#define GEN6_PCODE_ERROR_MASK0xFF
#define GEN6_PCODE_SUCCESS 0x0
#define GEN6_PCODE_ILLEGAL_CMD 0x1
diff --git a/drivers/gpu/drm/i915/intel_pcode.c
b/drivers/gpu/drm/i915/intel_pcode.c
index 66020b2e461f..f80aaf988cea 100644
--- a/drivers/gpu/drm/i915/intel_pcode.c
+++ b/drivers/gpu/drm/i915/intel_pcode.c
@@ -223,3 +223,35 @@ int intel_pcode_init(struct intel_uncore *uncore)
return ret;
}
+
+int intel_pcode_read_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32 p2,
u32 *val)
+{
+ intel_wakeref_t wakeref;
+ u32 mbox;
+ int err;
+
+ mbox = REG_FIELD_PREP(GEN6_PCODE_MB_COMMAND, mbcmd)
+ | REG_FIELD_PREP(GEN6_PCODE_MB_PARAM1, p1)
+ | REG_FIELD_PREP(GEN6_PCODE_MB_PARAM2, p2);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ err = intel_pcode_read(uncore, mbox, val, NULL);
+
+ return err;
+}
+
+int intel_pcode_write_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32
p2, u32 val)
+{
+ intel_wakeref_t wakeref;
+ u32 mbox;
+ int err;
+
+ mbox = REG_FIELD_PREP(GEN6_PCODE_MB_COMMAND, mbcmd)
+ | REG_FIELD_PREP(GEN6_PCODE_MB_PARAM1, p1)
+ | REG_FIELD_PREP(GEN6_PCODE_MB_PARAM2, p2);
+
+ with_intel_runtime_pm(uncore->rpm, wakeref)
+ err = intel_pcode_write(uncore, mbox, val);
+
+ return err;
+}
diff --git a/drivers/gpu/drm/i915/intel_pcode.h
b/drivers/gpu/drm/i915/intel_pcode.h
index a03d4ef688aa..b0f24bedef92 100644
--- a/drivers/gpu/drm/i915/intel_pcode.h
+++ b/drivers/gpu/drm/i915/intel_pcode.h
@@ -36,4 +36,10 @@ int intel_pcode_request(struct intel_uncore *uncore, u32
mbox, u32 request,
int intel_pcode_init(struct intel_uncore *uncore);
+/*
+ * Helpers for dGfx PCODE mailbox command formatting
+ */
+int intel_pcode_read_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32 p2,
u32 *val);
+int intel_pcode_write_p(struct intel_uncore *uncore, u32 mbcmd, u32 p1, u32
p2, u32 val);
+
#endif /* _INTEL_PCODE_H */
--
2.34.1
[Intel-gfx] [PATCH 4/9] drm/i915/gt: Convert callers to use per-gt pcode functions
Convert appropriate callers to use per-gt pcode functions. Callers using
pcode functions at "global scope", including *all* display functions are
not converted, they continue to use the legacy pcode interface.
v2: Convert to new uncore interface for pcode functions
Cc: Andi Shyti
Cc: Rodrigo Vivi
Signed-off-by: Ashutosh Dixit
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 6 +++---
drivers/gpu/drm/i915/gt/intel_llc.c | 9 -
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 ++--
drivers/gpu/drm/i915/gt/intel_rps.c | 6 +++---
drivers/gpu/drm/i915/gt/selftest_llc.c| 4 ++--
drivers/gpu/drm/i915/gt/selftest_rps.c| 4 ++--
6 files changed, 16 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
index 0c6b9eb724ae..025158732b8d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
@@ -138,7 +138,7 @@ static int gen6_drpc(struct seq_file *m)
}
if (GRAPHICS_VER(i915) <= 7)
- snb_pcode_read(i915, GEN6_PCODE_READ_RC6VIDS, , NULL);
+ intel_pcode_read(gt->uncore, GEN6_PCODE_READ_RC6VIDS, ,
NULL);
seq_printf(m, "RC1e Enabled: %s\n",
str_yes_no(rcctl1 & GEN6_RC_CTL_RC1e_ENABLE));
@@ -545,8 +545,8 @@ static int llc_show(struct seq_file *m, void *data)
wakeref = intel_runtime_pm_get(gt->uncore->rpm);
for (gpu_freq = min_gpu_freq; gpu_freq <= max_gpu_freq; gpu_freq++) {
ia_freq = gpu_freq;
- snb_pcode_read(i915, GEN6_PCODE_READ_MIN_FREQ_TABLE,
- _freq, NULL);
+ intel_pcode_read(gt->uncore, GEN6_PCODE_READ_MIN_FREQ_TABLE,
+_freq, NULL);
seq_printf(m, "%d\t\t%d\t\t\t\t%d\n",
intel_gpu_freq(rps,
(gpu_freq *
diff --git a/drivers/gpu/drm/i915/gt/intel_llc.c
b/drivers/gpu/drm/i915/gt/intel_llc.c
index 40e2e28ee6c7..3c70a937b86a 100644
--- a/drivers/gpu/drm/i915/gt/intel_llc.c
+++ b/drivers/gpu/drm/i915/gt/intel_llc.c
@@ -124,7 +124,6 @@ static void calc_ia_freq(struct intel_llc *llc,
static void gen6_update_ring_freq(struct intel_llc *llc)
{
- struct drm_i915_private *i915 = llc_to_gt(llc)->i915;
struct ia_constants consts;
unsigned int gpu_freq;
@@ -142,10 +141,10 @@ static void gen6_update_ring_freq(struct intel_llc *llc)
unsigned int ia_freq, ring_freq;
calc_ia_freq(llc, gpu_freq, , _freq, _freq);
- snb_pcode_write(i915, GEN6_PCODE_WRITE_MIN_FREQ_TABLE,
- ia_freq << GEN6_PCODE_FREQ_IA_RATIO_SHIFT |
- ring_freq << GEN6_PCODE_FREQ_RING_RATIO_SHIFT |
- gpu_freq);
+ intel_pcode_write(llc_to_gt(llc)->uncore,
GEN6_PCODE_WRITE_MIN_FREQ_TABLE,
+ ia_freq << GEN6_PCODE_FREQ_IA_RATIO_SHIFT |
+ ring_freq << GEN6_PCODE_FREQ_RING_RATIO_SHIFT
|
+ gpu_freq);
}
}
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index b4770690e794..c284baafa895 100644
--- a/drivers/gpu/drm/i915/gt/intel_rc6.c
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -272,7 +272,7 @@ static void gen6_rc6_enable(struct intel_rc6 *rc6)
GEN6_RC_CTL_HW_ENABLE;
rc6vids = 0;
- ret = snb_pcode_read(i915, GEN6_PCODE_READ_RC6VIDS, , NULL);
+ ret = intel_pcode_read(rc6_to_gt(rc6)->uncore, GEN6_PCODE_READ_RC6VIDS,
, NULL);
if (GRAPHICS_VER(i915) == 6 && ret) {
drm_dbg(>drm, "Couldn't check for BIOS workaround\n");
} else if (GRAPHICS_VER(i915) == 6 &&
@@ -282,7 +282,7 @@ static void gen6_rc6_enable(struct intel_rc6 *rc6)
GEN6_DECODE_RC6_VID(rc6vids & 0xff), 450);
rc6vids &= 0x00;
rc6vids |= GEN6_ENCODE_RC6_VID(450);
- ret = snb_pcode_write(i915, GEN6_PCODE_WRITE_RC6VIDS, rc6vids);
+ ret = intel_pcode_write(rc6_to_gt(rc6)->uncore,
GEN6_PCODE_WRITE_RC6VIDS, rc6vids);
if (ret)
drm_err(>drm,
"Couldn't fix incorrect rc6 voltage\n");
diff --git a/drivers/gpu/drm/i915/gt/intel_rps.c
b/drivers/gpu/drm/i915/gt/intel_rps.c
index 3476a11f294c..08aa6bf3abe2 100644
--- a/drivers/gpu/drm/i915/gt/intel_rps.c
+++ b/drivers/gpu/drm/i915/gt/intel_rps.c
@@ -1142,8 +1142,8 @@ static void gen6_rps_init(struct intel_rps *rps)
if (IS_GEN9_BC(i915) || GRAPHICS_VER(i915) >= 11)
mult = GEN9_FREQ_SCALER;
- if (snb_pcode_read(i915, HSW_PCODE_DYNAMIC_DUTY_CYCLE_CONTROL,
-
[Intel-gfx] [PATCH 7/9] 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)
Cc: Andi Shyti
Cc: Andrzej Hajda
Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs interface")
Signed-off-by: Ashutosh Dixit
---
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 07cfe66dd0e8..c992ad12d129 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -786,6 +786,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 b06611c1d4ad..edd7a3cf5f5f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -224,6 +224,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/9] drm/i915/pcode: Extend pcode functions for multiple gt's
Each gt contains an independent instance of pcode. Extend pcode functions
to interface with pcode on different gt's. To avoid creating dependency of
display functionality on intel_gt, new pcode function interfaces are
exposed in terms of uncore rather than intel_gt. Previous struct
drm_i915_private based pcode interfaces are preserved.
v2: Expose pcode functions in terms of uncore rather than gt (Jani/Rodrigo)
Cc: Rodrigo Vivi
Cc: Jani Nikula
Cc: Andi Shyti
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/gt/intel_gt.c | 17 +++
drivers/gpu/drm/i915/gt/intel_gt.h | 2 +
drivers/gpu/drm/i915/i915_driver.c | 4 +-
drivers/gpu/drm/i915/intel_pcode.c | 76 +++---
drivers/gpu/drm/i915/intel_pcode.h | 29 +---
5 files changed, 80 insertions(+), 48 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 92394f13b42f..07cfe66dd0e8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -28,6 +28,7 @@
#include "intel_rps.h"
#include "intel_gt_sysfs.h"
#include "intel_uncore.h"
+#include "intel_pcode.h"
#include "shmem_utils.h"
static void __intel_gt_init_early(struct intel_gt *gt)
@@ -1240,3 +1241,19 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
mutex_unlock(>tlb_invalidate_lock);
}
+
+int intel_gt_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;
+}
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index 44c6cb63ccbc..241d833fdb1e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -125,6 +125,8 @@ void intel_gt_watchdog_work(struct work_struct *work);
void intel_gt_invalidate_tlbs(struct intel_gt *gt);
+int intel_gt_pcode_init(struct drm_i915_private *i915);
+
struct resource intel_pci_resource(struct pci_dev *pdev, int bar);
#endif /* __INTEL_GT_H__ */
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 90b0ce5051af..518d6e357017 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -629,7 +629,7 @@ static int i915_driver_hw_probe(struct drm_i915_private
*dev_priv)
intel_opregion_setup(dev_priv);
- ret = intel_pcode_init(dev_priv);
+ ret = intel_gt_pcode_init(dev_priv);
if (ret)
goto err_msi;
@@ -1251,7 +1251,7 @@ static int i915_drm_resume(struct drm_device *dev)
disable_rpm_wakeref_asserts(_priv->runtime_pm);
- ret = intel_pcode_init(dev_priv);
+ ret = intel_gt_pcode_init(dev_priv);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/i915/intel_pcode.c
b/drivers/gpu/drm/i915/intel_pcode.c
index ac727546868e..66020b2e461f 100644
--- a/drivers/gpu/drm/i915/intel_pcode.c
+++ b/drivers/gpu/drm/i915/intel_pcode.c
@@ -52,14 +52,12 @@ static int gen7_check_mailbox_status(u32 mbox)
}
}
-static int __snb_pcode_rw(struct drm_i915_private *i915, u32 mbox,
+static int intel_pcode_rw(struct intel_uncore *uncore, u32 mbox,
u32 *val, u32 *val1,
int fast_timeout_us, int slow_timeout_ms,
bool is_read)
{
- struct intel_uncore *uncore = >uncore;
-
- lockdep_assert_held(>sb_lock);
+ lockdep_assert_held(>i915->sb_lock);
/*
* GEN6_PCODE_* are outside of the forcewake domain, we can use
@@ -88,22 +86,22 @@ static int __snb_pcode_rw(struct drm_i915_private *i915,
u32 mbox,
if (is_read && val1)
*val1 = intel_uncore_read_fw(uncore, GEN6_PCODE_DATA1);
- if (GRAPHICS_VER(i915) > 6)
+ if (GRAPHICS_VER(uncore->i915) > 6)
return gen7_check_mailbox_status(mbox);
else
return gen6_check_mailbox_status(mbox);
}
-int snb_pcode_read(struct drm_i915_private *i915, u32 mbox, u32 *val, u32
*val1)
+int intel_pcode_read(struct intel_uncore *uncore, u32 mbox, u32 *val, u32
*val1)
{
int err;
- mutex_lock(>sb_lock);
- err = __snb_pcode_rw(i915, mbox, val, val1, 500, 20, true);
- mutex_unlock(>sb_lock);
+ mutex_lock(>i915->sb_lock);
+ err = intel_pcode_rw(uncore, mbox, val, val1, 500, 20, true);
+ mutex_unlock(>i915->sb_lock);
if (err) {
- drm_dbg(>drm,
+ drm_dbg(>i915->drm,
"warning: pcode (read from mbox %x) mailbox access
failed for %ps: %d\n",
mbox, __builtin_return_address(0), err);
}
@@
[Intel-gfx] [PATCH 2/9] 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
Cc: Joonas Lahtinen
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 a39718a40cc3..8ba84c336925 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -732,6 +732,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 26cbfa6477d1..2b1cd6a01724 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
@@ -557,6 +557,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_uncore_read(gt->uncore, GEN6_RPNSWREQ);
+
[Intel-gfx] [PATCH 1/9] drm/i915: Introduce has_media_ratio_mode
Media ratio mode (the ability for media IP to work at a different frequency
from the GT) is available for a subset of dGfx platforms supporting
GuC/SLPC. Introduce 'has_media_ratio_mode' flag in intel_device_info to
identify these platforms and set it for XEHPSDV and DG2/ATS-M.
Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
Reviewed-by: Andi Shyti
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/i915_pci.c | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 1 +
3 files changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 24111bf42ce0..96625eabb244 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1227,6 +1227,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define CCS_MASK(gt) \
ENGINE_INSTANCES_MASK(gt, CCS0, I915_MAX_CCS)
+#define HAS_MEDIA_RATIO_MODE(dev_priv)
(INTEL_INFO(dev_priv)->has_media_ratio_mode)
+
/*
* The Gen7 cmdparser copies the scanned buffer to the ggtt for execution
* All later gens can run the final buffer from the ppgtt
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index b60492826478..3ea1e11cc2a7 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1033,6 +1033,7 @@ static const struct intel_device_info xehpsdv_info = {
.display = { },
.has_64k_pages = 1,
.needs_compact_pt = 1,
+ .has_media_ratio_mode = 1,
.platform_engine_mask =
BIT(RCS0) | BIT(BCS0) |
BIT(VECS0) | BIT(VECS1) | BIT(VECS2) | BIT(VECS3) |
@@ -1053,6 +1054,7 @@ static const struct intel_device_info xehpsdv_info = {
.has_guc_deprivilege = 1, \
.has_heci_pxp = 1, \
.needs_compact_pt = 1, \
+ .has_media_ratio_mode = 1, \
.platform_engine_mask = \
BIT(RCS0) | BIT(BCS0) | \
BIT(VECS0) | BIT(VECS1) | \
diff --git a/drivers/gpu/drm/i915/intel_device_info.h
b/drivers/gpu/drm/i915/intel_device_info.h
index 20c351c8d5bd..2bd67b3457f1 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -153,6 +153,7 @@ enum intel_ppgtt_type {
func(has_llc); \
func(has_logical_ring_contexts); \
func(has_logical_ring_elsq); \
+ func(has_media_ratio_mode); \
func(has_mslices); \
func(has_pooled_eu); \
func(has_pxp); \
--
2.34.1
[Intel-gfx] [PATCH v3 0/9] 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 * Patches 3 and 4 extend previous pcode functions for multiple gt's and 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 * Patch 8 creates a gt/gtN/.defaults directory to expose default RPS parameter values in the per-gt sysfs * Patch 9 adds the default value for media_freq_factor to gt/gtN/.defaults IGT tests for this new functionality have also been posted at: https://patchwork.freedesktop.org/series/103107/ Test-with: 20220426000337.9367-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) Cc: Rodrigo Vivi Cc: Joonas Lahtinen Cc: Andi Shyti Ashutosh Dixit (7): 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/gt: Convert callers to use per-gt pcode functions drm/i915/gt: Fix memory leaks in per-gt sysfs drm/i915/gt: Expose per-gt RPS defaults in sysfs drm/i915/gt: Expose default value for media_freq_factor 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/gt/intel_gt.c| 18 ++ drivers/gpu/drm/i915/gt/intel_gt.h| 2 + drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 6 +- drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_gt_sysfs.c | 35 ++- drivers/gpu/drm/i915/gt/intel_gt_sysfs.h | 12 +- drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 246 ++ drivers/gpu/drm/i915/gt/intel_gt_types.h | 14 + drivers/gpu/drm/i915/gt/intel_llc.c | 9 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +- drivers/gpu/drm/i915/gt/intel_rps.c | 9 +- drivers/gpu/drm/i915/gt/selftest_llc.c| 4 +- drivers/gpu/drm/i915/gt/selftest_rps.c| 4 +- .../drm/i915/gt/uc/abi/guc_actions_slpc_abi.h | 6 + drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 39 ++- 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| 4 +- 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_pcode.c| 108 +--- drivers/gpu/drm/i915/intel_pcode.h| 35 ++- 25 files changed, 483 insertions(+), 95 deletions(-) -- 2.34.1
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915/display: Do not schedule DRRS work thread when it is not active
== Series Details ==
Series: series starting with [1/3] drm/i915/display: Do not schedule DRRS work
thread when it is not active
URL : https://patchwork.freedesktop.org/series/103294/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103294v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103294v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@gem-idle:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-rkl-5/igt@i915_pm_...@gem-idle.html
* igt@kms_vblank@pipe-b-ts-continuation-dpms-suspend:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-dg1-18/igt@kms_vbl...@pipe-b-ts-continuation-dpms-suspend.html
Known issues
Here are the changes found in Patchwork_103294v1_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-skl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6],
[PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
[PASS][25], [PASS][26]) ([i915#5032]) -> ([PASS][27], [PASS][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35],
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41],
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47],
[PASS][48], [PASS][49], [PASS][50])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-skl9/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-skl9/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-skl9/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-skl8/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-skl8/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-skl8/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-skl8/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-skl7/boot.html
[35]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/shard-skl7/boot.html
[36]:
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/display: Do not schedule DRRS work thread when it is not active
== Series Details == Series: series starting with [1/3] drm/i915/display: Do not schedule DRRS work thread when it is not active URL : https://patchwork.freedesktop.org/series/103294/ State : success == Summary == CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103294v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/index.html Participating hosts (43 -> 44) -- Additional (3): bat-dg2-8 bat-dg1-6 bat-adlp-4 Missing(2): bat-rpls-1 fi-bsw-cyan Known issues Here are the changes found in Patchwork_103294v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s0@smem: - bat-dg1-6: NOTRUN -> [INCOMPLETE][1] ([i915#5827]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html - bat-adlp-4: NOTRUN -> [SKIP][4] ([i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/bat-adlp-4/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#3282]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/bat-adlp-4/igt@gem_tiled_pread_basic.html - fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3282]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#3012]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@kms_chamelium@dp-crc-fast: - bat-adlp-4: NOTRUN -> [SKIP][8] ([fdo#111827]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html - fi-rkl-11600: NOTRUN -> [SKIP][9] ([fdo#111827]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@kms_chamel...@dp-crc-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#4070] / [i915#4103]) +1 similar issue [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-adlp-4: NOTRUN -> [SKIP][11] ([i915#4103]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/bat-adlp-4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_flip@basic-flip-vs-modeset@a-edp1: - bat-adlp-4: NOTRUN -> [DMESG-WARN][12] ([i915#3576]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/bat-adlp-4/igt@kms_flip@basic-flip-vs-mode...@a-edp1.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][13] ([fdo#109285] / [i915#4098]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-adlp-4: NOTRUN -> [SKIP][14] ([i915#4093]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/bat-adlp-4/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#4070] / [i915#533]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html * igt@kms_psr@primary_mmap_gtt: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#1072]) +3 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@kms_psr@primary_mmap_gtt.html * igt@kms_setmode@basic-clone-single-crtc: - bat-adlp-4: NOTRUN -> [SKIP][17] ([i915#3555]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/bat-adlp-4/igt@kms_setm...@basic-clone-single-crtc.html - fi-rkl-11600: NOTRUN -> [SKIP][18] ([i915#3555] / [i915#4098]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103294v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html *
Re: [Intel-gfx] [PULL] gvt-next
On Thu, 28 Apr 2022 15:35:58 -0600
Alex Williamson wrote:
> On Tue, 26 Apr 2022 08:52:58 -0300
> Jason Gunthorpe wrote:
>
> > On Tue, Apr 26, 2022 at 08:42:25AM +, Wang, Zhi A wrote:
> > > On 4/26/22 8:37 AM, Jani Nikula wrote:
> > > > On Tue, 26 Apr 2022, "Wang, Zhi A" wrote:
> > > >> Hi folks:
> > > >>
> > > >> Here is the pull of gvt-next which fixs the compilation error when
> > > >> i915 debug
> > > >> is open after the GVT-g refactor patches.
> > > >>
> > > >> Thanks so much for the efforts.
> > > >
> > > > Pulled, thanks.
> > > >
> > > > BR,
> > > > Jani.
> > > >
> > > Thanks, looks good now. :)
> >
> > Great! Thanks everyone!
> >
> > Alex, can you pull this to VFIO now too? The top commit should be:
>
> I see a gvt-next-2022-04-29 tag adding the following fixes:
>
> 419f8299ddad i915/gvt: Fix NULL pointer dereference in
> init_mmio_block_handlers
> 5b95b9d58fb0 drm/i915/gvt: Fix the compiling error when
> CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n
> fa630c304b93 drm/i915/gvt: Make intel_gvt_match_device() static
>
> I'm expecting that's my new merge target once a pull request is
> completed for that. Please keep me cc'd. Thanks,
Oops, I see the new pull request for this tag came in while I was
writing this. I'll keep an eye for it to be merged. Thanks,
Alex
> > commit 5e9ae5c47052e28a31fb4f55a6e735c28d4c3948
> > Author: Zhi Wang
> > Date: Mon Apr 25 18:03:31 2022 -0400
> >
> > drm/i915/gvt: Add missing symbol export.
> >
> > When CONFIG_DRM_I915_DEBUG_RUNTIME and CONFIG_DRM_I915_DEBUG_PM
> > are enabled, two more extra symols in i915 are required to be
> > exported.
> >
> > Cc: Jani Nikula
> > Signed-off-by: Zhi Wang
> > Link:
> > http://patchwork.freedesktop.org/patch/msgid/20220425220331.24865-1-zhi.a.w...@intel.com
> > Reviewed-by: Jani Nikula
> >
> > Which was picked up here:
> >
> > https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next=f08699ec5bd924be4c9572e21fd0a806d3fb34c2
> >
> > It will have these commits:
> >
> > 5e9ae5c47052e2 drm/i915/gvt: Add missing symbol export.
> > 2917f53113be3b vfio/mdev: Remove mdev drvdata
> > 2aa72ec97ce9eb vfio/mdev: Use the driver core to create the 'remove' file
> > 6b42f491e17ce1 vfio/mdev: Remove mdev_parent_ops
> > e6486939d8ea22 vfio/mdev: Remove mdev_parent_ops dev_attr_groups
> > 6c7f98b334a32d vfio/mdev: Remove vfio_mdev.c
> > cba619cb0d4d66 drm/i915/gvt: merge gvt.c into kvmgvt.c
> > 978cf586ac35f3 drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
> > 0e09f4066ad11b drm/i915/gvt: remove kvmgt_guest_{init,exit}
> > 7f11e6893ff01b drm/i915/gvt: pass a struct intel_vgpu to the vfio
> > read/write helpers
> > 4456641232e2c1 drm/i915/gvt: streamline intel_vgpu_create
> > 37e4bdbd5bad71 drm/i915/gvt: remove the extra vfio_device refcounting for
> > dmabufs
> > 5f8f3fe67cd908 drm/i915/gvt: remove struct intel_gvt_mpt
> > 91879bbaf8890f drm/i915/gvt: devirtualize dma_pin_guest_page
> > 8398eee85fd009 drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
> > 4c2baaaf764bfb drm/i915/gvt: devirtualize ->{enable,disable}_page_track
> > 4050dab5981cd4 drm/i915/gvt: devirtualize ->gfn_to_mfn
> > bd73b4b193d450 drm/i915/gvt: devirtualize ->is_valid_gfn
> > b3bece34956f86 drm/i915/gvt: devirtualize ->inject_msi
> > 4c705ad0d784fd drm/i915/gvt: devirtualize ->detach_vgpu
> > f9399b0e4a9555 drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
> > fe902f0ce686e8 drm/i915/gvt: devirtualize ->{get,put}_vfio_device
> > e3d7640eeeb306 drm/i915/gvt: devirtualize ->{read,write}_gpa
> > 3c340d05868d98 drm/i915/gvt: remove vgpu->handle
> > 10ddb96295f3bd drm/i915/gvt: merge struct kvmgt_guest_info into strut
> > intel_vgpu
> > 62980cacc37f58 drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
> > 3cbac24c2cdbfe drm/i915/gvt: remove the unused from_virt_to_mfn op
> > c977092a997708 drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
> > 675e5c4a33e20c drm/i915/gvt: remove intel_gvt_ops
> > 8b750bf744181c drm/i915/gvt: move the gvt code into kvmgt.ko
> > f49fc35799fa63 drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
> > 367748066eeb37 drm/i915/gvt: remove enum hypervisor_type
> > a85749e12d66c2 drm/i915/gvt: remove module refcounting in
> > intel_gvt_{,un}register_hypervisor
> > 7f0cf30187cdb1 drm/i915/gvt: better align the Makefile with i915 Makefile
> > de5d437ae8696a drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
> > 1672991412dfef i915/gvt: Use the initial HW state snapshot saved in i915
> > 66e7a8063381cb i915/gvt: Save the initial HW state snapshot in i915
> > e0f74ed4634d6d i915/gvt: Separate the MMIO tracking table from GVT-g
> >
> > Thanks,
> > Jason
> >
>
Re: [Intel-gfx] [PULL] gvt-next
On Tue, 26 Apr 2022 08:52:58 -0300
Jason Gunthorpe wrote:
> On Tue, Apr 26, 2022 at 08:42:25AM +, Wang, Zhi A wrote:
> > On 4/26/22 8:37 AM, Jani Nikula wrote:
> > > On Tue, 26 Apr 2022, "Wang, Zhi A" wrote:
> > >> Hi folks:
> > >>
> > >> Here is the pull of gvt-next which fixs the compilation error when i915
> > >> debug
> > >> is open after the GVT-g refactor patches.
> > >>
> > >> Thanks so much for the efforts.
> > >
> > > Pulled, thanks.
> > >
> > > BR,
> > > Jani.
> > >
> > Thanks, looks good now. :)
>
> Great! Thanks everyone!
>
> Alex, can you pull this to VFIO now too? The top commit should be:
I see a gvt-next-2022-04-29 tag adding the following fixes:
419f8299ddad i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers
5b95b9d58fb0 drm/i915/gvt: Fix the compiling error when
CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n
fa630c304b93 drm/i915/gvt: Make intel_gvt_match_device() static
I'm expecting that's my new merge target once a pull request is
completed for that. Please keep me cc'd. Thanks,
Alex
> commit 5e9ae5c47052e28a31fb4f55a6e735c28d4c3948
> Author: Zhi Wang
> Date: Mon Apr 25 18:03:31 2022 -0400
>
> drm/i915/gvt: Add missing symbol export.
>
> When CONFIG_DRM_I915_DEBUG_RUNTIME and CONFIG_DRM_I915_DEBUG_PM
> are enabled, two more extra symols in i915 are required to be
> exported.
>
> Cc: Jani Nikula
> Signed-off-by: Zhi Wang
> Link:
> http://patchwork.freedesktop.org/patch/msgid/20220425220331.24865-1-zhi.a.w...@intel.com
> Reviewed-by: Jani Nikula
>
> Which was picked up here:
>
> https://cgit.freedesktop.org/drm-intel/commit/?h=drm-intel-next=f08699ec5bd924be4c9572e21fd0a806d3fb34c2
>
> It will have these commits:
>
> 5e9ae5c47052e2 drm/i915/gvt: Add missing symbol export.
> 2917f53113be3b vfio/mdev: Remove mdev drvdata
> 2aa72ec97ce9eb vfio/mdev: Use the driver core to create the 'remove' file
> 6b42f491e17ce1 vfio/mdev: Remove mdev_parent_ops
> e6486939d8ea22 vfio/mdev: Remove mdev_parent_ops dev_attr_groups
> 6c7f98b334a32d vfio/mdev: Remove vfio_mdev.c
> cba619cb0d4d66 drm/i915/gvt: merge gvt.c into kvmgvt.c
> 978cf586ac35f3 drm/i915/gvt: convert to use vfio_register_emulated_iommu_dev
> 0e09f4066ad11b drm/i915/gvt: remove kvmgt_guest_{init,exit}
> 7f11e6893ff01b drm/i915/gvt: pass a struct intel_vgpu to the vfio read/write
> helpers
> 4456641232e2c1 drm/i915/gvt: streamline intel_vgpu_create
> 37e4bdbd5bad71 drm/i915/gvt: remove the extra vfio_device refcounting for
> dmabufs
> 5f8f3fe67cd908 drm/i915/gvt: remove struct intel_gvt_mpt
> 91879bbaf8890f drm/i915/gvt: devirtualize dma_pin_guest_page
> 8398eee85fd009 drm/i915/gvt: devirtualize ->dma_{,un}map_guest_page
> 4c2baaaf764bfb drm/i915/gvt: devirtualize ->{enable,disable}_page_track
> 4050dab5981cd4 drm/i915/gvt: devirtualize ->gfn_to_mfn
> bd73b4b193d450 drm/i915/gvt: devirtualize ->is_valid_gfn
> b3bece34956f86 drm/i915/gvt: devirtualize ->inject_msi
> 4c705ad0d784fd drm/i915/gvt: devirtualize ->detach_vgpu
> f9399b0e4a9555 drm/i915/gvt: devirtualize ->set_edid and ->set_opregion
> fe902f0ce686e8 drm/i915/gvt: devirtualize ->{get,put}_vfio_device
> e3d7640eeeb306 drm/i915/gvt: devirtualize ->{read,write}_gpa
> 3c340d05868d98 drm/i915/gvt: remove vgpu->handle
> 10ddb96295f3bd drm/i915/gvt: merge struct kvmgt_guest_info into strut
> intel_vgpu
> 62980cacc37f58 drm/i915/gvt: merge struct kvmgt_vdev into struct intel_vgpu
> 3cbac24c2cdbfe drm/i915/gvt: remove the unused from_virt_to_mfn op
> c977092a997708 drm/i915/gvt: remove the map_gfn_to_mfn and set_trap_area ops
> 675e5c4a33e20c drm/i915/gvt: remove intel_gvt_ops
> 8b750bf744181c drm/i915/gvt: move the gvt code into kvmgt.ko
> f49fc35799fa63 drm/i915/gvt: rename intel_vgpu_ops to intel_vgpu_mdev_ops
> 367748066eeb37 drm/i915/gvt: remove enum hypervisor_type
> a85749e12d66c2 drm/i915/gvt: remove module refcounting in
> intel_gvt_{,un}register_hypervisor
> 7f0cf30187cdb1 drm/i915/gvt: better align the Makefile with i915 Makefile
> de5d437ae8696a drm/i915/gvt: fix trace TRACE_INCLUDE_PATH
> 1672991412dfef i915/gvt: Use the initial HW state snapshot saved in i915
> 66e7a8063381cb i915/gvt: Save the initial HW state snapshot in i915
> e0f74ed4634d6d i915/gvt: Separate the MMIO tracking table from GVT-g
>
> Thanks,
> Jason
>
[Intel-gfx] [PULL] gvt-next-2022-04-29
Hi folks: Here is the pull of gvt-next which fixes the compilation error and warnings for the the GVT-g refactor patches: - Fix a compiling warning of non-static function only having one caller. - Fix a potential NULL pointer reference in the code re-factor. - Fix a compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n I also tried to apply this pull on the latest drm-inte-next and it succeeded without error and warnings. The following changes since commit 5e9ae5c47052e28a31fb4f55a6e735c28d4c3948: drm/i915/gvt: Add missing symbol export. (2022-04-26 04:18:43 -0400) are available in the Git repository at: https://github.com/intel/gvt-linux tags/gvt-next-2022-04-29 for you to fetch changes up to 419f8299ddad6070a6c95aaedf78e50265871f36: i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers (2022-04-28 17:06:02 -0400) gvt-next-2022-04-29 Introduce fixes from previous pull. - Fix a compiling warning of non-static funtion only having one caller. - Fix a potential NULL pointer reference in the code re-factor. - Fix a compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n Wan Jiabing (1): i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers Zhi Wang (2): drm/i915/gvt: Make intel_gvt_match_device() static drm/i915/gvt: Fix the compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n drivers/gpu/drm/i915/gvt/handlers.c | 4 ++-- drivers/gpu/drm/i915/intel_gvt.c| 2 ++ 2 files changed, 4 insertions(+), 2 deletions(-)
[Intel-gfx] [PATCH 2/3] drm/i915/display: Allow DRRS to be enabled during driver load
When driver takes over display from firmware it does some checks and
if possible it tries to avoid a modeset to improve user boot
experience.
But even if DRRS is supported it was being left disabled as
intel_crtc_copy_fastset() was overwritten new state with the old one
(hardware readout).
So here checking if platform has only one set of m_n registers that
can change on the fly between high and low clock, if yes we can keep
DRRS enabled.
Cc: Vidya Srinivas
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 7 --
drivers/gpu/drm/i915/display/intel_drrs.c| 24
drivers/gpu/drm/i915/display/intel_drrs.h| 2 ++
3 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 0decf3d242372..17d0cad9e1686 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7086,8 +7086,11 @@ static void intel_crtc_copy_fastset(const struct
intel_crtc_state *old_crtc_stat
*/
new_crtc_state->fdi_m_n = old_crtc_state->fdi_m_n;
new_crtc_state->dp_m_n = old_crtc_state->dp_m_n;
- new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
- new_crtc_state->has_drrs = old_crtc_state->has_drrs;
+
+ if (!intel_drrs_crtc_copy_fastset(old_crtc_state, new_crtc_state)) {
+ new_crtc_state->dp_m2_n2 = old_crtc_state->dp_m2_n2;
+ new_crtc_state->has_drrs = old_crtc_state->has_drrs;
+ }
}
static int intel_crtc_add_planes_to_state(struct intel_atomic_state *state,
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 04bc296761be0..c6509c29e942b 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -305,3 +305,27 @@ void intel_crtc_drrs_init(struct intel_crtc *crtc)
mutex_init(>drrs.mutex);
crtc->drrs.cpu_transcoder = INVALID_TRANSCODER;
}
+
+/**
+ * intel_drrs_crtc_copy_fastset - Handles crtc state copy during fastsets when
+ * new state has DRRS.
+ * @old_crtc_state: old crtc state
+ * @new_crtc_state: new crtc state
+ *
+ * Handle crtc state copy during fastsets trying to keep DRRS enabled.
+ * That can be done in platforms that supports change the dp_m_n register on
+ * the fly between high and low clocks.
+ *
+ * Returns true if crtc copy was already handled otherwise returns false.
+ */
+bool intel_drrs_crtc_copy_fastset(const struct intel_crtc_state
*old_crtc_state,
+ struct intel_crtc_state *new_crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(old_crtc_state->uapi.crtc->dev);
+
+ /* m2_n2 register needs to already be set */
+ if (intel_cpu_transcoder_has_m2_n2(i915,
new_crtc_state->cpu_transcoder))
+ return false;
+
+ return true;
+}
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.h
b/drivers/gpu/drm/i915/display/intel_drrs.h
index 3ad1be1ad9c13..749ac717db063 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.h
+++ b/drivers/gpu/drm/i915/display/intel_drrs.h
@@ -24,5 +24,7 @@ void intel_drrs_invalidate(struct drm_i915_private *dev_priv,
void intel_drrs_flush(struct drm_i915_private *dev_priv,
unsigned int frontbuffer_bits);
void intel_crtc_drrs_init(struct intel_crtc *crtc);
+bool intel_drrs_crtc_copy_fastset(const struct intel_crtc_state
*old_crtc_state,
+ struct intel_crtc_state *new_crtc_state);
#endif /* __INTEL_DRRS_H__ */
--
2.36.0
[Intel-gfx] [PATCH 3/3] drm/i915/display: Implement seamless mode switch
So far the i915's DRRS feature was automatically changing between
preferred panel mode and downclock mode based on idleness but ChromeOS
compositor team is asking to be in control of the mode switch.
So for certain types of content it can switch to a mode with a lower
refresh rate without the user noticing a thing and saving more power.
This seamless mode switch will be triggered when user-space dispatches
an atomic commit with the new mode and clears the
DRM_MODE_ATOMIC_ALLOW_MODESET flag.
The main steps to acomplish that are:
- as mode changed in atomic state drm_atomic_helper_check_modeset()
will set mode_changed and it will trigger the crtc state computation
so intel_dp_compute_config() will be called and dp_m_n will be
computed for the new mode
- then intel_dp_drrs_compute_config() will check for the necessary
conditions to do a seamless mode switch, if possible
crtc_state->seamless_mode_switch will be set and has_drrs will not
be set, so i915 will not automatically switch between modes
- then intel_crtc_compute_config() will call
intel_crtc_compute_pixel_rate() that will take the hint that it is
trying to do a seamless mode switch and set pixel_rate to the
pixel_rate of the old state
- then if nothing else changed in the state intel_crtc_check_fastset()
will be able to set mode_changed to false and i915 can do fastset
otherwise the commit will fail during the check phase
- now on the atomic commit phase, intel_ddi_update_pipe_dp()
will be called and will program the new dp_m_n
- nothing else is different in the commit phase until the step to
verify programmed state, the most important change here is that need
to save the pixel_rate in DRRS global state as there is no other
way to get that from hardware or atomic state
Cc: Vidya Srinivas
Cc: Sean Paul
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 10
drivers/gpu/drm/i915/display/intel_display.c | 59 ---
.../drm/i915/display/intel_display_debugfs.c | 3 +
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/display/intel_dp.c | 56 +++---
drivers/gpu/drm/i915/display/intel_drrs.c | 35 ---
drivers/gpu/drm/i915/display/intel_drrs.h | 3 +
7 files changed, 147 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 9e6fa59eabba7..732e5d425412e 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -46,6 +46,7 @@
#include "intel_dp_link_training.h"
#include "intel_dp_mst.h"
#include "intel_dpio_phy.h"
+#include "intel_drrs.h"
#include "intel_dsi.h"
#include "intel_fdi.h"
#include "intel_fifo_underrun.h"
@@ -3010,6 +3011,14 @@ static void intel_ddi_update_pipe_dp(struct
intel_atomic_state *state,
intel_backlight_update(state, encoder, crtc_state, conn_state);
drm_connector_update_privacy_screen(conn_state);
+
+ if (crtc_state->seamless_mode_switch) {
+ struct intel_crtc *intel_crtc =
to_intel_crtc(crtc_state->uapi.crtc);
+
+ intel_cpu_transcoder_set_m1_n1(intel_crtc,
+ crtc_state->cpu_transcoder,
+ _state->dp_m_n);
+ }
}
void intel_ddi_update_pipe(struct intel_atomic_state *state,
@@ -3484,6 +3493,7 @@ static void intel_ddi_get_config(struct intel_encoder
*encoder,
intel_read_dp_sdp(encoder, pipe_config, DP_SDP_VSC);
intel_psr_get_config(encoder, pipe_config);
+ intel_drrs_get_config(encoder, pipe_config);
}
void intel_ddi_get_clock(struct intel_encoder *encoder,
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 17d0cad9e1686..c37501b2ab419 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -2629,6 +2629,44 @@ static void intel_crtc_compute_pixel_rate(struct
intel_crtc_state *crtc_state)
else
crtc_state->pixel_rate =
ilk_pipe_pixel_rate(crtc_state);
+
+ /*
+* Do not change pixel_rate when doing seamless mode switch, otherwise
+* it will change port_clock and other stuff that will need a modeset
+* to be programmed
+*/
+ if (crtc_state->seamless_mode_switch) {
+ struct intel_atomic_state *state =
to_intel_atomic_state(crtc_state->uapi.state);
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+ const struct intel_crtc_state *old_crtc_state;
+
+ old_crtc_state = intel_atomic_get_old_crtc_state(state, crtc);
+
+ /*
+* It can only seamless switch if pixel rate of the new mode is
+* <= than old one, if not commit will fail with pixel_rate
+* mismatch.
[Intel-gfx] [PATCH 1/3] drm/i915/display: Do not schedule DRRS work thread when it is not active
Frontbuffer updates were scheduling the execution of DRRS work thread
even if DRRS is not active.
There was no issues with it because intel_drrs_downclock_work() checks
if DRRS is active but there is no reason to keep scheduling this work
thread and wasting CPU time.
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_drrs.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_drrs.c
b/drivers/gpu/drm/i915/display/intel_drrs.c
index 166caf293f7bc..04bc296761be0 100644
--- a/drivers/gpu/drm/i915/display/intel_drrs.c
+++ b/drivers/gpu/drm/i915/display/intel_drrs.c
@@ -236,6 +236,11 @@ static void intel_drrs_frontbuffer_update(struct
drm_i915_private *dev_priv,
else
crtc->drrs.busy_frontbuffer_bits &= ~frontbuffer_bits;
+ if (!intel_drrs_is_active(crtc)) {
+ mutex_unlock(>drrs.mutex);
+ continue;
+ }
+
/* flush/invalidate means busy screen hence upclock */
intel_drrs_set_state(crtc, DRRS_REFRESH_RATE_HIGH);
--
2.36.0
Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/gvt: Fix missing static
On Thu, Apr 28, 2022 at 08:55:48PM +, Patchwork wrote: == Series Details == Series: series starting with [1/2] drm/i915/gvt: Fix missing static URL : https://patchwork.freedesktop.org/series/103293/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gvt/handlers.o drivers/gpu/drm/i915/gvt/handlers.c:75:13: error: static declaration of ‘intel_gvt_match_device’ follows non-static declaration static bool intel_gvt_match_device(struct intel_gvt *gvt, ^~ In file included from drivers/gpu/drm/i915/gvt/gvt.h:42, from drivers/gpu/drm/i915/gvt/handlers.c:41: drivers/gpu/drm/i915/gvt/mmio.h:75:6: note: previous declaration of ‘intel_gvt_match_device’ was here bool intel_gvt_match_device(struct intel_gvt *gvt, unsigned long device); ^~ it looks like CI tried to apply this to the wrong rev. It's probably trying to apply it to the last one that it knows is buildable... which means it never validates if something fixes the build? I think it would be better to try applying to the latest drm-tip, and fallback to latest known-buildable iff it fails. Lucas De Marchi scripts/Makefile.build:288: recipe for target 'drivers/gpu/drm/i915/gvt/handlers.o' failed make[4]: *** [drivers/gpu/drm/i915/gvt/handlers.o] Error 1 scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:550: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1834: recipe for target 'drivers' failed make: *** [drivers] Error 2
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: ttm for stolen region (rev5)
== Series Details ==
Series: drm/i915: ttm for stolen region (rev5)
URL : https://patchwork.freedesktop.org/series/102540/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102540v5
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_102540v5 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_102540v5, 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_102540v5/index.html
Participating hosts (43 -> 45)
--
Additional (4): bat-dg2-8 bat-adls-5 bat-dg1-6 bat-adlp-4
Missing(2): fi-bsw-cyan fi-pnv-d510
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_102540v5:
### IGT changes ###
Possible regressions
* igt@kms_force_connector_basic@force-connector-state:
- fi-kbl-8809g: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-kbl-8809g/igt@kms_force_connector_ba...@force-connector-state.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-kbl-8809g/igt@kms_force_connector_ba...@force-connector-state.html
* igt@runner@aborted:
- fi-cfl-8700k: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-cfl-8700k/igt@run...@aborted.html
- fi-bxt-dsi: NOTRUN -> [FAIL][4]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-bxt-dsi/igt@run...@aborted.html
- fi-adl-ddr5:NOTRUN -> [FAIL][5]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-adl-ddr5/igt@run...@aborted.html
- fi-cfl-guc: NOTRUN -> [FAIL][6]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-cfl-guc/igt@run...@aborted.html
- fi-glk-j4005: NOTRUN -> [FAIL][7]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-glk-j4005/igt@run...@aborted.html
Warnings
* igt@runner@aborted:
- fi-apl-guc: [FAIL][8] ([i915#4312]) -> [FAIL][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-apl-guc/igt@run...@aborted.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-apl-guc/igt@run...@aborted.html
- fi-bdw-5557u: [FAIL][10] ([i915#4312]) -> [FAIL][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bdw-5557u/igt@run...@aborted.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-bdw-5557u/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@runner@aborted:
- {fi-jsl-1}: NOTRUN -> [FAIL][12]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-jsl-1/igt@run...@aborted.html
- {fi-ehl-2}: NOTRUN -> [FAIL][13]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-ehl-2/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_102540v5 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][14] ([i915#5827])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-g3258: [PASS][15] -> [INCOMPLETE][16] ([i915#4785])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-hsw-g3258/igt@i915_selftest@l...@hangcheck.html
* igt@runner@aborted:
- fi-rkl-11600: NOTRUN -> [FAIL][17] ([i915#5602])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-rkl-11600/igt@run...@aborted.html
- fi-bsw-kefka: NOTRUN -> [FAIL][18] ([i915#3690])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-bsw-kefka/igt@run...@aborted.html
- fi-cfl-8109u: NOTRUN -> [FAIL][19] ([i915#5602])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-cfl-8109u/igt@run...@aborted.html
- fi-bsw-nick:NOTRUN -> [FAIL][20] ([i915#3690])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-bsw-nick/igt@run...@aborted.html
- fi-kbl-8809g: NOTRUN -> [FAIL][21] ([i915#4312])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102540v5/fi-kbl-8809g/igt@run...@aborted.html
- fi-hsw-g3258: NOTRUN -> [FAIL][22] ([fdo#109271] / [i915#4312])
[22]:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [1/2] drm/i915/gvt: Fix missing static
== Series Details == Series: series starting with [1/2] drm/i915/gvt: Fix missing static URL : https://patchwork.freedesktop.org/series/103293/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gvt/handlers.o drivers/gpu/drm/i915/gvt/handlers.c:75:13: error: static declaration of ‘intel_gvt_match_device’ follows non-static declaration static bool intel_gvt_match_device(struct intel_gvt *gvt, ^~ In file included from drivers/gpu/drm/i915/gvt/gvt.h:42, from drivers/gpu/drm/i915/gvt/handlers.c:41: drivers/gpu/drm/i915/gvt/mmio.h:75:6: note: previous declaration of ‘intel_gvt_match_device’ was here bool intel_gvt_match_device(struct intel_gvt *gvt, unsigned long device); ^~ scripts/Makefile.build:288: recipe for target 'drivers/gpu/drm/i915/gvt/handlers.o' failed make[4]: *** [drivers/gpu/drm/i915/gvt/handlers.o] Error 1 scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:550: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:550: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1834: recipe for target 'drivers' failed make: *** [drivers] Error 2
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gvt: Fix missing static
On Thu, Apr 28, 2022 at 01:42:53PM -0700, Wang, Zhi A wrote:
On 4/28/22 8:40 PM, De Marchi, Lucas wrote:
Fix broken build:
$ make W=1 drivers/gpu/drm/i915/gvt/handlers.o
...
CC [M] drivers/gpu/drm/i915/gvt/handlers.o
drivers/gpu/drm/i915/gvt/handlers.c:75:6: error: no previous prototype
for ‘intel_gvt_match_device’ [-Werror=missing-prototypes]
75 | bool intel_gvt_match_device(struct intel_gvt *gvt,
| ^~
cc1: all warnings being treated as errors
Commit e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from
GVT-g") removed the prototype from the header due to the function being
used only in this single compilation unit, but forgot to make it static.
Fixes: e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from GVT-g")
Cc: Zhi Wang
Cc: Christoph Hellwig
Cc: Zhenyu Wang
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Hi Lucas:
Thanks so much for the patch. There is a patch to fix
undergoing already. I will take your second patch.
oh 20220427212849.18109-1-zhi.a.w...@intel.com, I missed that.
Do you mind adding the Fixes tag in that one to avoid it going to a
kernel release without that?
thanks
Lucas De Marchi
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: ttm for stolen region (rev5)
== Series Details == Series: drm/i915: ttm for stolen region (rev5) URL : https://patchwork.freedesktop.org/series/102540/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gvt: Fix missing static
On 4/28/22 8:40 PM, De Marchi, Lucas wrote:
> Fix broken build:
>
> $ make W=1 drivers/gpu/drm/i915/gvt/handlers.o
> ...
> CC [M] drivers/gpu/drm/i915/gvt/handlers.o
> drivers/gpu/drm/i915/gvt/handlers.c:75:6: error: no previous prototype
> for ‘intel_gvt_match_device’ [-Werror=missing-prototypes]
> 75 | bool intel_gvt_match_device(struct intel_gvt *gvt,
> | ^~
> cc1: all warnings being treated as errors
>
> Commit e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from
> GVT-g") removed the prototype from the header due to the function being
> used only in this single compilation unit, but forgot to make it static.
>
> Fixes: e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from GVT-g")
> Cc: Zhi Wang
> Cc: Christoph Hellwig
> Cc: Zhenyu Wang
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
Hi Lucas:
Thanks so much for the patch. There is a patch to fix
undergoing already. I will take your second patch.
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index cf00398c2870..e4358aa01048 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -72,8 +72,8 @@ unsigned long intel_gvt_get_device_type(struct intel_gvt
> *gvt)
> return 0;
> }
>
> -bool intel_gvt_match_device(struct intel_gvt *gvt,
> - unsigned long device)
> +static bool intel_gvt_match_device(struct intel_gvt *gvt,
> +unsigned long device)
> {
> return intel_gvt_get_device_type(gvt) & device;
> }
>
[Intel-gfx] [PATCH 2/2] drm/i915/gvt: Fix wrong kernel doc
Fix function name when documenting it:
drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype
for intel_t_default_mmio_write(). Prototype was for
intel_vgpu_default_mmio_write() instead
Fixes: e39c5add3221 ("drm/i915/gvt: vGPU MMIO virtualization")
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index e4358aa01048..49aacae3b16f 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -3052,7 +3052,7 @@ int intel_vgpu_default_mmio_read(struct intel_vgpu *vgpu,
unsigned int offset,
}
/**
- * intel_t_default_mmio_write - default MMIO write handler
+ * intel_vgpu_default_mmio_write - default MMIO write handler
* @vgpu: a vGPU
* @offset: access offset
* @p_data: write data buffer
--
2.36.0
[Intel-gfx] [PATCH 1/2] drm/i915/gvt: Fix missing static
Fix broken build:
$ make W=1 drivers/gpu/drm/i915/gvt/handlers.o
...
CC [M] drivers/gpu/drm/i915/gvt/handlers.o
drivers/gpu/drm/i915/gvt/handlers.c:75:6: error: no previous prototype
for ‘intel_gvt_match_device’ [-Werror=missing-prototypes]
75 | bool intel_gvt_match_device(struct intel_gvt *gvt,
| ^~
cc1: all warnings being treated as errors
Commit e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from
GVT-g") removed the prototype from the header due to the function being
used only in this single compilation unit, but forgot to make it static.
Fixes: e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from GVT-g")
Cc: Zhi Wang
Cc: Christoph Hellwig
Cc: Zhenyu Wang
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gvt/handlers.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index cf00398c2870..e4358aa01048 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -72,8 +72,8 @@ unsigned long intel_gvt_get_device_type(struct intel_gvt *gvt)
return 0;
}
-bool intel_gvt_match_device(struct intel_gvt *gvt,
- unsigned long device)
+static bool intel_gvt_match_device(struct intel_gvt *gvt,
+ unsigned long device)
{
return intel_gvt_get_device_type(gvt) & device;
}
--
2.36.0
[Intel-gfx] [PATCH v5 6/6] drm/i915: stolen memory use ttm backend
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 78 +--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 -
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 453 --
drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 21 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 5 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 7 +
drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +-
drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +-
drivers/gpu/drm/i915/i915_debugfs.c | 7 +-
drivers/gpu/drm/i915/i915_drv.h | 5 -
drivers/gpu/drm/i915/intel_region_ttm.c | 36 +-
drivers/gpu/drm/i915/intel_region_ttm.h | 8 +-
drivers/gpu/drm/i915/selftests/mock_region.c | 3 +-
13 files changed, 307 insertions(+), 338 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
b/drivers/gpu/drm/i915/display/intel_fbc.c
index b7bdb0739744..7064682f8c9e 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -38,6 +38,7 @@
* forcibly disable it to allow proper screen updates.
*/
+#include "gem/i915_gem_stolen.h"
#include
#include
@@ -51,6 +52,7 @@
#include "intel_display_types.h"
#include "intel_fbc.h"
#include "intel_frontbuffer.h"
+#include "gem/i915_gem_region.h"
#define for_each_fbc_id(__dev_priv, __fbc_id) \
for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) < I915_MAX_FBCS;
(__fbc_id)++) \
@@ -92,8 +94,8 @@ struct intel_fbc {
struct mutex lock;
unsigned int busy_bits;
- struct drm_mm_node compressed_fb;
- struct drm_mm_node compressed_llb;
+ struct ttm_resource *compressed_fb;
+ struct ttm_resource *compressed_llb;
enum intel_fbc_id id;
@@ -331,16 +333,20 @@ static void i8xx_fbc_nuke(struct intel_fbc *fbc)
static void i8xx_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
+ u64 llb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_llb);
+ GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+ GEM_BUG_ON(llb_offset == I915_BO_INVALID_OFFSET);
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_fb.start, U32_MAX));
+fb_offset, U32_MAX));
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_llb.start, U32_MAX));
+llb_offset, U32_MAX));
intel_de_write(i915, FBC_CFB_BASE,
- i915->dsm.start + fbc->compressed_fb.start);
+ i915->dsm.start + fb_offset);
intel_de_write(i915, FBC_LL_BASE,
- i915->dsm.start + fbc->compressed_llb.start);
+ i915->dsm.start + llb_offset);
}
static const struct intel_fbc_funcs i8xx_fbc_funcs = {
@@ -448,8 +454,10 @@ static bool g4x_fbc_is_compressing(struct intel_fbc *fbc)
static void g4x_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
- intel_de_write(i915, DPFC_CB_BASE, fbc->compressed_fb.start);
+ GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+ intel_de_write(i915, DPFC_CB_BASE, fb_offset);
}
static const struct intel_fbc_funcs g4x_fbc_funcs = {
@@ -499,8 +507,10 @@ static bool ilk_fbc_is_compressing(struct intel_fbc *fbc)
static void ilk_fbc_program_cfb(struct intel_fbc *fbc)
{
struct drm_i915_private *i915 = fbc->i915;
+ u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
- intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id),
fbc->compressed_fb.start);
+ GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+ intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), fb_offset);
}
static const struct intel_fbc_funcs ilk_fbc_funcs = {
@@ -744,21 +754,24 @@ static int find_compression_limit(struct intel_fbc *fbc,
{
struct drm_i915_private *i915 = fbc->i915;
u64 end = intel_fbc_stolen_end(i915);
- int ret, limit = min_limit;
+ int limit = min_limit;
+ struct ttm_resource *res;
size /= limit;
/* Try to over-allocate to reduce reallocations and fragmentation. */
- ret = i915_gem_stolen_insert_node_in_range(i915, >compressed_fb,
- size <<= 1, 4096, 0, end);
- if (ret == 0)
+ res = i915_gem_stolen_reserve_range(i915, size <<= 1, 0, end);
+ if (!IS_ERR(res)) {
+ fbc->compressed_fb = res;
return limit;
+ }
for (; limit <=
[Intel-gfx] [PATCH v5 5/6] drm/i915: allow memory region creators to alloc and free the region
add callbacks for alloc and free.
this allows region creators to allocate any extra storage they may
require.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_memory_region.c | 16 +---
drivers/gpu/drm/i915/intel_memory_region.h | 2 ++
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_memory_region.c
b/drivers/gpu/drm/i915/intel_memory_region.c
index e38d2db1c3e3..3da07a712f90 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.c
+++ b/drivers/gpu/drm/i915/intel_memory_region.c
@@ -231,7 +231,10 @@ intel_memory_region_create(struct drm_i915_private *i915,
struct intel_memory_region *mem;
int err;
- mem = kzalloc(sizeof(*mem), GFP_KERNEL);
+ if (ops->alloc)
+ mem = ops->alloc();
+ else
+ mem = kzalloc(sizeof(*mem), GFP_KERNEL);
if (!mem)
return ERR_PTR(-ENOMEM);
@@ -265,7 +268,10 @@ intel_memory_region_create(struct drm_i915_private *i915,
if (mem->ops->release)
mem->ops->release(mem);
err_free:
- kfree(mem);
+ if (mem->ops->free)
+ mem->ops->free(mem);
+ else
+ kfree(mem);
return ERR_PTR(err);
}
@@ -288,7 +294,11 @@ void intel_memory_region_destroy(struct
intel_memory_region *mem)
GEM_WARN_ON(!list_empty_careful(>objects.list));
mutex_destroy(>objects.lock);
- if (!ret)
+ if (ret)
+ return;
+ if (mem->ops->free)
+ mem->ops->free(mem);
+ else
kfree(mem);
}
diff --git a/drivers/gpu/drm/i915/intel_memory_region.h
b/drivers/gpu/drm/i915/intel_memory_region.h
index 3d8378c1b447..048955b5429f 100644
--- a/drivers/gpu/drm/i915/intel_memory_region.h
+++ b/drivers/gpu/drm/i915/intel_memory_region.h
@@ -61,6 +61,8 @@ struct intel_memory_region_ops {
resource_size_t size,
resource_size_t page_size,
unsigned int flags);
+ struct intel_memory_region *(*alloc)(void);
+ void (*free)(struct intel_memory_region *mem);
};
struct intel_memory_region {
--
2.25.1
[Intel-gfx] [PATCH v5 4/6] drm/i915: ttm backend dont provide mmap_offset for kernel buffers
stolen/kernel buffers should not be mmapable by userland.
do not provide callbacks to facilitate this for these buffers.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 32 +
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 4c25d9b2f138..d22a1af214ce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1120,8 +1120,8 @@ static void i915_ttm_unmap_virtual(struct
drm_i915_gem_object *obj)
ttm_bo_unmap_virtual(i915_gem_to_ttm(obj));
}
-static const struct drm_i915_gem_object_ops i915_gem_ttm_obj_ops = {
- .name = "i915_gem_object_ttm",
+static const struct drm_i915_gem_object_ops i915_gem_ttm_user_obj_ops = {
+ .name = "i915_gem_object_ttm_user",
.flags = I915_GEM_OBJECT_IS_SHRINKABLE |
I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
@@ -1139,6 +1139,21 @@ static const struct drm_i915_gem_object_ops
i915_gem_ttm_obj_ops = {
.mmap_ops = _ops_ttm,
};
+static const struct drm_i915_gem_object_ops i915_gem_ttm_kern_obj_ops = {
+ .name = "i915_gem_object_ttm_kern",
+ .flags = I915_GEM_OBJECT_IS_SHRINKABLE |
+I915_GEM_OBJECT_SELF_MANAGED_SHRINK_LIST,
+
+ .get_pages = i915_ttm_get_pages,
+ .put_pages = i915_ttm_put_pages,
+ .truncate = i915_ttm_truncate,
+ .shrink = i915_ttm_shrink,
+
+ .adjust_lru = i915_ttm_adjust_lru,
+ .delayed_free = i915_ttm_delayed_free,
+ .migrate = i915_ttm_migrate,
+};
+
void i915_ttm_bo_destroy(struct ttm_buffer_object *bo)
{
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
@@ -1193,10 +1208,19 @@ int __i915_gem_ttm_object_init(struct
intel_memory_region *mem,
.no_wait_gpu = false,
};
enum ttm_bo_type bo_type;
+ const struct drm_i915_gem_object_ops *ops;
int ret;
drm_gem_private_object_init(>drm, >base, size);
- i915_gem_object_init(obj, _gem_ttm_obj_ops, _class, flags);
+
+ if (flags & I915_BO_ALLOC_USER && intel_region_to_ttm_type(mem) !=
I915_PL_STOLEN) {
+ bo_type = ttm_bo_type_device;
+ ops = _gem_ttm_user_obj_ops;
+ } else {
+ bo_type = ttm_bo_type_kernel;
+ ops = _gem_ttm_kern_obj_ops;
+ }
+ i915_gem_object_init(obj, ops, _class, flags);
obj->bo_offset = offset;
@@ -1206,8 +1230,6 @@ int __i915_gem_ttm_object_init(struct intel_memory_region
*mem,
INIT_RADIX_TREE(>ttm.get_io_page.radix, GFP_KERNEL | __GFP_NOWARN);
mutex_init(>ttm.get_io_page.lock);
- bo_type = (obj->flags & I915_BO_ALLOC_USER) ? ttm_bo_type_device :
- ttm_bo_type_kernel;
obj->base.vma_node.driver_private = i915_gem_to_ttm(obj);
--
2.25.1
[Intel-gfx] [PATCH v5 3/6] drm/i915: ttm move/clear logic fix
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.
The desired behaviour is to clear user allocated buffers and any kernel
buffers that specifically requests it only.
Make the logic match the desired behaviour.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 22 +++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 48046cfd8c4b..2895e13a1cac 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,6 +3,7 @@
* Copyright © 2021 Intel Corporation
*/
+#include "drm/ttm/ttm_tt.h"
#include
#include "i915_deps.h"
@@ -471,6 +472,25 @@ __i915_ttm_move(struct ttm_buffer_object *bo,
return fence;
}
+static bool
+allow_clear(struct drm_i915_gem_object *obj, struct ttm_tt *ttm, struct
ttm_resource *dst_mem)
+{
+ /* never clear stolen */
+ if (dst_mem->mem_type == I915_PL_STOLEN)
+ return false;
+ /*
+* we want to clear user buffers and any kernel buffers
+* that specifically request clearing.
+*/
+ if (obj->flags & I915_BO_ALLOC_USER)
+ return true;
+
+ if (ttm && ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)
+ return true;
+
+ return false;
+}
+
/**
* i915_ttm_move - The TTM move callback used by i915.
* @bo: The buffer object.
@@ -521,7 +541,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
return PTR_ERR(dst_rsgt);
clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm ||
!ttm_tt_is_populated(ttm));
- if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+ if (!clear || allow_clear(obj, ttm, dst_mem)) {
struct i915_deps deps;
i915_deps_init(, GFP_KERNEL | __GFP_NORETRY |
__GFP_NOWARN);
--
2.25.1
[Intel-gfx] [PATCH v5 2/6] drm/i915: sanitize mem_flags for stolen buffers
Stolen regions are not page backed or considered iomem. Prevent flags indicating such. This correctly prevents stolen buffers from attempting to directly map them. See i915_gem_object_has_struct_page() and i915_gem_object_has_iomem() usage for where it would break otherwise. Signed-off-by: Robert Beckett Reviewed-by: Thomas Hellström --- drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c index 358f8a1a30ce..48046cfd8c4b 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c @@ -14,6 +14,7 @@ #include "gem/i915_gem_region.h" #include "gem/i915_gem_ttm.h" #include "gem/i915_gem_ttm_move.h" +#include "gem/i915_gem_stolen.h" #include "gt/intel_engine_pm.h" #include "gt/intel_gt.h" @@ -122,8 +123,9 @@ void i915_ttm_adjust_gem_after_move(struct drm_i915_gem_object *obj) obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM); - obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? I915_BO_FLAG_IOMEM : - I915_BO_FLAG_STRUCT_PAGE; + if (!i915_gem_object_is_stolen(obj)) + obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? I915_BO_FLAG_IOMEM : + I915_BO_FLAG_STRUCT_PAGE; cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource, bo->ttm); -- 2.25.1
[Intel-gfx] [PATCH v5 1/6] drm/i915: instantiate ttm ranger manager for stolen memory
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 31 +++-
2 files changed, 27 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index a10716f4e717..358f8a1a30ce 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -58,11 +58,13 @@ i915_ttm_region(struct ttm_device *bdev, int ttm_mem_type)
struct drm_i915_private *i915 = container_of(bdev, typeof(*i915), bdev);
/* There's some room for optimization here... */
- GEM_BUG_ON(ttm_mem_type != I915_PL_SYSTEM &&
- ttm_mem_type < I915_PL_LMEM0);
+ GEM_BUG_ON(ttm_mem_type == I915_PL_GGTT);
+
if (ttm_mem_type == I915_PL_SYSTEM)
return intel_memory_region_lookup(i915, INTEL_MEMORY_SYSTEM,
0);
+ if (ttm_mem_type == I915_PL_STOLEN)
+ return i915->mm.stolen_region;
return intel_memory_region_lookup(i915, INTEL_MEMORY_LOCAL,
ttm_mem_type - I915_PL_LMEM0);
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 62ff77445b01..7d49ea72e33f 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -49,7 +49,7 @@ void intel_region_ttm_device_fini(struct drm_i915_private
*dev_priv)
/*
* Map the i915 memory regions to TTM memory types. We use the
- * driver-private types for now, reserving TTM_PL_VRAM for stolen
+ * driver-private types for now, reserving I915_PL_STOLEN for stolen
* memory and TTM_PL_TT for GGTT use if decided to implement this.
*/
int intel_region_to_ttm_type(const struct intel_memory_region *mem)
@@ -58,11 +58,17 @@ int intel_region_to_ttm_type(const struct
intel_memory_region *mem)
GEM_BUG_ON(mem->type != INTEL_MEMORY_LOCAL &&
mem->type != INTEL_MEMORY_MOCK &&
- mem->type != INTEL_MEMORY_SYSTEM);
+ mem->type != INTEL_MEMORY_SYSTEM &&
+ mem->type != INTEL_MEMORY_STOLEN_SYSTEM &&
+ mem->type != INTEL_MEMORY_STOLEN_LOCAL);
if (mem->type == INTEL_MEMORY_SYSTEM)
return TTM_PL_SYSTEM;
+ if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+ mem->type == INTEL_MEMORY_STOLEN_LOCAL)
+ return I915_PL_STOLEN;
+
type = mem->instance + TTM_PL_PRIV;
GEM_BUG_ON(type >= TTM_NUM_MEM_TYPES);
@@ -86,10 +92,16 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int mem_type = intel_region_to_ttm_type(mem);
int ret;
- ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
- resource_size(>region),
- mem->io_size,
- mem->min_page_size, PAGE_SIZE);
+ if (mem_type == I915_PL_STOLEN) {
+ ret = ttm_range_man_init(bdev, mem_type, false,
+resource_size(>region) >>
PAGE_SHIFT);
+ mem->is_range_manager = true;
+ } else {
+ ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
+ resource_size(>region),
+ mem->io_size,
+ mem->min_page_size, PAGE_SIZE);
+ }
if (ret)
return ret;
@@ -109,6 +121,7 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int intel_region_ttm_fini(struct intel_memory_region *mem)
{
struct ttm_resource_manager *man = mem->region_private;
+ int mem_type = intel_region_to_ttm_type(mem);
int ret = -EBUSY;
int count;
@@ -139,8 +152,10 @@ int intel_region_ttm_fini(struct intel_memory_region *mem)
if (ret || !man)
return ret;
- ret = i915_ttm_buddy_man_fini(>i915->bdev,
- intel_region_to_ttm_type(mem));
+ if (mem_type == I915_PL_STOLEN)
+ ret = ttm_range_man_fini(>i915->bdev, mem_type);
+ else
+ ret = i915_ttm_buddy_man_fini(>i915->bdev, mem_type);
GEM_WARN_ON(ret);
mem->region_private = NULL;
--
2.25.1
[Intel-gfx] [PATCH v5 0/6] drm/i915: ttm for stolen region
This series refactors i915's stolen memory region to use ttm. v2: handle disabled stolen similar to legacy version. relying on ttm to fail allocs works fine, but is dmesg noisy and causes testing dmesg warning regressions. v3: rebase to latest drm-tip. fix v2 code refactor which could leave a buffer pinned. locally passes fftl again now. v4: - Allow memory regions creators to do allocation. Allows stolen region to track it's own reservations. - Pre-reserve first page of stolen mem (add back WaSkipStolenMemoryFirstPage:bdw+) - Improve commit descritpion for "drm/i915: sanitize mem_flags for stolen buffers" - replace i915_gem_object_pin_pages_unlocked() call with manual locking and pinning. this avoids ww ctx class reuse during context creation -> ring vma obj alloc. v5: - detect both types of stolen as stolen buffers in "drm/i915: sanitize mem_flags for stolen buffers" - in stolen_object_init limit page size to mem region minimum. The range allocator expects the page_size to define the alignment Robert Beckett (6): drm/i915: instantiate ttm ranger manager for stolen memory drm/i915: sanitize mem_flags for stolen buffers drm/i915: ttm move/clear logic fix drm/i915: ttm backend dont provide mmap_offset for kernel buffers drm/i915: allow memory region creators to alloc and free the region drm/i915: stolen memory use ttm backend drivers/gpu/drm/i915/display/intel_fbc.c | 78 +-- .../gpu/drm/i915/gem/i915_gem_object_types.h | 2 - drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 453 -- drivers/gpu/drm/i915/gem/i915_gem_stolen.h| 21 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 35 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 7 + drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 34 +- drivers/gpu/drm/i915/gt/intel_rc6.c | 4 +- drivers/gpu/drm/i915/gt/selftest_reset.c | 16 +- drivers/gpu/drm/i915/i915_debugfs.c | 7 +- drivers/gpu/drm/i915/i915_drv.h | 5 - drivers/gpu/drm/i915/intel_memory_region.c| 16 +- drivers/gpu/drm/i915/intel_memory_region.h| 2 + drivers/gpu/drm/i915/intel_region_ttm.c | 67 ++- drivers/gpu/drm/i915/intel_region_ttm.h | 8 +- drivers/gpu/drm/i915/selftests/mock_region.c | 3 +- 16 files changed, 400 insertions(+), 358 deletions(-) -- 2.25.1
[Intel-gfx] PR for new GuC v70.1.2 for DG2
The following changes since commit ac21ab5d1de0de34201c90d32eee436f873d1e5b: Mellanox: Add lc_ini_bundle for xx.2010.1006 (2022-04-25 07:36:16 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware guc_v70.1.2_dg2 for you to fetch changes up to 89ae5eb20f65752db6a3e38b9a69144f19540567: i915: Add GuC v70.1.2 for DG2 (2022-04-26 13:27:47 -0700) John Harrison (1): i915: Add GuC v70.1.2 for DG2 WHENCE | 3 +++ i915/dg2_guc_70.1.2.bin | Bin 0 -> 365568 bytes 2 files changed, 3 insertions(+) create mode 100644 i915/dg2_guc_70.1.2.bin
Re: [Intel-gfx] [PATCH 1/1] drm/i915: Replace shmem memory region and object backend with TTM
On Thu, 28 Apr 2022 at 09:39, Adrian Larumbe
wrote:
>
> Remove shmem region and object backend code as they are now unnecessary.
> In the case of objects placed in SMEM and backed by kernel shmem files, the
> file pointer has to be retrieved from the ttm_tt structure, so change this
> as well. This means accessing an shmem-backed BO's file pointer requires
> getting its pages beforehand, unlike in the old shmem backend.
>
> Expand TTM BO creation by handling devices with no LLC so that their
> caching and coherency properties are set accordingly.
>
> Signed-off-by: Adrian Larumbe
> ---
> drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +-
> drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_phys.c | 5 +-
> drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 397 +--
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 212 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 +
> drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +-
> drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++-
> drivers/gpu/drm/i915/intel_memory_region.c | 7 +-
> 10 files changed, 333 insertions(+), 412 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> index f5062d0c6333..de04ce4210b3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
> @@ -12,6 +12,7 @@
> #include
>
> #include "gem/i915_gem_dmabuf.h"
> +#include "gem/i915_gem_ttm.h"
> #include "i915_drv.h"
> #include "i915_gem_object.h"
> #include "i915_scatterlist.h"
> @@ -94,22 +95,25 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
> struct vm_area_struct *
> {
> struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
> struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + struct file *filp = i915_gem_ttm_get_filep(obj);
> int ret;
>
> + GEM_BUG_ON(obj->base.import_attach != NULL);
> +
> if (obj->base.size < vma->vm_end - vma->vm_start)
> return -EINVAL;
>
> if (HAS_LMEM(i915))
> return drm_gem_prime_mmap(>base, vma);
>
> - if (!obj->base.filp)
> + if (!filp)
> return -ENODEV;
>
> - ret = call_mmap(obj->base.filp, vma);
> + ret = call_mmap(filp, vma);
> if (ret)
> return ret;
>
> - vma_set_file(vma, obj->base.filp);
> + vma_set_file(vma, filp);
>
> return 0;
> }
> @@ -224,6 +228,8 @@ struct dma_buf *i915_gem_prime_export(struct
> drm_gem_object *gem_obj, int flags)
> exp_info.priv = gem_obj;
> exp_info.resv = obj->base.resv;
>
> + GEM_BUG_ON(obj->base.import_attach != NULL);
> +
> if (obj->ops->dmabuf_export) {
> int ret = obj->ops->dmabuf_export(obj);
> if (ret)
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index 0c5c43852e24..d963cf35fdc9 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -64,7 +64,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
> struct drm_i915_private *i915 = to_i915(dev);
> struct drm_i915_gem_mmap *args = data;
> struct drm_i915_gem_object *obj;
> + struct file *filp;
> unsigned long addr;
> + int ret;
>
> /*
> * mmap ioctl is disallowed for all discrete platforms,
> @@ -83,12 +85,20 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
> if (!obj)
> return -ENOENT;
>
> - /* prime objects have no backing filp to GEM mmap
> -* pages from.
> -*/
> - if (!obj->base.filp) {
> - addr = -ENXIO;
> - goto err;
> + if (obj->base.import_attach)
> + filp = obj->base.filp;
> + else {
> + ret = i915_gem_object_pin_pages_unlocked(obj);
> + if (ret) {
> + addr = ret;
> + goto err_pin;
> + }
> +
> + filp = i915_gem_ttm_get_filep(obj);
> + if (!filp) {
> + addr = -ENXIO;
> + goto err;
> + }
> }
>
> if (range_overflows(args->offset, args->size, (u64)obj->base.size)) {
> @@ -96,7 +106,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
> goto err;
> }
>
> - addr = vm_mmap(obj->base.filp, 0, args->size,
> + addr = vm_mmap(filp, 0, args->size,
>PROT_READ | PROT_WRITE, MAP_SHARED,
>args->offset);
> if (IS_ERR_VALUE(addr))
> @@ -111,7 +121,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
> goto err;
> }
> vma
Re: [Intel-gfx] [PATCH] i915/guc/reset: Make __guc_reset_context aware of guilty engines
At a high level, this change looks good and simple.
However, inside __guc_reset_context, i think there might be
an observed change in behavior for parallel submission.
(or perhaps this change is part the intent?):
Unless my understanding is incorrect, assuming a
parallel submission comes in with virtual engines that
repeat the same kinds of workloads across multiple
physical engines (which i assume would be the typical
end-user usage of this UAPI feature), we would end up
marking the parent content (and other children contexts
that use the same engine) as guilty but not children
contexts that are running on a different engine.
I'm not sure if this would be an expected UAPI response
for parallel submission. (i.e. one or more children
get a re-run on other engines? I havent checked if
the replay is revoked later if the parent's or sibling's
'request' was reset and marked as -EIO ... this marking
of req->force_error as -EIO or -EAGAIN is part of the
call to __i915_request_reset where the guilty param
value sees this change i am referring to).
Is this intended / expected?
...alan
On Mon, 2022-04-25 at 17:30 -0700, Umesh Nerlige Ramappa wrote:
> There are 2 ways an engine can get reset in i915 and the method of reset
> affects how KMD labels a context as guilty/innocent.
>
> (1) GuC initiated engine-reset: GuC resets a hung engine and notifies
> KMD. The context that hung on the engine is marked guilty and all other
> contexts are innocent. The innocent contexts are resubmitted.
>
> (2) GT based reset: When an engine heartbeat fails to tick, KMD
> initiates a gt/chip reset. All active contexts are marked as guilty and
> discarded.
>
> In order to correctly mark the contexts as guilty/innocent, pass a mask
> of engines that were reset to __guc_reset_context.
>
> Fixes: eb5e7da736f3 ("drm/i915/guc: Reset implementation for new GuC
> interface")
> Signed-off-by: Umesh Nerlige Ramappa
> ---
> drivers/gpu/drm/i915/gt/intel_reset.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_guc.h | 2 +-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 16
> drivers/gpu/drm/i915/gt/uc/intel_uc.c| 2 +-
> drivers/gpu/drm/i915/gt/uc/intel_uc.h| 2 +-
> 5 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> b/drivers/gpu/drm/i915/gt/intel_reset.c
> index 5422a3b84bd4..a5338c3fde7a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -808,7 +808,7 @@ static int gt_reset(struct intel_gt *gt,
> intel_engine_mask_t stalled_mask)
> __intel_engine_reset(engine, stalled_mask & engine->mask);
> local_bh_enable();
>
> - intel_uc_reset(>uc, true);
> + intel_uc_reset(>uc, ALL_ENGINES);
>
> intel_ggtt_restore_fences(gt->ggtt);
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> index 3f3373f68123..966e69a8b1c1 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
> @@ -443,7 +443,7 @@ int intel_guc_global_policies_update(struct intel_guc
> *guc);
> void intel_guc_context_ban(struct intel_context *ce, struct i915_request
> *rq);
>
> void intel_guc_submission_reset_prepare(struct intel_guc *guc);
> -void intel_guc_submission_reset(struct intel_guc *guc, bool stalled);
> +void intel_guc_submission_reset(struct intel_guc *guc, intel_engine_mask_t
> stalled);
> void intel_guc_submission_reset_finish(struct intel_guc *guc);
> void intel_guc_submission_cancel_requests(struct intel_guc *guc);
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 61a6f2424e24..1fbf7b6c2740 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -1667,9 +1667,9 @@ __unwind_incomplete_requests(struct intel_context *ce)
> spin_unlock_irqrestore(_engine->lock, flags);
> }
>
> -static void __guc_reset_context(struct intel_context *ce, bool stalled)
> +static void __guc_reset_context(struct intel_context *ce,
> intel_engine_mask_t stalled)
> {
> - bool local_stalled;
> + bool guilty;
> struct i915_request *rq;
> unsigned long flags;
> u32 head;
> @@ -1697,7 +1697,7 @@ static void __guc_reset_context(struct intel_context
> *ce, bool stalled)
> if (!intel_context_is_pinned(ce))
> goto next_context;
>
> - local_stalled = false;
> + guilty = false;
> rq = intel_context_find_active_request(ce);
> if (!rq) {
> head = ce->ring->tail;
> @@ -1705,14 +1705,14 @@ static void __guc_reset_context(struct intel_context
> *ce, bool stalled)
> }
>
> if
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Fix memory leaks in per-gt sysfs
Addressed the failure and re-reported. Re-opened the issue https://gitlab.freedesktop.org/drm/intel/-/issues/5196 igt@syncobj_timeline@wait-all-for-submit-snapshot - fail - Failed assertion: __syncobj_timeline_wait_ioctl(wait->fd, >wait) == 0, error: -62 != 0 Filed a new issue https://gitlab.freedesktop.org/drm/intel/-/issues/5864 igt@kms_flip@flip-vs-suspend-interruptible@a-edp1 - incomplete - PM: suspend entry (deep) Thanks, Lakshmi. -Original Message- From: Dixit, Ashutosh Sent: Wednesday, April 27, 2022 5:42 PM To: intel-gfx@lists.freedesktop.org; Vudum, Lakshminarayana Subject: Re: ✗ Fi.CI.IGT: failure for drm/i915/gt: Fix memory leaks in per-gt sysfs On Wed, 27 Apr 2022 15:45:40 -0700, Patchwork wrote: > > Possible regressions > > * igt@kms_flip@flip-vs-suspend-interruptible@a-edp1: > > * shard-skl: PASS -> INCOMPLETE > > * igt@syncobj_timeline@wait-all-for-submit-snapshot: > > * shard-skl: PASS -> FAIL > > Warnings > > * igt@gem_eio@unwedge-stress: > > * shard-tglb: FAIL (i915#232) -> FAIL +1 similar issue These failures are unrelated, the patch is related only to per-gt sysfs.
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Fix memory leaks in per-gt sysfs
== Series Details ==
Series: drm/i915/gt: Fix memory leaks in per-gt sysfs
URL : https://patchwork.freedesktop.org/series/103236/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103236v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103236v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_dc@dc6-dpms:
- {shard-rkl}:NOTRUN -> [INCOMPLETE][1] +2 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103236v1/shard-rkl-5/igt@i915_pm...@dc6-dpms.html
* {igt@kms_concurrent@pipe-d@hdmi-a-3}:
- {shard-dg1}:NOTRUN -> [CRASH][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103236v1/shard-dg1-18/igt@kms_concurrent@pip...@hdmi-a-3.html
New tests
-
New tests have been introduced between CI_DRM_11550_full and
Patchwork_103236v1_full:
### New IGT tests (4) ###
* igt@kms_sequence@get-busy@hdmi-a-3-pipe-a:
- Statuses : 1 pass(s)
- Exec time: [2.42] s
* igt@kms_sequence@get-busy@hdmi-a-3-pipe-b:
- Statuses : 1 pass(s)
- Exec time: [2.38] s
* igt@kms_sequence@get-busy@hdmi-a-3-pipe-c:
- Statuses : 1 pass(s)
- Exec time: [2.38] s
* igt@kms_sequence@get-busy@hdmi-a-3-pipe-d:
- Statuses : 1 pass(s)
- Exec time: [2.39] s
Known issues
Here are the changes found in Patchwork_103236v1_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-skl: ([PASS][3], [PASS][4], [PASS][5], [PASS][6],
[PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [FAIL][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
[PASS][25], [PASS][26]) ([i915#5032]) -> ([PASS][27], [PASS][28], [PASS][29],
[PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35],
[PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41],
[PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47],
[PASS][48], [PASS][49], [PASS][50], [PASS][51])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103236v1/shard-skl2/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103236v1/shard-skl9/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103236v1/shard-skl9/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103236v1/shard-skl8/boot.html
[31]:
Re: [Intel-gfx] [PATCH 7/9] drm/i915/gt: Fix memory leaks in per-gt sysfs
On 27.04.2022 22:46, Dixit, Ashutosh wrote:
On Sun, 24 Apr 2022 15:36:23 -0700, Andi Shyti wrote:
Hi Andrzej and Ashutosh,
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 937b2e1a305e..4c72b4f983a6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -222,6 +222,9 @@ struct intel_gt {
} mocs;
struct intel_pxp pxp;
+
+ /* gt/gtN sysfs */
+ struct kobject sysfs_gtn;
If you put kobject as a part of intel_gt what assures you that lifetime of
kobject is shorter than intel_gt? Ie its refcounter is 0 on removal of
intel_gt?
Because we are explicitly doing a kobject_put() in
intel_gt_sysfs_unregister(). Which is exactly what we are *not* doing in
the previous code.
Let me explain a bit about the previous code (but feel free to skip since
the patch should speak for itself):
* Previously we kzalloc a 'struct kobj_gt'
* But we don't save a pointer to the 'struct kobj_gt' so we don't have the
pointer to the kobject to be able to do a kobject_put() on it later
* Therefore we need to store the pointer in 'struct intel_gt'
* But if we have to put the pointer in 'struct intel_gt' we might as well
put the kobject as part of 'struct intel_gt' and that also removes the
need to have a 'struct kobj_gt' (kobj_to_gt() can just use container_of()
to get gt from kobj).
* So I think this patch simpler/cleaner than the original code if you take
the requirement for kobject_put() into account.
This is my oversight. This was something I completely forgot to
fix but it was my intention to do and actually I had some fixes
ongoing. But because this patch took too long to get in I
completely forgot about it (Sujaritha was actually the first who
pointed this out).
Thanks, Ashutosh for taking this.
I fully agree that previous code is incorrect but I am not convinced current
code is correct.
If some objects are kref-counted it means usually they can have multiple
concurrent users and kobject_put does not work as traditional
destructor/cleanup/unregister.
So in this particular case after calling kobject_init_and_add sysfs core can
get multiple references on the object. Later, during driver unregistration
kobject_put is called, but if the object is still in use by sysfs core, the
object will not be destroyed/released. If the driver unregistration
continues memory will be freed, leaving sysfs-core (or other users) with
dangling pointers. Unless there is some additional synchronization mechanism
I am not aware of.
Thanks Andrzej for summarizing this and what you said is actually
what happens. I had a similar solution developed and I had wrong
pointer reference happening.
Hi Andrzej/Andi,
I did do some research into kobject's and such before writing this patch
and based on that I believe the patch is correct. Presenting some evidence
below.
The patch is verified by:
a. Putting a printk in the release() method when it exists (it does for
sysfs_gtn kobject)
b. Enabling dynamic prints for lib/kobject.c
For example, with the following:
# echo 'file kobject.c +p' > /sys/kernel/debug/dynamic_debug/control
# echo -n ":03:00.0" > /sys/bus/pci/drivers/i915/unbind
We see this in dmesg (see kobject_cleanup() called from kobject_put()):
[ 1034.930007] kobject: '.defaults' (88817130a640): kobject_cleanup, parent
8882262b5778
[ 1034.930020] kobject: '.defaults' (88817130a640): auto cleanup kobject_del
[ 1034.930336] kobject: '.defaults' (88817130a640): calling ktype release
[ 1034.930340] kobject: (88817130a640): dynamic_kobj_release
[ 1034.930354] kobject: '.defaults': free name
[ 1034.930366] kobject: 'gt0' (8882262b5778): kobject_cleanup, parent
88817130a240
[ 1034.930371] kobject: 'gt0' (8882262b5778): auto cleanup kobject_del
[ 1034.931930] kobject: 'gt0' (8882262b5778): calling ktype release
[ 1034.931936] kobject: 'gt0': free name
[ 1034.958004] kobject: 'i915__03_00.0' (88810e1f8800): fill_kobj_path:
path = '/devices/i915__03_00.0'
[ 1034.958155] kobject: 'i915__03_00.0' (88810e1f8800):
kobject_cleanup, parent
[ 1034.958162] kobject: 'i915__03_00.0' (88810e1f8800): calling ktype
release
[ 1034.958188] kobject: 'i915__03_00.0': free name
[ 1034.958729] kobject: 'gt' (88817130a240): kobject_cleanup, parent
8881160c5000
[ 1034.958736] kobject: 'gt' (88817130a240): auto cleanup kobject_del
[ 1034.958762] kobject: 'gt' (88817130a240): calling ktype release
[ 1034.958767] kobject: (88817130a240): dynamic_kobj_release
[ 1034.958778] kobject: 'gt': free name
We have the following directory structure (one of the patches is creating
/sys/class/drm/card0/gt/gt0/.defaults):
/sys/class/drm/card0/gt
|-gt0
|-.defaults
And we see from dmesg .defaults, gt0 and gt kobjects being cleaned up in
that order.
Looking at lib/kobject.c there are several
Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Convert ct buffer to iosys_map
On 14/04/22 17:41, Balasubramani Vivekanandan wrote:
> On 04.04.2022 15:01, Mullati Siva wrote:
>> From: Siva Mullati
>>
>> Convert CT commands and descriptors to use iosys_map rather
>> than plain pointer and save it in the intel_guc_ct_buffer struct.
>> This will help with ct_write and ct_read for cmd send and receive
>> after the initialization by abstracting the IO vs system memory.
>>
>> Signed-off-by: Siva Mullati
>> ---
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 200 +-
>> drivers/gpu/drm/i915/gt/uc/intel_guc_ct.h | 9 +-
>> 2 files changed, 127 insertions(+), 82 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index f01325cd1b62..64568dc90b05 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -44,6 +44,11 @@ static inline struct drm_device *ct_to_drm(struct
>> intel_guc_ct *ct)
>> #define CT_PROBE_ERROR(_ct, _fmt, ...) \
>> i915_probe_error(ct_to_i915(ct), "CT: " _fmt, ##__VA_ARGS__)
>>
>> +#define ct_desc_read(desc_map_, field_) \
>> +iosys_map_rd_field(desc_map_, 0, struct guc_ct_buffer_desc, field_)
>> +#define ct_desc_write(desc_map_, field_, val_) \
>> +iosys_map_wr_field(desc_map_, 0, struct guc_ct_buffer_desc, field_,
>> val_)
>> +
> Did you try to make the change Lucas mentioned in his comment on rev0,
> to pass `struct guc_ct_buffer_desc *` as first argument to the above
> macros? Was it not feasible?
It is not feasible.
>> /**
>> * DOC: CTB Blob
>> *
>> @@ -76,6 +81,11 @@ static inline struct drm_device *ct_to_drm(struct
>> intel_guc_ct *ct)
>> #define CTB_G2H_BUFFER_SIZE (4 * CTB_H2G_BUFFER_SIZE)
>> #define G2H_ROOM_BUFFER_SIZE(CTB_G2H_BUFFER_SIZE / 4)
>>
>> +#define CTB_SEND_DESC_OFFSET0u
>> +#define CTB_RECV_DESC_OFFSET(CTB_DESC_SIZE)
>> +#define CTB_SEND_CMDS_OFFSET(2 * CTB_DESC_SIZE)
>> +#define CTB_RECV_CMDS_OFFSET(2 * CTB_DESC_SIZE +
>> CTB_H2G_BUFFER_SIZE)
>> +
>> struct ct_request {
>> struct list_head link;
>> u32 fence;
>> @@ -113,9 +123,9 @@ void intel_guc_ct_init_early(struct intel_guc_ct *ct)
>> init_waitqueue_head(>wq);
>> }
>>
>> -static void guc_ct_buffer_desc_init(struct guc_ct_buffer_desc *desc)
>> +static void guc_ct_buffer_desc_init(struct iosys_map *desc)
>> {
>> -memset(desc, 0, sizeof(*desc));
>> +iosys_map_memset(desc, 0, 0, sizeof(struct guc_ct_buffer_desc));
>> }
>>
>> static void guc_ct_buffer_reset(struct intel_guc_ct_buffer *ctb)
>> @@ -128,17 +138,18 @@ static void guc_ct_buffer_reset(struct
>> intel_guc_ct_buffer *ctb)
>> space = CIRC_SPACE(ctb->tail, ctb->head, ctb->size) - ctb->resv_space;
>> atomic_set(>space, space);
>>
>> -guc_ct_buffer_desc_init(ctb->desc);
>> +guc_ct_buffer_desc_init(>desc_map);
>> }
>>
>> static void guc_ct_buffer_init(struct intel_guc_ct_buffer *ctb,
>> - struct guc_ct_buffer_desc *desc,
>> - u32 *cmds, u32 size_in_bytes, u32 resv_space)
>> + struct iosys_map *desc,
>> + struct iosys_map *cmds,
>> + u32 size_in_bytes, u32 resv_space)
>> {
>> GEM_BUG_ON(size_in_bytes % 4);
>>
>> -ctb->desc = desc;
>> -ctb->cmds = cmds;
>> +ctb->desc_map = *desc;
>> +ctb->cmds_map = *cmds;
>> ctb->size = size_in_bytes / 4;
>> ctb->resv_space = resv_space / 4;
>>
>> @@ -218,12 +229,13 @@ static int ct_register_buffer(struct intel_guc_ct *ct,
>> bool send,
>> int intel_guc_ct_init(struct intel_guc_ct *ct)
>> {
>> struct intel_guc *guc = ct_to_guc(ct);
>> -struct guc_ct_buffer_desc *desc;
>> +struct iosys_map blob_map;
>> +struct iosys_map desc_map;
>> +struct iosys_map cmds_map;
>> u32 blob_size;
>> u32 cmds_size;
>> u32 resv_space;
>> void *blob;
>> -u32 *cmds;
>> int err;
>>
>> err = i915_inject_probe_error(guc_to_gt(guc)->i915, -ENXIO);
>> @@ -242,27 +254,35 @@ int intel_guc_ct_init(struct intel_guc_ct *ct)
>>
>> CT_DEBUG(ct, "base=%#x size=%u\n", intel_guc_ggtt_offset(guc, ct->vma),
>> blob_size);
>>
>> -/* store pointers to desc and cmds for send ctb */
>> -desc = blob;
>> -cmds = blob + 2 * CTB_DESC_SIZE;
>> +if (i915_gem_object_is_lmem(ct->vma->obj))
>> +iosys_map_set_vaddr_iomem(_map,
>> + (void __iomem *)blob);
>> +else
>> +iosys_map_set_vaddr(_map, blob);
>> +
>> +/* store sysmap to desc_map and cmds_map for send ctb */
>> +desc_map = IOSYS_MAP_INIT_OFFSET(_map, CTB_SEND_DESC_OFFSET);
>> +cmds_map = IOSYS_MAP_INIT_OFFSET(_map, CTB_SEND_CMDS_OFFSET);
>> cmds_size = CTB_H2G_BUFFER_SIZE;
>> resv_space = 0;
>> -CT_DEBUG(ct, "%s desc %#tx cmds %#tx size %u/%u\n", "send",
>> - ptrdiff(desc, blob),
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/xehp: Add compute engine ABI
Hi Matt, On Wed, Apr 27, 2022 at 09:19:25PM -0700, Matt Roper wrote: > We're now ready to start exposing compute engines to userspace. > > v2: > - Move kerneldoc for other engine classes to a separate patch. (Andi) > > Cc: Daniele Ceraolo Spurio > Cc: Tvrtko Ursulin > Cc: Vinay Belgaumkar > Cc: Jordan Justen > Cc: Szymon Morek > UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14395 > Signed-off-by: Matt Roper looks good, Reviewed-by: Andi Shyti Thanks, Andi
Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/uapi: Add kerneldoc for engine class enum
Hi Matt, On Wed, Apr 27, 2022 at 09:19:23PM -0700, Matt Roper wrote: > We'll be adding a new type of engine soon. Let's document the existing > engine classes first to help make it clear what each type of engine is > used for. > > Cc: Andi Shyti > Signed-off-by: Matt Roper Reviewed-by: Andi Shyti Thank you for splitting this patch, Andi
Re: [Intel-gfx] [RFC v2 1/2] drm/doc/rfc: VM_BIND feature design document
On Wed, Apr 27, 2022 at 08:41:35AM -0700, Niranjana Vishwanathapura wrote: > On Wed, Apr 20, 2022 at 03:45:25PM -0700, Niranjana Vishwanathapura wrote: > > On Thu, Mar 31, 2022 at 10:28:48AM +0200, Daniel Vetter wrote: > > > Adding a pile of people who've expressed interest in vm_bind for their > > > drivers. > > > > > > Also note to the intel folks: This is largely written with me having my > > > subsystem co-maintainer hat on, i.e. what I think is the right thing to do > > > here for the subsystem at large. There is substantial rework involved > > > here, but it's not any different from i915 adopting ttm or i915 adpoting > > > drm/sched, and I do think this stuff needs to happen in one form or > > > another. > > > > > > On Mon, Mar 07, 2022 at 12:31:45PM -0800, Niranjana Vishwanathapura wrote: > > > > VM_BIND design document with description of intended use cases. > > > > > > > > Signed-off-by: Niranjana Vishwanathapura > > > > > > > > --- > > > > Documentation/gpu/rfc/i915_vm_bind.rst | 210 + > > > > Documentation/gpu/rfc/index.rst| 4 + > > > > 2 files changed, 214 insertions(+) > > > > create mode 100644 Documentation/gpu/rfc/i915_vm_bind.rst > > > > > > > > diff --git a/Documentation/gpu/rfc/i915_vm_bind.rst > > > > b/Documentation/gpu/rfc/i915_vm_bind.rst > > > > new file mode 100644 > > > > index ..cdc6bb25b942 > > > > --- /dev/null > > > > +++ b/Documentation/gpu/rfc/i915_vm_bind.rst > > > > @@ -0,0 +1,210 @@ > > > > +== > > > > +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) 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 ioctl deferes binding the mappings until next execbuff > > > > submission > > > > +where it will be required, or immediately if I915_GEM_VM_BIND_IMMEDIATE > > > > +flag is set (useful if mapping is required for an active context). > > > > > > So this is a screw-up I've done, and for upstream I think we need to fix > > > it: Implicit sync is bad, and it's also still a bad idea for vm_bind, and > > > I was wrong suggesting we should do this a few years back when we kicked > > > this off internally :-( > > > > > > What I think we need is just always VM_BIND_IMMEDIATE mode, and then a few > > > things on top: > > > - in and out fences, like with execbuf, to allow userspace to sync with > > > execbuf as needed > > > - for compute-mode context this means userspace memory fences > > > - for legacy context this means a timeline syncobj in drm_syncobj > > > > > > No sync_file or anything else like this at all. This means a bunch of > > > work, but also it'll have benefits because it means we should be able to > > > use exactly the same code paths and logic for both compute and for legacy > > > context, because drm_syncobj support future fence semantics. > > > > > > > Thanks Daniel, > > Ok, will update > > > > I had a long conversation with Daniel on some of the points discussed here. > Thanks to Daniel for clarifying many points here. > > Here is the summary of the discussion. > > 1) A prep patch is needed to update documentation of some existing uapi and > this > new VM_BIND uapi can update/refer to that. > I will include this prep patch in the next revision of this RFC series. > Will also include the uapi header file in the rst file so that it gets > rendered. > > 2) Will update documentation here with proper use of dma_resv_usage while > adding > fences to vm_bind objects. It is going to be, DMA_RESV_USAGE_BOOKKEEP by > default > if not override with execlist in execbuff path. > > 3) Add extension to execbuff ioctl to specify batch buffer as GPU virtual > address > instead of having to pass it as a BO handle in execlist. This will also > make the > execlist usage solely for implicit sync setting which is further discussed > below. > > 4) Need to look into when will Jason's dma-buf fence import/export ioctl > support will > land and whether it will be used both for vl and gl. Need to sync with > Jason on this. > Probably the better option here would be to not support execlist in > execbuff path in > vm_bind mode for initial vm_bind support (hoping Jason's dma-buf fence > import/export > ioctl will be enough). We can add support for execlist in execbuff for > vm_bind mode > later if required (say for gl). So I'm again less
Re: [Intel-gfx] [PATCH 5/5] drm/i915/sseu: Disassociate internal subslice mask representation from uapi
Hi,
On 28/04/2022 00:07, Matt Roper wrote:
Rather than storing subslice masks internally as u8[] (inside the sseu
structure) and u32 (everywhere else), let's move over to using an
intel_sseu_ss_mask_t typedef compatible with the operations in
linux/bitmap.h. We're soon going to start adding code for a new
platform where subslice masks are spread across two 32-bit registers
(requiring 64 bits to represent), and we expect future platforms will
likely take this even farther, requiring bitmask storage larger than a
simple u64 can hold.
I won't have time to look into this in a detailed way for a few days. Until
then a couple questions comments only.
First, out of curiousity, were you able to end up with less code after your
series? With my bitmap conversion I think actually ended up with couple KB
smaller text which was a good sign eliminating the internal layout
complications was a good approach.
For your series I am not convinced by sseu->has_common_ss_eumask. Why the
duality, just to save a few u32 at runtime?
I am also not convinced with leaving the eu_mask and subslice_mask being
manually indexed with stride, calculcated by the driver. In my approach I
simply went with multi-dimensional arrays which I think ends up with simpler
code.
For all bitmap API call sites and *pb printk format sites, I suggest not
hard-coding the widths from SSEU defines by querying the type itsef via
wrappers. (See my BITMAP_BITS macro and helpers which wrap it for fields.)
Ie instead:
bitmap_shift_left(to_mask->b, to_mask->b, offset, I915_MAX_SS_FUSE_BITS);
I suggest:
bitmap_zero(slices.b, BITMAP_BITS(slices.b));
Also, all accesses to the bitmap type from outside intel_sse*.c|h should use
intel_sseu wrappers and not embed knowledge of the typedef (that it has an
member named .b etc).
And finally I would also use the opportunity to clean up the pointless u8 types
for counts and such since I think they just result in worse code generation.
You can of course counter with what you did not like in my attempt. :) I know I
did not finish the wrappers and possibly made an overkill by converting the
slice mask to bitmap.
Regards,
Tvrtko
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
drivers/gpu/drm/i915/gt/intel_gt.c | 14 +-
drivers/gpu/drm/i915/gt/intel_sseu.c | 197 +++
drivers/gpu/drm/i915/gt/intel_sseu.h | 48 ++---
drivers/gpu/drm/i915/gt/intel_sseu_debugfs.c | 28 +--
drivers/gpu/drm/i915/gt/intel_workarounds.c | 28 ++-
drivers/gpu/drm/i915/i915_getparam.c | 2 +-
drivers/gpu/drm/i915/i915_query.c| 8 +-
9 files changed, 183 insertions(+), 148 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..ea012ee3a8de 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -1901,7 +1901,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 & ~device->subslice_mask.b[0])
return -EINVAL;
if (user->max_eus_per_subslice > device->max_eus_per_subslice)
@@ -1915,7 +1915,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(device->subslice_mask.b[0]);
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 14c6ddbbfde8..39c09963b3c7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -610,7 +610,7 @@ 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),
+ ccs_mask =
intel_slicemask_from_dssmask(info->sseu.compute_subslice_mask,
ss_per_ccs);
/*
* If all DSS in a quadrant are fused off, the corresponding CCS
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 92394f13b42f..cc03512d59ba 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
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/xehp: Add register for compute engine's MMIO-based TLB invalidation
On Wed, Apr 27, 2022 at 09:19:24PM -0700, Matt Roper wrote: > Compute engines have a separate register that the driver should use to > perform MMIO-based TLB invalidation. > > Note that the term "context" in this register's bspec description is > used to refer to the engine instance (in the same way "context" is used > on bspec 46167). > > Bspec: 43930 > Cc: Prathap Kumar Valsan > Cc: Tvrtko Ursulin > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/gt/intel_gt.c | 1 + > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + > 2 files changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c > b/drivers/gpu/drm/i915/gt/intel_gt.c > index 92394f13b42f..53307ca0eed0 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt.c > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c > @@ -1175,6 +1175,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt) > [VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR, > [VIDEO_ENHANCEMENT_CLASS] = GEN12_VE_TLB_INV_CR, > [COPY_ENGINE_CLASS] = GEN12_BLT_TLB_INV_CR, > + [COMPUTE_CLASS] = GEN12_COMPCTX_TLB_INV_CR, > }; > struct drm_i915_private *i915 = gt->i915; > struct intel_uncore *uncore = gt->uncore; > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > index a39718a40cc3..a0a49c16babd 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h > @@ -1007,6 +1007,7 @@ > #define GEN12_VD_TLB_INV_CR _MMIO(0xcedc) > #define GEN12_VE_TLB_INV_CR _MMIO(0xcee0) > #define GEN12_BLT_TLB_INV_CR _MMIO(0xcee4) > +#define GEN12_COMPCTX_TLB_INV_CR _MMIO(0xcf04) > > #define GEN12_MERT_MOD_CTRL _MMIO(0xcf28) > #define RENDER_MOD_CTRL _MMIO(0xcf2c) Reviewed-by: Prathap Kumar Valsan > -- > 2.35.1 >
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
On Thu, Apr 28, 2022 at 10:08:47AM +0200, Maxime Ripard wrote:
> Hi Daniel,
>
> On Wed, Apr 13, 2022 at 01:20:11PM +0200, Daniel Vetter wrote:
> > On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar
> > wrote:
> > > On 4/8/2022 9:04 PM, Abhinav Kumar wrote:
> > > >
> > > >
> > > > On 4/7/2022 4:12 PM, Rob Clark wrote:
> > > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar
> > > >> wrote:
> > > >>>
> > > >>> Hi Rob and Daniel
> > > >>>
> > > >>> On 4/7/2022 3:51 PM, Rob Clark wrote:
> > > On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang
> > > wrote:
> > > >
> > > >
> > > >
> > > > On 3/31/2022 8:20 AM, Daniel Vetter wrote:
> > > >> The stuff never really worked, and leads to lots of fun because it
> > > >> out-of-order frees atomic states. Which upsets KASAN, among other
> > > >> things.
> > > >>
> > > >> For async updates we now have a more solid solution with the
> > > >> ->atomic_async_check and ->atomic_async_commit hooks. Support for
> > > >> that
> > > >> for msm and vc4 landed. nouveau and i915 have their own commit
> > > >> routines, doing something similar.
> > > >>
> > > >> For everyone else it's probably better to remove the use-after-free
> > > >> bug, and encourage folks to use the async support instead. The
> > > >> affected drivers which register a legacy cursor plane and don't
> > > >> either
> > > >> use the new async stuff or their own commit routine are: amdgpu,
> > > >> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and
> > > >> vmwgfx.
> > > >>
> > > >> Inspired by an amdgpu bug report.
> > > >>
> > > >> v2: Drop RFC, I think with amdgpu converted over to use
> > > >> atomic_async_check/commit done in
> > > >>
> > > >> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
> > > >> Author: Nicholas Kazlauskas
> > > >> Date: Wed Dec 5 14:59:07 2018 -0500
> > > >>
> > > >>drm/amd/display: Add fast path for cursor plane updates
> > > >>
> > > >> we don't have any driver anymore where we have userspace expecting
> > > >> solid legacy cursor support _and_ they are using the atomic
> > > >> helpers in
> > > >> their fully glory. So we can retire this.
> > > >>
> > > >> v3: Paper over msm and i915 regression. The complete_all is the
> > > >> only
> > > >> thing missing afaict.
> > > >>
> > > >> v4: Fixup i915 fixup ...
> > > >>
> > > >> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> > > >> References:
> > > >> https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/
> > > >>
> > > >> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> > > >> Cc: Maxime Ripard
> > > >> Tested-by: Maxime Ripard
> > > >> Cc: mikita.lip...@amd.com
> > > >> Cc: Michel Dänzer
> > > >> Cc: harry.wentl...@amd.com
> > > >> Cc: Rob Clark
> > > >
> > > > Hey Rob,
> > > >
> > > > I saw your tested-by and reviewed-by tags on Patchwork. Just
> > > > curious,
> > > > what device did you test on?
> > >
> > > I was testing on strongbad.. v5.18-rc1 + patches (notably, revert
> > > 80253168dbfd ("drm: of: Lookup if child node has panel or bridge")
> > >
> > > I think the display setup shouldn't be significantly different than
> > > limozeen (ie. it's an eDP panel). But I didn't do much start/stop
> > > ui.. I was mostly looking to make sure cursor movements weren't
> > > causing fps drops ;-)
> > >
> > > BR,
> > > -R
> > > >>>
> > > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next.
> > > >>> So we cannot let that break.
> > > >>>
> > > >>> I think we need to check whats causing this splat.
> > > >>>
> > > >>> Can we hold back this change till then?
> > > >>
> > > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a
> > > >> loop of stop ui / start ui and hasn't triggered a splat yet.
> > > >>
> > > >> Otherwise maybe you can addr2line to figure out where it crashed?
> > > >>
> > > >> BR,
> > > >> -R
> > > >
> > > > So this is not a crash. Its a warning splat coming from
> > > >
> > > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785
> > > >
> > > >
> > > > Looks like the complete_commit() which should signal the event has not
> > > > happened before the next cursor commit.
> > > >
> > > > Somehow this change is affecting the flow to miss the event signaling
> > > > that the event is done.
> > > >
> > > > We tried a couple of approaches but couldnt still fix the warning.
> > > >
> > > > Will continue to check further next week.
> > > >
> > > >>
> > > >>> Thanks
> > > >>>
> > > >>> Abhinav
> > >
> > > After checking this more this week, I think the current patch needs to
> > > be changed a bit.
> > >
> > > So, here you are removing the complete_all part and leaving that to
Re: [Intel-gfx] [RFC PATCH 0/3] i915 writeback private framework
Hi Suraj, On Thu, Apr 28, 2022 at 05:51:47AM +, Kandpal, Suraj wrote: > ++Laurent ,Dmitry, and Abhinav > > Hi, > Can you have a look at the private implementation i915 is currently going > with till > we can figure out how to work with drm core . No, sorry, I barely have time to follow up on core DRM changes, I can't help with private i915 topics in my spare time. > > A patch series was floated in the drm mailing list which aimed to change the > > drm_connector and drm_encoder fields to pointer in the > > drm_connector_writeback structure, this received a huge pushback from the > > community but since i915 expects each connector present in the drm_device > > list to be a intel_connector but drm_writeback framework. > > [1] https://patchwork.kernel.org/project/dri- > > devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ > > [2] https://patchwork.kernel.org/project/dri- > > devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ > > This forces us to use a drm_connector which is not embedded in > > intel_connector the current drm_writeback framework becomes very > > unfeasible to us as it would mean a lot of checks at a lot of places to > > take into > > account the above issue.Since no one had an issue with encoder field being > > changed into a pointer it was decided to break the connector and encoder > > pointer changes into two different series.The encoder field changes is > > currently being worked upon by Abhinav Kumar > > [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 > > In the meantime for i915 to start using the writeback functionality we came > > up with a interim solution to own writeback pipeline bypassing one provided > > by drm which is what these patches do. > > Note: these are temp patches till we figure out how we can either change > > drm core writeback to work with our intel_connector structure or find a > > different solution which allows us to work with the current drm_writeback > > framework > > > > Suraj Kandpal (3): > > drm/i915: Creating writeback pipeline to bypass drm_writeback > > framework > > drm/i915: Define WD trancoder for i915 > > drm/i915: Enabling WD Transcoder > > > > drivers/gpu/drm/i915/Makefile | 2 + > > drivers/gpu/drm/i915/display/intel_acpi.c | 1 + > > drivers/gpu/drm/i915/display/intel_display.c | 89 +- > > drivers/gpu/drm/i915/display/intel_display.h | 15 + > > .../drm/i915/display/intel_display_types.h| 18 + > > drivers/gpu/drm/i915/display/intel_dpll.c | 3 + > > drivers/gpu/drm/i915/display/intel_opregion.c | 3 + > > .../gpu/drm/i915/display/intel_wb_connector.c | 296 ++ > > .../gpu/drm/i915/display/intel_wb_connector.h | 99 ++ > > drivers/gpu/drm/i915/display/intel_wd.c | 978 ++ > > drivers/gpu/drm/i915/display/intel_wd.h | 82 ++ > > drivers/gpu/drm/i915/i915_drv.h | 5 + > > drivers/gpu/drm/i915/i915_irq.c | 8 +- > > drivers/gpu/drm/i915/i915_pci.c | 7 +- > > drivers/gpu/drm/i915/i915_reg.h | 139 +++ > > 15 files changed, 1742 insertions(+), 3 deletions(-) create mode 100644 > > drivers/gpu/drm/i915/display/intel_wb_connector.c > > create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h > > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.c > > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h -- Regards, Laurent Pinchart
Re: [Intel-gfx] [RFC v2 1/2] drm/vrr: Attach vrr_enabled property to the drm crtc
On Wed-27-04-2022 03:31 am, Navare, Manasi wrote:
On Mon, Apr 25, 2022 at 12:16:11PM +0530, Bhanuprakash Modem wrote:
Modern display hardware is capable of supporting variable refresh rates.
This patch introduces helpers to attach and set "vrr_enabled" property
on the crtc to allow userspace to query VRR enabled status on that crtc.
Atomic drivers should attach this property to crtcs those are capable of
driving variable refresh rates using
drm_mode_crtc_attach_vrr_enabled_property().
The value should be updated based on driver and hardware capability
by using drm_mode_crtc_set_vrr_enabled_property().
V2: Use property flag as atomic
We already have userspace making us of the CRTC vrr_enabled property to
enable VRR for the CRTC like in case of full screen gaming.
This can already be done through:
drm_atomic_crtc_set_property call. Why do we need additonal helpers
for setting the same per CRTC property?
Thanks for the Review, Manasi.
Yeah, I just realized that we are attaching "vrr_enabled" as part of
crtc_init()
drm_crtc_init_with_planes() --> __drm_crtc_init_with_planes() -->
drm_object_attach_property(vrr_enabled);
I'll drop the drm_mode_crtc_attach_vrr_enabled_property() helper.
This is a default CRTC property so it will be created annd attached for
CRTC as per the DRM doc:
"VRR_ENABLED":
* Default _crtc boolean property that notifies the driver that the
* content on the CRTC is suitable for variable refresh rate presentation.
* The driver will take this property as a hint to enable variable
* refresh rate support if the receiver supports it, ie. if the
* "vrr_capable" property is true on the _connector object. The
* vertical front porch duration will be extended until page-flip or
* timeout when enabled.
Then we can use the atomic_crtc_set/get_property helpers to set it
Am I missing some other use case here?
My intention is to set/clear "VRR_ENABLED" prop based on the driver and
hardware capabilities. And user can request anytime to get the status of
VRR on that CRTC.
Example:
Consider we have an Non-VRR panel is connected, but driver supports VRR
(hence vrr_capable = 0)
* Request from user-space to enable the VRR on CRTC.
* Driver should take the decision to set/clear the "VRR_ENABLED".
* Request from use-space to read back the "VRR_ENABLED". It must be 0,
since "vrr_capable" is 0.
Without this series, in above scenario I am getting "VRR_ENABLED" as 1
which is not true.
IGT to validate the same: https://patchwork.freedesktop.org/series/100539/
I think, still we need a helper to set/clear the prop
drm_mode_crtc_set_vrr_enabled_property(). I am not sure that we can use
atomic_crtc_set/get_property helpers here, as these helpers are used by
atomic_ioctls only.
- Bhanu
Manasi
Cc: Ville Syrjälä
Cc: Nicholas Kazlauskas
Cc: Manasi Navare
Cc: Harry Wentland
Signed-off-by: Bhanuprakash Modem
---
drivers/gpu/drm/drm_crtc.c| 44 +++
drivers/gpu/drm/drm_mode_config.c | 2 +-
include/drm/drm_crtc.h| 4 +++
3 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 26a77a735905..95b4a0c7ecb3 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -883,3 +883,47 @@ int drm_crtc_create_scaling_filter_property(struct
drm_crtc *crtc,
return 0;
}
EXPORT_SYMBOL(drm_crtc_create_scaling_filter_property);
+
+/**
+ * drm_mode_crtc_attach_vrr_enabled_property - attaches the vrr_enabled
property
+ * @crtc: drm CRTC to attach the vrr_enabled property on.
+ *
+ * This is used by atomic drivers to add support for querying
+ * VRR enabled status for a crtc.
+ */
+void drm_mode_crtc_attach_vrr_enabled_property(struct drm_crtc *crtc)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = >mode_config;
+
+ if (!config->prop_vrr_enabled)
+ return;
+
+ drm_object_attach_property(>base,
+ config->prop_vrr_enabled,
+ 0);
+}
+EXPORT_SYMBOL(drm_mode_crtc_attach_vrr_enabled_property);
+
+/**
+ * drm_mode_crtc_set_vrr_enabled_property - sets the vrr enabled property for
+ * a crtc.
+ * @crtc: drm CRTC
+ * @vrr_enabled: True to enable the VRR on CRTC
+ *
+ * Should be used by atomic drivers to update the VRR enabled status on a CRTC
+ */
+void drm_mode_crtc_set_vrr_enabled_property(struct drm_crtc *crtc,
+ bool vrr_enabled)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_mode_config *config = >mode_config;
+
+ if (!config->prop_vrr_enabled)
+ return;
+
+ drm_object_property_set_value(>base,
+ config->prop_vrr_enabled,
+ vrr_enabled);
+}
+EXPORT_SYMBOL(drm_mode_crtc_set_vrr_enabled_property);
diff --git
Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi
On 28/04/2022 11:25, Matthew Auld wrote:
On 28/04/2022 09:55, Tvrtko Ursulin wrote:
On 27/04/2022 18:36, Matthew Auld wrote:
On 27/04/2022 09:36, Tvrtko Ursulin wrote:
On 20/04/2022 18:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 190
+++
Documentation/gpu/rfc/i915_small_bar.rst | 58 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 252 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 =
unknown) */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+ __u64 probed_cpu_visible_size;
Would unallocated_cpu_visible_size be useful, to follow the total
unallocated_size?
Make sense. But I don't think unallocated_size has actually been
properly wired up yet. It still just gives the same value as
probed_size. IIRC for unallocated_size we still need a real
user/usecase/umd, before wiring that up for real with the existing
avail tracking. Once we have that we can also add
unallocated_cpu_visible_size.
So this does nothing at the moment:
info.unallocated_size = mr->avail;
Right, it is set to "mem->avail = mem->total;" at region init time and
I indeed can't find it ever getting modified. Okay.
Btw, have we ever considered whether unallocated_size should require
CAP_SYS_ADMIN/PERFMON or something?
Note sure. But just in case we do add it for real at some point, why
the added restriction?
To avoid a side channel, albeit perhaps a very weak one. For engine
utilization we require CAP_SYS_PERFMON, but that is implied by the
perf core API. It's open for discussion. I guess it may make sense to
limit it also because it is questionable the field(s) are even useful.
+ };
+ };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create
behaviour, with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for
the stuff that
+ * is immutable. Previously we would have two ioctls, one to
create the object
+ * with gem_create, and another to apply various parameters,
however this
+ * creates some ambiguity for the params which are considered
immutable. Also in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+ /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated size for the object will be
returned.
+ *
+ * Note that for some devices we have might have further minimum
+ * page-size restrictions(larger than 4K), likefor device
local-memory.
+ * However in general the final size here should always
reflect any
+ * rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+ * extension to place the object in device local-memory.
+ */
+ __u64 size;
+ /**
+ * @handle: Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+ /**
+ * @flags: Optional flags.
+ *
+ * Supported values:
+ *
+ * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS -
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency()
== Series Details == Series: drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency() URL : https://patchwork.freedesktop.org/series/103260/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103260v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103260v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103260v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 12) -- Additional (2): shard-rkl shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_103260v1_full: ### IGT changes ### Possible regressions * igt@kms_flip@flip-vs-suspend-interruptible@a-edp1: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/igt@kms_flip@flip-vs-suspend-interrupti...@a-edp1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/shard-skl10/igt@kms_flip@flip-vs-suspend-interrupti...@a-edp1.html Warnings * igt@gem_eio@kms: - shard-tglb: [FAIL][3] ([i915#232]) -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb3/igt@gem_...@kms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/shard-tglb1/igt@gem_...@kms.html ### Piglit changes ### Possible regressions * spec@glsl-4.30@execution@built-in-functions@cs-op-uplus-mat4x3 (NEW): - pig-kbl-iris: NOTRUN -> [CRASH][5] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/pig-kbl-iris/spec@glsl-4.30@execution@built-in-functi...@cs-op-uplus-mat4x3.html New tests - New tests have been introduced between CI_DRM_11550_full and Patchwork_103260v1_full: ### New Piglit tests (1) ### * spec@glsl-4.30@execution@built-in-functions@cs-op-uplus-mat4x3: - Statuses : 1 crash(s) - Exec time: [1.14] s Known issues Here are the changes found in Patchwork_103260v1_full that come from known issues: ### CI changes ### Possible fixes * boot: - shard-skl: ([PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [FAIL][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29]) ([i915#5032]) -> ([PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html [29]:
Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi
On 28/04/2022 09:55, Tvrtko Ursulin wrote:
On 27/04/2022 18:36, Matthew Auld wrote:
On 27/04/2022 09:36, Tvrtko Ursulin wrote:
On 20/04/2022 18:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 190
+++
Documentation/gpu/rfc/i915_small_bar.rst | 58 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 252 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 =
unknown) */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+ __u64 probed_cpu_visible_size;
Would unallocated_cpu_visible_size be useful, to follow the total
unallocated_size?
Make sense. But I don't think unallocated_size has actually been
properly wired up yet. It still just gives the same value as
probed_size. IIRC for unallocated_size we still need a real
user/usecase/umd, before wiring that up for real with the existing
avail tracking. Once we have that we can also add
unallocated_cpu_visible_size.
So this does nothing at the moment:
info.unallocated_size = mr->avail;
Right, it is set to "mem->avail = mem->total;" at region init time and I
indeed can't find it ever getting modified. Okay.
Btw, have we ever considered whether unallocated_size should require
CAP_SYS_ADMIN/PERFMON or something?
Note sure. But just in case we do add it for real at some point, why
the added restriction?
To avoid a side channel, albeit perhaps a very weak one. For engine
utilization we require CAP_SYS_PERFMON, but that is implied by the perf
core API. It's open for discussion. I guess it may make sense to limit
it also because it is questionable the field(s) are even useful.
+ };
+ };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create
behaviour, with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for
the stuff that
+ * is immutable. Previously we would have two ioctls, one to create
the object
+ * with gem_create, and another to apply various parameters,
however this
+ * creates some ambiguity for the params which are considered
immutable. Also in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+ /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated size for the object will be
returned.
+ *
+ * Note that for some devices we have might have further minimum
+ * page-size restrictions(larger than 4K), likefor device
local-memory.
+ * However in general the final size here should always reflect
any
+ * rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+ * extension to place the object in device local-memory.
+ */
+ __u64 size;
+ /**
+ * @handle: Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+ /**
+ * @flags: Optional flags.
+ *
+ * Supported values:
+ *
+ * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the
kernel that
+ * the object
Re: [Intel-gfx] [RFC PATCH 1/3] drm/i915: Creating writeback pipeline to bypass drm_writeback framework
++Laurent ,Dmitry, and Abhinav
> Changes to create a i915 private pipeline to enable the WD transcoder
> without relying on the current drm_writeback framework.
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../drm/i915/display/intel_display_types.h| 4 +
> .../gpu/drm/i915/display/intel_wb_connector.c | 296
> ++ .../gpu/drm/i915/display/intel_wb_connector.h |
> 99 ++
> drivers/gpu/drm/i915/i915_drv.h | 3 +
> 5 files changed, 403 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_wb_connector.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 1a771ee5b1d0..087bd9d1b397 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -286,6 +286,7 @@ i915-y += \
> display/intel_tv.o \
> display/intel_vdsc.o \
> display/intel_vrr.o \
> + display/intel_wb_connector.o\
> display/vlv_dsi.o \
> display/vlv_dsi_pll.o
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index d84e82f3eab9..7a96ecba73c0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -52,6 +52,7 @@
> #include "intel_display_power.h"
> #include "intel_dpll_mgr.h"
> #include "intel_pm_types.h"
> +#include "intel_wb_connector.h"
>
> struct drm_printer;
> struct __intel_global_objs_state;
> @@ -537,11 +538,14 @@ struct intel_connector {
> struct work_struct modeset_retry_work;
>
> struct intel_hdcp hdcp;
> +
> + struct intel_writeback_connector wb_conn;
> };
>
> struct intel_digital_connector_state {
> struct drm_connector_state base;
>
> + struct intel_writeback_job *job;
> enum hdmi_force_audio force_audio;
> int broadcast_rgb;
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_wb_connector.c
> b/drivers/gpu/drm/i915/display/intel_wb_connector.c
> new file mode 100644
> index ..65f4abef53d0
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_wb_connector.c
> @@ -0,0 +1,296 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright © 2022 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person
> +obtaining a
> + * copy of this software and associated documentation files (the
> +"Software"),
> + * to deal in the Software without restriction, including without
> +limitation
> + * the rights to use, copy, modify, merge, publish, distribute,
> +sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom
> +the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the
> +next
> + * paragraph) shall be included in all copies or substantial portions
> +of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> +EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> +MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO
> EVENT
> +SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,
> DAMAGES OR
> +OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> +ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> OTHER
> +DEALINGS
> + * IN THE SOFTWARE.
> + *
> + * Authors:
> + * Suraj Kandpal
> + * Arun Murthy
> + *
> + */
> +
> +
> +#include
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "i915_drv.h"
> +#include "intel_wb_connector.h"
> +#include "intel_display_types.h"
> +
> +#define fence_to_wb_connector(x) container_of(x->lock, \
> + struct intel_writeback_connector,
> \
> + fence_lock)
> +
> +static const char *intel_writeback_fence_get_driver_name(struct
> +dma_fence *fence) {
> + struct intel_writeback_connector *wb_connector =
> + fence_to_wb_connector(fence);
> +
> + return wb_connector->base->dev->driver->name;
> +}
> +
> +static const char *
> +intel_writeback_fence_get_timeline_name(struct dma_fence *fence) {
> + struct intel_writeback_connector *wb_connector =
> + fence_to_wb_connector(fence);
> +
> + return wb_connector->timeline_name;
> +}
> +
> +static bool intel_writeback_fence_enable_signaling(struct dma_fence
> +*fence) {
> + return true;
> +}
> +
> +static const struct dma_fence_ops intel_writeback_fence_ops = {
> + .get_driver_name = intel_writeback_fence_get_driver_name,
> + .get_timeline_name = intel_writeback_fence_get_timeline_name,
> + .enable_signaling = intel_writeback_fence_enable_signaling,
> +};
> +
> +static int
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency()
== Series Details ==
Series: drm/i915: Fix -Wstringop-overflow warning in call to
intel_read_wm_latency()
URL : https://patchwork.freedesktop.org/series/103260/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103260v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/index.html
Participating hosts (43 -> 43)
--
Additional (4): bat-dg2-8 bat-adlm-1 bat-dg1-6 bat-adlp-4
Missing(4): fi-bsw-cyan bat-rpls-1 bat-rpls-2 bat-jsl-2
Known issues
Here are the changes found in Patchwork_103260v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s0@smem:
- bat-dg1-6: NOTRUN -> [INCOMPLETE][1] ([i915#5827])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-dg1-6/igt@gem_exec_suspend@basic...@smem.html
* igt@gem_lmem_swapping@basic:
- bat-adlp-4: NOTRUN -> [SKIP][2] ([i915#4613]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-4/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- bat-adlp-4: NOTRUN -> [SKIP][3] ([i915#3282])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-4/igt@gem_tiled_pread_basic.html
* igt@kms_chamelium@dp-crc-fast:
- bat-adlp-4: NOTRUN -> [SKIP][4] ([fdo#111827]) +8 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-4/igt@kms_chamel...@dp-crc-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy:
- bat-adlp-4: NOTRUN -> [SKIP][5] ([i915#4103]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-4/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html
* igt@kms_flip@basic-plain-flip@a-edp1:
- bat-adlp-4: NOTRUN -> [DMESG-WARN][6] ([i915#3576]) +2 similar
issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-4/igt@kms_flip@basic-plain-f...@a-edp1.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-kbl-guc: NOTRUN -> [SKIP][7] ([fdo#109271])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/fi-kbl-guc/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_force_connector_basic@prune-stale-modes:
- bat-adlp-4: NOTRUN -> [SKIP][8] ([i915#4093]) +3 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-4/igt@kms_force_connector_ba...@prune-stale-modes.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-b:
- fi-cfl-8109u: [PASS][9] -> [DMESG-WARN][10] ([i915#62]) +12 similar
issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/fi-cfl-8109u/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-b.html
* igt@kms_setmode@basic-clone-single-crtc:
- bat-adlp-4: NOTRUN -> [SKIP][11] ([i915#3555])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-4/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-fence-read:
- bat-adlp-4: NOTRUN -> [SKIP][12] ([i915#3291] / [i915#3708]) +2
similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-4/igt@prime_v...@basic-fence-read.html
* igt@prime_vgem@basic-userptr:
- bat-adlp-4: NOTRUN -> [SKIP][13] ([i915#3301] / [i915#3708])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-4/igt@prime_v...@basic-userptr.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-cfl-guc: [DMESG-FAIL][14] ([i915#5334]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/fi-cfl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][16] ([i915#3921]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_busy@basic@flip:
- {bat-adlp-6}: [DMESG-WARN][18] ([i915#3576]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/bat-adlp-6/igt@kms_busy@ba...@flip.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103260v1/bat-adlp-6/igt@kms_busy@ba...@flip.html
Warnings
* igt@gem_exec_suspend@basic-s3@smem:
- fi-rkl-11600:
[Intel-gfx] ✗ Fi.CI.BUILD: failure for i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers
== Series Details == Series: i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers URL : https://patchwork.freedesktop.org/series/103261/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/103261/revisions/1/mbox/ not applied Applying: i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gvt/handlers.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/gvt/handlers.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/gvt/handlers.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency()
== Series Details == Series: drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency() URL : https://patchwork.freedesktop.org/series/103260/ State : warning == Summary == Error: dim checkpatch failed bb6f50272286 drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency() -:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #17: 2861 | static void intel_read_wm_latency(struct drm_i915_private *dev_priv, total: 0 errors, 1 warnings, 0 checks, 8 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for Replace shmem memory region and object backend with TTM
== Series Details == Series: Replace shmem memory region and object backend with TTM URL : https://patchwork.freedesktop.org/series/103259/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103259v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_103259v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_103259v1, 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_103259v1/index.html Participating hosts (43 -> 43) -- Additional (4): bat-dg2-8 bat-adls-5 bat-dg1-6 bat-adlp-4 Missing(4): fi-bsw-cyan fi-rkl-11600 bat-jsl-2 fi-ilk-650 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_103259v1: ### IGT changes ### Possible regressions * igt@gem_close_race@basic-process: - fi-elk-e7500: [PASS][1] -> [FAIL][2] +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-elk-e7500/igt@gem_close_r...@basic-process.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-elk-e7500/igt@gem_close_r...@basic-process.html * igt@gem_close_race@basic-threads: - fi-bwr-2160:[PASS][3] -> [FAIL][4] +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bwr-2160/igt@gem_close_r...@basic-threads.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-bwr-2160/igt@gem_close_r...@basic-threads.html * igt@gem_exec_create@basic@smem: - fi-blb-e6850: [PASS][5] -> [FAIL][6] +15 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-blb-e6850/igt@gem_exec_create@ba...@smem.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-blb-e6850/igt@gem_exec_create@ba...@smem.html * igt@gem_render_tiled_blits@basic: - fi-bsw-nick:[PASS][7] -> [CRASH][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-nick/igt@gem_render_tiled_bl...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-bsw-nick/igt@gem_render_tiled_bl...@basic.html - fi-bwr-2160:[PASS][9] -> [DMESG-FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bwr-2160/igt@gem_render_tiled_bl...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-bwr-2160/igt@gem_render_tiled_bl...@basic.html * igt@gem_sync@basic-each: - fi-pnv-d510:[PASS][11] -> [FAIL][12] +11 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-pnv-d510/igt@gem_s...@basic-each.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-pnv-d510/igt@gem_s...@basic-each.html * igt@gem_tiled_fence_blits@basic: - fi-bxt-dsi: [PASS][13] -> [CRASH][14] +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bxt-dsi/igt@gem_tiled_fence_bl...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-bxt-dsi/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - fi-bsw-n3050: [PASS][15] -> [FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-n3050/igt@gem_tiled_pread_basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-bsw-n3050/igt@gem_tiled_pread_basic.html - fi-bxt-dsi: [PASS][17] -> [FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bxt-dsi/igt@gem_tiled_pread_basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-bxt-dsi/igt@gem_tiled_pread_basic.html - fi-bsw-nick:[PASS][19] -> [FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-nick/igt@gem_tiled_pread_basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-bsw-nick/igt@gem_tiled_pread_basic.html - fi-glk-j4005: [PASS][21] -> [FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-glk-j4005/igt@gem_tiled_pread_basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-glk-j4005/igt@gem_tiled_pread_basic.html - fi-bsw-kefka: [PASS][23] -> [FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-kefka/igt@gem_tiled_pread_basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103259v1/fi-bsw-kefka/igt@gem_tiled_pread_basic.html * igt@i915_selftest@live@mman: - fi-bsw-kefka: [PASS][25] -> [DMESG-FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/fi-bsw-kefka/igt@i915_selftest@l...@mman.html
Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi
On 27/04/2022 18:36, Matthew Auld wrote:
On 27/04/2022 09:36, Tvrtko Ursulin wrote:
On 20/04/2022 18:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 190 +++
Documentation/gpu/rfc/i915_small_bar.rst | 58 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 252 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 =
unknown) */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+ __u64 probed_cpu_visible_size;
Would unallocated_cpu_visible_size be useful, to follow the total
unallocated_size?
Make sense. But I don't think unallocated_size has actually been
properly wired up yet. It still just gives the same value as
probed_size. IIRC for unallocated_size we still need a real
user/usecase/umd, before wiring that up for real with the existing avail
tracking. Once we have that we can also add unallocated_cpu_visible_size.
So this does nothing at the moment:
info.unallocated_size = mr->avail;
Right, it is set to "mem->avail = mem->total;" at region init time and I
indeed can't find it ever getting modified. Okay.
Btw, have we ever considered whether unallocated_size should require
CAP_SYS_ADMIN/PERFMON or something?
Note sure. But just in case we do add it for real at some point, why the
added restriction?
To avoid a side channel, albeit perhaps a very weak one. For engine
utilization we require CAP_SYS_PERFMON, but that is implied by the perf
core API. It's open for discussion. I guess it may make sense to limit
it also because it is questionable the field(s) are even useful.
+ };
+ };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create behaviour,
with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for the
stuff that
+ * is immutable. Previously we would have two ioctls, one to create
the object
+ * with gem_create, and another to apply various parameters, however
this
+ * creates some ambiguity for the params which are considered
immutable. Also in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+ /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated size for the object will be
returned.
+ *
+ * Note that for some devices we have might have further minimum
+ * page-size restrictions(larger than 4K), likefor device
local-memory.
+ * However in general the final size here should always reflect any
+ * rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+ * extension to place the object in device local-memory.
+ */
+ __u64 size;
+ /**
+ * @handle: Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+ /**
+ * @flags: Optional flags.
+ *
+ * Supported values:
+ *
+ * I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS - Signal to the
kernel that
+ * the object will need to be accessed via the CPU.
+ *
+
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Replace shmem memory region and object backend with TTM
== Series Details ==
Series: Replace shmem memory region and object backend with TTM
URL : https://patchwork.freedesktop.org/series/103259/
State : warning
== Summary ==
Error: dim checkpatch failed
d619a74d74ea drm/i915: Replace shmem memory region and object backend with TTM
-:37: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"obj->base.import_attach"
#37: FILE: drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:101:
+ GEM_BUG_ON(obj->base.import_attach != NULL);
-:63: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"obj->base.import_attach"
#63: FILE: drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c:231:
+ GEM_BUG_ON(obj->base.import_attach != NULL);
-:94: CHECK:BRACES: Unbalanced braces around else statement
#94: FILE: drivers/gpu/drm/i915/gem/i915_gem_mman.c:90:
+ else {
-:184: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"obj->base.import_attach"
#184: FILE: drivers/gpu/drm/i915/gem/i915_gem_phys.c:32:
+ GEM_BUG_ON(obj->base.import_attach != NULL);
-:579: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!file"
#579: FILE: drivers/gpu/drm/i915/gem/i915_gem_shmem.c:316:
+ GEM_WARN_ON(file == NULL);
-:704: CHECK:UNNECESSARY_PARENTHESES: Unnecessary parentheses around 'caching
!= ttm_write_combined'
#704: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:326:
+ if (i915_gem_object_is_shrinkable(obj) && (caching !=
ttm_write_combined)) {
-:989: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#989: FILE: drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c:49:
{
+
total: 0 errors, 0 warnings, 7 checks, 979 lines checked
[Intel-gfx] [PATCH] i915/gvt: Fix NULL pointer dereference in init_mmio_block_handlers
Fix following coccicheck error:
./drivers/gpu/drm/i915/gvt/handlers.c:2925:35-41: ERROR: block is NULL but
dereferenced.
Use gvt->mmio.mmio_block instead of block to avoid NULL pointer
dereference when find_mmio_block returns NULL.
Fixes: e0f74ed4634d ("i915/gvt: Separate the MMIO tracking table from GVT-g")
Signed-off-by: Wan Jiabing
---
drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index cf00398c2870..7ffe0fb512a9 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt/handlers.c
@@ -2922,7 +2922,7 @@ static int init_mmio_block_handlers(struct intel_gvt *gvt)
block = find_mmio_block(gvt, VGT_PVINFO_PAGE);
if (!block) {
WARN(1, "fail to assign handlers to mmio block %x\n",
-i915_mmio_reg_offset(block->offset));
+i915_mmio_reg_offset(gvt->mmio.mmio_block->offset));
return -ENODEV;
}
--
2.35.3
[Intel-gfx] [PATCH][next] drm/i915: Fix -Wstringop-overflow warning in call to intel_read_wm_latency()
Fix the following -Wstringop-overflow warnings when building with GCC-11:
drivers/gpu/drm/i915/intel_pm.c:3106:9: warning: ‘intel_read_wm_latency’
accessing 16 bytes in a region of size 10 [-Wstringop-overflow=]
3106 | intel_read_wm_latency(dev_priv, dev_priv->wm.pri_latency);
| ^
drivers/gpu/drm/i915/intel_pm.c:3106:9: note: referencing argument 2 of type
‘u16 *’ {aka ‘short unsigned int *’}
drivers/gpu/drm/i915/intel_pm.c:2861:13: note: in a call to function
‘intel_read_wm_latency’
2861 | static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
| ^
by removing the over-specified array size from the argument declarations.
It seems that this code is actually safe because the size of the
array depends on the hardware generation, and the function checks
for that.
This helps with the ongoing efforts to globally enable
-Wstringop-overflow.
Link: https://github.com/KSPP/linux/issues/181
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index ee0047fdc95d..5735915facc5 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -2862,7 +2862,7 @@ static void ilk_compute_wm_level(const struct
drm_i915_private *dev_priv,
}
static void intel_read_wm_latency(struct drm_i915_private *dev_priv,
- u16 wm[8])
+ u16 wm[])
{
struct intel_uncore *uncore = _priv->uncore;
--
2.27.0
Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi
Am 27.04.22 um 17:02 schrieb Matthew Auld:
On 27/04/2022 07:55, Christian König wrote:
Well usually we increment the drm minor version when adding some new
flags on amdgpu.
Additional to that just one comment from our experience with that:
You don't just need one flag, but two. The first one is a hint which
says "CPU access needed" and the second is a promise which says "CPU
access never needed".
The background is that on a whole bunch of buffers you can 100%
certain say that you will never ever need CPU access.
Then at least we have a whole bunch of buffers where we might need
CPU access, but can't tell for sure.
And last we have stuff like transfer buffers you can be 100% sure
that you need CPU access.
Separating it like this helped a lot with performance on small BAR
systems.
Thanks for the comments. For the "CPU access never needed" flag, what
extra stuff does that do on the kernel side vs not specifying any
flag/hint? I assume it still prioritizes using the non-CPU visible
portion first? What else does it do?
It's used as a hint when you need to pin BOs for scanout for example.
In general we try to allocate BOs which are marked "CPU access needed"
in the CPU visible window if possible, but fallback to any memory if
that won't fit.
Christian.
Regards,
Christian.
Am 27.04.22 um 08:48 schrieb Lionel Landwerlin:
One question though, how do we detect that this flag
(I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS) is accepted on a given
kernel?
I assume older kernels are going to reject object creation if we use
this flag?
I didn't plan to use __drm_i915_query_vma_info, but isn't it
inconsistent to select the placement on the GEM object and then
query whether it's mappable by address?
You made a comment stating this is racy, wouldn't querying on the
GEM object prevent this?
Thanks,
-Lionel
On 27/04/2022 09:35, Lionel Landwerlin wrote:
Hi Matt,
The proposal looks good to me.
Looking forward to try it on drm-tip.
-Lionel
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 190
+++
Documentation/gpu/rfc/i915_small_bar.rst | 58 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 252 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 =
unknown) */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+ __u64 probed_cpu_visible_size;
+ };
+ };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create
behaviour, with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for
the stuff that
+ * is immutable. Previously we would have two ioctls, one to
create the object
+ * with gem_create, and another to apply various parameters,
however this
+ * creates some ambiguity for the params which are considered
immutable. Also in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+ /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated
Re: [Intel-gfx] [PATCH v2] drm/doc: add rfc section for small BAR uapi
Well usually we increment the drm minor version when adding some new
flags on amdgpu.
Additional to that just one comment from our experience with that: You
don't just need one flag, but two. The first one is a hint which says
"CPU access needed" and the second is a promise which says "CPU access
never needed".
The background is that on a whole bunch of buffers you can 100% certain
say that you will never ever need CPU access.
Then at least we have a whole bunch of buffers where we might need CPU
access, but can't tell for sure.
And last we have stuff like transfer buffers you can be 100% sure that
you need CPU access.
Separating it like this helped a lot with performance on small BAR systems.
Regards,
Christian.
Am 27.04.22 um 08:48 schrieb Lionel Landwerlin:
One question though, how do we detect that this flag
(I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS) is accepted on a given
kernel?
I assume older kernels are going to reject object creation if we use
this flag?
I didn't plan to use __drm_i915_query_vma_info, but isn't it
inconsistent to select the placement on the GEM object and then query
whether it's mappable by address?
You made a comment stating this is racy, wouldn't querying on the GEM
object prevent this?
Thanks,
-Lionel
On 27/04/2022 09:35, Lionel Landwerlin wrote:
Hi Matt,
The proposal looks good to me.
Looking forward to try it on drm-tip.
-Lionel
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size. (Lionel)
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
Cc: mesa-...@lists.freedesktop.org
---
Documentation/gpu/rfc/i915_small_bar.h | 190
+++
Documentation/gpu/rfc/i915_small_bar.rst | 58 +++
Documentation/gpu/rfc/index.rst | 4 +
3 files changed, 252 insertions(+)
create mode 100644 Documentation/gpu/rfc/i915_small_bar.h
create mode 100644 Documentation/gpu/rfc/i915_small_bar.rst
diff --git a/Documentation/gpu/rfc/i915_small_bar.h
b/Documentation/gpu/rfc/i915_small_bar.h
new file mode 100644
index ..7bfd0cf44d35
--- /dev/null
+++ b/Documentation/gpu/rfc/i915_small_bar.h
@@ -0,0 +1,190 @@
+/**
+ * struct __drm_i915_memory_region_info - Describes one region as
known to the
+ * driver.
+ *
+ * Note this is using both struct drm_i915_query_item and struct
drm_i915_query.
+ * For this new query we are adding the new query id
DRM_I915_QUERY_MEMORY_REGIONS
+ * at _i915_query_item.query_id.
+ */
+struct __drm_i915_memory_region_info {
+ /** @region: The class:instance pair encoding */
+ struct drm_i915_gem_memory_class_instance region;
+
+ /** @rsvd0: MBZ */
+ __u32 rsvd0;
+
+ /** @probed_size: Memory probed by the driver (-1 = unknown) */
+ __u64 probed_size;
+
+ /** @unallocated_size: Estimate of memory remaining (-1 =
unknown) */
+ __u64 unallocated_size;
+
+ union {
+ /** @rsvd1: MBZ */
+ __u64 rsvd1[8];
+ struct {
+ /**
+ * @probed_cpu_visible_size: Memory probed by the driver
+ * that is CPU accessible. (-1 = unknown).
+ *
+ * This will be always be <= @probed_size, and the
+ * remainder(if there is any) will not be CPU
+ * accessible.
+ */
+ __u64 probed_cpu_visible_size;
+ };
+ };
+};
+
+/**
+ * struct __drm_i915_gem_create_ext - Existing gem_create
behaviour, with added
+ * extension support using struct i915_user_extension.
+ *
+ * Note that new buffer flags should be added here, at least for
the stuff that
+ * is immutable. Previously we would have two ioctls, one to create
the object
+ * with gem_create, and another to apply various parameters,
however this
+ * creates some ambiguity for the params which are considered
immutable. Also in
+ * general we're phasing out the various SET/GET ioctls.
+ */
+struct __drm_i915_gem_create_ext {
+ /**
+ * @size: Requested size for the object.
+ *
+ * The (page-aligned) allocated size for the object will be
returned.
+ *
+ * Note that for some devices we have might have further minimum
+ * page-size restrictions(larger than 4K), like for device
local-memory.
+ * However in general the final size here should always reflect
any
+ * rounding up, if for example using the
I915_GEM_CREATE_EXT_MEMORY_REGIONS
+ * extension to place the object in device local-memory.
+ */
+ __u64 size;
+ /**
+ * @handle: Returned handle for the object.
+ *
+ * Object handles are nonzero.
+ */
+ __u32 handle;
+ /**
+
[Intel-gfx] [PATCH 1/1] drm/i915: Replace shmem memory region and object backend with TTM
Remove shmem region and object backend code as they are now unnecessary.
In the case of objects placed in SMEM and backed by kernel shmem files, the
file pointer has to be retrieved from the ttm_tt structure, so change this
as well. This means accessing an shmem-backed BO's file pointer requires
getting its pages beforehand, unlike in the old shmem backend.
Expand TTM BO creation by handling devices with no LLC so that their
caching and coherency properties are set accordingly.
Signed-off-by: Adrian Larumbe
---
drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +-
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +-
drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 5 +-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 397 +--
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 212 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 +
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +-
drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++-
drivers/gpu/drm/i915/intel_memory_region.c | 7 +-
10 files changed, 333 insertions(+), 412 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
index f5062d0c6333..de04ce4210b3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c
@@ -12,6 +12,7 @@
#include
#include "gem/i915_gem_dmabuf.h"
+#include "gem/i915_gem_ttm.h"
#include "i915_drv.h"
#include "i915_gem_object.h"
#include "i915_scatterlist.h"
@@ -94,22 +95,25 @@ static int i915_gem_dmabuf_mmap(struct dma_buf *dma_buf,
struct vm_area_struct *
{
struct drm_i915_gem_object *obj = dma_buf_to_obj(dma_buf);
struct drm_i915_private *i915 = to_i915(obj->base.dev);
+ struct file *filp = i915_gem_ttm_get_filep(obj);
int ret;
+ GEM_BUG_ON(obj->base.import_attach != NULL);
+
if (obj->base.size < vma->vm_end - vma->vm_start)
return -EINVAL;
if (HAS_LMEM(i915))
return drm_gem_prime_mmap(>base, vma);
- if (!obj->base.filp)
+ if (!filp)
return -ENODEV;
- ret = call_mmap(obj->base.filp, vma);
+ ret = call_mmap(filp, vma);
if (ret)
return ret;
- vma_set_file(vma, obj->base.filp);
+ vma_set_file(vma, filp);
return 0;
}
@@ -224,6 +228,8 @@ struct dma_buf *i915_gem_prime_export(struct drm_gem_object
*gem_obj, int flags)
exp_info.priv = gem_obj;
exp_info.resv = obj->base.resv;
+ GEM_BUG_ON(obj->base.import_attach != NULL);
+
if (obj->ops->dmabuf_export) {
int ret = obj->ops->dmabuf_export(obj);
if (ret)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 0c5c43852e24..d963cf35fdc9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -64,7 +64,9 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
struct drm_i915_private *i915 = to_i915(dev);
struct drm_i915_gem_mmap *args = data;
struct drm_i915_gem_object *obj;
+ struct file *filp;
unsigned long addr;
+ int ret;
/*
* mmap ioctl is disallowed for all discrete platforms,
@@ -83,12 +85,20 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
if (!obj)
return -ENOENT;
- /* prime objects have no backing filp to GEM mmap
-* pages from.
-*/
- if (!obj->base.filp) {
- addr = -ENXIO;
- goto err;
+ if (obj->base.import_attach)
+ filp = obj->base.filp;
+ else {
+ ret = i915_gem_object_pin_pages_unlocked(obj);
+ if (ret) {
+ addr = ret;
+ goto err_pin;
+ }
+
+ filp = i915_gem_ttm_get_filep(obj);
+ if (!filp) {
+ addr = -ENXIO;
+ goto err;
+ }
}
if (range_overflows(args->offset, args->size, (u64)obj->base.size)) {
@@ -96,7 +106,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
goto err;
}
- addr = vm_mmap(obj->base.filp, 0, args->size,
+ addr = vm_mmap(filp, 0, args->size,
PROT_READ | PROT_WRITE, MAP_SHARED,
args->offset);
if (IS_ERR_VALUE(addr))
@@ -111,7 +121,7 @@ i915_gem_mmap_ioctl(struct drm_device *dev, void *data,
goto err;
}
vma = find_vma(mm, addr);
- if (vma && __vma_matches(vma, obj->base.filp, addr, args->size))
+ if (vma && __vma_matches(vma, filp, addr, args->size))
vma->vm_page_prot =
[Intel-gfx] [PATCH 0/1] Replace shmem memory region and object backend with TTM
This patch is an attempt at eliminating the old shmem memory region and GEM object backend, in favour of a TTM-based one that is able to manage objects placed on both system and local memory. Known issues: Many GPU hungs in machines of GEN <= 5. My assumption is this has something to do with a caching issues, but everywhere across the TTM backend code I've tried to handle object creation and getting its pages with the same set of caching and coherency properties as in the old shmem backend. Object passed to shmem_create_from_object somehow not being flushed after being written into at lrc_init_state. Seems thatwith the new backend and when pinning an intel_context, either i915_gem_object_pin_map is not creating a kernel mapping with the right caching properties or else flushing it afterwards doesn't do anything. This leads to a GPU hung because the engine's default state that is read with shmem_read doesn't reflect what had been written into it previously by vmap'ing the object's pages. The only workaround I could find was manually setting the shmem file's pages dirty and putting them back, but this looks hacky and wasteful for big BO's Besides all this, I haven't yet implemented the pread callback for TTM object backend, as it seems CI's BAT test list doesn't include it. Adrian Larumbe (1): drm/i915: Replace shmem memory region and object backend with TTM drivers/gpu/drm/i915/gem/i915_gem_dmabuf.c | 12 +- drivers/gpu/drm/i915/gem/i915_gem_mman.c | 32 +- drivers/gpu/drm/i915/gem/i915_gem_object.h | 2 +- drivers/gpu/drm/i915/gem/i915_gem_phys.c | 5 +- drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 397 +-- drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 212 +- drivers/gpu/drm/i915/gem/i915_gem_ttm.h | 3 + drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 11 +- drivers/gpu/drm/i915/gt/shmem_utils.c| 64 ++- drivers/gpu/drm/i915/intel_memory_region.c | 7 +- 10 files changed, 333 insertions(+), 412 deletions(-) -- 2.35.1
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915/xehp: Add register for compute engine's MMIO-based TLB invalidation
On 28/04/2022 05:19, Matt Roper wrote: Compute engines have a separate register that the driver should use to perform MMIO-based TLB invalidation. Note that the term "context" in this register's bspec description is used to refer to the engine instance (in the same way "context" is used on bspec 46167). Bspec: 43930 Cc: Prathap Kumar Valsan Cc: Tvrtko Ursulin Signed-off-by: Matt Roper Happy even a blind chicken (me) managed to pick on this piece of correctness. :) Acked-by: Tvrtko Ursulin Prathap please r-b since you were the authoritative source in this case. Regards, Tvrtko --- drivers/gpu/drm/i915/gt/intel_gt.c | 1 + drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/intel_gt.c index 92394f13b42f..53307ca0eed0 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt.c +++ b/drivers/gpu/drm/i915/gt/intel_gt.c @@ -1175,6 +1175,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt) [VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR, [VIDEO_ENHANCEMENT_CLASS] = GEN12_VE_TLB_INV_CR, [COPY_ENGINE_CLASS] = GEN12_BLT_TLB_INV_CR, + [COMPUTE_CLASS] = GEN12_COMPCTX_TLB_INV_CR, }; struct drm_i915_private *i915 = gt->i915; struct intel_uncore *uncore = gt->uncore; diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h b/drivers/gpu/drm/i915/gt/intel_gt_regs.h index a39718a40cc3..a0a49c16babd 100644 --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h @@ -1007,6 +1007,7 @@ #define GEN12_VD_TLB_INV_CR _MMIO(0xcedc) #define GEN12_VE_TLB_INV_CR _MMIO(0xcee0) #define GEN12_BLT_TLB_INV_CR _MMIO(0xcee4) +#define GEN12_COMPCTX_TLB_INV_CR _MMIO(0xcf04) #define GEN12_MERT_MOD_CTRL _MMIO(0xcf28) #define RENDER_MOD_CTRL _MMIO(0xcf2c)
Re: [Intel-gfx] [PATCH 2/2] drm/i915/gvt: Fix the compiling error when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n
On Wed, 27 Apr 2022, Zhi Wang wrote: > A compiling error was reported when CONFIG_DRM_I915_DEBUG_RUNTIME_PM=n. > Fix the problem by using the pre-defined macro. > > Cc: Jason Gunthorpe > Cc: Jani Nikula > Signed-off-by: Zhi Wang We'll get this right, for now, but I do wonder if breaking these is going to be a perpetual thing. :( Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_gvt.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/i915/intel_gvt.c > b/drivers/gpu/drm/i915/intel_gvt.c > index 24bc693439e8..e98b6d69a91a 100644 > --- a/drivers/gpu/drm/i915/intel_gvt.c > +++ b/drivers/gpu/drm/i915/intel_gvt.c > @@ -309,7 +309,9 @@ EXPORT_SYMBOL_NS_GPL(__intel_context_do_pin, I915_GVT); > EXPORT_SYMBOL_NS_GPL(__intel_context_do_unpin, I915_GVT); > EXPORT_SYMBOL_NS_GPL(intel_ring_begin, I915_GVT); > EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_get, I915_GVT); > +#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM) > EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put, I915_GVT); > +#endif > EXPORT_SYMBOL_NS_GPL(intel_runtime_pm_put_unchecked, I915_GVT); > EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_for_reg, I915_GVT); > EXPORT_SYMBOL_NS_GPL(intel_uncore_forcewake_get, I915_GVT); -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/2] drm/i915/gvt: Make intel_gvt_match_device() static
On Wed, 27 Apr 2022, Zhi Wang wrote:
> After the refactor of GVT-g, the reference of intel_gvt_match_device()
> only happens in handlers.c. Make it static to let the compiler be
> happy.
>
> Cc: Jason Gunthorpe
> Cc: Jani Nikula
> Cc: Robert Beckett
> Signed-off-by: Zhi Wang
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index cf00398c2870..a93f8fd423c2 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -72,7 +72,7 @@ unsigned long intel_gvt_get_device_type(struct intel_gvt
> *gvt)
> return 0;
> }
>
> -bool intel_gvt_match_device(struct intel_gvt *gvt,
> +static bool intel_gvt_match_device(struct intel_gvt *gvt,
> unsigned long device)
> {
> return intel_gvt_get_device_type(gvt) & device;
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/atomic-helpers: remove legacy_cursor_update hacks
Hi Daniel,
On Wed, Apr 13, 2022 at 01:20:11PM +0200, Daniel Vetter wrote:
> On Wed, 13 Apr 2022 at 01:36, Abhinav Kumar wrote:
> > On 4/8/2022 9:04 PM, Abhinav Kumar wrote:
> > >
> > >
> > > On 4/7/2022 4:12 PM, Rob Clark wrote:
> > >> On Thu, Apr 7, 2022 at 3:59 PM Abhinav Kumar
> > >> wrote:
> > >>>
> > >>> Hi Rob and Daniel
> > >>>
> > >>> On 4/7/2022 3:51 PM, Rob Clark wrote:
> > On Wed, Apr 6, 2022 at 6:27 PM Jessica Zhang
> > wrote:
> > >
> > >
> > >
> > > On 3/31/2022 8:20 AM, Daniel Vetter wrote:
> > >> The stuff never really worked, and leads to lots of fun because it
> > >> out-of-order frees atomic states. Which upsets KASAN, among other
> > >> things.
> > >>
> > >> For async updates we now have a more solid solution with the
> > >> ->atomic_async_check and ->atomic_async_commit hooks. Support for
> > >> that
> > >> for msm and vc4 landed. nouveau and i915 have their own commit
> > >> routines, doing something similar.
> > >>
> > >> For everyone else it's probably better to remove the use-after-free
> > >> bug, and encourage folks to use the async support instead. The
> > >> affected drivers which register a legacy cursor plane and don't
> > >> either
> > >> use the new async stuff or their own commit routine are: amdgpu,
> > >> atmel, mediatek, qxl, rockchip, sti, sun4i, tegra, virtio, and
> > >> vmwgfx.
> > >>
> > >> Inspired by an amdgpu bug report.
> > >>
> > >> v2: Drop RFC, I think with amdgpu converted over to use
> > >> atomic_async_check/commit done in
> > >>
> > >> commit 674e78acae0dfb4beb56132e41cbae5b60f7d662
> > >> Author: Nicholas Kazlauskas
> > >> Date: Wed Dec 5 14:59:07 2018 -0500
> > >>
> > >>drm/amd/display: Add fast path for cursor plane updates
> > >>
> > >> we don't have any driver anymore where we have userspace expecting
> > >> solid legacy cursor support _and_ they are using the atomic
> > >> helpers in
> > >> their fully glory. So we can retire this.
> > >>
> > >> v3: Paper over msm and i915 regression. The complete_all is the only
> > >> thing missing afaict.
> > >>
> > >> v4: Fixup i915 fixup ...
> > >>
> > >> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> > >> References:
> > >> https://lore.kernel.org/all/20220221134155.125447-9-max...@cerno.tech/
> > >>
> > >> References: https://bugzilla.kernel.org/show_bug.cgi?id=199425
> > >> Cc: Maxime Ripard
> > >> Tested-by: Maxime Ripard
> > >> Cc: mikita.lip...@amd.com
> > >> Cc: Michel Dänzer
> > >> Cc: harry.wentl...@amd.com
> > >> Cc: Rob Clark
> > >
> > > Hey Rob,
> > >
> > > I saw your tested-by and reviewed-by tags on Patchwork. Just curious,
> > > what device did you test on?
> >
> > I was testing on strongbad.. v5.18-rc1 + patches (notably, revert
> > 80253168dbfd ("drm: of: Lookup if child node has panel or bridge")
> >
> > I think the display setup shouldn't be significantly different than
> > limozeen (ie. it's an eDP panel). But I didn't do much start/stop
> > ui.. I was mostly looking to make sure cursor movements weren't
> > causing fps drops ;-)
> >
> > BR,
> > -R
> > >>>
> > >>> start ui/ stop ui is a basic operation for us to use IGT on msm-next.
> > >>> So we cannot let that break.
> > >>>
> > >>> I think we need to check whats causing this splat.
> > >>>
> > >>> Can we hold back this change till then?
> > >>
> > >> Can you reproduce on v5.18-rc1 (plus 80253168dbfd)? I'm running a
> > >> loop of stop ui / start ui and hasn't triggered a splat yet.
> > >>
> > >> Otherwise maybe you can addr2line to figure out where it crashed?
> > >>
> > >> BR,
> > >> -R
> > >
> > > So this is not a crash. Its a warning splat coming from
> > >
> > > https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c#L785
> > >
> > >
> > > Looks like the complete_commit() which should signal the event has not
> > > happened before the next cursor commit.
> > >
> > > Somehow this change is affecting the flow to miss the event signaling
> > > that the event is done.
> > >
> > > We tried a couple of approaches but couldnt still fix the warning.
> > >
> > > Will continue to check further next week.
> > >
> > >>
> > >>> Thanks
> > >>>
> > >>> Abhinav
> >
> > After checking this more this week, I think the current patch needs to
> > be changed a bit.
> >
> > So, here you are removing the complete_all part and leaving that to the
> > individual drivers, which is fine.
> >
> > But, you are also removing the continue part which I think seems
> > incorrect and causing these warnings for MSM driver.
> >
> > @@ -2135,12 +2128,6 @@ int drm_atomic_helper_setup_commit(struct
> > drm_atomic_state *state,
> > continue;
> > }
> >
> > -
Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/xehp: Add compute engine ABI
On 28/04/2022 05:19, Matt Roper wrote:
We're now ready to start exposing compute engines to userspace.
v2:
- Move kerneldoc for other engine classes to a separate patch. (Andi)
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Vinay Belgaumkar
Cc: Jordan Justen
Cc: Szymon Morek
UMD (mesa): https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/14395
If in doubt cut it out. :) Works for me.
The rest looks complete.
Acked-by: Tvrtko Ursulin
Anyone cares to smoke test and update intel_gpu_top to display a nice name?
Regards,
Tvrtko
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
drivers/gpu/drm/i915/i915_drm_client.c | 1 +
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
include/uapi/drm/i915_drm.h | 9 +
4 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
b/drivers/gpu/drm/i915/gt/intel_engine_user.c
index 0f6cd96b459f..46a174f8aa00 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
@@ -47,7 +47,7 @@ static const u8 uabi_classes[] = {
[COPY_ENGINE_CLASS] = I915_ENGINE_CLASS_COPY,
[VIDEO_DECODE_CLASS] = I915_ENGINE_CLASS_VIDEO,
[VIDEO_ENHANCEMENT_CLASS] = I915_ENGINE_CLASS_VIDEO_ENHANCE,
- /* TODO: Add COMPUTE_CLASS mapping once ABI is available */
+ [COMPUTE_CLASS] = I915_ENGINE_CLASS_COMPUTE,
};
static int engine_cmp(void *priv, const struct list_head *A,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 475a6f824cad..18d38cb59923 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -81,6 +81,7 @@ static const char * const uabi_class_names[] = {
[I915_ENGINE_CLASS_COPY] = "copy",
[I915_ENGINE_CLASS_VIDEO] = "video",
[I915_ENGINE_CLASS_VIDEO_ENHANCE] = "video-enhance",
+ [I915_ENGINE_CLASS_COMPUTE] = "compute",
};
static u64 busy_add(struct i915_gem_context *ctx, unsigned int class)
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 5f5b02b01ba0..f796c5e8e060 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -13,7 +13,7 @@
#include "gt/intel_engine_types.h"
-#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_VIDEO_ENHANCE
+#define I915_LAST_UABI_ENGINE_CLASS I915_ENGINE_CLASS_COMPUTE
struct drm_i915_private;
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index ec000fc6c879..a2def7b27009 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -203,6 +203,15 @@ enum drm_i915_gem_engine_class {
*/
I915_ENGINE_CLASS_VIDEO_ENHANCE = 3,
+ /**
+* @I915_ENGINE_CLASS_COMPUTE:
+*
+* Compute engines support a subset of the instructions available
+* on render engines: compute engines support Compute (GPGPU) and
+* programmable media workloads, but do not support the 3D pipeline.
+*/
+ I915_ENGINE_CLASS_COMPUTE = 4,
+
/* Values in this enum should be kept compact. */
/**
[Intel-gfx] [PULL] drm-misc-next
Hi Daniel, Dave, Here's this week drm-misc-next PR Maxime drm-misc-next-2022-04-28: drm-misc-next for 5.19: UAPI Changes: Cross-subsystem Changes: Core Changes: - Introduction of display-helper module, and rework of the DP, DSC, HDCP, HDMI and SCDC headers - doc: Improvements for tiny drivers, link to external resources - formats: helper to convert from RGB888 and RGB565 to XRGB - modes: make width-mm/height-mm check mandatory in of_get_drm_panel_display_mode - ttm: Convert from kvmalloc_array to kvcalloc Driver Changes: - bridge: - analogix_dp: Fix error handling in probe - dw_hdmi: Coccinelle fixes - it6505: Fix Kconfig dependency on DRM_DP_AUX_BUS - panel: - new panel: DataImage FG040346DSSWBG04 - amdgpu: ttm_eu cleanups - mxsfb: Rework CRTC mode setting - nouveau: Make some variables static - sun4i: Drop drm_display_info.is_hdmi caching, support for the Allwinner D1 - vc4: Drop drm_display_info.is_hdmi caching - vmwgfx: Fence improvements The following changes since commit 40d8d4bd06720aed6c1125bab7296c57de4f1157: drm/radeon: Use TTM builtin resource manager debugfs code (2022-04-20 21:06:02 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2022-04-28 for you to fetch changes up to e08a99d005588f7f1d0647cdbc3368c98471fa6c: drm/format-helper: Add RGB565-to-XRGB conversion (2022-04-27 08:52:06 +0200) drm-misc-next for 5.19: UAPI Changes: Cross-subsystem Changes: Core Changes: - Introduction of display-helper module, and rework of the DP, DSC, HDCP, HDMI and SCDC headers - doc: Improvements for tiny drivers, link to external resources - formats: helper to convert from RGB888 and RGB565 to XRGB - modes: make width-mm/height-mm check mandatory in of_get_drm_panel_display_mode - ttm: Convert from kvmalloc_array to kvcalloc Driver Changes: - bridge: - analogix_dp: Fix error handling in probe - dw_hdmi: Coccinelle fixes - it6505: Fix Kconfig dependency on DRM_DP_AUX_BUS - panel: - new panel: DataImage FG040346DSSWBG04 - amdgpu: ttm_eu cleanups - mxsfb: Rework CRTC mode setting - nouveau: Make some variables static - sun4i: Drop drm_display_info.is_hdmi caching, support for the Allwinner D1 - vc4: Drop drm_display_info.is_hdmi caching - vmwgfx: Fence improvements Chia-I Wu (2): drm/sched: use DECLARE_EVENT_CLASS drm/sched: use __string in tracepoints Christian König (2): drm/amdgpu: remove pointless ttm_eu usage from vkms drm/amdgpu: remove pointless ttm_eu usage from DM Chunguang Xu (1): drm/tilcdc: fix typos in comment Colin Ian King (1): drm/v3d: Fix null pointer dereference of pointer perfmon Dmitry Baryshkov (1): drm/bridge: tc358762: drop connector field Guo Zhengkui (1): drm/nouveau/devinit/nva3-: fix returnvar.cocci warning Javier Martinez Canillas (1): drm/doc: Add sections about tiny drivers and external refs to intro page Jernej Skrabec (3): sun4i/drm: engine: Add mode_set callback sun4i/drm: backend: use mode_set engine callback sun4i/drm: sun8i: use mode_set engine callback José Expósito (3): drm/vc4: hdmi: Replace drm_detect_hdmi_monitor() with is_hdmi drm/vc4: hdmi: Remove vc4_hdmi_encoder drm/sun4i: hdmi: Replace drm_detect_hdmi_monitor() with is_hdmi Marek Vasut (10): dt-bindings: display: simple: Add DataImage FG040346DSSWBG04 compatible string drm/panel: simple: Add DataImage FG040346DSSWBG04 panel support drm/modes: Make width-mm/height-mm check in of_get_drm_panel_display_mode() mandatory drm/panel: lvds: Drop now redundant width-mm and height-mm check drm/panel: simple: Add missing bus flags for Innolux G070Y2-L01 drm: mxsfb: Wrap FIFO reset and comments into mxsfb_reset_block() drm: mxsfb: Replace mxsfb_get_fb_paddr() with drm_fb_cma_get_gem_addr() drm: mxsfb: Factor out mxsfb_set_mode() drm: mxsfb: Reorder mxsfb_crtc_mode_set_nofb() drm: mxsfb: Obtain bus flags from bridge state Miaoqian Lin (1): drm/bridge: Fix error handling in analogix_dp_probe Robert Foss (1): drm/bridge: Fix it6505 Kconfig DRM_DP_AUX_BUS dependency Samuel Holland (10): dt-bindings: display: Separate clock item lists by compatible dt-bindings: display: Add D1 display engine compatibles drm/sun4i: hdmi: Use more portable I/O helpers drm/sun4i: Allow building the driver on RISC-V drm/sun4i: Allow VI layers to be primary planes drm/sun4i: csc: Add support for the new MMIO layout drm/sun4i: Add support for D1 mixers drm/sun4i: Add support for D1 TCON TOP drm/sun4i: Add support for D1 TCONs drm/sun4i: Add compatible for D1 display engine Thomas Zimmermann (11):
[Intel-gfx] ✓ Fi.CI.IGT: success for i915: Turn on compute engine support (rev4)
== Series Details ==
Series: i915: Turn on compute engine support (rev4)
URL : https://patchwork.freedesktop.org/series/103011/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103011v4_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_103011v4_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_103011v4_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (10 -> 13)
--
Additional (3): shard-rkl shard-dg1 shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_103011v4_full:
### IGT changes ###
Warnings
* igt@gem_eio@kms:
- shard-tglb: [FAIL][1] ([i915#232]) -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-tglb3/igt@gem_...@kms.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-tglb1/igt@gem_...@kms.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_pm_rpm@system-suspend-devices:
- {shard-dg1}:NOTRUN -> [INCOMPLETE][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-dg1-19/igt@i915_pm_...@system-suspend-devices.html
Known issues
Here are the changes found in Patchwork_103011v4_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-skl: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
[PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13],
[PASS][14], [PASS][15], [FAIL][16], [PASS][17], [PASS][18], [PASS][19],
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25],
[PASS][26], [PASS][27]) ([i915#5032]) -> ([PASS][28], [PASS][29], [PASS][30],
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
[PASS][49], [PASS][50], [PASS][51])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl9/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl8/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl7/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl6/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl5/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl4/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl3/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl2/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl1/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_11550/shard-skl10/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-skl9/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-skl9/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-skl8/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-skl8/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-skl8/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_103011v4/shard-skl7/boot.html
[34]:
[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel, Here goes drm-intel-fixes PR for v5.18-rc5. Fixes for backlight control on XMG Core 15 e21 (#5284, regression since 5.15) and black display plane on Acer One AO532h. Then two smaller display fixes picked up by tooling. Regards, Joonas *** drm-intel-fixes-2022-04-28: - Fix #5284: Backlight control regression on XMG Core 15 e21 - Fix black display plane on Acer One AO532h - Two smaller display fixes - The following changes since commit af2d861d4cd2a4da5137f795ee3509e6f944a25b: Linux 5.18-rc4 (2022-04-24 14:51:22 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-04-28 for you to fetch changes up to f7e1089f43761ca221914aea9a755b23dc7cbc33: drm/i915/fbc: Consult hw.crtc instead of uapi.crtc (2022-04-26 10:12:36 +0300) - Fix #5284: Backlight control regression on XMG Core 15 e21 - Fix black display plane on Acer One AO532h - Two smaller display fixes - Hans de Goede (1): drm/i915: Fix DISP_POS_Y and DISP_HEIGHT defines Imre Deak (1): drm/i915: Fix SEL_FETCH_PLANE_*(PIPE_B+) register addresses Jouni Högander (1): drm/i915: Check EDID for HDR static metadata when choosing blc Ville Syrjälä (1): drm/i915/fbc: Consult hw.crtc instead of uapi.crtc .../gpu/drm/i915/display/intel_dp_aux_backlight.c | 34 +- drivers/gpu/drm/i915/display/intel_fbc.c | 2 +- drivers/gpu/drm/i915/i915_reg.h| 6 ++-- 3 files changed, 30 insertions(+), 12 deletions(-)
