Re: [Intel-gfx] [PATCH v3 00/15] Add vfio_device cdev for iommufd support
> From: Alex Williamson > Sent: Tuesday, February 14, 2023 11:47 PM > > On Tue, 14 Feb 2023 01:55:17 + > "Liu, Yi L" wrote: > > > > From: Alex Williamson > > > Sent: Tuesday, February 14, 2023 3:47 AM > > > > > > On Mon, 13 Feb 2023 07:13:33 -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 > vfio_device_open() > > > be > > > > 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_v3 > > > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > > > Even using your branch[1], it seems like this has not been tested > > > except with cdev support enabled: > > > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > > ‘vfio_device_add’: > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:253:48: error: > ‘struct > > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > > 253 | ret = cdev_device_add(>cdev, > > > >device); > > > |^~~~ > > > |dev > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > > ‘vfio_device_del’: > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:262:42: error: > ‘struct > > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > > 262 | cdev_device_del(>cdev, >device); > > > | ^~~~ > > > | dev > > > > Sorry for it. It is due to the cdev definition is under > > "#if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)". While, in the code it > > uses "if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". I think for > > readability, it would be better to always define cdev in vfio_device, > > and keep the using of cdev in code. How about your taste? > > It seems necessary unless we want to litter the code with #ifdefs. I've moved it to the header file and call cdev_device_add() under #if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". > > > Additionally the VFIO_ENABLE_GROUP Kconfig option doesn't make much > > > sense to me, it seems entirely redundant to VFIO_GROUP. > > > > The intention is to make the group code compiling match existing case. > > Currently, if VFIO is configured, group code is by default compiled. > > So VFIO_ENABLE_GROUP a hidden option, and VFIO_GROUP an option > > for user. User needs to explicitly config VFIO_GROUP if > > VFIO_DEVICE_CDEV==y. > > If VFIO_DEVICE_CDEV==n, then no matter user configed VFIO_GROUP or > > not, the group code shall be compiled. > > I understand the mechanics, I still find VFIO_ENABLE_GROUP redundant > and unnecessary. Also, Kconfig should not allow a configuration > without either VFIO_GROUP or VFIO_DEVICE_CDEV as this is not > functional. Deselecting VFIO_GROUP should select VFIO_DEVICE_CDEV, > but VFIO_DEVICE_CDEV should be an optional addition to VFIO_GROUP. How about below? As Jason's remark on patch 0003, cdev is not available for SPAPR. diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig index 0476abf154f2..96535adc2301 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) select VFIO_CONTAINER if IOMMUFD=n help VFIO provides a framework for secure userspace device drivers. @@ -14,7 +16,8 @@ menuconfig VFIO if VFIO config
Re: [Intel-gfx] [PATCH v3 05/15] kvm/vfio: Accept vfio device file from userspace
> From: Jason Gunthorpe
> Sent: Wednesday, February 15, 2023 7:25 AM
>
> On Tue, Feb 14, 2023 at 03:26:27PM -0700, Alex Williamson wrote:
> > > index 857d6ba349e1..d869913baafd 100644
> > > --- a/virt/kvm/vfio.c
> > > +++ b/virt/kvm/vfio.c
> > > @@ -286,18 +286,18 @@ static int kvm_vfio_set_file(struct kvm_device
> *dev, long attr,
> > > int32_t fd;
> > >
> > > switch (attr) {
> > > - case KVM_DEV_VFIO_GROUP_ADD:
> > > + case KVM_DEV_VFIO_FILE_ADD:
> > > if (get_user(fd, argp))
> > > return -EFAULT;
> > > return kvm_vfio_file_add(dev, fd);
> > >
> > > - case KVM_DEV_VFIO_GROUP_DEL:
> > > + case KVM_DEV_VFIO_FILE_DEL:
> > > if (get_user(fd, argp))
> > > return -EFAULT;
> > > return kvm_vfio_file_del(dev, fd);
> > >
> > > #ifdef CONFIG_SPAPR_TCE_IOMMU
> > > - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE:
> > > + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE:
> > > return kvm_vfio_file_set_spapr_tce(dev, arg);
> >
> > I don't see that the SPAPR code is so easily fungible to a device
> > file descriptor. The kvm_vfio_spapr_tce data structure includes a
> > groupfd, which is required to match a groupfd on the file_list. So
> > a SPAPR user cannot pass a cdev via FILE_ADD if they intend to use
> > this TCE code.
>
> SPAPR cannot use cdev at all, cdev mode only works with iommufd.
>
> So with my other remark about blocking unbound cdevs, in SPAPR mode
> you can never open a cdev and make it bound thus
> kvm_vfio_file_iommu_group() and others will return NULL always for
> cdev.
>
> Thus AFAICT this is all fine.
>
> Yi, you should also add some kconfig stuff to ensure that SPAPR always
> has the group interface compiled in.
Ok. I can make VFIO to select VFIO_GROUP for SPAPR.
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH v3 14/15] vfio: Add ioctls for device cdev using iommufd
> From: Tian, Kevin
> Sent: Wednesday, February 15, 2023 10:05 AM
>
> > From: Zhao, Yan Y
> > Sent: Wednesday, February 15, 2023 7:39 AM
> >
> > On Mon, Feb 13, 2023 at 07:13:47AM -0800, Yi Liu wrote:
> > ...
> > > +long vfio_device_ioctl_bind_iommufd(struct vfio_device_file *df,
> > > + unsigned long arg)
> > > +{
> > > + struct vfio_device *device = df->device;
> > > + struct vfio_device_bind_iommufd bind;
> > > + struct iommufd_ctx *iommufd = NULL;
> > > + struct fd f;
> > > + 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_claim_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 {
> > > + f = fdget(bind.iommufd);
> > > + if (!f.file) {
> > > + ret = -EBADF;
> > > + goto out_unlock;
> > > + }
> > > + iommufd = iommufd_ctx_from_file(f.file);
> > > + if (IS_ERR(iommufd)) {
> > > + ret = PTR_ERR(iommufd);
> > > + goto out_put_file;
> > > + }
> > > + }
> > > +
> > > + /*
> > > + * 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),
> > > +_devid,
> > > +sizeof(bind.out_devid)) ? -EFAULT : 0;
> > > + if (ret)
> > > + goto out_close_device;
> > > +
> > > + if (iommufd)
> > > + fdput(f);
> > > + else if (df->noiommu)
> > > + dev_warn(device->dev, "vfio-noiommu device used by user
> "
> > > + "(%s:%d)\n", current->comm,
> task_pid_nr(current));
> >
> > IMHO, the "smp_store_release(>access_granted, true);" in patch 7
> > should be moved to here when bind is indeed successful.
> >
>
> yes. in that case patch7 should put release in vfio_device_group_open()
> and then add a new release here.
Right. This needs to be set in the caller instead of the vfio_device_open().
Done in the latest branch on github.
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page()
On Tue, Feb 14, 2023 at 08:25:08PM -0800, Ira Weiny wrote: > Date: Tue, 14 Feb 2023 20:25:08 -0800 > From: Ira Weiny > Subject: Re: [PATCH 0/9] drm/i915: Replace kmap_atomic() with > kmap_local_page() > > Zhao Liu wrote: > > From: Zhao Liu > > > > The use of kmap_atomic() is being deprecated in favor of > > kmap_local_page()[1]. > > Zhao, > > Was there ever a v2 of this series? I'm not finding it on Lore. Sorry Ira, my delay is too long, I was busy with other patch work, I will refresh v2 soon, and push this forward! Best Regards, Zhao > > Thanks, > Ira > > > > > In the following patches, we can convert the calls of kmap_atomic() / > > kunmap_atomic() to kmap_local_page() / kunmap_local(), which can > > instead do the mapping / unmapping regardless of the context. > > > > With kmap_local_page(), the mapping is per thread, CPU local and not > > globally visible. > > > > [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com > > --- > > Zhao Liu (9): > > drm/i915: Use kmap_local_page() in gem/i915_gem_object.c > > drm/i915: Use kmap_local_page() in gem/i915_gem_pyhs.c > > drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c > > drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c > > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c > > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c > > drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c > > drm/i915: Use kmap_local_page() in i915_cmd_parser.c > > drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c > > > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +- > > drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++- > > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 8 > > drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 6 -- > > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++--- > > .../gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 > > .../gpu/drm/i915/gem/selftests/i915_gem_context.c| 8 > > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 + > > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- > > 9 files changed, 30 insertions(+), 37 deletions(-) > > > > -- > > 2.34.1 > > > >
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: move a Kconfig symbol to unbreak the menu presentation
== Series Details ==
Series: drm/i915: move a Kconfig symbol to unbreak the menu presentation
URL : https://patchwork.freedesktop.org/series/114037/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12741 -> Patchwork_114037v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114037v1/index.html
Participating hosts (38 -> 38)
--
Additional (1): fi-pnv-d510
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114037v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-rpls-1}: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114037v1/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_114037v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@dmabuf:
- fi-bsw-nick:[PASS][3] -> [DMESG-FAIL][4] ([i915#7562] /
[i915#7913])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114037v1/fi-bsw-nick/igt@i915_selftest@l...@dmabuf.html
* igt@kms_psr@primary_page_flip:
- fi-pnv-d510:NOTRUN -> [SKIP][5] ([fdo#109271]) +44 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114037v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-glk-j4005: [DMESG-FAIL][6] ([i915#5334]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114037v1/fi-glk-j4005/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@requests:
- {bat-rpls-2}: [ABORT][8] ([i915#7982]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12741/bat-rpls-2/igt@i915_selftest@l...@requests.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114037v1/bat-rpls-2/igt@i915_selftest@l...@requests.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
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7562]: https://gitlab.freedesktop.org/drm/intel/issues/7562
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
[i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12741 -> Patchwork_114037v1
CI-20190529: 20190529
CI_DRM_12741: 67545af096c3c8dee1d48662a3f4830cd84b1105 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7160: 45da871dd2684227e93a2fc002b87dfc58bd5fd9 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_114037v1: 67545af096c3c8dee1d48662a3f4830cd84b1105 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
cbd2c02030bb drm/i915: move a Kconfig symbol to unbreak the menu presentation
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114037v1/index.html
Re: [Intel-gfx] [PATCH v3 07/15] vfio: Block device access via device fd until device is opened
> From: Alex Williamson
> Sent: Wednesday, February 15, 2023 6:47 AM
>
> On Mon, 13 Feb 2023 07:13:40 -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/vfio.h | 1 +
> > drivers/vfio/vfio_main.c | 34 +-
> > 2 files changed, 34 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> > index 11e56fe079a1..d56cdb114024 100644
> > --- a/drivers/vfio/vfio.h
> > +++ b/drivers/vfio/vfio.h
> > @@ -18,6 +18,7 @@ struct vfio_container;
> >
> > struct vfio_device_file {
> > struct vfio_device *device;
> > + bool access_granted;
> > spinlock_t kvm_ref_lock; /* protect kvm field */
> > struct kvm *kvm;
> > struct iommufd_ctx *iommufd; /* protected by struct
> vfio_device_set::lock */
> > diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> > index c517252aba19..2267057240bd 100644
> > --- a/drivers/vfio/vfio_main.c
> > +++ b/drivers/vfio/vfio_main.c
> > @@ -476,7 +476,15 @@ int vfio_device_open(struct vfio_device_file *df)
> > device->open_count--;
> > }
> >
> > - return ret;
> > + if (ret)
> > + return ret;
> > +
> > + /*
> > +* Paired with smp_load_acquire() in vfio_device_fops::ioctl/
> > +* read/write/mmap
> > +*/
> > + smp_store_release(>access_granted, true);
> > + return 0;
> > }
> >
> > void vfio_device_close(struct vfio_device_file *df)
> > @@ -1104,8 +1112,14 @@ static long vfio_device_fops_unl_ioctl(struct
> file *filep,
> > {
> > struct vfio_device_file *df = filep->private_data;
> > struct vfio_device *device = df->device;
> > + bool access;
> > int ret;
> >
> > + /* Paired with smp_store_release() in vfio_device_open() */
> > + access = smp_load_acquire(>access_granted);
> > + if (!access)
> > + return -EINVAL;
> > +
>
> Nit,
>
> if (!smp_load_acquire(>access_granted))
> ...
Got it. also updated other similar lines.
> Thanks,
> Alex
>
> > ret = vfio_device_pm_runtime_get(device);
> > if (ret)
> > return ret;
> > @@ -1132,6 +1146,12 @@ static ssize_t vfio_device_fops_read(struct file
> *filep, char __user *buf,
> > {
> > struct vfio_device_file *df = filep->private_data;
> > struct vfio_device *device = df->device;
> > + bool access;
> > +
> > + /* Paired with smp_store_release() in vfio_device_open() */
> > + access = smp_load_acquire(>access_granted);
> > + if (!access)
> > + return -EINVAL;
> >
> > if (unlikely(!device->ops->read))
> > return -EINVAL;
> > @@ -1145,6 +1165,12 @@ static ssize_t vfio_device_fops_write(struct file
> *filep,
> > {
> > struct vfio_device_file *df = filep->private_data;
> > struct vfio_device *device = df->device;
> > + bool access;
> > +
> > + /* Paired with smp_store_release() in vfio_device_open() */
> > + access = smp_load_acquire(>access_granted);
> > + if (!access)
> > + return -EINVAL;
> >
> > if (unlikely(!device->ops->write))
> > return -EINVAL;
> > @@ -1156,6 +1182,12 @@ static int vfio_device_fops_mmap(struct file
> *filep, struct vm_area_struct *vma)
> > {
> > struct vfio_device_file *df = filep->private_data;
> > struct vfio_device *device = df->device;
> > + bool access;
> > +
> > + /* Paired with smp_store_release() in vfio_device_open() */
> > + access = smp_load_acquire(>access_granted);
> > + if (!access)
> > + return -EINVAL;
> >
> > if (unlikely(!device->ops->mmap))
> > return -EINVAL;
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH] drm/i915: move a Kconfig symbol to unbreak the menu presentation
On Tue, Feb 14, 2023 at 08:45:33PM -0800, Randy Dunlap wrote: > Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT) > into a list of other symbols that do have a dependency (on DRM_I915) > breaks the driver menu presentation in 'make *config'. > > Relocate the DRM_I915_GVT symbol so that it does not cause this > problem. Looks good: Reviewed-by: Christoph Hellwig
Re: [Intel-gfx] [PATCH 13/19] arch/riscv: rename internal name __xchg to __arch_xchg
On Thu, 22 Dec 2022 03:46:29 PST (-0800), andrzej.ha...@intel.com wrote:
__xchg will be used for non-atomic xchg macro.
Signed-off-by: Andrzej Hajda
---
arch/riscv/include/asm/atomic.h | 2 +-
arch/riscv/include/asm/cmpxchg.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/riscv/include/asm/atomic.h b/arch/riscv/include/asm/atomic.h
index 0dfe9d857a762b..bba472928b5393 100644
--- a/arch/riscv/include/asm/atomic.h
+++ b/arch/riscv/include/asm/atomic.h
@@ -261,7 +261,7 @@ c_t arch_atomic##prefix##_xchg_release(atomic##prefix##_t
*v, c_t n)\
static __always_inline \
c_t arch_atomic##prefix##_xchg(atomic##prefix##_t *v, c_t n) \
{ \
- return __xchg(&(v->counter), n, size); \
+ return __arch_xchg(&(v->counter), n, size); \
} \
static __always_inline \
c_t arch_atomic##prefix##_cmpxchg_relaxed(atomic##prefix##_t *v, \
diff --git a/arch/riscv/include/asm/cmpxchg.h b/arch/riscv/include/asm/cmpxchg.h
index 12debce235e52d..2f4726d3cfcc25 100644
--- a/arch/riscv/include/asm/cmpxchg.h
+++ b/arch/riscv/include/asm/cmpxchg.h
@@ -114,7 +114,7 @@
_x_, sizeof(*(ptr))); \
})
-#define __xchg(ptr, new, size) \
+#define __arch_xchg(ptr, new, size)\
({ \
__typeof__(ptr) __ptr = (ptr); \
__typeof__(new) __new = (new); \
@@ -143,7 +143,7 @@
#define arch_xchg(ptr, x) \
({ \
__typeof__(*(ptr)) _x_ = (x); \
- (__typeof__(*(ptr))) __xchg((ptr), _x_, sizeof(*(ptr)));\
+ (__typeof__(*(ptr))) __arch_xchg((ptr), _x_, sizeof(*(ptr))); \
})
#define xchg32(ptr, x) \
Acked-by: Palmer Dabbelt
[Intel-gfx] [PATCH] drm/i915: move a Kconfig symbol to unbreak the menu presentation
Inserting a Kconfig symbol that does not have a dependency (DRM_I915_GVT)
into a list of other symbols that do have a dependency (on DRM_I915)
breaks the driver menu presentation in 'make *config'.
Relocate the DRM_I915_GVT symbol so that it does not cause this
problem.
Fixes: 8b750bf74418 ("drm/i915/gvt: move the gvt code into kvmgt.ko")
Signed-off-by: Randy Dunlap
Cc: Christoph Hellwig
Cc: Zhi Wang
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: Zhenyu Wang
Cc: intel-gfx@lists.freedesktop.org
Cc: intel-gvt-...@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org
---
drivers/gpu/drm/i915/Kconfig |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff -- a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -118,9 +118,6 @@ config DRM_I915_USERPTR
If in doubt, say "Y".
-config DRM_I915_GVT
- bool
-
config DRM_I915_GVT_KVMGT
tristate "Enable KVM host support Intel GVT-g graphics virtualization"
depends on DRM_I915
@@ -172,3 +169,6 @@ menu "drm/i915 Unstable Evolution"
depends on DRM_I915
source "drivers/gpu/drm/i915/Kconfig.unstable"
endmenu
+
+config DRM_I915_GVT
+ bool
Re: [Intel-gfx] [PATCH 0/9] drm/i915: Replace kmap_atomic() with kmap_local_page()
Zhao Liu wrote: > From: Zhao Liu > > The use of kmap_atomic() is being deprecated in favor of > kmap_local_page()[1]. Zhao, Was there ever a v2 of this series? I'm not finding it on Lore. Thanks, Ira > > In the following patches, we can convert the calls of kmap_atomic() / > kunmap_atomic() to kmap_local_page() / kunmap_local(), which can > instead do the mapping / unmapping regardless of the context. > > With kmap_local_page(), the mapping is per thread, CPU local and not > globally visible. > > [1]: https://lore.kernel.org/all/20220813220034.806698-1-ira.we...@intel.com > --- > Zhao Liu (9): > drm/i915: Use kmap_local_page() in gem/i915_gem_object.c > drm/i915: Use kmap_local_page() in gem/i915_gem_pyhs.c > drm/i915: Use kmap_local_page() in gem/i915_gem_shmem.c > drm/i915: Use kmap_local_page() in gem/selftests/huge_pages.c > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_coherency.c > drm/i915: Use kmap_local_page() in gem/selftests/i915_gem_context.c > drm/i915: Use memcpy_from_page() in gt/uc/intel_uc_fw.c > drm/i915: Use kmap_local_page() in i915_cmd_parser.c > drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c > > drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 10 +- > drivers/gpu/drm/i915/gem/i915_gem_object.c | 8 +++- > drivers/gpu/drm/i915/gem/i915_gem_phys.c | 8 > drivers/gpu/drm/i915/gem/i915_gem_shmem.c| 6 -- > drivers/gpu/drm/i915/gem/selftests/huge_pages.c | 6 +++--- > .../gpu/drm/i915/gem/selftests/i915_gem_coherency.c | 12 > .../gpu/drm/i915/gem/selftests/i915_gem_context.c| 8 > drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 5 + > drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- > 9 files changed, 30 insertions(+), 37 deletions(-) > > -- > 2.34.1 >
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable YCbCr420 for VDSC (rev4)
== Series Details ==
Series: Enable YCbCr420 for VDSC (rev4)
URL : https://patchwork.freedesktop.org/series/113729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12739 -> Patchwork_113729v4
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v4/index.html
Participating hosts (39 -> 37)
--
Additional (1): bat-rpls-2
Missing(3): fi-kbl-soraka fi-blb-e6850 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113729v4:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-rpls-1}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v4/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_113729v4 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [PASS][2] -> [ABORT][3] ([i915#7911])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v4/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][4] ([i915#5334]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v4/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [ABORT][6] ([i915#4983]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/bat-rpls-1/igt@i915_selftest@l...@reset.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v4/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6621]: https://gitlab.freedesktop.org/drm/intel/issues/6621
[i915#7456]: https://gitlab.freedesktop.org/drm/intel/issues/7456
[i915#7561]: https://gitlab.freedesktop.org/drm/intel/issues/7561
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12739 -> Patchwork_113729v4
CI-20190529: 20190529
CI_DRM_12739: 5fc904286af94038fbf2c7cda50ed871b70cf4e8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7160: 45da871dd2684227e93a2fc002b87dfc58bd5fd9 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_113729v4: 5fc904286af94038fbf2c7cda50ed871b70cf4e8 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
4cf9e7dff922 drm/i915/dsc: Add debugfs entry to validate DSC output formats
05c6ec9e5ff4 drm/i915/vdsc: Check slice design requirement
5eaadf0006f8 drm/i915: Fill in native_420 field
16c71a0f64d5 drm/i915: Enable YCbCr420 for VDSC
a5bccef5d67d drm/i915: Adding the new registers for DSC
0b9daac93e28 drm/i915/dp: Check if DSC supports the given output_format
6aa69e525d67 drm/dp_helper: Add helper to check if the sink supports given
format with DSC
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v4/index.html
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enable YCbCr420 for VDSC (rev4)
== Series Details ==
Series: Enable YCbCr420 for VDSC (rev4)
URL : https://patchwork.freedesktop.org/series/113729/
State : warning
== Summary ==
Error: dim checkpatch failed
6cdd40baf8cf drm/dp_helper: Add helper to check if the sink supports given
format with DSC
04c83ea19cea drm/i915/dp: Check if DSC supports the given output_format
80ca3b9cb354 drm/i915: Adding the new registers for DSC
bc52e4f42491 drm/i915: Enable YCbCr420 for VDSC
-:199: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_row' - possible
side-effects?
#199: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420) do { \
+ if (bpc == (_bpc)) {\
+ if (_is_420)\
+ return
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+ else\
+ return
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+ } \
} while (0)
-:199: CHECK:MACRO_ARG_REUSE: Macro argument reuse '_col' - possible
side-effects?
#199: FILE: drivers/gpu/drm/i915/display/intel_qp_tables.c:447:
+#define PARAM_TABLE(_minmax, _bpc, _row, _col, _is_420) do { \
+ if (bpc == (_bpc)) {\
+ if (_is_420)\
+ return
rc_range_##_minmax##qp420_##_bpc##bpc[_row][_col]; \
+ else\
+ return
rc_range_##_minmax##qp444_##_bpc##bpc[_row][_col]; \
+ } \
} while (0)
total: 0 errors, 0 warnings, 2 checks, 228 lines checked
6b12844735fd drm/i915: Fill in native_420 field
e3abb5a999a6 drm/i915/vdsc: Check slice design requirement
ce3c95890351 drm/i915/dsc: Add debugfs entry to validate DSC output formats
-:114: WARNING:LONG_LINE: line length of 102 exceeds 100 columns
#114: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:1909:
+ seq_printf(m, "DSC_Output_Format: %s\n",
intel_output_format_name(crtc_state->output_format));
total: 0 errors, 1 warnings, 0 checks, 151 lines checked
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/dg2: Fix platforms without display (rev2)
== Series Details ==
Series: drm/i915/dg2: Fix platforms without display (rev2)
URL : https://patchwork.freedesktop.org/series/113782/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12738_full -> Patchwork_113782v2_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/index.html
Participating hosts (9 -> 10)
--
Additional (1): shard-rkl0
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_113782v2_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_softpin@evict-prime@vecs0:
- {shard-tglu}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-tglu-4/igt@gem_softpin@evict-pr...@vecs0.html
Known issues
Here are the changes found in Patchwork_113782v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-apl: NOTRUN -> [SKIP][2] ([fdo#109271]) +3 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-apl7/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#2346])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-apl2/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-apl4/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt:
- shard-glk: NOTRUN -> [SKIP][5] ([fdo#109271]) +4 similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-glk8/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt.html
*
igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271]) +24 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-snb1/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][7] ([i915#7742]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-4/igt@drm_fdinfo@i...@rcs0.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-rkl-4/igt@drm_fdinfo@i...@rcs0.html
* igt@drm_read@short-buffer-wakeup:
- {shard-rkl}:[SKIP][9] ([i915#4098]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-3/igt@drm_r...@short-buffer-wakeup.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-rkl-6/igt@drm_r...@short-buffer-wakeup.html
* igt@fbdev@pan:
- {shard-rkl}:[SKIP][11] ([i915#2582]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-2/igt@fb...@pan.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-rkl-6/igt@fb...@pan.html
* igt@gem_bad_reloc@negative-reloc-lut:
- {shard-rkl}:[SKIP][13] ([i915#3281]) -> [PASS][14] +13 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-2/igt@gem_bad_re...@negative-reloc-lut.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-rkl-5/igt@gem_bad_re...@negative-reloc-lut.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][15] ([i915#6252]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-rkl-4/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_fair@basic-deadline:
- {shard-rkl}:[FAIL][17] ([i915#2846]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-3/igt@gem_exec_f...@basic-deadline.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-rkl-2/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-none-solo@rcs0:
- {shard-rkl}:[FAIL][19] ([i915#2842]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-3/igt@gem_exec_fair@basic-none-s...@rcs0.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/shard-rkl-5/igt@gem_exec_fair@basic-none-s...@rcs0.html
*
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Make backlight setup debugs consistent
== Series Details ==
Series: series starting with [1/3] drm/i915: Make backlight setup debugs
consistent
URL : https://patchwork.freedesktop.org/series/114012/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12738_full -> Patchwork_114012v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/index.html
Participating hosts (9 -> 9)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_114012v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-apl: NOTRUN -> [SKIP][1] ([fdo#109271]) +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-apl7/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt:
- shard-glk: NOTRUN -> [SKIP][2] ([fdo#109271]) +4 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-glk8/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt.html
*
igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][3] ([fdo#109271]) +16 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-snb1/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][4] ([i915#7742]) -> [PASS][5] +1 similar issue
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-rkl-6/igt@drm_fdi...@virtual-idle.html
* igt@fbdev@pan:
- {shard-rkl}:[SKIP][6] ([i915#2582]) -> [PASS][7] +1 similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-2/igt@fb...@pan.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-rkl-6/igt@fb...@pan.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][8] ([i915#6252]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-rkl-1/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][10] ([i915#2842]) -> [PASS][11] +2 similar
issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-1/igt@gem_exec_fair@basic-n...@vcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-rkl-5/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [FAIL][12] ([i915#2842]) -> [PASS][13] +1 similar
issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-apl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_reloc@basic-gtt-read:
- {shard-rkl}:[SKIP][14] ([i915#3281]) -> [PASS][15] +9 similar
issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-3/igt@gem_exec_re...@basic-gtt-read.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-rkl-5/igt@gem_exec_re...@basic-gtt-read.html
* igt@gem_userptr_blits@forbidden-operations:
- {shard-rkl}:[SKIP][16] ([i915#3282]) -> [PASS][17] +2 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-1/igt@gem_userptr_bl...@forbidden-operations.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-rkl-5/igt@gem_userptr_bl...@forbidden-operations.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [ABORT][18] ([i915#5566]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-apl3/igt@gen9_exec_pa...@allowed-single.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
* igt@gen9_exec_parse@bb-chained:
- {shard-rkl}:[SKIP][20] ([i915#2527]) -> [PASS][21] +3 similar
issues
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-1/igt@gen9_exec_pa...@bb-chained.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/shard-rkl-5/igt@gen9_exec_pa...@bb-chained.html
* igt@i915_hangman@gt-engine-error@bcs0:
- {shard-rkl}:[SKIP][22] ([i915#6258]) -> [PASS][23]
[22]:
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL
== Series Details ==
Series: series starting with [1/3] drm/i915: Don't switch to TPS1 when
disabling DP_TP_CTL
URL : https://patchwork.freedesktop.org/series/114011/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12738_full -> Patchwork_114011v1_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/index.html
Participating hosts (9 -> 10)
--
Additional (1): shard-rkl0
Known issues
Here are the changes found in Patchwork_114011v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][1] -> [ABORT][2] ([i915#5566])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-glk9/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-apl: NOTRUN -> [SKIP][3] ([fdo#109271]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-apl1/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions-varying-size:
- shard-apl: [PASS][4] -> [FAIL][5] ([i915#2346])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-apl2/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-apl7/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions-varying-size.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271]) +4 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-glk1/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt.html
*
igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271]) +16 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-snb1/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@idle@rcs0:
- {shard-rkl}:[FAIL][8] ([i915#7742]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-4/igt@drm_fdinfo@i...@rcs0.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-rkl-5/igt@drm_fdinfo@i...@rcs0.html
* igt@drm_read@short-buffer-block:
- {shard-rkl}:[SKIP][10] ([i915#4098]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-3/igt@drm_r...@short-buffer-block.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-rkl-6/igt@drm_r...@short-buffer-block.html
* igt@fbdev@info:
- {shard-rkl}:[SKIP][12] ([i915#2582]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-1/igt@fb...@info.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-rkl-6/igt@fb...@info.html
* igt@fbdev@unaligned-read:
- {shard-tglu}: [SKIP][14] ([i915#2582]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-tglu-6/igt@fb...@unaligned-read.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-tglu-8/igt@fb...@unaligned-read.html
* igt@feature_discovery@psr2:
- {shard-rkl}:[SKIP][16] ([i915#658]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-2/igt@feature_discov...@psr2.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-rkl-6/igt@feature_discov...@psr2.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][18] ([i915#6252]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-rkl-4/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [FAIL][20] ([i915#2842]) -> [PASS][21] +1 similar
issue
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/shard-apl2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_fair@basic-throttle@rcs0:
- shard-glk: [FAIL][22] ([i915#2842]) -> [PASS][23] +1 similar
issue
[22]:
[Intel-gfx] [PATCH v10 5/7] drm/i915: Fill in native_420 field
Now that we have laid the groundwork for YUV420 Enablement
we fill up native_420 field in vdsc_cfg and add appropriate
checks wherever required.
---v2
-adding native_422 field as 0 [Vandita]
-filling in second_line_bpg_offset, second_line_offset_adj
and nsl_bpg_offset in vds_cfg when native_420 is true
---v3
-adding display version check to solve igt issue
--v7
-remove is_pipe_dsc check as its always true for D14 [Jani]
--v10
-keep sink capability check [Jani]
-move from !(x == y || w == z) to x !=y && w != z [Jani]
Cc: Jani Nikula
Signed-off-by: Suraj Kandpal
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 05e749861658..7065203460d3 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1534,8 +1534,6 @@ static int gen11_dsi_dsc_compute_config(struct
intel_encoder *encoder,
if (crtc_state->dsc.slice_count > 1)
crtc_state->dsc.dsc_split = true;
- vdsc_cfg->convert_rgb = true;
-
/* FIXME: initialize from VBT */
vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 1a397ab710dd..baa5af7d3bdc 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1466,9 +1466,10 @@ static int intel_dp_dsc_compute_params(struct
intel_encoder *encoder,
vdsc_cfg->dsc_version_minor =
min(intel_dp_source_dsc_version_minor(intel_dp),
intel_dp_sink_dsc_version_minor(intel_dp));
-
- vdsc_cfg->convert_rgb = intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP
- DP_DSC_SUPPORT] &
- DP_DSC_RGB;
+ if (vdsc_cfg->convert_rgb)
+ vdsc_cfg->convert_rgb =
+ intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP -
DP_DSC_SUPPORT] &
+ DP_DSC_RGB;
line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp->dsc_dpcd);
if (!line_buf_depth) {
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index ed16f63d6355..19f9fb53f139 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -460,14 +460,47 @@ int intel_dsc_compute_params(struct intel_crtc_state
*pipe_config)
vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
pipe_config->dsc.slice_count);
-
- /* Gen 11 does not support YCbCr */
+ /*
+* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
is 0
+* else 1
+*/
+ vdsc_cfg->convert_rgb = pipe_config->output_format !=
INTEL_OUTPUT_FORMAT_YCBCR420 &&
+ pipe_config->output_format !=
INTEL_OUTPUT_FORMAT_YCBCR444;
+
+ if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
+ vdsc_cfg->native_420 = true;
+ /* We do not support YcBCr422 as of now */
+ vdsc_cfg->native_422 = false;
+ /* Gen 11 does not support YCbCr422 */
vdsc_cfg->simple_422 = false;
/* Gen 11 does not support VBR */
vdsc_cfg->vbr_enable = false;
/* Gen 11 only supports integral values of bpp */
vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
+ /*
+* According to DSC 1.2 specs if native_420 is set:
+* -We need to double the current bpp.
+* -second_line_bpg_offset is 12 in general and equal to
2*(slice_height-1) if slice
+* height < 8.
+* -second_line_offset_adj is 512 as shown by emperical values to yeild
best chroma
+* preservation in second line.
+* -nsl_bpg_offset is calculated as second_line_offset/slice_height -1
then rounded
+* up to 16 fractional bits, we left shift second line offset by 11 to
preserve 11
+* fractional bits.
+*/
+ if (vdsc_cfg->native_420) {
+ vdsc_cfg->bits_per_pixel <<= 1;
+ if (vdsc_cfg->slice_height >= 8)
+ vdsc_cfg->second_line_bpg_offset = 12;
+ else
+ vdsc_cfg->second_line_bpg_offset =
+ 2 * (vdsc_cfg->slice_height - 1);
+ vdsc_cfg->second_line_offset_adj = 512;
+ vdsc_cfg->nsl_bpg_offset =
DIV_ROUND_UP(vdsc_cfg->second_line_bpg_offset << 11,
+ vdsc_cfg->slice_height
- 1);
+ }
+
vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
@@ -594,8 +627,13 @@ static void intel_dsc_pps_configure(const struct
intel_crtc_state *crtc_state)
DSC_VER_MIN_SHIFT |
vdsc_cfg->bits_per_component << DSC_BPC_SHIFT |
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable YCbCr420 for VDSC (rev3)
== Series Details ==
Series: Enable YCbCr420 for VDSC (rev3)
URL : https://patchwork.freedesktop.org/series/113729/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12738_full -> Patchwork_113729v3_full
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/index.html
Participating hosts (9 -> 9)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_113729v3_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [PASS][1] -> [ABORT][2] ([i915#5566])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-glk5/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_big_fb@x-tiled-max-hw-stride-32bpp-rotate-0-hflip:
- shard-apl: NOTRUN -> [SKIP][3] ([fdo#109271]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-apl7/igt@kms_big...@x-tiled-max-hw-stride-32bpp-rotate-0-hflip.html
* igt@kms_flip@flip-vs-expired-vblank@b-hdmi-a2:
- shard-glk: [PASS][4] -> [FAIL][5] ([i915#79])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-glk6/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-glk9/igt@kms_flip@flip-vs-expired-vbl...@b-hdmi-a2.html
* igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271]) +4 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-glk9/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt.html
*
igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-0-5@pipe-a-hdmi-a-1:
- shard-snb: NOTRUN -> [SKIP][7] ([fdo#109271]) +16 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-snb1/igt@kms_plane_scaling@planes-upscale-factor-0-25-downscale-factor-...@pipe-a-hdmi-a-1.html
Possible fixes
* igt@drm_fdinfo@virtual-idle:
- {shard-rkl}:[FAIL][8] ([i915#7742]) -> [PASS][9] +1 similar issue
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-2/igt@drm_fdi...@virtual-idle.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-rkl-4/igt@drm_fdi...@virtual-idle.html
* igt@gem_ctx_persistence@engines-hang@bcs0:
- {shard-rkl}:[SKIP][10] ([i915#6252]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-5/igt@gem_ctx_persistence@engines-h...@bcs0.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-rkl-3/igt@gem_ctx_persistence@engines-h...@bcs0.html
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [FAIL][12] ([i915#2842]) -> [PASS][13] +1 similar
issue
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-glk2/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-apl: [FAIL][14] ([i915#2842]) -> [PASS][15] +1 similar
issue
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-apl7/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-apl3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_exec_reloc@basic-write-read-noreloc:
- {shard-rkl}:[SKIP][16] ([i915#3281]) -> [PASS][17] +8 similar
issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-2/igt@gem_exec_re...@basic-write-read-noreloc.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-rkl-5/igt@gem_exec_re...@basic-write-read-noreloc.html
* igt@gem_partial_pwrite_pread@writes-after-reads-uncached:
- {shard-rkl}:[SKIP][18] ([i915#3282]) -> [PASS][19] +4 similar
issues
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-rkl-4/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-rkl-5/igt@gem_partial_pwrite_pr...@writes-after-reads-uncached.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [ABORT][20] ([i915#5566]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/shard-apl3/igt@gen9_exec_pa...@allowed-single.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
*
Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Expose power1_max_enable
On Mon, 13 Feb 2023 22:16:44 -0800, Guenter Roeck wrote:
>
Hi Guenter,
> On 2/13/23 21:33, Ashutosh Dixit wrote:
> > On ATSM the PL1 power limit is disabled at power up. The previous uapi
> > assumed that the PL1 limit is always enabled and therefore did not have a
> > notion of a disabled PL1 limit. This results in erroneous PL1 limit values
> > when PL1 limit is disabled. For example at power up, the disabled ATSM PL1
> > limit is shown as 0 which means a low PL1 limit whereas the limit being
> > disabled actually implies a high effective PL1 limit value.
> >
> > To get round this problem, expose power1_max_enable as a custom hwmon
> > attribute. power1_max_enable can be used in conjunction with power1_max to
> > interpret power1_max (PL1 limit) values correctly. It can also be used to
> > enable/disable the PL1 power limit.
> >
> > Signed-off-by: Ashutosh Dixit
> > ---
> > .../ABI/testing/sysfs-driver-intel-i915-hwmon | 7 +++
> > drivers/gpu/drm/i915/i915_hwmon.c | 48 +--
> > 2 files changed, 51 insertions(+), 4 deletions(-)
> >
> > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > index 2d6a472eef885..edd94a44b4570 100644
> > --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > @@ -18,6 +18,13 @@ Description: RW. Card reactive sustained (PL1/Tau)
> > power limit in microwatts.
> > Only supported for particular Intel i915 graphics
> > platforms.
> > +What:/sys/devices/.../hwmon/hwmon/power1_max_enable
>
> This is not a standard hwmon attribute. The standard attribute would be
> power1_enable.
>
> So from hwmon perspective this is a NACK.
Thanks for the feedback. I did consider power1_enable but decided to go
with the power1_max_enable custom attribute. Documentation for
power1_enable says it is to "Enable or disable the sensors" but in our case
we are not enabling/disabling sensors (which we don't have any ability to,
neither do we expose any power measurements, only energy from which power
can be derived) but enabling/disabling a "power limit" (a limit beyond
which HW takes steps to limit power).
As mentioned in the commit message, power1_max_enable is exposed to avoid
possible misinterpretations in measured energy in response to the set power
limit (something specific to our HW). We may have multiple such limits in
the future with similar issues and multiplexing enabling/disabling these
power limits via a single power1_enable file will not provide sufficient
granularity for our purposes.
Also, I had previously posted this patch:
https://patchwork.freedesktop.org/patch/522612/?series=113972=1
which avoids the power1_max_enable file and instead uses a power1_max value
of -1 to indicate that the power1_max limit is disabled.
So in summary we have the following options:
1. Go with power1_max_enable (preferred, works well for us)
2. Go with -1 to indicate that the power1_max limit is disabled
(non-intuitive and also a little ugly)
3. Go with power1_enable (possible but confusing because multiple power
limits/entities are multiplexed via a single file)
If you still think we should not use power1_max_enable I think I might drop
this patch for now (I am trying to preempt future issues but in this case
it's better to wait till people actually complain rather than expose a
non-ideal uapi).
Even if drop we this patch now, it would be good to know your preference in
case we need to revisit this issue later.
Thanks and also sorry for the rather long winded email.
Ashutosh
> Guenter
>
> > +Date: May 2023
> > +KernelVersion: 6.3
> > +Contact: intel-gfx@lists.freedesktop.org
> > +Description: RW. Enable/disable the PL1 power limit (power1_max).
> > +
> > + Only supported for particular Intel i915 graphics platforms.
> > What: /sys/devices/.../hwmon/hwmon/power1_rated_max
> > Date: February 2023
> > KernelVersion:6.2
> > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> > b/drivers/gpu/drm/i915/i915_hwmon.c
> > index 7c20a6f47b92e..5665869d8602b 100644
> > --- a/drivers/gpu/drm/i915/i915_hwmon.c
> > +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> > @@ -230,13 +230,52 @@ hwm_power1_max_interval_store(struct device *dev,
> > PKG_PWR_LIM_1_TIME, rxy);
> > return count;
> > }
> > +static SENSOR_DEVICE_ATTR_RW(power1_max_interval, hwm_power1_max_interval,
> > 0);
> > -static SENSOR_DEVICE_ATTR(power1_max_interval, 0664,
> > - hwm_power1_max_interval_show,
> > - hwm_power1_max_interval_store, 0);
> > +static ssize_t
> > +hwm_power1_max_enable_show(struct device *dev, struct device_attribute
> > *attr, char *buf)
> > +{
> > + struct hwm_drvdata *ddat = dev_get_drvdata(dev);
> > + intel_wakeref_t wakeref;
> > +
Re: [Intel-gfx] [PATCH v9 5/7] drm/i915: Fill in native_420 field
> On Tue, 07 Feb 2023, Suraj Kandpal wrote:
> > Now that we have laid the groundwork for YUV420 Enablement we fill up
> > native_420 field in vdsc_cfg and add appropriate checks wherever
> > required.
> >
> > ---v2
> > -adding native_422 field as 0 [Vandita] -filling in
> > second_line_bpg_offset, second_line_offset_adj and nsl_bpg_offset in
> > vds_cfg when native_420 is true
> >
> > ---v3
> > -adding display version check to solve igt issue
> >
> > --v7
> > -remove is_pipe_dsc check as its always true for D14 [Jani]
> >
> > Signed-off-by: Suraj Kandpal
> > ---
> > drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
> > drivers/gpu/drm/i915/display/intel_dp.c | 3 -
> > drivers/gpu/drm/i915/display/intel_vdsc.c | 72
> > ++-
> > 3 files changed, 69 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index 003cac918228..f8c999fa3242 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -1534,8 +1534,6 @@ static int gen11_dsi_dsc_compute_config(struct
> intel_encoder *encoder,
> > if (crtc_state->dsc.slice_count > 1)
> > crtc_state->dsc.dsc_split = true;
> >
> > - vdsc_cfg->convert_rgb = true;
> > -
> > /* FIXME: initialize from VBT */
> > vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> > b/drivers/gpu/drm/i915/display/intel_dp.c
> > index 73a7baccd7d0..250d9cdd14b8 100644
> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> > @@ -1470,9 +1470,6 @@ static int intel_dp_dsc_compute_params(struct
> intel_encoder *encoder,
> > min(intel_dp_source_dsc_version_minor(intel_dp),
> > intel_dp_sink_dsc_version_minor(intel_dp));
> >
> > - vdsc_cfg->convert_rgb = intel_dp-
> >dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP - DP_DSC_SUPPORT] &
> > - DP_DSC_RGB;
>
> Are the sink caps taken into account somewhere else?
Looking at it again I should move it after intel_dsc_compute_params and check
sink capability
If convert_rgb is set as true there
>
> > -
> > line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp-
> >dsc_dpcd);
> > if (!line_buf_depth) {
> > drm_dbg_kms(>drm,
> > diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > index ed16f63d6355..13ad853e24eb 100644
> > --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> > +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> > @@ -460,14 +460,47 @@ int intel_dsc_compute_params(struct
> intel_crtc_state *pipe_config)
> > vdsc_cfg->pic_width = pipe_config-
> >hw.adjusted_mode.crtc_hdisplay;
> > vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
> > pipe_config->dsc.slice_count);
> > -
> > - /* Gen 11 does not support YCbCr */
> > + /*
> > +* According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
> is 0
> > +* else 1
> > +*/
> > + vdsc_cfg->convert_rgb = !(pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420 ||
> > + pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR444);
>
> Nitpick, IMO "format != x && format != y" reads better than "!(format == x ||
> format == y)"
>
Sure will change this in the next revision
Regards,
Suraj Kandpal
> > +
> > + if (pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420)
> > + vdsc_cfg->native_420 = true;
> > + /* We do not support YcBCr422 as of now */
> > + vdsc_cfg->native_422 = false;
> > + /* Gen 11 does not support YCbCr422 */
> > vdsc_cfg->simple_422 = false;
> > /* Gen 11 does not support VBR */
> > vdsc_cfg->vbr_enable = false;
> >
> > /* Gen 11 only supports integral values of bpp */
> > vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
> > + /*
> > +* According to DSC 1.2 specs if native_420 is set:
> > +* -We need to double the current bpp.
> > +* -second_line_bpg_offset is 12 in general and equal to
> 2*(slice_height-1) if slice
> > +* height < 8.
> > +* -second_line_offset_adj is 512 as shown by emperical values to
> yeild best chroma
> > +* preservation in second line.
> > +* -nsl_bpg_offset is calculated as second_line_offset/slice_height -1
> then rounded
> > +* up to 16 fractional bits, we left shift second line offset by 11 to
> preserve 11
> > +* fractional bits.
> > +*/
> > + if (vdsc_cfg->native_420) {
> > + vdsc_cfg->bits_per_pixel <<= 1;
> > + if (vdsc_cfg->slice_height >= 8)
> > + vdsc_cfg->second_line_bpg_offset = 12;
> > + else
> > + vdsc_cfg->second_line_bpg_offset =
> > + 2 * (vdsc_cfg->slice_height - 1);
> > + vdsc_cfg->second_line_offset_adj = 512;
> > +
[Intel-gfx] ✗ Fi.CI.BAT: failure for Add OAM support for MTL
== Series Details ==
Series: Add OAM support for MTL
URL : https://patchwork.freedesktop.org/series/114033/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12739 -> Patchwork_114033v1
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_114033v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_114033v1, 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_114033v1/index.html
Participating hosts (39 -> 39)
--
Additional (1): bat-rpls-2
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114033v1:
### IGT changes ###
Possible regressions
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-cfl-8109u: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114033v1/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-rpls-1}: NOTRUN -> [ABORT][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114033v1/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_114033v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-kbl-soraka: [PASS][4] -> [INCOMPLETE][5] ([i915#7913])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114033v1/fi-kbl-soraka/igt@i915_selftest@l...@hangcheck.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][6] -> [FAIL][7] ([i915#6298])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114033v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][8] ([i915#7229]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114033v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [DMESG-FAIL][10] ([i915#5334] / [i915#7872]) ->
[PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114033v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
- fi-apl-guc: [DMESG-FAIL][12] ([i915#5334]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114033v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [ABORT][14] ([i915#4983]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/bat-rpls-1/igt@i915_selftest@l...@reset.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114033v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109295]: https://bugs.freedesktop.org/show_bug.cgi?id=109295
[i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072
[i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845
[i915#1849]: https://gitlab.freedesktop.org/drm/intel/issues/1849
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#3282]: https://gitlab.freedesktop.org/drm/intel/issues/3282
[i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555
[i915#3637]: https://gitlab.freedesktop.org/drm/intel/issues/3637
[i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708
[i915#4258]: https://gitlab.freedesktop.org/drm/intel/issues/4258
[i915#4613]:
Re: [Intel-gfx] [PATCH v3 14/15] vfio: Add ioctls for device cdev using iommufd
> From: Zhao, Yan Y
> Sent: Wednesday, February 15, 2023 7:39 AM
>
> On Mon, Feb 13, 2023 at 07:13:47AM -0800, Yi Liu wrote:
> ...
> > +long vfio_device_ioctl_bind_iommufd(struct vfio_device_file *df,
> > + unsigned long arg)
> > +{
> > + struct vfio_device *device = df->device;
> > + struct vfio_device_bind_iommufd bind;
> > + struct iommufd_ctx *iommufd = NULL;
> > + struct fd f;
> > + 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_claim_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 {
> > + f = fdget(bind.iommufd);
> > + if (!f.file) {
> > + ret = -EBADF;
> > + goto out_unlock;
> > + }
> > + iommufd = iommufd_ctx_from_file(f.file);
> > + if (IS_ERR(iommufd)) {
> > + ret = PTR_ERR(iommufd);
> > + goto out_put_file;
> > + }
> > + }
> > +
> > + /*
> > +* 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),
> > + _devid,
> > + sizeof(bind.out_devid)) ? -EFAULT : 0;
> > + if (ret)
> > + goto out_close_device;
> > +
> > + if (iommufd)
> > + fdput(f);
> > + else if (df->noiommu)
> > + dev_warn(device->dev, "vfio-noiommu device used by user "
> > +"(%s:%d)\n", current->comm, task_pid_nr(current));
>
> IMHO, the "smp_store_release(>access_granted, true);" in patch 7
> should be moved to here when bind is indeed successful.
>
yes. in that case patch7 should put release in vfio_device_group_open()
and then add a new release here.
Re: [Intel-gfx] [PATCH] drm/i915: Don't use stolen memory for ring buffers
On 2/14/2023 3:48 PM, john.c.harri...@intel.com wrote: From: John Harrison Direction from hardware is that stolen memory should never be used for ring buffer allocations. There are too many caching pitfalls due to the way stolen memory accesses are routed. So it is safest to just not use it. I'm wondering if this applies to machines in ringbuffer mode as well, as some of the caching stuff that according to the HW team may not work properly with stolen mem accesses from the CS (mocs, ppat) came with gen8/gen9. Maybe limit this change to gen8+, to avoid changing the behavior for very old platforms? Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/intel_ring.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c index 15ec64d881c44..d1a47e1ae6452 100644 --- a/drivers/gpu/drm/i915/gt/intel_ring.c +++ b/drivers/gpu/drm/i915/gt/intel_ring.c @@ -116,8 +116,6 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size) obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE | I915_BO_ALLOC_PM_VOLATILE); - if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt)) - obj = i915_gem_object_create_stolen(i915, size); There is code in ring_pin/unpin() that only applies to rings in stolen memory, so you need to remove that as well if you drop stolen for rings on all platforms. Daniele if (IS_ERR(obj)) obj = i915_gem_object_create_internal(i915, size); if (IS_ERR(obj))
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add OAM support for MTL
== Series Details == Series: Add OAM support for MTL URL : https://patchwork.freedesktop.org/series/114033/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] [PATCH 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.
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
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 | 247 ---
drivers/gpu/drm/i915/i915_perf_oa_regs.h | 78 +++
drivers/gpu/drm/i915/i915_perf_types.h | 40
drivers/gpu/drm/i915/intel_device_info.h | 1 +
include/uapi/drm/i915_drm.h | 4 +
7 files changed, 347 insertions(+), 26 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 8f7306eaf43c..9fce3ea6a7dc 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,13 @@ 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 },
+};
+
+/* PERF_GROUP_OAG is unused for oa_base, drop it for mtl */
+static const u32 mtl_oa_base[] = {
+ [PERF_GROUP_OAM_SAMEDIA_0] = 0x393000,
};
#define SAMPLE_OA_REPORT (1<<0)
@@ -418,11 +426,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 >oa_buffer.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;
}
@@ -886,7 +900,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);
@@ -939,7 +954,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);
@@ -1643,6 +1659,18 @@ free_noa_wait(struct i915_perf_stream *stream)
i915_vma_unpin_and_release(>noa_wait, 0);
}
+/*
+ * intel_engine_lookup_user ensures that most of engine specific checks are
+ * taken care of, however, we can run into a case where the OA unit catering to
+ * the engine passed by the user is disabled for some reason. In such cases,
+ * ensure oa unit corresponding to an engine is functional. If there are no
+ * engines in the group, the unit is disabled.
+ */
+static bool oa_unit_functional(const struct intel_engine_cs *engine)
+{
+ return engine->oa_group && engine->oa_group->num_engines;
[Intel-gfx] [PATCH 2/9] drm/i915/perf: Add helper to check supported OA engines
Add helper to check for supported OA engines.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 19 ---
1 file changed, 16 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 393a0da8b7c8..a879ae4bf8d7 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1570,6 +1570,19 @@ 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;
+
+ if (intel_engine_is_virtual(engine))
+ return false;
+
+ 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 +2518,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 +2669,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 +3382,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 8/9] drm/i915/perf: Add engine class instance parameters to perf
Current implementation of perf defaults to render to and configures the
default OAG unit. Since there are more OA units on newer hardware, allow
user to pass engine class and instance to 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
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 49 +++-
include/uapi/drm/i915_drm.h | 20 +
2 files changed, 49 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2e1b305032c0..8f7306eaf43c 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4038,40 +4038,29 @@ static int read_properties_unlocked(struct i915_perf
*perf,
u64 __user *uprop = uprops;
u32 i;
int ret;
+ u8 class, instance;
bool config_sseu = false;
struct drm_i915_gem_context_param_sseu user_sseu;
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;
- }
-
/* 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 no. 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;
@@ -4192,7 +4181,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;
}
@@ -4200,6 +4195,17 @@ 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))
+ return -EINVAL;
+
if (config_sseu) {
ret = get_sseu_config(>sseu, props->engine, _sseu);
if (ret) {
@@ -5210,8 +5216,11 @@ int i915_perf_ioctl_version(void)
*
* 5: Add DRM_I915_PERF_PROP_POLL_OA_PERIOD parameter that controls the
*interval for the hrtimer used to check for OA data.
+*
+* 6: Add DRM_I915_PERF_PROP_OA_ENGINE_CLASS and
+*DRM_I915_PERF_PROP_OA_ENGINE_INSTANCE
*/
- return 5;
+ return 6;
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 8df261c5ab9b..b6922b52d85c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2758,6 +2758,26 @@ enum drm_i915_perf_property_id {
*/
DRM_I915_PERF_PROP_POLL_OA_PERIOD,
+ /**
+* In platforms with multiple OA
[Intel-gfx] [PATCH 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,
hw_tail is adjusted accordingly when checking for new reports.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 50 ++--
1 file changed, 28 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 030f3a598229..2e1b305032c0 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -542,6 +542,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
@@ -551,10 +552,16 @@ 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, whereas report
+* sizes need not be integral multiples or 64 or powers 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 + ((hw_tail - partial_report_size) &
+ (stream->oa_buffer.vma->size - 1));
now = ktime_get_mono_fast_ns();
@@ -677,6 +684,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;
@@ -690,8 +699,21 @@ 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 +
+stream->oa_buffer.vma->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;
@@ -759,8 +781,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* all a power of two).
*/
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;
@@ -774,22 +796,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 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.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 105 -
drivers/gpu/drm/i915/i915_perf_types.h | 6 ++
2 files changed, 92 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index fda779b2c16f..030f3a598229 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -441,6 +441,75 @@ 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 inline u64
+oa_report_id(struct i915_perf_stream *stream, void *report)
+{
+ return oa_report_header_64bit(stream) ? *(u64 *)report : *(u32 *)report;
+}
+
+static inline 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 inline 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 inline 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 inline u64
+oa_timestamp(struct i915_perf_stream *stream, void *report)
+{
+ return oa_report_header_64bit(stream) ?
+ *((u64 *)report + 1) :
+ *((u32 *)report + 1);
+}
+
+static inline 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 inline 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 inline 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
@@ -521,9 +590,10 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
* 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 +772,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;
+ u64 reason;
/*
* All the report sizes factor neatly into the buffer
@@ -725,16 +795,12 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* triggered this specific report (mostly timer
* triggered or e.g. due to a context switch).
*
-* This field is never expected to be zero so we can
-* check that the report isn't invalid before copying
-* it to userspace...
+* In MMIO triggered reports, some platforms do not set the
+* reason bit in this field and it is valid to have a reason
+* field of zero.
*/
- reason = ((report32[0] >> OAREPORT_REASON_SHIFT) &
- (GRAPHICS_VER(stream->perf->i915) == 12 ?
- OAREPORT_REASON_MASK_EXTENDED :
- OAREPORT_REASON_MASK));
-
- ctx_id = report32[2] & stream->specific_ctx_id_mask;
+ reason = oa_report_reason(stream, report);
+ ctx_id = oa_context_id(stream, report32);
[Intel-gfx] [PATCH 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. Signed-off-by: Umesh Nerlige Ramappa Test-with: 20230215004648.2100655-1-umesh.nerlige.rama...@intel.com Cc: "Ashutosh Dixit " Cc: "Lionel G Landwerlin " Cc: "Joonas Lahtinen " Cc: "Tvrtko Ursulin " 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: Fail modprobe if i915_perf_init fails drm/i915/perf: Group engines into respective OA groups 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 | 4 + 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 | 632 +++ 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 | 103 ++- drivers/gpu/drm/i915/intel_device_info.h | 1 + include/uapi/drm/i915_drm.h | 24 + 11 files changed, 735 insertions(+), 119 deletions(-) -- 2.36.1
[Intel-gfx] [PATCH 5/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.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/gt/intel_engine_types.h | 4 +
drivers/gpu/drm/i915/gt/intel_sseu.c | 3 +-
drivers/gpu/drm/i915/i915_perf.c | 126 +--
drivers/gpu/drm/i915/i915_perf_types.h | 51 +++-
4 files changed, 171 insertions(+), 13 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..8a8b0dce241b 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,8 @@ struct intel_engine_cs {
} props, defaults;
I915_SELFTEST_DECLARE(struct fault_attr reset_timeout);
+
+ 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 e134523576f8..fda779b2c16f 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1587,8 +1587,9 @@ 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;
/*
@@ -1597,7 +1598,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);
@@ -3195,6 +3196,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;
@@ -3205,6 +3207,12 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
}
gt = props->engine->gt;
+ g = props->engine->oa_group;
+ if (!g) {
+ DRM_DEBUG("Perf group invalid\n");
+ return -EINVAL;
+ }
+
/*
* If the sysfs metrics/ directory wasn't registered for some
* reason then don't let userspace try their luck with config
@@ -3234,7 +3242,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;
@@ -3329,7 +3337,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
stream->ops = _oa_stream_ops;
stream->engine->gt->perf.sseu = props->sseu;
- WRITE_ONCE(gt->perf.exclusive_stream, stream);
+ WRITE_ONCE(g->exclusive_stream, stream);
ret = i915_perf_stream_enable_sync(stream);
if (ret) {
@@ -3352,7 +3360,7 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
return 0;
err_enable:
- WRITE_ONCE(gt->perf.exclusive_stream, NULL);
+ WRITE_ONCE(g->exclusive_stream, NULL);
perf->ops.disable_metric_set(stream);
free_oa_buffer(stream);
@@ -3381,12 +3389,13 @@ void i915_oa_init_reg_state(const struct intel_context
*ce,
const struct intel_engine_cs *engine)
{
struct i915_perf_stream *stream;
+ struct i915_perf_group *g = engine->oa_group;
-
[Intel-gfx] [PATCH 3/9] drm/i915/perf: Validate OA sseu config outside switch
Validate the OA sseu config after all params are parsed.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_perf.c | 22 --
1 file changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index a879ae4bf8d7..0b2097ad000e 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3956,6 +3956,8 @@ static int read_properties_unlocked(struct i915_perf
*perf,
u64 __user *uprop = uprops;
u32 i;
int ret;
+ bool config_sseu = false;
+ struct drm_i915_gem_context_param_sseu user_sseu;
memset(props, 0, sizeof(struct perf_open_properties));
props->poll_oa_period = DEFAULT_POLL_PERIOD_NS;
@@ -4082,8 +4084,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",
@@ -4098,14 +4098,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:
@@ -4125,6 +4118,15 @@ 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_DEBUG("Invalid SSEU configuration\n");
+ return ret;
+ }
+ props->has_sseu = true;
+ }
+
return 0;
}
--
2.36.1
[Intel-gfx] [PATCH 4/9] drm/i915/perf: Fail modprobe if i915_perf_init fails
Check for return value from i915_perf_init and fail driver init if perf
init fails.
Signed-off-by: Umesh Nerlige Ramappa
---
drivers/gpu/drm/i915/i915_driver.c | 4 +++-
drivers/gpu/drm/i915/i915_perf.c | 4 +++-
drivers/gpu/drm/i915/i915_perf.h | 2 +-
3 files changed, 7 insertions(+), 3 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 0b2097ad000e..e134523576f8 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -4845,7 +4845,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;
@@ -4962,6 +4962,8 @@ void i915_perf_init(struct drm_i915_private *i915)
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 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.
Fixes: 01e742746785 ("drm/i915/guc: Support OA when Wa_16011777198 is enabled")
Signed-off-by: Chris Wilson
Cc: Vinay Belgaumkar
Cc: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_perf.c | 18 +++---
drivers/gpu/drm/i915/i915_perf_types.h | 6 ++
2 files changed, 17 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 824a34ec0b83..393a0da8b7c8 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,13 +3303,15 @@ 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_fw;
}
+
+ stream->override_gucrc = true;
}
ret = alloc_oa_buffer(stream);
if (ret)
- goto err_oa_buf_alloc;
+ goto err_gucrc;
stream->ops = _oa_stream_ops;
@@ -3344,12 +3344,16 @@ static int i915_oa_stream_init(struct i915_perf_stream
*stream,
free_oa_buffer(stream);
-err_oa_buf_alloc:
- free_oa_configs(stream);
+err_gucrc:
+ if (stream->override_gucrc)
+ intel_guc_slpc_unset_gucrc_mode(>uc.guc.slpc);
+err_fw:
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] ✓ Fi.CI.BAT: success for drm/i915: Don't use stolen memory for ring buffers
== Series Details ==
Series: drm/i915: Don't use stolen memory for ring buffers
URL : https://patchwork.freedesktop.org/series/114030/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12739 -> Patchwork_114030v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114030v1/index.html
Participating hosts (39 -> 37)
--
Missing(2): fi-tgl-1115g4 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114030v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-rpls-1}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114030v1/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_114030v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@execlists:
- fi-bsw-n3050: [PASS][2] -> [ABORT][3] ([i915#7911])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114030v1/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][4] -> [FAIL][5] ([i915#6298])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114030v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [DMESG-FAIL][6] ([i915#5334] / [i915#7872]) ->
[PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114030v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
- fi-apl-guc: [DMESG-FAIL][8] ([i915#5334]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114030v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [ABORT][10] ([i915#4983]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/bat-rpls-1/igt@i915_selftest@l...@reset.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114030v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
[i915#7911]: https://gitlab.freedesktop.org/drm/intel/issues/7911
Build changes
-
* Linux: CI_DRM_12739 -> Patchwork_114030v1
CI-20190529: 20190529
CI_DRM_12739: 5fc904286af94038fbf2c7cda50ed871b70cf4e8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7160: 45da871dd2684227e93a2fc002b87dfc58bd5fd9 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_114030v1: 5fc904286af94038fbf2c7cda50ed871b70cf4e8 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
da4b6027a0f2 drm/i915: Don't use stolen memory for ring buffers
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114030v1/index.html
Re: [Intel-gfx] [PATCH v3 05/15] kvm/vfio: Accept vfio device file from userspace
On Tue, Feb 14, 2023 at 04:42:35PM -0700, Alex Williamson wrote: > A device file opened through a group could be passed through this > interface though, right? Yes, I think so > Do we just chalk that up to user error? Maybe the SPAPR extension > at least needs to be documented as relying on registering groups > rather than devices. The way these APIs work is you have to pass the same FD to all of them. The SPAPR stuff is no different, if you used a cdev with KVM_DEV_VFIO_GROUP_ADD then you have to use the same cdev fd with the SPAPR group_fd. Yi just didn't rename it. It is weird, but logically self consistent, I think. > > I'm still thinking about proposing to just delete all this SPAPR > > stuff. Power still hasn't had the patches applied to make it work > > again so it seems to all be dead. > > There's been some off-list discussion about at least fixing SPAPR > support, but yes, it either needs to get some love or we ought to think > about its future. Thanks, The patches exist, they just need to be applied AFAIK. If the people responsible can't care enough about this to even do that then I find it hard to care at all about the state of SPAPR. Jason
Re: [Intel-gfx] [PATCH v3 14/15] vfio: Add ioctls for device cdev using iommufd
On Mon, Feb 13, 2023 at 07:13:47AM -0800, Yi Liu wrote:
...
> +long vfio_device_ioctl_bind_iommufd(struct vfio_device_file *df,
> + unsigned long arg)
> +{
> + struct vfio_device *device = df->device;
> + struct vfio_device_bind_iommufd bind;
> + struct iommufd_ctx *iommufd = NULL;
> + struct fd f;
> + 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_claim_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 {
> + f = fdget(bind.iommufd);
> + if (!f.file) {
> + ret = -EBADF;
> + goto out_unlock;
> + }
> + iommufd = iommufd_ctx_from_file(f.file);
> + if (IS_ERR(iommufd)) {
> + ret = PTR_ERR(iommufd);
> + goto out_put_file;
> + }
> + }
> +
> + /*
> + * 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),
> +_devid,
> +sizeof(bind.out_devid)) ? -EFAULT : 0;
> + if (ret)
> + goto out_close_device;
> +
> + if (iommufd)
> + fdput(f);
> + else if (df->noiommu)
> + dev_warn(device->dev, "vfio-noiommu device used by user "
> + "(%s:%d)\n", current->comm, task_pid_nr(current));
IMHO, the "smp_store_release(>access_granted, true);" in patch 7
should be moved to here when bind is indeed successful.
> + mutex_unlock(>dev_set->lock);
> + return 0;
> +
> +out_close_device:
> + vfio_device_close(df);
> +out_put_kvm:
> + df->iommufd = NULL;
> + df->noiommu = false;
> + vfio_device_put_kvm(device);
> +out_put_file:
> + if (iommufd)
> + fdput(f);
> +out_unlock:
> + mutex_unlock(>dev_set->lock);
> + vfio_device_release_group(device);
> + return ret;
> +}
...
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Use encoder->devdata more
== Series Details ==
Series: series starting with [1/3] drm/i915: Use encoder->devdata more
URL : https://patchwork.freedesktop.org/series/114029/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12739 -> Patchwork_114029v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114029v1/index.html
Participating hosts (39 -> 37)
--
Missing(2): fi-kbl-soraka fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114029v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-rpls-1}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114029v1/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_114029v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][2] -> [FAIL][3] ([i915#6298])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114029v1/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][4] ([i915#7229]) -> [PASS][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114029v1/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [ABORT][6] ([i915#4983]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/bat-rpls-1/igt@i915_selftest@l...@reset.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114029v1/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
Build changes
-
* Linux: CI_DRM_12739 -> Patchwork_114029v1
CI-20190529: 20190529
CI_DRM_12739: 5fc904286af94038fbf2c7cda50ed871b70cf4e8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7160: 45da871dd2684227e93a2fc002b87dfc58bd5fd9 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_114029v1: 5fc904286af94038fbf2c7cda50ed871b70cf4e8 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
7df05f4bf1da drm/i915: Try to initialize DDI ports for every VBT child device
c71fdcbe502e drm/i915: Sanitize child devices later
4e89250129c9 drm/i915: Use encoder->devdata more
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114029v1/index.html
[Intel-gfx] [PATCH] drm/i915: Don't use stolen memory for ring buffers
From: John Harrison Direction from hardware is that stolen memory should never be used for ring buffer allocations. There are too many caching pitfalls due to the way stolen memory accesses are routed. So it is safest to just not use it. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/intel_ring.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_ring.c b/drivers/gpu/drm/i915/gt/intel_ring.c index 15ec64d881c44..d1a47e1ae6452 100644 --- a/drivers/gpu/drm/i915/gt/intel_ring.c +++ b/drivers/gpu/drm/i915/gt/intel_ring.c @@ -116,8 +116,6 @@ static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size) obj = i915_gem_object_create_lmem(i915, size, I915_BO_ALLOC_VOLATILE | I915_BO_ALLOC_PM_VOLATILE); - if (IS_ERR(obj) && i915_ggtt_has_aperture(ggtt)) - obj = i915_gem_object_create_stolen(i915, size); if (IS_ERR(obj)) obj = i915_gem_object_create_internal(i915, size); if (IS_ERR(obj)) -- 2.39.1
Re: [Intel-gfx] [PATCH v3 05/15] kvm/vfio: Accept vfio device file from userspace
On Tue, 14 Feb 2023 19:25:19 -0400
Jason Gunthorpe wrote:
> On Tue, Feb 14, 2023 at 03:26:27PM -0700, Alex Williamson wrote:
> > > index 857d6ba349e1..d869913baafd 100644
> > > --- a/virt/kvm/vfio.c
> > > +++ b/virt/kvm/vfio.c
> > > @@ -286,18 +286,18 @@ static int kvm_vfio_set_file(struct kvm_device
> > > *dev, long attr,
> > > int32_t fd;
> > >
> > > switch (attr) {
> > > - case KVM_DEV_VFIO_GROUP_ADD:
> > > + case KVM_DEV_VFIO_FILE_ADD:
> > > if (get_user(fd, argp))
> > > return -EFAULT;
> > > return kvm_vfio_file_add(dev, fd);
> > >
> > > - case KVM_DEV_VFIO_GROUP_DEL:
> > > + case KVM_DEV_VFIO_FILE_DEL:
> > > if (get_user(fd, argp))
> > > return -EFAULT;
> > > return kvm_vfio_file_del(dev, fd);
> > >
> > > #ifdef CONFIG_SPAPR_TCE_IOMMU
> > > - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE:
> > > + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE:
> > > return kvm_vfio_file_set_spapr_tce(dev, arg);
> >
> > I don't see that the SPAPR code is so easily fungible to a device
> > file descriptor. The kvm_vfio_spapr_tce data structure includes a
> > groupfd, which is required to match a groupfd on the file_list. So
> > a SPAPR user cannot pass a cdev via FILE_ADD if they intend to use
> > this TCE code.
>
> SPAPR cannot use cdev at all, cdev mode only works with iommufd.
>
> So with my other remark about blocking unbound cdevs, in SPAPR mode
> you can never open a cdev and make it bound thus
> kvm_vfio_file_iommu_group() and others will return NULL always for
> cdev.
>
> Thus AFAICT this is all fine.
A device file opened through a group could be passed through this
interface though, right? Do we just chalk that up to user error?
Maybe the SPAPR extension at least needs to be documented as relying on
registering groups rather than devices.
> Yi, you should also add some kconfig stuff to ensure that SPAPR always
> has the group interface compiled in.
>
> > That also makes me wonder what we're really gaining in forcing this
> > generalization from group to file.
>
> I think it is just less code overall. Otherwise we need to needlessly
> double quite a lot of stuff, rather pointlessly, IMHO.
>
> I'm still thinking about proposing to just delete all this SPAPR
> stuff. Power still hasn't had the patches applied to make it work
> again so it seems to all be dead.
There's been some off-list discussion about at least fixing SPAPR
support, but yes, it either needs to get some love or we ought to think
about its future. Thanks,
Alex
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Add MTL PXP Support (rev5)
== Series Details ==
Series: drm/i915/pxp: Add MTL PXP Support (rev5)
URL : https://patchwork.freedesktop.org/series/112647/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12739 -> Patchwork_112647v5
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_112647v5 need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_112647v5, 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_112647v5/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_112647v5:
### IGT changes ###
Warnings
* igt@i915_selftest@live@gt_heartbeat:
- fi-kbl-soraka: [DMESG-FAIL][1] ([i915#5334] / [i915#7872]) ->
[ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v5/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-rpls-1}: NOTRUN -> [ABORT][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v5/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_112647v5 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions:
- fi-bsw-n3050: [PASS][4] -> [FAIL][5] ([i915#6298])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v5/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html
Possible fixes
* igt@gem_exec_gttfill@basic:
- fi-pnv-d510:[FAIL][6] ([i915#7229]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v5/fi-pnv-d510/igt@gem_exec_gttf...@basic.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-apl-guc: [DMESG-FAIL][8] ([i915#5334]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v5/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [ABORT][10] ([i915#4983]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12739/bat-rpls-1/igt@i915_selftest@l...@reset.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_112647v5/bat-rpls-1/igt@i915_selftest@l...@reset.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#7229]: https://gitlab.freedesktop.org/drm/intel/issues/7229
[i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872
[i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932
[i915#7977]: https://gitlab.freedesktop.org/drm/intel/issues/7977
[i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996
Build changes
-
* Linux: CI_DRM_12739 -> Patchwork_112647v5
CI-20190529: 20190529
CI_DRM_12739: 5fc904286af94038fbf2c7cda50ed871b70cf4e8 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_7160: 45da871dd2684227e93a2fc002b87dfc58bd5fd9 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_112647v5: 5fc904286af94038fbf2c7cda50ed871b70cf4e8 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
f4d42a743541 drm/i915/pxp: Enable PXP with MTL-GSC-CS
5604da0f5507 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component
ba1c0f52684b drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0
6addf55bed82 drm/i915/pxp: Add ARB session creation and cleanup
9d13e02eecce drm/i915/pxp: Add GSC-CS backend to send GSC fw messages
2e34fc4a4adb drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
13734f3abe7b drm/i915/pxp: Add MTL hw-plumbing
Re: [Intel-gfx] [PATCH v3 05/15] kvm/vfio: Accept vfio device file from userspace
On Tue, Feb 14, 2023 at 03:26:27PM -0700, Alex Williamson wrote:
> > index 857d6ba349e1..d869913baafd 100644
> > --- a/virt/kvm/vfio.c
> > +++ b/virt/kvm/vfio.c
> > @@ -286,18 +286,18 @@ static int kvm_vfio_set_file(struct kvm_device *dev,
> > long attr,
> > int32_t fd;
> >
> > switch (attr) {
> > - case KVM_DEV_VFIO_GROUP_ADD:
> > + case KVM_DEV_VFIO_FILE_ADD:
> > if (get_user(fd, argp))
> > return -EFAULT;
> > return kvm_vfio_file_add(dev, fd);
> >
> > - case KVM_DEV_VFIO_GROUP_DEL:
> > + case KVM_DEV_VFIO_FILE_DEL:
> > if (get_user(fd, argp))
> > return -EFAULT;
> > return kvm_vfio_file_del(dev, fd);
> >
> > #ifdef CONFIG_SPAPR_TCE_IOMMU
> > - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE:
> > + case KVM_DEV_VFIO_FILE_SET_SPAPR_TCE:
> > return kvm_vfio_file_set_spapr_tce(dev, arg);
>
> I don't see that the SPAPR code is so easily fungible to a device
> file descriptor. The kvm_vfio_spapr_tce data structure includes a
> groupfd, which is required to match a groupfd on the file_list. So
> a SPAPR user cannot pass a cdev via FILE_ADD if they intend to use
> this TCE code.
SPAPR cannot use cdev at all, cdev mode only works with iommufd.
So with my other remark about blocking unbound cdevs, in SPAPR mode
you can never open a cdev and make it bound thus
kvm_vfio_file_iommu_group() and others will return NULL always for
cdev.
Thus AFAICT this is all fine.
Yi, you should also add some kconfig stuff to ensure that SPAPR always
has the group interface compiled in.
> That also makes me wonder what we're really gaining in forcing this
> generalization from group to file.
I think it is just less code overall. Otherwise we need to needlessly
double quite a lot of stuff, rather pointlessly, IMHO.
I'm still thinking about proposing to just delete all this SPAPR
stuff. Power still hasn't had the patches applied to make it work
again so it seems to all be dead.
Jason
[Intel-gfx] [PATCH 2/3] drm/i915: Sanitize child devices later
From: Ville Syrjälä
Currently we sanitize the child device aux_ch/ddc_pin while parsing
the ports from VBT. But that won't work when we have duplicate child
devices for the same port.
Instead let's sanitize just before initializing the encoder,
based on which resources were consumed by encoders that were
(successfully) initialized earlier.
I also included the intel_bios_encoder_sanitize() calls in the
g4x+ DP/HDMI code, but there we need to be careful not confuse
the split DP vs. HDMI encoders as conflicting child devices.
Checking encoder->devdata for equality should suffice.
TODO: the sanitation only affects the VBT assigned stuff, but
we could still have a conflict if one port came from VBT
with a non-default pin, and another port just used the
platform default which happens be the same pin...
TODO: Need to double check the details on commit 41e35ffb380b ("drm/i915:
Favor last VBT child device with conflicting AUX ch/DDC pin")
to make sure we're not breaking stuff with the new
sanitation scheme
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 3 +-
drivers/gpu/drm/i915/display/g4x_hdmi.c | 3 +-
drivers/gpu/drm/i915/display/intel_bios.c | 91 +--
drivers/gpu/drm/i915/display/intel_bios.h | 4 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
5 files changed, 62 insertions(+), 43 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index 5a3e79484608..b794cd2ff7d5 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -1279,13 +1279,14 @@ static const struct drm_encoder_funcs
intel_dp_enc_funcs = {
bool g4x_dp_init(struct drm_i915_private *dev_priv,
i915_reg_t output_reg, enum port port)
{
- const struct intel_bios_encoder_data *devdata;
+ struct intel_bios_encoder_data *devdata;
struct intel_digital_port *dig_port;
struct intel_encoder *intel_encoder;
struct drm_encoder *encoder;
struct intel_connector *intel_connector;
devdata = intel_bios_encoder_data_lookup(dev_priv, port);
+ intel_bios_encoder_sanitize(devdata, port);
/* FIXME bail? */
if (!devdata)
diff --git a/drivers/gpu/drm/i915/display/g4x_hdmi.c
b/drivers/gpu/drm/i915/display/g4x_hdmi.c
index 3a1144865c30..d6c6726bedf8 100644
--- a/drivers/gpu/drm/i915/display/g4x_hdmi.c
+++ b/drivers/gpu/drm/i915/display/g4x_hdmi.c
@@ -548,12 +548,13 @@ intel_hdmi_hotplug(struct intel_encoder *encoder,
void g4x_hdmi_init(struct drm_i915_private *dev_priv,
i915_reg_t hdmi_reg, enum port port)
{
- const struct intel_bios_encoder_data *devdata;
+ struct intel_bios_encoder_data *devdata;
struct intel_digital_port *dig_port;
struct intel_encoder *intel_encoder;
struct intel_connector *intel_connector;
devdata = intel_bios_encoder_data_lookup(dev_priv, port);
+ intel_bios_encoder_sanitize(devdata, port);
/* FIXME bail? */
if (!devdata)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 22bbbca171dc..ac9fc07e5ccf 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -,31 +,31 @@ static u8 map_ddc_pin(struct drm_i915_private *i915, u8
vbt_pin)
return 0;
}
-static enum port get_port_by_ddc_pin(struct drm_i915_private *i915, u8 ddc_pin)
+static struct intel_encoder *
+get_encoder_by_ddc_pin(struct drm_i915_private *i915, u8 ddc_pin)
{
- enum port port;
+ struct intel_encoder *encoder;
if (!ddc_pin)
- return PORT_NONE;
+ return NULL;
- for_each_port(port) {
- const struct intel_bios_encoder_data *devdata =
- i915->display.vbt.ports[port];
+ for_each_intel_encoder(>drm, encoder) {
+ const struct intel_bios_encoder_data *devdata =
encoder->devdata;
if (devdata && ddc_pin == devdata->child.ddc_pin)
- return port;
+ return encoder;
}
- return PORT_NONE;
+ return NULL;
}
static void sanitize_ddc_pin(struct intel_bios_encoder_data *devdata,
enum port port)
{
struct drm_i915_private *i915 = devdata->i915;
- struct child_device_config *child;
+ struct child_device_config *child = >child;
+ struct intel_encoder *other;
u8 mapped_ddc_pin;
- enum port p;
if (!devdata->child.ddc_pin)
return;
@@ -2261,79 +2261,85 @@ static void sanitize_ddc_pin(struct
intel_bios_encoder_data *devdata,
return;
}
- p = get_port_by_ddc_pin(i915, devdata->child.ddc_pin);
- if (p == PORT_NONE)
+ other = get_encoder_by_ddc_pin(i915, devdata->child.ddc_pin);
+
[Intel-gfx] [PATCH 3/3] drm/i915: Try to initialize DDI ports for every VBT child device
From: Ville Syrjälä
Try to deal with duplicate child devices for the same DDI port
by attempting to initialize each in turn. The first on to succeed
will be the one we use.
TODO: Still very rough. Should probably just initialize DDIs
strictly in child device order, and just filter out the
ones that are bogus (eg. via device_info->port_mask etc.)?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 67 ++-
drivers/gpu/drm/i915/display/intel_bios.h | 6 ++
drivers/gpu/drm/i915/display/intel_ddi.c | 29
.../gpu/drm/i915/display/intel_display_core.h | 2 -
4 files changed, 72 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index ac9fc07e5ccf..73b1f18bc8c9 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2610,6 +2610,31 @@ intel_bios_encoder_is_lspcon(const struct
intel_bios_encoder_data *devdata)
return devdata && HAS_LSPCON(devdata->i915) && devdata->child.lspcon;
}
+bool
+intel_bios_for_each_child(struct drm_i915_private *i915,
+ enum port port,
+ bool (*func)(struct drm_i915_private *i915,
+ struct intel_bios_encoder_data *devdata,
+ enum port port))
+{
+ struct intel_bios_encoder_data *devdata;
+ bool found = false;
+
+ list_for_each_entry(devdata, >display.vbt.display_devices, node) {
+ const struct child_device_config *child = >child;
+
+ if (dvo_port_to_port(i915, child->dvo_port) != port)
+ continue;
+
+ found = true;
+
+ if (func(i915, devdata, port))
+ break;
+ }
+
+ return found;
+}
+
/* This is an index in the HDMI/DVI DDI buffer translation table, or -1 */
int intel_bios_encoder_hdmi_level_shift(const struct intel_bios_encoder_data
*devdata)
{
@@ -2656,13 +2681,19 @@ static bool is_port_valid(struct drm_i915_private
*i915, enum port port)
return true;
}
-static void print_ddi_port(const struct intel_bios_encoder_data *devdata,
- enum port port)
+static void print_ddi_port(const struct intel_bios_encoder_data *devdata)
{
struct drm_i915_private *i915 = devdata->i915;
const struct child_device_config *child = >child;
bool is_dvi, is_hdmi, is_dp, is_edp, is_dsi, is_crt,
supports_typec_usb, supports_tbt;
int dp_boost_level, dp_max_link_rate, hdmi_boost_level,
hdmi_level_shift, max_tmds_clock;
+ enum port port;
+
+ port = dvo_port_to_port(i915, child->dvo_port);
+ if (port == PORT_NONE && DISPLAY_VER(i915) >= 11)
+ port = dsi_dvo_port_to_port(i915, child->dvo_port);
+ if (port == PORT_NONE)
+ return;
is_dvi = intel_bios_encoder_supports_dvi(devdata);
is_dp = intel_bios_encoder_supports_dp(devdata);
@@ -2741,16 +2772,7 @@ static void parse_ddi_port(struct
intel_bios_encoder_data *devdata)
return;
}
- if (i915->display.vbt.ports[port]) {
- drm_dbg_kms(>drm,
- "More than one child device for port %c in VBT,
using the first.\n",
- port_name(port));
- return;
- }
-
sanitize_device_type(devdata, port);
-
- i915->display.vbt.ports[port] = devdata;
}
void intel_bios_encoder_sanitize(struct intel_bios_encoder_data *devdata,
@@ -2774,7 +2796,6 @@ static bool has_ddi_port_info(struct drm_i915_private
*i915)
static void parse_ddi_ports(struct drm_i915_private *i915)
{
struct intel_bios_encoder_data *devdata;
- enum port port;
if (!has_ddi_port_info(i915))
return;
@@ -2782,10 +2803,8 @@ static void parse_ddi_ports(struct drm_i915_private
*i915)
list_for_each_entry(devdata, >display.vbt.display_devices, node)
parse_ddi_port(devdata);
- for_each_port(port) {
- if (i915->display.vbt.ports[port])
- print_ddi_port(i915->display.vbt.ports[port], port);
- }
+ list_for_each_entry(devdata, >display.vbt.display_devices, node)
+ print_ddi_port(devdata);
}
static void
@@ -3727,5 +3746,19 @@ bool intel_bios_encoder_hpd_invert(const struct
intel_bios_encoder_data *devdata
struct intel_bios_encoder_data *
intel_bios_encoder_data_lookup(struct drm_i915_private *i915, enum port port)
{
- return i915->display.vbt.ports[port];
+ struct intel_bios_encoder_data *devdata;
+
+ list_for_each_entry(devdata, >display.vbt.display_devices, node) {
+ const struct child_device_config *child = >child;
+ enum port p;
+
+ p = dvo_port_to_port(i915, child->dvo_port);
+ if
[Intel-gfx] [PATCH 1/3] drm/i915: Use encoder->devdata more
From: Ville Syrjälä
Switch a lot of the intel_bios_foo() stuff to just accept the
devdata (VBT child device info) directly, instead of taking
detours via vbt.ports[].
Also unify the function naming scheme.
TODO: is intel_bios_encoder_{dp,hdmi}_ too much? Or should we
shorten to just intel_bios_{dp,hdmi}_ ?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 54 +--
drivers/gpu/drm/i915/display/intel_bios.h | 15 ---
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_dp.c | 4 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 4 +-
5 files changed, 23 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index 229f9782e226..22bbbca171dc 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -2520,7 +2520,7 @@ static int parse_bdb_216_dp_max_link_rate(const int
vbt_max_link_rate)
}
}
-static int _intel_bios_dp_max_link_rate(const struct intel_bios_encoder_data
*devdata)
+int intel_bios_encoder_dp_max_link_rate(const struct intel_bios_encoder_data
*devdata)
{
if (!devdata || devdata->i915->display.vbt.version < 216)
return 0;
@@ -2531,7 +2531,7 @@ static int _intel_bios_dp_max_link_rate(const struct
intel_bios_encoder_data *de
return
parse_bdb_216_dp_max_link_rate(devdata->child.dp_max_link_rate);
}
-static int _intel_bios_dp_max_lane_count(const struct intel_bios_encoder_data
*devdata)
+int intel_bios_encoder_dp_max_lane_count(const struct intel_bios_encoder_data
*devdata)
{
if (!devdata || devdata->i915->display.vbt.version < 244)
return 0;
@@ -2604,7 +2604,8 @@ intel_bios_encoder_is_lspcon(const struct
intel_bios_encoder_data *devdata)
return devdata && HAS_LSPCON(devdata->i915) && devdata->child.lspcon;
}
-static int _intel_bios_hdmi_level_shift(const struct intel_bios_encoder_data
*devdata)
+/* This is an index in the HDMI/DVI DDI buffer translation table, or -1 */
+int intel_bios_encoder_hdmi_level_shift(const struct intel_bios_encoder_data
*devdata)
{
if (!devdata || devdata->i915->display.vbt.version < 158)
return -1;
@@ -2612,7 +2613,7 @@ static int _intel_bios_hdmi_level_shift(const struct
intel_bios_encoder_data *de
return devdata->child.hdmi_level_shifter_value;
}
-static int _intel_bios_max_tmds_clock(const struct intel_bios_encoder_data
*devdata)
+int intel_bios_encoder_hdmi_max_tmds_clock(const struct
intel_bios_encoder_data *devdata)
{
if (!devdata || devdata->i915->display.vbt.version < 204)
return 0;
@@ -2674,14 +2675,14 @@ static void print_ddi_port(const struct
intel_bios_encoder_data *devdata,
supports_typec_usb, supports_tbt,
devdata->dsc != NULL);
- hdmi_level_shift = _intel_bios_hdmi_level_shift(devdata);
+ hdmi_level_shift = intel_bios_encoder_hdmi_level_shift(devdata);
if (hdmi_level_shift >= 0) {
drm_dbg_kms(>drm,
"Port %c VBT HDMI level shift: %d\n",
port_name(port), hdmi_level_shift);
}
- max_tmds_clock = _intel_bios_max_tmds_clock(devdata);
+ max_tmds_clock = intel_bios_encoder_hdmi_max_tmds_clock(devdata);
if (max_tmds_clock)
drm_dbg_kms(>drm,
"Port %c VBT HDMI max TMDS clock: %d kHz\n",
@@ -2700,7 +2701,7 @@ static void print_ddi_port(const struct
intel_bios_encoder_data *devdata,
"Port %c VBT HDMI boost level: %d\n",
port_name(port), hdmi_boost_level);
- dp_max_link_rate = _intel_bios_dp_max_link_rate(devdata);
+ dp_max_link_rate = intel_bios_encoder_dp_max_link_rate(devdata);
if (dp_max_link_rate)
drm_dbg_kms(>drm,
"Port %c VBT DP max link rate: %d\n",
@@ -3665,22 +3666,6 @@ enum aux_ch intel_bios_port_aux_ch(struct
drm_i915_private *i915,
return aux_ch;
}
-int intel_bios_max_tmds_clock(struct intel_encoder *encoder)
-{
- struct drm_i915_private *i915 = to_i915(encoder->base.dev);
- const struct intel_bios_encoder_data *devdata =
i915->display.vbt.ports[encoder->port];
-
- return _intel_bios_max_tmds_clock(devdata);
-}
-
-/* This is an index in the HDMI/DVI DDI buffer translation table, or -1 */
-int intel_bios_hdmi_level_shift(struct intel_encoder *encoder)
-{
- struct drm_i915_private *i915 = to_i915(encoder->base.dev);
- const struct intel_bios_encoder_data *devdata =
i915->display.vbt.ports[encoder->port];
-
- return _intel_bios_hdmi_level_shift(devdata);
-}
int intel_bios_encoder_dp_boost_level(const struct intel_bios_encoder_data
*devdata)
{
@@ -3698,31 +3683,12 @@ int intel_bios_encoder_hdmi_boost_level(const
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pxp: Add MTL PXP Support (rev5)
== Series Details == Series: drm/i915/pxp: Add MTL PXP Support (rev5) URL : https://patchwork.freedesktop.org/series/112647/ State : warning == Summary == Error: dim checkpatch failed 4a495413a6d8 drm/i915/pxp: Add GSC-CS back-end resource init and cleanup Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:98: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #98: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 170 lines checked fa2d6c5ec447 drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:109: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #109: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 153 lines checked 84add81a8c3b drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:120: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #120: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 199 lines checked 52e92ac44437 drm/i915/pxp: Add GSC-CS backend to send GSC fw messages 4126f119077b drm/i915/pxp: Add ARB session creation and cleanup 5a94144d5a73 drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0 4c78ae560a0a drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component 7e86d571d1c1 drm/i915/pxp: Enable PXP with MTL-GSC-CS
Re: [Intel-gfx] [PATCH v3 07/15] vfio: Block device access via device fd until device is opened
On Mon, 13 Feb 2023 07:13:40 -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/vfio.h | 1 +
> drivers/vfio/vfio_main.c | 34 +-
> 2 files changed, 34 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/vfio/vfio.h b/drivers/vfio/vfio.h
> index 11e56fe079a1..d56cdb114024 100644
> --- a/drivers/vfio/vfio.h
> +++ b/drivers/vfio/vfio.h
> @@ -18,6 +18,7 @@ struct vfio_container;
>
> struct vfio_device_file {
> struct vfio_device *device;
> + bool access_granted;
> spinlock_t kvm_ref_lock; /* protect kvm field */
> struct kvm *kvm;
> struct iommufd_ctx *iommufd; /* protected by struct
> vfio_device_set::lock */
> diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
> index c517252aba19..2267057240bd 100644
> --- a/drivers/vfio/vfio_main.c
> +++ b/drivers/vfio/vfio_main.c
> @@ -476,7 +476,15 @@ int vfio_device_open(struct vfio_device_file *df)
> device->open_count--;
> }
>
> - return ret;
> + if (ret)
> + return ret;
> +
> + /*
> + * Paired with smp_load_acquire() in vfio_device_fops::ioctl/
> + * read/write/mmap
> + */
> + smp_store_release(>access_granted, true);
> + return 0;
> }
>
> void vfio_device_close(struct vfio_device_file *df)
> @@ -1104,8 +1112,14 @@ static long vfio_device_fops_unl_ioctl(struct file
> *filep,
> {
> struct vfio_device_file *df = filep->private_data;
> struct vfio_device *device = df->device;
> + bool access;
> int ret;
>
> + /* Paired with smp_store_release() in vfio_device_open() */
> + access = smp_load_acquire(>access_granted);
> + if (!access)
> + return -EINVAL;
> +
Nit,
if (!smp_load_acquire(>access_granted))
...
Thanks,
Alex
> ret = vfio_device_pm_runtime_get(device);
> if (ret)
> return ret;
> @@ -1132,6 +1146,12 @@ static ssize_t vfio_device_fops_read(struct file
> *filep, char __user *buf,
> {
> struct vfio_device_file *df = filep->private_data;
> struct vfio_device *device = df->device;
> + bool access;
> +
> + /* Paired with smp_store_release() in vfio_device_open() */
> + access = smp_load_acquire(>access_granted);
> + if (!access)
> + return -EINVAL;
>
> if (unlikely(!device->ops->read))
> return -EINVAL;
> @@ -1145,6 +1165,12 @@ static ssize_t vfio_device_fops_write(struct file
> *filep,
> {
> struct vfio_device_file *df = filep->private_data;
> struct vfio_device *device = df->device;
> + bool access;
> +
> + /* Paired with smp_store_release() in vfio_device_open() */
> + access = smp_load_acquire(>access_granted);
> + if (!access)
> + return -EINVAL;
>
> if (unlikely(!device->ops->write))
> return -EINVAL;
> @@ -1156,6 +1182,12 @@ static int vfio_device_fops_mmap(struct file *filep,
> struct vm_area_struct *vma)
> {
> struct vfio_device_file *df = filep->private_data;
> struct vfio_device *device = df->device;
> + bool access;
> +
> + /* Paired with smp_store_release() in vfio_device_open() */
> + access = smp_load_acquire(>access_granted);
> + if (!access)
> + return -EINVAL;
>
> if (unlikely(!device->ops->mmap))
> return -EINVAL;
Re: [Intel-gfx] [PATCH i-g-t v3 1/1] tests: Exercise remote request vs barrier handling race
Hi Kamil,
Thanks for review.
On Tuesday, 14 February 2023 22:20:10 CET Kamil Konieczny wrote:
> Hi Janusz,
>
> On 2023-02-13 at 10:31:32 +0100, Janusz Krzysztofik wrote:
> > Users reported oopses on list corruptions when using i915 perf with a
> > number of concurrently running graphics applications. That indicates we
> > are currently missing some important tests for such scenarios. Cover
> > that gap.
> >
> > Root cause analysis pointed out to an issue in barrier processing code and
> > its interaction with perf replacing kernel contexts' active barriers with
> > its own requests.
> >
> > Add a new test intended for exercising intentionally racy barrier tasks
> > list processing and its interaction with other i915 subsystems. As a
> > first subtest, add one that exercises the interaction of remote requests
> > with barrier tasks list handling, especially barrier preallocate / acquire
> > operations performed during context first pin / last unpin.
> >
> > The code is partially inspired by Chris Wilson's igt@perf@open-race
> > subtest, which I was not able to get an Ack for from upstream.
> >
> > v3: don't add the new subtest to gem_ctx_exec which occurred blocklisted,
> > create a new test hosting the new subtest, update commit descripion,
> > - prepare parameters for perf open still in the main thread to avoid
> > test failures on platforms with no perf support (will skip now),
> > - call perf open with OA buffer reports disabled, this will make sure
> > that the perf API doesn't unnecessarily enable the OA unit, while the
> > test still runs the targeted code (Umesh),
> > - replace additional code for OA exponent calculations with a reasonable
> > hardcoded value (Umesh).
> > v2: convert to a separate subtest, not a variant of another one (that has
> > been dropped from the series),
> > - move the subtest out of tests/i915/perf.c (Ashutosh), add it to
> > tests/i915/gem_ctx_exec.c,
> > - don't touch lib/i915/perf.c (Umesh, Ashutosh), duplicate reused code
> > from tests/i915/perf.c in tests/i915/gem_ctx_exec.c.
> >
> > References: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
> > Signed-off-by: Janusz Krzysztofik
> > Cc: Chris Wilson
> > Cc: Kamil Konieczny
> > Cc: Ashutosh Dixit
> > Cc: Umesh Nerlige Ramappa
> > ---
> > tests/i915/gem_barrier_race.c | 159 ++
> > tests/meson.build | 8 ++
> > 2 files changed, 167 insertions(+)
> > create mode 100644 tests/i915/gem_barrier_race.c
> >
> > diff --git a/tests/i915/gem_barrier_race.c b/tests/i915/gem_barrier_race.c
> > new file mode 100644
> > index 00..fd0c7bdf1c
> > --- /dev/null
> > +++ b/tests/i915/gem_barrier_race.c
> > @@ -0,0 +1,159 @@
> > +// SPDX-License-Identifier: MIT
> > +/*
> > + * Copyright(c) 2023 Intel Corporation. All rights reserved.
> > + */
> > +
> > +#include
> > +
> > +#include "drmtest.h"
> > +#include "igt_aux.h"
> > +#include "igt_core.h"
> > +#include "igt_gt.h"
> > +#include "intel_chipset.h"
> > +#include "intel_reg.h"
> > +#include "ioctl_wrappers.h"
> > +
> > +#include "i915/gem.h"
> > +#include "i915/gem_create.h"
> > +#include "i915/gem_engine_topology.h"
> > +#include "i915/perf.h"
> > +
> > +IGT_TEST_DESCRIPTION("Exercise barrier tasks list handling and its
> > interation with other i915 subsystems");
> --- ^
> --^-- ^
> s/interation/interaction/
Thanks.
> Please make it generic so it will not need to be changed soon,
> for example:
> IGT_TEST_DESCRIPTION("Exercise barrier tasks and its interaction with other
> subsystems");
Since we are not exercising barrier tasks only barriers (the list name is
barrier_tasks, while another list is called preallocated_barriers, then
"tasks" without "list" may be confusing, I believe), I'll use:
IGT_TEST_DESCRIPTION("Exercise barriers and their interaction with other
subsystems");
OK?
>
> > +
> > +/* Based on code patterns found in tests/i915/perf.c */
> > +static void perf_open_close_workload(int fd, int *done)
> > +{
> > + struct intel_perf_metric_set *metric_set = NULL, *metric_set_iter;
> > + struct intel_perf *intel_perf = intel_perf_for_fd(fd);
> > + uint64_t properties[] = {
> > + DRM_I915_PERF_PROP_SAMPLE_OA, true,
> > + DRM_I915_PERF_PROP_OA_METRICS_SET, 0,
> > + DRM_I915_PERF_PROP_OA_FORMAT, 0,
> > + DRM_I915_PERF_PROP_OA_EXPONENT, 5,
> > + };
> > + struct drm_i915_perf_open_param param = {
> > + .flags = I915_PERF_FLAG_FD_CLOEXEC | I915_PERF_FLAG_DISABLED,
> > + .num_properties = sizeof(properties) / 16,
> > + .properties_ptr = to_user_pointer(properties),
> > + };
> > + uint32_t devid = intel_get_drm_devid(fd);
> > +
> > + igt_require(intel_perf);
> > + intel_perf_load_perf_configs(intel_perf, fd);
> > +
> > + igt_require(devid);
> > +
Re: [Intel-gfx] [PATCH v3 05/15] kvm/vfio: Accept vfio device file from userspace
On Mon, 13 Feb 2023 07:13:38 -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 | 45 -
> include/uapi/linux/kvm.h| 16 ++---
> virt/kvm/vfio.c | 16 -
> 3 files changed, 50 insertions(+), 27 deletions(-)
>
> diff --git a/Documentation/virt/kvm/devices/vfio.rst
> b/Documentation/virt/kvm/devices/vfio.rst
> index 2d20dc561069..90f22933dcfa 100644
> --- a/Documentation/virt/kvm/devices/vfio.rst
> +++ b/Documentation/virt/kvm/devices/vfio.rst
> @@ -9,24 +9,37 @@ Device types supported:
>- KVM_DEV_TYPE_VFIO
>
> Only one VFIO instance may be created per VM. The created device
> -tracks VFIO groups in use by the VM and features of those groups
> -important to the correctness and acceleration of the VM. As groups
> -are enabled and disabled for use by the VM, KVM should be updated
> -about their presence. When registered with KVM, a reference to the
> -VFIO-group is held by KVM.
> +tracks VFIO files (group or device) in use by the VM and features
> +of those groups/devices important to the correctness and acceleration
> +of the VM. As groups/devices are enabled and disabled for use by the
> +VM, KVM should be updated about their presence. When registered with
> +KVM, a reference to the VFIO file is held by KVM.
>
> Groups:
> - KVM_DEV_VFIO_GROUP
> -
> -KVM_DEV_VFIO_GROUP attributes:
> - KVM_DEV_VFIO_GROUP_ADD: Add a VFIO group to VFIO-KVM device tracking
> - kvm_device_attr.addr points to an int32_t file descriptor
> - for the VFIO group.
> - KVM_DEV_VFIO_GROUP_DEL: Remove a VFIO group from VFIO-KVM device tracking
> - kvm_device_attr.addr points to an int32_t file descriptor
> - for the VFIO group.
> - KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE: attaches a guest visible TCE table
> + KVM_DEV_VFIO_FILE
> + alias: KVM_DEV_VFIO_GROUP
> +
> +KVM_DEV_VFIO_FILE attributes:
> + KVM_DEV_VFIO_FILE_ADD: Add a VFIO file (group/device) to VFIO-KVM device
> + tracking
> +
> + alias: KVM_DEV_VFIO_GROUP_ADD
> +
> + kvm_device_attr.addr points to an int32_t file descriptor for the
> + VFIO file.
> + KVM_DEV_VFIO_FILE_DEL: Remove a VFIO file (group/device) from VFIO-KVM
> + device tracking
> +
> + alias: KVM_DEV_VFIO_GROUP_DEL
> +
> + kvm_device_attr.addr points to an int32_t file descriptor for the
> + VFIO file.
> +
> + KVM_DEV_VFIO_FILE_SET_SPAPR_TCE: attaches a guest visible TCE table
> allocated by sPAPR KVM.
> +
> + alias: KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE
> +
> kvm_device_attr.addr points to a struct::
>
> struct kvm_vfio_spapr_tce {
> @@ -39,3 +52,5 @@ KVM_DEV_VFIO_GROUP attributes:
> - @groupfd is a file descriptor for a VFIO group;
> - @tablefd is a file descriptor for a TCE table allocated via
> KVM_CREATE_SPAPR_TCE.
> +
> + only accepts vfio group file
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 55155e262646..484a8133bc69 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
> @@ -1401,10 +1401,18 @@ struct kvm_device_attr {
> __u64 addr; /* userspace address of attr data */
> };
>
> -#define KVM_DEV_VFIO_GROUP 1
> -#define KVM_DEV_VFIO_GROUP_ADD 1
> -#define KVM_DEV_VFIO_GROUP_DEL 2
> -#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE 3
> +#define KVM_DEV_VFIO_FILE 1
> +
> +#define KVM_DEV_VFIO_FILE_ADD 1
> +#define KVM_DEV_VFIO_FILE_DEL 2
> +#define KVM_DEV_VFIO_FILE_SET_SPAPR_TCE3
> +
> +/* KVM_DEV_VFIO_GROUP aliases are for compile time uapi compatibility */
> +#define KVM_DEV_VFIO_GROUP KVM_DEV_VFIO_FILE
> +
> +#define KVM_DEV_VFIO_GROUP_ADD KVM_DEV_VFIO_FILE_ADD
> +#define KVM_DEV_VFIO_GROUP_DEL KVM_DEV_VFIO_FILE_DEL
> +#define KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE KVM_DEV_VFIO_FILE_SET_SPAPR_TCE
>
> enum kvm_device_type {
> KVM_DEV_TYPE_FSL_MPIC_20= 1,
> diff --git a/virt/kvm/vfio.c b/virt/kvm/vfio.c
> index 857d6ba349e1..d869913baafd 100644
> --- a/virt/kvm/vfio.c
> +++ b/virt/kvm/vfio.c
> @@ -286,18 +286,18 @@ static int kvm_vfio_set_file(struct kvm_device *dev,
> long attr,
> int32_t fd;
>
> switch (attr) {
> - case KVM_DEV_VFIO_GROUP_ADD:
> + case KVM_DEV_VFIO_FILE_ADD:
> if (get_user(fd, argp))
> return -EFAULT;
> return kvm_vfio_file_add(dev, fd);
>
> - case KVM_DEV_VFIO_GROUP_DEL:
> + case KVM_DEV_VFIO_FILE_DEL:
> if (get_user(fd, argp))
> return -EFAULT;
> return kvm_vfio_file_del(dev, fd);
>
> #ifdef CONFIG_SPAPR_TCE_IOMMU
> - case KVM_DEV_VFIO_GROUP_SET_SPAPR_TCE:
> +
[Intel-gfx] [PATCH v5 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 timeouts for 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_session.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
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_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 v5 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 v5 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 c25e9ff16b57..425e552e335d 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 v5 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 | 9 +-
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 21 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 92 +++
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.h| 3 +
drivers/gpu/drm/i915/pxp/intel_pxp_session.c | 11 ++-
5 files changed, 132 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/pxp/intel_pxp.c
b/drivers/gpu/drm/i915/pxp/intel_pxp.c
index aecc65b5da70..c25e9ff16b57 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp.c
@@ -353,8 +353,13 @@ 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)) {
+ if (wait_for(intel_uc_fw_is_running(>ctrl_gt->uc.gsc.fw),
250))
+ 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 3cd28db830c1..002686cc7c8a 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -9,6 +9,7 @@
#include "gt/uc/intel_gsc_uc_heci_cmd_submit.h"
#include "i915_drv.h"
+#include "intel_pxp_cmd_interface_42.h"
#include "intel_pxp_cmd_interface_43.h"
#include "intel_pxp_gsccs.h"
#include "intel_pxp_types.h"
@@ -121,6 +122,97 @@ static int gsccs_send_message(struct intel_pxp *pxp,
return ret;
}
+int intel_pxp_gsccs_create_session(struct intel_pxp *pxp,
+ int arb_session_id)
+{
+ struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
+ struct gsccs_session_resources *exec = >gsccs_res;
+ struct pxp43_create_arb_in msg_in = {0};
+ struct pxp43_create_arb_out msg_out = {0};
+ u64 gsc_session_retry = 0;
+ int ret, tries = 0;
+
+ /* get a unique host-session-handle (used later in HW cmds) at time of
session creation */
+ get_random_bytes(>host_session_handle,
sizeof(exec->host_session_handle));
+
+ msg_in.header.api_version = PXP_APIVER(4, 3);
+ msg_in.header.command_id = PXP43_CMDID_INIT_SESSION;
+ msg_in.header.stream_id = (FIELD_PREP(PXP43_INIT_SESSION_APPID,
arb_session_id) |
+ FIELD_PREP(PXP43_INIT_SESSION_VALID, 1) |
+ FIELD_PREP(PXP43_INIT_SESSION_APPTYPE, 0));
+ msg_in.header.buffer_len = sizeof(msg_in) - sizeof(msg_in.header);
+ msg_in.protection_mode = PXP43_INIT_SESSION_PROTECTION_ARB;
+
+ /*
+* Keep sending request if GSC firmware was busy.
+* Based on specs, we can expects a worst case pending-bit
+* delay of 2000 milisecs.
+*/
+ do {
+ ret = gsccs_send_message(pxp,
+_in, sizeof(msg_in),
+_out, sizeof(msg_out), NULL,
+_session_retry);
+ /*
[Intel-gfx] [PATCH v5 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 v5 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
and 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.
Signed-off-by: Alan Previn
---
.../drm/i915/pxp/intel_pxp_cmd_interface_43.h | 4 +
drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c| 224 +-
drivers/gpu/drm/i915/pxp/intel_pxp_types.h| 6 +
3 files changed, 232 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..3cd28db830c1 100644
--- a/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
+++ b/drivers/gpu/drm/i915/pxp/intel_pxp_gsccs.c
@@ -6,19 +6,211 @@
#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;
+
+ mutex_lock(>tee_mutex);
+
+ if (!exec->pkt_vma || !exec->bb_vma)
+ return -ENOENT;
+
+ 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, 500);
+ if (ret) {
+ drm_err(>drm, "failed to send gsc PXP msg (%d)\n", ret);
+ goto unlock;
+ }
+
+ /* we keep separate location for reply, so get the response header loc
first */
+ header = exec->pkt_vaddr + PXP43_MAX_HECI_IN_SIZE;
+
+ /* Response validity marker, status and busyness */
+ if (header->validity_marker != GSC_HECI_VALIDITY_MARKER) {
+ drm_err(>drm, "gsc PXP reply with invalid validity
marker\n");
+ ret = -EINVAL;
+ goto unlock;
+ }
+ if (header->status != 0) {
+ drm_dbg(>drm, "gsc PXP reply status has error = 0x%08x\n",
+
[Intel-gfx] [PATCH v5 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 918470a04591..ec2f7d4ed638 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -332,6 +332,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 v5 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. Alan Previn (8): drm/i915/pxp: Add GSC-CS back-end resource init and cleanup drm/i915/pxp: Add MTL hw-plumbing enabling for KCR operation drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC drm/i915/pxp: Add GSC-CS backend to send GSC fw messages drm/i915/pxp: Add ARB session creation and cleanup drm/i915/pxp: MTL-KCR interrupt ctrl's are in GT-0 drm/i915/pxp: On MTL, KCR enabling doesn't wait on tee component drm/i915/pxp: Enable PXP with MTL-GSC-CS drivers/gpu/drm/i915/Makefile
[Intel-gfx] [PATCH v5 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)
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/xelpmp: Consider GSI offset when doing MCR lookups
On Tue, Feb 14, 2023 at 04:35:26AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/xelpmp: Consider GSI offset when doing MCR lookups
> URL : https://patchwork.freedesktop.org/series/113978/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_12734_full -> Patchwork_113978v1_full
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_113978v1_full absolutely need
> to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_113978v1_full, 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_113978v1/index.html
>
> Participating hosts (11 -> 9)
> --
>
> Missing(2): shard-rkl0 shard-tglu-9
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_113978v1_full:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@kms_fbcon_fbt@fbc-suspend:
> - shard-apl: [PASS][1] -> [ABORT][2]
>[1]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12734/shard-apl1/igt@kms_fbcon_...@fbc-suspend.html
>[2]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113978v1/shard-apl6/igt@kms_fbcon_...@fbc-suspend.html
Looks like a problem communicating with the monitor; not related to the
GT MCR change here.
Matt
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_113978v1_full that come from known
> issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_ccs:
> - shard-glk: NOTRUN -> [SKIP][3] ([fdo#109271])
>[3]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113978v1/shard-glk9/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_ccs.html
>
> * igt@kms_cursor_legacy@2x-long-flip-vs-cursor-atomic:
> - shard-glk: [PASS][4] -> [FAIL][5] ([i915#72])
>[4]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12734/shard-glk1/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
>[5]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113978v1/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-atomic.html
>
> * igt@kms_cursor_legacy@flip-vs-cursor@atomic-transitions:
> - shard-apl: [PASS][6] -> [FAIL][7] ([i915#2346])
>[6]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12734/shard-apl6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
>[7]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113978v1/shard-apl4/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
> - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2346])
>[8]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12734/shard-glk6/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
>[9]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113978v1/shard-glk8/igt@kms_cursor_legacy@flip-vs-cur...@atomic-transitions.html
>
>
> Possible fixes
>
> * igt@fbdev@unaligned-read:
> - {shard-tglu}: [SKIP][10] ([i915#2582]) -> [PASS][11]
>[10]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12734/shard-tglu-6/igt@fb...@unaligned-read.html
>[11]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113978v1/shard-tglu-1/igt@fb...@unaligned-read.html
>
> * igt@feature_discovery@psr2:
> - {shard-rkl}:[SKIP][12] ([i915#658]) -> [PASS][13]
>[12]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12734/shard-rkl-2/igt@feature_discov...@psr2.html
>[13]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113978v1/shard-rkl-6/igt@feature_discov...@psr2.html
>
> * igt@gem_exec_endless@dispatch@bcs0:
> - {shard-rkl}:[SKIP][14] ([i915#6247]) -> [PASS][15]
>[14]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12734/shard-rkl-5/igt@gem_exec_endless@dispa...@bcs0.html
>[15]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113978v1/shard-rkl-1/igt@gem_exec_endless@dispa...@bcs0.html
>
> * igt@gem_exec_fair@basic-throttle@rcs0:
> - shard-glk: [FAIL][16] ([i915#2842]) -> [PASS][17] +2 similar
> issues
>[16]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12734/shard-glk9/igt@gem_exec_fair@basic-throt...@rcs0.html
>[17]:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113978v1/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html
>
> * igt@gem_exec_reloc@basic-write-gtt:
> - {shard-rkl}:[SKIP][18] ([i915#3281]) -> [PASS][19] +1 similar
> issue
>[18]:
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12734/shard-rkl-3/igt@gem_exec_re...@basic-write-gtt.html
>[19]:
>
Re: [Intel-gfx] [PATCH i-g-t v3 1/1] tests: Exercise remote request vs barrier handling race
Hi Janusz,
On 2023-02-13 at 10:31:32 +0100, Janusz Krzysztofik wrote:
> Users reported oopses on list corruptions when using i915 perf with a
> number of concurrently running graphics applications. That indicates we
> are currently missing some important tests for such scenarios. Cover
> that gap.
>
> Root cause analysis pointed out to an issue in barrier processing code and
> its interaction with perf replacing kernel contexts' active barriers with
> its own requests.
>
> Add a new test intended for exercising intentionally racy barrier tasks
> list processing and its interaction with other i915 subsystems. As a
> first subtest, add one that exercises the interaction of remote requests
> with barrier tasks list handling, especially barrier preallocate / acquire
> operations performed during context first pin / last unpin.
>
> The code is partially inspired by Chris Wilson's igt@perf@open-race
> subtest, which I was not able to get an Ack for from upstream.
>
> v3: don't add the new subtest to gem_ctx_exec which occurred blocklisted,
> create a new test hosting the new subtest, update commit descripion,
> - prepare parameters for perf open still in the main thread to avoid
> test failures on platforms with no perf support (will skip now),
> - call perf open with OA buffer reports disabled, this will make sure
> that the perf API doesn't unnecessarily enable the OA unit, while the
> test still runs the targeted code (Umesh),
> - replace additional code for OA exponent calculations with a reasonable
> hardcoded value (Umesh).
> v2: convert to a separate subtest, not a variant of another one (that has
> been dropped from the series),
> - move the subtest out of tests/i915/perf.c (Ashutosh), add it to
> tests/i915/gem_ctx_exec.c,
> - don't touch lib/i915/perf.c (Umesh, Ashutosh), duplicate reused code
> from tests/i915/perf.c in tests/i915/gem_ctx_exec.c.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
> Signed-off-by: Janusz Krzysztofik
> Cc: Chris Wilson
> Cc: Kamil Konieczny
> Cc: Ashutosh Dixit
> Cc: Umesh Nerlige Ramappa
> ---
> tests/i915/gem_barrier_race.c | 159 ++
> tests/meson.build | 8 ++
> 2 files changed, 167 insertions(+)
> create mode 100644 tests/i915/gem_barrier_race.c
>
> diff --git a/tests/i915/gem_barrier_race.c b/tests/i915/gem_barrier_race.c
> new file mode 100644
> index 00..fd0c7bdf1c
> --- /dev/null
> +++ b/tests/i915/gem_barrier_race.c
> @@ -0,0 +1,159 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright(c) 2023 Intel Corporation. All rights reserved.
> + */
> +
> +#include
> +
> +#include "drmtest.h"
> +#include "igt_aux.h"
> +#include "igt_core.h"
> +#include "igt_gt.h"
> +#include "intel_chipset.h"
> +#include "intel_reg.h"
> +#include "ioctl_wrappers.h"
> +
> +#include "i915/gem.h"
> +#include "i915/gem_create.h"
> +#include "i915/gem_engine_topology.h"
> +#include "i915/perf.h"
> +
> +IGT_TEST_DESCRIPTION("Exercise barrier tasks list handling and its
> interation with other i915 subsystems");
--- ^
--^-- ^
s/interation/interaction/
Please make it generic so it will not need to be changed soon,
for example:
IGT_TEST_DESCRIPTION("Exercise barrier tasks and its interaction with other
subsystems");
> +
> +/* Based on code patterns found in tests/i915/perf.c */
> +static void perf_open_close_workload(int fd, int *done)
> +{
> + struct intel_perf_metric_set *metric_set = NULL, *metric_set_iter;
> + struct intel_perf *intel_perf = intel_perf_for_fd(fd);
> + uint64_t properties[] = {
> + DRM_I915_PERF_PROP_SAMPLE_OA, true,
> + DRM_I915_PERF_PROP_OA_METRICS_SET, 0,
> + DRM_I915_PERF_PROP_OA_FORMAT, 0,
> + DRM_I915_PERF_PROP_OA_EXPONENT, 5,
> + };
> + struct drm_i915_perf_open_param param = {
> + .flags = I915_PERF_FLAG_FD_CLOEXEC | I915_PERF_FLAG_DISABLED,
> + .num_properties = sizeof(properties) / 16,
> + .properties_ptr = to_user_pointer(properties),
> + };
> + uint32_t devid = intel_get_drm_devid(fd);
> +
> + igt_require(intel_perf);
> + intel_perf_load_perf_configs(intel_perf, fd);
> +
> + igt_require(devid);
> + igt_list_for_each_entry(metric_set_iter, _perf->metric_sets,
> link) {
> + if (!strcmp(metric_set_iter->symbol_name,
> + IS_HASWELL(devid) ? "RenderBasic" : "TestOa")) {
> + metric_set = metric_set_iter;
> + break;
> + }
> + }
> + igt_require(metric_set);
> + igt_require(metric_set->perf_oa_metrics_set);
> + properties[3] = metric_set->perf_oa_metrics_set;
> + properties[5] = metric_set->perf_oa_format;
> +
> + intel_perf_free(intel_perf);
> +
> + igt_fork(child, 1) {
> + do {
> +
Re: [Intel-gfx] [PATCH 2/3] drm/i915/hwmon: Enable PL1 limit when writing limit value to HW
On Tue, Feb 14, 2023 at 12:47:23PM -0800, Dixit, Ashutosh wrote: > On Tue, 14 Feb 2023 06:51:37 -0800, Rodrigo Vivi wrote: > > > > Hi Rodrigo, > > > On Mon, Feb 13, 2023 at 01:00:48PM -0800, Ashutosh Dixit wrote: > > > Previous documentation suggested that the PL1 power limit is always > > > enabled > > > in HW. However we now find this not to be the case on some platforms (such > > > as ATSM). Therefore enable the PL1 power limit (by setting the enable bit) > > > when writing the PL1 limit value to HW. > > > > > > Bspec: 51864 > > > > > > Signed-off-by: Ashutosh Dixit > > > --- > > > drivers/gpu/drm/i915/i915_hwmon.c | 5 +++-- > > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c > > > b/drivers/gpu/drm/i915/i915_hwmon.c > > > index 85195d61f89c7..7c20a6f47b92e 100644 > > > --- a/drivers/gpu/drm/i915/i915_hwmon.c > > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c > > > @@ -385,10 +385,11 @@ hwm_power_max_write(struct hwm_drvdata *ddat, long > > > val) > > > > > > /* Computation in 64-bits to avoid overflow. Round to nearest. */ > > > nval = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_power, > > > SF_POWER); > > > + nval = PKG_PWR_LIM_1_EN | REG_FIELD_PREP(PKG_PWR_LIM_1, nval); > > > > > > hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit, > > > - PKG_PWR_LIM_1, > > > - REG_FIELD_PREP(PKG_PWR_LIM_1, > > > nval)); > > > + PKG_PWR_LIM_1_EN | PKG_PWR_LIM_1, > > > + nval); > > > > This patch looks right to me. But could you please open up on what exactly > > failed on that reverted patch? Why do we need to set the bits together? > > I had explained a bit here: > > https://gitlab.freedesktop.org/drm/intel/-/issues/8062#note_1761070 > > But will repeat. On ATSM, at power-up, PCODE sets the PL1 power limit to 0 > but disables the PL1 power limit. The earlier patch had enabled the the PL1 > power limit during module load itself but had left the PL1 power limit set > to 0 (since there is no easy way to find out what it should be set to, on > ATSM PCODE sets even the max power (which could have been used to set the > PL1 limit) to 0). You can see that patch here: > > https://patchwork.freedesktop.org/patch/521321/?series=113578=4 > > Now the PL1 power limit being 0 (and enabled) implies that HW will work > with minimum power and therefore the lowest effective frequency. This means > all workloads will run slower and this was resulting in various IGT tests > timing out and GuC FW load (on resets) timing out on ATSM and that is why > we had to revert that patch. > > In this patch I have changed the strategy and instead of enabling the PL1 > power limit on module load we now enable it only when the limit is set by > userspace. So at least the default CI will not be affected in this case. We > can see that there no regressions on ATSM this time here: > > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113984v1/bat-all.html? > this makes total sense. Thank you! Reviewed-by: Rodrigo Vivi > Thanks. > -- > Ashutosh > > > > > > > > return 0; > > > } > > > > > > -- > > > 2.38.0 > > >
Re: [Intel-gfx] [PATCH 2/3] drm/i915/hwmon: Enable PL1 limit when writing limit value to HW
On Tue, 14 Feb 2023 06:51:37 -0800, Rodrigo Vivi wrote: > Hi Rodrigo, > On Mon, Feb 13, 2023 at 01:00:48PM -0800, Ashutosh Dixit wrote: > > Previous documentation suggested that the PL1 power limit is always enabled > > in HW. However we now find this not to be the case on some platforms (such > > as ATSM). Therefore enable the PL1 power limit (by setting the enable bit) > > when writing the PL1 limit value to HW. > > > > Bspec: 51864 > > > > Signed-off-by: Ashutosh Dixit > > --- > > drivers/gpu/drm/i915/i915_hwmon.c | 5 +++-- > > 1 file changed, 3 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c > > b/drivers/gpu/drm/i915/i915_hwmon.c > > index 85195d61f89c7..7c20a6f47b92e 100644 > > --- a/drivers/gpu/drm/i915/i915_hwmon.c > > +++ b/drivers/gpu/drm/i915/i915_hwmon.c > > @@ -385,10 +385,11 @@ hwm_power_max_write(struct hwm_drvdata *ddat, long > > val) > > > > /* Computation in 64-bits to avoid overflow. Round to nearest. */ > > nval = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_power, > > SF_POWER); > > + nval = PKG_PWR_LIM_1_EN | REG_FIELD_PREP(PKG_PWR_LIM_1, nval); > > > > hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit, > > - PKG_PWR_LIM_1, > > - REG_FIELD_PREP(PKG_PWR_LIM_1, > > nval)); > > + PKG_PWR_LIM_1_EN | PKG_PWR_LIM_1, > > + nval); > > This patch looks right to me. But could you please open up on what exactly > failed on that reverted patch? Why do we need to set the bits together? I had explained a bit here: https://gitlab.freedesktop.org/drm/intel/-/issues/8062#note_1761070 But will repeat. On ATSM, at power-up, PCODE sets the PL1 power limit to 0 but disables the PL1 power limit. The earlier patch had enabled the the PL1 power limit during module load itself but had left the PL1 power limit set to 0 (since there is no easy way to find out what it should be set to, on ATSM PCODE sets even the max power (which could have been used to set the PL1 limit) to 0). You can see that patch here: https://patchwork.freedesktop.org/patch/521321/?series=113578=4 Now the PL1 power limit being 0 (and enabled) implies that HW will work with minimum power and therefore the lowest effective frequency. This means all workloads will run slower and this was resulting in various IGT tests timing out and GuC FW load (on resets) timing out on ATSM and that is why we had to revert that patch. In this patch I have changed the strategy and instead of enabling the PL1 power limit on module load we now enable it only when the limit is set by userspace. So at least the default CI will not be affected in this case. We can see that there no regressions on ATSM this time here: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113984v1/bat-all.html? Thanks. -- Ashutosh > > > return 0; > > } > > > > -- > > 2.38.0 > >
Re: [Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Replace hwm_field_scale_and_write with hwm_power_max_write
On Tue, Feb 14, 2023 at 12:20:36PM -0800, Dixit, Ashutosh wrote:
> On Tue, 14 Feb 2023 06:50:44 -0800, Rodrigo Vivi wrote:
> >
> > > +static int
> > > +hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> > +{
> > > + struct i915_hwmon *hwmon = ddat->hwmon;
> > > + u32 nval;
> > > +
> > > + /* Computation in 64-bits to avoid overflow. Round to nearest. */
> > > + nval = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_power,
> > > SF_POWER);
> > > +
> > > + hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit,
> > > + PKG_PWR_LIM_1,
> > > + REG_FIELD_PREP(PKG_PWR_LIM_1,
> > > nval));
> > > + return 0;
> >
> > Let's keep this function as void and the return 0 in the previous spot.
>
> Hmm, see your point. Though there is an identical situation for
> hwm_power_max_read read too (in hwm_power_read). Maybe I'll change it there
> too in the same patch to keep things symmetrical and retain your R-b?
okay then. let's move this one as is and fix both functions in a follow up.
Thanks,
Rodrigo.
>
> > With that change:
> >
> > Reviewed-by: Rodrigo Vivi
>
> Thanks.
Re: [Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Replace hwm_field_scale_and_write with hwm_power_max_write
On Tue, 14 Feb 2023 06:50:44 -0800, Rodrigo Vivi wrote:
>
> > +static int
> > +hwm_power_max_write(struct hwm_drvdata *ddat, long val)
> +{
> > + struct i915_hwmon *hwmon = ddat->hwmon;
> > + u32 nval;
> > +
> > + /* Computation in 64-bits to avoid overflow. Round to nearest. */
> > + nval = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_power,
> > SF_POWER);
> > +
> > + hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit,
> > + PKG_PWR_LIM_1,
> > + REG_FIELD_PREP(PKG_PWR_LIM_1,
> > nval));
> > + return 0;
>
> Let's keep this function as void and the return 0 in the previous spot.
Hmm, see your point. Though there is an identical situation for
hwm_power_max_read read too (in hwm_power_read). Maybe I'll change it there
too in the same patch to keep things symmetrical and retain your R-b?
> With that change:
>
> Reviewed-by: Rodrigo Vivi
Thanks.
Re: [Intel-gfx] [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
On Tue, Feb 14, 2023 at 02:27:19PM -0500, Harry Wentland wrote: > > > On 2/14/23 05:28, Ville Syrjälä wrote: > > On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote: > >> On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote: > >>> On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote: > On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Add a new immutable plane property by which a plane can advertise > > a handful of recommended plane sizes. This would be mostly exposed > > by cursor planes as a slightly more capable replacement for > > the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare > > a one size fits all limit for the whole device. > > > > Currently eg. amdgpu/i915/nouveau just advertize the max cursor > > size via the cursor size caps. But always using the max sized > > cursor can waste a surprising amount of power, so a better > > stragey is desirable. > > > > Most other drivers don't specify any cursor size at all, in > > which case the ioctl code just claims that 64x64 is a great > > choice. Whether that is actually true is debatable. > > > > A poll of various compositor developers informs us that > > blindly probing with setcursor/atomic ioctl to determine > > suitable cursor sizes is not acceptable, thus the > > introduction of the new property to supplant the cursor > > size caps. The compositor will now be free to select a > > more optimal cursor size from the short list of options. > > > > Note that the reported sizes (either via the property or the > > caps) make no claims about things such as plane scaling. So > > these things should only really be consulted for simple > > "cursor like" use cases. > > > > v2: Try to add some docs > > > > Cc: Simon Ser > > Cc: Jonas Ådahl > > Cc: Daniel Stone > > Cc: Pekka Paalanen > > Acked-by: Harry Wentland > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/drm_mode_config.c | 7 + > > drivers/gpu/drm/drm_plane.c | 48 +++ > > include/drm/drm_mode_config.h | 5 > > include/drm/drm_plane.h | 4 +++ > > include/uapi/drm/drm_mode.h | 11 +++ > > 5 files changed, 75 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_mode_config.c > > b/drivers/gpu/drm/drm_mode_config.c > > index 87eb591fe9b5..21860f94a18c 100644 > > --- a/drivers/gpu/drm/drm_mode_config.c > > +++ b/drivers/gpu/drm/drm_mode_config.c > > @@ -374,6 +374,13 @@ static int > > drm_mode_create_standard_properties(struct drm_device *dev) > > return -ENOMEM; > > dev->mode_config.modifiers_property = prop; > > > > + prop = drm_property_create(dev, > > + DRM_MODE_PROP_IMMUTABLE | > > DRM_MODE_PROP_BLOB, > > + "SIZE_HINTS", 0); > > + if (!prop) > > + return -ENOMEM; > > + dev->mode_config.size_hints_property = prop; > > + > > return 0; > > } > > > > diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c > > index 24e7998d1731..ae51b1f83755 100644 > > --- a/drivers/gpu/drm/drm_plane.c > > +++ b/drivers/gpu/drm/drm_plane.c > > @@ -140,6 +140,21 @@ > >* DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there > > have been > >* various bugs in this area with inconsistencies between the > > capability > >* flag and per-plane properties. > > + * > > + * SIZE_HINTS: > > + * Blob property which contains the set of recommended plane size > > + * which can used for simple "cursor like" use cases (eg. no > > scaling). > > + * Using these hints frees userspace from extensive probing of > > + * supported plane sizes through atomic/setcursor ioctls. > > + * > > + * For optimal usage userspace should pick the smallest size > > + * that satisfies its own requirements. > > + * > > + * The blob contains an array of struct drm_plane_size_hint. > > + * > > + * Drivers should only attach this property to planes that > > + * support a very limited set of sizes (eg. cursor planes > > + * on typical hardware). > > This is a bit awkward since problematic drivers would only expose > this property if they are new enough. > > A way to avoid this is for all new drivers expose this property, but > special case the size 0x0 as "everything below the max limit goes". Then > userspace can do (ignoring the missing cap fallback). > >>> > >>> I don't think there are any drivers that need that. > >>> So I'm thinking we can just ignore that
Re: [Intel-gfx] [PATCH v2 1/2] drm: Introduce plane SIZE_HINTS property
On 2/14/23 05:28, Ville Syrjälä wrote: On Tue, Feb 14, 2023 at 10:54:27AM +0100, Jonas Ådahl wrote: On Tue, Feb 14, 2023 at 11:25:56AM +0200, Ville Syrjälä wrote: On Thu, Feb 09, 2023 at 03:16:23PM +0100, Jonas Ådahl wrote: On Wed, Feb 08, 2023 at 11:10:16PM +0200, Ville Syrjala wrote: From: Ville Syrjälä Add a new immutable plane property by which a plane can advertise a handful of recommended plane sizes. This would be mostly exposed by cursor planes as a slightly more capable replacement for the DRM_CAP_CURSOR_WIDTH/HEIGHT caps, which can only declare a one size fits all limit for the whole device. Currently eg. amdgpu/i915/nouveau just advertize the max cursor size via the cursor size caps. But always using the max sized cursor can waste a surprising amount of power, so a better stragey is desirable. Most other drivers don't specify any cursor size at all, in which case the ioctl code just claims that 64x64 is a great choice. Whether that is actually true is debatable. A poll of various compositor developers informs us that blindly probing with setcursor/atomic ioctl to determine suitable cursor sizes is not acceptable, thus the introduction of the new property to supplant the cursor size caps. The compositor will now be free to select a more optimal cursor size from the short list of options. Note that the reported sizes (either via the property or the caps) make no claims about things such as plane scaling. So these things should only really be consulted for simple "cursor like" use cases. v2: Try to add some docs Cc: Simon Ser Cc: Jonas Ådahl Cc: Daniel Stone Cc: Pekka Paalanen Acked-by: Harry Wentland Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_mode_config.c | 7 + drivers/gpu/drm/drm_plane.c | 48 +++ include/drm/drm_mode_config.h | 5 include/drm/drm_plane.h | 4 +++ include/uapi/drm/drm_mode.h | 11 +++ 5 files changed, 75 insertions(+) diff --git a/drivers/gpu/drm/drm_mode_config.c b/drivers/gpu/drm/drm_mode_config.c index 87eb591fe9b5..21860f94a18c 100644 --- a/drivers/gpu/drm/drm_mode_config.c +++ b/drivers/gpu/drm/drm_mode_config.c @@ -374,6 +374,13 @@ static int drm_mode_create_standard_properties(struct drm_device *dev) return -ENOMEM; dev->mode_config.modifiers_property = prop; + prop = drm_property_create(dev, + DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB, + "SIZE_HINTS", 0); + if (!prop) + return -ENOMEM; + dev->mode_config.size_hints_property = prop; + return 0; } diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c index 24e7998d1731..ae51b1f83755 100644 --- a/drivers/gpu/drm/drm_plane.c +++ b/drivers/gpu/drm/drm_plane.c @@ -140,6 +140,21 @@ * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been * various bugs in this area with inconsistencies between the capability * flag and per-plane properties. + * + * SIZE_HINTS: + * Blob property which contains the set of recommended plane size + * which can used for simple "cursor like" use cases (eg. no scaling). + * Using these hints frees userspace from extensive probing of + * supported plane sizes through atomic/setcursor ioctls. + * + * For optimal usage userspace should pick the smallest size + * that satisfies its own requirements. + * + * The blob contains an array of struct drm_plane_size_hint. + * + * Drivers should only attach this property to planes that + * support a very limited set of sizes (eg. cursor planes + * on typical hardware). This is a bit awkward since problematic drivers would only expose this property if they are new enough. A way to avoid this is for all new drivers expose this property, but special case the size 0x0 as "everything below the max limit goes". Then userspace can do (ignoring the missing cap fallback). I don't think there are any drivers that need that. So I'm thinking we can just ignore that for now. None the less, userspace not seeing SIZE_HINTS will be required to indefinitely use the existing "old" behavior using the size cap as the buffer size with a fallback, and drivers without any size limitations that, i.e. details that are hard to express with a set of accepted sizes, will still use the inoptimal buffer sizes. If I read [1] correctly, AMD has no particular size limitations other than a size limit, but without a SIZE_HINTS, userspace still needs to use the maximum size. Simon pointed out they have pretty much the same exact limits as i915. Ie. only a few power of two sizes, and stride must match width. That's an artificial limitation in the driver. The HW has no such limitation and it would be nice to drop that from our driver as well. Harry [1] https://gitlab.freedesktop.org/drm/intel/-/issues/7687#note_1760865 Jonas if
Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits
On Tue, Feb 14, 2023 at 11:14 AM Rob Clark wrote: > > On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin > wrote: > > > > From: Tvrtko Ursulin > > > > In i915 we have this concept of "wait boosting" where we give a priority > > boost > > for instance to fences which are actively waited upon from userspace. This > > has > > it's pros and cons and can certainly be discussed at lenght. However fact is > > some workloads really like it. > > > > Problem is that with the arrival of drm syncobj and a new userspace waiting > > entry point it added, the waitboost mechanism was bypassed. Hence I cooked > > up > > this mini series really (really) quickly to see if some discussion can be > > had. > > > > It adds a concept of "wait count" to dma fence, which is incremented for > > every > > explicit dma_fence_enable_sw_signaling and dma_fence_add_wait_callback (like > > dma_fence_add_callback but from explicit/userspace wait paths). > > I was thinking about a similar thing, but in the context of dma_fence > (or rather sync_file) fd poll()ing. How does the kernel differentiate > between "housekeeping" poll()ers that don't want to trigger boost but > simply know when to do cleanup, and waiters who are waiting with some > urgency. I think we could use EPOLLPRI for this purpose. > > Not sure how that translates to waits via the syncobj. But I think we > want to let userspace give some hint about urgent vs housekeeping > waits. So probably the syncobj equiv of this would be to add something along the lines of DRM_SYNCOBJ_WAIT_FLAGS_WAIT_PRI BR, -R > Also, on a related topic: https://lwn.net/Articles/868468/ > > BR, > -R > > > Individual drivers can then inspect this via dma_fence_wait_count() and > > decide > > to wait boost the waits on such fences. > > > > Again, quickly put together and smoke tested only - no guarantees > > whatsoever and > > I will rely on interested parties to test and report if it even works or how > > well. > > > > v2: > > * Small fixups based on CI feedback: > > * Handle decrement correctly for already signalled case while adding > > callback. > > * Remove i915 assert which was making sure struct i915_request does not > > grow. > > * Split out the i915 patch into three separate functional changes. > > > > Tvrtko Ursulin (5): > > dma-fence: Track explicit waiters > > drm/syncobj: Mark syncobj waits as external waiters > > drm/i915: Waitboost external waits > > drm/i915: Mark waits as explicit > > drm/i915: Wait boost requests waited upon by others > > > > drivers/dma-buf/dma-fence.c | 102 -- > > drivers/gpu/drm/drm_syncobj.c | 6 +- > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 - > > drivers/gpu/drm/i915/i915_request.c | 13 ++- > > include/linux/dma-fence.h | 14 +++ > > 5 files changed, 101 insertions(+), 35 deletions(-) > > > > -- > > 2.34.1 > >
Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits
On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > In i915 we have this concept of "wait boosting" where we give a priority boost > for instance to fences which are actively waited upon from userspace. This has > it's pros and cons and can certainly be discussed at lenght. However fact is > some workloads really like it. > > Problem is that with the arrival of drm syncobj and a new userspace waiting > entry point it added, the waitboost mechanism was bypassed. Hence I cooked up > this mini series really (really) quickly to see if some discussion can be had. > > It adds a concept of "wait count" to dma fence, which is incremented for every > explicit dma_fence_enable_sw_signaling and dma_fence_add_wait_callback (like > dma_fence_add_callback but from explicit/userspace wait paths). I was thinking about a similar thing, but in the context of dma_fence (or rather sync_file) fd poll()ing. How does the kernel differentiate between "housekeeping" poll()ers that don't want to trigger boost but simply know when to do cleanup, and waiters who are waiting with some urgency. I think we could use EPOLLPRI for this purpose. Not sure how that translates to waits via the syncobj. But I think we want to let userspace give some hint about urgent vs housekeeping waits. Also, on a related topic: https://lwn.net/Articles/868468/ BR, -R > Individual drivers can then inspect this via dma_fence_wait_count() and decide > to wait boost the waits on such fences. > > Again, quickly put together and smoke tested only - no guarantees whatsoever > and > I will rely on interested parties to test and report if it even works or how > well. > > v2: > * Small fixups based on CI feedback: > * Handle decrement correctly for already signalled case while adding > callback. > * Remove i915 assert which was making sure struct i915_request does not > grow. > * Split out the i915 patch into three separate functional changes. > > Tvrtko Ursulin (5): > dma-fence: Track explicit waiters > drm/syncobj: Mark syncobj waits as external waiters > drm/i915: Waitboost external waits > drm/i915: Mark waits as explicit > drm/i915: Wait boost requests waited upon by others > > drivers/dma-buf/dma-fence.c | 102 -- > drivers/gpu/drm/drm_syncobj.c | 6 +- > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 - > drivers/gpu/drm/i915/i915_request.c | 13 ++- > include/linux/dma-fence.h | 14 +++ > 5 files changed, 101 insertions(+), 35 deletions(-) > > -- > 2.34.1 >
Re: [Intel-gfx] [PATCH v4 5/8] drm/i915/pxp: Add ARB session creation and cleanup
On Thu, 2023-02-09 at 16:42 -0800, Teres Alexis, Alan Previn wrote:
> 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
> ---
>
alan:snip..
> +void intel_pxp_gsccs_end_arb_fw_session(struct intel_pxp *pxp, u32
> session_id)
> +{
> + struct drm_i915_private *i915 = pxp->ctrl_gt->i915;
> + struct pxp42_inv_stream_key_in msg_in = {0};
> + struct pxp42_inv_stream_key_out msg_out = {0};
> + int ret = 0, tries = 0;
> + u64 gsc_session_retry = 0;
> +
> + memset(_in, 0, sizeof(msg_in));
> + memset(_out, 0, sizeof(msg_out));
> + msg_in.header.api_version = PXP_APIVER(4, 2);
> +
Firmware API version is backward compatibility and enforces the correct
API calls for the platform+firmware. Thus, although the structs are v4.2,
the api_version needs to carry PXP_APIVER(4, 3)
alan:snip..
[Intel-gfx] [linux-next:master] BUILD REGRESSION 3ebb0ac55efaf1d0fb1b106f852c114e5021f7eb
tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 3ebb0ac55efaf1d0fb1b106f852c114e5021f7eb Add linux-next specific files for 20230214 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202301300743.bp7dpazv-...@intel.com https://lore.kernel.org/oe-kbuild-all/202301302110.metnwkbd-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302061911.c7xvhx9v-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302062224.byzetxh1-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302092211.54eydhyh-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302111601.jty4lkra-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302112104.g75cghzd-...@intel.com https://lore.kernel.org/oe-kbuild-all/202302142145.in5wznpf-...@intel.com Error/Warning: (recently discovered and may have been fixed) Documentation/riscv/uabi.rst:24: WARNING: Enumerated list ends without a blank line; unexpected unindent. Documentation/sphinx/templates/kernel-toc.html: 1:36 Invalid token: #} ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/fsl-edma.ko] undefined! ERROR: modpost: "devm_platform_ioremap_resource" [drivers/dma/idma64.ko] undefined! arch/mips/kernel/vpe.c:643:41: error: 'struct module' has no member named 'mod_mem' drivers/cxl/core/region.c:2628:6: warning: variable 'rc' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_optc.c:294:6: warning: no previous prototype for 'optc3_wait_drr_doublebuffer_pending_clear' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_hubbub.c:1011:6: warning: no previous prototype for 'hubbub31_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_hubbub.c:948:6: warning: no previous prototype for 'hubbub32_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_hubp.c:158:6: warning: no previous prototype for 'hubp32_init' [-Wmissing-prototypes] drivers/gpu/drm/amd/amdgpu/../display/dc/dcn32/dcn32_resource_helpers.c:62:18: warning: variable 'cursor_bpp' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:1296:32: warning: variable 'result_write_min_hblank' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_capability.c:280:42: warning: variable 'ds_port' set but not used [-Wunused-but-set-variable] drivers/gpu/drm/amd/amdgpu/../display/dc/link/protocols/link_dp_training.c:1586:38: warning: variable 'result' set but not used [-Wunused-but-set-variable] ftrace-ops.c:(.init.text+0x2c3): undefined reference to `__udivdi3' Unverified Error/Warning (likely false positive, please contact us if interested): drivers/clk/ingenic/jz4760-cgu.c:80 jz4760_cgu_calc_m_n_od() error: uninitialized symbol 'od'. drivers/net/ethernet/broadcom/bnxt/bnxt_ulp.c:415 bnxt_rdma_aux_device_init() warn: possible memory leak of 'edev' drivers/net/wireless/realtek/rtl8xxxu/rtl8xxxu_8188e.c:1678 rtl8188e_handle_ra_tx_report2() warn: ignoring unreachable code. drivers/pci/setup-bus.c:1916:21-24: ERROR: invalid reference to the index variable of the iterator on line 1890 drivers/usb/gadget/composite.c:2082:33: sparse: sparse: restricted __le16 degrades to integer drivers/usb/host/xhci-plat.c:371 xhci_generic_plat_probe() error: we previously assumed 'sysdev' could be null (see line 361) Error/Warning ids grouped by kconfigs: gcc_recent_errors |-- alpha-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-ds_port-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_training.c:warning:variable-result-set-but-not-used |-- alpha-randconfig-c041-20230212 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-ds_port-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used |-- alpha-randconfig-s042-20230212 | `-- drivers-usb-gadget-composite.c:sparse:sparse:restricted-__le16-degrades-to-integer |-- arc-allyesconfig | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-ds_port-set-but-not-used | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:variable-result_write_min_hblank-set-but-not-used | `-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_training.c:warning:variable-result-set-but-not-used |-- arc-randconfig-r016-20230213 | |-- drivers-gpu-drm-amd-amdgpu-..-display-dc-link-protocols-link_dp_capability.c:warning:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: Fix platforms without display (rev2)
== Series Details == Series: drm/i915/dg2: Fix platforms without display (rev2) URL : https://patchwork.freedesktop.org/series/113782/ State : success == Summary == CI Bug Log - changes from CI_DRM_12738 -> Patchwork_113782v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/index.html Participating hosts (38 -> 38) -- Additional (2): fi-rkl-11600 fi-elk-e7500 Missing(2): bat-atsm-1 fi-snb-2520m Known issues Here are the changes found in Patchwork_113782v2 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3282]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#7561]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-elk-e7500: NOTRUN -> [SKIP][6] ([fdo#109271]) +30 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-elk-e7500/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@execlists: - fi-bsw-n3050: [PASS][7] -> [ABORT][8] ([i915#7911]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-bsw-n3050/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium_hpd@dp-hpd-fast: - fi-rkl-11600: NOTRUN -> [SKIP][9] ([i915#7828]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-rkl-11600: NOTRUN -> [SKIP][10] ([i915#4103]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size: - fi-blb-e6850: NOTRUN -> [SKIP][11] ([fdo#109271]) +9 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-blb-e6850/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html - fi-bsw-n3050: [PASS][12] -> [FAIL][13] ([i915#6298]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@sprite_plane_onoff: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-read: - fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] / [i915#3708]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-userptr: - fi-rkl-11600: NOTRUN -> [SKIP][18] ([fdo#109295] / [i915#3301] / [i915#3708]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113782v2/fi-rkl-11600/igt@prime_v...@basic-userptr.html Possible fixes * igt@fbdev@write: - fi-blb-e6850:
Re: [Intel-gfx] [PATCH v3 00/15] Add vfio_device cdev for iommufd support
On Tue, Feb 14, 2023 at 08:54:19AM -0700, Alex Williamson wrote: > On Tue, 14 Feb 2023 15:15:28 + > "Liu, Yi L" wrote: > > > > From: Jason Gunthorpe > > > Sent: Tuesday, February 14, 2023 7:22 AM > > > > > > On Mon, Feb 13, 2023 at 12:47:19PM -0700, Alex Williamson wrote: > > > > > > > I think it's too late for v6.3 already, but given this needs at least > > > > one more spin, let's set expectations of this being v6.4 material. > > > > Thanks, > > > > > > Please let's continue to try to get this finished during the merge > > > window, all the other series depend on it. We can manage it with a > > > shared branch again.. > > > > > > > Sure. I've updated the below branch to address Kevin's latest remarks. > > Fixed the compiling failure reported by Alex as well. > > > > https://github.com/yiliu1765/iommufd/commits/vfio_device_cdev_v3 > > > Sorry, I think this is an abuse of the merge window. We have a new uAPI > proposal that's barely a week old and has no reviews or acks other than > Yi's, we have build configuration issues which suggests a lack of > testing, we're finding subtle implications to other existing uAPIs, and > nobody seems to have finished an upstream review, including me. > > Code for the merge window should already be in maintainer trees by now, > the merge window should be for integration. There are a lot of things > in flight and many more review comments coming in than we should see > for this to be a v6.3 candidate. Thanks, Sorry, I ment that we continue to review and try to get this ready for rc1, not abuse the merge window. Obviously this cycle is lost. Jason
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/dg2: Fix platforms without display (rev2)
== Series Details == Series: drm/i915/dg2: Fix platforms without display (rev2) URL : https://patchwork.freedesktop.org/series/113782/ State : warning == Summary == Error: dim checkpatch failed 128c12d5b429 drm/i915: Fix system suspend without fbdev being initialized e6eae74760bb drm/i915: Move display power initialization during driver probing later -:10: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #10: > > only in intel_device_info_runtime_init(). Initializing the display power -:160: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 0 checks, 54 lines checked 2816f4f3cef9 drm/i915/dgfx, mtl+: Disable display functionality if the display is not present b60c3a12b7a6 drm/i915: Sanitize the display fused-off check on GEN7/8
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Make backlight setup debugs consistent
== Series Details ==
Series: series starting with [1/3] drm/i915: Make backlight setup debugs
consistent
URL : https://patchwork.freedesktop.org/series/114012/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12738 -> Patchwork_114012v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/index.html
Participating hosts (38 -> 38)
--
Additional (2): fi-rkl-11600 fi-elk-e7500
Missing(2): bat-atsm-1 fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_114012v1:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live@reset:
- {bat-dg2-11}: [PASS][1] -> [ABORT][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/bat-dg2-11/igt@i915_selftest@l...@reset.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/bat-dg2-11/igt@i915_selftest@l...@reset.html
* igt@i915_suspend@basic-s2idle-without-i915:
- {bat-rpls-1}: [PASS][3] -> [ABORT][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/bat-rpls-1/igt@i915_susp...@basic-s2idle-without-i915.html
Known issues
Here are the changes found in Patchwork_114012v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@basic-hwmon:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#7456])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#2190])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@parallel-random-engines:
- fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#3282])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][9] ([i915#7561])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-elk-e7500: NOTRUN -> [SKIP][10] ([fdo#109271]) +30 similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-elk-e7500/igt@i915_pm_...@basic-pci-d3-state.html
* igt@kms_chamelium_hpd@dp-hpd-fast:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([i915#7828]) +8 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([i915#4103])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-blb-e6850: NOTRUN -> [SKIP][13] ([fdo#109271]) +9 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-blb-e6850/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#109285] / [i915#4098])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@sprite_plane_onoff:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#1072]) +3 similar issues
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([i915#3555] / [i915#4098])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-read:
- fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114012v1/fi-rkl-11600/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][18]
Re: [Intel-gfx] [PATCH v3 00/15] Add vfio_device cdev for iommufd support
On Tue, 14 Feb 2023 15:15:28 + "Liu, Yi L" wrote: > > From: Jason Gunthorpe > > Sent: Tuesday, February 14, 2023 7:22 AM > > > > On Mon, Feb 13, 2023 at 12:47:19PM -0700, Alex Williamson wrote: > > > > > I think it's too late for v6.3 already, but given this needs at least > > > one more spin, let's set expectations of this being v6.4 material. > > > Thanks, > > > > Please let's continue to try to get this finished during the merge > > window, all the other series depend on it. We can manage it with a > > shared branch again.. > > > > Sure. I've updated the below branch to address Kevin's latest remarks. > Fixed the compiling failure reported by Alex as well. > > https://github.com/yiliu1765/iommufd/commits/vfio_device_cdev_v3 Sorry, I think this is an abuse of the merge window. We have a new uAPI proposal that's barely a week old and has no reviews or acks other than Yi's, we have build configuration issues which suggests a lack of testing, we're finding subtle implications to other existing uAPIs, and nobody seems to have finished an upstream review, including me. Code for the merge window should already be in maintainer trees by now, the merge window should be for integration. There are a lot of things in flight and many more review comments coming in than we should see for this to be a v6.3 candidate. Thanks, Alex
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL
== Series Details == Series: series starting with [1/3] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL URL : https://patchwork.freedesktop.org/series/114011/ State : success == Summary == CI Bug Log - changes from CI_DRM_12738 -> Patchwork_114011v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/index.html Participating hosts (38 -> 39) -- Additional (3): fi-kbl-soraka fi-rkl-11600 fi-elk-e7500 Missing(2): bat-atsm-1 fi-snb-2520m Known issues Here are the changes found in Patchwork_114011v1 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#2190]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613]) +3 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#3282]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#7561]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-elk-e7500: NOTRUN -> [SKIP][8] ([fdo#109271]) +30 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-elk-e7500/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@execlists: - fi-kbl-soraka: NOTRUN -> [INCOMPLETE][9] ([i915#7156] / [i915#7913]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html - fi-bsw-nick:[PASS][10] -> [ABORT][11] ([i915#7911] / [i915#7913]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/fi-bsw-nick/igt@i915_selftest@l...@execlists.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-bsw-nick/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][12] ([i915#1886]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][13] ([fdo#109271]) +15 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@dp-hpd-fast: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#7828]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#4103]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size: - fi-blb-e6850: NOTRUN -> [SKIP][16] ([fdo#109271]) +9 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-blb-e6850/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109285] / [i915#4098]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@sprite_plane_onoff: - fi-rkl-11600: NOTRUN -> [SKIP][18] ([i915#1072]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114011v1/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: -
[Intel-gfx] ✗ Fi.CI.IGT: failure for DP2.0 SDP CRC16 for 128/132b link layer (rev2)
== Series Details == Series: DP2.0 SDP CRC16 for 128/132b link layer (rev2) URL : https://patchwork.freedesktop.org/series/113134/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12736_full -> Patchwork_113134v2_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_113134v2_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_113134v2_full, 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_113134v2/index.html Participating hosts (11 -> 10) -- Missing(1): shard-rkl0 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_113134v2_full: ### IGT changes ### Possible regressions * igt@gem_eio@in-flight-suspend: - shard-apl: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12736/shard-apl1/igt@gem_...@in-flight-suspend.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-apl2/igt@gem_...@in-flight-suspend.html Known issues Here are the changes found in Patchwork_113134v2_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fair@basic-deadline: - shard-apl: NOTRUN -> [FAIL][3] ([i915#2846]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-apl3/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace-solo@rcs0: - shard-apl: [PASS][4] -> [FAIL][5] ([i915#2842]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12736/shard-apl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-apl1/igt@gem_exec_fair@basic-pace-s...@rcs0.html * igt@gem_exec_fair@basic-throttle@rcs0: - shard-glk: [PASS][6] -> [FAIL][7] ([i915#2842]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12736/shard-glk5/igt@gem_exec_fair@basic-throt...@rcs0.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-glk7/igt@gem_exec_fair@basic-throt...@rcs0.html * igt@gem_lmem_swapping@smem-oom: - shard-apl: NOTRUN -> [SKIP][8] ([fdo#109271] / [i915#4613]) +1 similar issue [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-apl1/igt@gem_lmem_swapp...@smem-oom.html * igt@gen9_exec_parse@allowed-single: - shard-apl: [PASS][9] -> [ABORT][10] ([i915#5566]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12736/shard-apl6/igt@gen9_exec_pa...@allowed-single.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-apl4/igt@gen9_exec_pa...@allowed-single.html * igt@i915_selftest@live@gt_heartbeat: - shard-apl: [PASS][11] -> [DMESG-FAIL][12] ([i915#5334]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12736/shard-apl2/igt@i915_selftest@live@gt_heartbeat.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-apl6/igt@i915_selftest@live@gt_heartbeat.html * igt@kms_ccs@pipe-a-crc-primary-rotation-180-4_tiled_dg2_rc_ccs: - shard-apl: NOTRUN -> [SKIP][13] ([fdo#109271]) +88 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-apl3/igt@kms_ccs@pipe-a-crc-primary-rotation-180-4_tiled_dg2_rc_ccs.html * igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_mc_ccs: - shard-apl: NOTRUN -> [SKIP][14] ([fdo#109271] / [i915#3886]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-apl3/igt@kms_ccs@pipe-c-ccs-on-another-bo-y_tiled_gen12_mc_ccs.html * igt@kms_flip@2x-plain-flip-fb-recreate@ab-hdmi-a1-hdmi-a2: - shard-glk: [PASS][15] -> [FAIL][16] ([i915#2122]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12736/shard-glk3/igt@kms_flip@2x-plain-flip-fb-recre...@ab-hdmi-a1-hdmi-a2.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-glk8/igt@kms_flip@2x-plain-flip-fb-recre...@ab-hdmi-a1-hdmi-a2.html * igt@kms_frontbuffer_tracking@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt: - shard-glk: NOTRUN -> [SKIP][17] ([fdo#109271]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-glk1/igt@kms_frontbuffer_track...@fbcpsr-2p-scndscrn-pri-indfb-draw-mmap-gtt.html * igt@kms_plane_alpha_blend@alpha-opaque-fb@pipe-a-dp-1: - shard-apl: NOTRUN -> [FAIL][18] ([i915#4573]) +1 similar issue [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v2/shard-apl1/igt@kms_plane_alpha_blend@alpha-opaque...@pipe-a-dp-1.html *
Re: [Intel-gfx] [PATCH v3 00/15] Add vfio_device cdev for iommufd support
On Tue, 14 Feb 2023 01:55:17 + "Liu, Yi L" wrote: > > From: Alex Williamson > > Sent: Tuesday, February 14, 2023 3:47 AM > > > > On Mon, 13 Feb 2023 07:13:33 -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 vfio_device_open() > > be > > > 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_v3 > > > (config CONFIG_IOMMUFD=y CONFIG_VFIO_DEVICE_CDEV=y) > > > > Even using your branch[1], it seems like this has not been tested > > except with cdev support enabled: > > > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > ‘vfio_device_add’: > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:253:48: error: > > ‘struct > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > 253 | ret = cdev_device_add(>cdev, > > >device); > > |^~~~ > > |dev > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c: In function > > ‘vfio_device_del’: > > /home/alwillia/Work/linux.git/drivers/vfio/vfio_main.c:262:42: error: > > ‘struct > > vfio_device’ has no member named ‘cdev’; did you mean ‘dev’? > > 262 | cdev_device_del(>cdev, >device); > > | ^~~~ > > | dev > > Sorry for it. It is due to the cdev definition is under > "#if IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV)". While, in the code it > uses "if (IS_ENABLED(CONFIG_VFIO_DEVICE_CDEV))". I think for > readability, it would be better to always define cdev in vfio_device, > and keep the using of cdev in code. How about your taste? It seems necessary unless we want to litter the code with #ifdefs. > > Additionally the VFIO_ENABLE_GROUP Kconfig option doesn't make much > > sense to me, it seems entirely redundant to VFIO_GROUP. > > The intention is to make the group code compiling match existing case. > Currently, if VFIO is configured, group code is by default compiled. > So VFIO_ENABLE_GROUP a hidden option, and VFIO_GROUP an option > for user. User needs to explicitly config VFIO_GROUP if VFIO_DEVICE_CDEV==y. > If VFIO_DEVICE_CDEV==n, then no matter user configed VFIO_GROUP or not, > the group code shall be compiled. I understand the mechanics, I still find VFIO_ENABLE_GROUP redundant and unnecessary. Also, Kconfig should not allow a configuration without either VFIO_GROUP or VFIO_DEVICE_CDEV as this is not functional. Deselecting VFIO_GROUP should select VFIO_DEVICE_CDEV, but VFIO_DEVICE_CDEV should be an optional addition to VFIO_GROUP. Thanks, Alex
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL
== Series Details == Series: series starting with [1/3] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL URL : https://patchwork.freedesktop.org/series/114011/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask'
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable YCbCr420 for VDSC (rev3)
== Series Details == Series: Enable YCbCr420 for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/113729/ State : success == Summary == CI Bug Log - changes from CI_DRM_12738 -> Patchwork_113729v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/index.html Participating hosts (38 -> 39) -- Additional (3): fi-kbl-soraka fi-rkl-11600 fi-elk-e7500 Missing(2): bat-atsm-1 fi-snb-2520m Known issues Here are the changes found in Patchwork_113729v3 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#7456]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html * igt@gem_exec_gttfill@basic: - fi-pnv-d510:[PASS][2] -> [FAIL][3] ([i915#7229]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/fi-pnv-d510/igt@gem_exec_gttf...@basic.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-pnv-d510/igt@gem_exec_gttf...@basic.html * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#2190]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#4613]) +3 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#3282]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][9] ([i915#7561]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-elk-e7500: NOTRUN -> [SKIP][10] ([fdo#109271]) +30 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-elk-e7500/igt@i915_pm_...@basic-pci-d3-state.html * igt@i915_selftest@live@execlists: - fi-kbl-soraka: NOTRUN -> [INCOMPLETE][11] ([i915#7156] / [i915#7913]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][12] ([i915#1886]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][13] ([fdo#109271]) +15 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@dp-hpd-fast: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#7828]) +8 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#4103]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size: - fi-blb-e6850: NOTRUN -> [SKIP][16] ([fdo#109271]) +9 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-blb-e6850/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109285] / [i915#4098]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@sprite_plane_onoff: - fi-rkl-11600: NOTRUN -> [SKIP][18] ([i915#1072]) +3 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113729v3/fi-rkl-11600/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - fi-rkl-11600: NOTRUN -> [SKIP][19]
Re: [Intel-gfx] [PATCH v3 00/15] Add vfio_device cdev for iommufd support
> From: Jason Gunthorpe > Sent: Tuesday, February 14, 2023 7:22 AM > > On Mon, Feb 13, 2023 at 12:47:19PM -0700, Alex Williamson wrote: > > > I think it's too late for v6.3 already, but given this needs at least > > one more spin, let's set expectations of this being v6.4 material. Thanks, > > Please let's continue to try to get this finished during the merge > window, all the other series depend on it. We can manage it with a > shared branch again.. > Sure. I've updated the below branch to address Kevin's latest remarks. Fixed the compiling failure reported by Alex as well. https://github.com/yiliu1765/iommufd/commits/vfio_device_cdev_v3 Regards, Yi Liu
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable YCbCr420 for VDSC (rev3)
== Series Details == Series: Enable YCbCr420 for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/113729/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH 2/3] drm/i915/hwmon: Enable PL1 limit when writing limit value to HW
On Mon, Feb 13, 2023 at 01:00:48PM -0800, Ashutosh Dixit wrote: > Previous documentation suggested that the PL1 power limit is always enabled > in HW. However we now find this not to be the case on some platforms (such > as ATSM). Therefore enable the PL1 power limit (by setting the enable bit) > when writing the PL1 limit value to HW. > > Bspec: 51864 > > Signed-off-by: Ashutosh Dixit > --- > drivers/gpu/drm/i915/i915_hwmon.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/i915_hwmon.c > b/drivers/gpu/drm/i915/i915_hwmon.c > index 85195d61f89c7..7c20a6f47b92e 100644 > --- a/drivers/gpu/drm/i915/i915_hwmon.c > +++ b/drivers/gpu/drm/i915/i915_hwmon.c > @@ -385,10 +385,11 @@ hwm_power_max_write(struct hwm_drvdata *ddat, long val) > > /* Computation in 64-bits to avoid overflow. Round to nearest. */ > nval = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_power, > SF_POWER); > + nval = PKG_PWR_LIM_1_EN | REG_FIELD_PREP(PKG_PWR_LIM_1, nval); > > hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit, > - PKG_PWR_LIM_1, > - REG_FIELD_PREP(PKG_PWR_LIM_1, > nval)); > + PKG_PWR_LIM_1_EN | PKG_PWR_LIM_1, > + nval); This patch looks right to me. But could you please open up on what exactly failed on that reverted patch? Why do we need to set the bits together? > return 0; > } > > -- > 2.38.0 >
Re: [Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Replace hwm_field_scale_and_write with hwm_power_max_write
On Mon, Feb 13, 2023 at 01:00:47PM -0800, Ashutosh Dixit wrote:
> hwm_field_scale_and_write has a single caller hwm_power_write and is
> specific to hwm_power_write but makes it appear that it is a general
> function which can have multiple callers. Replace the function with
> hwm_power_max_write which is specific to hwm_power_write and use that in
> future patches where the function needs to be extended.
>
> Signed-off-by: Ashutosh Dixit
> ---
> drivers/gpu/drm/i915/i915_hwmon.c | 36 ++-
> 1 file changed, 16 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_hwmon.c
> b/drivers/gpu/drm/i915/i915_hwmon.c
> index 1225bc432f0d5..85195d61f89c7 100644
> --- a/drivers/gpu/drm/i915/i915_hwmon.c
> +++ b/drivers/gpu/drm/i915/i915_hwmon.c
> @@ -99,20 +99,6 @@ hwm_field_read_and_scale(struct hwm_drvdata *ddat,
> i915_reg_t rgadr,
> return mul_u64_u32_shr(reg_value, scale_factor, nshift);
> }
>
> -static void
> -hwm_field_scale_and_write(struct hwm_drvdata *ddat, i915_reg_t rgadr,
> - int nshift, unsigned int scale_factor, long lval)
> -{
> - u32 nval;
> -
> - /* Computation in 64-bits to avoid overflow. Round to nearest. */
> - nval = DIV_ROUND_CLOSEST_ULL((u64)lval << nshift, scale_factor);
> -
> - hwm_locked_with_pm_intel_uncore_rmw(ddat, rgadr,
> - PKG_PWR_LIM_1,
> - REG_FIELD_PREP(PKG_PWR_LIM_1,
> nval));
> -}
> -
> /*
> * hwm_energy - Obtain energy value
> *
> @@ -391,6 +377,21 @@ hwm_power_max_read(struct hwm_drvdata *ddat, long *val)
> return 0;
> }
>
> +static int
> +hwm_power_max_write(struct hwm_drvdata *ddat, long val)
+{
> + struct i915_hwmon *hwmon = ddat->hwmon;
> + u32 nval;
> +
> + /* Computation in 64-bits to avoid overflow. Round to nearest. */
> + nval = DIV_ROUND_CLOSEST_ULL((u64)val << hwmon->scl_shift_power,
> SF_POWER);
> +
> + hwm_locked_with_pm_intel_uncore_rmw(ddat, hwmon->rg.pkg_rapl_limit,
> + PKG_PWR_LIM_1,
> + REG_FIELD_PREP(PKG_PWR_LIM_1,
> nval));
> + return 0;
Let's keep this function as void and the return 0 in the previous spot.
With that change:
Reviewed-by: Rodrigo Vivi
> +}
> +
> static int
> hwm_power_read(struct hwm_drvdata *ddat, u32 attr, int chan, long *val)
> {
> @@ -425,16 +426,11 @@ hwm_power_read(struct hwm_drvdata *ddat, u32 attr, int
> chan, long *val)
> static int
> hwm_power_write(struct hwm_drvdata *ddat, u32 attr, int chan, long val)
> {
> - struct i915_hwmon *hwmon = ddat->hwmon;
> u32 uval;
>
> switch (attr) {
> case hwmon_power_max:
> - hwm_field_scale_and_write(ddat,
> - hwmon->rg.pkg_rapl_limit,
> - hwmon->scl_shift_power,
> - SF_POWER, val);
> - return 0;
> + return hwm_power_max_write(ddat, val);
> case hwmon_power_crit:
> uval = DIV_ROUND_CLOSEST_ULL(val << POWER_SETUP_I1_SHIFT,
> SF_POWER);
> return hwm_pcode_write_i1(ddat->uncore->i915, uval);
> --
> 2.38.0
>
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/display: Communicate display configuration to pcode (rev3)
== Series Details == Series: drm/i915/display: Communicate display configuration to pcode (rev3) URL : https://patchwork.freedesktop.org/series/102678/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12738 -> Patchwork_102678v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_102678v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_102678v3, 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_102678v3/index.html Participating hosts (38 -> 38) -- Additional (2): fi-kbl-soraka fi-rkl-11600 Missing(2): bat-atsm-1 fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_102678v3: ### IGT changes ### Possible regressions * igt@i915_selftest@live@execlists: - fi-kbl-soraka: NOTRUN -> [INCOMPLETE][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-kbl-soraka/igt@i915_selftest@l...@execlists.html Known issues Here are the changes found in Patchwork_102678v3 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@basic-hwmon: - fi-rkl-11600: NOTRUN -> [SKIP][2] ([i915#7456]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-rkl-11600/igt@debugfs_t...@basic-hwmon.html * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html - fi-kbl-soraka: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#2190]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][5] ([fdo#109271] / [i915#4613]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-rkl-11600: NOTRUN -> [SKIP][6] ([i915#4613]) +3 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-rkl-11600/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][7] ([i915#3282]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][8] ([i915#7561]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][9] ([i915#5334] / [i915#7872]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][10] ([i915#1886]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][11] ([fdo#109271]) +15 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@dp-hpd-fast: - fi-rkl-11600: NOTRUN -> [SKIP][12] ([i915#7828]) +8 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-rkl-11600/igt@kms_chamelium_...@dp-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-rkl-11600: NOTRUN -> [SKIP][13] ([i915#4103]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions: - fi-bsw-n3050: [PASS][14] -> [FAIL][15] ([i915#6298]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12738/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-bsw-n3050/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#109285] / [i915#4098]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_102678v3/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@sprite_plane_onoff: - fi-rkl-11600:
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Move display power initialization during driver probing later
On Tue, 14 Feb 2023, Imre Deak wrote:
> On Tue, Feb 14, 2023 at 11:25:04AM +0200, Jani Nikula wrote:
>> On Wed, 08 Feb 2023, Imre Deak wrote:
>> > Determining whether the display engine is present on a platform happens
>> > only in intel_device_info_runtime_init(). Initializing the display power
>> > functionality depends on this condition, so move
>> > intel_power_domains_init() later after the runtime init function has
>> > been called.
>> >
>> > The next patch fixing platforms without display, depends on this patch.
>> >
>>
>> It's pretty hard to review we aren't using any of the power domain stuff
>> before the intel_power_domains_init() call. What happens if we do?
>
> That shouldn't happen before the HW state is read out in
> intel_power_domains_init_hw(). I can't see anything calling the display power
> get/put/is_enabled functions before that, but it would be good to ensure this.
> So how about also adding:
Seems fine to me; doesn't need to be part of this series.
BR,
Jani.
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 7222502a760cc..7014e1770f57a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -213,6 +213,9 @@ bool __intel_display_power_is_enabled(struct
> drm_i915_private *dev_priv,
> struct i915_power_well *power_well;
> bool is_enabled;
>
> + drm_WARN_ON(_priv->drm,
> + dev_priv->display.power.domains.init_state <
> I915_POWER_DOMAINS_INITIALIZING);
> +
> if (dev_priv->runtime_pm.suspended)
> return false;
>
> @@ -488,6 +491,9 @@ __intel_display_power_get_domain(struct drm_i915_private
> *dev_priv,
> struct i915_power_domains *power_domains =
> _priv->display.power.domains;
> struct i915_power_well *power_well;
>
> + drm_WARN_ON(_priv->drm,
> + power_domains->init_state <
> I915_POWER_DOMAINS_INITIALIZING);
> +
> if (intel_display_power_grab_async_put_ref(dev_priv, domain))
> return;
>
> @@ -1880,7 +1886,7 @@ void intel_power_domains_init_hw(struct
> drm_i915_private *i915, bool resume)
> {
> struct i915_power_domains *power_domains = >display.power.domains;
>
> - power_domains->initializing = true;
> + power_domains->init_state = I915_POWER_DOMAINS_INITIALIZING;
>
> if (DISPLAY_VER(i915) >= 11) {
> icl_display_core_init(i915, resume);
> @@ -1924,7 +1930,7 @@ void intel_power_domains_init_hw(struct
> drm_i915_private *i915, bool resume)
> }
> intel_power_domains_sync_hw(i915);
>
> - power_domains->initializing = false;
> + power_domains->init_state = I915_POWER_DOMAINS_INITIALIZED;
> }
>
> /**
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
> b/drivers/gpu/drm/i915/display/intel_display_power.h
> index 2154d900b1aad..0d9aba94bae01 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.h
> @@ -133,7 +133,11 @@ struct i915_power_domains {
>* Power wells needed for initialization at driver init and suspend
>* time are on. They are kept on until after the first modeset.
>*/
> - bool initializing;
> + enum {
> + I915_POWER_DOMAINS_UNINITIALIZED,
> + I915_POWER_DOMAINS_INITIALIZING,
> + I915_POWER_DOMAINS_INITIALIZED,
> + } init_state;
> bool display_core_suspended;
> int power_well_count;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> index 8710dd41ffd4c..66df7a733afb9 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
> @@ -1208,7 +1208,7 @@ static void vlv_display_power_well_init(struct
> drm_i915_private *dev_priv)
>* During driver initialization/resume we can avoid restoring the
>* part of the HW/SW state that will be inited anyway explicitly.
>*/
> - if (dev_priv->display.power.domains.initializing)
> + if (dev_priv->display.power.domains.init_state <
> I915_POWER_DOMAINS_INITIALIZED)
> return;
>
> intel_hpd_init(dev_priv);
>
>> I approve of the change, but I can't in good faith claim I checked this.
>>
>> Acked-by: Jani Nikula
>>
>>
>> > Signed-off-by: Imre Deak
>> > ---
>> > drivers/gpu/drm/i915/display/intel_display.c | 5 +
>> > drivers/gpu/drm/i915/i915_driver.c | 7 ---
>> > 2 files changed, 5 insertions(+), 7 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> > b/drivers/gpu/drm/i915/display/intel_display.c
>> > index 12ade593c..b3e7ed3866cde 100644
>> > --- a/drivers/gpu/drm/i915/display/intel_display.c
>> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> > @@ -8634,6
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: Communicate display configuration to pcode (rev3)
== Series Details == Series: drm/i915/display: Communicate display configuration to pcode (rev3) URL : https://patchwork.freedesktop.org/series/102678/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: Move display power initialization during driver probing later
On Tue, Feb 14, 2023 at 11:25:04AM +0200, Jani Nikula wrote:
> On Wed, 08 Feb 2023, Imre Deak wrote:
> > Determining whether the display engine is present on a platform happens
> > only in intel_device_info_runtime_init(). Initializing the display power
> > functionality depends on this condition, so move
> > intel_power_domains_init() later after the runtime init function has
> > been called.
> >
> > The next patch fixing platforms without display, depends on this patch.
> >
>
> It's pretty hard to review we aren't using any of the power domain stuff
> before the intel_power_domains_init() call. What happens if we do?
That shouldn't happen before the HW state is read out in
intel_power_domains_init_hw(). I can't see anything calling the display power
get/put/is_enabled functions before that, but it would be good to ensure this.
So how about also adding:
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 7222502a760cc..7014e1770f57a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -213,6 +213,9 @@ bool __intel_display_power_is_enabled(struct
drm_i915_private *dev_priv,
struct i915_power_well *power_well;
bool is_enabled;
+ drm_WARN_ON(_priv->drm,
+ dev_priv->display.power.domains.init_state <
I915_POWER_DOMAINS_INITIALIZING);
+
if (dev_priv->runtime_pm.suspended)
return false;
@@ -488,6 +491,9 @@ __intel_display_power_get_domain(struct drm_i915_private
*dev_priv,
struct i915_power_domains *power_domains =
_priv->display.power.domains;
struct i915_power_well *power_well;
+ drm_WARN_ON(_priv->drm,
+ power_domains->init_state <
I915_POWER_DOMAINS_INITIALIZING);
+
if (intel_display_power_grab_async_put_ref(dev_priv, domain))
return;
@@ -1880,7 +1886,7 @@ void intel_power_domains_init_hw(struct drm_i915_private
*i915, bool resume)
{
struct i915_power_domains *power_domains = >display.power.domains;
- power_domains->initializing = true;
+ power_domains->init_state = I915_POWER_DOMAINS_INITIALIZING;
if (DISPLAY_VER(i915) >= 11) {
icl_display_core_init(i915, resume);
@@ -1924,7 +1930,7 @@ void intel_power_domains_init_hw(struct drm_i915_private
*i915, bool resume)
}
intel_power_domains_sync_hw(i915);
- power_domains->initializing = false;
+ power_domains->init_state = I915_POWER_DOMAINS_INITIALIZED;
}
/**
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.h
b/drivers/gpu/drm/i915/display/intel_display_power.h
index 2154d900b1aad..0d9aba94bae01 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.h
+++ b/drivers/gpu/drm/i915/display/intel_display_power.h
@@ -133,7 +133,11 @@ struct i915_power_domains {
* Power wells needed for initialization at driver init and suspend
* time are on. They are kept on until after the first modeset.
*/
- bool initializing;
+ enum {
+ I915_POWER_DOMAINS_UNINITIALIZED,
+ I915_POWER_DOMAINS_INITIALIZING,
+ I915_POWER_DOMAINS_INITIALIZED,
+ } init_state;
bool display_core_suspended;
int power_well_count;
diff --git a/drivers/gpu/drm/i915/display/intel_display_power_well.c
b/drivers/gpu/drm/i915/display/intel_display_power_well.c
index 8710dd41ffd4c..66df7a733afb9 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power_well.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power_well.c
@@ -1208,7 +1208,7 @@ static void vlv_display_power_well_init(struct
drm_i915_private *dev_priv)
* During driver initialization/resume we can avoid restoring the
* part of the HW/SW state that will be inited anyway explicitly.
*/
- if (dev_priv->display.power.domains.initializing)
+ if (dev_priv->display.power.domains.init_state <
I915_POWER_DOMAINS_INITIALIZED)
return;
intel_hpd_init(dev_priv);
> I approve of the change, but I can't in good faith claim I checked this.
>
> Acked-by: Jani Nikula
>
>
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 5 +
> > drivers/gpu/drm/i915/i915_driver.c | 7 ---
> > 2 files changed, 5 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 12ade593c..b3e7ed3866cde 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -8634,6 +8634,10 @@ int intel_modeset_init_noirq(struct drm_i915_private
> > *i915)
> > goto cleanup_bios;
> >
> > /* FIXME: completely on the wrong abstraction layer */
> > + ret = intel_power_domains_init(i915);
> > + if (ret < 0)
Re: [Intel-gfx] [PATCH] drm/i915/display: Communicate display configuration to pcode
On Tue, Feb 14, 2023 at 12:01:32PM +0200, Stanislav Lisovskiy wrote:
> From: Jigar Bhatt
>
> Display to communicate "display configuration" to Pcode for more accurate
> power accounting for DG2. Existing sequence is only sending the voltage
> value to the Pcode. Adding new sequence with current cdclk associate
> with voltage value masking. Adding pcode request when any power well
> will disable or enable.
>
> v2: - Fixed identation(Stanislav Lisovskiy)
> - Made conditions more specific(in the commit we declare that
> we do this for DG2 only, however that commit changes >= to
> == for many other platforms.(Stanislav Lisovskiy)
>
> v3: - Refactored code for proper identation and smaller conditions
> (Andi Shyti)
> - Switched to proper function naming, removed platform specific
> code from intel_atomic_commit_tail(Jani Nikula)
> - Moved intel_cdclk_power_usage_to_pcode_pre/post_notification
> to proper places, before and after setting CDCLK(Stanislav Lisovskiy)
>
> Signed-off-by: Jigar Bhatt
> Signed-off-by: Stanislav Lisovskiy
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 97 --
> drivers/gpu/drm/i915/display/intel_cdclk.h | 2 +
> drivers/gpu/drm/i915/i915_reg.h| 4 +
> 3 files changed, 94 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index 82da76b586ed..4f8bcc0b51e8 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1908,10 +1908,10 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
>* NOOP - No Pcode communication needed for
>* Display versions 14 and beyond
>*/;
> - else if (DISPLAY_VER(dev_priv) >= 11)
> + else if (DISPLAY_VER(dev_priv) >= 11 && !IS_DG2(dev_priv))
> ret = snb_pcode_write(_priv->uncore,
> SKL_PCODE_CDCLK_CONTROL,
> cdclk_config->voltage_level);
> - else
> + if (DISPLAY_VER(dev_priv) < 11) {
> /*
>* The timeout isn't specified, the 2ms used here is based on
>* experiment.
> @@ -1922,7 +1922,7 @@ static void bxt_set_cdclk(struct drm_i915_private
> *dev_priv,
> HSW_PCODE_DE_WRITE_FREQ_REQ,
> cdclk_config->voltage_level,
> 150, 2);
> -
> + }
> if (ret) {
> drm_err(_priv->drm,
> "PCode CDCLK freq set failed, (err %d, freq %d)\n",
> @@ -2218,6 +2218,29 @@ void intel_cdclk_dump_config(struct drm_i915_private
> *i915,
> cdclk_config->voltage_level);
> }
>
> +static void intel_pcode_notify(struct drm_i915_private *i915,
> +unsigned int cdclk, u8 voltage_level,
> +u8 active_pipes)
> +{
> + int ret;
> +
> + if (DISPLAY_VER(i915) < 12)
> + return;
> +
> + ret = skl_pcode_request(>uncore, SKL_PCODE_CDCLK_CONTROL,
> + SKL_CDCLK_PREPARE_FOR_CHANGE |
Isn't that something we're supposed to set only *before*
the change? Here it looks like we're setting also for the
post call.
> + DISPLAY_TO_PCODE_MASK
> + (cdclk, active_pipes, voltage_level),
> + SKL_CDCLK_READY_FOR_CHANGE,
> + SKL_CDCLK_READY_FOR_CHANGE, 3);
> + if (ret) {
> + drm_err(>drm,
> + "Failed to inform PCU about display config (err
> %d)\n",
> + ret);
> + return;
> + }
> +}
> +
> /**
> * intel_set_cdclk - Push the CDCLK configuration to the hardware
> * @dev_priv: i915 device
> @@ -2287,6 +2310,56 @@ static void intel_set_cdclk(struct drm_i915_private
> *dev_priv,
> }
> }
>
> +/**
> + * intel_cdclk_power_usage_to_pcode_pre_notification: display to pcode
> notification
> + * before the enabling power wells.
> + * send notification with cdclk, number of pipes, voltage_level.
> + * @state: intel atomic state
> + */
> +void intel_cdclk_power_usage_to_pcode_pre_notification(struct
> intel_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> + const struct intel_cdclk_state *old_cdclk_state =
> + intel_atomic_get_old_cdclk_state(state);
> + const struct intel_cdclk_state *new_cdclk_state =
> + intel_atomic_get_new_cdclk_state(state);
> + if (!intel_cdclk_changed(_cdclk_state->actual,
> + _cdclk_state->actual) &&
> + (new_cdclk_state->active_pipes ==
> + old_cdclk_state->active_pipes))
> + return;
> + else if
[Intel-gfx] [PATCH 3/3] drm/i915: Clean up g4x+ sprite TILEOFF programming
From: Ville Syrjälä We defined the bitmasks for DVSTILEOFF but never used them. Remedy that. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_sprite.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c index e6b4d24b9cd0..a16e56a60c30 100644 --- a/drivers/gpu/drm/i915/display/intel_sprite.c +++ b/drivers/gpu/drm/i915/display/intel_sprite.c @@ -1217,7 +1217,8 @@ g4x_sprite_update_arm(struct intel_plane *plane, } intel_de_write_fw(dev_priv, DVSLINOFF(pipe), linear_offset); - intel_de_write_fw(dev_priv, DVSTILEOFF(pipe), (y << 16) | x); + intel_de_write_fw(dev_priv, DVSTILEOFF(pipe), + DVS_OFFSET_Y(y) | DVS_OFFSET_X(x)); /* * The control register self-arms if the plane was previously -- 2.39.1
[Intel-gfx] [PATCH 2/3] drm/i915: Don't hide function calls with side effects
From: Ville Syrjälä
Hiding a function call with side effects inside the
variable declaration block is a bit rude. Make it
stand out more.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_backlight.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index d1d54870aefd..e196da8c8f71 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -1614,8 +1614,9 @@ static void intel_pwm_disable_backlight(const struct
drm_connector_state *conn_s
static int intel_pwm_setup_backlight(struct intel_connector *connector, enum
pipe pipe)
{
struct intel_panel *panel = >panel;
- int ret = panel->backlight.pwm_funcs->setup(connector, pipe);
+ int ret;
+ ret = panel->backlight.pwm_funcs->setup(connector, pipe);
if (ret < 0)
return ret;
--
2.39.1
[Intel-gfx] [PATCH 1/3] drm/i915: Make backlight setup debugs consistent
From: Ville Syrjälä
It's confusing to debug backlight issues when one can't
easily even tell what kind of backlight control was
selected. Sprinkle uniform debug messages to all the
backlight setup functions.
Also the one that was already there (ext_pwm) was
using drm_info() for some reason. I don't think that's
warranted so switch it to drm_dbg_kms() as well.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_backlight.c| 36 +--
.../i915/display/intel_dsi_dcs_backlight.c| 5 +++
2 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c
b/drivers/gpu/drm/i915/display/intel_backlight.c
index a4e4b7f79e4d..d1d54870aefd 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -1270,6 +1270,10 @@ static int lpt_setup_backlight(struct intel_connector
*connector, enum pipe unus
cpu_ctl2 & ~BLM_PWM_ENABLE);
}
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s] Using native PCH PWM for backlight
control\n",
+ connector->base.base.id, connector->base.name);
+
return 0;
}
@@ -1297,6 +1301,10 @@ static int pch_setup_backlight(struct intel_connector
*connector, enum pipe unus
panel->backlight.pwm_enabled = (cpu_ctl2 & BLM_PWM_ENABLE) &&
(pch_ctl1 & BLM_PCH_PWM_ENABLE);
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s] Using native PCH PWM for backlight
control\n",
+ connector->base.base.id, connector->base.name);
+
return 0;
}
@@ -1335,6 +1343,10 @@ static int i9xx_setup_backlight(struct intel_connector
*connector, enum pipe unu
panel->backlight.pwm_enabled = val != 0;
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s] Using native PWM for backlight
control\n",
+ connector->base.base.id, connector->base.name);
+
return 0;
}
@@ -1364,6 +1376,10 @@ static int i965_setup_backlight(struct intel_connector
*connector, enum pipe unu
panel->backlight.pwm_enabled = ctl2 & BLM_PWM_ENABLE;
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s] Using native PWM for backlight
control\n",
+ connector->base.base.id, connector->base.name);
+
return 0;
}
@@ -1392,6 +1408,10 @@ static int vlv_setup_backlight(struct intel_connector
*connector, enum pipe pipe
panel->backlight.pwm_enabled = ctl2 & BLM_PWM_ENABLE;
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s] Using native PWM for backlight
control\n",
+ connector->base.base.id, connector->base.name);
+
return 0;
}
@@ -1428,6 +1448,11 @@ bxt_setup_backlight(struct intel_connector *connector,
enum pipe unused)
panel->backlight.pwm_enabled = pwm_ctl & BXT_BLC_PWM_ENABLE;
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s] Using native PWM for backlight control
(controller=%d)\n",
+ connector->base.base.id, connector->base.name,
+ panel->backlight.controller);
+
return 0;
}
@@ -1490,6 +1515,11 @@ cnp_setup_backlight(struct intel_connector *connector,
enum pipe unused)
panel->backlight.pwm_enabled = pwm_ctl & BXT_BLC_PWM_ENABLE;
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s] Using native PCH PWM for backlight
control (controller=%d)\n",
+ connector->base.base.id, connector->base.name,
+ panel->backlight.controller);
+
return 0;
}
@@ -1538,8 +1568,10 @@ static int ext_pwm_setup_backlight(struct
intel_connector *connector,
NSEC_PER_SEC / get_vbt_pwm_freq(connector);
}
- drm_info(>drm, "Using %s PWM for LCD backlight control\n",
-desc);
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s] Using %s PWM for backlight control\n",
+ connector->base.base.id, connector->base.name, desc);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
index 20e466d843ce..049443245310 100644
--- a/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dsi_dcs_backlight.c
@@ -162,6 +162,7 @@ static void dcs_enable_backlight(const struct
intel_crtc_state *crtc_state,
static int dcs_setup_backlight(struct intel_connector *connector,
enum pipe unused)
{
+ struct drm_i915_private *i915 = to_i915(connector->base.dev);
struct intel_panel *panel = >panel;
if (panel->vbt.backlight.brightness_precision_bits > 8)
@@ -171,6 +172,10 @@ static int dcs_setup_backlight(struct intel_connector
*connector,
panel->backlight.level = panel->backlight.max;
+ drm_dbg_kms(>drm,
+ "[CONNECTOR:%d:%s]
[Intel-gfx] [PATCH 3/3] drm/i915: Fix idle pattern enabling
From: Ville Syrjälä
Currently we are always switching to the idle pattern after the
link training, but we don't always wait for the minimum number
of idle patterns sent. That doesn't look to be what Bspec
asks of us.
According to bspec what we should do is switch to idle pattern
and wait for it only in DP1.4 MST cases. In all other cases we
should apparently do neither.
What confuses matters further is that the port sync SST sequence
asks us to "stay in idle pattern". But if we never switched to it
how can we stay in it? This still needs further clarificaiton.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 4af2ba2dfcad..a3466b71d18a 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3219,24 +3219,22 @@ static void intel_ddi_set_idle_link_train(struct
intel_dp *intel_dp,
{
struct intel_encoder *encoder = _to_dig_port(intel_dp)->base;
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- enum port port = encoder->port;
u32 val;
+ /*
+* FIXME DP modeset sequence says to switch to idle pattern
+* only for DP1.4 MST cases, but port sync SST sequence asks
+* us to "stay in Idle Pattern", implying that we should
+* switch to it earlier. Which is it?
+*/
+ if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_DP_MST))
+ return;
+
val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder, crtc_state));
val &= ~DP_TP_CTL_LINK_TRAIN_MASK;
val |= DP_TP_CTL_LINK_TRAIN_IDLE;
intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state), val);
- /*
-* Until TGL on PORT_A we can have only eDP in SST mode. There the only
-* reason we need to set idle transmission mode is to work around a HW
-* issue where we enable the pipe while not in idle link-training mode.
-* In this case there is requirement to wait for a minimum number of
-* idle patterns to be sent.
-*/
- if (port == PORT_A && DISPLAY_VER(dev_priv) < 12)
- return;
-
if (intel_de_wait_for_set(dev_priv,
dp_tp_status_reg(encoder, crtc_state),
DP_TP_STATUS_IDLE_DONE, 1))
--
2.39.1
[Intel-gfx] [PATCH 2/3] drm/i915: Don't send idle pattern after DP2.0 link training
From: Ville Syrjälä Bspec calls us to select pattern 2 after link training for DP 2.0. Let's do that... by doing nothing because we will be transmitting pattern 2 at the end of the link training already. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_dp_link_training.c | 4 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.c b/drivers/gpu/drm/i915/display/intel_dp_link_training.c index 3d3efcf02011..b35af21a2761 100644 --- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c +++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c @@ -1379,10 +1379,6 @@ intel_dp_128b132b_lane_cds(struct intel_dp *intel_dp, } } - /* FIXME: Should DP_TRAINING_PATTERN_DISABLE be written first? */ - if (intel_dp->set_idle_link_train) - intel_dp->set_idle_link_train(intel_dp, crtc_state); - return true; } -- 2.39.1
[Intel-gfx] [PATCH 1/3] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL
From: Ville Syrjälä
AFAICS Bspec has never asked us to switch to TPS1 when *disabling*
DP_TP_CTL. Let's stop doing that in case it confuses something.
We do have to switch before we *enable* DP_TP_CTL, but that
is already being handled correctly.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index bfd1e30a27b4..4af2ba2dfcad 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2624,8 +2624,7 @@ static void intel_disable_ddi_buf(struct intel_encoder
*encoder,
if (intel_crtc_has_dp_encoder(crtc_state)) {
val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder,
crtc_state));
- val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
- val |= DP_TP_CTL_LINK_TRAIN_PAT1;
+ val &= ~DP_TP_CTL_ENABLE;
intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state),
val);
}
@@ -3153,8 +3152,7 @@ static void intel_ddi_prepare_link_retrain(struct
intel_dp *intel_dp,
wait = true;
}
- dp_tp_ctl &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
- dp_tp_ctl |= DP_TP_CTL_LINK_TRAIN_PAT1;
+ dp_tp_ctl &= ~DP_TP_CTL_ENABLE;
intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state),
dp_tp_ctl);
intel_de_posting_read(dev_priv, dp_tp_ctl_reg(encoder,
crtc_state));
--
2.39.1
Re: [Intel-gfx] [PATCH] drm/i915/display/selftest: Add pcode selftest
On Tue, 07 Feb 2023, Swati Sharma wrote:
> From: Mohammed Khajapasha
>
> Include pcode selftest for display to validate QGV points read.
> Failure of this selftest indicates a bad firmware rather than regular
> display issue.
>
> Cc: Stanislav Lisovskiy
> Cc: Matt Roper
> Signed-off-by: Mohammed Khajapasha
> Signed-off-by: Swati Sharma
> ---
> drivers/gpu/drm/i915/Makefile | 3 +-
> drivers/gpu/drm/i915/display/intel_bw.c | 4 ++
> .../drm/i915/display/selftests/selftest_bw.c | 54 +++
> .../i915/display/selftests/selftest_display.c | 18 +++
> .../i915/display/selftests/selftest_display.h | 6 +++
> .../drm/i915/selftests/i915_live_selftests.h | 1 +
> 6 files changed, 85 insertions(+), 1 deletion(-)
> create mode 100644 drivers/gpu/drm/i915/display/selftests/selftest_bw.c
> create mode 100644 drivers/gpu/drm/i915/display/selftests/selftest_display.c
> create mode 100644 drivers/gpu/drm/i915/display/selftests/selftest_display.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 918470a04591..aa7d34b3f71c 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -350,7 +350,8 @@ i915-$(CONFIG_DRM_I915_SELFTEST) += \
> selftests/igt_mmap.o \
> selftests/igt_reset.o \
> selftests/igt_spinner.o \
> - selftests/librapl.o
> + selftests/librapl.o \
> + display/selftests/selftest_display.o
I think we'll want to start adding display selftests under a separate
Kconfig, and in separate build lists. CONFIG_DRM_I915_DISPLAY_SELFTEST
maybe.
>
> # virtual gpu code
> i915-y += i915_vgpu.o
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 202321ffbe2a..b0bfe04f2835 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -1211,3 +1211,7 @@ int intel_bw_init(struct drm_i915_private *dev_priv)
>
> return 0;
> }
> +
> +#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
> +#include "selftests/selftest_bw.c"
> +#endif
Why here, why bw?
> diff --git a/drivers/gpu/drm/i915/display/selftests/selftest_bw.c
> b/drivers/gpu/drm/i915/display/selftests/selftest_bw.c
> new file mode 100644
> index ..69d52201bd9b
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/selftests/selftest_bw.c
bw?
> @@ -0,0 +1,54 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2020 Intel Corporation
Year.
> + */
> +
> +#include "display/intel_bw.h"
> +#include "i915_drv.h"
> +#include "i915_selftest.h"
> +#include "soc/intel_dram.h"
> +#include "selftest_display.h"
Please keep these sorted.
> +
> +/**
> + * intel_pcode_read_qgv_points_read_test - Test QGV point reads from pcode
> + * @arg: i915 device instance
> + *
> + * Return 0 on success and error on fail and when dclk is zero
> + */
> +int intel_pcode_read_qgv_points_test(void *arg)
> +{
> + struct drm_i915_private *i915 = arg;
> + struct intel_qgv_info qi;
> + struct intel_qgv_point qp;
> + int i, ret;
> + bool fail = false;
> + intel_wakeref_t wakeref;
> +
> + if (DISPLAY_VER(i915) < 11) {
> + drm_info(>drm, "QGV doesn't support, skipping\n");
> + return 0;
> + }
> +
> + with_intel_runtime_pm(i915->uncore.rpm, wakeref)
> + intel_dram_detect(i915);
> +
> + qi.num_points = i915->dram_info.num_qgv_points;
Not entirely happy about sprinkling new dram_info access outside of
intel_dram.c. I'd rather we moved in the other direction. So maybe the
whole thing should be in intel_dram.
Which kind of makes this selftest not about display too, but rather the
"soc" stuff.
> +
> + for (i = 0; i < qi.num_points; i++) {
> + ret = intel_read_qgv_point_info(i915, , i);
> + if (ret) {
> + drm_err(>drm, "Pcode failed to read qgv point
> %d\n", i);
> + fail = true;
> + }
> +
> + if (qp.dclk == 0) {
> + drm_err(>drm, "DCLK set to 0 for qgv point %d\n",
> i);
> + fail = true;
> + }
> + }
> +
> + if (fail)
> + return -EINVAL;
> +
> + return 0;
> +}
> diff --git a/drivers/gpu/drm/i915/display/selftests/selftest_display.c
> b/drivers/gpu/drm/i915/display/selftests/selftest_display.c
> new file mode 100644
> index ..1663c69f9ddc
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/selftests/selftest_display.c
> @@ -0,0 +1,18 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2020 Intel Corporation
Year.
> + */
> +
> +#include "i915_drv.h"
> +#include "i915_selftest.h"
> +
> +#include "selftest_display.h"
> +
> +int intel_display_live_selftests(struct drm_i915_private *i915)
What's with the "live" here?
> +{
> + static const struct i915_subtest tests[] = {
> + SUBTEST(intel_pcode_read_qgv_points_test),
> + };
> +
> + return
Re: [Intel-gfx] [PATCH] drm/i915/display: Add a debugfs entry for fifo underruns
On Wed, 08 Feb 2023, Andi Shyti wrote:
> Hi Swati,
>
> [...]
>
>> +static void intel_fifo_underrun_inc_count(struct intel_crtc *crtc,
>> + bool is_cpu_fifo)
>
> I'm not a big fan of the true/false parameters in functions. I
> actually hate them because it's never clear from the caller what
> the true/false means.
>
> Isn't it clear to just have some wrappers
>
> #define intel_fifo_underrun_inc_cpu_count(...)
> #define intel_fifo_underrun_inc_cph_count(...)
>
> or similar?
>
>> +{
>> +#ifdef CONFIG_DEBUG_FS
>> +if (is_cpu_fifo)
>> +crtc->cpu_fifo_underrun_count++;
>> +else
>> +crtc->pch_fifo_underrun_count++;
>> +#endif
>> +}
>> +
>> static void i9xx_check_fifo_underruns(struct intel_crtc *crtc)
>> {
>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> @@ -103,6 +114,7 @@ static void i9xx_check_fifo_underruns(struct intel_crtc
>> *crtc)
>> intel_de_write(dev_priv, reg, enable_mask | PIPE_FIFO_UNDERRUN_STATUS);
>> intel_de_posting_read(dev_priv, reg);
>>
>> +intel_fifo_underrun_inc_count(crtc, true);
>> trace_intel_cpu_fifo_underrun(dev_priv, crtc->pipe);
>> drm_err(_priv->drm, "pipe %c underrun\n", pipe_name(crtc->pipe));
>> }
>> @@ -156,6 +168,7 @@ static void ivb_check_fifo_underruns(struct intel_crtc
>> *crtc)
>> intel_de_write(dev_priv, GEN7_ERR_INT, ERR_INT_FIFO_UNDERRUN(pipe));
>> intel_de_posting_read(dev_priv, GEN7_ERR_INT);
>>
>> +intel_fifo_underrun_inc_count(crtc, true);
>> trace_intel_cpu_fifo_underrun(dev_priv, pipe);
>> drm_err(_priv->drm, "fifo underrun on pipe %c\n", pipe_name(pipe));
>> }
>> @@ -244,6 +257,7 @@ static void cpt_check_pch_fifo_underruns(struct
>> intel_crtc *crtc)
>> SERR_INT_TRANS_FIFO_UNDERRUN(pch_transcoder));
>> intel_de_posting_read(dev_priv, SERR_INT);
>>
>> +intel_fifo_underrun_inc_count(crtc, false);
>> trace_intel_pch_fifo_underrun(dev_priv, pch_transcoder);
>> drm_err(_priv->drm, "pch fifo underrun on pch transcoder %c\n",
>> pipe_name(pch_transcoder));
>> @@ -286,6 +300,11 @@ static bool
>> __intel_set_cpu_fifo_underrun_reporting(struct drm_device *dev,
>>
>> old = !crtc->cpu_fifo_underrun_disabled;
>> crtc->cpu_fifo_underrun_disabled = !enable;
>> +#ifdef CONFIG_DEBUG_FS
>> +/* don't reset count in fifo underrun irq path */
>> +if (!in_irq() && !enable)
>> +crtc->cpu_fifo_underrun_count = 0;
>> +#endif
>>
>> if (HAS_GMCH(dev_priv))
>> i9xx_set_fifo_underrun_reporting(dev, pipe, enable, old);
>> @@ -365,6 +384,11 @@ bool intel_set_pch_fifo_underrun_reporting(struct
>> drm_i915_private *dev_priv,
>>
>> old = !crtc->pch_fifo_underrun_disabled;
>> crtc->pch_fifo_underrun_disabled = !enable;
>> +#ifdef CONFIG_DEBUG_FS
>> +/* don't reset count in fifo underrun irq path */
>> +if (!in_irq() && !enable)
>> +crtc->pch_fifo_underrun_count = 0;
>> +#endif
>
> All these ifdefs are a bit ugly. Can we put all these stuff
> inside the debugfs.c file that is compiled only if DEBUG_FS is
> configured?
The opposite, the debugfs should be added in this file instead. :)
See my reply.
BR,
Jani.
>
> Andi
>
>>
>> if (HAS_PCH_IBX(dev_priv))
>> ibx_set_fifo_underrun_reporting(_priv->drm,
>> @@ -434,6 +458,7 @@ void intel_cpu_fifo_underrun_irq_handler(struct
>> drm_i915_private *dev_priv,
>> drm_err(_priv->drm, "CPU pipe %c FIFO underrun\n",
>> pipe_name(pipe));
>> }
>>
>> +intel_fifo_underrun_inc_count(crtc, true);
>> intel_fbc_handle_fifo_underrun_irq(dev_priv);
>> }
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/display: Add a debugfs entry for fifo underruns
On Wed, 08 Feb 2023, Swati Sharma wrote:
> From: Mohammed Khajapasha
>
> Add a debugfs entry i915_fifo_underruns to indicate the count of
> fifo underruns for each pipe.
>
> Cc: Stanislav Lisovskiy
> Signed-off-by: Mohammed Khajapasha
> Signed-off-by: Swati Sharma
> ---
> .../drm/i915/display/intel_display_debugfs.c | 28 ++
> .../drm/i915/display/intel_display_types.h| 2 ++
> .../drm/i915/display/intel_fifo_underrun.c| 29 +++
> 3 files changed, 59 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 9e2fb8626c96..d64b4675766c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -9,6 +9,7 @@
> #include
>
> #include "i915_debugfs.h"
> +#include "intel_crtc.h"
> #include "i915_irq.h"
> #include "i915_reg.h"
> #include "intel_de.h"
> @@ -1057,6 +1058,32 @@ static int i915_lpsp_status(struct seq_file *m, void
> *unused)
> return 0;
> }
>
> +static int i915_fifo_underruns(struct seq_file *m, void *unused)
> +{
> + struct drm_i915_private *dev_priv = node_to_i915(m->private);
> + struct intel_crtc *crtc;
> + enum pipe pipe;
> + unsigned long flags;
> + u32 cpu_fifo_underrun_count[I915_MAX_PIPES];
> + u32 pch_fifo_underrun_count[I915_MAX_PIPES];
> +
> + spin_lock_irqsave(_priv->irq_lock, flags);
> + for_each_pipe(dev_priv, pipe) {
> + crtc = intel_crtc_for_pipe(dev_priv, pipe);
See the implementation of intel_crtc_for_pipe(). Looping over pipes and
then converting to crtcs is not great.
> + cpu_fifo_underrun_count[pipe] = crtc->cpu_fifo_underrun_count;
> + pch_fifo_underrun_count[pipe] = crtc->pch_fifo_underrun_count;
> + }
> + spin_unlock_irqrestore(_priv->irq_lock, flags);
> +
> + seq_printf(m, "\t%-10s \t%10s\n", "cpu fifounderruns", "pch
> fifounderruns");
> + for_each_pipe(dev_priv, pipe)
> + seq_printf(m, "pipe:%c %10u %20u\n", pipe_name(pipe),
> +cpu_fifo_underrun_count[pipe],
> +pch_fifo_underrun_count[pipe]);
I would replace all of the above with a single for_each_intel_crtc()
loop, and ditch the local count arrays here. I'm not sure we care about
the counts being in sync across crtcs i.e. no need to take the irq lock
across the whole loop.
...
No wait. I think I'd actually replace all of that with a *crtc* specific
debugfs file instead. See below.
> +
> + return 0;
> +}
> +
> static int i915_dp_mst_info(struct seq_file *m, void *unused)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -1586,6 +1613,7 @@ static const struct drm_info_list
> intel_display_debugfs_list[] = {
> {"i915_dp_mst_info", i915_dp_mst_info, 0},
> {"i915_ddb_info", i915_ddb_info, 0},
> {"i915_lpsp_status", i915_lpsp_status, 0},
> + {"i915_fifo_underruns", i915_fifo_underruns, 0},
The direction now is to add debugfs files next to the implementation.
So with the crtc specific files, you'd add
void intel_fifo_underrun_debugfs_add(struct intel_crtc *crtc)
in intel_fifo_underrun.[ch] and call that from intel_crtc_debugfs_add().
It handles exactly one crtc. See for example
intel_drrs_crtc_debugfs_add().
> };
>
> static const struct {
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 9ccae7a46020..b0468ac70059 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1438,6 +1438,8 @@ struct intel_crtc {
>
> #ifdef CONFIG_DEBUG_FS
> struct intel_pipe_crc pipe_crc;
> + u32 cpu_fifo_underrun_count;
> + u32 pch_fifo_underrun_count;
> #endif
> };
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> index d636d21fa9ce..7131dd400ac3 100644
> --- a/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> +++ b/drivers/gpu/drm/i915/display/intel_fifo_underrun.c
> @@ -88,6 +88,17 @@ static bool cpt_can_enable_serr_int(struct drm_device *dev)
> return true;
> }
>
> +static void intel_fifo_underrun_inc_count(struct intel_crtc *crtc,
> + bool is_cpu_fifo)
What Andy said, but please don't add #defines, just add two separate
functions like:
intel_cpu_fifo_underrun_count_inc()
intel_pch_fifo_underrun_count_inc()
Those go hand in hand with:
intel_cpu_fifo_underrun_count_reset()
intel_pch_fifo_underrun_count_reset()
which we'll also need instead of messing with the counts directly in
some places and via accessors in some others.
> +{
> +#ifdef CONFIG_DEBUG_FS
The #ifdefs go outside the function. See coding-style.rst.
> + if (is_cpu_fifo)
> + crtc->cpu_fifo_underrun_count++;
> + else
> +
Re: [Intel-gfx] [PATCH v9 5/7] drm/i915: Fill in native_420 field
On Tue, 07 Feb 2023, Suraj Kandpal wrote:
> Now that we have laid the groundwork for YUV420 Enablement
> we fill up native_420 field in vdsc_cfg and add appropriate
> checks wherever required.
>
> ---v2
> -adding native_422 field as 0 [Vandita]
> -filling in second_line_bpg_offset, second_line_offset_adj
> and nsl_bpg_offset in vds_cfg when native_420 is true
>
> ---v3
> -adding display version check to solve igt issue
>
> --v7
> -remove is_pipe_dsc check as its always true for D14 [Jani]
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
> drivers/gpu/drm/i915/display/intel_dp.c | 3 -
> drivers/gpu/drm/i915/display/intel_vdsc.c | 72 ++-
> 3 files changed, 69 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index 003cac918228..f8c999fa3242 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -1534,8 +1534,6 @@ static int gen11_dsi_dsc_compute_config(struct
> intel_encoder *encoder,
> if (crtc_state->dsc.slice_count > 1)
> crtc_state->dsc.dsc_split = true;
>
> - vdsc_cfg->convert_rgb = true;
> -
> /* FIXME: initialize from VBT */
> vdsc_cfg->rc_model_size = DSC_RC_MODEL_SIZE_CONST;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 73a7baccd7d0..250d9cdd14b8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -1470,9 +1470,6 @@ static int intel_dp_dsc_compute_params(struct
> intel_encoder *encoder,
> min(intel_dp_source_dsc_version_minor(intel_dp),
> intel_dp_sink_dsc_version_minor(intel_dp));
>
> - vdsc_cfg->convert_rgb = intel_dp->dsc_dpcd[DP_DSC_DEC_COLOR_FORMAT_CAP
> - DP_DSC_SUPPORT] &
> - DP_DSC_RGB;
Are the sink caps taken into account somewhere else?
> -
> line_buf_depth = drm_dp_dsc_sink_line_buf_depth(intel_dp->dsc_dpcd);
> if (!line_buf_depth) {
> drm_dbg_kms(>drm,
> diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
> b/drivers/gpu/drm/i915/display/intel_vdsc.c
> index ed16f63d6355..13ad853e24eb 100644
> --- a/drivers/gpu/drm/i915/display/intel_vdsc.c
> +++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
> @@ -460,14 +460,47 @@ int intel_dsc_compute_params(struct intel_crtc_state
> *pipe_config)
> vdsc_cfg->pic_width = pipe_config->hw.adjusted_mode.crtc_hdisplay;
> vdsc_cfg->slice_width = DIV_ROUND_UP(vdsc_cfg->pic_width,
>pipe_config->dsc.slice_count);
> -
> - /* Gen 11 does not support YCbCr */
> + /*
> + * According to DSC 1.2 specs if colorspace is YCbCr then convert_rgb
> is 0
> + * else 1
> + */
> + vdsc_cfg->convert_rgb = !(pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR420 ||
> + pipe_config->output_format ==
> INTEL_OUTPUT_FORMAT_YCBCR444);
Nitpick, IMO "format != x && format != y" reads better than "!(format ==
x || format == y)"
> +
> + if (pipe_config->output_format == INTEL_OUTPUT_FORMAT_YCBCR420)
> + vdsc_cfg->native_420 = true;
> + /* We do not support YcBCr422 as of now */
> + vdsc_cfg->native_422 = false;
> + /* Gen 11 does not support YCbCr422 */
> vdsc_cfg->simple_422 = false;
> /* Gen 11 does not support VBR */
> vdsc_cfg->vbr_enable = false;
>
> /* Gen 11 only supports integral values of bpp */
> vdsc_cfg->bits_per_pixel = compressed_bpp << 4;
> + /*
> + * According to DSC 1.2 specs if native_420 is set:
> + * -We need to double the current bpp.
> + * -second_line_bpg_offset is 12 in general and equal to
> 2*(slice_height-1) if slice
> + * height < 8.
> + * -second_line_offset_adj is 512 as shown by emperical values to yeild
> best chroma
> + * preservation in second line.
> + * -nsl_bpg_offset is calculated as second_line_offset/slice_height -1
> then rounded
> + * up to 16 fractional bits, we left shift second line offset by 11 to
> preserve 11
> + * fractional bits.
> + */
> + if (vdsc_cfg->native_420) {
> + vdsc_cfg->bits_per_pixel <<= 1;
> + if (vdsc_cfg->slice_height >= 8)
> + vdsc_cfg->second_line_bpg_offset = 12;
> + else
> + vdsc_cfg->second_line_bpg_offset =
> + 2 * (vdsc_cfg->slice_height - 1);
> + vdsc_cfg->second_line_offset_adj = 512;
> + vdsc_cfg->nsl_bpg_offset =
> DIV_ROUND_UP(vdsc_cfg->second_line_bpg_offset << 11,
> + vdsc_cfg->slice_height
> - 1);
> + }
> +
> vdsc_cfg->bits_per_component = pipe_config->pipe_bpp / 3;
>
> for (i = 0; i < DSC_NUM_BUF_RANGES - 1; i++) {
> @@ -594,8
Re: [Intel-gfx] [PATCH v3 2/3] drm/i915/display: debugfs entry to control ignore long hpd flag
On Tue, 07 Feb 2023, Vinod Govindapillai wrote:
> Knob to control ignoring the long hpds. Set this to true will
> start ignoring the long HPDs generated by the displays. Useful
> for use cases like CI systems where we dont expect to disconnect
> the panels.
>
> v2: Address patch styling comments (Jani Nikula)
>
> Signed-off-by: Vinod Govindapillai
> ---
> drivers/gpu/drm/i915/display/intel_hotplug.c | 25
> 1 file changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c
> b/drivers/gpu/drm/i915/display/intel_hotplug.c
> index f0a2aa648bb8..41372a10288c 100644
> --- a/drivers/gpu/drm/i915/display/intel_hotplug.c
> +++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
> @@ -939,6 +939,29 @@ static const struct file_operations
> i915_hpd_short_storm_ctl_fops = {
> .write = i915_hpd_short_storm_ctl_write,
> };
>
> +static int i915_ignore_long_hpd_set(void *data, u64 val)
> +{
> + struct drm_i915_private *i915 = data;
> +
> + drm_dbg_kms(>drm, "Ignoring long HPDs: %s\n", str_yes_no(val));
> +
> + i915->display.hotplug.ignore_long_hpd = val;
> +
> + return 0;
> +}
> +
> +static int i915_ignore_long_hpd_get(void *data, u64 *val)
> +{
> + struct drm_i915_private *i915 = data;
> +
> + *val = i915->display.hotplug.ignore_long_hpd;
> +
> + return 0;
> +}
> +
> +DEFINE_SIMPLE_ATTRIBUTE(i915_ignore_long_hpd_fops, i915_ignore_long_hpd_get,
> + i915_ignore_long_hpd_set, "%llu\n");
> +
> void intel_hpd_debugfs_register(struct drm_i915_private *i915)
> {
> struct drm_minor *minor = i915->drm.primary;
> @@ -947,4 +970,6 @@ void intel_hpd_debugfs_register(struct drm_i915_private
> *i915)
> i915, _hpd_storm_ctl_fops);
> debugfs_create_file("i915_hpd_short_storm_ctl", 0644,
> minor->debugfs_root,
> i915, _hpd_short_storm_ctl_fops);
> + debugfs_create_file("i915_ignore_long_hpd", 0644, minor->debugfs_root,
> + i915, _ignore_long_hpd_fops);
See debugfs_create_bool(). This whole patch becomes so simple that
should be part of the previous patch, really.
> }
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce plane SIZE_HINTS property
On Tue, Feb 14, 2023 at 01:17:45PM +0200, Pekka Paalanen wrote: > On Tue, 14 Feb 2023 12:27:45 +0200 > Ville Syrjälä wrote: > > > On Tue, Feb 14, 2023 at 11:42:27AM +0200, Pekka Paalanen wrote: > > > On Thu, 9 Feb 2023 13:51:05 +0200 > > > Pekka Paalanen wrote: > > > > > > > Maybe we could refine this so that userspace uses the stride and height > > > > implied by the caps for allocation, and then use the exact cursor image > > > > size for AddFB2? And have drivers pick any size between those two they > > > > can use. The kernel would need the userspace to promise that the > > > > padding is always zero-initialized, so the driver can simply scan out > > > > any area of the buffer it needs. > > > > > > > > Then we don't need SIZE_HINTS. > > > > > > Would there be any problem with this? > > > > > > If this works, it would seem the superior solution to me, because > > > userspace does not need to guess or test for the exact right size. > > > Simply allocate at the CAP size, pad the cursor image with transparent > > > pixels, and let the kernel scan out the optimal area. > > > > No, the hardware cannot scan out a smaller area because the > > stride will be wrong. > > In another email of yours you said that hardware requires stride to be > equivalent to the width. So it's not that hardware supports only > specific strides, it must equal to width. That's really unfortunate and > surprising. Yeah, probably some Windows legacy hangover that refuses to die. Ye olde Intel gen2 desktop chipsets (i845/i865) had a somewhat programmable stride for cursors (still POT, but could exceed the width), but the mobile chipsets (i830/i85x) did not. Unfortunately the mobile lineage won out and we've been stuck with this limitation ever since. -- Ville Syrjälä Intel
