[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/selftests: Fix live_requests for all engines (rev2)
== Series Details ==
Series: drm/i915/selftests: Fix live_requests for all engines (rev2)
URL : https://patchwork.freedesktop.org/series/114393/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12789_full -> Patchwork_114393v2_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_114393v2_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114393v2_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114393v2_full:
### IGT changes ###
Possible regressions
* igt@vgem_basic@unload:
- shard-apl: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/shard-apl6/igt@vgem_ba...@unload.html
Known issues
Here are the changes found in Patchwork_114393v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_lmem_swapping@smem-oom:
- shard-apl: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/shard-apl6/igt@gem_lmem_swapp...@smem-oom.html
* igt@gem_pxp@create-regular-context-2:
- shard-apl: NOTRUN -> [SKIP][3] ([fdo#109271]) +14 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/shard-apl6/igt@gem_...@create-regular-context-2.html
* igt@gem_ringfill@basic-all:
- shard-apl: NOTRUN -> [ABORT][4] ([i915#8233])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/shard-apl6/igt@gem_ringf...@basic-all.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3886]) +2
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/shard-glk7/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/shard-apl6/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_crc@cursor-random-max-size:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +2 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/shard-glk7/igt@kms_cursor_...@cursor-random-max-size.html
* igt@prime_vgem@basic-fence-read:
- shard-glk: NOTRUN -> [ABORT][8] ([i915#8233])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/shard-glk7/igt@prime_v...@basic-fence-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111825]: https://bugs.freedesktop.org/show_bug.cgi?id=111825
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1839]: https://gitlab.freedesktop.org/drm/intel/issues/1839
[i915#2437]: https://gitlab.freedesktop.org/drm/intel/issues/2437
[i915#2527]: https://gitlab.freedesktop.org/drm/intel/issues/2527
[i915#2575]: https://gitlab.freedesktop.org/drm/intel/issues/2575
[i915#2587]: https://gitlab.freedesktop.org/drm/intel/issues/2587
[i915#2672]: https://gitlab.freedesktop.org/drm/intel/issues/2672
[i915#3281]: https://gitlab.freedesktop.org/drm/intel/issues/3281
[i915#3297]: https://gitlab.freedesktop.org/drm/intel/issues/3297
[i915#3299]: https://gitlab.freedesktop.org/drm/intel/issues/3299
[i915#3359]: https://gitlab.freedesktop.org/drm/intel/issues/3359
[i915#3361]: https://gitlab.freedesktop.org/drm/intel/issues/3361
[i915#3458]: https://gitlab.freedesktop.org/drm/intel/issues/3458
[i915#3539]: https://gitlab.freedesktop.org/drm/intel/issues/3539
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3638]: https://gitlab.freedesktop.org/drm/intel/issues/3638
[i915#3689]: https://gitlab.freedesktop.org/drm/intel/issues/3689
[i915#3886]: https://gitlab.freedesktop.org/drm/intel/issues/3886
[i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
> From: Liu, Yi L
> Sent: Tuesday, February 28, 2023 10:35 AM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, February 28, 2023 2:30 AM
> >
> > On Mon, Feb 27, 2023 at 03:11:26AM -0800, Yi Liu wrote:
> > > For the device fd opened from cdev, userspace needs to bind it to an
> > > iommufd and attach it to IOAS managed by iommufd. With such
> > operations,
> > > userspace can set up a secure DMA context and hence access device.
> > >
> > > This changes the existing vfio_iommufd_bind() to accept a pt_id pointer
> > > as an optional input, and also an dev_id pointer to selectively return
> > > the dev_id to prepare for adding bind_iommufd ioctl, which does the
> bind
> > > first and then attach IOAS.
> > >
> > > Signed-off-by: Yi Liu
> > > Reviewed-by: Kevin Tian
> > > ---
> > > drivers/vfio/group.c | 17 ++---
> > > drivers/vfio/iommufd.c | 21 +
> > > drivers/vfio/vfio.h | 9 ++---
> > > drivers/vfio/vfio_main.c | 10 ++
> > > 4 files changed, 35 insertions(+), 22 deletions(-)
> > >
> > > diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> > > index d8771d585cb1..e44232551448 100644
> > > --- a/drivers/vfio/group.c
> > > +++ b/drivers/vfio/group.c
> > > @@ -169,6 +169,7 @@ static void
> > vfio_device_group_get_kvm_safe(struct vfio_device *device)
> > > static int vfio_device_group_open(struct vfio_device_file *df)
> > > {
> > > struct vfio_device *device = df->device;
> > > + u32 ioas_id;
> > > int ret;
> > >
> > > mutex_lock(>group->group_lock);
> > > @@ -177,6 +178,13 @@ static int vfio_device_group_open(struct
> > vfio_device_file *df)
> > > goto out_unlock;
> > > }
> > >
> > > + if (device->group->iommufd) {
> > > + ret = iommufd_vfio_compat_ioas_id(device->group-
> > >iommufd,
> > > + _id);
> > > + if (ret)
> > > + goto out_unlock;
> > > + }
> >
> > I don't really like this being moved out of iommufd.c
> >
> > Pass in a NULL pt_id and the do some
> >
> > > -int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx
> > *ictx)
> > > +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx
> > *ictx,
> > > + u32 *dev_id, u32 *pt_id)
> > > {
> > > - u32 ioas_id;
> > > u32 device_id;
> > > int ret;
> > >
> > > @@ -29,17 +29,14 @@ int vfio_iommufd_bind(struct vfio_device *vdev,
> > struct iommufd_ctx *ictx)
> > > if (ret)
> > > return ret;
> > >
> > > - ret = iommufd_vfio_compat_ioas_id(ictx, _id);
> > > - if (ret)
> > > - goto err_unbind;
> >
> > io_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx,
> > u32 *dev_id, u32 *pt_id)
> > {
> >u32 tmp_pt_id;
> >if (!pt_id) {
> >pt_id = _pt_id;
> >ret = iommufd_vfio_compat_ioas_id(ictx, pt_id);
> >if (ret)
> > goto err_unbind;
> >
> >}
> >
> > To handle it
> >
> > And the commit message is sort of out of sync with the patch, more like:
> >
> > vfio: Pass the pt_id as an argument to vfio_iommufd_bind()
> >
> > To support binding the cdev the pt_id must come from userspace instead
> > of being forced to the compat_ioas_id.
> >
Seems like pt_id is no more needed in the vfio_iommufd_bind()
since it can get compat_ioas_id in the function itself. Cdev path
never passes a pt_id to vfio_iommufd_bind() as its attach is done
by separate ATTACH ioctl. Can we use the dev_id pointer to indicate
if it needs to get the compat ioas and attach it?
vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx,
u32 *dev_id)
{
...
if (!dev_id) {
u32 ioas_id;
ret = iommufd_vfio_compat_ioas_id(ictx, _id);
if (ret)
goto err_unbind;
ret = vdev->ops->attach_ioas(vdev, _id);
if (ret)
goto err_unbind;
}
...
}
Regards,
Yi Liu
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pxp: Add MTL PXP Support (rev6)
== Series Details ==
Series: drm/i915/pxp: Add MTL PXP Support (rev6)
URL : https://patchwork.freedesktop.org/series/112647/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12789_full -> Patchwork_112647v6_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_112647v6_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_112647v6_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (8 -> 8)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_112647v6_full:
### IGT changes ###
Possible regressions
* igt@vgem_basic@unload:
- shard-glk: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-glk4/igt@vgem_ba...@unload.html
Known issues
Here are the changes found in Patchwork_112647v6_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fence@syncobj-timeline-invalid-flags:
- shard-glk: NOTRUN -> [ABORT][2] ([i915#8233]) +2 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-glk7/igt@gem_exec_fe...@syncobj-timeline-invalid-flags.html
* igt@gem_lmem_swapping@random:
- shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#4613]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-glk3/igt@gem_lmem_swapp...@random.html
* igt@kms_big_fb@4-tiled-max-hw-stride-32bpp-rotate-180-async-flip:
- shard-apl: NOTRUN -> [SKIP][4] ([fdo#109271]) +84 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-apl6/igt@kms_big...@4-tiled-max-hw-stride-32bpp-rotate-180-async-flip.html
* igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#3886]) +4
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-apl6/igt@kms_ccs@pipe-a-crc-primary-rotation-180-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886]) +4
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-glk7/igt@kms_ccs@pipe-c-crc-sprite-planes-basic-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_cursor_crc@cursor-random-max-size:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +43 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-glk3/igt@kms_cursor_...@cursor-random-max-size.html
* igt@kms_psr2_sf@overlay-plane-move-continuous-exceed-fully-sf:
- shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#658]) +1
similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-apl6/igt@kms_psr2...@overlay-plane-move-continuous-exceed-fully-sf.html
* igt@kms_psr2_sf@primary-plane-update-sf-dmg-area:
- shard-glk: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#658])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-glk7/igt@kms_psr2...@primary-plane-update-sf-dmg-area.html
* igt@kms_vblank@pipe-d-wait-idle:
- shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-apl6/igt@kms_vbl...@pipe-d-wait-idle.html
* igt@prime_vgem@basic-fence-read:
- shard-apl: NOTRUN -> [ABORT][11] ([i915#8233]) +3 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/shard-apl6/igt@prime_v...@basic-fence-read.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109274]: https://bugs.freedesktop.org/show_bug.cgi?id=109274
[fdo#109280]: https://bugs.freedesktop.org/show_bug.cgi?id=109280
[fdo#109283]: https://bugs.freedesktop.org/show_bug.cgi?id=109283
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#110189]: https://bugs.freedesktop.org/show_bug.cgi?id=110189
[fdo#111068]: https://bugs.freedesktop.org/show_bug.cgi?id=111068
[fdo#111614]: https://bugs.freedesktop.org/show_bug.cgi?id=111614
[fdo#111615]: https://bugs.freedesktop.org/show_bug.cgi?id=111615
[fdo#111825]:
Re: [Intel-gfx] [PATCH v5 18/19] vfio: Compile group optionally
> From: Liu, Yi L
> Sent: Monday, February 27, 2023 7:12 PM
>
> group code is not needed for vfio device cdev, so with vfio device cdev
> introduced, the group infrastructures can be compiled out if only cdev
> is needed.
>
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/Kconfig | 14 +
> drivers/vfio/Makefile | 2 +-
> drivers/vfio/vfio.h | 72
> +++
> include/linux/vfio.h | 24 ++-
> 4 files changed, 110 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig
> index 169762316513..c3ab06c314ea 100644
> --- a/drivers/vfio/Kconfig
> +++ b/drivers/vfio/Kconfig
> @@ -4,6 +4,8 @@ menuconfig VFIO
> select IOMMU_API
> depends on IOMMUFD || !IOMMUFD
> select INTERVAL_TREE
> + select VFIO_GROUP if SPAPR_TCE_IOMMU
> + select VFIO_DEVICE_CDEV if !VFIO_GROUP && (X86 || S390 || ARM || ARM64)
Got below warning when IOMMUFD=n, VFIO_GROUP=n. so may remove
this select or needs to let VFIO_DEVICE_CDEV select IOMMUFD instead of
depends on IOMMUFD.
WARNING: unmet direct dependencies detected for VFIO_DEVICE_CDEV
Depends on [n]: VFIO [=m] && IOMMUFD [=n]
Selected by [m]:
- VFIO [=m] && (IOMMUFD [=n] || !IOMMUFD [=n]) && !VFIO_GROUP [=n]
> select VFIO_CONTAINER if IOMMUFD=n
Needs to be if IOMMUFD=n && VFIO_GROUP, otherwise vfio container
is compiled even VFIO_GROUP=n.
> help
> VFIO provides a framework for secure userspace device drivers.
> @@ -15,6 +17,7 @@ if VFIO
> config VFIO_DEVICE_CDEV
> bool "Support for the VFIO cdev /dev/vfio/devices/vfioX"
> depends on IOMMUFD && (X86 || S390 || ARM || ARM64)
depends on IOMMUFD have warning when IOMMUFD=n and VFIO_GROUP=n.
> + default !VFIO_GROUP
> help
> The VFIO device cdev is another way for userspace to get device
> access. Userspace gets device fd by opening device cdev under
> @@ -24,9 +27,20 @@ config VFIO_DEVICE_CDEV
>
> If you don't know what to do here, say N.
>
> +config VFIO_GROUP
> + bool "Support for the VFIO group /dev/vfio/$group_id"
> + default y
> + help
> +VFIO group support provides the traditional model for accessing
> +devices through VFIO and is used by the majority of userspace
> +applications and drivers making use of VFIO.
> +
> +If you don't know what to do here, say Y.
> +
> config VFIO_CONTAINER
> bool "Support for the VFIO container /dev/vfio/vfio"
> select VFIO_IOMMU_TYPE1 if MMU && (X86 || S390 || ARM ||
> ARM64)
> + depends on VFIO_GROUP
> default y
> help
> The VFIO container is the classic interface to VFIO for establishing
> diff --git a/drivers/vfio/Makefile b/drivers/vfio/Makefile
> index 245394aeb94b..57c3515af606 100644
> --- a/drivers/vfio/Makefile
> +++ b/drivers/vfio/Makefile
> @@ -2,9 +2,9 @@
> obj-$(CONFIG_VFIO) += vfio.o
>
> vfio-y += vfio_main.o \
> - group.o \
> iova_bitmap.o
> vfio-$(CONFIG_VFIO_DEVICE_CDEV) += device_cdev.o
> +vfio-$(CONFIG_VFIO_GROUP) += group.o
> vfio-$(CONFIG_IOMMUFD) += iommufd.o
> vfio-$(CONFIG_VFIO_CONTAINER) += container.o
> vfio-$(CONFIG_VFIO_VIRQFD) += virqfd.o
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index 5a1ceb014779..a7b88521bf48 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -62,6 +62,7 @@ enum vfio_group_type {
> VFIO_NO_IOMMU,
> };
>
> +#if IS_ENABLED(CONFIG_VFIO_GROUP)
> struct vfio_group {
> struct device dev;
> struct cdev cdev;
> @@ -107,6 +108,77 @@ void vfio_group_set_kvm(struct vfio_group *group,
> struct kvm *kvm);
> bool vfio_device_has_container(struct vfio_device *device);
> int __init vfio_group_init(void);
> void vfio_group_cleanup(void);
> +#else
> +struct vfio_group;
> +
> +static inline int vfio_device_block_group(struct vfio_device *device)
> +{
> + return 0;
> +}
> +
> +static inline void vfio_device_unblock_group(struct vfio_device *device)
> +{
> +}
> +
> +static inline int vfio_device_set_group(struct vfio_device *device,
> + enum vfio_group_type type)
> +{
> + return 0;
> +}
> +
> +static inline void vfio_device_remove_group(struct vfio_device *device)
> +{
> +}
> +
> +static inline void vfio_device_group_register(struct vfio_device *device)
> +{
> +}
> +
> +static inline void vfio_device_group_unregister(struct vfio_device *device)
> +{
> +}
> +
> +static inline int vfio_device_group_use_iommu(struct vfio_device *device)
> +{
> + return -EOPNOTSUPP;
> +}
> +
> +static inline void vfio_device_group_unuse_iommu(struct vfio_device
> *device)
> +{
> +}
> +
> +static inline void vfio_device_group_close(struct vfio_device_file *df)
> +{
> +}
> +
> +static inline struct vfio_group *vfio_group_from_file(struct file *file)
> +{
> + return NULL;
> +}
> +
> +static inline bool vfio_group_enforced_coherent(struct vfio_group *group)
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hwmon: Accept writes of value 0 to power1_max_interval
== Series Details == Series: drm/i915/hwmon: Accept writes of value 0 to power1_max_interval URL : https://patchwork.freedesktop.org/series/114459/ State : success == Summary == CI Bug Log - changes from CI_DRM_12789 -> Patchwork_114459v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114459v1/index.html Participating hosts (38 -> 37) -- Missing(1): fi-snb-2520m Changes --- No changes found Build changes - * Linux: CI_DRM_12789 -> Patchwork_114459v1 CI-20190529: 20190529 CI_DRM_12789: 8589fd9227ca62484e8599cbd62216230c2c9a64 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7174: 55642b7805d6fc5b987b396c2bbfa46db654db4f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114459v1: 8589fd9227ca62484e8599cbd62216230c2c9a64 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits d1e30cfc6f64 drm/i915/hwmon: Accept writes of value 0 to power1_max_interval == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114459v1/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Fix live_requests for all engines (rev2)
== Series Details == Series: drm/i915/selftests: Fix live_requests for all engines (rev2) URL : https://patchwork.freedesktop.org/series/114393/ State : success == Summary == CI Bug Log - changes from CI_DRM_12789 -> Patchwork_114393v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/index.html Participating hosts (38 -> 37) -- Missing(1): fi-snb-2520m Changes --- No changes found Build changes - * Linux: CI_DRM_12789 -> Patchwork_114393v2 CI-20190529: 20190529 CI_DRM_12789: 8589fd9227ca62484e8599cbd62216230c2c9a64 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7174: 55642b7805d6fc5b987b396c2bbfa46db654db4f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114393v2: 8589fd9227ca62484e8599cbd62216230c2c9a64 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits a536b651f81f drm/i915/selftests: Fix live_requests for all engines == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114393v2/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Fix live_requests for all engines (rev2)
== Series Details == Series: drm/i915/selftests: Fix live_requests for all engines (rev2) URL : https://patchwork.freedesktop.org/series/114393/ State : warning == Summary == Error: dim checkpatch failed 3342b504f81b drm/i915/selftests: Fix live_requests for all engines -:213: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #213: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1234: + GEM_BUG_ON(request[idx]->context->vm != batch->vm); -:275: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #275: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1288: + GEM_BUG_ON(!i915_request_completed(rq)); -:318: WARNING:AVOID_BUG: Do not crash the kernel unless it is absolutely unavoidable--use WARN_ON_ONCE() plus recovery code (if feasible) instead of BUG() or variants #318: FILE: drivers/gpu/drm/i915/selftests/i915_request.c:1364: + GEM_BUG_ON(request[idx]->context->vm != batch->vm); total: 0 errors, 3 warnings, 0 checks, 293 lines checked
[Intel-gfx] [PATCH] drm/i915/hwmon: Accept writes of value 0 to power1_max_interval
The value shown by power1_max_interval in millisec is essentially:
((1.x * power(2,y)) * 1000) >> 10
Where x and y are read from a HW register. On ATSM, x and y are 0 on
power-up so the value shown is 0.
Writes of 0 to power1_max_interval had previously been disallowed to avoid
computing ilog2(0) but this resulted in the corner-case bug
below. Therefore allow writes of 0 now but special case that write to
x = y = 0.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/7754
Signed-off-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_hwmon.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
b/drivers/gpu/drm/i915/i915_hwmon.c
index 7c20a6f47b92e..596dd2c070106 100644
--- a/drivers/gpu/drm/i915/i915_hwmon.c
+++ b/drivers/gpu/drm/i915/i915_hwmon.c
@@ -218,11 +218,15 @@ hwm_power1_max_interval_store(struct device *dev,
/* val in hw units */
val = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_time, SF_TIME);
/* Convert to 1.x * power(2,y) */
- if (!val)
- return -EINVAL;
- y = ilog2(val);
- /* x = (val - (1 << y)) >> (y - 2); */
- x = (val - (1ul << y)) << x_w >> y;
+ if (!val) {
+ /* Avoid ilog2(0) */
+ y = 0;
+ x = 0;
+ } else {
+ y = ilog2(val);
+ /* x = (val - (1 << y)) >> (y - 2); */
+ x = (val - (1ul << y)) << x_w >> y;
+ }
rxy = REG_FIELD_PREP(PKG_PWR_LIM_1_TIME_X, x) |
REG_FIELD_PREP(PKG_PWR_LIM_1_TIME_Y, y);
--
2.38.0
[Intel-gfx] [Intel-gfx V2] drm/i915/selftests: Fix live_requests for all engines
From: Tvrtko Ursulin
After the abandonment of i915->kernel_context and since we have started to
create per-gt engine->kernel_context, these tests need to be updated to
instantiate the batch buffer VMA in the correct PPGTT for the context used
to execute each spinner.
v2(Tejas):
- Clean commit message - Matt
- Add BUG_ON to match vm
v3(Tejas):
- Fix dim checkpatch warnings
Acked-by: Andi Shyti
Signed-off-by: Tvrtko Ursulin
Signed-off-by: Tejas Upadhyay
---
drivers/gpu/drm/i915/selftests/i915_request.c | 133 ++
1 file changed, 77 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/selftests/i915_request.c
b/drivers/gpu/drm/i915/selftests/i915_request.c
index 6fe22b096bdd..7a27aba3da8a 100644
--- a/drivers/gpu/drm/i915/selftests/i915_request.c
+++ b/drivers/gpu/drm/i915/selftests/i915_request.c
@@ -957,18 +957,18 @@ static int live_cancel_request(void *arg)
return 0;
}
-static struct i915_vma *empty_batch(struct drm_i915_private *i915)
+static struct i915_vma *empty_batch(struct intel_gt *gt)
{
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
u32 *cmd;
int err;
- obj = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ obj = i915_gem_object_create_internal(gt->i915, PAGE_SIZE);
if (IS_ERR(obj))
return ERR_CAST(obj);
- cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WB);
+ cmd = i915_gem_object_pin_map_unlocked(obj, I915_MAP_WC);
if (IS_ERR(cmd)) {
err = PTR_ERR(cmd);
goto err;
@@ -979,15 +979,15 @@ static struct i915_vma *empty_batch(struct
drm_i915_private *i915)
__i915_gem_object_flush_map(obj, 0, 64);
i915_gem_object_unpin_map(obj);
- intel_gt_chipset_flush(to_gt(i915));
+ intel_gt_chipset_flush(gt);
- vma = i915_vma_instance(obj, _gt(i915)->ggtt->vm, NULL);
+ vma = i915_vma_instance(obj, gt->vm, NULL);
if (IS_ERR(vma)) {
err = PTR_ERR(vma);
goto err;
}
- err = i915_vma_pin(vma, 0, 0, PIN_USER | PIN_GLOBAL);
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
if (err)
goto err;
@@ -1005,6 +1005,14 @@ static struct i915_vma *empty_batch(struct
drm_i915_private *i915)
return ERR_PTR(err);
}
+static int emit_bb_start(struct i915_request *rq, struct i915_vma *batch)
+{
+ return rq->engine->emit_bb_start(rq,
+i915_vma_offset(batch),
+i915_vma_size(batch),
+0);
+}
+
static struct i915_request *
empty_request(struct intel_engine_cs *engine,
struct i915_vma *batch)
@@ -1016,10 +1024,7 @@ empty_request(struct intel_engine_cs *engine,
if (IS_ERR(request))
return request;
- err = engine->emit_bb_start(request,
- i915_vma_offset(batch),
- i915_vma_size(batch),
- I915_DISPATCH_SECURE);
+ err = emit_bb_start(request, batch);
if (err)
goto out_request;
@@ -1034,8 +1039,7 @@ static int live_empty_request(void *arg)
struct drm_i915_private *i915 = arg;
struct intel_engine_cs *engine;
struct igt_live_test t;
- struct i915_vma *batch;
- int err = 0;
+ int err;
/*
* Submit various sized batches of empty requests, to each engine
@@ -1043,16 +1047,17 @@ static int live_empty_request(void *arg)
* the overhead of submitting requests to the hardware.
*/
- batch = empty_batch(i915);
- if (IS_ERR(batch))
- return PTR_ERR(batch);
-
for_each_uabi_engine(engine, i915) {
IGT_TIMEOUT(end_time);
struct i915_request *request;
+ struct i915_vma *batch;
unsigned long n, prime;
ktime_t times[2] = {};
+ batch = empty_batch(engine->gt);
+ if (IS_ERR(batch))
+ return PTR_ERR(batch);
+
err = igt_live_test_begin(, i915, __func__, engine->name);
if (err)
goto out_batch;
@@ -1100,27 +1105,30 @@ static int live_empty_request(void *arg)
engine->name,
ktime_to_ns(times[0]),
prime, div64_u64(ktime_to_ns(times[1]), prime));
+out_batch:
+ i915_vma_unpin(batch);
+ i915_vma_put(batch);
+ if (err)
+ break;
}
-out_batch:
- i915_vma_unpin(batch);
- i915_vma_put(batch);
return err;
}
-static struct i915_vma *recursive_batch(struct drm_i915_private *i915)
+static struct i915_vma *recursive_batch(struct intel_gt *gt)
{
+ struct drm_i915_private *i915 = gt->i915;
Re: [Intel-gfx] [PATCH v5 16/19] vfio: Add VFIO_DEVICE_BIND_IOMMUFD
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 3:20 AM
>
> On Mon, Feb 27, 2023 at 03:11:32AM -0800, Yi Liu wrote:
> > This adds ioctl for userspace to bind device cdev fd to iommufd.
> >
> > VFIO_DEVICE_BIND_IOMMUFD: bind device to an iommufd, hence gain
> DMA
> > control provided by the iommufd. open_device
> > op is called after bind_iommufd op.
> > VFIO no iommu mode is indicated by passing
> > a negative iommufd value.
> >
> > Signed-off-by: Yi Liu
> > ---
> > drivers/vfio/device_cdev.c | 146
> +
> > drivers/vfio/vfio.h| 17 -
> > drivers/vfio/vfio_main.c | 54 --
> > include/linux/iommufd.h| 6 ++
> > include/uapi/linux/vfio.h | 34 +
> > 5 files changed, 248 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
> > index 9e2c1ecaaf4f..37f80e368551 100644
> > --- a/drivers/vfio/device_cdev.c
> > +++ b/drivers/vfio/device_cdev.c
> > @@ -3,6 +3,7 @@
> > * Copyright (c) 2023 Intel Corporation.
> > */
> > #include
> > +#include
> >
> > #include "vfio.h"
> >
> > @@ -45,6 +46,151 @@ int vfio_device_fops_cdev_open(struct inode
> *inode, struct file *filep)
> > return ret;
> > }
> >
> > +static void vfio_device_get_kvm_safe(struct vfio_device_file *df)
> > +{
> > + spin_lock(>kvm_ref_lock);
> > + if (!df->kvm)
> > + goto unlock;
> > +
> > + _vfio_device_get_kvm_safe(df->device, df->kvm);
> > +
> > +unlock:
>
> Just
>
> if (df->kvm)
>_vfio_device_get_kvm_safe(df->device, df->kvm);
>
> Without the goto
Got it.
> > + spin_unlock(>kvm_ref_lock);
> > +}
> > +
> > +void vfio_device_cdev_close(struct vfio_device_file *df)
> > +{
> > + struct vfio_device *device = df->device;
> > +
> > + mutex_lock(>dev_set->lock);
> > + /*
> > +* As df->access_granted writer is under dev_set->lock as well,
> > +* so this read no need to use smp_load_acquire() to pair with
> > +* smp_store_release() in the caller of vfio_device_open().
> > +*/
>
> This is a bit misleading, we are about to free df in the caller, so at
> this moment df has no current access. We don't even need to have the
> mutex to test it.
Ok. so I can test it outside the lock and make the comment
more clear? How about below? Or simply no need to have
a comment here?
/*
* caller of vfio_device_cdev_close() is going to free df, so there
* is no need to use smp_load_acquire() to pair with
* smp_store_release() in the writer path of df->access_granted.
*/
> > +long vfio_device_ioctl_bind_iommufd(struct vfio_device_file *df,
> > + unsigned long arg)
>
> struct device __user *arg and remove all the casts.
>
> > +{
> > + struct vfio_device *device = df->device;
> > + struct vfio_device_bind_iommufd bind;
> > + struct iommufd_ctx *iommufd = NULL;
> > + unsigned long minsz;
> > + int ret;
> > +
> > + minsz = offsetofend(struct vfio_device_bind_iommufd, out_devid);
> > +
> > + if (copy_from_user(, (void __user *)arg, minsz))
> > + return -EFAULT;
> > +
> > + if (bind.argsz < minsz || bind.flags)
> > + return -EINVAL;
> > +
> > + if (!device->ops->bind_iommufd)
> > + return -ENODEV;
> > +
> > + ret = vfio_device_block_group(device);
> > + if (ret)
> > + return ret;
> > +
> > + mutex_lock(>dev_set->lock);
> > + /*
> > +* If already been bound to an iommufd, or already set noiommu
> > +* then fail it.
> > +*/
> > + if (df->iommufd || df->noiommu) {
> > + ret = -EINVAL;
> > + goto out_unlock;
> > + }
> > +
> > + /* iommufd < 0 means noiommu mode */
> > + if (bind.iommufd < 0) {
> > + if (!capable(CAP_SYS_RAWIO)) {
> > + ret = -EPERM;
> > + goto out_unlock;
> > + }
> > + df->noiommu = true;
> > + } else {
> > + iommufd = vfio_get_iommufd_from_fd(bind.iommufd);
> > + if (IS_ERR(iommufd)) {
> > + ret = PTR_ERR(iommufd);
> > + goto out_unlock;
> > + }
> > + }
> > +
> > + /*
> > +* Before the device open, get the KVM pointer currently
> > +* associated with the device file (if there is) and obtain
> > +* a reference. This reference is held until device closed.
> > +* Save the pointer in the device for use by drivers.
> > +*/
> > + vfio_device_get_kvm_safe(df);
> > +
> > + df->iommufd = iommufd;
> > + ret = vfio_device_open(df, _devid, NULL);
> > + if (ret)
> > + goto out_put_kvm;
> > +
> > + ret = copy_to_user((void __user *)arg +
> > + offsetofend(struct vfio_device_bind_iommufd,
> iommufd),
>
> ??
>
> >out_dev_id
>
> static_assert(__same_type...)
Yes, all the above comments are similar with other two patches. Will
refine
Re: [Intel-gfx] [PATCH v5 15/19] vfio: Add cdev for vfio_device
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 3:06 AM
>
> On Mon, Feb 27, 2023 at 03:11:31AM -0800, Yi Liu wrote:
> > @@ -309,6 +310,13 @@ void vfio_unregister_group_dev(struct
> vfio_device *device)
> > bool interrupted = false;
> > long rc;
> >
> > + /*
> > +* Balances vfio_device_add in register path. Putting it as the
> > +* first operation in unregister to prevent registration refcount
> > +* from incrementing per cdev open.
> > +*/
> > + vfio_device_del(device);
> > +
> > vfio_device_put_registration(device);
> > rc = try_wait_for_completion(>comp);
> > while (rc <= 0) {
> > @@ -334,9 +342,6 @@ void vfio_unregister_group_dev(struct vfio_device
> *device)
> >
> > vfio_device_group_unregister(device);
> >
> > - /* Balances device_add in register path */
> > - device_del(>device);
> > -
> > /* Balances vfio_device_set_group in register path */
> > vfio_device_remove_group(device);
>
> The same rational applies to vfio_device_group_unregister too, so it
> should be moved up as well.
You are right. User may get new registration refcount in below path
which can be in parallel with this vfio_unregister_group_dev() path.
Let me move it and refine the comment as well.
ioctl(group_fd, VFIO_GROUP_GET_DEVICE_FD, )
vfio_group_ioctl_get_device_fd()
-> vfio_device_get_from_name()
-> vfio_device_try_get_registration() -- refcount++
Thanks,
Yi Liu
Re: [Intel-gfx] [PATCH v5 15/19] vfio: Add cdev for vfio_device
> From: Jason Gunthorpe > Sent: Tuesday, February 28, 2023 2:56 AM > > On Mon, Feb 27, 2023 at 03:11:31AM -0800, Yi Liu wrote: > > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig > > index a8f544629467..169762316513 100644 > > --- a/drivers/vfio/Kconfig > > +++ b/drivers/vfio/Kconfig > > @@ -12,6 +12,18 @@ menuconfig VFIO > > If you don't know what to do here, say N. > > > > if VFIO > > +config VFIO_DEVICE_CDEV > > + bool "Support for the VFIO cdev /dev/vfio/devices/vfioX" > > + depends on IOMMUFD && (X86 || S390 || ARM || ARM64) > > We don't need to propogate this arch detection stuff, at worst it > should be in iommufd kconfig if it is really needed. Ok. this makes sense as cdev's real dependency is iommufd. Btw. Also no need for the below stuff. Is it? just select CDEV if !VFIO_GROUP. right? select VFIO_DEVICE_CDEV if !VFIO_GROUP && (X86 || S390 || ARM || ARM64) > Also that other thread shows that vfio doesn't work on ARM because we > can never take ownership of a device due to arm iommu It's interesting. May you share the link of this thread?:-) Regards, Yi Liu
Re: [Intel-gfx] [PATCH v5 18/19] vfio: Compile group optionally
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 3:20 AM
>
> On Mon, Feb 27, 2023 at 03:11:34AM -0800, Yi Liu wrote:
>
> > diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> > index ce390533cb30..d12384824656 100644
> > --- a/include/linux/vfio.h
> > +++ b/include/linux/vfio.h
> > @@ -43,7 +43,9 @@ struct vfio_device {
> > */
> > const struct vfio_migration_ops *mig_ops;
> > const struct vfio_log_ops *log_ops;
> > +#if IS_ENABLED(CONFIG_VFIO_GROUP)
> > struct vfio_group *group;
> > +#endif
> > struct vfio_device_set *dev_set;
> > struct list_head dev_set_list;
> > unsigned int migration_flags;
> > @@ -58,8 +60,10 @@ struct vfio_device {
> > refcount_t refcount;/* user count on registered device*/
> > unsigned int open_count;
> > struct completion comp;
> > +#if IS_ENABLED(CONFIG_VFIO_GROUP)
> > struct list_head group_next;
> > struct list_head iommu_entry;
> > +#endif
> > struct iommufd_access *iommufd_access;
> > void (*put_kvm)(struct kvm *kvm);
>
> I'd combine these for readability
Sure.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Add MTL PXP Support (rev6)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev6) URL : https://patchwork.freedesktop.org/series/112647/ State : success == Summary == CI Bug Log - changes from CI_DRM_12789 -> Patchwork_112647v6 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/index.html Participating hosts (38 -> 37) -- Missing(1): fi-snb-2520m Changes --- No changes found Build changes - * Linux: CI_DRM_12789 -> Patchwork_112647v6 CI-20190529: 20190529 CI_DRM_12789: 8589fd9227ca62484e8599cbd62216230c2c9a64 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7174: 55642b7805d6fc5b987b396c2bbfa46db654db4f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_112647v6: 8589fd9227ca62484e8599cbd62216230c2c9a64 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits f564e0d0d0cf drm/i915/pxp: Enable PXP with MTL-GSC-CS c97e82a4a5e8 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component bf542f18a9a8 drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0 731dbaef9cdf drm/i915/pxp: Add ARB session creation and cleanup eb13058b2943 drm/i915/pxp: Add GSC-CS backend to send GSC fw messages 36550cd9936b drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC d052146d347c drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation a7356c3fad2c drm/i915/pxp: Add GSC-CS back-end resource init and cleanup == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v6/index.html
Re: [Intel-gfx] [PATCH v5 14/19] vfio: Make vfio_device_open() single open for device cdev path
> From: Jason Gunthorpe > Sent: Tuesday, February 28, 2023 2:52 AM > > On Mon, Feb 27, 2023 at 03:11:30AM -0800, Yi Liu wrote: > > @@ -535,7 +542,8 @@ static int vfio_device_fops_release(struct inode > *inode, struct file *filep) > > struct vfio_device_file *df = filep->private_data; > > struct vfio_device *device = df->device; > > > > - vfio_device_group_close(df); > > + if (!df->is_cdev_device) > > + vfio_device_group_close(df); > > This hunk should go in another patch Patch 15 or 16? Which one is your preference? To me, I guess patch 15 is better since the user may open cdev fds after it. But its release op should not call vfio_device_group_close(); Regards, Yi Liu
Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support
> From: Jason Gunthorpe > Sent: Tuesday, February 28, 2023 3:21 AM > > On Mon, Feb 27, 2023 at 03:11:16AM -0800, Yi Liu wrote: > > Existing VFIO provides group-centric user APIs for userspace. Userspace > > opens the /dev/vfio/$group_id first before getting device fd and hence > > getting access to device. This is not the desired model for iommufd. Per > > the conclusion of community discussion[1], iommufd provides device- > centric > > kAPIs and requires its consumer (like VFIO) to be device-centric user > > APIs. Such user APIs are used to associate device with iommufd and also > > the I/O address spaces managed by the iommufd. > > > > This series first introduces a per device file structure to be prepared > > for further enhancement and refactors the kvm-vfio code to be prepared > > for accepting device file from userspace. Then refactors the vfio to be > > able to handle iommufd binding. This refactor includes the mechanism of > > blocking device access before iommufd bind, making the device_open > exclusive. > > between the group path and the cdev path. Eventually, adds the cdev > support > > for vfio device, and makes group infrastructure optional as it is not needed > > when vfio device cdev is compiled. > > > > This is also a prerequisite for iommu nesting for vfio device[2]. > > > > The complete code can be found in below branch, simple test done with > the > > legacy group path and the cdev path. Draft QEMU branch can be found > at[3] > > > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v5 > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > base-commit: 63777bd2daa3625da6eada88bd9081f047664dad > > This needs to be rebased onto a clean v6.3-rc1 when it comes out Yes, I'll send rebase and send one more version when v6.3-rc1 comes. Here just try to be near to the vfio code in Alex's next branch. Regards, Yi Liu
Re: [Intel-gfx] [PATCH v5 11/19] vfio-iommufd: Add detach_ioas support for physical VFIO devices
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 2:45 AM
>
> On Mon, Feb 27, 2023 at 03:11:27AM -0800, Yi Liu wrote:
> > diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c b/drivers/vfio/fsl-
> mc/vfio_fsl_mc.c
> > index c89a047a4cd8..d540cf683d93 100644
> > --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> > +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> > @@ -594,6 +594,7 @@ static const struct vfio_device_ops
> vfio_fsl_mc_ops = {
> > .bind_iommufd = vfio_iommufd_physical_bind,
> > .unbind_iommufd = vfio_iommufd_physical_unbind,
> > .attach_ioas= vfio_iommufd_physical_attach_ioas,
> > + .detach_ioas= vfio_iommufd_physical_detach_ioas,
> > };
> >
> > static struct fsl_mc_driver vfio_fsl_mc_driver = {
> > diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> > index beef6ca21107..bfaa9876499b 100644
> > --- a/drivers/vfio/iommufd.c
> > +++ b/drivers/vfio/iommufd.c
> > @@ -88,6 +88,14 @@ int vfio_iommufd_physical_attach_ioas(struct
> vfio_device *vdev, u32 *pt_id)
> > {
> > int rc;
> >
> > + lockdep_assert_held(>dev_set->lock);
> > +
> > + if (!vdev->iommufd_device)
> > + return -EINVAL;
>
> This should be a WARN_ON. The vdev->iommufd_ctx should be NULL if it
> hasn't been bound, and it can't be bound unless the
> iommufd_device/attach was created.
sure. But it is a user-triggerable warn. If userspace triggers it on
purpose, will it be a bad thing for kernel? Maybe use dev_warn_ratelimited()?
> > @@ -96,6 +104,18 @@ int vfio_iommufd_physical_attach_ioas(struct
> vfio_device *vdev, u32 *pt_id)
> > }
> > EXPORT_SYMBOL_GPL(vfio_iommufd_physical_attach_ioas);
> >
> > +void vfio_iommufd_physical_detach_ioas(struct vfio_device *vdev)
> > +{
> > + lockdep_assert_held(>dev_set->lock);
> > +
> > + if (!vdev->iommufd_device || !vdev->iommufd_attached)
> > + return;
>
> Same
Sure. Will apply same warn when above comment is aligned.
Regards,
Yi Liu
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/pxp: Add MTL PXP Support (rev6)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev6) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit'
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 2:39 AM
>
> On Mon, Feb 27, 2023 at 03:11:33AM -0800, Yi Liu wrote:
> > This adds ioctl for userspace to attach device cdev fd to and detach
> > from IOAS/hw_pagetable managed by iommufd.
> >
> > VFIO_DEVICE_ATTACH_IOMMUFD_PT: attach vfio device to IOAS,
> hw_pagetable
> >managed by iommufd. Attach can be
> >undo by
> VFIO_DEVICE_DETACH_IOMMUFD_PT
> >or device fd close.
> > VFIO_DEVICE_DETACH_IOMMUFD_PT: detach vfio device from the
> current attached
> >IOAS or hw_pagetable managed by
> iommufd.
> >
> > Signed-off-by: Yi Liu
> > Reviewed-by: Kevin Tian
> > ---
> > drivers/vfio/device_cdev.c | 76
> ++
> > drivers/vfio/vfio.h| 16
> > drivers/vfio/vfio_main.c | 8
> > include/uapi/linux/vfio.h | 52 ++
> > 4 files changed, 152 insertions(+)
> >
> > diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
> > index 37f80e368551..5b5a249a6612 100644
> > --- a/drivers/vfio/device_cdev.c
> > +++ b/drivers/vfio/device_cdev.c
> > @@ -191,6 +191,82 @@ long vfio_device_ioctl_bind_iommufd(struct
> vfio_device_file *df,
> > return ret;
> > }
> >
> > +int vfio_ioctl_device_attach(struct vfio_device_file *df,
> > +void __user *arg)
>
> This should be
>
> struct vfio_device_attach_iommufd_pt __user *arg
Got it.
> > +{
> > + struct vfio_device *device = df->device;
> > + struct vfio_device_attach_iommufd_pt attach;
> > + unsigned long minsz;
> > + int ret;
> > +
> > + minsz = offsetofend(struct vfio_device_attach_iommufd_pt, pt_id);
> > +
> > + if (copy_from_user(, (void __user *)arg, minsz))
>
> No cast
Yes.
> > + return -EFAULT;
> > +
> > + if (attach.argsz < minsz || attach.flags ||
> > + attach.pt_id == IOMMUFD_INVALID_ID)
> > + return -EINVAL;
> > +
> > + if (!device->ops->bind_iommufd)
> > + return -ENODEV;
> > +
> > + mutex_lock(>dev_set->lock);
> > + if (df->noiommu) {
> > + ret = -EINVAL;
> > + goto out_unlock;
> > + }
> > +
> > + ret = device->ops->attach_ioas(device, _id);
> > + if (ret)
> > + goto out_unlock;
> > +
> > + ret = copy_to_user((void __user *)arg +
> > + offsetofend(struct
> vfio_device_attach_iommufd_pt, flags),
>
> This should just be >flags
Yes, can use arg->xxx here. I guess you mean >pt_id.
>
> > + _id,
> > + sizeof(attach.pt_id)) ? -EFAULT : 0;
>
> Also:
>
> static_assert(__same_type(arg->flags), attach.pt_id);
Got it. but s/arg->flags/arg->pt_id/
> > + if (ret)
> > + goto out_detach;
> > + mutex_unlock(>dev_set->lock);
> > +
> > + return 0;
> > +
> > +out_detach:
> > + device->ops->detach_ioas(device);
>
>
> > +out_unlock:
> > + mutex_unlock(>dev_set->lock);
> > + return ret;
> > +}
> > +
> > +int vfio_ioctl_device_detach(struct vfio_device_file *df,
> > +void __user *arg)
> > +{
> > + struct vfio_device *device = df->device;
> > + struct vfio_device_detach_iommufd_pt detach;
> > + unsigned long minsz;
> > +
> > + minsz = offsetofend(struct vfio_device_detach_iommufd_pt, flags);
> > +
> > + if (copy_from_user(, (void __user *)arg, minsz))
> > + return -EFAULT;
>
> Same comments here
Sure.
> > +
> > + if (detach.argsz < minsz || detach.flags)
> > + return -EINVAL;
> > +
> > + if (!device->ops->bind_iommufd)
> > + return -ENODEV;
> > +
> > + mutex_lock(>dev_set->lock);
> > + if (df->noiommu) {
> > + mutex_unlock(>dev_set->lock);
> > + return -EINVAL;
> > + }
>
> This seems strange. no iommu mode should have a NULL dev->iommufctx.
> Why do we have a df->noiommu at all?
This is due to the vfio_device_first_open(). Detail as below comment (part of
patch 0016).
+ /*
+* For group/container path, iommufd pointer is NULL when comes
+* into this helper. Its noiommu support is handled by
+* vfio_device_group_use_iommu()
+*
+* For iommufd compat mode, iommufd pointer here is a valid value.
+* Its noiommu support is in vfio_iommufd_bind().
+*
+* For device cdev path, iommufd pointer here is a valid value for
+* normal cases, but it is NULL if it's noiommu. Check df->noiommu
+* to differentiate cdev noiommu from the group/container path which
+* also passes NULL iommufd pointer in. If set then do nothing.
+*/
if (iommufd)
ret = vfio_iommufd_bind(device, iommufd, dev_id, pt_id);
- else
+ else if (!df->noiommu)
ret = vfio_device_group_use_iommu(device);
if (ret)
goto err_module_put;
Regards,
Yi Liu
[Intel-gfx] ✗ Fi.CI.BAT: failure for Fix error propagation amongst request
== Series Details == Series: Fix error propagation amongst request URL : https://patchwork.freedesktop.org/series/114451/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12789 -> Patchwork_114451v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_114451v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_114451v1, 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_114451v1/index.html Participating hosts (38 -> 37) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_114451v1: ### IGT changes ### Possible regressions * igt@i915_module_load@load: - bat-dg1-5: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/bat-dg1-5/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114451v1/bat-dg1-5/igt@i915_module_l...@load.html - bat-dg1-7: [PASS][3] -> [ABORT][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/bat-dg1-7/igt@i915_module_l...@load.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114451v1/bat-dg1-7/igt@i915_module_l...@load.html - bat-dg2-11: [PASS][5] -> [ABORT][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/bat-dg2-11/igt@i915_module_l...@load.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114451v1/bat-dg2-11/igt@i915_module_l...@load.html - bat-dg1-6: [PASS][7] -> [ABORT][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/bat-dg1-6/igt@i915_module_l...@load.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114451v1/bat-dg1-6/igt@i915_module_l...@load.html - bat-dg2-9: [PASS][9] -> [ABORT][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/bat-dg2-9/igt@i915_module_l...@load.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114451v1/bat-dg2-9/igt@i915_module_l...@load.html - bat-dg2-8: [PASS][11] -> [ABORT][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12789/bat-dg2-8/igt@i915_module_l...@load.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114451v1/bat-dg2-8/igt@i915_module_l...@load.html Build changes - * Linux: CI_DRM_12789 -> Patchwork_114451v1 CI-20190529: 20190529 CI_DRM_12789: 8589fd9227ca62484e8599cbd62216230c2c9a64 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7174: 55642b7805d6fc5b987b396c2bbfa46db654db4f @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114451v1: 8589fd9227ca62484e8599cbd62216230c2c9a64 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits e941bcdf0c5f drm/i915/gt: Make sure that errors are propagated through request chains 6b53716b9933 drm/i915: Throttle for ringspace prior to taking the timeline mutex == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114451v1/index.html
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 2:30 AM
>
> On Mon, Feb 27, 2023 at 03:11:26AM -0800, Yi Liu wrote:
> > For the device fd opened from cdev, userspace needs to bind it to an
> > iommufd and attach it to IOAS managed by iommufd. With such
> operations,
> > userspace can set up a secure DMA context and hence access device.
> >
> > This changes the existing vfio_iommufd_bind() to accept a pt_id pointer
> > as an optional input, and also an dev_id pointer to selectively return
> > the dev_id to prepare for adding bind_iommufd ioctl, which does the bind
> > first and then attach IOAS.
> >
> > Signed-off-by: Yi Liu
> > Reviewed-by: Kevin Tian
> > ---
> > drivers/vfio/group.c | 17 ++---
> > drivers/vfio/iommufd.c | 21 +
> > drivers/vfio/vfio.h | 9 ++---
> > drivers/vfio/vfio_main.c | 10 ++
> > 4 files changed, 35 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> > index d8771d585cb1..e44232551448 100644
> > --- a/drivers/vfio/group.c
> > +++ b/drivers/vfio/group.c
> > @@ -169,6 +169,7 @@ static void
> vfio_device_group_get_kvm_safe(struct vfio_device *device)
> > static int vfio_device_group_open(struct vfio_device_file *df)
> > {
> > struct vfio_device *device = df->device;
> > + u32 ioas_id;
> > int ret;
> >
> > mutex_lock(>group->group_lock);
> > @@ -177,6 +178,13 @@ static int vfio_device_group_open(struct
> vfio_device_file *df)
> > goto out_unlock;
> > }
> >
> > + if (device->group->iommufd) {
> > + ret = iommufd_vfio_compat_ioas_id(device->group-
> >iommufd,
> > + _id);
> > + if (ret)
> > + goto out_unlock;
> > + }
>
> I don't really like this being moved out of iommufd.c
>
> Pass in a NULL pt_id and the do some
>
> > -int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx
> *ictx)
> > +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx
> *ictx,
> > + u32 *dev_id, u32 *pt_id)
> > {
> > - u32 ioas_id;
> > u32 device_id;
> > int ret;
> >
> > @@ -29,17 +29,14 @@ int vfio_iommufd_bind(struct vfio_device *vdev,
> struct iommufd_ctx *ictx)
> > if (ret)
> > return ret;
> >
> > - ret = iommufd_vfio_compat_ioas_id(ictx, _id);
> > - if (ret)
> > - goto err_unbind;
>
> io_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx,
> u32 *dev_id, u32 *pt_id)
> {
>u32 tmp_pt_id;
>if (!pt_id) {
>pt_id = _pt_id;
>ret = iommufd_vfio_compat_ioas_id(ictx, pt_id);
>if (ret)
> goto err_unbind;
>
>}
>
> To handle it
>
> And the commit message is sort of out of sync with the patch, more like:
>
> vfio: Pass the pt_id as an argument to vfio_iommufd_bind()
>
> To support binding the cdev the pt_id must come from userspace instead
> of being forced to the compat_ioas_id.
>
Got it. not only pt_id, also dev_id.
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Jason Gunthorpe
> Sent: Tuesday, February 28, 2023 2:23 AM
>
> On Mon, Feb 27, 2023 at 03:11:25AM -0800, Yi Liu wrote:
> > to indicate kernel to use the device's bound iommufd_ctx for the device
> > ownership check. Kernel should loop all the opened devices in the
> dev_set,
> > and check if they are bound to the same iommufd_ctx. For the devices
> that
> > has not been opened yet but affected, they can be reset by the current
> > users as they cannot be opened by any other user. This applies to the
> > existing group/container path as well.
> >
> > Suggested-by: Jason Gunthorpe
> > Signed-off-by: Yi Liu
> > ---
> > drivers/vfio/pci/vfio_pci_core.c | 111 +++---
> -
> > drivers/vfio/vfio.h | 11 +++
> > include/uapi/linux/vfio.h| 16 +
> > 3 files changed, 109 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> > index 1bf54beeaef2..e0ebe55b4df0 100644
> > --- a/drivers/vfio/pci/vfio_pci_core.c
> > +++ b/drivers/vfio/pci/vfio_pci_core.c
> > @@ -27,11 +27,13 @@
> > #include
> > #include
> > #include
> > +#include
>
> Is this needed anymore?
No more. Will remove it.
> > #if IS_ENABLED(CONFIG_EEH)
> > #include
> > #endif
> >
> > #include "vfio_pci_priv.h"
> > +#include "../vfio.h"
>
> Don't do this, put vfio_device_iommufd() in the normal public header
Ok. will put it in include/linux/vfio.h
> > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> > index 0552e8dcf0cb..4bf11ee8de53 100644
> > --- a/include/uapi/linux/vfio.h
> > +++ b/include/uapi/linux/vfio.h
> > @@ -673,6 +673,22 @@ struct vfio_pci_hot_reset_info {
> > * VFIO_DEVICE_PCI_HOT_RESET - _IOW(VFIO_TYPE, VFIO_BASE + 13,
> > * struct vfio_pci_hot_reset)
> > *
> > + * Userspace requests hot reset for the devices it uses. Due to the
> > + * underlying topology, multiple devices may be affected in the reset.
> > + * The affected devices may have been opened by the user or by other
> > + * users or not opened yet. Only when all the affected devices are
> > + * either opened by the current user or not opened by any user, should
> > + * the reset request be allowed. Otherwise, this request is expected
> > + * to return error.
> > + *
> > + * If the user uses group and container interface, it should pass down
> > + * a set of group fds for ownership check. If the user uses iommufd, it
> > + * should pass down a zero-length group_fds array to indicate the kernel
> > + * to use the bound iommufd for the ownership check. User that uses
> the
> > + * vfio iommufd compatible mode can also pass down a zero-length
> group_fds
> > + * array as this mode uses iommufd in kernel, and there is no reason to
> > + * forbide it.
>
> 'forbid'
Oh, yes. will correct it.
Regards,
Yi Liu
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fix error propagation amongst request
== Series Details == Series: Fix error propagation amongst request URL : https://patchwork.freedesktop.org/series/114451/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
[Intel-gfx] [PATCH v3 0/9] Add OAM support for MTL
The OAM unit captures OA reports specific to the media engines. Add support to program the OAM unit on media tile on MTL. The OAM unit is selected by passing the class:instance of a media engine to perf parameters. Corresponding UMD changes are posted to the igt-dev repo as part of supporting the GPUvis tool. v2: Incorporate review feedback (Jani, Ashutosh) v3: Incorporate review feedback (Jani, Ashutosh) Signed-off-by: Umesh Nerlige Ramappa Test-with: 20230215004648.2100655-1-umesh.nerlige.rama...@intel.com Chris Wilson (1): drm/i915/perf: Drop wakeref on GuC RC error Umesh Nerlige Ramappa (8): drm/i915/perf: Add helper to check supported OA engines drm/i915/perf: Validate OA sseu config outside switch drm/i915/perf: Group engines into respective OA groups drm/i915/perf: Fail modprobe if i915_perf_init fails on OOM drm/i915/perf: Parse 64bit report header formats correctly drm/i915/perf: Handle non-power-of-2 reports drm/i915/perf: Add engine class instance parameters to perf drm/i915/perf: Add support for OA media units drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 + drivers/gpu/drm/i915/gt/intel_sseu.c | 3 +- drivers/gpu/drm/i915/i915_driver.c | 4 +- drivers/gpu/drm/i915/i915_drv.h | 2 + drivers/gpu/drm/i915/i915_pci.c | 1 + drivers/gpu/drm/i915/i915_perf.c | 543 +++ drivers/gpu/drm/i915/i915_perf.h | 2 +- drivers/gpu/drm/i915/i915_perf_oa_regs.h | 78 +++ drivers/gpu/drm/i915/i915_perf_types.h | 75 ++- drivers/gpu/drm/i915/intel_device_info.h | 1 + include/uapi/drm/i915_drm.h | 26 + 11 files changed, 624 insertions(+), 121 deletions(-) -- 2.36.1
[Intel-gfx] [PATCH v3 5/9] drm/i915/perf: Fail modprobe if i915_perf_init fails on OOM
i915_perf_init can fail due to OOM. Fail driver init if i915_perf_init
fails.
v2: (Jani)
- Reorder patch in the series
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_driver.c | 4 +++-
drivers/gpu/drm/i915/i915_perf.c | 8 ++--
drivers/gpu/drm/i915/i915_perf.h | 2 +-
3 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 0c0ae3eabb4b..998ca41c9713 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -477,7 +477,9 @@ static int i915_driver_hw_probe(struct drm_i915_private
*dev_priv)
if (ret)
return ret;
- i915_perf_init(dev_priv);
+ ret = i915_perf_init(dev_priv);
+ if (ret)
+ return ret;
ret = i915_ggtt_probe_hw(dev_priv);
if (ret)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2554f7a470c9..2b80f0482884 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4903,7 +4903,7 @@ static void i915_perf_init_info(struct drm_i915_private
*i915)
* Note: i915-perf initialization is split into an 'init' and 'register'
* phase with the i915_perf_register() exposing state to userspace.
*/
-void i915_perf_init(struct drm_i915_private *i915)
+int i915_perf_init(struct drm_i915_private *i915)
{
struct i915_perf *perf = >perf;
@@ -5019,12 +5019,16 @@ void i915_perf_init(struct drm_i915_private *i915)
perf->i915 = i915;
ret = oa_init_engine_groups(perf);
- if (ret)
+ if (ret) {
drm_err(>drm,
"OA initialization failed %d\n", ret);
+ return ret;
+ }
oa_init_supported_formats(perf);
}
+
+ return 0;
}
static int destroy_config(int id, void *p, void *data)
diff --git a/drivers/gpu/drm/i915/i915_perf.h b/drivers/gpu/drm/i915/i915_perf.h
index f96e09a4af04..253637651d5e 100644
--- a/drivers/gpu/drm/i915/i915_perf.h
+++ b/drivers/gpu/drm/i915/i915_perf.h
@@ -18,7 +18,7 @@ struct i915_oa_config;
struct intel_context;
struct intel_engine_cs;
-void i915_perf_init(struct drm_i915_private *i915);
+int i915_perf_init(struct drm_i915_private *i915);
void i915_perf_fini(struct drm_i915_private *i915);
void i915_perf_register(struct drm_i915_private *i915);
void i915_perf_unregister(struct drm_i915_private *i915);
--
2.36.1
[Intel-gfx] [PATCH v3 6/9] drm/i915/perf: Parse 64bit report header formats correctly
Now that OA formats come in flavor of 64 bit reports, the report header
has 64 bit report-id, timestamp, context-id and gpu-ticks fields. When
filtering these reports, use the right width for these fields.
Note that upper dword of context id is reserved, so squash lower dword
only.
v2: (Ashutosh)
- Drop inline
- Update comment with dword definitions - report id and timestamp
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 109 +++--
drivers/gpu/drm/i915/i915_perf_types.h | 6 ++
2 files changed, 90 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2b80f0482884..b8f7ddf63530 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -441,6 +441,67 @@ static u32 gen7_oa_hw_tail_read(struct i915_perf_stream
*stream)
return oastatus1 & GEN7_OASTATUS1_TAIL_MASK;
}
+#define oa_report_header_64bit(__s) \
+ ((__s)->oa_buffer.format->header == HDR_64_BIT)
+
+static u64 oa_report_id(struct i915_perf_stream *stream, void *report)
+{
+ return oa_report_header_64bit(stream) ? *(u64 *)report : *(u32 *)report;
+}
+
+static u64 oa_report_reason(struct i915_perf_stream *stream, void *report)
+{
+ return (oa_report_id(stream, report) >> OAREPORT_REASON_SHIFT) &
+ (GRAPHICS_VER(stream->perf->i915) == 12 ?
+ OAREPORT_REASON_MASK_EXTENDED :
+ OAREPORT_REASON_MASK);
+}
+
+static void oa_report_id_clear(struct i915_perf_stream *stream, u32 *report)
+{
+ if (oa_report_header_64bit(stream))
+ *(u64 *)report = 0;
+ else
+ *report = 0;
+}
+
+static bool oa_report_ctx_invalid(struct i915_perf_stream *stream, void
*report)
+{
+ return !(oa_report_id(stream, report) &
+ stream->perf->gen8_valid_ctx_bit) &&
+ GRAPHICS_VER(stream->perf->i915) <= 11;
+}
+
+static u64 oa_timestamp(struct i915_perf_stream *stream, void *report)
+{
+ return oa_report_header_64bit(stream) ?
+ *((u64 *)report + 1) :
+ *((u32 *)report + 1);
+}
+
+static void oa_timestamp_clear(struct i915_perf_stream *stream, u32 *report)
+{
+ if (oa_report_header_64bit(stream))
+ *(u64 *)[2] = 0;
+ else
+ report[1] = 0;
+}
+
+static u32 oa_context_id(struct i915_perf_stream *stream, u32 *report)
+{
+ u32 ctx_id = oa_report_header_64bit(stream) ? report[4] : report[2];
+
+ return ctx_id & stream->specific_ctx_id_mask;
+}
+
+static void oa_context_id_squash(struct i915_perf_stream *stream, u32 *report)
+{
+ if (oa_report_header_64bit(stream))
+ report[4] = INVALID_CTX_ID;
+ else
+ report[2] = INVALID_CTX_ID;
+}
+
/**
* oa_buffer_check_unlocked - check for data and update tail ptr state
* @stream: i915 stream instance
@@ -509,21 +570,22 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
hw_tail -= gtt_offset;
tail = hw_tail;
- /* Walk the stream backward until we find a report with dword 0
-* & 1 not at 0. Since the circular buffer pointers progress by
-* increments of 64 bytes and that reports can be up to 256
-* bytes long, we can't tell whether a report has fully landed
-* in memory before the first 2 dwords of the following report
-* have effectively landed.
+ /* Walk the stream backward until we find a report with report
+* id and timestmap not at 0. Since the circular buffer pointers
+* progress by increments of 64 bytes and that reports can be up
+* to 256 bytes long, we can't tell whether a report has fully
+* landed in memory before the report id and timestamp of the
+* following report have effectively landed.
*
* This is assuming that the writes of the OA unit land in
* memory in the order they were written to.
* If not : (╯°□°）╯︵ ┻━┻
*/
while (OA_TAKEN(tail, aged_tail) >= report_size) {
- u32 *report32 = (void *)(stream->oa_buffer.vaddr +
tail);
+ void *report = stream->oa_buffer.vaddr + tail;
- if (report32[0] != 0 || report32[1] != 0)
+ if (oa_report_id(stream, report) ||
+ oa_timestamp(stream, report))
break;
tail = (tail - report_size) & (OA_BUFFER_SIZE - 1);
@@ -702,7 +764,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
u8 *report = oa_buf_base + head;
u32 *report32 = (void *)report;
u32 ctx_id;
- u32 reason;
+
[Intel-gfx] [PATCH v3 4/9] drm/i915/perf: Group engines into respective OA groups
Now that we may have multiple OA units in a single GT as well as on
separate GTs, create an engine group that maps to a single OA unit.
v2: (Jani)
- Drop warning on ENOMEM
- Reorder patch in the series
v3: (Ashutosh)
- Remove unused members from perf structs
- Update comments
- Update engine_supports_oa check
- Just return 1 in num_perf_groups_per_gt for now
- Set engine->oa_group to NULL to begin with
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 10 ++
drivers/gpu/drm/i915/gt/intel_sseu.c | 3 +-
drivers/gpu/drm/i915/i915_perf.c | 98 +---
drivers/gpu/drm/i915/i915_perf_types.h | 33 ++-
4 files changed, 125 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
b/drivers/gpu/drm/i915/gt/intel_engine_types.h
index 4fd54fb8810f..1a5fb4131ec2 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
@@ -53,6 +53,8 @@ struct intel_gt;
struct intel_ring;
struct intel_uncore;
struct intel_breadcrumbs;
+struct intel_engine_cs;
+struct i915_perf_group;
typedef u32 intel_engine_mask_t;
#define ALL_ENGINES ((intel_engine_mask_t)~0ul)
@@ -603,6 +605,14 @@ struct intel_engine_cs {
} props, defaults;
I915_SELFTEST_DECLARE(struct fault_attr reset_timeout);
+
+ /*
+* The perf group maps to one OA unit which controls one OA buffer. All
+* reports corresponding to this engine will be reported to this OA
+* buffer. An engine will map to a single OA unit, but a single OA unit
+* can generate reports for multiple engines.
+*/
+ struct i915_perf_group *oa_group;
};
static inline bool
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
index 6c6198a257ac..1141f875f5bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_sseu.c
+++ b/drivers/gpu/drm/i915/gt/intel_sseu.c
@@ -6,6 +6,7 @@
#include
#include "i915_drv.h"
+#include "i915_perf_types.h"
#include "intel_engine_regs.h"
#include "intel_gt_regs.h"
#include "intel_sseu.h"
@@ -677,7 +678,7 @@ u32 intel_sseu_make_rpcs(struct intel_gt *gt,
* If i915/perf is active, we want a stable powergating configuration
* on the system. Use the configuration pinned by i915/perf.
*/
- if (gt->perf.exclusive_stream)
+ if (gt->perf.group && gt->perf.group[PERF_GROUP_OAG].exclusive_stream)
req_sseu = >perf.sseu;
slices = hweight8(req_sseu->slice_mask);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 1229f65534e2..2554f7a470c9 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1572,20 +1572,16 @@ free_noa_wait(struct i915_perf_stream *stream)
static bool engine_supports_oa(const struct intel_engine_cs *engine)
{
- enum intel_platform platform = INTEL_INFO(engine->i915)->platform;
-
- switch (platform) {
- default:
- return engine->class == RENDER_CLASS;
- }
+ return engine->oa_group;
}
static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
{
struct i915_perf *perf = stream->perf;
struct intel_gt *gt = stream->engine->gt;
+ struct i915_perf_group *g = stream->engine->oa_group;
- if (WARN_ON(stream != gt->perf.exclusive_stream))
+ if (WARN_ON(stream != g->exclusive_stream))
return;
/*
@@ -1594,7 +1590,7 @@ static void i915_oa_stream_destroy(struct
i915_perf_stream *stream)
*
* See i915_oa_init_reg_state() and lrc_configure_all_contexts()
*/
- WRITE_ONCE(gt->perf.exclusive_stream, NULL);
+ WRITE_ONCE(g->exclusive_stream, NULL);
perf->ops.disable_metric_set(stream);
free_oa_buffer(stream);
@@ -3192,6 +3188,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
{
struct drm_i915_private *i915 = stream->perf->i915;
struct i915_perf *perf = stream->perf;
+ struct i915_perf_group *g;
struct intel_gt *gt;
int ret;
@@ -3201,6 +3198,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
return -EINVAL;
}
gt = props->engine->gt;
+ g = props->engine->oa_group;
/*
* If the sysfs metrics/ directory wasn't registered for some
@@ -3231,7 +3229,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
* counter reports and marshal to the appropriate client
* we currently only allow exclusive access
*/
- if (gt->perf.exclusive_stream) {
+ if (g->exclusive_stream) {
drm_dbg(>perf->i915->drm,
"OA unit already in use\n");
return -EBUSY;
@@ -3326,7 +3324,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
stream->ops = _oa_stream_ops;
[Intel-gfx] [PATCH v3 1/9] drm/i915/perf: Drop wakeref on GuC RC error
From: Chris Wilson
If we fail to adjust the GuC run-control on opening the perf stream,
make sure we unwind the wakeref just taken.
v2: Retain old goto label names (Ashutosh)
Fixes: 01e742746785 ("drm/i915/guc: Support OA when Wa_16011777198 is enabled")
Signed-off-by: Chris Wilson
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 14 +-
drivers/gpu/drm/i915/i915_perf_types.h | 6 ++
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 824a34ec0b83..283a4a3c6862 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1592,9 +1592,7 @@ static void i915_oa_stream_destroy(struct
i915_perf_stream *stream)
/*
* Wa_16011777198:dg2: Unset the override of GUCRC mode to enable rc6.
*/
- if (intel_uc_uses_guc_rc(>uc) &&
- (IS_DG2_GRAPHICS_STEP(gt->i915, G10, STEP_A0, STEP_C0) ||
-IS_DG2_GRAPHICS_STEP(gt->i915, G11, STEP_A0, STEP_B0)))
+ if (stream->override_gucrc)
drm_WARN_ON(>i915->drm,
intel_guc_slpc_unset_gucrc_mode(>uc.guc.slpc));
@@ -3305,8 +3303,10 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
if (ret) {
drm_dbg(>perf->i915->drm,
"Unable to override gucrc mode\n");
- goto err_config;
+ goto err_gucrc;
}
+
+ stream->override_gucrc = true;
}
ret = alloc_oa_buffer(stream);
@@ -3345,11 +3345,15 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
free_oa_buffer(stream);
err_oa_buf_alloc:
- free_oa_configs(stream);
+ if (stream->override_gucrc)
+ intel_guc_slpc_unset_gucrc_mode(>uc.guc.slpc);
+err_gucrc:
intel_uncore_forcewake_put(stream->uncore, FORCEWAKE_ALL);
intel_engine_pm_put(stream->engine);
+ free_oa_configs(stream);
+
err_config:
free_noa_wait(stream);
diff --git a/drivers/gpu/drm/i915/i915_perf_types.h
b/drivers/gpu/drm/i915/i915_perf_types.h
index ca150b7af3f2..e36f046fe2b6 100644
--- a/drivers/gpu/drm/i915/i915_perf_types.h
+++ b/drivers/gpu/drm/i915/i915_perf_types.h
@@ -316,6 +316,12 @@ struct i915_perf_stream {
* buffer should be checked for available data.
*/
u64 poll_oa_period;
+
+ /**
+* @override_gucrc: GuC RC has been overridden for the perf stream,
+* and we need to restore the default configuration on release.
+*/
+ bool override_gucrc:1;
};
/**
--
2.36.1
[Intel-gfx] [PATCH v3 9/9] drm/i915/perf: Add support for OA media units
MTL introduces additional OA units dedicated to media use cases. Add
support for programming these OA units by passing the media engine class
and instance parameters.
UMD specific changes for GPUvis support:
https://patchwork.freedesktop.org/patch/522827/?series=114023
https://patchwork.freedesktop.org/patch/522822/?series=114023
https://patchwork.freedesktop.org/patch/522826/?series=114023
https://patchwork.freedesktop.org/patch/522828/?series=114023
https://patchwork.freedesktop.org/patch/522816/?series=114023
https://patchwork.freedesktop.org/patch/522825/?series=114023
v2: (Ashutosh)
- check for IP_VER(12, 70) instead of MTL
- remove PERF_GROUP_OAG comment in mtl_oa_base
- remove oa_buffer.group
- use engine->oa_group->type in engine_supports_oa_format
- remove fw_domains and use FORCEWAKE_ALL
- remove MPES/MPEC comment
- s/xehp/mtl/ in b counter validation function name
- remove engine_supports_oa in __oa_engine_group
- remove warn_ON from __oam_engine_group
- refactor oa_init_groups and oa_init_regs
- assign g->type correctly
- use enum oa_type definition
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/i915_perf.c | 204 ---
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 78 +
drivers/gpu/drm/i915/i915_perf_types.h | 30
drivers/gpu/drm/i915/intel_device_info.h | 1 +
include/uapi/drm/i915_drm.h | 4 +
7 files changed, 296 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0393273faa09..f3cacbf41c86 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -856,6 +856,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
(INTEL_INFO(dev_priv)->has_oa_bpc_reporting)
#define HAS_OA_SLICE_CONTRIB_LIMITS(dev_priv) \
(INTEL_INFO(dev_priv)->has_oa_slice_contrib_limits)
+#define HAS_OAM(dev_priv) \
+ (INTEL_INFO(dev_priv)->has_oam)
/*
* Set this flag, when platform requires 64K GTT page sizes or larger for
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a8d942b16223..621730b6551c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1028,6 +1028,7 @@ static const struct intel_device_info adl_p_info = {
.has_mslice_steering = 1, \
.has_oa_bpc_reporting = 1, \
.has_oa_slice_contrib_limits = 1, \
+ .has_oam = 1, \
.has_rc6 = 1, \
.has_reset_engine = 1, \
.has_rps = 1, \
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 9d3db1edab64..0464e38f6db5 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,6 +192,7 @@
*/
#include
+#include
#include
#include
@@ -326,6 +327,12 @@ static const struct i915_oa_format
oa_formats[I915_OA_FORMAT_MAX] = {
[I915_OA_FORMAT_A32u40_A4u32_B8_C8] = { 5, 256 },
[I915_OAR_FORMAT_A32u40_A4u32_B8_C8]= { 5, 256 },
[I915_OA_FORMAT_A24u40_A14u32_B8_C8]= { 5, 256 },
+ [I915_OAM_FORMAT_MPEC8u64_B8_C8]= { 1, 192, TYPE_OAM,
HDR_64_BIT },
+ [I915_OAM_FORMAT_MPEC8u32_B8_C8]= { 2, 128, TYPE_OAM,
HDR_64_BIT },
+};
+
+static const u32 mtl_oa_base[] = {
+ [PERF_GROUP_OAM_SAMEDIA_0] = 0x393000,
};
#define SAMPLE_OA_REPORT (1<<0)
@@ -418,11 +425,17 @@ static void free_oa_config_bo(struct i915_oa_config_bo
*oa_bo)
kfree(oa_bo);
}
+static inline const
+struct i915_perf_regs *__oa_regs(struct i915_perf_stream *stream)
+{
+ return >engine->oa_group->regs;
+}
+
static u32 gen12_oa_hw_tail_read(struct i915_perf_stream *stream)
{
struct intel_uncore *uncore = stream->uncore;
- return intel_uncore_read(uncore, GEN12_OAG_OATAILPTR) &
+ return intel_uncore_read(uncore, __oa_regs(stream)->oa_tail_ptr) &
GEN12_OAG_OATAILPTR_MASK;
}
@@ -875,7 +888,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
i915_reg_t oaheadptr;
oaheadptr = GRAPHICS_VER(stream->perf->i915) == 12 ?
- GEN12_OAG_OAHEADPTR : GEN8_OAHEADPTR;
+ __oa_regs(stream)->oa_head_ptr :
+ GEN8_OAHEADPTR;
spin_lock_irqsave(>oa_buffer.ptr_lock, flags);
@@ -928,7 +942,8 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
return -EIO;
oastatus_reg = GRAPHICS_VER(stream->perf->i915) == 12 ?
- GEN12_OAG_OASTATUS : GEN8_OASTATUS;
+ __oa_regs(stream)->oa_status :
+ GEN8_OASTATUS;
oastatus = intel_uncore_read(uncore, oastatus_reg);
@@ -1632,11 +1647,28 @@ free_noa_wait(struct i915_perf_stream *stream)
i915_vma_unpin_and_release(>noa_wait, 0);
}
+/*
+ *
[Intel-gfx] [PATCH v3 7/9] drm/i915/perf: Handle non-power-of-2 reports
Some of the newer OA formats are not powers of 2. For those formats,
adjust the hw_tail accordingly when checking for new reports.
v2: (Ashutosh)
- Switch to OA_TAKEN for diff calculation
- Use OA_BUFFER_SIZE instead of the vma size
- Update comments
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 51 +---
1 file changed, 27 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index b8f7ddf63530..a8eb37be2aa2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -534,6 +534,7 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
bool pollin;
u32 hw_tail;
u64 now;
+ u32 partial_report_size;
/* We have to consider the (unlikely) possibility that read() errors
* could result in an OA buffer reset which might reset the head and
@@ -543,10 +544,15 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
hw_tail = stream->perf->ops.oa_hw_tail_read(stream);
- /* The tail pointer increases in 64 byte increments,
-* not in report_size steps...
+ /* The tail pointer increases in 64 byte increments, not in report_size
+* steps. Also the report size may not be a power of 2. Compute
+* potentially partially landed report in the OA buffer
*/
- hw_tail &= ~(report_size - 1);
+ partial_report_size = OA_TAKEN(hw_tail, stream->oa_buffer.tail);
+ partial_report_size %= report_size;
+
+ /* Subtract partial amount off the tail */
+ hw_tail = gtt_offset + OA_TAKEN(hw_tail, partial_report_size);
now = ktime_get_mono_fast_ns();
@@ -669,6 +675,8 @@ static int append_oa_sample(struct i915_perf_stream *stream,
{
int report_size = stream->oa_buffer.format->size;
struct drm_i915_perf_record_header header;
+ int report_size_partial;
+ u8 *oa_buf_end;
header.type = DRM_I915_PERF_RECORD_SAMPLE;
header.pad = 0;
@@ -682,8 +690,20 @@ static int append_oa_sample(struct i915_perf_stream
*stream,
return -EFAULT;
buf += sizeof(header);
- if (copy_to_user(buf, report, report_size))
+ oa_buf_end = stream->oa_buffer.vaddr + OA_BUFFER_SIZE;
+ report_size_partial = oa_buf_end - report;
+
+ if (report_size_partial < report_size) {
+ if (copy_to_user(buf, report, report_size_partial))
+ return -EFAULT;
+ buf += report_size_partial;
+
+ if (copy_to_user(buf, stream->oa_buffer.vaddr,
+report_size - report_size_partial))
+ return -EFAULT;
+ } else if (copy_to_user(buf, report, report_size)) {
return -EFAULT;
+ }
(*offset) += header.size;
@@ -747,12 +767,11 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* An out of bounds or misaligned head or tail pointer implies a driver
* bug since we validate + align the tail pointers we read from the
* hardware and we are in full control of the head pointer which should
-* only be incremented by multiples of the report size (notably also
-* all a power of two).
+* only be incremented by multiples of the report size.
*/
if (drm_WARN_ONCE(>i915->drm,
- head > OA_BUFFER_SIZE || head % report_size ||
- tail > OA_BUFFER_SIZE || tail % report_size,
+ head > OA_BUFFER_SIZE ||
+ tail > OA_BUFFER_SIZE,
"Inconsistent OA buffer pointers: head = %u, tail =
%u\n",
head, tail))
return -EIO;
@@ -766,22 +785,6 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
u32 ctx_id;
u64 reason;
- /*
-* All the report sizes factor neatly into the buffer
-* size so we never expect to see a report split
-* between the beginning and end of the buffer.
-*
-* Given the initial alignment check a misalignment
-* here would imply a driver bug that would result
-* in an overrun.
-*/
- if (drm_WARN_ON(>i915->drm,
- (OA_BUFFER_SIZE - head) < report_size)) {
- drm_err(>i915->drm,
- "Spurious OA head ptr: non-integral report
offset\n");
- break;
- }
-
/*
* The reason field includes flags identifying what
* triggered this specific report (mostly timer
--
2.36.1
[Intel-gfx] [PATCH v3 8/9] drm/i915/perf: Add engine class instance parameters to perf
One or more engines map to a specific OA unit. All reports from these
engines are captured in the OA buffer managed by this OA unit.
Current i915 OA implementation supports only the OAG unit. OAG primarily
caters to render engine, so i915 OA uses render as the default engine
in the OA implementation. Since there are more OA units on newer
hardware that map to other engines, allow user to pass engine class and
instance to select and program specific OA units.
UMD specific changes for GPUvis support:
https://patchwork.freedesktop.org/patch/522827/?series=114023
https://patchwork.freedesktop.org/patch/522822/?series=114023
https://patchwork.freedesktop.org/patch/522826/?series=114023
https://patchwork.freedesktop.org/patch/522828/?series=114023
https://patchwork.freedesktop.org/patch/522816/?series=114023
https://patchwork.freedesktop.org/patch/522825/?series=114023
v2: (Ashutosh)
- Clarify commit message
- Add drm_dbg
- Clarify uapi description
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 60 ++--
include/uapi/drm/i915_drm.h | 22
2 files changed, 55 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a8eb37be2aa2..9d3db1edab64 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4014,47 +4014,29 @@ static int read_properties_unlocked(struct i915_perf
*perf,
struct drm_i915_gem_context_param_sseu user_sseu;
u64 __user *uprop = uprops;
bool config_sseu = false;
+ u8 class, instance;
u32 i;
int ret;
memset(props, 0, sizeof(struct perf_open_properties));
props->poll_oa_period = DEFAULT_POLL_PERIOD_NS;
- if (!n_props) {
- drm_dbg(>i915->drm,
- "No i915 perf properties given\n");
- return -EINVAL;
- }
-
- /* At the moment we only support using i915-perf on the RCS. */
- props->engine = intel_engine_lookup_user(perf->i915,
-I915_ENGINE_CLASS_RENDER,
-0);
- if (!props->engine) {
- drm_dbg(>i915->drm,
- "No RENDER-capable engines\n");
- return -EINVAL;
- }
-
- if (!engine_supports_oa(props->engine)) {
- drm_dbg(>i915->drm,
- "Engine not supported by OA %d:%d\n",
- I915_ENGINE_CLASS_RENDER, 0);
- return -EINVAL;
- }
-
/* Considering that ID = 0 is reserved and assuming that we don't
* (currently) expect any configurations to ever specify duplicate
* values for a particular property ID then the last _PROP_MAX value is
* one greater than the maximum number of properties we expect to get
* from userspace.
*/
- if (n_props >= DRM_I915_PERF_PROP_MAX) {
+ if (!n_props || n_props >= DRM_I915_PERF_PROP_MAX) {
drm_dbg(>i915->drm,
- "More i915 perf properties specified than exist\n");
+ "Invalid number of i915 perf properties given\n");
return -EINVAL;
}
+ /* Defaults when class:instance is not passed */
+ class = I915_ENGINE_CLASS_RENDER;
+ instance = 0;
+
for (i = 0; i < n_props; i++) {
u64 oa_period, oa_freq_hz;
u64 id, value;
@@ -4175,7 +4157,13 @@ static int read_properties_unlocked(struct i915_perf
*perf,
}
props->poll_oa_period = value;
break;
- case DRM_I915_PERF_PROP_MAX:
+ case DRM_I915_PERF_PROP_OA_ENGINE_CLASS:
+ class = (u8)value;
+ break;
+ case DRM_I915_PERF_PROP_OA_ENGINE_INSTANCE:
+ instance = (u8)value;
+ break;
+ default:
MISSING_CASE(id);
return -EINVAL;
}
@@ -4183,6 +4171,21 @@ static int read_properties_unlocked(struct i915_perf
*perf,
uprop += 2;
}
+ props->engine = intel_engine_lookup_user(perf->i915, class, instance);
+ if (!props->engine) {
+ drm_dbg(>i915->drm,
+ "OA engine class and instance invalid %d:%d\n",
+ class, instance);
+ return -EINVAL;
+ }
+
+ if (!engine_supports_oa(props->engine)) {
+ drm_dbg(>i915->drm,
+ "Engine not supported by OA %d:%d\n",
+ class, instance);
+ return -EINVAL;
+ }
+
if (config_sseu) {
ret = get_sseu_config(>sseu, props->engine, _sseu);
if (ret) {
@@ -5159,8 +5162,11 @@ int
[Intel-gfx] [PATCH v3 3/9] drm/i915/perf: Validate OA sseu config outside switch
Once OA supports media engine class:instance, the engine can only be
validated outside the switch since class and instance parameters are
separate entities. Since OA sseu config depends on engine
class:instance, validate OA sseu config outside the switch.
v2: (Ashutosh)
- Clarify commit message
- Use drm_dbg instead of DRM_DEBUG
- Reorder stack variables
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index b0e1acbe90fc..1229f65534e2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3950,7 +3950,9 @@ static int read_properties_unlocked(struct i915_perf
*perf,
u32 n_props,
struct perf_open_properties *props)
{
+ struct drm_i915_gem_context_param_sseu user_sseu;
u64 __user *uprop = uprops;
+ bool config_sseu = false;
u32 i;
int ret;
@@ -4079,8 +4081,6 @@ static int read_properties_unlocked(struct i915_perf
*perf,
props->hold_preemption = !!value;
break;
case DRM_I915_PERF_PROP_GLOBAL_SSEU: {
- struct drm_i915_gem_context_param_sseu user_sseu;
-
if (GRAPHICS_VER_FULL(perf->i915) >= IP_VER(12, 50)) {
drm_dbg(>i915->drm,
"SSEU config not supported on gfx %x\n",
@@ -4095,14 +4095,7 @@ static int read_properties_unlocked(struct i915_perf
*perf,
"Unable to copy global sseu
parameter\n");
return -EFAULT;
}
-
- ret = get_sseu_config(>sseu, props->engine,
_sseu);
- if (ret) {
- drm_dbg(>i915->drm,
- "Invalid SSEU configuration\n");
- return ret;
- }
- props->has_sseu = true;
+ config_sseu = true;
break;
}
case DRM_I915_PERF_PROP_POLL_OA_PERIOD:
@@ -4122,6 +4115,16 @@ static int read_properties_unlocked(struct i915_perf
*perf,
uprop += 2;
}
+ if (config_sseu) {
+ ret = get_sseu_config(>sseu, props->engine, _sseu);
+ if (ret) {
+ drm_dbg(>i915->drm,
+ "Invalid SSEU configuration\n");
+ return ret;
+ }
+ props->has_sseu = true;
+ }
+
return 0;
}
--
2.36.1
[Intel-gfx] [PATCH v3 2/9] drm/i915/perf: Add helper to check supported OA engines
With an intention to add more engines that are supported by OA, add
helper to check for supported OA engines.
v2: (Ashutosh)
- Update commit message
- Drop virtual engine check since we support only one render engine
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 283a4a3c6862..b0e1acbe90fc 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1570,6 +1570,16 @@ free_noa_wait(struct i915_perf_stream *stream)
i915_vma_unpin_and_release(>noa_wait, 0);
}
+static bool engine_supports_oa(const struct intel_engine_cs *engine)
+{
+ enum intel_platform platform = INTEL_INFO(engine->i915)->platform;
+
+ switch (platform) {
+ default:
+ return engine->class == RENDER_CLASS;
+ }
+}
+
static void i915_oa_stream_destroy(struct i915_perf_stream *stream)
{
struct i915_perf *perf = stream->perf;
@@ -2505,7 +2515,7 @@ static int gen8_configure_context(struct i915_gem_context
*ctx,
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
GEM_BUG_ON(ce == ce->engine->kernel_context);
- if (ce->engine->class != RENDER_CLASS)
+ if (!engine_supports_oa(ce->engine))
continue;
/* Otherwise OA settings will be set upon first use */
@@ -2656,7 +2666,7 @@ oa_configure_all_contexts(struct i915_perf_stream *stream,
for_each_uabi_engine(engine, i915) {
struct intel_context *ce = engine->kernel_context;
- if (engine->class != RENDER_CLASS)
+ if (!engine_supports_oa(ce->engine))
continue;
regs[0].value = intel_sseu_make_rpcs(engine->gt, >sseu);
@@ -3369,7 +3379,7 @@ void i915_oa_init_reg_state(const struct intel_context
*ce,
{
struct i915_perf_stream *stream;
- if (engine->class != RENDER_CLASS)
+ if (!engine_supports_oa(engine))
return;
/* perf.exclusive_stream serialised by lrc_configure_all_contexts() */
--
2.36.1
[Intel-gfx] [PATCH v6 8/8] drm/i915/pxp: Enable PXP with MTL-GSC-CS
Enable PXP with MTL-GSC-CS: add the has_pxp into device info
and increase the debugfs teardown timeouts to align with
new GSC-CS + firmware specs.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 9 -
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 2 +-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index a8d942b16223..4ecf0f2ab6ec 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1150,6 +1150,7 @@ static const struct intel_device_info mtl_info = {
.has_guc_deprivilege = 1,
.has_mslice_steering = 0,
.has_snoop = 1,
+ .has_pxp = 1,
.__runtime.memory_regions = REGION_SMEM | REGION_STOLEN_LMEM,
.__runtime.platform_engine_mask = BIT(RCS0) | BIT(BCS0) | BIT(CCS0),
.require_force_probe = 1,
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 9f6e300486b4..ddf9f8bb7791 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_debugfs.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_types.h"
@@ -45,6 +46,7 @@ static int pxp_terminate_set(void *data, u64 val)
{
struct intel_pxp *pxp = data;
struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
+ int timeout_ms;
if (!intel_pxp_is_active(pxp))
return -ENODEV;
@@ -54,8 +56,13 @@ static int pxp_terminate_set(void *data, u64 val)
intel_pxp_irq_handler(pxp,
GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT);
spin_unlock_irq(gt->irq_lock);
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ timeout_ms = GSC_PENDING_RETRY_LATENCY_MS;
+ else
+ timeout_ms = 250;
+
if (!wait_for_completion_timeout(>termination,
-msecs_to_jiffies(100)))
+msecs_to_jiffies(timeout_ms)))
return -ETIMEDOUT;
return 0;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
index 4ddf2ee60222..03f006f9dc2e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_session.c
@@ -44,7 +44,7 @@ static int pxp_wait_for_session_state(struct intel_pxp *pxp,
u32 id, bool in_pla
KCR_SIP(pxp->kcr_base),
mask,
in_play ? mask : 0,
- 100);
+ 250);
intel_runtime_pm_put(uncore->rpm, wakeref);
--
2.39.0
[Intel-gfx] [PATCH v6 6/8] drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0
Despite KCR subsystem being in the media-tile (close to the
GSC-CS), the IRQ controls for it are on GT-0 with other global
IRQ controls. Thus, add a helper for KCR hw interrupt
enable/disable functions to get the correct gt structure (for
uncore) for MTL.
In the helper, we get GT-0's handle for uncore when touching
IRQ registers despite the pxp->ctrl_gt being the media-tile.
No difference for legacy of course.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c | 2 +-
drivers/gpu/drm/i915/pxp/intel_pxp_irq.c | 24 +---
drivers/gpu/drm/i915/pxp/intel_pxp_irq.h | 8 +++
3 files changed, 30 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
index 4b8e70caa3ad..9f6e300486b4 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_debugfs.c
@@ -44,7 +44,7 @@ static int pxp_terminate_get(void *data, u64 *val)
static int pxp_terminate_set(void *data, u64 val)
{
struct intel_pxp *pxp = data;
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
if (!intel_pxp_is_active(pxp))
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
index 91e9622c07d0..3a725397349f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.c
@@ -4,10 +4,12 @@
*/
#include
+#include "gt/intel_gt.h"
#include "gt/intel_gt_irq.h"
#include "gt/intel_gt_regs.h"
#include "gt/intel_gt_types.h"
+#include "i915_drv.h"
#include "i915_irq.h"
#include "i915_reg.h"
@@ -17,6 +19,22 @@
#include "intel_pxp_types.h"
#include "intel_runtime_pm.h"
+/**
+ * intel_pxp_get_irq_gt - Find the correct GT that owns KCR interrupts
+ * @pxp: pointer to pxp struct
+ *
+ * For platforms with a single GT, we return the pxp->ctrl_gt (as expected)
+ * but for MTL+ that has a media-tile, although the KCR engine is in the
+ * media-tile (i.e. pxp->ctrl_gt), the IRQ controls are on the root tile.
+ * In the end, we don't use pxp->ctrl_gt for IRQ, we always return root gt.
+ */
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ WARN_ON_ONCE(!pxp->ctrl_gt->i915->media_gt &&
!gt_is_root(pxp->ctrl_gt));
+
+ return to_gt(pxp->ctrl_gt->i915);
+}
+
/**
* intel_pxp_irq_handler - Handles PXP interrupts.
* @pxp: pointer to pxp struct
@@ -29,7 +47,7 @@ void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
if (GEM_WARN_ON(!intel_pxp_is_enabled(pxp)))
return;
- gt = pxp->ctrl_gt;
+ gt = intel_pxp_get_irq_gt(pxp);
lockdep_assert_held(gt->irq_lock);
@@ -68,7 +86,7 @@ static inline void pxp_irq_reset(struct intel_gt *gt)
void intel_pxp_irq_enable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
spin_lock_irq(gt->irq_lock);
@@ -83,7 +101,7 @@ void intel_pxp_irq_enable(struct intel_pxp *pxp)
void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
- struct intel_gt *gt = pxp->ctrl_gt;
+ struct intel_gt *gt = intel_pxp_get_irq_gt(pxp);
/*
* We always need to submit a global termination when we re-enable the
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
index 8c292dc86f68..eea87c9eb62b 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_irq.h
@@ -9,6 +9,7 @@
#include
struct intel_pxp;
+struct intel_gt;
#define GEN12_DISPLAY_PXP_STATE_TERMINATED_INTERRUPT BIT(1)
#define GEN12_DISPLAY_APP_TERMINATED_PER_FW_REQ_INTERRUPT BIT(2)
@@ -23,6 +24,8 @@ struct intel_pxp;
void intel_pxp_irq_enable(struct intel_pxp *pxp);
void intel_pxp_irq_disable(struct intel_pxp *pxp);
void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir);
+struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp);
+
#else
static inline void intel_pxp_irq_handler(struct intel_pxp *pxp, u16 iir)
{
@@ -35,6 +38,11 @@ static inline void intel_pxp_irq_enable(struct intel_pxp
*pxp)
static inline void intel_pxp_irq_disable(struct intel_pxp *pxp)
{
}
+
+static inline struct intel_gt *intel_pxp_get_irq_gt(struct intel_pxp *pxp)
+{
+ return NULL;
+}
#endif
#endif /* __INTEL_PXP_IRQ_H__ */
--
2.39.0
[Intel-gfx] [PATCH v6 5/8] drm/i915/pxp: Add ARB session creation and cleanup
Add MTL's function for ARB session creation using PXP firmware
version 4.3 ABI structure format.
Also add MTL's function for ARB session invalidation but this
reuses PXP firmware version 4.2 ABI structure format.
Before checking the return status, look at the GSC-CS-Mem-Header's
pending-bit which means the GSC firmware is busy and we should
resubmit.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp.c | 34 --
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 21 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 62 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 4 ++
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 11 +++-
5 files changed, 126 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index aecc65b5da70..61041277be24 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -290,6 +290,8 @@ static bool pxp_component_bound(struct intel_pxp *pxp)
static int __pxp_global_teardown_final(struct intel_pxp *pxp)
{
+ int timeout;
+
if (!pxp->arb_is_valid)
return 0;
/*
@@ -299,7 +301,12 @@ static int __pxp_global_teardown_final(struct intel_pxp
*pxp)
intel_pxp_mark_termination_in_progress(pxp);
intel_pxp_terminate(pxp, false);
- if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(250)))
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ timeout = GSC_PENDING_RETRY_LATENCY_MS;
+ else
+ timeout = 250;
+
+ if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
return 0;
@@ -307,6 +314,8 @@ static int __pxp_global_teardown_final(struct intel_pxp
*pxp)
static int __pxp_global_teardown_restart(struct intel_pxp *pxp)
{
+ int timeout;
+
if (pxp->arb_is_valid)
return 0;
/*
@@ -315,7 +324,12 @@ static int __pxp_global_teardown_restart(struct intel_pxp
*pxp)
*/
pxp_queue_termination(pxp);
- if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(250)))
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ timeout = GSC_PENDING_RETRY_LATENCY_MS;
+ else
+ timeout = 250;
+
+ if (!wait_for_completion_timeout(>termination,
msecs_to_jiffies(timeout)))
return -ETIMEDOUT;
return 0;
@@ -353,8 +367,20 @@ int intel_pxp_start(struct intel_pxp *pxp)
if (!intel_pxp_is_enabled(pxp))
return -ENODEV;
- if (wait_for(pxp_component_bound(pxp), 250))
- return -ENXIO;
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
+ /*
+* GSC-fw loading, GSC-proxy init (requiring an mei component
driver) and
+* HuC-fw loading must all occur first before we start
requesting for PXP
+* sessions. Checking HuC authentication (the last dependency)
will suffice.
+* Let's use a much larger 8 second timeout considering all the
types of
+* dependencies prior to that.
+*/
+ if (wait_for(intel_huc_is_authenticated(>ctrl_gt->uc.huc),
8000))
+ return -ENXIO;
+ } else {
+ if (wait_for(pxp_component_bound(pxp), 250))
+ return -ENXIO;
+ }
mutex_lock(>arb_mutex);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index b2523d6918c7..9089e02a8c2d 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -11,6 +11,7 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+#define PXP43_CMDID_INIT_SESSION 0x0036
/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
@@ -27,4 +28,24 @@ struct pxp43_start_huc_auth_out {
struct pxp_cmd_header header;
} __packed;
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_in {
+ struct pxp_cmd_header header;
+ /* header.stream_id fields for vesion 4.3 of Init PXP session:
*/
+ #define PXP43_INIT_SESSION_VALID BIT(0)
+ #define PXP43_INIT_SESSION_APPTYPE BIT(1)
+ #define PXP43_INIT_SESSION_APPID GENMASK(17, 2)
+ u32 protection_mode;
+ #define PXP43_INIT_SESSION_PROTECTION_ARB 0x2
+ u32 sub_session_id;
+ u32 init_flags;
+ u32 rsvd[12];
+} __packed;
+
+/* PXP-Input-Packet: Init PXP session */
+struct pxp43_create_arb_out {
+ struct pxp_cmd_header header;
+ u32 rsvd[8];
+} __packed;
+
#endif /* __INTEL_PXP_FW_INTERFACE_43_H__ */
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index
[Intel-gfx] [PATCH v6 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
Add GSC engine based method for sending PXP firmware packets
to the GSC firmware for MTL (and future) products.
Use the newly added helpers to populate the GSC-CS memory
header and send the message packet to the FW by dispatching
the GSC_HECI_CMD_PKT instruction on the GSC engine.
We use non-priveleged batches for submission to GSC engine
which require two buffers for the request:
- a buffer for the HECI packet that contains PXP FW commands
- a batch-buffer that contains the engine instruction for
sending the HECI packet to the GSC firmware.
Thus, add the allocation and freeing of these buffers in gsccs
init and fini.
The GSC-fw may reply to commands with a SUCCESS but with an
additional pending-bit set in the reply packet. This bit
means the GSC-FW is currently busy and the caller needs to
try again with the gsc_message_handle the fw gave. The
GSC-fw requires a non-zero host_session_handle provided
by the caller to enable gsc_message_handle tracking.
Thus, allocate the host_session_handle at init and destroy it
at fini (the latter requiring an FYI to the gsc-firmware).
Also ensure the send-message function allows replay of the
gsc_message_handle.
Signed-off-by: Alan Previn
---
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 4 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 239 +-
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 4 +
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 +
4 files changed, 251 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
index ad67e3f49c20..b2523d6918c7 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_cmd_interface_43.h
@@ -12,6 +12,10 @@
/* PXP-Cmd-Op definitions */
#define PXP43_CMDID_START_HUC_AUTH 0x003A
+/* PXP-Packet sizes for MTL's GSCCS-HECI instruction */
+#define PXP43_MAX_HECI_IN_SIZE (SZ_32K)
+#define PXP43_MAX_HECI_OUT_SIZE (SZ_32K)
+
/* PXP-Input-Packet: HUC-Authentication */
struct pxp43_start_huc_auth_in {
struct pxp_cmd_header header;
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
index 13693e78b57e..30aa660a975f 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,19 +6,226 @@
#include "gem/i915_gem_internal.h"
#include "gt/intel_context.h"
+#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_types.h"
+static int
+gsccs_send_message(struct intel_pxp *pxp,
+ void *msg_in, size_t msg_in_size,
+ void *msg_out, size_t msg_out_size_max,
+ size_t *msg_out_len,
+ u64 *gsc_msg_handle_retry)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct drm_i915_private *i915 = gt->i915;
+ struct gsccs_session_resources *exec = >gsccs_res;
+ struct intel_gsc_mtl_header *header = exec->pkt_vaddr;
+ struct intel_gsc_heci_non_priv_pkt pkt;
+ bool null_pkt = !msg_in && !msg_out;
+ size_t max_msg_size;
+ u32 reply_size;
+ int ret;
+
+ if (!exec->ce)
+ return -ENODEV;
+
+ max_msg_size = PXP43_MAX_HECI_IN_SIZE - sizeof(*header);
+
+ if (msg_in_size > max_msg_size || msg_out_size_max > max_msg_size)
+ return -ENOSPC;
+
+ if (!exec->pkt_vma || !exec->bb_vma)
+ return -ENOENT;
+
+ mutex_lock(>tee_mutex);
+
+ memset(header, 0, sizeof(*header));
+ intel_gsc_uc_heci_cmd_emit_mtl_header(header, GSC_HECI_MEADDRESS_PXP,
+ msg_in_size + sizeof(*header),
+ exec->host_session_handle);
+
+ /* check if this is a host-session-handle cleanup call */
+ if (null_pkt)
+ header->flags |= GSC_HECI_FLAG_MSG_CLEANUP;
+
+ /* copy caller provided gsc message handle if this is polling for a
prior msg completion */
+ header->gsc_message_handle = *gsc_msg_handle_retry;
+
+ /* NOTE: zero size packets are used for session-cleanups */
+ if (msg_in && msg_in_size)
+ memcpy(exec->pkt_vaddr + sizeof(*header), msg_in, msg_in_size);
+
+ pkt.addr_in = i915_vma_offset(exec->pkt_vma);
+ pkt.size_in = header->message_size;
+ pkt.addr_out = pkt.addr_in + PXP43_MAX_HECI_IN_SIZE;
+ pkt.size_out = msg_out_size_max + sizeof(*header);
+ pkt.heci_pkt_vma = exec->pkt_vma;
+ pkt.bb_vma = exec->bb_vma;
+
+ ret = intel_gsc_uc_heci_cmd_submit_nonpriv(>uc.gsc,
+ exec->ce, ,
exec->bb_vaddr,
+ GSC_REPLY_LATENCY_MS);
+ if (ret) {
+ drm_err(>drm, "failed to send gsc PXP
[Intel-gfx] [PATCH v6 0/8] drm/i915/pxp: Add MTL PXP Support
This series enables PXP on MTL. On ADL/TGL platforms, we rely on the mei driver via the i915-mei PXP component interface to establish a connection to the security firmware via the HECI device interface. That interface is used to create and teardown the PXP ARB session. PXP ARB session is created when protected contexts are created. In this series, the front end behaviors and interfaces (uapi) remain the same. We add backend support for MTL but with MTL we directly use the GSC-CS engine on the MTL GPU device to send messages to the PXP (a.k.a. GSC a.k.a graphics-security) firmware. With MTL, the format of the message is slightly different with a 2-layer packetization that is explained in detail in Patch #3. Also, the second layer which is the actual PXP firmware packet is now rev'd to version 4.3 for MTL that is defined in Patch #5. Take note that Patch #4 adds the buffer allocation and gsccs-send- message without actually being called by the arb-creation code which gets added in Patch #5. Additionally, a seperate series being reviewed is introducing a change for session teardown (in pxp front- end layer that will need backend support by both legacy and gsccs). If we squash all of these together (buffer-alloc, send-message, arb-creation and, in future, session-termination), the single patch will be rather large. That said, we are keeping Patch #4 and #5 separate for now, but at merge time, we can squash them together if maintainer requires it. Changes from prior revs: v1 : - fixed when building with CONFIG_PXP disabled. - more alignment with gsc_mtl_header structure from the HDCP v2 : - (all following changes as per reviews from Daniele) - squashed Patch #1 from v1 into the next one. - replaced unnecessary "uses_gsccs" boolean in the pxp with "HAS_ENGINE(pxp->ctrl_gt, GSC0)". - moved the stashing of gsccs resources from a dynamically allocated opaque handle to an explicit sub-struct in 'struct intel_pxp'. - moved the buffer object allocations from Patch #1 of this series to Patch #5 (but keep the context allocation in Patch #1). - used the kernel default ppgtt for the gsccs context. - optimized the buffer allocation and deallocation code and drop the need to stash the drm_i915_gem_object. - use a macro with the right mmio reg base (depending on root-tile vs media-tile) along with common relative offset to access all KCR registers thus minimizing changes to the KCR register access codes. - fixed bugs in the heci packet request submission code in Patch #3 (of this series) - add comments in the mtl-gsc-heci-header regarding the host-session-handle. - re-use tee-mutex instead of introducing a gsccs specific cmd mutex. - minor cosmetic improvements in Patch #5. - before creating arb session, ensure intel_pxp_start first ensures the GSC FW is up and running. - use 2 second timeout for the pending-bit scenario when sending command to GSC-FW as per specs. - simplify intel_pxp_get_irq_gt with addition comments - redo Patch #7 to minimize the changes without introducing a common abstraction helper for suspend/resume/init/fini codes that have to change the kcr power state. v3 : - rebase onto latest drm-tip with the updated firmware session invalidation flow - on Patch#1: move 'mutex_init(>tee_mutex)' to a common init place in intel_pxp_init since its needed everywhere (Daniele) - on Patch#1: remove unneccasary "ce->vm = i915_vm_get(vm);" (Daniele) - on Patch#2: move the introduction of host_session_handle to Patch#4 where it starts getting used. - on Patch#4: move host-session-handle initialization to the allocate-resources during gsccs-init (away from Patch#5) and add the required call to PXP-firmware to cleanup the host-session-handle in destroy-resources during gsccs-fini - on Patch#5: add dispatching of arb session termination firmware cmd during session teardown (as per latest upstream flows) v4 : - Added proper initialization and cleanup of host-session-handle that the gsc firmware expects. - Fix the stream-session-key invalidation instruction for MTL. v5 : - In Patch #4, move the tee_mutex locking to after we check for valid vma allocations. - In Patch #5, wait for intel_huc_is_authenticated instead of intel_uc_fw_is_running(gsc-fw) before starting ARB session. - In Patch #5, increase the necessary timeouts at the top-level (PXP arb session creation / termination) to accomodate SLA of GSC firmware when busy with pending-bit responses. - In Patch #5, remove redundant host_session_handle init
[Intel-gfx] [PATCH v6 2/8] drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation
Add MTL hw-plumbing enabling for KCR operation under PXP
which includes:
1. Updating 'pick-gt' to get the media tile for
KCR interrupt handling
2. Adding MTL's KCR registers for PXP operation
(init, status-checking, etc.).
While doing #2, lets create a separate registers header file for PXP
to be consistent with other i915 global subsystems.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 3 +-
drivers/gpu/drm/i915/pxp/intel_pxp.c | 32
drivers/gpu/drm/i915/pxp/intel_pxp_regs.h| 27 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 12 +++-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 6
5 files changed, 58 insertions(+), 22 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
index 1b25a6039152..c360776a98b5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_irq.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_irq.c
@@ -100,7 +100,8 @@ static struct intel_gt *pick_gt(struct intel_gt *gt, u8
class, u8 instance)
case VIDEO_ENHANCEMENT_CLASS:
return media_gt;
case OTHER_CLASS:
- if (instance == OTHER_GSC_INSTANCE && HAS_ENGINE(media_gt,
GSC0))
+ if ((instance == OTHER_GSC_INSTANCE || instance ==
OTHER_KCR_INSTANCE) &&
+ HAS_ENGINE(media_gt, GSC0))
return media_gt;
fallthrough;
default:
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 560d94d23114..aecc65b5da70 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -14,6 +14,7 @@
#include "intel_pxp.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
+#include "intel_pxp_regs.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
#include "intel_pxp_types.h"
@@ -61,21 +62,22 @@ bool intel_pxp_is_active(const struct intel_pxp *pxp)
return IS_ENABLED(CONFIG_DRM_I915_PXP) && pxp && pxp->arb_is_valid;
}
-/* KCR register definitions */
-#define KCR_INIT _MMIO(0x320f0)
-/* Setting KCR Init bit is required after system boot */
-#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+static void kcr_pxp_set_status(const struct intel_pxp *pxp, bool enable)
+{
+ u32 val = enable ? _MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES)
:
+ _MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES);
+
+ intel_uncore_write(pxp->ctrl_gt->uncore, KCR_INIT(pxp->kcr_base), val);
+}
-static void kcr_pxp_enable(struct intel_gt *gt)
+static void kcr_pxp_enable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_ENABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, true);
}
-static void kcr_pxp_disable(struct intel_gt *gt)
+static void kcr_pxp_disable(const struct intel_pxp *pxp)
{
- intel_uncore_write(gt->uncore, KCR_INIT,
-
_MASKED_BIT_DISABLE(KCR_INIT_ALLOW_DISPLAY_ME_WRITES));
+ kcr_pxp_set_status(pxp, false);
}
static int create_vcs_context(struct intel_pxp *pxp)
@@ -127,6 +129,11 @@ static void pxp_init_full(struct intel_pxp *pxp)
init_completion(>termination);
complete_all(>termination);
+ if (pxp->ctrl_gt->type == GT_MEDIA)
+ pxp->kcr_base = MTL_KCR_BASE;
+ else
+ pxp->kcr_base = GEN12_KCR_BASE;
+
intel_pxp_session_management_init(pxp);
ret = create_vcs_context(pxp);
@@ -368,14 +375,13 @@ int intel_pxp_start(struct intel_pxp *pxp)
void intel_pxp_init_hw(struct intel_pxp *pxp)
{
- kcr_pxp_enable(pxp->ctrl_gt);
+ kcr_pxp_enable(pxp);
intel_pxp_irq_enable(pxp);
}
void intel_pxp_fini_hw(struct intel_pxp *pxp)
{
- kcr_pxp_disable(pxp->ctrl_gt);
-
+ kcr_pxp_disable(pxp);
intel_pxp_irq_disable(pxp);
}
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
new file mode 100644
index ..a9e7e6efa4c7
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_regs.h
@@ -0,0 +1,27 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright(c) 2023, Intel Corporation. All rights reserved.
+ */
+
+#ifndef __INTEL_PXP_REGS_H__
+#define __INTEL_PXP_REGS_H__
+
+#include "i915_reg_defs.h"
+
+/* KCR subsystem register base address */
+#define GEN12_KCR_BASE 0x32000
+#define MTL_KCR_BASE 0x386000
+
+/* KCR enable/disable control */
+#define KCR_INIT(base) _MMIO((base) + 0xf0)
+
+/* Setting KCR Init bit is required after system boot */
+#define KCR_INIT_ALLOW_DISPLAY_ME_WRITES REG_BIT(14)
+
+/* KCR hwdrm session in play status 0-31 */
+#define KCR_SIP(base) _MMIO((base) + 0x260)
+
+/* PXP global terminate register for session termination */
+#define KCR_GLOBAL_TERMINATE(base)
[Intel-gfx] [PATCH v6 7/8] drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
On legacy platforms, KCR HW enabling is done at the time the mei
component interface is bound. It's also disabled during unbind.
However, for MTL onwards, we don't depend on a tee component
to start sending GSC-CS firmware messages.
Thus, immediately enable (or disable) KCR HW on PXP's init,
fini and resume.
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/pxp/intel_pxp.c| 19 +++
drivers/gpu/drm/i915/pxp/intel_pxp_pm.c | 3 ++-
2 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 61041277be24..e2f2cc5f6a6e 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -119,6 +119,7 @@ static void destroy_vcs_context(struct intel_pxp *pxp)
static void pxp_init_full(struct intel_pxp *pxp)
{
struct intel_gt *gt = pxp->ctrl_gt;
+ intel_wakeref_t wakeref;
int ret;
/*
@@ -140,10 +141,15 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0)) {
ret = intel_pxp_gsccs_init(pxp);
- else
+ if (!ret) {
+ with_intel_runtime_pm(>ctrl_gt->i915->runtime_pm,
wakeref)
+ intel_pxp_init_hw(pxp);
+ }
+ } else {
ret = intel_pxp_tee_component_init(pxp);
+ }
if (ret)
goto out_context;
@@ -239,15 +245,20 @@ int intel_pxp_init(struct drm_i915_private *i915)
void intel_pxp_fini(struct drm_i915_private *i915)
{
+ intel_wakeref_t wakeref;
+
if (!i915->pxp)
return;
i915->pxp->arb_is_valid = false;
- if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+ if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0)) {
+ with_intel_runtime_pm(>pxp->ctrl_gt->i915->runtime_pm,
wakeref)
+ intel_pxp_fini_hw(i915->pxp);
intel_pxp_gsccs_fini(i915->pxp);
- else
+ } else {
intel_pxp_tee_component_fini(i915->pxp);
+ }
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
index 4f836b317424..1a04067f61fc 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_pm.c
@@ -43,8 +43,9 @@ void intel_pxp_resume_complete(struct intel_pxp *pxp)
* The PXP component gets automatically unbound when we go into S3 and
* re-bound after we come out, so in that scenario we can defer the
* hw init to the bind call.
+* NOTE: GSC-CS backend doesn't rely on components.
*/
- if (!pxp->pxp_component)
+ if (!HAS_ENGINE(pxp->ctrl_gt, GSC0) && !pxp->pxp_component)
return;
intel_pxp_init_hw(pxp);
--
2.39.0
[Intel-gfx] [PATCH v6 1/8] drm/i915/pxp: Add GSC-CS back-end resource init and cleanup
For MTL, the PXP back-end transport uses the GSC engine to submit
HECI packets through the HW to the GSC firmware for PXP arb
session management. This submission uses a non-priveleged
batch buffer, a buffer for the command packet and of course
a context targeting the GSC-CS.
Thus for MTL, we need to allocate and free a set of execution
submission resources for the management of the arbitration session.
Lets start with the context creation first since that object and
its usage is very straight-forward. We'll add the buffer allocation
and freeing later when we introduce the gsccs' send-message function.
Do this one time allocation of gsccs specific resources in
a new gsccs source file with intel_pxp_gsccs_init / fini functions
and hook them up from the PXP front-end.
Signed-off-by: Alan Previn
Reviewed-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/pxp/intel_pxp.c | 19 +--
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c | 61 ++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h | 29 ++
drivers/gpu/drm/i915/pxp/intel_pxp_tee.c | 2 -
drivers/gpu/drm/i915/pxp/intel_pxp_types.h | 8 +++
6 files changed, 114 insertions(+), 6 deletions(-)
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
create mode 100644 drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b2f91a1f8268..ad5f2660808d 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -334,6 +334,7 @@ i915-y += \
i915-$(CONFIG_DRM_I915_PXP) += \
pxp/intel_pxp_cmd.o \
pxp/intel_pxp_debugfs.o \
+ pxp/intel_pxp_gsccs.o \
pxp/intel_pxp_irq.o \
pxp/intel_pxp_pm.o \
pxp/intel_pxp_session.o
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index 9d4c7724e98e..560d94d23114 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -12,6 +12,7 @@
#include "i915_drv.h"
#include "intel_pxp.h"
+#include "intel_pxp_gsccs.h"
#include "intel_pxp_irq.h"
#include "intel_pxp_session.h"
#include "intel_pxp_tee.h"
@@ -132,7 +133,10 @@ static void pxp_init_full(struct intel_pxp *pxp)
if (ret)
return;
- ret = intel_pxp_tee_component_init(pxp);
+ if (HAS_ENGINE(pxp->ctrl_gt, GSC0))
+ ret = intel_pxp_gsccs_init(pxp);
+ else
+ ret = intel_pxp_tee_component_init(pxp);
if (ret)
goto out_context;
@@ -165,9 +169,11 @@ static struct intel_gt
*find_gt_for_required_protected_content(struct drm_i915_p
/*
* For MTL onwards, PXP-controller-GT needs to have a valid GSC engine
* on the media GT. NOTE: if we have a media-tile with a GSC-engine,
-* the VDBOX is already present so skip that check
+* the VDBOX is already present so skip that check. We also have to
+* ensure the GSC firmware is coming online
*/
- if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0))
+ if (i915->media_gt && HAS_ENGINE(i915->media_gt, GSC0) &&
+ intel_uc_fw_is_loadable(>media_gt->uc.gsc.fw))
return i915->media_gt;
/*
@@ -207,7 +213,9 @@ int intel_pxp_init(struct drm_i915_private *i915)
if (!i915->pxp)
return -ENOMEM;
+ /* init common info used by all feature-mode usages*/
i915->pxp->ctrl_gt = gt;
+ mutex_init(>pxp->tee_mutex);
/*
* If full PXP feature is not available but HuC is loaded by GSC on
pre-MTL
@@ -229,7 +237,10 @@ void intel_pxp_fini(struct drm_i915_private *i915)
i915->pxp->arb_is_valid = false;
- intel_pxp_tee_component_fini(i915->pxp);
+ if (HAS_ENGINE(i915->pxp->ctrl_gt, GSC0))
+ intel_pxp_gsccs_fini(i915->pxp);
+ else
+ intel_pxp_tee_component_fini(i915->pxp);
destroy_vcs_context(i915->pxp);
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
new file mode 100644
index ..13693e78b57e
--- /dev/null
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright(c) 2023 Intel Corporation.
+ */
+
+#include "gem/i915_gem_internal.h"
+
+#include "gt/intel_context.h"
+
+#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_43.h"
+#include "intel_pxp_gsccs.h"
+#include "intel_pxp_types.h"
+
+static void
+gsccs_destroy_execution_resource(struct intel_pxp *pxp)
+{
+ struct gsccs_session_resources *strm_res = >gsccs_res;
+
+ if (strm_res->ce)
+ intel_context_put(strm_res->ce);
+
+ memset(strm_res, 0, sizeof(*strm_res));
+}
+
+static int
+gsccs_allocate_execution_resource(struct intel_pxp *pxp)
+{
+ struct intel_gt *gt = pxp->ctrl_gt;
+ struct gsccs_session_resources *strm_res =
[Intel-gfx] [PATCH v6 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
Add helper functions into a new file for heci-packet-submission.
The helpers will handle generating the MTL GSC-CS Memory-Header
and submission of the Heci-Cmd-Packet instructions to the engine.
NOTE1: These common functions for heci-packet-submission will be used
by different i915 callers:
1- GSC-SW-Proxy: This is pending upstream publication awaiting
a few remaining opens
2- MTL-HDCP: An equivalent patch has also been published at:
https://patchwork.freedesktop.org/series/111876/. (Patch 1)
3- PXP: This series.
NOTE2: A difference in this patch vs what is appearing is in bullet 2
above is that HDCP (and SW-Proxy) will be using priveleged submission
(GGTT and common gsc-uc-context) while PXP will be using non-priveleged
PPGTT, context and batch buffer. Therefore this patch will only slightly
overlap with the MTL-HDCP patches despite have very similar function
names (emit_foo vs emit_nonpriv_foo). This is because HECI_CMD_PKT
instructions require different flows and hw-specific code when done
via PPGTT based submission (not different from other engines). MTL-HDCP
contains the same intel_gsc_mtl_header_t structures as this but the
helpers there are different. Both add the same new file names.
NOTE3: Additional clarity about the heci-cmd-pkt layout and where the
common helpers come in:
- On MTL, when an i915 subsystem needs to send a command request
to the security firmware, it will send that via the GSC-
engine-command-streamer.
- However those commands, (lets call them "gsc_specific_fw_api"
calls), are not understood by the GSC command streamer hw.
- The GSC CS only looks at the GSC_HECI_CMD_PKT instruction and
passes it along to the GSC firmware.
- The GSC FW on the other hand needs additional metadata to know
which usage service is being called (PXP, HDCP, proxy, etc) along
with session specific info. Thus an extra header called GSC-CS
HECI Memory Header, (C) in below diagram is prepended before
the FW specific API, (D).
- Thus, the structural layout of the request submitted would
need to look like the diagram below (for non-priv PXP).
- In the diagram, the common helper for HDCP, (GSC-Sw-Proxy) and
PXP (i.e. new function intel_gsc_uc_heci_cmd_emit_mtl_header)
will populate blob (C) while additional helpers, different for
PPGGTT (this patch) vs GGTT (HDCP series) will populate
blobs (A) and (B) below.
___
(A) | MI_BATCH_BUFFER_START (ppgtt, batchbuff-addr, ...) |
| | |
|_| |
| (B)| GSC_HECI_CMD_PKT (pkt-addr-in, pkt-size-in,| |
|| pkt-addr-out, pkt-size-out) |
|| MI_BATCH_BUFFER_END| | |
||| | |
| | |
|_| |
|
-
|
\|/
__V___
| _|
|(C)| ||
| | struct intel_gsc_mtl_header { ||
| | validity marker ||
| | heci_clent_id ||
| | ... ||
| | }||
| |___||
|(D)| ||
| | struct gsc_fw_specific_api_foobar { ||
| | ... ||
| | For an example, see ||
| | 'struct pxp43_create_arb_in' at ||
| | intel_pxp_cmd_interface_43.h ||
| | ||
| | } ||
| | Struture depends on command type ||
| | struct gsc_fw_specific_api_foobar { ||
| |___||
||
That said, this patch provides basic helpers but leaves the
PXP subsystem (i.e. the caller) to handle (D) and everything
else such as input/output size verification or handling the
responses from security firmware (for example, requiring a retry).
Signed-off-by: Alan Previn
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +
.../i915/gt/uc/intel_gsc_uc_heci_cmd_submit.c | 108
[Intel-gfx] [PATCH v3 2/2] drm/i915/gt: Make sure that errors are propagated through request chains
Currently, when we perform operations such as clearing or copying
large blocks of memory, we generate multiple requests that are
executed in a chain.
However, if one of these requests fails, we may not realize it
unless it happens to be the last request in the chain. This is
because errors are not properly propagated.
For this we need to keep propagating the chain of fence
notification in order to always reach the final fence associated
to the final request.
To address this issue, we need to ensure that the chain of fence
notifications is always propagated so that we can reach the final
fence associated with the last request. By doing so, we will be
able to detect any memory operation failures and determine
whether the memory is still invalid.
On copy and clear migration signal fences upon completion.
On copy and clear migration, signal fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 39 ++---
1 file changed, 29 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 3f638f1987968..6b497640d3a0a 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context *ce,
dst_offset = 2 * CHUNK_SZ;
}
+ /*
+* While building the chain of requests, we need to ensure
+* that no one can sneak into the timeline unnoticed.
+*/
+ mutex_lock(>timeline->mutex);
+
do {
int len;
rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context *ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
- i915_request_put(*out);
- *out = i915_request_get(rq);
+ i915_sw_fence_await(>submit);
+ i915_request_get(rq);
i915_request_add(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
+ i915_request_put(*out);
+ }
+ *out = rq;
if (err)
break;
@@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce,
cond_resched();
} while (1);
-out_ce:
+ mutex_unlock(>timeline->mutex);
+
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
@@ -1005,7 +1018,7 @@ intel_context_migrate_clear(struct intel_context *ce,
rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -1056,17 +1069,23 @@ intel_context_migrate_clear(struct intel_context *ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
- i915_request_put(*out);
- *out = i915_request_get(rq);
+ i915_sw_fence_await(>submit);
+ i915_request_get(rq);
i915_request_add(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
+ i915_request_put(*out);
+ }
+ *out = rq;
+
if (err || !it.sg || !sg_dma_len(it.sg))
break;
cond_resched();
} while (1);
-out_ce:
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
--
2.39.1
[Intel-gfx] [PATCH v3 1/2] drm/i915: Throttle for ringspace prior to taking the timeline mutex
From: Chris Wilson
Before taking exclusive ownership of the ring for emitting the request,
wait for space in the ring to become available. This allows others to
take the timeline->mutex to make forward progresses while userspace is
blocked.
In particular, this allows regular clients to issue requests on the
kernel context, potentially filling the ring, but allow the higher
priority heartbeats and pulses to still be submitted without being
blocked by the less critical work.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Signed-off-by: Chris Wilson
Cc: Maciej Patelczyk
Cc: sta...@vger.kernel.org
Signed-off-by: Andi Shyti
---
Hi,
I'm not sure I need to add the Fixes tag here as this is more
preparatory for the next patch. Together, though, patch 1 and 2
make the fix with proper locking mechanism.
Andi
drivers/gpu/drm/i915/gt/intel_context.c | 41 +
drivers/gpu/drm/i915/gt/intel_context.h | 2 ++
drivers/gpu/drm/i915/i915_request.c | 3 ++
3 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 2aa63ec521b89..59cd612a23561 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -626,6 +626,47 @@ bool intel_context_revoke(struct intel_context *ce)
return ret;
}
+int intel_context_throttle(const struct intel_context *ce)
+{
+ const struct intel_ring *ring = ce->ring;
+ const struct intel_timeline *tl = ce->timeline;
+ struct i915_request *rq;
+ int err = 0;
+
+ if (READ_ONCE(ring->space) >= SZ_1K)
+ return 0;
+
+ rcu_read_lock();
+ list_for_each_entry_reverse(rq, >requests, link) {
+ if (__i915_request_is_complete(rq))
+ break;
+
+ if (rq->ring != ring)
+ continue;
+
+ /* Wait until there will be enough space following that rq */
+ if (__intel_ring_space(rq->postfix,
+ ring->emit,
+ ring->size) < ring->size / 2) {
+ if (i915_request_get_rcu(rq)) {
+ rcu_read_unlock();
+
+ if (i915_request_wait(rq,
+ I915_WAIT_INTERRUPTIBLE,
+ MAX_SCHEDULE_TIMEOUT) < 0)
+ err = -EINTR;
+
+ rcu_read_lock();
+ i915_request_put(rq);
+ }
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return err;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_context.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f43..f919a66cebf5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -226,6 +226,8 @@ static inline void intel_context_exit(struct intel_context
*ce)
ce->ops->exit(ce);
}
+int intel_context_throttle(const struct intel_context *ce);
+
static inline struct intel_context *intel_context_get(struct intel_context *ce)
{
kref_get(>ref);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043bb..a1741c4a8cffd 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1035,6 +1035,9 @@ i915_request_create(struct intel_context *ce)
struct i915_request *rq;
struct intel_timeline *tl;
+ if (intel_context_throttle(ce))
+ return ERR_PTR(-EINTR);
+
tl = intel_context_timeline_lock(ce);
if (IS_ERR(tl))
return ERR_CAST(tl);
--
2.39.1
[Intel-gfx] [PATCH v3 0/2] Fix error propagation amongst request
Hi,
This series of two patches fixes the issue introduced in
cf586021642d80 ("drm/i915/gt: Pipelined page migration") where,
as reported by Matt, in a chain of requests an error is reported
only if happens in the last request.
However Chris noticed that without ensuring exclusivity in the
locking we might end up in some deadlock. That's why patch 1
throttles for the ringspace in order to make sure that no one is
holding it.
Version 1 of this patch has been reviewed by matt and this
version is adding Chris exclusive locking.
Thanks Chris for this work.
Andi
Changelog
=
v1 -> v2
- Add patch 1 for ensuring exclusive locking of the timeline
- Reword git commit of patch 2.
Andi Shyti (1):
drm/i915/gt: Make sure that errors are propagated through request
chains
Chris Wilson (1):
drm/i915: Throttle for ringspace prior to taking the timeline mutex
drivers/gpu/drm/i915/gt/intel_context.c | 41 +
drivers/gpu/drm/i915/gt/intel_context.h | 2 ++
drivers/gpu/drm/i915/gt/intel_migrate.c | 39 +--
drivers/gpu/drm/i915/i915_request.c | 3 ++
4 files changed, 75 insertions(+), 10 deletions(-)
--
2.39.1
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
== Series Details ==
Series: series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock
hugepage selftests to live
URL : https://patchwork.freedesktop.org/series/114432/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12787_full -> Patchwork_114432v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_114432v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114432v1_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 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114432v1_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_shared@q-promotion@rcs0:
- shard-apl: NOTRUN -> [ABORT][1] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-apl6/igt@gem_ctx_shared@q-promot...@rcs0.html
* igt@gem_ctx_shared@q-promotion@vcs0:
- shard-apl: NOTRUN -> [DMESG-WARN][2] +2 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-apl6/igt@gem_ctx_shared@q-promot...@vcs0.html
* igt@gem_exec_fence@syncobj-timeline-export:
- shard-glk: NOTRUN -> [ABORT][3] +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-glk4/igt@gem_exec_fe...@syncobj-timeline-export.html
* igt@prime_vgem@basic-blt:
- shard-tglu-10: NOTRUN -> [ABORT][4] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-tglu-10/igt@prime_v...@basic-blt.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_eio@kms:
- {shard-tglu}: NOTRUN -> [ABORT][5] +4 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-tglu-4/igt@gem_...@kms.html
* igt@perf_pmu@interrupts-sync:
- {shard-dg1}:NOTRUN -> [ABORT][6] +4 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-dg1-14/igt@perf_...@interrupts-sync.html
Known issues
Here are the changes found in Patchwork_114432v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271]) +38 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-glk4/igt@feature_discov...@display-4x.html
* igt@gem_exec_fair@basic-pace@rcs0:
- shard-glk: NOTRUN -> [FAIL][8] ([i915#2842])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-glk5/igt@gem_exec_fair@basic-p...@rcs0.html
* igt@i915_pm_backlight@basic-brightness:
- shard-tglu-10: NOTRUN -> [SKIP][9] ([i915#7561])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-tglu-10/igt@i915_pm_backli...@basic-brightness.html
* igt@kms_big_fb@linear-32bpp-rotate-270:
- shard-tglu-10: NOTRUN -> [SKIP][10] ([fdo#111614])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-tglu-10/igt@kms_big...@linear-32bpp-rotate-270.html
* igt@kms_big_fb@yf-tiled-64bpp-rotate-90:
- shard-tglu-10: NOTRUN -> [SKIP][11] ([fdo#111615])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-tglu-10/igt@kms_big...@yf-tiled-64bpp-rotate-90.html
* igt@kms_ccs@pipe-b-bad-rotation-90-4_tiled_dg2_rc_ccs_cc:
- shard-tglu-10: NOTRUN -> [SKIP][12] ([i915#6095])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-tglu-10/igt@kms_ccs@pipe-b-bad-rotation-90-4_tiled_dg2_rc_ccs_cc.html
* igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc:
- shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271] / [i915#3886]) +3
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-apl6/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_rc_ccs_cc.html
* igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_gen12_mc_ccs:
- shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271]) +56 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-apl6/igt@kms_ccs@pipe-d-bad-pixel-format-y_tiled_gen12_mc_ccs.html
* igt@kms_chamelium_edid@dp-edid-read:
- shard-tglu-10: NOTRUN -> [SKIP][15] ([i915#7828]) +1 similar issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/shard-tglu-10/igt@kms_chamelium_e...@dp-edid-read.html
*
igt@kms_cursor_legacy@short-busy-flip-before-cursor-atomic-transitions-varying-size:
-
Re: [Intel-gfx] [RFC 0/2] Add new CDCLK step for RPL-U
On Mon, Jan 30, 2023 at 03:38:04PM +0530, Chaitanya Kumar Borah wrote: > A new step of 480MHz has been added on SKUs that have an RPL-U > device id. This particular step is to support 120Hz panels > more efficiently. > > This patchset adds a new table to include this new CDCLK > step. Details can be found in BSpec entry 55409. Hi Chaitanya. It looks like we probably need one more change related to the 480MHz rate beyond what was in this series. For platforms that support this rate, we can set voltage level 1 (see bspec 49208) whereas the i915 code at the moment will push it up to voltage level 2 instead. Matt > > Create a new sub-platform to identify RPL-U which will enable > us to make the differentiation during CDCLK initialization. > > Furthermore, we need to make a distinction between ES (Engineering > Sample) and QS (Quality Sample) parts as this change comes only > to QS parts. This version of the patch does not include this change > as we are yet to make a decision if this particular part needs > to be upstreamed.(see comments on revision 2) > > Chaitanya Kumar Borah (2): > drm/i915: Add RPL-U sub platform > drm/i915/display: Add 480 MHz CDCLK steps for RPL-U > > drivers/gpu/drm/i915/display/intel_cdclk.c | 26 ++ > drivers/gpu/drm/i915/i915_drv.h| 2 ++ > drivers/gpu/drm/i915/intel_device_info.c | 7 ++ > drivers/gpu/drm/i915/intel_device_info.h | 1 + > include/drm/i915_pciids.h | 12 ++ > 5 files changed, 44 insertions(+), 4 deletions(-) > > -- > 2.25.1 > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg file for PICA registers
On Fri, Feb 24, 2023 at 12:13:37PM +0200, Mika Kahola wrote: > Create a separate file to store registers for PICA chips > C10 and C20. > > v2: Rename file (Jani) > > Signed-off-by: Radhakrishna Sripada > Signed-off-by: Mika Kahola > --- > .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 136 ++ > 1 file changed, 136 insertions(+) > create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h > > diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h > b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h > new file mode 100644 > index ..d6b3709d3762 > --- /dev/null > +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy_regs.h > @@ -0,0 +1,136 @@ > +/* SPDX-License-Identifier: MIT > + * > + * Copyright © 2022 Intel Corporation > + */ > + > +#ifndef __INTEL_CX0_PHY_REGS_H__ > +#define __INTEL_CX0_PHY_REGS_H__ > + > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A0x64040 > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B0x64140 > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC10x16F240 > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC20x16F440 > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC30x16F640 > +#define _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC40x16F840 > +#define _XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) (_PICK(port, \ > + [PORT_A] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_A, \ > + [PORT_B] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_B, \ > + [PORT_TC1] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC1, \ > + [PORT_TC2] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC2, \ > + [PORT_TC3] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC3, \ > + [PORT_TC4] = > _XELPDP_PORT_M2P_MSGBUS_CTL_LN0_USBC4) + ((lane) * 4)) > + > +#define XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) > _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane)) > +#define XELPDP_PORT_M2P_TRANSACTION_PENDING REG_BIT(31) > +#define XELPDP_PORT_M2P_COMMAND_TYPE_MASK REG_GENMASK(30, 27) > +#define XELPDP_PORT_M2P_COMMAND_WRITE_UNCOMMITTED > REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x1) > +#define XELPDP_PORT_M2P_COMMAND_WRITE_COMMITTED > REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x2) > +#define XELPDP_PORT_M2P_COMMAND_READ > REG_FIELD_PREP(XELPDP_PORT_M2P_COMMAND_TYPE_MASK, 0x3) > +#define XELPDP_PORT_M2P_DATA_MASK REG_GENMASK(23, 16) > +#define XELPDP_PORT_M2P_DATA(val) > REG_FIELD_PREP(XELPDP_PORT_M2P_DATA_MASK, val) > +#define XELPDP_PORT_M2P_TRANSACTION_RESET REG_BIT(15) > +#define XELPDP_PORT_M2P_ADDRESS_MASKREG_GENMASK(11, > 0) > +#define XELPDP_PORT_M2P_ADDRESS(val) > REG_FIELD_PREP(XELPDP_PORT_M2P_ADDRESS_MASK, val) > + > +#define XELPDP_PORT_P2M_MSGBUS_STATUS(port, lane) > _MMIO(_XELPDP_PORT_M2P_MSGBUS_CTL(port, lane) + 8) > +#define XELPDP_PORT_P2M_RESPONSE_READY REG_BIT(31) > +#define XELPDP_PORT_P2M_COMMAND_TYPE_MASK REG_GENMASK(30, 27) > +#define XELPDP_PORT_P2M_COMMAND_READ_ACK0x4 > +#define XELPDP_PORT_P2M_COMMAND_WRITE_ACK 0x5 > +#define XELPDP_PORT_P2M_DATA_MASK REG_GENMASK(23, 16) > +#define XELPDP_PORT_P2M_DATA(val) > REG_FIELD_PREP(XELPDP_PORT_P2M_DATA_MASK, val) > +#define XELPDP_PORT_P2M_ERROR_SET REG_BIT(15) > +#define XELPDP_MSGBUS_TIMEOUT_SLOW 1 > +#define XELPDP_MSGBUS_TIMEOUT_FAST_US 2 > + > +#define XELPDP_PCLK_PLL_ENABLE_TIMEOUT_US3200 > +#define XELPDP_PCLK_PLL_DISABLE_TIMEOUT_US 20 > +#define XELPDP_PORT_BUF_SOC_READY_TIMEOUT_US 100 > +#define XELPDP_PORT_RESET_START_TIMEOUT_US 5 > +#define XELPDP_PORT_POWERDOWN_UPDATE_TIMEOUT_US 100 Drive-by comment: is this constant correct? On bspec 65450 it looks like there's a table of different values (anywhere from 2 to 1380) that get used depending on the old/new state combination. Matt > +#define XELPDP_PORT_RESET_END_TIMEOUT15 > +#define XELPDP_REFCLK_ENABLE_TIMEOUT_US 1 > + > +#define _XELPDP_PORT_BUF_CTL1_LN0_A 0x64004 > +#define _XELPDP_PORT_BUF_CTL1_LN0_B 0x64104 > +#define _XELPDP_PORT_BUF_CTL1_LN0_USBC1 0x16F200 > +#define _XELPDP_PORT_BUF_CTL1_LN0_USBC2 0x16F400 > +#define _XELPDP_PORT_BUF_CTL1_LN0_USBC3 0x16F600 > +#define _XELPDP_PORT_BUF_CTL1_LN0_USBC4 0x16F800 > +#define _XELPDP_PORT_BUF_CTL1(port)
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v4,1/2] drm/i915: Use correct huge page manager for MTL
== Series Details ==
Series: series starting with [v4,1/2] drm/i915: Use correct huge page manager
for MTL
URL : https://patchwork.freedesktop.org/series/114428/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12786_full -> Patchwork_114428v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_114428v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114428v1_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 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114428v1_full:
### IGT changes ###
Possible regressions
* igt@gem_ctx_shared@q-promotion@vecs0:
- shard-tglu-10: NOTRUN -> [DMESG-WARN][1] +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-tglu-10/igt@gem_ctx_shared@q-promot...@vecs0.html
* igt@gem_exec_fence@basic-busy-all:
- shard-snb: NOTRUN -> [ABORT][2] +2 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-snb1/igt@gem_exec_fe...@basic-busy-all.html
* igt@gem_exec_fence@syncobj-timeline-export:
- shard-tglu-10: NOTRUN -> [ABORT][3] +4 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-tglu-10/igt@gem_exec_fe...@syncobj-timeline-export.html
- shard-glk: NOTRUN -> [ABORT][4] +2 similar issues
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-glk7/igt@gem_exec_fe...@syncobj-timeline-export.html
* igt@gem_wait@write-busy@bcs0:
- shard-glk: NOTRUN -> [DMESG-WARN][5] +3 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-glk5/igt@gem_wait@write-b...@bcs0.html
* igt@gem_wait@write-busy@rcs0:
- shard-apl: NOTRUN -> [DMESG-WARN][6] +3 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-apl6/igt@gem_wait@write-b...@rcs0.html
* igt@prime_vgem@basic-fence-read:
- shard-apl: NOTRUN -> [ABORT][7] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-apl6/igt@prime_v...@basic-fence-read.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_barrier_race@remote-request@rcs0}:
- shard-tglu-10: [ABORT][8] ([i915#6333]) -> [ABORT][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12786/shard-tglu-10/igt@gem_barrier_race@remote-requ...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-tglu-10/igt@gem_barrier_race@remote-requ...@rcs0.html
* igt@gem_ctx_shared@q-promotion@vcs0:
- {shard-rkl}:NOTRUN -> [DMESG-WARN][10] +2 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-rkl-5/igt@gem_ctx_shared@q-promot...@vcs0.html
* igt@gem_eio@in-flight-suspend:
- {shard-rkl}:NOTRUN -> [ABORT][11] +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-rkl-1/igt@gem_...@in-flight-suspend.html
* igt@gem_exec_fence@syncobj-import:
- {shard-tglu}: NOTRUN -> [ABORT][12] +3 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-tglu-2/igt@gem_exec_fe...@syncobj-import.html
* igt@gem_wait@write-busy@rcs0:
- {shard-dg1}:NOTRUN -> [DMESG-WARN][13] +4 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-dg1-15/igt@gem_wait@write-b...@rcs0.html
* igt@prime_vgem@basic-fence-flip:
- {shard-dg1}:NOTRUN -> [ABORT][14] +2 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-dg1-14/igt@prime_v...@basic-fence-flip.html
Known issues
Here are the changes found in Patchwork_114428v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@feature_discovery@display-4x:
- shard-tglu-10: NOTRUN -> [SKIP][15] ([i915#1839])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-tglu-10/igt@feature_discov...@display-4x.html
* igt@gem_close_race@multigpu-basic-threads:
- shard-tglu-10: NOTRUN -> [SKIP][16] ([i915#7697])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/shard-tglu-10/igt@gem_close_r...@multigpu-basic-threads.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [PASS][17] -> [FAIL][18] ([i915#2842])
[17]:
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid: Fix csync detailed mode parsing
== Series Details ==
Series: drm/edid: Fix csync detailed mode parsing
URL : https://patchwork.freedesktop.org/series/114424/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12786_full -> Patchwork_114424v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_114424v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114424v1_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 -> 10)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114424v1_full:
### IGT changes ###
Possible regressions
* igt@gem_exec_fence@basic-busy-all:
- shard-snb: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-snb1/igt@gem_exec_fe...@basic-busy-all.html
* igt@gem_exec_fence@syncobj-timeline-chain-engines:
- shard-tglu-10: NOTRUN -> [ABORT][2] +5 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-tglu-10/igt@gem_exec_fe...@syncobj-timeline-chain-engines.html
* igt@gem_wait@write-busy@bcs0:
- shard-glk: NOTRUN -> [DMESG-WARN][3] +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-glk3/igt@gem_wait@write-b...@bcs0.html
* igt@kms_plane@plane-panning-bottom-right-suspend@pipe-a-planes:
- shard-apl: [PASS][4] -> [ABORT][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12786/shard-apl4/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-apl3/igt@kms_plane@plane-panning-bottom-right-susp...@pipe-a-planes.html
* igt@perf_pmu@interrupts-sync:
- shard-apl: NOTRUN -> [ABORT][6] +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-apl4/igt@perf_...@interrupts-sync.html
* igt@vgem_basic@dmabuf-mmap:
- shard-glk: NOTRUN -> [ABORT][7] +1 similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-glk9/igt@vgem_ba...@dmabuf-mmap.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_ctx_shared@q-promotion@vcs0:
- {shard-tglu}: NOTRUN -> [DMESG-WARN][8] +3 similar issues
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-tglu-3/igt@gem_ctx_shared@q-promot...@vcs0.html
* igt@gem_exec_fence@keep-in-fence@vecs0:
- {shard-tglu}: NOTRUN -> [ABORT][9] +5 similar issues
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-tglu-5/igt@gem_exec_fence@keep-in-fe...@vecs0.html
* igt@gem_exec_fence@syncobj-stationary-timeline-chain-engines:
- {shard-rkl}:NOTRUN -> [ABORT][10] +5 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-rkl-5/igt@gem_exec_fe...@syncobj-stationary-timeline-chain-engines.html
* igt@gem_wait@write-busy@rcs0:
- {shard-dg1}:NOTRUN -> [DMESG-WARN][11] +4 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-dg1-14/igt@gem_wait@write-b...@rcs0.html
* igt@prime_vgem@basic-fence-flip:
- {shard-dg1}:NOTRUN -> [ABORT][12] +7 similar issues
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-dg1-13/igt@prime_v...@basic-fence-flip.html
Known issues
Here are the changes found in Patchwork_114424v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@api_intel_bb@crc32:
- shard-tglu-10: NOTRUN -> [SKIP][13] ([i915#6230])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-tglu-10/igt@api_intel...@crc32.html
* igt@feature_discovery@psr1:
- shard-tglu-10: NOTRUN -> [SKIP][14] ([i915#658])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-tglu-10/igt@feature_discov...@psr1.html
* igt@gem_ccs@block-copy-inplace:
- shard-tglu-10: NOTRUN -> [SKIP][15] ([i915#3555] / [i915#5325])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-tglu-10/igt@gem_...@block-copy-inplace.html
* igt@gem_ccs@block-multicopy-compressed:
- shard-tglu-10: NOTRUN -> [SKIP][16] ([i915#5325])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/shard-tglu-10/igt@gem_...@block-multicopy-compressed.html
* igt@gem_exec_fair@basic-pace@bcs0:
- shard-tglu-10: NOTRUN -> [FAIL][17] ([i915#2842]) +5 similar issues
[17]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for Fix error propagation amongst requests
== Series Details == Series: Fix error propagation amongst requests URL : https://patchwork.freedesktop.org/series/11/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12787 -> Patchwork_11v1 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_11v1 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_11v1, 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_11v1/index.html Participating hosts (39 -> 39) -- Additional (1): bat-adls-5 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_11v1: ### IGT changes ### Possible regressions * igt@gem_exec_fence@basic-busy@vecs0: - bat-adls-5: NOTRUN -> [ABORT][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11v1/bat-adls-5/igt@gem_exec_fence@basic-b...@vecs0.html Warnings * igt@gem_exec_fence@basic-busy@vecs0: - fi-kbl-x1275: [DMESG-WARN][2] -> [ABORT][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12787/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vecs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11v1/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vecs0.html Known issues Here are the changes found in Patchwork_11v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adls-5: NOTRUN -> [SKIP][4] ([i915#7456]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11v1/bat-adls-5/igt@debugfs_t...@basic-hwmon.html Possible fixes * igt@gem_exec_fence@basic-busy@vcs0: - fi-kbl-x1275: [ABORT][5] -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12787/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11v1/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vcs0.html [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456 Build changes - * Linux: CI_DRM_12787 -> Patchwork_11v1 CI-20190529: 20190529 CI_DRM_12787: 70da1d04c2abaaaef514174168a7e5595dbae6f3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7173: deab4e0bdf5a9366b67d0a44f478f3da3c9a943b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_11v1: 70da1d04c2abaaaef514174168a7e5595dbae6f3 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 4de414be1dc4 drm/i915/gt: Make sure that errors are propagated through request chains 5c5771ccc385 drm/i915: Throttle for ringspace prior to taking the timeline mutex == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_11v1/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Fix error propagation amongst requests
== Series Details == Series: Fix error propagation amongst requests URL : https://patchwork.freedesktop.org/series/11/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return'
Re: [Intel-gfx] [RFC PATCH 1/2] drm/msm/dpu: add dsc helper functions
On 2/27/2023 11:25 AM, Dmitry Baryshkov wrote:
27 февраля 2023 г. 19:59:35 GMT+02:00, Abhinav Kumar
пишет:
On 2/27/2023 4:45 AM, Dmitry Baryshkov wrote:
On Mon, 27 Feb 2023 at 01:49, Abhinav Kumar wrote:
On 2/26/2023 5:09 AM, Dmitry Baryshkov wrote:
On 26/02/2023 02:47, Abhinav Kumar wrote:
Hi Dmitry
On 2/25/2023 7:23 AM, Dmitry Baryshkov wrote:
On 25/02/2023 02:36, Abhinav Kumar wrote:
On 2/24/2023 3:53 PM, Dmitry Baryshkov wrote:
On Sat, 25 Feb 2023 at 00:26, Abhinav Kumar
wrote:
On 2/24/2023 1:36 PM, Dmitry Baryshkov wrote:
24 февраля 2023 г. 23:23:03 GMT+02:00, Abhinav Kumar
пишет:
On 2/24/2023 1:13 PM, Dmitry Baryshkov wrote:
On 24/02/2023 21:40, Kuogee Hsieh wrote:
Add DSC helper functions based on DSC configuration profiles
to produce
DSC related runtime parameters through both table look up and
runtime
calculation to support DSC on DPU.
There are 6 different DSC configuration profiles are supported
currently.
DSC configuration profiles are differiented by 5 keys, DSC
version (V1.1),
chroma (444/422/420), colorspace (RGB/YUV), bpc(8/10),
bpp (6/7/7.5/8/9/10/12/15) and SCR (0/1).
Only DSC version V1.1 added and V1.2 will be added later.
These helpers should go to
drivers/gpu/drm/display/drm_dsc_helper.c
Also please check that they can be used for i915 or for amdgpu
(ideally for both of them).
No, it cannot. So each DSC encoder parameter is calculated based
on the HW core which is being used.
They all get packed to the same DSC structure which is the
struct drm_dsc_config but the way the parameters are computed is
specific to the HW.
This DPU file helper still uses the drm_dsc_helper's
drm_dsc_compute_rc_parameters() like all other vendors do but
the parameters themselves are very HW specific and belong to
each vendor's dir.
This is not unique to MSM.
Lets take a few other examples:
AMD:
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c#L165
i915:
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/i915/display/intel_vdsc.c#L379
I checked several values here. Intel driver defines more bpc/bpp
combinations, but the ones which are defined in intel_vdsc and in
this patch seem to match. If there are major differences there,
please point me to the exact case.
I remember that AMD driver might have different values.
Some values in the rc_params table do match. But the
rc_buf_thresh[] doesnt.
Because later they do:
vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/i915/display/intel_vdsc.c#L40
Vs
+static u16 dpu_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
+ 0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54,
+ 0x62, 0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
+};
I'd prefer to have 896, 1792, etc. here, as those values come from the
standard. As it's done in the Intel driver.
Got it, thanks
I dont know the AMD calculation very well to say that moving this
to the
helper is going to help.
Those calculations correspond (more or less) at the first glance to
what intel does for their newer generations. I think that's not our
problem for now.
Well, we have to figure out if each value matches and if each of
them come from the spec for us and i915 and from which section. So
it is unfortunately our problem.
Otherwise it will have to be handled by Marijn, me or anybody else
wanting to hack up the DSC code. Or by anybody adding DSC support to
the next platform and having to figure out the difference between
i915, msm and their platform.
Yes, I wonder why the same doubt didn't arise when the other vendors
added their support both from other maintainers and others.
Which makes me think that like I wrote in my previous response, these
are "recommended" values in the spec but its not mandatory.
I think, it is because there were no other drivers to compare. In other
words, for a first driver it is pretty logical to have everything
handled on its own. As soon as we start getting other implementations of
a feature, it becomes logical to think if the code can be generalized.
This is what we see we with the HDCP series or with the code being moved
to DP helpers.
We were not the second, MSM was/is the third to add support for DSC afer
i915 and AMD. Thats what made me think why whoever was the second didnt
end up generalizing. Was it just missed out or was it intentionally left
in the vendor driver.
I didn't count AMD here, since it calculates some of the params rather
than using the fixed ones from the model.
Moving this to the drm_dsc_helper is generalizing the tables and not
giving room for the vendors to customize even if they want to (which
the spec does allow).
That depends on the API you select. For example, in
intel_dsc_compute_params() I see customization being applied to
rc_buf_thresh in 6bpp case. I'd leave that to the i915 driver.
Thanks for going through the i915
[Intel-gfx] [PATCH v2 1/2] drm/i915: Throttle for ringspace prior to taking the timeline mutex
From: Chris Wilson
Before taking exclusive ownership of the ring for emitting the request,
wait for space in the ring to become available. This allows others to
take the timeline->mutex to make forward progresses while userspace is
blocked.
In particular, this allows regular clients to issue requests on the
kernel context, potentially filling the ring, but allow the higher
priority heartbeats and pulses to still be submitted without being
blocked by the less critical work.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Signed-off-by: Chris Wilson
Cc: Maciej Patelczyk
Cc: sta...@vger.kernel.org
Signed-off-by: Andi Shyti
---
Hi,
I'm not sure I need to add the Fixes tag here as this is more
preparatory for the next patch. Together, though, patch 1 and 2
make the fix with proper locking mechanism.
Andi
drivers/gpu/drm/i915/gt/intel_context.c | 41 +
drivers/gpu/drm/i915/gt/intel_context.h | 2 ++
drivers/gpu/drm/i915/i915_request.c | 3 ++
3 files changed, 46 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index 2aa63ec521b89..59cd612a23561 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -626,6 +626,47 @@ bool intel_context_revoke(struct intel_context *ce)
return ret;
}
+int intel_context_throttle(const struct intel_context *ce)
+{
+ const struct intel_ring *ring = ce->ring;
+ const struct intel_timeline *tl = ce->timeline;
+ struct i915_request *rq;
+ int err = 0;
+
+ if (READ_ONCE(ring->space) >= SZ_1K)
+ return 0;
+
+ rcu_read_lock();
+ list_for_each_entry_reverse(rq, >requests, link) {
+ if (__i915_request_is_complete(rq))
+ break;
+
+ if (rq->ring != ring)
+ continue;
+
+ /* Wait until there will be enough space following that rq */
+ if (__intel_ring_space(rq->postfix,
+ ring->emit,
+ ring->size) < ring->size / 2) {
+ if (i915_request_get_rcu(rq)) {
+ rcu_read_unlock();
+
+ if (i915_request_wait(rq,
+ I915_WAIT_INTERRUPTIBLE,
+ MAX_SCHEDULE_TIMEOUT) < 0)
+ err = -EINTR;
+
+ rcu_read_lock();
+ i915_request_put(rq);
+ }
+ break;
+ }
+ }
+ rcu_read_unlock();
+
+ return err;
+}
+
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
#include "selftest_context.c"
#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_context.h
b/drivers/gpu/drm/i915/gt/intel_context.h
index 0a8d553da3f43..f919a66cebf5b 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.h
+++ b/drivers/gpu/drm/i915/gt/intel_context.h
@@ -226,6 +226,8 @@ static inline void intel_context_exit(struct intel_context
*ce)
ce->ops->exit(ce);
}
+int intel_context_throttle(const struct intel_context *ce);
+
static inline struct intel_context *intel_context_get(struct intel_context *ce)
{
kref_get(>ref);
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043bb..a1741c4a8cffd 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1035,6 +1035,9 @@ i915_request_create(struct intel_context *ce)
struct i915_request *rq;
struct intel_timeline *tl;
+ if (intel_context_throttle(ce))
+ return ERR_PTR(-EINTR);
+
tl = intel_context_timeline_lock(ce);
if (IS_ERR(tl))
return ERR_CAST(tl);
--
2.39.1
[Intel-gfx] [PATCH v2 2/2] drm/i915/gt: Make sure that errors are propagated through request chains
Currently, when we perform operations such as clearing or copying
large blocks of memory, we generate multiple requests that are
executed in a chain.
However, if one of these requests fails, we may not realize it
unless it happens to be the last request in the chain. This is
because errors are not properly propagated.
For this we need to keep propagating the chain of fence
notification in order to always reach the final fence associated
to the final request.
To address this issue, we need to ensure that the chain of fence
notifications is always propagated so that we can reach the final
fence associated with the last request. By doing so, we will be
able to detect any memory operation failures and determine
whether the memory is still invalid.
On copy and clear migration signal fences upon completion.
On copy and clear migration, signal fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 31 +
1 file changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 3f638f1987968..8a293045a7b96 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -748,7 +748,7 @@ intel_context_migrate_copy(struct intel_context *ce,
rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -878,10 +878,14 @@ intel_context_migrate_copy(struct intel_context *ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
- i915_request_put(*out);
- *out = i915_request_get(rq);
+ i915_sw_fence_await(>submit);
+ i915_request_get(rq);
i915_request_add(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
+ i915_request_put(*out);
+ }
+ *out = rq;
if (err)
break;
@@ -905,7 +909,8 @@ intel_context_migrate_copy(struct intel_context *ce,
cond_resched();
} while (1);
-out_ce:
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
@@ -1005,7 +1010,7 @@ intel_context_migrate_clear(struct intel_context *ce,
rq = i915_request_create(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -1056,17 +1061,23 @@ intel_context_migrate_clear(struct intel_context *ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
- i915_request_put(*out);
- *out = i915_request_get(rq);
+ i915_sw_fence_await(>submit);
+ i915_request_get(rq);
i915_request_add(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
+ i915_request_put(*out);
+ }
+ *out = rq;
+
if (err || !it.sg || !sg_dma_len(it.sg))
break;
cond_resched();
} while (1);
-out_ce:
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
--
2.39.1
[Intel-gfx] [PATCH v2 0/2] Fix error propagation amongst requests
Hi,
This series of two patches fixes the issue introduced in
cf586021642d80 ("drm/i915/gt: Pipelined page migration") where,
as reported by Matt, in a chain of requests an error is reported
only if happens in the last request.
However Chris noticed that without ensuring exclusivity in the
locking we might end up in some deadlock. That's why patch 1
throttles for the ringspace in order to make sure that no one is
holding it.
Version 1 of this patch has been reviewed by matt and this
version is adding Chris exclusive locking.
Thanks Chris for this work.
Andi
Changelog
=
v1 -> v2
- Add patch 1 for ensuring exclusive locking of the timeline
- Reword git commit of patch 2.
Andi Shyti (1):
drm/i915/gt: Make sure that errors are propagated through request
chains
Chris Wilson (1):
drm/i915: Throttle for ringspace prior to taking the timeline mutex
drivers/gpu/drm/i915/gt/intel_context.c | 41 +
drivers/gpu/drm/i915/gt/intel_context.h | 2 ++
drivers/gpu/drm/i915/gt/intel_migrate.c | 31 +--
drivers/gpu/drm/i915/i915_request.c | 3 ++
4 files changed, 67 insertions(+), 10 deletions(-)
--
2.39.1
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev3)
== Series Details == Series: drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev3) URL : https://patchwork.freedesktop.org/series/114199/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12787 -> Patchwork_114199v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_114199v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_114199v3, 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_114199v3/index.html Participating hosts (39 -> 39) -- Additional (1): bat-adls-5 Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_114199v3: ### IGT changes ### Possible regressions * igt@gem_exec_fence@basic-busy@vecs0: - bat-adls-5: NOTRUN -> [ABORT][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v3/bat-adls-5/igt@gem_exec_fence@basic-b...@vecs0.html Warnings * igt@gem_exec_fence@basic-busy@vecs0: - fi-kbl-x1275: [DMESG-WARN][2] -> [ABORT][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12787/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vecs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v3/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vecs0.html Known issues Here are the changes found in Patchwork_114199v3 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - bat-adls-5: NOTRUN -> [SKIP][4] ([i915#7456]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v3/bat-adls-5/igt@debugfs_t...@basic-hwmon.html Possible fixes * igt@gem_exec_fence@basic-busy@vcs0: - fi-kbl-x1275: [ABORT][5] -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12787/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v3/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vcs0.html [i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456 Build changes - * Linux: CI_DRM_12787 -> Patchwork_114199v3 CI-20190529: 20190529 CI_DRM_12787: 70da1d04c2abaaaef514174168a7e5595dbae6f3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7173: deab4e0bdf5a9366b67d0a44f478f3da3c9a943b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114199v3: 70da1d04c2abaaaef514174168a7e5595dbae6f3 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 71ec2b66733e drm/i915/sseu: fix max_subslices array-index-out-of-bounds access == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114199v3/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev3)
== Series Details == Series: drm/i915/sseu: fix max_subslices array-index-out-of-bounds access (rev3) URL : https://patchwork.freedesktop.org/series/114199/ State : warning == Summary == Error: dim checkpatch failed 4fd8113016d7 drm/i915/sseu: fix max_subslices array-index-out-of-bounds access -:12: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #12: UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27 total: 0 errors, 1 warnings, 0 checks, 8 lines checked
[Intel-gfx] [PATCH v7 15/15] drm/i915: Add deadline based boost support
From: Rob Clark
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_request.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043b..44491e7e214c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct dma_fence
*fence)
return i915_request_enable_breadcrumb(to_request(fence));
}
+static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
+{
+ struct i915_request *rq = to_request(fence);
+
+ if (i915_request_completed(rq))
+ return;
+
+ if (i915_request_started(rq))
+ return;
+
+ /*
+* TODO something more clever for deadlines that are in the
+* future. I think probably track the nearest deadline in
+* rq->timeline and set timer to trigger boost accordingly?
+*/
+
+ intel_rps_boost(rq);
+}
+
static signed long i915_fence_wait(struct dma_fence *fence,
bool interruptible,
signed long timeout)
@@ -182,6 +201,7 @@ const struct dma_fence_ops i915_fence_ops = {
.signaled = i915_fence_signaled,
.wait = i915_fence_wait,
.release = i915_fence_release,
+ .set_deadline = i915_fence_set_deadline,
};
static void irq_execute_cb(struct irq_work *wrk)
--
2.39.1
[Intel-gfx] [PATCH v7 00/15] dma-fence: Deadline awareness
From: Rob Clark This series adds a deadline hint to fences, so realtime deadlines such as vblank can be communicated to the fence signaller for power/ frequency management decisions. This is partially inspired by a trick i915 does, but implemented via dma-fence for a couple of reasons: 1) To continue to be able to use the atomic helpers 2) To support cases where display and gpu are different drivers This iteration adds a dma-fence ioctl to set a deadline (both to support igt-tests, and compositors which delay decisions about which client buffer to display), and a sw_sync ioctl to read back the deadline. IGT tests utilizing these can be found at: https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline v1: https://patchwork.freedesktop.org/series/93035/ v2: Move filtering out of later deadlines to fence implementation to avoid increasing the size of dma_fence v3: Add support in fence-array and fence-chain; Add some uabi to support igt tests and userspace compositors. v4: Rebase, address various comments, and add syncobj deadline support, and sync_file EPOLLPRI based on experience with perf/ freq issues with clvk compute workloads on i915 (anv) v5: Clarify that this is a hint as opposed to a more hard deadline guarantee, switch to using u64 ns values in UABI (still absolute CLOCK_MONOTONIC values), drop syncobj related cap and driver feature flag in favor of allowing count_handles==0 for probing kernel support. v6: Re-work vblank helper to calculate time of _start_ of vblank, and work correctly if the last vblank event was more than a frame ago. Add (mostly unrelated) drm/msm patch which also uses the vblank helper. Use dma_fence_chain_contained(). More verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v7: Fix kbuild complaints about vblank helper. Add more docs. Rob Clark (15): dma-buf/dma-fence: Add deadline awareness dma-buf/fence-array: Add fence deadline support dma-buf/fence-chain: Add fence deadline support dma-buf/dma-resv: Add a way to set fence deadline dma-buf/sync_file: Add SET_DEADLINE ioctl dma-buf/sync_file: Support (E)POLLPRI dma-buf/sw_sync: Add fence deadline support drm/scheduler: Add fence deadline support drm/syncobj: Add deadline support for syncobj waits drm/vblank: Add helper to get next vblank time drm/atomic-helper: Set fence deadline for vblank drm/msm: Add deadline based boost support drm/msm: Add wait-boost support drm/msm/atomic: Switch to vblank_start helper drm/i915: Add deadline based boost support Documentation/driver-api/dma-buf.rst| 6 ++ drivers/dma-buf/dma-fence-array.c | 11 drivers/dma-buf/dma-fence-chain.c | 12 drivers/dma-buf/dma-fence.c | 60 drivers/dma-buf/dma-resv.c | 22 drivers/dma-buf/sw_sync.c | 58 +++ drivers/dma-buf/sync_debug.h| 2 + drivers/dma-buf/sync_file.c | 27 + drivers/gpu/drm/drm_atomic_helper.c | 36 drivers/gpu/drm/drm_syncobj.c | 64 - drivers/gpu/drm/drm_vblank.c| 53 +++--- drivers/gpu/drm/i915/i915_request.c | 20 +++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 - drivers/gpu/drm/msm/msm_atomic.c| 8 ++- drivers/gpu/drm/msm/msm_drv.c | 12 ++-- drivers/gpu/drm/msm/msm_fence.c | 74 + drivers/gpu/drm/msm/msm_fence.h | 20 +++ drivers/gpu/drm/msm/msm_gem.c | 5 ++ drivers/gpu/drm/msm/msm_kms.h | 8 --- drivers/gpu/drm/scheduler/sched_fence.c | 46 +++ drivers/gpu/drm/scheduler/sched_main.c | 2 +- include/drm/drm_vblank.h| 1 + include/drm/gpu_scheduler.h | 17 ++ include/linux/dma-fence.h | 20 +++ include/linux/dma-resv.h| 2 + include/uapi/drm/drm.h | 17 ++ include/uapi/drm/msm_drm.h | 14 - include/uapi/linux/sync_file.h | 26 + 28 files changed, 603 insertions(+), 55 deletions(-) -- 2.39.1
Re: [Intel-gfx] [RFC PATCH 1/2] drm/msm/dpu: add dsc helper functions
27 февраля 2023 г. 19:59:35 GMT+02:00, Abhinav Kumar
пишет:
>
>
>On 2/27/2023 4:45 AM, Dmitry Baryshkov wrote:
>> On Mon, 27 Feb 2023 at 01:49, Abhinav Kumar
>> wrote:
>>>
>>>
>>>
>>> On 2/26/2023 5:09 AM, Dmitry Baryshkov wrote:
On 26/02/2023 02:47, Abhinav Kumar wrote:
> Hi Dmitry
>
> On 2/25/2023 7:23 AM, Dmitry Baryshkov wrote:
>> On 25/02/2023 02:36, Abhinav Kumar wrote:
>>>
>>>
>>> On 2/24/2023 3:53 PM, Dmitry Baryshkov wrote:
On Sat, 25 Feb 2023 at 00:26, Abhinav Kumar
wrote:
> On 2/24/2023 1:36 PM, Dmitry Baryshkov wrote:
>> 24 февраля 2023 г. 23:23:03 GMT+02:00, Abhinav Kumar
>> пишет:
>>> On 2/24/2023 1:13 PM, Dmitry Baryshkov wrote:
On 24/02/2023 21:40, Kuogee Hsieh wrote:
> Add DSC helper functions based on DSC configuration profiles
> to produce
> DSC related runtime parameters through both table look up and
> runtime
> calculation to support DSC on DPU.
>
> There are 6 different DSC configuration profiles are supported
> currently.
> DSC configuration profiles are differiented by 5 keys, DSC
> version (V1.1),
> chroma (444/422/420), colorspace (RGB/YUV), bpc(8/10),
> bpp (6/7/7.5/8/9/10/12/15) and SCR (0/1).
>
> Only DSC version V1.1 added and V1.2 will be added later.
These helpers should go to
drivers/gpu/drm/display/drm_dsc_helper.c
Also please check that they can be used for i915 or for amdgpu
(ideally for both of them).
>>>
>>> No, it cannot. So each DSC encoder parameter is calculated based
>>> on the HW core which is being used.
>>>
>>> They all get packed to the same DSC structure which is the
>>> struct drm_dsc_config but the way the parameters are computed is
>>> specific to the HW.
>>>
>>> This DPU file helper still uses the drm_dsc_helper's
>>> drm_dsc_compute_rc_parameters() like all other vendors do but
>>> the parameters themselves are very HW specific and belong to
>>> each vendor's dir.
>>>
>>> This is not unique to MSM.
>>>
>>> Lets take a few other examples:
>>>
>>> AMD:
>>> https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c#L165
>>>
>>>
>>> i915:
>>> https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/i915/display/intel_vdsc.c#L379
>>>
>>
>> I checked several values here. Intel driver defines more bpc/bpp
>> combinations, but the ones which are defined in intel_vdsc and in
>> this patch seem to match. If there are major differences there,
>> please point me to the exact case.
>>
>> I remember that AMD driver might have different values.
>>
>
> Some values in the rc_params table do match. But the
> rc_buf_thresh[] doesnt.
Because later they do:
vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
>
> https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/i915/display/intel_vdsc.c#L40
>
>
> Vs
>
> +static u16 dpu_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
> + 0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54,
> + 0x62, 0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
> +};
I'd prefer to have 896, 1792, etc. here, as those values come from the
standard. As it's done in the Intel driver.
>>>
>>> Got it, thanks
>>>
> I dont know the AMD calculation very well to say that moving this
> to the
> helper is going to help.
Those calculations correspond (more or less) at the first glance to
what intel does for their newer generations. I think that's not our
problem for now.
>>>
>>> Well, we have to figure out if each value matches and if each of
>>> them come from the spec for us and i915 and from which section. So
>>> it is unfortunately our problem.
>>
>> Otherwise it will have to be handled by Marijn, me or anybody else
>> wanting to hack up the DSC code. Or by anybody adding DSC support to
>> the next platform and having to figure out the difference between
>> i915, msm and their platform.
>>
>
> Yes, I wonder why the same doubt didn't arise when the other vendors
> added their support both from other maintainers and others.
>
> Which makes me think that like I wrote in my previous response, these
> are "recommended" values in
Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support
On Mon, Feb 27, 2023 at 03:11:16AM -0800, Yi Liu wrote: > Existing VFIO provides group-centric user APIs for userspace. Userspace > opens the /dev/vfio/$group_id first before getting device fd and hence > getting access to device. This is not the desired model for iommufd. Per > the conclusion of community discussion[1], iommufd provides device-centric > kAPIs and requires its consumer (like VFIO) to be device-centric user > APIs. Such user APIs are used to associate device with iommufd and also > the I/O address spaces managed by the iommufd. > > This series first introduces a per device file structure to be prepared > for further enhancement and refactors the kvm-vfio code to be prepared > for accepting device file from userspace. Then refactors the vfio to be > able to handle iommufd binding. This refactor includes the mechanism of > blocking device access before iommufd bind, making the device_open exclusive. > between the group path and the cdev path. Eventually, adds the cdev support > for vfio device, and makes group infrastructure optional as it is not needed > when vfio device cdev is compiled. > > This is also a prerequisite for iommu nesting for vfio device[2]. > > The complete code can be found in below branch, simple test done with the > legacy group path and the cdev path. Draft QEMU branch can be found at[3] > > https://github.com/yiliu1765/iommufd/tree/vfio_device_cdev_v5 > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > base-commit: 63777bd2daa3625da6eada88bd9081f047664dad This needs to be rebased onto a clean v6.3-rc1 when it comes out Jason
Re: [Intel-gfx] [PATCH v5 13/19] vfio: Add cdev_device_open_cnt to vfio_group
On Mon, Feb 27, 2023 at 03:11:29AM -0800, Yi Liu wrote: > for counting the devices that are opened via the cdev path. This count > is increased and decreased by the cdev path. The group path checks it > to achieve exclusion with the cdev path. With this, only one path (group > path or cdev path) will claim DMA ownership. This avoids scenarios in > which devices within the same group may be opened via different paths. > > Signed-off-by: Yi Liu > Reviewed-by: Kevin Tian > --- > drivers/vfio/group.c | 33 + > drivers/vfio/vfio.h | 3 +++ > 2 files changed, 36 insertions(+) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v5 18/19] vfio: Compile group optionally
On Mon, Feb 27, 2023 at 03:11:34AM -0800, Yi Liu wrote:
> diff --git a/include/linux/vfio.h b/include/linux/vfio.h
> index ce390533cb30..d12384824656 100644
> --- a/include/linux/vfio.h
> +++ b/include/linux/vfio.h
> @@ -43,7 +43,9 @@ struct vfio_device {
>*/
> const struct vfio_migration_ops *mig_ops;
> const struct vfio_log_ops *log_ops;
> +#if IS_ENABLED(CONFIG_VFIO_GROUP)
> struct vfio_group *group;
> +#endif
> struct vfio_device_set *dev_set;
> struct list_head dev_set_list;
> unsigned int migration_flags;
> @@ -58,8 +60,10 @@ struct vfio_device {
> refcount_t refcount;/* user count on registered device*/
> unsigned int open_count;
> struct completion comp;
> +#if IS_ENABLED(CONFIG_VFIO_GROUP)
> struct list_head group_next;
> struct list_head iommu_entry;
> +#endif
> struct iommufd_access *iommufd_access;
> void (*put_kvm)(struct kvm *kvm);
I'd combine these for readability
Jason
Re: [Intel-gfx] [PATCH v5 16/19] vfio: Add VFIO_DEVICE_BIND_IOMMUFD
On Mon, Feb 27, 2023 at 03:11:32AM -0800, Yi Liu wrote:
> This adds ioctl for userspace to bind device cdev fd to iommufd.
>
> VFIO_DEVICE_BIND_IOMMUFD: bind device to an iommufd, hence gain DMA
> control provided by the iommufd. open_device
> op is called after bind_iommufd op.
> VFIO no iommu mode is indicated by passing
> a negative iommufd value.
>
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/device_cdev.c | 146 +
> drivers/vfio/vfio.h| 17 -
> drivers/vfio/vfio_main.c | 54 --
> include/linux/iommufd.h| 6 ++
> include/uapi/linux/vfio.h | 34 +
> 5 files changed, 248 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
> index 9e2c1ecaaf4f..37f80e368551 100644
> --- a/drivers/vfio/device_cdev.c
> +++ b/drivers/vfio/device_cdev.c
> @@ -3,6 +3,7 @@
> * Copyright (c) 2023 Intel Corporation.
> */
> #include
> +#include
>
> #include "vfio.h"
>
> @@ -45,6 +46,151 @@ int vfio_device_fops_cdev_open(struct inode *inode,
> struct file *filep)
> return ret;
> }
>
> +static void vfio_device_get_kvm_safe(struct vfio_device_file *df)
> +{
> + spin_lock(>kvm_ref_lock);
> + if (!df->kvm)
> + goto unlock;
> +
> + _vfio_device_get_kvm_safe(df->device, df->kvm);
> +
> +unlock:
Just
if (df->kvm)
_vfio_device_get_kvm_safe(df->device, df->kvm);
Without the goto
> + spin_unlock(>kvm_ref_lock);
> +}
> +
> +void vfio_device_cdev_close(struct vfio_device_file *df)
> +{
> + struct vfio_device *device = df->device;
> +
> + mutex_lock(>dev_set->lock);
> + /*
> + * As df->access_granted writer is under dev_set->lock as well,
> + * so this read no need to use smp_load_acquire() to pair with
> + * smp_store_release() in the caller of vfio_device_open().
> + */
This is a bit misleading, we are about to free df in the caller, so at
this moment df has no current access. We don't even need to have the
mutex to test it.
> +long vfio_device_ioctl_bind_iommufd(struct vfio_device_file *df,
> + unsigned long arg)
struct device __user *arg and remove all the casts.
> +{
> + struct vfio_device *device = df->device;
> + struct vfio_device_bind_iommufd bind;
> + struct iommufd_ctx *iommufd = NULL;
> + unsigned long minsz;
> + int ret;
> +
> + minsz = offsetofend(struct vfio_device_bind_iommufd, out_devid);
> +
> + if (copy_from_user(, (void __user *)arg, minsz))
> + return -EFAULT;
> +
> + if (bind.argsz < minsz || bind.flags)
> + return -EINVAL;
> +
> + if (!device->ops->bind_iommufd)
> + return -ENODEV;
> +
> + ret = vfio_device_block_group(device);
> + if (ret)
> + return ret;
> +
> + mutex_lock(>dev_set->lock);
> + /*
> + * If already been bound to an iommufd, or already set noiommu
> + * then fail it.
> + */
> + if (df->iommufd || df->noiommu) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + /* iommufd < 0 means noiommu mode */
> + if (bind.iommufd < 0) {
> + if (!capable(CAP_SYS_RAWIO)) {
> + ret = -EPERM;
> + goto out_unlock;
> + }
> + df->noiommu = true;
> + } else {
> + iommufd = vfio_get_iommufd_from_fd(bind.iommufd);
> + if (IS_ERR(iommufd)) {
> + ret = PTR_ERR(iommufd);
> + goto out_unlock;
> + }
> + }
> +
> + /*
> + * Before the device open, get the KVM pointer currently
> + * associated with the device file (if there is) and obtain
> + * a reference. This reference is held until device closed.
> + * Save the pointer in the device for use by drivers.
> + */
> + vfio_device_get_kvm_safe(df);
> +
> + df->iommufd = iommufd;
> + ret = vfio_device_open(df, _devid, NULL);
> + if (ret)
> + goto out_put_kvm;
> +
> + ret = copy_to_user((void __user *)arg +
> +offsetofend(struct vfio_device_bind_iommufd,
> iommufd),
??
>out_dev_id
static_assert(__same_type...)
> diff --git a/include/linux/iommufd.h b/include/linux/iommufd.h
> index 650d45629647..9672cf839687 100644
> --- a/include/linux/iommufd.h
> +++ b/include/linux/iommufd.h
> @@ -17,6 +17,12 @@ struct iommufd_ctx;
> struct iommufd_access;
> struct file;
>
> +/*
> + * iommufd core init xarray with flags==XA_FLAGS_ALLOC1, so valid
> + * ID starts from 1.
> + */
> +#define IOMMUFD_INVALID_ID 0
Why? vfio doesn't need to check this just to generate EINVAL.
Jason
Re: [Intel-gfx] [PATCH v5 15/19] vfio: Add cdev for vfio_device
On Mon, Feb 27, 2023 at 03:11:31AM -0800, Yi Liu wrote:
> @@ -309,6 +310,13 @@ void vfio_unregister_group_dev(struct vfio_device
> *device)
> bool interrupted = false;
> long rc;
>
> + /*
> + * Balances vfio_device_add in register path. Putting it as the
> + * first operation in unregister to prevent registration refcount
> + * from incrementing per cdev open.
> + */
> + vfio_device_del(device);
> +
> vfio_device_put_registration(device);
> rc = try_wait_for_completion(>comp);
> while (rc <= 0) {
> @@ -334,9 +342,6 @@ void vfio_unregister_group_dev(struct vfio_device *device)
>
> vfio_device_group_unregister(device);
>
> - /* Balances device_add in register path */
> - device_del(>device);
> -
> /* Balances vfio_device_set_group in register path */
> vfio_device_remove_group(device);
The same rational applies to vfio_device_group_unregister too, so it
should be moved up as well.
Jason
Re: [Intel-gfx] [PATCH v5 15/19] vfio: Add cdev for vfio_device
On Mon, Feb 27, 2023 at 03:11:31AM -0800, Yi Liu wrote: > diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig > index a8f544629467..169762316513 100644 > --- a/drivers/vfio/Kconfig > +++ b/drivers/vfio/Kconfig > @@ -12,6 +12,18 @@ menuconfig VFIO > If you don't know what to do here, say N. > > if VFIO > +config VFIO_DEVICE_CDEV > + bool "Support for the VFIO cdev /dev/vfio/devices/vfioX" > + depends on IOMMUFD && (X86 || S390 || ARM || ARM64) We don't need to propogate this arch detection stuff, at worst it should be in iommufd kconfig if it is really needed. Also that other thread shows that vfio doesn't work on ARM because we can never take ownership of a device due to arm iommu Jason
Re: [Intel-gfx] [PATCH v5 14/19] vfio: Make vfio_device_open() single open for device cdev path
On Mon, Feb 27, 2023 at 03:11:30AM -0800, Yi Liu wrote: > @@ -535,7 +542,8 @@ static int vfio_device_fops_release(struct inode *inode, > struct file *filep) > struct vfio_device_file *df = filep->private_data; > struct vfio_device *device = df->device; > > - vfio_device_group_close(df); > + if (!df->is_cdev_device) > + vfio_device_group_close(df); This hunk should go in another patch Jason
Re: [Intel-gfx] [PATCH v5 08/19] vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset()
On Mon, Feb 27, 2023 at 03:11:24AM -0800, Yi Liu wrote: > this suits more on what the code does. > > Signed-off-by: Yi Liu > Reviewed-by: Kevin Tian > --- > drivers/vfio/pci/vfio_pci_core.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v5 07/19] vfio: Block device access via device fd until device is opened
On Mon, Feb 27, 2023 at 03:11:23AM -0800, Yi Liu wrote: > Allow the vfio_device file to be in a state where the device FD is > opened but the device cannot be used by userspace (i.e. its .open_device() > hasn't been called). This inbetween state is not used when the device > FD is spawned from the group FD, however when we create the device FD > directly by opening a cdev it will be opened in the blocked state. > > The reason for the inbetween state is that userspace only gets a FD but > doesn't gain access permission until binding the FD to an iommufd. So in > the blocked state, only the bind operation is allowed. Completing bind > will allow user to further access the device. > > This is implemented by adding a flag in struct vfio_device_file to mark > the blocked state and using a simple smp_load_acquire() to obtain the > flag value and serialize all the device setup with the thread accessing > this device. > > Following this lockless scheme, it can safely handle the device FD > unbound->bound but it cannot handle bound->unbound. To allow this we'd > need to add a lock on all the vfio ioctls which seems costly. So once > device FD is bound, it remains bound until the FD is closed. > > Suggested-by: Jason Gunthorpe > Signed-off-by: Yi Liu > Reviewed-by: Kevin Tian > --- > drivers/vfio/group.c | 6 ++ > drivers/vfio/vfio.h | 1 + > drivers/vfio/vfio_main.c | 16 > 3 files changed, 23 insertions(+) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v5 06/19] vfio: Pass struct vfio_device_file * to vfio_device_open/close()
On Mon, Feb 27, 2023 at 03:11:22AM -0800, Yi Liu wrote: > This avoids passing too much parameters in multiple functions. > > Signed-off-by: Yi Liu > Reviewed-by: Kevin Tian > --- > drivers/vfio/group.c | 19 +-- > drivers/vfio/vfio.h | 8 > drivers/vfio/vfio_main.c | 25 +++-- > 3 files changed, 32 insertions(+), 20 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v5 05/19] kvm/vfio: Accept vfio device file from userspace
On Mon, Feb 27, 2023 at 03:11:21AM -0800, Yi Liu wrote: > This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*. > Old userspace uses KVM_DEV_VFIO_GROUP* works as well. > > Signed-off-by: Yi Liu > --- > Documentation/virt/kvm/devices/vfio.rst | 52 + > include/uapi/linux/kvm.h| 16 ++-- > virt/kvm/vfio.c | 16 > 3 files changed, 55 insertions(+), 29 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v5 04/19] kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd
On Mon, Feb 27, 2023 at 03:11:20AM -0800, Yi Liu wrote: > Meanwhile, rename related helpers. No functional change is intended. > > Signed-off-by: Yi Liu > Reviewed-by: Kevin Tian > Reviewed-by: Eric Auger > --- > virt/kvm/vfio.c | 115 > 1 file changed, 58 insertions(+), 57 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v5 03/19] vfio: Accept vfio device file in the KVM facing kAPI
On Mon, Feb 27, 2023 at 03:11:19AM -0800, Yi Liu wrote: > This makes the vfio file kAPIs to accepte vfio device files, also a > preparation for vfio device cdev support. > > For the kvm set with vfio device file, kvm pointer is stored in struct > vfio_device_file, and use kvm_ref_lock to protect kvm set and kvm > pointer usage within VFIO. This kvm pointer will be set to vfio_device > after device file is bound to iommufd in the cdev path. > > Signed-off-by: Yi Liu > Reviewed-by: Kevin Tian > --- > drivers/vfio/vfio.h | 2 ++ > drivers/vfio/vfio_main.c | 42 +--- > 2 files changed, 41 insertions(+), 3 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v5 02/19] vfio: Refine vfio file kAPIs for KVM
On Mon, Feb 27, 2023 at 03:11:18AM -0800, Yi Liu wrote: > This prepares for making the below kAPIs to accept both group file > and device file instead of only vfio group file. > > bool vfio_file_enforced_coherent(struct file *file); > void vfio_file_set_kvm(struct file *file, struct kvm *kvm); > > Besides the above change, vfio_file_is_valid() is added to check if a > given file is a valid vfio file. It would be extended to check both > vfio group file and vfio device file later. > > vfio_file_is_group() is kept to for the VFIO PCI hot reset path. > > Signed-off-by: Yi Liu > Reviewed-by: Kevin Tian > Reviewed-by: Eric Auger > --- > drivers/vfio/group.c | 57 +++- > drivers/vfio/vfio.h | 3 +++ > drivers/vfio/vfio_main.c | 45 +++ > include/linux/vfio.h | 1 + > virt/kvm/vfio.c | 10 +++ > 5 files changed, 75 insertions(+), 41 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v5 01/19] vfio: Allocate per device file structure
On Mon, Feb 27, 2023 at 03:11:17AM -0800, Yi Liu wrote: > This is preparation for adding vfio device cdev support. vfio device > cdev requires: > 1) a per device file memory to store the kvm pointer set by KVM. It will >be propagated to vfio_device:kvm after the device cdev file is bound >to an iommufd > 2) a mechanism to block device access through device cdev fd before it >is bound to an iommufd > > To address above requirements, this adds a per device file structure > named vfio_device_file. For now, it's only a wrapper of struct vfio_device > pointer. Other fields will be added to this per file structure in future > commits. > > Signed-off-by: Yi Liu > Reviewed-by: Kevin Tian > Reviewed-by: Eric Auger > --- > drivers/vfio/group.c | 13 +++-- > drivers/vfio/vfio.h | 6 ++ > drivers/vfio/vfio_main.c | 31 ++- > 3 files changed, 43 insertions(+), 7 deletions(-) Reviewed-by: Jason Gunthorpe Jason
Re: [Intel-gfx] [PATCH v5 12/19] vfio-iommufd: Add detach_ioas for emulated VFIO devices
On Mon, Feb 27, 2023 at 03:11:28AM -0800, Yi Liu wrote: > diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c > index bfaa9876499b..faf2516b0f06 100644 > --- a/drivers/vfio/iommufd.c > +++ b/drivers/vfio/iommufd.c > @@ -165,6 +165,12 @@ int vfio_iommufd_emulated_attach_ioas(struct vfio_device > *vdev, u32 *pt_id) > > lockdep_assert_held(>dev_set->lock); > > + if (!vdev->iommufd_ictx) > + return -EINVAL; Same remark about WARN_ON here too Jason
Re: [Intel-gfx] [PATCH v5 11/19] vfio-iommufd: Add detach_ioas support for physical VFIO devices
On Mon, Feb 27, 2023 at 03:11:27AM -0800, Yi Liu wrote:
> diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> index c89a047a4cd8..d540cf683d93 100644
> --- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> +++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
> @@ -594,6 +594,7 @@ static const struct vfio_device_ops vfio_fsl_mc_ops = {
> .bind_iommufd = vfio_iommufd_physical_bind,
> .unbind_iommufd = vfio_iommufd_physical_unbind,
> .attach_ioas= vfio_iommufd_physical_attach_ioas,
> + .detach_ioas= vfio_iommufd_physical_detach_ioas,
> };
>
> static struct fsl_mc_driver vfio_fsl_mc_driver = {
> diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> index beef6ca21107..bfaa9876499b 100644
> --- a/drivers/vfio/iommufd.c
> +++ b/drivers/vfio/iommufd.c
> @@ -88,6 +88,14 @@ int vfio_iommufd_physical_attach_ioas(struct vfio_device
> *vdev, u32 *pt_id)
> {
> int rc;
>
> + lockdep_assert_held(>dev_set->lock);
> +
> + if (!vdev->iommufd_device)
> + return -EINVAL;
This should be a WARN_ON. The vdev->iommufd_ctx should be NULL if it
hasn't been bound, and it can't be bound unless the
iommufd_device/attach was created.
> @@ -96,6 +104,18 @@ int vfio_iommufd_physical_attach_ioas(struct vfio_device
> *vdev, u32 *pt_id)
> }
> EXPORT_SYMBOL_GPL(vfio_iommufd_physical_attach_ioas);
>
> +void vfio_iommufd_physical_detach_ioas(struct vfio_device *vdev)
> +{
> + lockdep_assert_held(>dev_set->lock);
> +
> + if (!vdev->iommufd_device || !vdev->iommufd_attached)
> + return;
Same
Jason
Re: [Intel-gfx] [PATCH v5 17/19] vfio: Add VFIO_DEVICE_AT[DE]TACH_IOMMUFD_PT
On Mon, Feb 27, 2023 at 03:11:33AM -0800, Yi Liu wrote:
> This adds ioctl for userspace to attach device cdev fd to and detach
> from IOAS/hw_pagetable managed by iommufd.
>
> VFIO_DEVICE_ATTACH_IOMMUFD_PT: attach vfio device to IOAS, hw_pagetable
> managed by iommufd. Attach can be
> undo by VFIO_DEVICE_DETACH_IOMMUFD_PT
> or device fd close.
> VFIO_DEVICE_DETACH_IOMMUFD_PT: detach vfio device from the current
> attached
> IOAS or hw_pagetable managed by iommufd.
>
> Signed-off-by: Yi Liu
> Reviewed-by: Kevin Tian
> ---
> drivers/vfio/device_cdev.c | 76 ++
> drivers/vfio/vfio.h| 16
> drivers/vfio/vfio_main.c | 8
> include/uapi/linux/vfio.h | 52 ++
> 4 files changed, 152 insertions(+)
>
> diff --git a/drivers/vfio/device_cdev.c b/drivers/vfio/device_cdev.c
> index 37f80e368551..5b5a249a6612 100644
> --- a/drivers/vfio/device_cdev.c
> +++ b/drivers/vfio/device_cdev.c
> @@ -191,6 +191,82 @@ long vfio_device_ioctl_bind_iommufd(struct
> vfio_device_file *df,
> return ret;
> }
>
> +int vfio_ioctl_device_attach(struct vfio_device_file *df,
> + void __user *arg)
This should be
struct vfio_device_attach_iommufd_pt __user *arg
> +{
> + struct vfio_device *device = df->device;
> + struct vfio_device_attach_iommufd_pt attach;
> + unsigned long minsz;
> + int ret;
> +
> + minsz = offsetofend(struct vfio_device_attach_iommufd_pt, pt_id);
> +
> + if (copy_from_user(, (void __user *)arg, minsz))
No cast
> + return -EFAULT;
> +
> + if (attach.argsz < minsz || attach.flags ||
> + attach.pt_id == IOMMUFD_INVALID_ID)
> + return -EINVAL;
> +
> + if (!device->ops->bind_iommufd)
> + return -ENODEV;
> +
> + mutex_lock(>dev_set->lock);
> + if (df->noiommu) {
> + ret = -EINVAL;
> + goto out_unlock;
> + }
> +
> + ret = device->ops->attach_ioas(device, _id);
> + if (ret)
> + goto out_unlock;
> +
> + ret = copy_to_user((void __user *)arg +
> +offsetofend(struct vfio_device_attach_iommufd_pt,
> flags),
This should just be >flags
> +_id,
> +sizeof(attach.pt_id)) ? -EFAULT : 0;
Also:
static_assert(__same_type(arg->flags), attach.pt_id);
> + if (ret)
> + goto out_detach;
> + mutex_unlock(>dev_set->lock);
> +
> + return 0;
> +
> +out_detach:
> + device->ops->detach_ioas(device);
> +out_unlock:
> + mutex_unlock(>dev_set->lock);
> + return ret;
> +}
> +
> +int vfio_ioctl_device_detach(struct vfio_device_file *df,
> + void __user *arg)
> +{
> + struct vfio_device *device = df->device;
> + struct vfio_device_detach_iommufd_pt detach;
> + unsigned long minsz;
> +
> + minsz = offsetofend(struct vfio_device_detach_iommufd_pt, flags);
> +
> + if (copy_from_user(, (void __user *)arg, minsz))
> + return -EFAULT;
Same comments here
> +
> + if (detach.argsz < minsz || detach.flags)
> + return -EINVAL;
> +
> + if (!device->ops->bind_iommufd)
> + return -ENODEV;
> +
> + mutex_lock(>dev_set->lock);
> + if (df->noiommu) {
> + mutex_unlock(>dev_set->lock);
> + return -EINVAL;
> + }
This seems strange. no iommu mode should have a NULL dev->iommufctx.
Why do we have a df->noiommu at all?
Jason
Re: [Intel-gfx] [PATCH v5 10/19] vfio: Add infrastructure for bind_iommufd from userspace
On Mon, Feb 27, 2023 at 03:11:26AM -0800, Yi Liu wrote:
> For the device fd opened from cdev, userspace needs to bind it to an
> iommufd and attach it to IOAS managed by iommufd. With such operations,
> userspace can set up a secure DMA context and hence access device.
>
> This changes the existing vfio_iommufd_bind() to accept a pt_id pointer
> as an optional input, and also an dev_id pointer to selectively return
> the dev_id to prepare for adding bind_iommufd ioctl, which does the bind
> first and then attach IOAS.
>
> Signed-off-by: Yi Liu
> Reviewed-by: Kevin Tian
> ---
> drivers/vfio/group.c | 17 ++---
> drivers/vfio/iommufd.c | 21 +
> drivers/vfio/vfio.h | 9 ++---
> drivers/vfio/vfio_main.c | 10 ++
> 4 files changed, 35 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/vfio/group.c b/drivers/vfio/group.c
> index d8771d585cb1..e44232551448 100644
> --- a/drivers/vfio/group.c
> +++ b/drivers/vfio/group.c
> @@ -169,6 +169,7 @@ static void vfio_device_group_get_kvm_safe(struct
> vfio_device *device)
> static int vfio_device_group_open(struct vfio_device_file *df)
> {
> struct vfio_device *device = df->device;
> + u32 ioas_id;
> int ret;
>
> mutex_lock(>group->group_lock);
> @@ -177,6 +178,13 @@ static int vfio_device_group_open(struct
> vfio_device_file *df)
> goto out_unlock;
> }
>
> + if (device->group->iommufd) {
> + ret = iommufd_vfio_compat_ioas_id(device->group->iommufd,
> + _id);
> + if (ret)
> + goto out_unlock;
> + }
I don't really like this being moved out of iommufd.c
Pass in a NULL pt_id and the do some
> -int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx)
> +int vfio_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx,
> + u32 *dev_id, u32 *pt_id)
> {
> - u32 ioas_id;
> u32 device_id;
> int ret;
>
> @@ -29,17 +29,14 @@ int vfio_iommufd_bind(struct vfio_device *vdev, struct
> iommufd_ctx *ictx)
> if (ret)
> return ret;
>
> - ret = iommufd_vfio_compat_ioas_id(ictx, _id);
> - if (ret)
> - goto err_unbind;
io_iommufd_bind(struct vfio_device *vdev, struct iommufd_ctx *ictx,
u32 *dev_id, u32 *pt_id)
{
u32 tmp_pt_id;
if (!pt_id) {
pt_id = _pt_id;
ret = iommufd_vfio_compat_ioas_id(ictx, pt_id);
if (ret)
goto err_unbind;
}
To handle it
And the commit message is sort of out of sync with the patch, more like:
vfio: Pass the pt_id as an argument to vfio_iommufd_bind()
To support binding the cdev the pt_id must come from userspace instead
of being forced to the compat_ioas_id.
Jason
Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Mon, Feb 27, 2023 at 03:11:25AM -0800, Yi Liu wrote:
> to indicate kernel to use the device's bound iommufd_ctx for the device
> ownership check. Kernel should loop all the opened devices in the dev_set,
> and check if they are bound to the same iommufd_ctx. For the devices that
> has not been opened yet but affected, they can be reset by the current
> users as they cannot be opened by any other user. This applies to the
> existing group/container path as well.
>
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Yi Liu
> ---
> drivers/vfio/pci/vfio_pci_core.c | 111 +++
> drivers/vfio/vfio.h | 11 +++
> include/uapi/linux/vfio.h| 16 +
> 3 files changed, 109 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_core.c
> b/drivers/vfio/pci/vfio_pci_core.c
> index 1bf54beeaef2..e0ebe55b4df0 100644
> --- a/drivers/vfio/pci/vfio_pci_core.c
> +++ b/drivers/vfio/pci/vfio_pci_core.c
> @@ -27,11 +27,13 @@
> #include
> #include
> #include
> +#include
Is this needed anymore?
> #if IS_ENABLED(CONFIG_EEH)
> #include
> #endif
>
> #include "vfio_pci_priv.h"
> +#include "../vfio.h"
Don't do this, put vfio_device_iommufd() in the normal public header
> diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h
> index 0552e8dcf0cb..4bf11ee8de53 100644
> --- a/include/uapi/linux/vfio.h
> +++ b/include/uapi/linux/vfio.h
> @@ -673,6 +673,22 @@ struct vfio_pci_hot_reset_info {
> * VFIO_DEVICE_PCI_HOT_RESET - _IOW(VFIO_TYPE, VFIO_BASE + 13,
> * struct vfio_pci_hot_reset)
> *
> + * Userspace requests hot reset for the devices it uses. Due to the
> + * underlying topology, multiple devices may be affected in the reset.
> + * The affected devices may have been opened by the user or by other
> + * users or not opened yet. Only when all the affected devices are
> + * either opened by the current user or not opened by any user, should
> + * the reset request be allowed. Otherwise, this request is expected
> + * to return error.
> + *
> + * If the user uses group and container interface, it should pass down
> + * a set of group fds for ownership check. If the user uses iommufd, it
> + * should pass down a zero-length group_fds array to indicate the kernel
> + * to use the bound iommufd for the ownership check. User that uses the
> + * vfio iommufd compatible mode can also pass down a zero-length group_fds
> + * array as this mode uses iommufd in kernel, and there is no reason to
> + * forbide it.
'forbid'
Rest looks good
Thanks,
Jason
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
== Series Details == Series: series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live URL : https://patchwork.freedesktop.org/series/114432/ State : success == Summary == CI Bug Log - changes from CI_DRM_12787 -> Patchwork_114432v1 Summary --- **WARNING** Minor unknown changes coming with Patchwork_114432v1 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_114432v1, 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_114432v1/index.html Participating hosts (39 -> 38) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_114432v1: ### IGT changes ### Warnings * igt@gem_exec_fence@basic-busy@vecs0: - fi-kbl-x1275: [DMESG-WARN][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12787/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vecs0.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vecs0.html Known issues Here are the changes found in Patchwork_114432v1 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_fence@basic-busy@vcs0: - fi-kbl-x1275: [ABORT][3] -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12787/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/fi-kbl-x1275/igt@gem_exec_fence@basic-b...@vcs0.html Build changes - * Linux: CI_DRM_12787 -> Patchwork_114432v1 CI-20190529: 20190529 CI_DRM_12787: 70da1d04c2abaaaef514174168a7e5595dbae6f3 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7173: deab4e0bdf5a9366b67d0a44f478f3da3c9a943b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114432v1: 70da1d04c2abaaaef514174168a7e5595dbae6f3 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 50d9bb55694e drm/i915: Use correct huge page manager for MTL 236427dd6e66 drm/i915: Migrate platform-dependent mock hugepage selftests to live == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v1/index.html
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: Communicate display power demands to pcode more accurately (rev2)
== Series Details == Series: drm/i915/display: Communicate display power demands to pcode more accurately (rev2) URL : https://patchwork.freedesktop.org/series/114401/ State : success == Summary == CI Bug Log - changes from CI_DRM_12779_full -> Patchwork_114401v2_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 9) -- Missing(1): shard-rkl0 Known issues Here are the changes found in Patchwork_114401v2_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_buddy@all-tests: - shard-tglu-10: NOTRUN -> [SKIP][1] ([i915#6433]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@drm_bu...@all-tests.html * igt@gem_ccs@block-copy-compressed: - shard-tglu-10: NOTRUN -> [SKIP][2] ([i915#3555] / [i915#5325]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gem_...@block-copy-compressed.html * igt@gem_ccs@ctrl-surf-copy-new-ctx: - shard-tglu-10: NOTRUN -> [SKIP][3] ([i915#5325]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gem_...@ctrl-surf-copy-new-ctx.html * igt@gem_eio@hibernate: - shard-tglu-10: NOTRUN -> [ABORT][4] ([i915#7975]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gem_...@hibernate.html * igt@gem_exec_fair@basic-pace@bcs0: - shard-tglu-10: NOTRUN -> [FAIL][5] ([i915#2842]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gem_exec_fair@basic-p...@bcs0.html * igt@gem_lmem_swapping@heavy-verify-multi: - shard-tglu-10: NOTRUN -> [SKIP][6] ([i915#4613]) +5 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gem_lmem_swapp...@heavy-verify-multi.html * igt@gem_pxp@create-regular-buffer: - shard-tglu-10: NOTRUN -> [SKIP][7] ([i915#4270]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gem_...@create-regular-buffer.html * igt@gem_userptr_blits@dmabuf-sync: - shard-tglu-10: NOTRUN -> [SKIP][8] ([i915#3323]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gem_userptr_bl...@dmabuf-sync.html * igt@gem_userptr_blits@invalid-mmap-offset-unsync: - shard-tglu-10: NOTRUN -> [SKIP][9] ([i915#3297]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gem_userptr_bl...@invalid-mmap-offset-unsync.html * igt@gen3_render_tiledy_blits: - shard-tglu-10: NOTRUN -> [SKIP][10] ([fdo#109289]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gen3_render_tiledy_blits.html * igt@gen9_exec_parse@bb-secure: - shard-tglu-10: NOTRUN -> [SKIP][11] ([i915#2527] / [i915#2856]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@gen9_exec_pa...@bb-secure.html * igt@i915_pm_rpm@modeset-non-lpsp: - shard-tglu-10: NOTRUN -> [SKIP][12] ([fdo#111644] / [i915#1397]) +2 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@i915_pm_...@modeset-non-lpsp.html * igt@i915_pm_rpm@pc8-residency: - shard-tglu-10: NOTRUN -> [SKIP][13] ([fdo#109506]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@i915_pm_...@pc8-residency.html * igt@kms_big_fb@4-tiled-32bpp-rotate-90: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271]) +31 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-apl6/igt@kms_big...@4-tiled-32bpp-rotate-90.html * igt@kms_big_fb@4-tiled-8bpp-rotate-270: - shard-tglu-10: NOTRUN -> [SKIP][15] ([i915#5286]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@kms_big...@4-tiled-8bpp-rotate-270.html * igt@kms_big_fb@y-tiled-8bpp-rotate-270: - shard-tglu-10: NOTRUN -> [SKIP][16] ([fdo#111614]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@kms_big...@y-tiled-8bpp-rotate-270.html * igt@kms_big_fb@yf-tiled-8bpp-rotate-0: - shard-tglu-10: NOTRUN -> [SKIP][17] ([fdo#111615]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114401v2/shard-tglu-10/igt@kms_big...@yf-tiled-8bpp-rotate-0.html * igt@kms_ccs@pipe-b-crc-sprite-planes-basic-y_tiled_gen12_mc_ccs: - shard-tglu-10: NOTRUN -> [SKIP][18] ([i915#3689] / [i915#3886]) +5 similar issues [18]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
== Series Details == Series: series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live URL : https://patchwork.freedesktop.org/series/114432/ State : warning == Summary == Error: dim checkpatch failed 8e94821ec3ff drm/i915: Migrate platform-dependent mock hugepage selftests to live -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests into total: 0 errors, 1 warnings, 0 checks, 58 lines checked f02e3f98bdef drm/i915: Use correct huge page manager for MTL -:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #6: MTL currently uses gen8_ppgtt_insert_huge when managing huge pages. This is because total: 0 errors, 1 warnings, 0 checks, 15 lines checked
Re: [Intel-gfx] [RFC PATCH 1/2] drm/msm/dpu: add dsc helper functions
On 2/27/2023 4:45 AM, Dmitry Baryshkov wrote:
On Mon, 27 Feb 2023 at 01:49, Abhinav Kumar wrote:
On 2/26/2023 5:09 AM, Dmitry Baryshkov wrote:
On 26/02/2023 02:47, Abhinav Kumar wrote:
Hi Dmitry
On 2/25/2023 7:23 AM, Dmitry Baryshkov wrote:
On 25/02/2023 02:36, Abhinav Kumar wrote:
On 2/24/2023 3:53 PM, Dmitry Baryshkov wrote:
On Sat, 25 Feb 2023 at 00:26, Abhinav Kumar
wrote:
On 2/24/2023 1:36 PM, Dmitry Baryshkov wrote:
24 февраля 2023 г. 23:23:03 GMT+02:00, Abhinav Kumar
пишет:
On 2/24/2023 1:13 PM, Dmitry Baryshkov wrote:
On 24/02/2023 21:40, Kuogee Hsieh wrote:
Add DSC helper functions based on DSC configuration profiles
to produce
DSC related runtime parameters through both table look up and
runtime
calculation to support DSC on DPU.
There are 6 different DSC configuration profiles are supported
currently.
DSC configuration profiles are differiented by 5 keys, DSC
version (V1.1),
chroma (444/422/420), colorspace (RGB/YUV), bpc(8/10),
bpp (6/7/7.5/8/9/10/12/15) and SCR (0/1).
Only DSC version V1.1 added and V1.2 will be added later.
These helpers should go to
drivers/gpu/drm/display/drm_dsc_helper.c
Also please check that they can be used for i915 or for amdgpu
(ideally for both of them).
No, it cannot. So each DSC encoder parameter is calculated based
on the HW core which is being used.
They all get packed to the same DSC structure which is the
struct drm_dsc_config but the way the parameters are computed is
specific to the HW.
This DPU file helper still uses the drm_dsc_helper's
drm_dsc_compute_rc_parameters() like all other vendors do but
the parameters themselves are very HW specific and belong to
each vendor's dir.
This is not unique to MSM.
Lets take a few other examples:
AMD:
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/amd/display/dc/dml/dsc/rc_calc_fpu.c#L165
i915:
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/i915/display/intel_vdsc.c#L379
I checked several values here. Intel driver defines more bpc/bpp
combinations, but the ones which are defined in intel_vdsc and in
this patch seem to match. If there are major differences there,
please point me to the exact case.
I remember that AMD driver might have different values.
Some values in the rc_params table do match. But the
rc_buf_thresh[] doesnt.
Because later they do:
vdsc_cfg->rc_buf_thresh[i] = rc_buf_thresh[i] >> 6;
https://gitlab.freedesktop.org/drm/msm/-/blob/msm-next/drivers/gpu/drm/i915/display/intel_vdsc.c#L40
Vs
+static u16 dpu_dsc_rc_buf_thresh[DSC_NUM_BUF_RANGES - 1] = {
+ 0x0e, 0x1c, 0x2a, 0x38, 0x46, 0x54,
+ 0x62, 0x69, 0x70, 0x77, 0x79, 0x7b, 0x7d, 0x7e
+};
I'd prefer to have 896, 1792, etc. here, as those values come from the
standard. As it's done in the Intel driver.
Got it, thanks
I dont know the AMD calculation very well to say that moving this
to the
helper is going to help.
Those calculations correspond (more or less) at the first glance to
what intel does for their newer generations. I think that's not our
problem for now.
Well, we have to figure out if each value matches and if each of
them come from the spec for us and i915 and from which section. So
it is unfortunately our problem.
Otherwise it will have to be handled by Marijn, me or anybody else
wanting to hack up the DSC code. Or by anybody adding DSC support to
the next platform and having to figure out the difference between
i915, msm and their platform.
Yes, I wonder why the same doubt didn't arise when the other vendors
added their support both from other maintainers and others.
Which makes me think that like I wrote in my previous response, these
are "recommended" values in the spec but its not mandatory.
I think, it is because there were no other drivers to compare. In other
words, for a first driver it is pretty logical to have everything
handled on its own. As soon as we start getting other implementations of
a feature, it becomes logical to think if the code can be generalized.
This is what we see we with the HDCP series or with the code being moved
to DP helpers.
We were not the second, MSM was/is the third to add support for DSC afer
i915 and AMD. Thats what made me think why whoever was the second didnt
end up generalizing. Was it just missed out or was it intentionally left
in the vendor driver.
I didn't count AMD here, since it calculates some of the params rather
than using the fixed ones from the model.
Moving this to the drm_dsc_helper is generalizing the tables and not
giving room for the vendors to customize even if they want to (which
the spec does allow).
That depends on the API you select. For example, in
intel_dsc_compute_params() I see customization being applied to
rc_buf_thresh in 6bpp case. I'd leave that to the i915 driver.
Thanks for going through the i915 to figure out that the 6bpp is handled
in a customized way. So what you are saying is let the helper first fill
up
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/dmc: allocate dmc structure dynamically
On Fri, 17 Feb 2023, Imre Deak wrote:
> On Fri, Feb 17, 2023 at 12:04:14PM +0200, Jani Nikula wrote:
>> On Thu, 16 Feb 2023, Imre Deak wrote:
>> > On Thu, Feb 16, 2023 at 06:17:39PM +0200, Jani Nikula wrote:
>> >> sizeof(struct intel_dmc) > 1024 bytes, allocated on all platforms as
>> >> part of struct drm_i915_private, whether they have DMC or not.
>> >>
>> >> Allocate struct intel_dmc dynamically, and hide all the dmc details
>> >> behind an opaque pointer in intel_dmc.c.
>> >>
>> >> Care must be taken to take into account all cases: DMC not supported on
>> >> the platform, DMC supported but not initialized, and DMC initialized but
>> >> not loaded. For the second case, we need to move the wakeref out of
>> >> struct intel_dmc.
>> >>
>> >> Cc: Imre Deak
>> >> Signed-off-by: Jani Nikula
>> >> ---
>> >> .../gpu/drm/i915/display/intel_display_core.h | 8 ++-
>> >> drivers/gpu/drm/i915/display/intel_dmc.c | 50 +--
>> >> drivers/gpu/drm/i915/display/intel_dmc.h | 34 +
>> >> .../drm/i915/display/intel_modeset_setup.c| 1 +
>> >> 4 files changed, 53 insertions(+), 40 deletions(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
>> >> b/drivers/gpu/drm/i915/display/intel_display_core.h
>> >> index b870f7f47f2b..ff51149c5fcb 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_display_core.h
>> >> +++ b/drivers/gpu/drm/i915/display/intel_display_core.h
>> >> @@ -19,7 +19,6 @@
>> >> #include "intel_cdclk.h"
>> >> #include "intel_display_limits.h"
>> >> #include "intel_display_power.h"
>> >> -#include "intel_dmc.h"
>> >> #include "intel_dpll_mgr.h"
>> >> #include "intel_fbc.h"
>> >> #include "intel_global_state.h"
>> >> @@ -40,6 +39,7 @@ struct intel_cdclk_vals;
>> >> struct intel_color_funcs;
>> >> struct intel_crtc;
>> >> struct intel_crtc_state;
>> >> +struct intel_dmc;
>> >> struct intel_dpll_funcs;
>> >> struct intel_dpll_mgr;
>> >> struct intel_fbdev;
>> >> @@ -340,6 +340,11 @@ struct intel_display {
>> >> spinlock_t phy_lock;
>> >> } dkl;
>> >>
>> >> + struct {
>> >> + struct intel_dmc *dmc;
>> >> + intel_wakeref_t wakeref;
>> >> + } dmc;
>> >> +
>> >> struct {
>> >> /* VLV/CHV/BXT/GLK DSI MMIO register base address */
>> >> u32 mmio_base;
>> >> @@ -467,7 +472,6 @@ struct intel_display {
>> >>
>> >> /* Grouping using named structs. Keep sorted. */
>> >> struct intel_audio audio;
>> >> - struct intel_dmc dmc;
>> >> struct intel_dpll dpll;
>> >> struct intel_fbc *fbc[I915_MAX_FBCS];
>> >> struct intel_frontbuffer_tracking fb_tracking;
>> >> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
>> >> b/drivers/gpu/drm/i915/display/intel_dmc.c
>> >> index 1d156ac2eb4c..8428d08e0c3d 100644
>> >> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
>> >> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
>> >> @@ -38,9 +38,37 @@
>> >> * low-power state and comes back to normal.
>> >> */
>> >>
>> >> +enum intel_dmc_id {
>> >> + DMC_FW_MAIN = 0,
>> >> + DMC_FW_PIPEA,
>> >> + DMC_FW_PIPEB,
>> >> + DMC_FW_PIPEC,
>> >> + DMC_FW_PIPED,
>> >> + DMC_FW_MAX
>> >> +};
>> >> +
>> >> +struct intel_dmc {
>> >> + struct drm_i915_private *i915;
>> >> + struct work_struct work;
>> >> + const char *fw_path;
>> >> + u32 max_fw_size; /* bytes */
>> >> + u32 version;
>> >> + struct dmc_fw_info {
>> >> + u32 mmio_count;
>> >> + i915_reg_t mmioaddr[20];
>> >> + u32 mmiodata[20];
>> >> + u32 dmc_offset;
>> >> + u32 start_mmioaddr;
>> >> + u32 dmc_fw_size; /*dwords */
>> >> + u32 *payload;
>> >> + bool present;
>> >> + } dmc_info[DMC_FW_MAX];
>> >> +};
>> >> +
>> >> +/* Note: This may be NULL. */
>> >> static struct intel_dmc *i915_to_dmc(struct drm_i915_private *i915)
>> >> {
>> >> - return >display.dmc;
>> >> + return i915->display.dmc.dmc;
>> >> }
>> >>
>> >> #define DMC_VERSION(major, minor)((major) << 16 | (minor))
>> >> @@ -937,7 +965,10 @@ void intel_dmc_init(struct drm_i915_private
>> >> *dev_priv)
>> >> if (!HAS_DMC(dev_priv))
>> >> return;
>> >>
>> >> - dmc = i915_to_dmc(dev_priv);
>> >> + dmc = kzalloc(sizeof(*dmc), GFP_KERNEL);
>> >> + if (!dmc)
>> >> + return;
>> >
>> > Couldn't driver loading fail in this case instead (simplifying the
>> > dmc==NULL checks elsewhere)?
>>
>> We could fail driver load, yes, but it still wouldn't simplify the NULL
>> checks because you could use i915.dmc_firmware_path="" to disable the
>> firmware, and what's the point in keeping the 1k memory allocated in
>> that case?
>
> Right, only noticed the same later. But that's only a debug feature so
> could be acceptable trade-off for simplicity imo; also the supported but
> non-initialized state wouldn't be needed then either.
>
> It's not a big deal and the check is local to intel_dmc.c, so either way
> on the patchset:
> Reviewed-by: Imre Deak
>
> (Querying the DMC FW presence in IGT needs
[Intel-gfx] [PATCH v3 4/4] drm/i915/dmc: allocate dmc structure dynamically
sizeof(struct intel_dmc) > 1024 bytes, allocated on all platforms as
part of struct drm_i915_private, whether they have DMC or not.
Allocate struct intel_dmc dynamically, and hide all the dmc details
behind an opaque pointer in intel_dmc.c.
Care must be taken to take into account all cases: DMC not supported on
the platform, DMC supported but not initialized, and DMC initialized but
not loaded. For the second case, we need to move the wakeref out of
struct intel_dmc.
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
.../gpu/drm/i915/display/intel_display_core.h | 8 ++-
drivers/gpu/drm/i915/display/intel_dmc.c | 50 +--
drivers/gpu/drm/i915/display/intel_dmc.h | 34 +
.../drm/i915/display/intel_modeset_setup.c| 1 +
4 files changed, 53 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_core.h
b/drivers/gpu/drm/i915/display/intel_display_core.h
index 631a7b17899e..fdab7bb93a7d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_core.h
+++ b/drivers/gpu/drm/i915/display/intel_display_core.h
@@ -19,7 +19,6 @@
#include "intel_cdclk.h"
#include "intel_display_limits.h"
#include "intel_display_power.h"
-#include "intel_dmc.h"
#include "intel_dpll_mgr.h"
#include "intel_fbc.h"
#include "intel_global_state.h"
@@ -40,6 +39,7 @@ struct intel_cdclk_vals;
struct intel_color_funcs;
struct intel_crtc;
struct intel_crtc_state;
+struct intel_dmc;
struct intel_dpll_funcs;
struct intel_dpll_mgr;
struct intel_fbdev;
@@ -340,6 +340,11 @@ struct intel_display {
spinlock_t phy_lock;
} dkl;
+ struct {
+ struct intel_dmc *dmc;
+ intel_wakeref_t wakeref;
+ } dmc;
+
struct {
/* VLV/CHV/BXT/GLK DSI MMIO register base address */
u32 mmio_base;
@@ -467,7 +472,6 @@ struct intel_display {
/* Grouping using named structs. Keep sorted. */
struct intel_audio audio;
- struct intel_dmc dmc;
struct intel_dpll dpll;
struct intel_fbc *fbc[I915_MAX_FBCS];
struct intel_frontbuffer_tracking fb_tracking;
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 0b54b9b96249..8deebd4b62fb 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -38,9 +38,37 @@
* low-power state and comes back to normal.
*/
+enum intel_dmc_id {
+ DMC_FW_MAIN = 0,
+ DMC_FW_PIPEA,
+ DMC_FW_PIPEB,
+ DMC_FW_PIPEC,
+ DMC_FW_PIPED,
+ DMC_FW_MAX
+};
+
+struct intel_dmc {
+ struct drm_i915_private *i915;
+ struct work_struct work;
+ const char *fw_path;
+ u32 max_fw_size; /* bytes */
+ u32 version;
+ struct dmc_fw_info {
+ u32 mmio_count;
+ i915_reg_t mmioaddr[20];
+ u32 mmiodata[20];
+ u32 dmc_offset;
+ u32 start_mmioaddr;
+ u32 dmc_fw_size; /*dwords */
+ u32 *payload;
+ bool present;
+ } dmc_info[DMC_FW_MAX];
+};
+
+/* Note: This may be NULL. */
static struct intel_dmc *i915_to_dmc(struct drm_i915_private *i915)
{
- return >display.dmc;
+ return i915->display.dmc.dmc;
}
#define DMC_VERSION(major, minor) ((major) << 16 | (minor))
@@ -937,7 +965,10 @@ void intel_dmc_init(struct drm_i915_private *dev_priv)
if (!HAS_DMC(dev_priv))
return;
- dmc = i915_to_dmc(dev_priv);
+ dmc = kzalloc(sizeof(*dmc), GFP_KERNEL);
+ if (!dmc)
+ return;
+
dmc->i915 = dev_priv;
INIT_WORK(>work, dmc_load_work_fn);
@@ -991,10 +1022,9 @@ void intel_dmc_init(struct drm_i915_private *dev_priv)
if (dev_priv->params.dmc_firmware_path) {
if (strlen(dev_priv->params.dmc_firmware_path) == 0) {
- dmc->fw_path = NULL;
drm_info(_priv->drm,
"Disabling DMC firmware and runtime PM\n");
- return;
+ goto out;
}
dmc->fw_path = dev_priv->params.dmc_firmware_path;
@@ -1003,11 +1033,18 @@ void intel_dmc_init(struct drm_i915_private *dev_priv)
if (!dmc->fw_path) {
drm_dbg_kms(_priv->drm,
"No known DMC firmware for platform, disabling
runtime PM\n");
- return;
+ goto out;
}
+ dev_priv->display.dmc.dmc = dmc;
+
drm_dbg_kms(_priv->drm, "Loading %s\n", dmc->fw_path);
schedule_work(>work);
+
+ return;
+
+out:
+ kfree(dmc);
}
/**
@@ -1074,6 +,9 @@ void intel_dmc_fini(struct drm_i915_private *dev_priv)
if (dmc) {
for_each_dmc_id(dmc_id)
kfree(dmc->dmc_info[dmc_id].payload);
+
+ kfree(dmc);
+
[Intel-gfx] [PATCH v3 3/4] drm/i915/dmc: add i915_to_dmc() and dmc->i915 and use them
Start preparing for dynamically allocated struct intel_dmc by adding
i915_to_dmc() and dmc->i915, and using them. Take the future NULL dmc
pointer into account already now, and add separate logging for
initialization in the DMC debugfs.
v2:
- Don't reduce debugfs output (Imre)
Cc: Imre Deak
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dmc.c | 94 ++--
drivers/gpu/drm/i915/display/intel_dmc.h | 1 +
2 files changed, 56 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 599fb92a5161..0b54b9b96249 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -38,6 +38,11 @@
* low-power state and comes back to normal.
*/
+static struct intel_dmc *i915_to_dmc(struct drm_i915_private *i915)
+{
+ return >display.dmc;
+}
+
#define DMC_VERSION(major, minor) ((major) << 16 | (minor))
#define DMC_VERSION_MAJOR(version) ((version) >> 16)
#define DMC_VERSION_MINOR(version) ((version) & 0x)
@@ -259,7 +264,9 @@ static bool is_valid_dmc_id(enum intel_dmc_id dmc_id)
static bool has_dmc_id_fw(struct drm_i915_private *i915, enum intel_dmc_id
dmc_id)
{
- return i915->display.dmc.dmc_info[dmc_id].payload;
+ struct intel_dmc *dmc = i915_to_dmc(i915);
+
+ return dmc && dmc->dmc_info[dmc_id].payload;
}
bool intel_dmc_has_payload(struct drm_i915_private *i915)
@@ -450,7 +457,7 @@ void intel_dmc_disable_pipe(struct drm_i915_private *i915,
enum pipe pipe)
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
struct i915_power_domains *power_domains =
_priv->display.power.domains;
- struct intel_dmc *dmc = _priv->display.dmc;
+ struct intel_dmc *dmc = i915_to_dmc(dev_priv);
enum intel_dmc_id dmc_id;
u32 i;
@@ -515,8 +522,11 @@ void intel_dmc_disable_program(struct drm_i915_private
*i915)
void assert_dmc_loaded(struct drm_i915_private *i915)
{
- drm_WARN_ONCE(>drm,
- !intel_de_read(i915,
DMC_PROGRAM(i915->display.dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
+ struct intel_dmc *dmc = i915_to_dmc(i915);
+
+ drm_WARN_ONCE(>drm, !dmc, "DMC not initialized\n");
+ drm_WARN_ONCE(>drm, dmc &&
+ !intel_de_read(i915,
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
"DMC program storage start is NULL\n");
drm_WARN_ONCE(>drm, !intel_de_read(i915, DMC_SSP_BASE),
"DMC SSP Base Not fine\n");
@@ -551,11 +561,10 @@ static void dmc_set_fw_offset(struct intel_dmc *dmc,
const struct stepping_info *si,
u8 package_ver)
{
+ struct drm_i915_private *i915 = dmc->i915;
enum intel_dmc_id dmc_id;
unsigned int i;
- struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
display.dmc);
-
for (i = 0; i < num_entries; i++) {
dmc_id = package_ver <= 1 ? DMC_FW_MAIN : fw_info[i].dmc_id;
@@ -582,7 +591,7 @@ static bool dmc_mmio_addr_sanity_check(struct intel_dmc
*dmc,
const u32 *mmioaddr, u32 mmio_count,
int header_ver, enum intel_dmc_id dmc_id)
{
- struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
display.dmc);
+ struct drm_i915_private *i915 = dmc->i915;
u32 start_range, end_range;
int i;
@@ -615,7 +624,7 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
const struct intel_dmc_header_base *dmc_header,
size_t rem_size, enum intel_dmc_id dmc_id)
{
- struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
display.dmc);
+ struct drm_i915_private *i915 = dmc->i915;
struct dmc_fw_info *dmc_info = >dmc_info[dmc_id];
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
@@ -726,7 +735,7 @@ parse_dmc_fw_package(struct intel_dmc *dmc,
const struct stepping_info *si,
size_t rem_size)
{
- struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
display.dmc);
+ struct drm_i915_private *i915 = dmc->i915;
u32 package_size = sizeof(struct intel_package_header);
u32 num_entries, max_entries;
const struct intel_fw_info *fw_info;
@@ -780,7 +789,7 @@ static u32 parse_dmc_fw_css(struct intel_dmc *dmc,
struct intel_css_header *css_header,
size_t rem_size)
{
- struct drm_i915_private *i915 = container_of(dmc, typeof(*i915),
display.dmc);
+ struct drm_i915_private *i915 = dmc->i915;
if (rem_size < sizeof(struct intel_css_header)) {
drm_err(>drm, "Truncated DMC firmware, refusing.\n");
@@
[Intel-gfx] [PATCH v3 2/4] drm/i915/dmc: use has_dmc_id_fw() instead of poking dmc->dmc_info directly
This will help in follow-up changes. Cc: Imre Deak Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/display/intel_dmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c b/drivers/gpu/drm/i915/display/intel_dmc.c index ab4fdedd4c5f..599fb92a5161 100644 --- a/drivers/gpu/drm/i915/display/intel_dmc.c +++ b/drivers/gpu/drm/i915/display/intel_dmc.c @@ -1098,12 +1098,12 @@ static int intel_dmc_debugfs_status_show(struct seq_file *m, void *unused) seq_printf(m, "Pipe A fw needed: %s\n", str_yes_no(GRAPHICS_VER(i915) >= 12)); seq_printf(m, "Pipe A fw loaded: %s\n", - str_yes_no(dmc->dmc_info[DMC_FW_PIPEA].payload)); + str_yes_no(has_dmc_id_fw(i915, DMC_FW_PIPEA))); seq_printf(m, "Pipe B fw needed: %s\n", str_yes_no(IS_ALDERLAKE_P(i915) || DISPLAY_VER(i915) >= 14)); seq_printf(m, "Pipe B fw loaded: %s\n", - str_yes_no(dmc->dmc_info[DMC_FW_PIPEB].payload)); + str_yes_no(has_dmc_id_fw(i915, DMC_FW_PIPEB))); if (!intel_dmc_has_payload(i915)) goto out; -- 2.39.1
[Intel-gfx] [PATCH v5 2/2] drm/i915: Use correct huge page manager for MTL
MTL currently uses gen8_ppgtt_insert_huge when managing huge pages. This is
because
MTL reports as not supporting 64K pages, or more accurately, the system that
reports
whether a platform has 64K pages reports false for MTL. This is only half
correct,
as the 64K page support reporting system only cares about 64K page support for
LMEM,
which MTL doesn't have.
MTL should be using xehpsdv_ppgtt_insert_huge. However, simply changing over to
using that manager doesn't resolve the issue because MTL is expecting the
virtual
address space for the page table to be flushed after initialization, so we must
also
add a flush statement there.
v2: Update igt_mock_ppgtt_huge_fill with current behavior expectations.
v3: Update igt_mock_ppgtt_64K with current behavior expectations.
v4: Break mock subtest changes into separate patch.
v5: Reorder
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4daaa6f55668..9c571185395f 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -570,6 +570,7 @@ xehpsdv_ppgtt_insert_huge(struct i915_address_space *vm,
}
} while (rem >= page_size && index < max);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
vma_res->page_sizes_gtt |= page_size;
} while (iter->sg && sg_dma_len(iter->sg));
}
@@ -707,7 +708,7 @@ static void gen8_ppgtt_insert(struct i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- if (HAS_64K_PAGES(vm->i915))
+ if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 50))
xehpsdv_ppgtt_insert_huge(vm, vma_res, ,
cache_level, flags);
else
gen8_ppgtt_insert_huge(vm, vma_res, , cache_level,
flags);
--
2.25.1
[Intel-gfx] [PATCH v5 1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests into
live selftests as their requirements have recently become platform-dependent.
Additionally, apply necessary platform dependency checks to these tests.
v2: Reorder
Signed-off-by: Jonathan Cavitt
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index defece0bcb81..375f119ab261 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -710,7 +710,7 @@ static void close_object_list(struct list_head *objects,
}
}
-static int igt_mock_ppgtt_huge_fill(void *arg)
+static int igt_ppgtt_huge_fill(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -784,7 +784,8 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
GEM_BUG_ON(!expected_gtt);
GEM_BUG_ON(size);
- if (expected_gtt & I915_GTT_PAGE_SIZE_4K)
+ if (expected_gtt & I915_GTT_PAGE_SIZE_4K &&
+ GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
expected_gtt &= ~I915_GTT_PAGE_SIZE_64K;
i915_vma_unpin(vma);
@@ -831,7 +832,7 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
return err;
}
-static int igt_mock_ppgtt_64K(void *arg)
+static int igt_ppgtt_64K(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -913,6 +914,17 @@ static int igt_mock_ppgtt_64K(void *arg)
unsigned int offset = objects[i].offset;
unsigned int flags = PIN_USER;
+ /*
+* For modern GTT models, the requirements for marking a
page-table
+* as 64K have been relaxed. Account for this.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
+ expected_gtt = 0;
+ expected_gtt |= size & (SZ_64K | SZ_2M) ?
I915_GTT_PAGE_SIZE_64K : 0;
+ expected_gtt |= size & SZ_4K ? I915_GTT_PAGE_SIZE_4K :
0;
+ }
+
for (single = 0; single <= 1; single++) {
obj = fake_huge_pages_object(i915, size, !!single);
if (IS_ERR(obj))
@@ -1910,8 +1922,6 @@ int i915_gem_huge_page_mock_selftests(void)
SUBTEST(igt_mock_exhaust_device_supported_pages),
SUBTEST(igt_mock_memory_region_huge_pages),
SUBTEST(igt_mock_ppgtt_misaligned_dma),
- SUBTEST(igt_mock_ppgtt_huge_fill),
- SUBTEST(igt_mock_ppgtt_64K),
};
struct drm_i915_private *dev_priv;
struct i915_ppgtt *ppgtt;
@@ -1962,6 +1972,8 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_ppgtt_sanity_check),
SUBTEST(igt_ppgtt_compact),
SUBTEST(igt_ppgtt_mixed),
+ SUBTEST(igt_ppgtt_huge_fill),
+ SUBTEST(igt_ppgtt_64K),
};
if (!HAS_PPGTT(i915)) {
--
2.25.1
[Intel-gfx] [PATCH v3 1/4] drm/i915/power: move dc state members to struct i915_power_domains
There's only one reference to the struct intel_dmc members dc_state,
target_dc_state, and allowed_dc_mask within intel_dmc.c, begging the
question why they are under struct intel_dmc to begin with.
Moreover, the only references to i915->display.dmc outside of
intel_dmc.c are to these members.
They don't belong. Move them from struct intel_dmc to struct
i915_power_domains, which seems like a more suitable place.
Cc: Imre Deak
Reviewed-by: Imre Deak
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_power.c| 25 ---
.../drm/i915/display/intel_display_power.h| 4 +++
.../i915/display/intel_display_power_well.c | 31 +++
drivers/gpu/drm/i915/display/intel_dmc.c | 3 +-
drivers/gpu/drm/i915/display/intel_dmc.h | 3 --
drivers/gpu/drm/i915/display/intel_psr.c | 3 +-
6 files changed, 39 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 743b919bb2cf..f085ae971150 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -264,9 +264,10 @@ bool intel_display_power_is_enabled(struct
drm_i915_private *dev_priv,
}
static u32
-sanitize_target_dc_state(struct drm_i915_private *dev_priv,
+sanitize_target_dc_state(struct drm_i915_private *i915,
u32 target_dc_state)
{
+ struct i915_power_domains *power_domains = >display.power.domains;
static const u32 states[] = {
DC_STATE_EN_UPTO_DC6,
DC_STATE_EN_UPTO_DC5,
@@ -279,7 +280,7 @@ sanitize_target_dc_state(struct drm_i915_private *dev_priv,
if (target_dc_state != states[i])
continue;
- if (dev_priv->display.dmc.allowed_dc_mask & target_dc_state)
+ if (power_domains->allowed_dc_mask & target_dc_state)
break;
target_dc_state = states[i + 1];
@@ -312,7 +313,7 @@ void intel_display_power_set_target_dc_state(struct
drm_i915_private *dev_priv,
state = sanitize_target_dc_state(dev_priv, state);
- if (state == dev_priv->display.dmc.target_dc_state)
+ if (state == power_domains->target_dc_state)
goto unlock;
dc_off_enabled = intel_power_well_is_enabled(dev_priv, power_well);
@@ -323,7 +324,7 @@ void intel_display_power_set_target_dc_state(struct
drm_i915_private *dev_priv,
if (!dc_off_enabled)
intel_power_well_enable(dev_priv, power_well);
- dev_priv->display.dmc.target_dc_state = state;
+ power_domains->target_dc_state = state;
if (!dc_off_enabled)
intel_power_well_disable(dev_priv, power_well);
@@ -992,10 +993,10 @@ int intel_power_domains_init(struct drm_i915_private
*dev_priv)
dev_priv->params.disable_power_well =
sanitize_disable_power_well_option(dev_priv,
dev_priv->params.disable_power_well);
- dev_priv->display.dmc.allowed_dc_mask =
+ power_domains->allowed_dc_mask =
get_allowed_dc_mask(dev_priv, dev_priv->params.enable_dc);
- dev_priv->display.dmc.target_dc_state =
+ power_domains->target_dc_state =
sanitize_target_dc_state(dev_priv, DC_STATE_EN_UPTO_DC6);
mutex_init(_domains->lock);
@@ -2032,7 +2033,7 @@ void intel_power_domains_suspend(struct drm_i915_private
*i915,
* resources as required and also enable deeper system power states
* that would be blocked if the firmware was inactive.
*/
- if (!(i915->display.dmc.allowed_dc_mask & DC_STATE_EN_DC9) &&
+ if (!(power_domains->allowed_dc_mask & DC_STATE_EN_DC9) &&
suspend_mode == I915_DRM_SUSPEND_IDLE &&
intel_dmc_has_payload(i915)) {
intel_display_power_flush_work(i915);
@@ -2221,22 +,22 @@ void intel_display_power_suspend(struct
drm_i915_private *i915)
void intel_display_power_resume(struct drm_i915_private *i915)
{
+ struct i915_power_domains *power_domains = >display.power.domains;
+
if (DISPLAY_VER(i915) >= 11) {
bxt_disable_dc9(i915);
icl_display_core_init(i915, true);
if (intel_dmc_has_payload(i915)) {
- if (i915->display.dmc.allowed_dc_mask &
- DC_STATE_EN_UPTO_DC6)
+ if (power_domains->allowed_dc_mask &
DC_STATE_EN_UPTO_DC6)
skl_enable_dc6(i915);
- else if (i915->display.dmc.allowed_dc_mask &
-DC_STATE_EN_UPTO_DC5)
+ else if (power_domains->allowed_dc_mask &
DC_STATE_EN_UPTO_DC5)
gen9_enable_dc5(i915);
}
} else if (IS_GEMINILAKE(i915) ||
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
On 27/02/2023 16:21, Jonathan Cavitt wrote:
Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests into
live selftests as their requirements have recently become platform-dependent.
Additionally, apply necessary platform dependency checks to these tests.
Signed-off-by: Jonathan Cavitt
The patch order should be the other way around. When the series is
applied to drm-intel-gt-next, every commit should pretty much always be
functional/bisectable. In this case the first patch by itself will make
the mock tests fail, if we don't already have this patch applied. It's
only a selftest so likely meh in practice, but in general we should
always try to keep every commit functional/bisectable.
Otherwise for the series,
Reviewed-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index defece0bcb81..375f119ab261 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -710,7 +710,7 @@ static void close_object_list(struct list_head *objects,
}
}
-static int igt_mock_ppgtt_huge_fill(void *arg)
+static int igt_ppgtt_huge_fill(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -784,7 +784,8 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
GEM_BUG_ON(!expected_gtt);
GEM_BUG_ON(size);
- if (expected_gtt & I915_GTT_PAGE_SIZE_4K)
+ if (expected_gtt & I915_GTT_PAGE_SIZE_4K &&
+ GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
expected_gtt &= ~I915_GTT_PAGE_SIZE_64K;
i915_vma_unpin(vma);
@@ -831,7 +832,7 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
return err;
}
-static int igt_mock_ppgtt_64K(void *arg)
+static int igt_ppgtt_64K(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -913,6 +914,17 @@ static int igt_mock_ppgtt_64K(void *arg)
unsigned int offset = objects[i].offset;
unsigned int flags = PIN_USER;
+ /*
+* For modern GTT models, the requirements for marking a
page-table
+* as 64K have been relaxed. Account for this.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
+ expected_gtt = 0;
+ expected_gtt |= size & (SZ_64K | SZ_2M) ?
I915_GTT_PAGE_SIZE_64K : 0;
+ expected_gtt |= size & SZ_4K ? I915_GTT_PAGE_SIZE_4K :
0;
+ }
+
for (single = 0; single <= 1; single++) {
obj = fake_huge_pages_object(i915, size, !!single);
if (IS_ERR(obj))
@@ -1910,8 +1922,6 @@ int i915_gem_huge_page_mock_selftests(void)
SUBTEST(igt_mock_exhaust_device_supported_pages),
SUBTEST(igt_mock_memory_region_huge_pages),
SUBTEST(igt_mock_ppgtt_misaligned_dma),
- SUBTEST(igt_mock_ppgtt_huge_fill),
- SUBTEST(igt_mock_ppgtt_64K),
};
struct drm_i915_private *dev_priv;
struct i915_ppgtt *ppgtt;
@@ -1962,6 +1972,8 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_ppgtt_sanity_check),
SUBTEST(igt_ppgtt_compact),
SUBTEST(igt_ppgtt_mixed),
+ SUBTEST(igt_ppgtt_huge_fill),
+ SUBTEST(igt_ppgtt_64K),
};
if (!HAS_PPGTT(i915)) {
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gen12: Update combo PHY init sequence (rev2)
On Tue, Feb 21, 2023 at 11:26:58PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/gen12: Update combo PHY init sequence (rev2) > URL : https://patchwork.freedesktop.org/series/114233/ > State : success > > == Summary == > > CI Bug Log - changes from CI_DRM_12768_full -> Patchwork_114233v2_full > > > Summary > --- > > **SUCCESS** > > No regressions found. Applied to drm-intel-next. Thanks Matt Atwood for the review. Matt > > External URL: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/index.html > > Participating hosts (10 -> 11) > -- > > Additional (1): shard-rkl0 > > Known issues > > > Here are the changes found in Patchwork_114233v2_full that come from known > issues: > > ### IGT changes ### > > Issues hit > > * igt@device_reset@cold-reset-bound: > - shard-tglu-10: NOTRUN -> [SKIP][1] ([i915#7701]) >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-10/igt@device_re...@cold-reset-bound.html > > * igt@fbdev@pan: > - shard-tglu-9: NOTRUN -> [SKIP][2] ([i915#2582]) >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-9/igt@fb...@pan.html > > * igt@feature_discovery@display-2x: > - shard-tglu-10: NOTRUN -> [SKIP][3] ([i915#1839]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-10/igt@feature_discov...@display-2x.html > > * igt@gem_ccs@ctrl-surf-copy: > - shard-tglu-10: NOTRUN -> [SKIP][4] ([i915#3555] / [i915#5325]) +1 > similar issue >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-10/igt@gem_...@ctrl-surf-copy.html > > * igt@gem_create@create-ext-cpu-access-big: > - shard-tglu-9: NOTRUN -> [SKIP][5] ([i915#6335]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-9/igt@gem_cre...@create-ext-cpu-access-big.html > > * igt@gem_ctx_persistence@smoketest: > - shard-tglu-9: NOTRUN -> [FAIL][6] ([i915#5099]) >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-9/igt@gem_ctx_persiste...@smoketest.html > > * igt@gem_exec_balancer@parallel-ordering: > - shard-tglu-9: NOTRUN -> [FAIL][7] ([i915#6117]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-9/igt@gem_exec_balan...@parallel-ordering.html > > * igt@gem_exec_fair@basic-none-solo@rcs0: > - shard-tglu-10: NOTRUN -> [FAIL][8] ([i915#2842]) >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-10/igt@gem_exec_fair@basic-none-s...@rcs0.html > > * igt@gem_exec_fair@basic-none@vcs0: > - shard-glk: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar > issue >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12768/shard-glk5/igt@gem_exec_fair@basic-n...@vcs0.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-glk3/igt@gem_exec_fair@basic-n...@vcs0.html > > * igt@gem_exec_fair@basic-pace-solo@rcs0: > - shard-tglu-9: NOTRUN -> [FAIL][11] ([i915#2842]) >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-9/igt@gem_exec_fair@basic-pace-s...@rcs0.html > > * igt@gem_lmem_swapping@verify-random: > - shard-tglu-10: NOTRUN -> [SKIP][12] ([i915#4613]) +1 similar issue >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-10/igt@gem_lmem_swapp...@verify-random.html > > * igt@gem_pxp@fail-invalid-protected-context: > - shard-tglu-10: NOTRUN -> [SKIP][13] ([i915#4270]) +3 similar issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-10/igt@gem_...@fail-invalid-protected-context.html > > * igt@gem_pxp@verify-pxp-stale-ctx-execution: > - shard-tglu-9: NOTRUN -> [SKIP][14] ([i915#4270]) +1 similar issue >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-9/igt@gem_...@verify-pxp-stale-ctx-execution.html > > * igt@gem_userptr_blits@access-control: > - shard-tglu-10: NOTRUN -> [SKIP][15] ([i915#3297]) +2 similar issues >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-10/igt@gem_userptr_bl...@access-control.html > > * igt@gem_userptr_blits@invalid-mmap-offset-unsync: > - shard-tglu-9: NOTRUN -> [SKIP][16] ([i915#3297]) >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-9/igt@gem_userptr_bl...@invalid-mmap-offset-unsync.html > > * igt@gen7_exec_parse@load-register-reg: > - shard-tglu-10: NOTRUN -> [SKIP][17] ([fdo#109289]) +4 similar > issues >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114233v2/shard-tglu-10/igt@gen7_exec_pa...@load-register-reg.html > > * igt@gen9_exec_parse@allowed-single:
Re: [Intel-gfx] [PATCH v2] drm/i915/gen12: Update combo PHY init sequence
On Tue, Feb 21, 2023 at 12:18:36PM -0800, Matt Roper wrote: > The bspec was updated with a minor change to the 'DCC mode select' > setting to be programmed during combo PHY initialization. > > v2: > - Keep the opencoded rmw behavior instead of switching to >intel_de_rmw(). We need to read from a _LN register, but write to >the _GRP register to update all lanes. > > Bspec: 49291 Reviewed-by: Matt Atwood > Signed-off-by: Matt Roper > --- > drivers/gpu/drm/i915/display/intel_combo_phy.c | 5 ++--- > drivers/gpu/drm/i915/display/intel_combo_phy_regs.h | 4 ++-- > 2 files changed, 4 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c > b/drivers/gpu/drm/i915/display/intel_combo_phy.c > index 27e98eabb006..922a6d87b553 100644 > --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c > +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c > @@ -233,8 +233,7 @@ static bool icl_combo_phy_verify_state(struct > drm_i915_private *dev_priv, >ICL_PORT_TX_DW8_ODCC_CLK_DIV_SEL_DIV2); > > ret &= check_phy_reg(dev_priv, phy, ICL_PORT_PCS_DW1_LN(0, phy), > - DCC_MODE_SELECT_MASK, > - DCC_MODE_SELECT_CONTINUOSLY); > + DCC_MODE_SELECT_MASK, RUN_DCC_ONCE); > } > > ret &= icl_verify_procmon_ref_values(dev_priv, phy); > @@ -354,7 +353,7 @@ static void icl_combo_phys_init(struct drm_i915_private > *dev_priv) > > val = intel_de_read(dev_priv, ICL_PORT_PCS_DW1_LN(0, > phy)); > val &= ~DCC_MODE_SELECT_MASK; > - val |= DCC_MODE_SELECT_CONTINUOSLY; > + val |= RUN_DCC_ONCE; > intel_de_write(dev_priv, ICL_PORT_PCS_DW1_GRP(phy), > val); > } > > diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy_regs.h > b/drivers/gpu/drm/i915/display/intel_combo_phy_regs.h > index 2ed65193ca19..b0983edccf3f 100644 > --- a/drivers/gpu/drm/i915/display/intel_combo_phy_regs.h > +++ b/drivers/gpu/drm/i915/display/intel_combo_phy_regs.h > @@ -90,8 +90,8 @@ > #define ICL_PORT_PCS_DW1_AUX(phy)_MMIO(_ICL_PORT_PCS_DW_AUX(1, > phy)) > #define ICL_PORT_PCS_DW1_GRP(phy)_MMIO(_ICL_PORT_PCS_DW_GRP(1, > phy)) > #define ICL_PORT_PCS_DW1_LN(ln, phy) _MMIO(_ICL_PORT_PCS_DW_LN(1, > ln, phy)) > -#define DCC_MODE_SELECT_MASK (0x3 << 20) > -#define DCC_MODE_SELECT_CONTINUOSLY(0x3 << 20) > +#define DCC_MODE_SELECT_MASK REG_GENMASK(21, 20) > +#define RUN_DCC_ONCE > REG_FIELD_PREP(DCC_MODE_SELECT_MASK, 0) > #define COMMON_KEEPER_EN (1 << 26) > #define LATENCY_OPTIM_MASK (0x3 << 2) > #define LATENCY_OPTIM_VAL(x) ((x) << 2) > -- > 2.39.1 >
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v4,1/2] drm/i915: Use correct huge page manager for MTL
== Series Details == Series: series starting with [v4,1/2] drm/i915: Use correct huge page manager for MTL URL : https://patchwork.freedesktop.org/series/114428/ State : success == Summary == CI Bug Log - changes from CI_DRM_12786 -> Patchwork_114428v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/index.html Participating hosts (40 -> 38) -- Missing(2): fi-kbl-soraka fi-snb-2520m Changes --- No changes found Build changes - * Linux: CI_DRM_12786 -> Patchwork_114428v1 CI-20190529: 20190529 CI_DRM_12786: f182ba6684a2393069248bc946f20ceabd9e395d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7173: deab4e0bdf5a9366b67d0a44f478f3da3c9a943b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114428v1: f182ba6684a2393069248bc946f20ceabd9e395d @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 3a1c8a32b095 drm/i915: Migrate platform-dependent mock hugepage selftests to live c80c1df6f164 drm/i915: Use correct huge page manager for MTL == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114428v1/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v4,1/2] drm/i915: Use correct huge page manager for MTL
== Series Details == Series: series starting with [v4,1/2] drm/i915: Use correct huge page manager for MTL URL : https://patchwork.freedesktop.org/series/114428/ State : warning == Summary == Error: dim checkpatch failed 39e49179dfa7 drm/i915: Use correct huge page manager for MTL -:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #6: MTL currently uses gen8_ppgtt_insert_huge when managing huge pages. This is because total: 0 errors, 1 warnings, 0 checks, 15 lines checked 63e6266701df drm/i915: Migrate platform-dependent mock hugepage selftests to live -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests into total: 0 errors, 1 warnings, 0 checks, 58 lines checked
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: Fix csync detailed mode parsing
== Series Details == Series: drm/edid: Fix csync detailed mode parsing URL : https://patchwork.freedesktop.org/series/114424/ State : success == Summary == CI Bug Log - changes from CI_DRM_12786 -> Patchwork_114424v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/index.html Participating hosts (40 -> 38) -- Missing(2): fi-kbl-soraka fi-snb-2520m Changes --- No changes found Build changes - * Linux: CI_DRM_12786 -> Patchwork_114424v1 CI-20190529: 20190529 CI_DRM_12786: f182ba6684a2393069248bc946f20ceabd9e395d @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7173: deab4e0bdf5a9366b67d0a44f478f3da3c9a943b @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114424v1: f182ba6684a2393069248bc946f20ceabd9e395d @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits bfbeab2e98ce drm/edid: Fix csync detailed mode parsing == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114424v1/index.html
[Intel-gfx] [PATCH v4 2/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests into
live selftests as their requirements have recently become platform-dependent.
Additionally, apply necessary platform dependency checks to these tests.
Signed-off-by: Jonathan Cavitt
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index defece0bcb81..375f119ab261 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -710,7 +710,7 @@ static void close_object_list(struct list_head *objects,
}
}
-static int igt_mock_ppgtt_huge_fill(void *arg)
+static int igt_ppgtt_huge_fill(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -784,7 +784,8 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
GEM_BUG_ON(!expected_gtt);
GEM_BUG_ON(size);
- if (expected_gtt & I915_GTT_PAGE_SIZE_4K)
+ if (expected_gtt & I915_GTT_PAGE_SIZE_4K &&
+ GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
expected_gtt &= ~I915_GTT_PAGE_SIZE_64K;
i915_vma_unpin(vma);
@@ -831,7 +832,7 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
return err;
}
-static int igt_mock_ppgtt_64K(void *arg)
+static int igt_ppgtt_64K(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -913,6 +914,17 @@ static int igt_mock_ppgtt_64K(void *arg)
unsigned int offset = objects[i].offset;
unsigned int flags = PIN_USER;
+ /*
+* For modern GTT models, the requirements for marking a
page-table
+* as 64K have been relaxed. Account for this.
+*/
+
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
+ expected_gtt = 0;
+ expected_gtt |= size & (SZ_64K | SZ_2M) ?
I915_GTT_PAGE_SIZE_64K : 0;
+ expected_gtt |= size & SZ_4K ? I915_GTT_PAGE_SIZE_4K :
0;
+ }
+
for (single = 0; single <= 1; single++) {
obj = fake_huge_pages_object(i915, size, !!single);
if (IS_ERR(obj))
@@ -1910,8 +1922,6 @@ int i915_gem_huge_page_mock_selftests(void)
SUBTEST(igt_mock_exhaust_device_supported_pages),
SUBTEST(igt_mock_memory_region_huge_pages),
SUBTEST(igt_mock_ppgtt_misaligned_dma),
- SUBTEST(igt_mock_ppgtt_huge_fill),
- SUBTEST(igt_mock_ppgtt_64K),
};
struct drm_i915_private *dev_priv;
struct i915_ppgtt *ppgtt;
@@ -1962,6 +1972,8 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_ppgtt_sanity_check),
SUBTEST(igt_ppgtt_compact),
SUBTEST(igt_ppgtt_mixed),
+ SUBTEST(igt_ppgtt_huge_fill),
+ SUBTEST(igt_ppgtt_64K),
};
if (!HAS_PPGTT(i915)) {
--
2.25.1
[Intel-gfx] [PATCH v4 1/2] drm/i915: Use correct huge page manager for MTL
MTL currently uses gen8_ppgtt_insert_huge when managing huge pages. This is
because
MTL reports as not supporting 64K pages, or more accurately, the system that
reports
whether a platform has 64K pages reports false for MTL. This is only half
correct,
as the 64K page support reporting system only cares about 64K page support for
LMEM,
which MTL doesn't have.
MTL should be using xehpsdv_ppgtt_insert_huge. However, simply changing over to
using that manager doesn't resolve the issue because MTL is expecting the
virtual
address space for the page table to be flushed after initialization, so we must
also
add a flush statement there.
v2: Update igt_mock_ppgtt_huge_fill with current behavior expectations.
v3: Update igt_mock_ppgtt_64K with current behavior expectations.
v4: Break mock subtest changes into separate patch.
Signed-off-by: Jonathan Cavitt
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
index 4daaa6f55668..9c571185395f 100644
--- a/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen8_ppgtt.c
@@ -570,6 +570,7 @@ xehpsdv_ppgtt_insert_huge(struct i915_address_space *vm,
}
} while (rem >= page_size && index < max);
+ drm_clflush_virt_range(vaddr, PAGE_SIZE);
vma_res->page_sizes_gtt |= page_size;
} while (iter->sg && sg_dma_len(iter->sg));
}
@@ -707,7 +708,7 @@ static void gen8_ppgtt_insert(struct i915_address_space *vm,
struct sgt_dma iter = sgt_dma(vma_res);
if (vma_res->bi.page_sizes.sg > I915_GTT_PAGE_SIZE) {
- if (HAS_64K_PAGES(vm->i915))
+ if (GRAPHICS_VER_FULL(vm->i915) >= IP_VER(12, 50))
xehpsdv_ppgtt_insert_huge(vm, vma_res, ,
cache_level, flags);
else
gen8_ppgtt_insert_huge(vm, vma_res, , cache_level,
flags);
--
2.25.1
