[Intel-gfx] ✗ Fi.CI.BUILD: failure for Change the meaning of the fields in the ttm_place structure from pfn to bytes
== Series Details == Series: Change the meaning of the fields in the ttm_place structure from pfn to bytes URL : https://patchwork.freedesktop.org/series/114603/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/114603/revisions/1/mbox/ not applied Applying: Change the meaning of the fields in the ttm_place structure from pfn to bytes Using index info to reconstruct a base tree... M drivers/gpu/drm/amd/amdgpu/amdgpu_object.c M drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c M drivers/gpu/drm/i915/i915_ttm_buddy_manager.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_ttm_buddy_manager.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_ttm_buddy_manager.c Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c Auto-merging drivers/gpu/drm/amd/amdgpu/amdgpu_object.c CONFLICT (content): Merge conflict in drivers/gpu/drm/amd/amdgpu/amdgpu_object.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 Change the meaning of the fields in the ttm_place structure from pfn to bytes When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH v5 16/19] vfio: Add VFIO_DEVICE_BIND_IOMMUFD
> From: Liu, Yi L
> Sent: Friday, March 3, 2023 2:58 PM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, March 2, 2023 1:47 AM
> >
> > On Wed, Mar 01, 2023 at 09:19:07AM +, Liu, Yi L wrote:
> > > > From: Liu, Yi L
> > > > Sent: Monday, February 27, 2023 7:12 PM
> > > [...]
> > > > +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;
> > > > + 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;
> > >
> > > Hi Jason,
> > >
> > > Per the comment in vfio_iommufd_bind(), such device driver
> > > won't provide .bind_iommufd(). So shall we allow this ioctl
> > > to go longer to call .open_device() instead of failing it here?
> > > I think we need to allow it to go further. E.g. leave the check
> > > to be in vfio_iommufd_bind(). Otherwise, user may not able
> > > to use such devices. Is it?
> >
> > You are thinking about the crazy mdev samples?
> >
> > We should probably just change them to provide a 'no dma' set of ops.
> >
> > > > +struct vfio_device_bind_iommufd {
> > > > + __u32 argsz;
> > > > + __u32 flags;
> > > > + __aligned_u64 dev_cookie;
> > > > + __s32 iommufd;
> > > > + __u32 out_devid;
> > >
> > > As above, for the devices that do not do DMA, there is
> no .bind_iommufd
> > > op, hence no iommufd_device generated. This means no good value
> > > can be filled in this out_devid field. So this field is optional. Only
> > > for the devices which do DMA, should this out_devid field return a
> > > valid ID otherwise an invalid ID would be filled (e.g. value #0 is an
> > > invalid value in the iommufd object id pool). Userspace needs to
> > > check if the out_devid is valid or not before use. This ID can be further
> > > used in iommufd uAPIs like IOMMU_HWPT_ALLOC,
> > IOMMU_DEVICE_GET_INFO
> > > and etc.
> >
> > I would say create an access and harmonize the no-DMA devices with the
> > emulated devices.
>
> How about below change?
>
> diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
> index 4f82a6fa7c6c..e536515086d7 100644
> --- a/drivers/vfio/iommufd.c
> +++ b/drivers/vfio/iommufd.c
> @@ -18,12 +18,8 @@ int vfio_iommufd_bind(struct vfio_device *vdev,
> struct iommufd_ctx *ictx)
>
> lockdep_assert_held(>dev_set->lock);
>
> - /*
> - * If the driver doesn't provide this op then it means the device does
> - * not do DMA at all. So nothing to do.
> - */
> - if (!vdev->ops->bind_iommufd)
> - return 0;
> + if (WARN_ON(!vdev->ops->bind_iommufd))
> + return -ENODEV;
>
> ret = vdev->ops->bind_iommufd(vdev, ictx, _id);
> if (ret)
> @@ -102,7 +98,9 @@
> EXPORT_SYMBOL_GPL(vfio_iommufd_physical_attach_ioas);
> /*
> * The emulated standard ops mean that vfio_device is going to use the
> * "mdev path" and will call vfio_pin_pages()/vfio_dma_rw(). Drivers using
> this
> - * ops set should call vfio_register_emulated_iommu_dev().
> + * ops set should call vfio_register_emulated_iommu_dev(). Drivers that
> do
> + * not call vfio_pin_pages()/vfio_dma_rw() has no need to provide
> dma_unmap
> + * callback.
> */
>
> static void vfio_emulated_unmap(void *data, unsigned long iova,
> @@ -110,7 +107,8 @@ static void vfio_emulated_unmap(void *data,
> unsigned long iova,
> {
> struct vfio_device *vdev = data;
>
> - vdev->ops->dma_unmap(vdev, iova, length);
> + if (vdev->ops->dma_unmap)
> + vdev->ops->dma_unmap(vdev, iova, length);
> }
>
> static const struct iommufd_access_ops vfio_user_ops = {
> diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
> index e54eb752e1ba..19391dda5fba 100644
> --- a/samples/vfio-mdev/mbochs.c
> +++ b/samples/vfio-mdev/mbochs.c
> @@ -1374,6 +1374,9 @@ static const struct vfio_device_ops
> mbochs_dev_ops = {
> .write = mbochs_write,
> .ioctl = mbochs_ioctl,
> .mmap = mbochs_mmap,
> + .bind_iommufd = vfio_iommufd_emulated_bind,
> + .unbind_iommufd = vfio_iommufd_emulated_unbind,
> + .attach_ioas= vfio_iommufd_emulated_attach_ioas,
> };
>
> static struct mdev_driver mbochs_driver = {
> diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
> index e8400fdab71d..5f48aef36995 100644
> --- a/samples/vfio-mdev/mdpy.c
> +++ b/samples/vfio-mdev/mdpy.c
> @@ -663,6 +663,9 @@ static const struct
[Intel-gfx] [PATCH] Change the meaning of the fields in the ttm_place structure from pfn to bytes
Change the ttm_place structure member fpfn, lpfn, mem_type to
res_start, res_end, res_type.
Change the unsigned to u64.
Fix the dependence in all the DRM drivers and
clean up PAGE_SHIFT operation.
Signed-off-by: Somalapuram Amaranath
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 11 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 66 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 22 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_uvd.c | 4 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_vce.c | 17 +--
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c | 40 ---
drivers/gpu/drm/drm_gem_vram_helper.c | 10 +-
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 22 ++--
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
drivers/gpu/drm/i915/i915_ttm_buddy_manager.c | 102 --
drivers/gpu/drm/i915/i915_ttm_buddy_manager.h | 2 +-
drivers/gpu/drm/i915/intel_region_ttm.c | 12 +--
drivers/gpu/drm/nouveau/nouveau_bo.c | 41 +++
drivers/gpu/drm/nouveau/nouveau_mem.c | 10 +-
drivers/gpu/drm/qxl/qxl_object.c | 14 +--
drivers/gpu/drm/qxl/qxl_ttm.c | 8 +-
drivers/gpu/drm/radeon/radeon_object.c| 50 -
drivers/gpu/drm/radeon/radeon_ttm.c | 20 ++--
drivers/gpu/drm/radeon/radeon_uvd.c | 8 +-
drivers/gpu/drm/ttm/ttm_bo.c | 20 ++--
drivers/gpu/drm/ttm/ttm_range_manager.c | 21 ++--
drivers/gpu/drm/ttm/ttm_resource.c| 8 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c| 46
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c| 30 +++---
include/drm/ttm/ttm_placement.h | 12 +--
25 files changed, 293 insertions(+), 305 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
index 44367f03316f..5b5104e724e3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
@@ -131,11 +131,12 @@ static int amdgpu_gtt_mgr_new(struct ttm_resource_manager
*man,
goto err_free;
}
- if (place->lpfn) {
+ if (place->res_end) {
spin_lock(>lock);
r = drm_mm_insert_node_in_range(>mm, >mm_nodes[0],
- num_pages, tbo->page_alignment,
- 0, place->fpfn, place->lpfn,
+ num_pages, tbo->page_alignment,
0,
+ place->res_start << PAGE_SHIFT,
+ place->res_end << PAGE_SHIFT,
DRM_MM_INSERT_BEST);
spin_unlock(>lock);
if (unlikely(r))
@@ -219,7 +220,7 @@ static bool amdgpu_gtt_mgr_intersects(struct
ttm_resource_manager *man,
const struct ttm_place *place,
size_t size)
{
- return !place->lpfn || amdgpu_gtt_mgr_has_gart_addr(res);
+ return !place->res_end || amdgpu_gtt_mgr_has_gart_addr(res);
}
/**
@@ -237,7 +238,7 @@ static bool amdgpu_gtt_mgr_compatible(struct
ttm_resource_manager *man,
const struct ttm_place *place,
size_t size)
{
- return !place->lpfn || amdgpu_gtt_mgr_has_gart_addr(res);
+ return !place->res_end || amdgpu_gtt_mgr_has_gart_addr(res);
}
/**
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 283e8fe608ce..2926389e21d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -130,15 +130,15 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo
*abo, u32 domain)
u32 c = 0;
if (domain & AMDGPU_GEM_DOMAIN_VRAM) {
- unsigned visible_pfn = adev->gmc.visible_vram_size >>
PAGE_SHIFT;
+ u64 visible_pfn = adev->gmc.visible_vram_size;
- places[c].fpfn = 0;
- places[c].lpfn = 0;
- places[c].mem_type = TTM_PL_VRAM;
+ places[c].res_start = 0;
+ places[c].res_end = 0;
+ places[c].res_type = TTM_PL_VRAM;
places[c].flags = 0;
if (flags & AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED)
- places[c].lpfn = visible_pfn;
+ places[c].res_end = visible_pfn;
else
places[c].flags |= TTM_PL_FLAG_TOPDOWN;
@@ -148,9 +148,9 @@ void amdgpu_bo_placement_from_domain(struct amdgpu_bo *abo,
u32 domain)
}
if (domain & AMDGPU_GEM_DOMAIN_GTT) {
- places[c].fpfn = 0;
- places[c].lpfn = 0;
- places[c].mem_type =
+ places[c].res_start = 0;
+ places[c].res_end =
Re: [Intel-gfx] [PATCH] drm/i915/gvt: Make use of idr_find and idr_for_each_entry in dmabuf
On 2023.03.02 19:53:18 +0800, Cai Huoqing wrote:
> This patch uses the already existing IDR mechanism to simplify
> and improve the dmabuf code.
>
> Using 'vgpu.object_idr' directly instead of 'dmabuf_obj_list_head'
> or 'dmabuf.list', because the dmabuf_obj can be found by 'idr_find'
> or 'idr_for_each_entry'.
>
> Signed-off-by: Cai Huoqing
> ---
> drivers/gpu/drm/i915/gvt/dmabuf.c | 69 +++
> drivers/gpu/drm/i915/gvt/dmabuf.h | 1 -
> drivers/gpu/drm/i915/gvt/gvt.h| 1 -
> drivers/gpu/drm/i915/gvt/vgpu.c | 1 -
> 4 files changed, 16 insertions(+), 56 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.c
> b/drivers/gpu/drm/i915/gvt/dmabuf.c
> index 6834f9fe40cf..7933bd843ae8 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.c
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.c
> @@ -133,21 +133,15 @@ static void dmabuf_gem_object_free(struct kref *kref)
> struct intel_vgpu_dmabuf_obj *obj =
> container_of(kref, struct intel_vgpu_dmabuf_obj, kref);
> struct intel_vgpu *vgpu = obj->vgpu;
> - struct list_head *pos;
> struct intel_vgpu_dmabuf_obj *dmabuf_obj;
> + int id;
>
> - if (vgpu && test_bit(INTEL_VGPU_STATUS_ACTIVE, vgpu->status) &&
> - !list_empty(>dmabuf_obj_list_head)) {
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct
> intel_vgpu_dmabuf_obj, list);
> - if (dmabuf_obj == obj) {
> - list_del(pos);
> - idr_remove(>object_idr,
> -dmabuf_obj->dmabuf_id);
> - kfree(dmabuf_obj->info);
> - kfree(dmabuf_obj);
> - break;
> - }
> + if (vgpu && test_bit(INTEL_VGPU_STATUS_ACTIVE, vgpu->status)) {
> + idr_for_each_entry(>object_idr, dmabuf_obj, id) {
> + idr_remove(>object_idr, id);
> + kfree(dmabuf_obj->info);
> + kfree(dmabuf_obj);
This is wrong, it is not to free all dmabuf objects, but just for target one.
> + break;
> }
> } else {
> /* Free the orphan dmabuf_objs here */
> @@ -340,13 +334,11 @@ static struct intel_vgpu_dmabuf_obj *
> pick_dmabuf_by_info(struct intel_vgpu *vgpu,
> struct intel_vgpu_fb_info *latest_info)
> {
> - struct list_head *pos;
> struct intel_vgpu_fb_info *fb_info;
> struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
> - struct intel_vgpu_dmabuf_obj *ret = NULL;
> + int id;
>
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
> list);
> + idr_for_each_entry(>object_idr, dmabuf_obj, id) {
> if (!dmabuf_obj->info)
> continue;
>
> @@ -357,31 +349,11 @@ pick_dmabuf_by_info(struct intel_vgpu *vgpu,
> (fb_info->drm_format_mod == latest_info->drm_format_mod) &&
> (fb_info->drm_format == latest_info->drm_format) &&
> (fb_info->width == latest_info->width) &&
> - (fb_info->height == latest_info->height)) {
> - ret = dmabuf_obj;
> - break;
> - }
Maybe just keep original code's use of extra ret to not include this cumbersome
diff?
> - }
> -
> - return ret;
> -}
> -
> -static struct intel_vgpu_dmabuf_obj *
> -pick_dmabuf_by_num(struct intel_vgpu *vgpu, u32 id)
> -{
> - struct list_head *pos;
> - struct intel_vgpu_dmabuf_obj *dmabuf_obj = NULL;
> - struct intel_vgpu_dmabuf_obj *ret = NULL;
> -
> - list_for_each(pos, >dmabuf_obj_list_head) {
> - dmabuf_obj = list_entry(pos, struct intel_vgpu_dmabuf_obj,
> list);
> - if (dmabuf_obj->dmabuf_id == id) {
> - ret = dmabuf_obj;
> - break;
> - }
> + (fb_info->height == latest_info->height))
> + return dmabuf_obj;
> }
>
> - return ret;
> + return dmabuf_obj;
> }
>
> static void update_fb_info(struct vfio_device_gfx_plane_info *gvt_dmabuf,
> @@ -477,11 +449,6 @@ int intel_vgpu_query_plane(struct intel_vgpu *vgpu, void
> *args)
>
> update_fb_info(gfx_plane_info, _info);
>
> - INIT_LIST_HEAD(_obj->list);
> - mutex_lock(>dmabuf_lock);
> - list_add_tail(_obj->list, >dmabuf_obj_list_head);
> - mutex_unlock(>dmabuf_lock);
> -
> gvt_dbg_dpy("vgpu%d: %s new dmabuf_obj ref %d, id %d\n", vgpu->id,
> __func__, kref_read(_obj->kref), ret);
>
> @@ -508,7 +475,7 @@ int intel_vgpu_get_dmabuf(struct intel_vgpu *vgpu,
> unsigned int dmabuf_id)
>
> mutex_lock(>dmabuf_lock);
>
> - dmabuf_obj = pick_dmabuf_by_num(vgpu, dmabuf_id);
> + dmabuf_obj =
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add vfio_device cdev for iommufd support (rev7)
== Series Details == Series: Add vfio_device cdev for iommufd support (rev7) URL : https://patchwork.freedesktop.org/series/113696/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/113696/revisions/7/mbox/ not applied Applying: vfio: Allocate per device file structure Using index info to reconstruct a base tree... M drivers/vfio/group.c M drivers/vfio/vfio.h M drivers/vfio/vfio_main.c Falling back to patching base and 3-way merge... Auto-merging drivers/vfio/vfio_main.c Auto-merging drivers/vfio/vfio.h Auto-merging drivers/vfio/group.c Applying: vfio: Refine vfio file kAPIs for KVM Using index info to reconstruct a base tree... M drivers/vfio/group.c M drivers/vfio/vfio.h M drivers/vfio/vfio_main.c M include/linux/vfio.h Falling back to patching base and 3-way merge... Auto-merging include/linux/vfio.h Auto-merging drivers/vfio/vfio_main.c Auto-merging drivers/vfio/vfio.h Auto-merging drivers/vfio/group.c CONFLICT (content): Merge conflict in drivers/vfio/group.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 vfio: Refine vfio file kAPIs for KVM When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
Re: [Intel-gfx] [PATCH v5 16/19] vfio: Add VFIO_DEVICE_BIND_IOMMUFD
> From: Jason Gunthorpe
> Sent: Thursday, March 2, 2023 1:47 AM
>
> On Wed, Mar 01, 2023 at 09:19:07AM +, Liu, Yi L wrote:
> > > From: Liu, Yi L
> > > Sent: Monday, February 27, 2023 7:12 PM
> > [...]
> > > +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;
> > > + 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;
> >
> > Hi Jason,
> >
> > Per the comment in vfio_iommufd_bind(), such device driver
> > won't provide .bind_iommufd(). So shall we allow this ioctl
> > to go longer to call .open_device() instead of failing it here?
> > I think we need to allow it to go further. E.g. leave the check
> > to be in vfio_iommufd_bind(). Otherwise, user may not able
> > to use such devices. Is it?
>
> You are thinking about the crazy mdev samples?
>
> We should probably just change them to provide a 'no dma' set of ops.
>
> > > +struct vfio_device_bind_iommufd {
> > > + __u32 argsz;
> > > + __u32 flags;
> > > + __aligned_u64 dev_cookie;
> > > + __s32 iommufd;
> > > + __u32 out_devid;
> >
> > As above, for the devices that do not do DMA, there is no .bind_iommufd
> > op, hence no iommufd_device generated. This means no good value
> > can be filled in this out_devid field. So this field is optional. Only
> > for the devices which do DMA, should this out_devid field return a
> > valid ID otherwise an invalid ID would be filled (e.g. value #0 is an
> > invalid value in the iommufd object id pool). Userspace needs to
> > check if the out_devid is valid or not before use. This ID can be further
> > used in iommufd uAPIs like IOMMU_HWPT_ALLOC,
> IOMMU_DEVICE_GET_INFO
> > and etc.
>
> I would say create an access and harmonize the no-DMA devices with the
> emulated devices.
How about below change?
diff --git a/drivers/vfio/iommufd.c b/drivers/vfio/iommufd.c
index 4f82a6fa7c6c..e536515086d7 100644
--- a/drivers/vfio/iommufd.c
+++ b/drivers/vfio/iommufd.c
@@ -18,12 +18,8 @@ int vfio_iommufd_bind(struct vfio_device *vdev, struct
iommufd_ctx *ictx)
lockdep_assert_held(>dev_set->lock);
- /*
-* If the driver doesn't provide this op then it means the device does
-* not do DMA at all. So nothing to do.
-*/
- if (!vdev->ops->bind_iommufd)
- return 0;
+ if (WARN_ON(!vdev->ops->bind_iommufd))
+ return -ENODEV;
ret = vdev->ops->bind_iommufd(vdev, ictx, _id);
if (ret)
@@ -102,7 +98,9 @@ EXPORT_SYMBOL_GPL(vfio_iommufd_physical_attach_ioas);
/*
* The emulated standard ops mean that vfio_device is going to use the
* "mdev path" and will call vfio_pin_pages()/vfio_dma_rw(). Drivers using this
- * ops set should call vfio_register_emulated_iommu_dev().
+ * ops set should call vfio_register_emulated_iommu_dev(). Drivers that do
+ * not call vfio_pin_pages()/vfio_dma_rw() has no need to provide dma_unmap
+ * callback.
*/
static void vfio_emulated_unmap(void *data, unsigned long iova,
@@ -110,7 +107,8 @@ static void vfio_emulated_unmap(void *data, unsigned long
iova,
{
struct vfio_device *vdev = data;
- vdev->ops->dma_unmap(vdev, iova, length);
+ if (vdev->ops->dma_unmap)
+ vdev->ops->dma_unmap(vdev, iova, length);
}
static const struct iommufd_access_ops vfio_user_ops = {
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index e54eb752e1ba..19391dda5fba 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -1374,6 +1374,9 @@ static const struct vfio_device_ops mbochs_dev_ops = {
.write = mbochs_write,
.ioctl = mbochs_ioctl,
.mmap = mbochs_mmap,
+ .bind_iommufd = vfio_iommufd_emulated_bind,
+ .unbind_iommufd = vfio_iommufd_emulated_unbind,
+ .attach_ioas= vfio_iommufd_emulated_attach_ioas,
};
static struct mdev_driver mbochs_driver = {
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
index e8400fdab71d..5f48aef36995 100644
--- a/samples/vfio-mdev/mdpy.c
+++ b/samples/vfio-mdev/mdpy.c
@@ -663,6 +663,9 @@ static const struct vfio_device_ops mdpy_dev_ops = {
.write = mdpy_write,
.ioctl = mdpy_ioctl,
.mmap = mdpy_mmap,
+ .bind_iommufd = vfio_iommufd_emulated_bind,
+ .unbind_iommufd = vfio_iommufd_emulated_unbind,
+ .attach_ioas= vfio_iommufd_emulated_attach_ioas,
};
static struct mdev_driver mdpy_driver = {
diff --git a/samples/vfio-mdev/mtty.c
Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Liu, Yi L
> Sent: Thursday, March 2, 2023 10:20 PM
>
> > From: Jason Gunthorpe
> > Sent: Thursday, March 2, 2023 8:35 PM
> >
> > On Thu, Mar 02, 2023 at 09:55:46AM +, Tian, Kevin wrote:
> > > > From: Liu, Yi L
> > > > Sent: Thursday, March 2, 2023 2:07 PM
> > > >
> > > > > - if (!vfio_dev_in_groups(cur_vma, groups)) {
> > > > > + if (cur_vma->vdev.open_count &&
> > > > > + !vfio_dev_in_groups(cur_vma, groups) &&
> > > > > + !vfio_dev_in_iommufd_ctx(cur_vma,
> iommufd_ctx)) {
> > > >
> > > > Hi Alex, Jason,
> > > >
> > > > There is one concern on this approach which is related to the
> > > > cdev noiommu mode. As patch 16 of this series, cdev path
> > > > supports noiommu mode by passing a negative iommufd to
> > > > kernel. In such case, the vfio_device is not bound to a valid
> > > > iommufd. Then the check in vfio_dev_in_iommufd_ctx() is
> > > > to be broken.
> > > >
> > > > An idea is to add a cdev_noiommu flag in vfio_device, when
> > > > checking the iommufd_ictx, also check this flag. If all the opened
> > > > devices in the dev_set have vfio_device->cdev_noiommu==true,
> > > > then the reset is considered to be doable. But there is a special
> > > > case. If devices in this dev_set are opened by two applications
> > > > that operates in cdev noiommu mode, then this logic is not able
> > > > to differentiate them. In that case, should we allow the reset?
> > > > It seems to ok to allow reset since noiommu mode itself means
> > > > no security between the applications that use it. thoughts?
> > > >
> > >
> > > Probably we need still pass in a valid iommufd (instead of using
> > > a negative value) in noiommu case to mark the ownership so the
> > > check in the reset path can correctly catch whether an opened
> > > device belongs to this user.
> >
> > There should be no iommufd at all in no-iommu mode
> >
> > Adding one just to deal with noiommu reset seems pretty sad :\
> >
> > no-iommu is only really used by dpdk, and it doesn't invoke
> > VFIO_DEVICE_PCI_HOT_RESET at all.
>
> Does it happen to be or by design, this ioctl is not needed by dpdk?
use of noiommu should be discouraged.
if only known noiommu user doesn't use it then having certain
new restriction for noiommu in the hot reset path might be an
acceptable tradeoff.
but again needs Alex's input as he knows all the history about
noiommu.
>
> > I'd say as long as VFIO_DEVICE_PCI_HOT_RESET works if only one vfio
> > device is open using a empty list (eg we should ensure that the
> > invoking cdev itself is allowed) then I think it is OK.
>
> Sorry, which empty list are your referring?
>
I guess it refers to zero-length fd array.
But IMHO this restriction better only applies to the case where
noiommu device (iommufd_ctx=NULL) exists in the device set.
otherwise we still compare iommufd_ctx when multiple devices
are opened.
Then the impact to noiommu case is just that user cannot do
hot reset when it opens multiple devices in a same set.
[Intel-gfx] [PATCH v2 5/7] drm/i915/display: 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]
--v11
-avoid native_420 computation if not gen14 [Uma]
--v12
-fix state mismatch issue of compressed_bpp
Cc: Uma Shankar
Cc: Jani Nikula
Signed-off-by: Suraj Kandpal
---
drivers/gpu/drm/i915/display/icl_dsi.c| 2 -
drivers/gpu/drm/i915/display/intel_dp.c | 16 +++-
drivers/gpu/drm/i915/display/intel_vdsc.c | 98 ---
3 files changed, 100 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index b5316715bb3b..fb7efab8e9e6 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -1539,8 +1539,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 2649e8b8ef57..86b9348b74bb 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -1467,9 +1467,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) {
@@ -1587,6 +1588,15 @@ int intel_dp_dsc_compute_config(struct intel_dp
*intel_dp,
pipe_config->bigjoiner_pipes,
pipe_bpp,
timeslots);
+ /*
+* According to DSC 1.2a Section 4.1.1 Table 4.1 the
maximum
+* supported PPS value can be 63.9375 and with the
further
+* mention that bpp should be programmed double the
target bpp
+* restricting our target bpp to be 31.9375 at max
+*/
+ if (pipe_config->output_format ==
INTEL_OUTPUT_FORMAT_YCBCR420)
+ dsc_max_output_bpp = min_t(u16,
dsc_max_output_bpp, 31 << 4);
+
if (!dsc_max_output_bpp) {
drm_dbg_kms(_priv->drm,
"Compressed BPP not supported\n");
diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c
b/drivers/gpu/drm/i915/display/intel_vdsc.c
index ed16f63d6355..44243fc81b46 100644
--- a/drivers/gpu/drm/i915/display/intel_vdsc.c
+++ b/drivers/gpu/drm/i915/display/intel_vdsc.c
@@ -460,14 +460,50 @@ 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 (DISPLAY_VER(dev_priv) >= 14 &&
+ 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;
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 in Section 4.1 if native_420 is set:
+* -We need to
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Set wedged if enable guc communication failed (rev2)
== Series Details == Series: drm/i915: Set wedged if enable guc communication failed (rev2) URL : https://patchwork.freedesktop.org/series/114366/ State : success == Summary == CI Bug Log - changes from CI_DRM_12803 -> Patchwork_114366v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114366v2/index.html Participating hosts (3 -> 2) -- Missing(1): fi-snb-2520m Changes --- No changes found Build changes - * Linux: CI_DRM_12803 -> Patchwork_114366v2 CI-20190529: 20190529 CI_DRM_12803: 0ad120d8f0908938dab408cef86d227321ebab74 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7179: fcbbb6ab645cdbd7545c3f96d7b7df7674e620be @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114366v2: 0ad120d8f0908938dab408cef86d227321ebab74 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 1280a123bbec drm/i915: Set wedged if enable guc communication failed == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114366v2/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/rps: split out display rps parts to a separate file
== Series Details == Series: drm/i915/rps: split out display rps parts to a separate file URL : https://patchwork.freedesktop.org/series/114581/ State : success == Summary == CI Bug Log - changes from CI_DRM_12801 -> Patchwork_114581v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114581v1/index.html Participating hosts (3 -> 2) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_114581v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@load: - bat-atsm-1: [PASS][1] -> [ABORT][2] ([i915#8219]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12801/bat-atsm-1/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114581v1/bat-atsm-1/igt@i915_module_l...@load.html [i915#8219]: https://gitlab.freedesktop.org/drm/intel/issues/8219 Build changes - * Linux: CI_DRM_12801 -> Patchwork_114581v1 CI-20190529: 20190529 CI_DRM_12801: 6695d34a4e09a2371e6ad8a2ea8644bfa901744e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7178: ffe3f6670b91ab975f90799ab3fd0941b6eae019 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114581v1: 6695d34a4e09a2371e6ad8a2ea8644bfa901744e @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 6bf468203cfa drm/i915/rps: split out display rps parts to a separate file == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114581v1/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check HPD during eDP probe
== Series Details == Series: drm/i915: Check HPD during eDP probe URL : https://patchwork.freedesktop.org/series/114577/ State : success == Summary == CI Bug Log - changes from CI_DRM_12801 -> Patchwork_114577v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v1/index.html Participating hosts (3 -> 2) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_114577v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@load: - bat-atsm-1: [PASS][1] -> [ABORT][2] ([i915#8219]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12801/bat-atsm-1/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v1/bat-atsm-1/igt@i915_module_l...@load.html [i915#8219]: https://gitlab.freedesktop.org/drm/intel/issues/8219 Build changes - * Linux: CI_DRM_12801 -> Patchwork_114577v1 CI-20190529: 20190529 CI_DRM_12801: 6695d34a4e09a2371e6ad8a2ea8644bfa901744e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7178: ffe3f6670b91ab975f90799ab3fd0941b6eae019 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114577v1: 6695d34a4e09a2371e6ad8a2ea8644bfa901744e @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 1d54e51ee661 drm/i915: Reuse _hotplug_mask() in .hpd_detection_setup() 2ecd6021b80b drm/i915: Check HPD live state during eDP probe 2578c6a778cd drm/i915: Introduce intel_hpd_enable_detection() d957e5f50ef6 drm/i915: Introduce _hotplug_mask() 3a44e2d7f01c drm/i915: Get rid of the gm45 HPD live state nonsense dd2f93f4bbdc drm/i915: Fix SKL DDI A digital port .connected() c88426521507 drm/i915: Populate dig_port->connected() before connector init == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114577v1/index.html
Re: [Intel-gfx] [PATCH v9 15/15] drm/i915: Add deadline based boost support
On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote:
> From: Rob Clark
>
missing some wording here...
> v2: rebase
>
> Signed-off-by: Rob Clark
> ---
> drivers/gpu/drm/i915/i915_request.c | 20
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.c
> b/drivers/gpu/drm/i915/i915_request.c
> index 7503dcb9043b..44491e7e214c 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct dma_fence
> *fence)
> return i915_request_enable_breadcrumb(to_request(fence));
> }
>
> +static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t
> deadline)
> +{
> + struct i915_request *rq = to_request(fence);
> +
> + if (i915_request_completed(rq))
> + return;
> +
> + if (i915_request_started(rq))
> + return;
why do we skip the boost if already started?
don't we want to boost the freq anyway?
> +
> + /*
> + * TODO something more clever for deadlines that are in the
> + * future. I think probably track the nearest deadline in
> + * rq->timeline and set timer to trigger boost accordingly?
> + */
I'm afraid it will be very hard to find some heuristics of what's
late enough for the boost no?
I mean, how early to boost the freq on an upcoming deadline for the
timer?
> +
> + intel_rps_boost(rq);
> +}
> +
> static signed long i915_fence_wait(struct dma_fence *fence,
> bool interruptible,
> signed long timeout)
> @@ -182,6 +201,7 @@ const struct dma_fence_ops i915_fence_ops = {
> .signaled = i915_fence_signaled,
> .wait = i915_fence_wait,
> .release = i915_fence_release,
> + .set_deadline = i915_fence_set_deadline,
> };
>
> static void irq_execute_cb(struct irq_work *wrk)
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH v6 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC
On Mon, 2023-02-27 at 18:21 -0800, Teres Alexis, Alan Previn wrote:
> 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.
>
>
alan:snip
> +int
> +intel_gsc_uc_heci_cmd_submit_nonpriv(struct intel_gsc_uc *gsc,
> + struct intel_context *ce,
> + struct intel_gsc_heci_non_priv_pkt *pkt,
> + u32 *cmd, int timeout_ms)
> +{
> + struct intel_engine_cs *eng;
> + struct i915_request *rq;
> + int err;
> +
> + rq = intel_context_create_request(ce);
> + if (IS_ERR(rq))
> + return PTR_ERR(rq);
> +
> + emit_gsc_heci_pkt_nonpriv(cmd, pkt);
> +
> + i915_vma_lock(pkt->bb_vma);
> + err = i915_vma_move_to_active(pkt->bb_vma, rq, EXEC_OBJECT_WRITE);
> + i915_vma_unlock(pkt->bb_vma);
> + if (err)
> + goto out_rq;
> +
alan:
depending on timing (appears to be a racy trigger event), in <5% of the time
when I tested this internally,
I am seeing lockdep issues when running live_selftests(gt_timelines) followed
by a PXP teardown at pxp-fini.
The lockdep kernel logs point to the sequence of calling
"intel_context_create_request" followed by
i915_vma_lock/move_to_active/i915_vma_unlock for the objects (and how the
internal ww-locks vs timeline-locks are taken)
Internal discussions realize that i really shouldnt be using these function
call sequences and should instead
follow what our workaround batch buffers do:
(the following is the current fix proposal from internal discussions, but i
still need to do more testing +
debug before i re-rev but i wanted to put this review comment first so the
follow-up action is not lost)
i915_gem_ww_ctx_init(, false);
i915_gem_object_lock(pkt->bb_vma->obj, );
intel_context_pin_ww(ce, );
i915_request_create(ce);
i915_vma_move_to_active(pkt->bb_vma, rq, EXEC_OBJECT_WRITE);
submit (breadcrumbs, init-bb, flush...)
i915_request_get/add/put(rq);
intel_context_unpin(ce);
i915_gem_ww_ctx_fini();
alan:snip
Re: [Intel-gfx] [PATCH v3 8/9] drm/i915/perf: Add engine class instance parameters to perf
On Wed, Mar 01, 2023 at 01:59:10PM -0800, Dixit, Ashutosh wrote:
On Mon, 27 Feb 2023 18:23:28 -0800, Umesh Nerlige Ramappa wrote:
Hi Umesh,
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 8df261c5ab9b..8ce20004a9dd 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -2758,6 +2758,28 @@ enum drm_i915_perf_property_id {
*/
DRM_I915_PERF_PROP_POLL_OA_PERIOD,
+ /**
+* In platforms with multiple OA buffers, the engine class instance must
I'd say "one engine class instance".
+* be passed to open a stream to a OA unit corresponding to the engine.
+* Multiple engines may be mapped to the same OA unit.
Maybe (at the risk of over-stating) something like "Multiple engines may be
mapped to the same OA unit. The OA unit is identified by class:instance of
any engine mapped to it".
But it's ok to not change anything here.
+*
+* In addition to the class:instance, if a gem context is also passed,
then
+* 1) the report headers of OA reports from any contexts that do not
+*match this specific engine context are squashed.
This one I don't understand: we seem to be mixing gem contexts and engine
context here. Also, afais there are no changes related to this in this
series. This context squashing has always been happening, so why add this
comment to DRM_I915_PERF_PROP_OA_ENGINE_CLASS (or to this patch)? If we
want to clarify something maybe this comment should be added to
DRM_I915_PERF_PROP_CTX_HANDLE? But otherwise I think we should just drop
this comment, at least from this patch?
+* 2) if the engine supports MI_REPORT_PERF_COUNT, this specific engine
+*context is configured for this command.
I think I will drop 1 and 2 since they are not specifically related to
the class:instance parameters.
Thanks,
Umesh
+*
+* This property is available in perf revision 6.
+*/
+ DRM_I915_PERF_PROP_OA_ENGINE_CLASS,
+
+ /**
+* This parameter specifies the engine instance.
+*
+* This property is available in perf revision 6.
+*/
+ DRM_I915_PERF_PROP_OA_ENGINE_INSTANCE,
+
DRM_I915_PERF_PROP_MAX /* non-ABI */
};
Thanks.
--
Ashutosh
[Intel-gfx] [PATCH v9 15/15] drm/i915: Add deadline based boost support
From: Rob Clark
v2: rebase
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_request.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 7503dcb9043b..44491e7e214c 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -97,6 +97,25 @@ static bool i915_fence_enable_signaling(struct dma_fence
*fence)
return i915_request_enable_breadcrumb(to_request(fence));
}
+static void i915_fence_set_deadline(struct dma_fence *fence, ktime_t deadline)
+{
+ struct i915_request *rq = to_request(fence);
+
+ if (i915_request_completed(rq))
+ return;
+
+ if (i915_request_started(rq))
+ return;
+
+ /*
+* TODO something more clever for deadlines that are in the
+* future. I think probably track the nearest deadline in
+* rq->timeline and set timer to trigger boost accordingly?
+*/
+
+ intel_rps_boost(rq);
+}
+
static signed long i915_fence_wait(struct dma_fence *fence,
bool interruptible,
signed long timeout)
@@ -182,6 +201,7 @@ const struct dma_fence_ops i915_fence_ops = {
.signaled = i915_fence_signaled,
.wait = i915_fence_wait,
.release = i915_fence_release,
+ .set_deadline = i915_fence_set_deadline,
};
static void irq_execute_cb(struct irq_work *wrk)
--
2.39.1
[Intel-gfx] [PATCH v9 00/15] dma-fence: Deadline awareness
From: Rob Clark This series adds a deadline hint to fences, so realtime deadlines such as vblank can be communicated to the fence signaller for power/ frequency management decisions. This is partially inspired by a trick i915 does, but implemented via dma-fence for a couple of reasons: 1) To continue to be able to use the atomic helpers 2) To support cases where display and gpu are different drivers This iteration adds a dma-fence ioctl to set a deadline (both to support igt-tests, and compositors which delay decisions about which client buffer to display), and a sw_sync ioctl to read back the deadline. IGT tests utilizing these can be found at: https://gitlab.freedesktop.org/robclark/igt-gpu-tools/-/commits/fence-deadline v1: https://patchwork.freedesktop.org/series/93035/ v2: Move filtering out of later deadlines to fence implementation to avoid increasing the size of dma_fence v3: Add support in fence-array and fence-chain; Add some uabi to support igt tests and userspace compositors. v4: Rebase, address various comments, and add syncobj deadline support, and sync_file EPOLLPRI based on experience with perf/ freq issues with clvk compute workloads on i915 (anv) v5: Clarify that this is a hint as opposed to a more hard deadline guarantee, switch to using u64 ns values in UABI (still absolute CLOCK_MONOTONIC values), drop syncobj related cap and driver feature flag in favor of allowing count_handles==0 for probing kernel support. v6: Re-work vblank helper to calculate time of _start_ of vblank, and work correctly if the last vblank event was more than a frame ago. Add (mostly unrelated) drm/msm patch which also uses the vblank helper. Use dma_fence_chain_contained(). More verbose syncobj UABI comments. Drop DMA_FENCE_FLAG_HAS_DEADLINE_BIT. v7: Fix kbuild complaints about vblank helper. Add more docs. v8: Add patch to surface sync_file UAPI, and more docs updates. v9: Drop (E)POLLPRI support.. I still like it, but not essential and it can always be revived later. Fix doc build warning. Rob Clark (15): dma-buf/dma-fence: Add deadline awareness dma-buf/fence-array: Add fence deadline support dma-buf/fence-chain: Add fence deadline support dma-buf/dma-resv: Add a way to set fence deadline dma-buf/sync_file: Surface sync-file uABI dma-buf/sync_file: Add SET_DEADLINE ioctl dma-buf/sw_sync: Add fence deadline support drm/scheduler: Add fence deadline support drm/syncobj: Add deadline support for syncobj waits drm/vblank: Add helper to get next vblank time drm/atomic-helper: Set fence deadline for vblank drm/msm: Add deadline based boost support drm/msm: Add wait-boost support drm/msm/atomic: Switch to vblank_start helper drm/i915: Add deadline based boost support Documentation/driver-api/dma-buf.rst| 16 - drivers/dma-buf/dma-fence-array.c | 11 drivers/dma-buf/dma-fence-chain.c | 12 drivers/dma-buf/dma-fence.c | 60 ++ drivers/dma-buf/dma-resv.c | 22 +++ drivers/dma-buf/sw_sync.c | 81 + drivers/dma-buf/sync_debug.h| 2 + drivers/dma-buf/sync_file.c | 19 ++ drivers/gpu/drm/drm_atomic_helper.c | 36 +++ drivers/gpu/drm/drm_syncobj.c | 64 +++ drivers/gpu/drm/drm_vblank.c| 53 +--- drivers/gpu/drm/i915/i915_request.c | 20 ++ drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 15 - drivers/gpu/drm/msm/msm_atomic.c| 8 ++- drivers/gpu/drm/msm/msm_drv.c | 12 ++-- drivers/gpu/drm/msm/msm_fence.c | 74 ++ drivers/gpu/drm/msm/msm_fence.h | 20 ++ drivers/gpu/drm/msm/msm_gem.c | 5 ++ drivers/gpu/drm/msm/msm_kms.h | 8 --- drivers/gpu/drm/scheduler/sched_fence.c | 46 ++ drivers/gpu/drm/scheduler/sched_main.c | 2 +- include/drm/drm_vblank.h| 1 + include/drm/gpu_scheduler.h | 17 ++ include/linux/dma-fence.h | 22 +++ include/linux/dma-resv.h| 2 + include/uapi/drm/drm.h | 17 ++ include/uapi/drm/msm_drm.h | 14 - include/uapi/linux/sync_file.h | 59 +++--- 28 files changed, 639 insertions(+), 79 deletions(-) -- 2.39.1
Re: [Intel-gfx] [PATCH v5 00/19] Add vfio_device cdev for iommufd support
On Thu, Mar 02, 2023 at 09:43:00AM +, Shameerali Kolothum Thodi wrote: > Hi Nicolin, > > Thanks for the latest ARM64 branch. Do you have a working Qemu branch > corresponding to the > above one? > > I tried the > https://github.com/nicolinc/qemu/tree/wip/iommufd_rfcv3%2Bnesting%2Bsmmuv3 > but for some reason not able to launch the Guest. > > Please let me know. I do use that branch. It might not be that robust though as it went through a big rebase. Can you try with the followings? --trace "iommufd*" --trace "smmu*" --trace "vfio_*" --trace "pci_*" --trace "msi_*" --trace "nvme_*" Thanks Nicolin
Re: [Intel-gfx] [PATCH] drm/i915: Set wedged if enable guc communication failed
Thanks Jani.
Updated patch sent, let me know if you have any comments.
Regards,
Zhanjun
> -Original Message-
> From: Jani Nikula
> Sent: February 27, 2023 6:30 AM
> To: Dong, Zhanjun ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Cc: Dong, Zhanjun
> Subject: Re: [PATCH] drm/i915: Set wedged if enable guc communication
> failed
>
> On Fri, 24 Feb 2023, Zhanjun Dong wrote:
> > Add err code check for enable_communication on resume path, set
> wedged if failed.
>
> I can see that this is *what* the code does, but the commit message should
> answer the question *why*.
>
> >
> > Signed-off-by: Zhanjun Dong
> > ---
> > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 5 -
> > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++--
> > 2 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > index cef3d6f5c34e..f3bb7cbbd293 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> > @@ -401,8 +401,11 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
> > intel_ggtt_restore_fences(gt->ggtt);
> >
> > ret = intel_uc_runtime_resume(>uc);
> > - if (ret)
> > + if (ret) {
> > + /* Set wedge if uc resume failed */
>
> This comment is just a reiteration of the C code in English, but doesn't
> provide any useful additional information.
>
> BR,
> Jani.
>
> > + intel_gt_set_wedged(gt);
> > return ret;
> > + }
> >
> > return 0;
> > }
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > index 6648691bd645..d4f428acf20a 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
> > @@ -698,8 +698,13 @@ static int __uc_resume(struct intel_uc *uc, bool
> enable_communication)
> > /* Make sure we enable communication if and only if it's disabled */
> > GEM_BUG_ON(enable_communication ==
> intel_guc_ct_enabled(>ct));
> >
> > - if (enable_communication)
> > - guc_enable_communication(guc);
> > + if (enable_communication) {
> > + err = guc_enable_communication(guc);
> > + if (err) {
> > + guc_dbg(guc, "Failed to resume, %pe", ERR_PTR(err));
> > + return err;
> > + }
> > + }
> >
> > /* If we are only resuming GuC communication but not reloading
> > * GuC, we need to ensure the ARAT timer interrupt is enabled
>
> --
> Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH] drm/i915: Set wedged if enable guc communication failed
Add err code check for enable_communication on resume path. When resume failed,
we can no longer use the GPU, marking the GPU as wedged.
Signed-off-by: Zhanjun Dong
---
drivers/gpu/drm/i915/gt/intel_gt_pm.c | 7 ++-
drivers/gpu/drm/i915/gt/uc/intel_uc.c | 9 +++--
2 files changed, 13 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
index cef3d6f5c34e..42a7d75ce39e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
@@ -401,8 +401,13 @@ int intel_gt_runtime_resume(struct intel_gt *gt)
intel_ggtt_restore_fences(gt->ggtt);
ret = intel_uc_runtime_resume(>uc);
- if (ret)
+ if (ret) {
+ /* Resume failed, we can no longer use the GPU, marking the GPU
+* as wedged.
+*/
+ intel_gt_set_wedged(gt);
return ret;
+ }
return 0;
}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
index 6648691bd645..d4f428acf20a 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc.c
@@ -698,8 +698,13 @@ static int __uc_resume(struct intel_uc *uc, bool
enable_communication)
/* Make sure we enable communication if and only if it's disabled */
GEM_BUG_ON(enable_communication == intel_guc_ct_enabled(>ct));
- if (enable_communication)
- guc_enable_communication(guc);
+ if (enable_communication) {
+ err = guc_enable_communication(guc);
+ if (err) {
+ guc_dbg(guc, "Failed to resume, %pe", ERR_PTR(err));
+ return err;
+ }
+ }
/* If we are only resuming GuC communication but not reloading
* GuC, we need to ensure the ARAT timer interrupt is enabled
--
2.34.1
Re: [Intel-gfx] [PATCH v4 04/22] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
Hi Mika,
> -Original Message-
> From: Kahola, Mika
> Sent: Friday, February 24, 2023 2:14 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sripada, Radhakrishna ; Deak, Imre
> ; Shankar, Uma ; Kahola,
> Mika
> Subject: [PATCH v4 04/22] drm/i915/mtl: Add Support for C10 PHY message bus
> and pll programming
>
> From: Radhakrishna Sripada
>
> XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
> has a dedicated PIPE 5.2 Message bus for configuration. This message
> bus is used to configure the phy internal registers.
>
> XELPDP has C10 phys to drive output to the EDP and the native output
> from the display engine. Add structures, programming hardware state
> readout logic. Port clock calculations are similar to DG2. Use the DG2
> formulae to calculate the port clock but use the relevant pll signals.
> Note: PHY lane 0 is always used for PLL programming.
>
> Add sequences for C10 phy enable/disable phy lane reset,
> powerdown change sequence and phy lane programming.
>
> Bspec: 64539, 64568, 64599, 65100, 65101, 65450, 65451, 67610, 67636
>
> v2: Squash patches related to C10 phy message bus and pll
> programming support (Jani)
> Move register definitions to a new file i.e. intel_cx0_reg_defs.h (Jani)
> Move macro definitions (Jani)
> DP rates as separate patch (Jani)
> Spin out xelpdp register definitions into a separate file (Jani)
> Replace macro to select registers based on phy lane with
> function calls (Jani)
> Fix styling issues (Jani)
> Call XELPDP_PORT_P2M_MSGBUS_STATUS() with port instead of phy (Lucas)
> v3: Move clear request flag into try-loop
> v4: On PHY idle change drm_err_once() as drm_dbg_kms() (Jani)
> use __intel_de_wait_for_register() instead of __intel_wait_for_register
> and uncomment intel_uncore.h (Jani)
> Add DP-alt support for PHY lane programming (Khaled)
>
> Cc: Imre Deak
> Cc: Uma Shankar
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/Makefile |1 +
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 1120 +
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 43 +
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 34 +
> drivers/gpu/drm/i915/display/intel_ddi.c | 22 +-
> .../drm/i915/display/intel_display_power.c|3 +-
> .../i915/display/intel_display_power_well.c |2 +-
> .../drm/i915/display/intel_display_types.h|6 +
> drivers/gpu/drm/i915/display/intel_dpll.c | 22 +-
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c |2 +-
> .../drm/i915/display/intel_modeset_verify.c |2 +
> drivers/gpu/drm/i915/i915_reg.h |5 +
> drivers/gpu/drm/i915/i915_reg_defs.h | 57 +
> 13 files changed, 1314 insertions(+), 5 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_cx0_phy.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index b2f91a1f8268..b04395472437 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -294,6 +294,7 @@ i915-y += \
> display/icl_dsi.o \
> display/intel_backlight.o \
> display/intel_crt.o \
> + display/intel_cx0_phy.o \
> display/intel_ddi.o \
> display/intel_ddi_buf_trans.o \
> display/intel_display_trace.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> new file mode 100644
> index ..dce55f0ed5e1
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -0,0 +1,1120 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2021 Intel Corporation
> + */
> +
> +#include "i915_reg.h"
> +#include "intel_cx0_phy.h"
> +#include "intel_cx0_phy_regs.h"
> +#include "intel_de.h"
> +#include "intel_display_types.h"
> +#include "intel_dp.h"
> +#include "intel_panel.h"
> +#include "intel_tc.h"
> +
> +bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
> +{
> + if (IS_METEORLAKE(dev_priv) && (phy < PHY_C))
> + return true;
> +
> + return false;
> +}
> +
> +static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port
> port,
> int lane)
> +{
> + enum phy phy = intel_port_to_phy(i915, port);
> +
> + /* Bring the phy to idle. */
> + intel_de_write(i915, XELPDP_PORT_M2P_MSGBUS_CTL(port, lane-1),
> +XELPDP_PORT_M2P_TRANSACTION_RESET);
> +
> + /* Wait for Idle Clear. */
> + if (intel_de_wait_for_clear(i915,
> XELPDP_PORT_M2P_MSGBUS_CTL(port, lane-1),
> + XELPDP_PORT_M2P_TRANSACTION_RESET,
> + XELPDP_MSGBUS_TIMEOUT_SLOW)) {
> + drm_dbg_kms(>drm, "Failed to bring PHY %c to idle.\n",
> phy_name(phy));
> + return;
> + }
> +
> + intel_de_write(i915,
Re: [Intel-gfx] [PATCH v3 9/9] drm/i915/perf: Add support for OA media units
On Mon, 27 Feb 2023 18:23:29 -0800, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
> @@ -1632,11 +1647,28 @@ 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;
This doesn't add anything above engine_supports_oa() below: if
engine->oa_group is true for engine X, engine->oa_group->num_engines must
at least be 1 because the oa_group must at least contain X. (Of course
oa_group->num_engines can still be 0 but engine->oa_group->num_engines must
be > 0).
We can see this in oa_init_gt where num_engines++ and oa_group assignment
is done together:
static int oa_init_gt(struct intel_gt *gt)
{
...
for_each_engine_masked(engine, gt, ALL_ENGINES, tmp) {
u32 index = __oa_engine_group(engine);
engine->oa_group = NULL;
if (index < num_groups) {
g[index].num_engines++;
engine->oa_group = [index];
}
}
}
Therefore in read_properties_unlocked these checks are sufficient:
props->engine = intel_engine_lookup_user(perf->i915, class, instance);
if (!props->engine) {
return -EINVAL;
}
if (!engine_supports_oa(props->engine)) {
return -EINVAL;
}
The oa_unit_functional check is not needed.
> +}
> +
> static bool engine_supports_oa(const struct intel_engine_cs *engine)
> {
> return engine->oa_group;
> }
>
> +static bool engine_supports_oa_format(struct intel_engine_cs *engine, int
> type)
> +{
> + return engine->oa_group && engine->oa_group->type == type;
> +}
> +
/snip/
> @@ -4186,6 +4227,17 @@ static int read_properties_unlocked(struct i915_perf
> *perf,
> return -EINVAL;
> }
>
> + if (!oa_unit_functional(props->engine))
> + return -ENODEV;
> +
> + i = array_index_nospec(props->oa_format, I915_OA_FORMAT_MAX);
> + f = >oa_formats[i];
> + if (!engine_supports_oa_format(props->engine, f->type)) {
> + DRM_DEBUG("Invalid OA format %d for class %d\n",
> + f->type, props->engine->class);
> + return -EINVAL;
> + }
> +
Thanks.
--
Ashutosh
Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Thu, 2 Mar 2023 06:07:04 +
"Liu, Yi L" wrote:
> > From: Liu, Yi L
> > Sent: Monday, February 27, 2023 7:11 PM
> [...]
> > @@ -2392,13 +2416,25 @@ static int
> > vfio_pci_dev_set_pm_runtime_get(struct vfio_device_set *dev_set)
> > return ret;
> > }
> >
> > +static bool vfio_dev_in_iommufd_ctx(struct vfio_pci_core_device *vdev,
> > + struct iommufd_ctx *iommufd_ctx)
> > +{
> > + struct iommufd_ctx *iommufd = vfio_device_iommufd(
> > >vdev);
> > +
> > + if (!iommufd)
> > + return false;
> > +
> > + return iommufd == iommufd_ctx;
> > +}
> > +
> > /*
> > * We need to get memory_lock for each device, but devices can share
> > mmap_lock,
> > * therefore we need to zap and hold the vma_lock for each device, and
> > only then
> > * get each memory_lock.
> > */
> > static int vfio_pci_dev_set_hot_reset(struct vfio_device_set *dev_set,
> > - struct vfio_pci_group_info *groups)
> > + struct vfio_pci_group_info *groups,
> > + struct iommufd_ctx *iommufd_ctx)
> > {
> > struct vfio_pci_core_device *cur_mem;
> > struct vfio_pci_core_device *cur_vma;
> > @@ -2429,10 +2465,27 @@ static int vfio_pci_dev_set_hot_reset(struct
> > vfio_device_set *dev_set,
> >
> > list_for_each_entry(cur_vma, _set->device_list,
> > vdev.dev_set_list) {
> > /*
> > -* Test whether all the affected devices are contained by
> > the
> > -* set of groups provided by the user.
> > +* Test whether all the affected devices can be reset by the
> > +* user. The affected devices may already been opened or
> > not
> > +* yet.
> > +*
> > +* For the devices not opened yet, user can reset them. The
> > +* reason is that the hot reset is done under the protection
> > +* of the dev_set->lock, and device open is also under this
> > +* lock. During the hot reset, such devices can not be
> > opened
> > +* by other users.
> > +*
> > +* For the devices that have been opened, needs to check
> > the
> > +* ownership. If the user provides a set of group fds, the
> > +* ownership check is done by checking if all the opened
> > +* devices are contained by the groups. If the user provides
> > +* a zero-length fd array, the ownerhsip check is done by
> > +* checking if all the opened devices are bound to the same
> > +* iommufd_ctx.
> > */
> > - if (!vfio_dev_in_groups(cur_vma, groups)) {
> > + if (cur_vma->vdev.open_count &&
> > + !vfio_dev_in_groups(cur_vma, groups) &&
> > + !vfio_dev_in_iommufd_ctx(cur_vma, iommufd_ctx)) {
>
> Hi Alex, Jason,
>
> There is one concern on this approach which is related to the
> cdev noiommu mode. As patch 16 of this series, cdev path
> supports noiommu mode by passing a negative iommufd to
> kernel. In such case, the vfio_device is not bound to a valid
> iommufd. Then the check in vfio_dev_in_iommufd_ctx() is
> to be broken.
>
> An idea is to add a cdev_noiommu flag in vfio_device, when
> checking the iommufd_ictx, also check this flag. If all the opened
> devices in the dev_set have vfio_device->cdev_noiommu==true,
> then the reset is considered to be doable. But there is a special
> case. If devices in this dev_set are opened by two applications
> that operates in cdev noiommu mode, then this logic is not able
> to differentiate them. In that case, should we allow the reset?
> It seems to ok to allow reset since noiommu mode itself means
> no security between the applications that use it. thoughts?
I don't think the existing vulnerabilities of no-iommu mode should be
carte blanche to add additional weaknesses. Thanks,
Alex
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dmc: Load DMC on MTL
== Series Details == Series: drm/i915/dmc: Load DMC on MTL URL : https://patchwork.freedesktop.org/series/114576/ State : success == Summary == CI Bug Log - changes from CI_DRM_12801 -> Patchwork_114576v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v1/index.html Participating hosts (3 -> 2) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_114576v1 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@load: - bat-atsm-1: [PASS][1] -> [ABORT][2] ([i915#8219]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12801/bat-atsm-1/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v1/bat-atsm-1/igt@i915_module_l...@load.html [i915#8219]: https://gitlab.freedesktop.org/drm/intel/issues/8219 Build changes - * Linux: CI_DRM_12801 -> Patchwork_114576v1 CI-20190529: 20190529 CI_DRM_12801: 6695d34a4e09a2371e6ad8a2ea8644bfa901744e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7178: ffe3f6670b91ab975f90799ab3fd0941b6eae019 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114576v1: 6695d34a4e09a2371e6ad8a2ea8644bfa901744e @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits e59ba8e512ef drm/i915/dmc: Load DMC on MTL == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114576v1/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live (rev2)
== Series Details == Series: series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live (rev2) URL : https://patchwork.freedesktop.org/series/114432/ State : success == Summary == CI Bug Log - changes from CI_DRM_12801 -> Patchwork_114432v2 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v2/index.html Participating hosts (3 -> 2) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_114432v2 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@load: - bat-atsm-1: [PASS][1] -> [ABORT][2] ([i915#8219]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12801/bat-atsm-1/igt@i915_module_l...@load.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v2/bat-atsm-1/igt@i915_module_l...@load.html [i915#8219]: https://gitlab.freedesktop.org/drm/intel/issues/8219 Build changes - * Linux: CI_DRM_12801 -> Patchwork_114432v2 CI-20190529: 20190529 CI_DRM_12801: 6695d34a4e09a2371e6ad8a2ea8644bfa901744e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7178: ffe3f6670b91ab975f90799ab3fd0941b6eae019 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_114432v2: 6695d34a4e09a2371e6ad8a2ea8644bfa901744e @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 1d4179943633 drm/i915: Use correct huge page manager for MTL fd3d09fc29a1 drm/i915: Migrate platform-dependent mock hugepage selftests to live == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114432v2/index.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/active: Fix misuse of non-idle barriers as fence trackers (rev7)
== Series Details == Series: drm/i915/active: Fix misuse of non-idle barriers as fence trackers (rev7) URL : https://patchwork.freedesktop.org/series/113950/ State : success == Summary == CI Bug Log - changes from CI_DRM_12801 -> Patchwork_113950v7 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/index.html Participating hosts (3 -> 3) -- Additional (1): bat-dg1-6 Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_113950v7 that come from known issues: ### IGT changes ### Issues hit * igt@gem_mmap@basic: - bat-dg1-6: NOTRUN -> [SKIP][1] ([i915#4083]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@gem_m...@basic.html * igt@gem_mmap_gtt@basic: - bat-dg1-6: NOTRUN -> [SKIP][2] ([i915#4077]) +2 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@gem_mmap_...@basic.html * igt@gem_render_tiled_blits@basic: - bat-dg1-6: NOTRUN -> [SKIP][3] ([i915#4079]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@gem_render_tiled_bl...@basic.html * igt@i915_pm_backlight@basic-brightness: - bat-dg1-6: NOTRUN -> [SKIP][4] ([i915#7561]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rps@basic-api: - bat-dg1-6: NOTRUN -> [SKIP][5] ([i915#6621]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@i915_pm_...@basic-api.html * igt@kms_addfb_basic@basic-y-tiled-legacy: - bat-dg1-6: NOTRUN -> [SKIP][6] ([i915#4215]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@kms_addfb_ba...@basic-y-tiled-legacy.html * igt@kms_addfb_basic@tile-pitch-mismatch: - bat-dg1-6: NOTRUN -> [SKIP][7] ([i915#4212]) +7 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@kms_addfb_ba...@tile-pitch-mismatch.html * igt@kms_chamelium_hpd@dp-hpd-fast: - bat-dg1-6: NOTRUN -> [SKIP][8] ([i915#7828]) +8 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@kms_chamelium_...@dp-hpd-fast.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-legacy: - bat-dg1-6: NOTRUN -> [SKIP][9] ([i915#4103] / [i915#4213]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-legacy.html * igt@kms_force_connector_basic@force-load-detect: - bat-dg1-6: NOTRUN -> [SKIP][10] ([fdo#109285]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_psr@cursor_plane_move: - bat-dg1-6: NOTRUN -> [SKIP][11] ([i915#1072] / [i915#4078]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@kms_psr@cursor_plane_move.html * igt@kms_setmode@basic-clone-single-crtc: - bat-dg1-6: NOTRUN -> [SKIP][12] ([i915#3555]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-mmap: - bat-dg1-6: NOTRUN -> [SKIP][13] ([i915#3708] / [i915#4077]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@prime_v...@basic-fence-mmap.html * igt@prime_vgem@basic-read: - bat-dg1-6: NOTRUN -> [SKIP][14] ([i915#3708]) +3 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@prime_v...@basic-read.html * igt@prime_vgem@basic-userptr: - bat-dg1-6: NOTRUN -> [SKIP][15] ([i915#3708] / [i915#4873]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113950v7/bat-dg1-6/igt@prime_v...@basic-userptr.html [fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285 [i915#1072]: https://gitlab.freedesktop.org/drm/intel/issues/1072 [i915#3555]: https://gitlab.freedesktop.org/drm/intel/issues/3555 [i915#3708]: https://gitlab.freedesktop.org/drm/intel/issues/3708 [i915#4077]: https://gitlab.freedesktop.org/drm/intel/issues/4077 [i915#4078]: https://gitlab.freedesktop.org/drm/intel/issues/4078 [i915#4079]: https://gitlab.freedesktop.org/drm/intel/issues/4079 [i915#4083]: https://gitlab.freedesktop.org/drm/intel/issues/4083 [i915#4103]: https://gitlab.freedesktop.org/drm/intel/issues/4103 [i915#4212]: https://gitlab.freedesktop.org/drm/intel/issues/4212 [i915#4213]: https://gitlab.freedesktop.org/drm/intel/issues/4213 [i915#4215]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Apply Wa_14017073508 for MTL Media Step (rev2)
== Series Details == Series: drm/i915/mtl: Apply Wa_14017073508 for MTL Media Step (rev2) URL : https://patchwork.freedesktop.org/series/114508/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12800 -> Patchwork_114508v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_114508v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_114508v2, 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_114508v2/index.html Participating hosts (38 -> 2) -- ERROR: It appears as if the changes made in Patchwork_114508v2 prevented too many machines from booting. Additional (1): bat-atsm-1 Missing(37): fi-rkl-11600 bat-adls-5 bat-dg1-6 bat-dg1-5 bat-adlp-6 fi-apl-guc fi-snb-2520m bat-rpls-1 fi-blb-e6850 bat-rpls-2 fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 fi-ilk-650 fi-hsw-4770 bat-adln-1 fi-ivb-3770 bat-jsl-3 bat-rplp-1 fi-elk-e7500 bat-dg2-11 fi-bsw-nick fi-kbl-7567u bat-dg1-7 bat-kbl-2 bat-adlp-9 fi-skl-guc fi-cfl-8700k fi-glk-j4005 bat-jsl-1 fi-tgl-1115g4 fi-cfl-guc fi-kbl-guc fi-kbl-x1275 fi-cfl-8109u Known issues Here are the changes found in Patchwork_114508v2 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][3] ([i915#4077]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4079]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#6621]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@i915_pm_...@basic-api.html * igt@i915_suspend@basic-s3-without-i915: - bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#6645]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@size-max: - bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#6077]) +36 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@kms_addfb_ba...@size-max.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#6078]) +19 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html * igt@kms_flip@basic-plain-flip: - bat-atsm-1: NOTRUN -> [SKIP][9] ([i915#6166]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@kms_f...@basic-plain-flip.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-atsm-1: NOTRUN -> [SKIP][10] ([i915#6093]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@hang-read-crc: - bat-atsm-1: NOTRUN -> [SKIP][11] ([i915#1836]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@kms_pipe_crc_ba...@hang-read-crc.html * igt@kms_prop_blob@basic: - bat-atsm-1: NOTRUN -> [SKIP][12] ([i915#7357]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@kms_prop_b...@basic.html * igt@kms_psr@sprite_plane_onoff: - bat-atsm-1: NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - bat-atsm-1: NOTRUN -> [SKIP][14] ([i915#6094]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-flip: - bat-atsm-1: NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#6078]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114508v2/bat-atsm-1/igt@prime_v...@basic-fence-flip.html *
Re: [Intel-gfx] [PATCH v3 06/22] drm/i915/mtl: Add vswing programming for C10 phys
Hi Mika,
> -Original Message-
> From: Kahola, Mika
> Sent: Thursday, February 23, 2023 5:40 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sripada, Radhakrishna ; Deak, Imre
> ; Shankar, Uma ; Taylor,
> Clinton A ; Kahola, Mika
> Subject: [PATCH v3 06/22] drm/i915/mtl: Add vswing programming for C10 phys
>
> From: Radhakrishna Sripada
>
> C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
> Program the levels directly to the fields in the VDR Registers.
>
> Bspec: 65449
>
> v2: From table "C10: Tx EQ settings for DP 1.4x" it shows level 1
> and preemphasis 1 instead of two times of level 1 preemphasis 0.
> Fix this in the driver code as well.
> v3: VSwing update (Clint)
>
> Cc: Imre Deak
> Cc: Uma Shankar
> Signed-off-by: Clint Taylor
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 140 --
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 14 ++
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
> .../drm/i915/display/intel_ddi_buf_trans.c| 36 -
> .../drm/i915/display/intel_ddi_buf_trans.h| 6 +
> .../i915/display/intel_display_power_map.c| 1 +
> 7 files changed, 192 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index c73d2bc3e1a8..3d61afbe7bdb 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -6,11 +6,15 @@
> #include "i915_reg.h"
> #include "intel_cx0_phy.h"
> #include "intel_cx0_phy_regs.h"
> +#include "intel_ddi.h"
> +#include "intel_ddi_buf_trans.h"
> #include "intel_de.h"
> #include "intel_display_types.h"
> #include "intel_dp.h"
> #include "intel_panel.h"
> #include "intel_tc.h"
> +#include "intel_psr.h"
> +#include "intel_uncore.h"
>
> bool intel_is_c10phy(struct drm_i915_private *dev_priv, enum phy phy)
> {
> @@ -20,6 +24,15 @@ bool intel_is_c10phy(struct drm_i915_private *dev_priv,
> enum phy phy)
> return false;
> }
>
> +static void
> +assert_dc_off(struct drm_i915_private *i915)
> +{
> + bool enabled;
> +
> + enabled = intel_display_power_is_enabled(i915,
> POWER_DOMAIN_DC_OFF);
> + drm_WARN_ON(>drm, !enabled);
> +}
> +
> static void intel_cx0_bus_reset(struct drm_i915_private *i915, enum port
> port,
> int lane)
> {
> enum phy phy = intel_port_to_phy(i915, port);
> @@ -112,6 +125,8 @@ static u8 intel_cx0_read(struct drm_i915_private *i915,
> enum port port,
> int i, status = 0;
> u32 val;
>
> + assert_dc_off(i915);
> +
> for (i = 0; i < 3; i++) {
> status = __intel_cx0_read(i915, port, lane, addr, );
>
> @@ -194,6 +209,8 @@ static void __intel_cx0_write(struct drm_i915_private
> *i915, enum port port,
> enum phy phy = intel_port_to_phy(i915, port);
> int i, status;
>
> + assert_dc_off(i915);
> +
> for (i = 0; i < 3; i++) {
> status = __intel_cx0_write_once(i915, port, lane, addr, data,
> committed);
>
> @@ -241,6 +258,89 @@ static void intel_cx0_rmw(struct drm_i915_private
> *i915, enum port port,
> }
> }
>
> +/*
> + * Prepare HW for CX0 phy transactions.
> + *
> + * It is required that PSR and DC5/6 are disabled before any CX0 message
> + * bus transaction is executed.
> + */
> +static intel_wakeref_t intel_cx0_phy_transaction_begin(struct intel_encoder
> *encoder)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + intel_psr_pause(intel_dp);
> + return intel_display_power_get(i915, POWER_DOMAIN_DC_OFF);
> +}
> +
> +static void intel_cx0_phy_transaction_end(struct intel_encoder *encoder,
> intel_wakeref_t wakeref)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_dp *intel_dp = enc_to_intel_dp(encoder);
> +
> + intel_psr_resume(intel_dp);
> + intel_display_power_put(i915, POWER_DOMAIN_DC_OFF, wakeref);
> +}
> +
> +void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> + bool lane_reversal = dig_port->saved_port_bits &
> DDI_BUF_PORT_REVERSAL;
> + u8 master_lane = lane_reversal ? INTEL_CX0_LANE1 :
> + INTEL_CX0_LANE0;
> + u8 follower_lane = lane_reversal ? INTEL_CX0_LANE0 :
> + INTEL_CX0_LANE1;
> + const struct intel_ddi_buf_trans *trans;
> + intel_wakeref_t wakeref;
> + int n_entries, ln;
> +
> + wakeref = intel_cx0_phy_transaction_begin(encoder);
> +
> + trans =
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Fix idle pattern enabling
On Tue, Feb 14, 2023 at 03:43:48PM +0200, Ville Syrjala wrote:
> 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.
HSW seems to require it also for SST, but yes for all other platforms
bspec only requires it for MST. The DP2.1 standard has some addition
(3.5.1.2.6) referring to idle pattern to be sent after TPS even for SST.
Not sure if this would be done automatically by HW w/o manually
switching to it.
> 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
>
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Don't send idle pattern after DP2.0 link training
On Tue, Feb 14, 2023 at 03:43:47PM +0200, Ville Syrjala wrote: > 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ä Reviewed-by: Imre Deak > --- > 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 >
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Don't switch to TPS1 when disabling DP_TP_CTL
On Tue, Feb 14, 2023 at 03:43:46PM +0200, Ville Syrjala wrote:
> 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ä
Reviewed-by: Imre Deak
> ---
> 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 6/6] drm/i915/clock: mass rename dev_priv to i915
On Wed, Mar 01, 2023 at 03:54:20PM +0200, Jani Nikula wrote:
> Follow the contemporary naming style. Include some indentation fixes
> while at it on the affected statements.
>
> One function needs to keep using dev_priv due to implicit dev_priv usage
> in a macro.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_clock_gating.c | 589 +++---
> 1 file changed, 296 insertions(+), 293 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_clock_gating.c
> b/drivers/gpu/drm/i915/intel_clock_gating.c
> index 8cfc19b48760..2c5302bcba19 100644
> --- a/drivers/gpu/drm/i915/intel_clock_gating.c
> +++ b/drivers/gpu/drm/i915/intel_clock_gating.c
> @@ -44,9 +44,9 @@ struct drm_i915_clock_gating_funcs {
> void (*init_clock_gating)(struct drm_i915_private *i915);
> };
>
> -static void gen9_init_clock_gating(struct drm_i915_private *dev_priv)
> +static void gen9_init_clock_gating(struct drm_i915_private *i915)
> {
> - if (HAS_LLC(dev_priv)) {
> + if (HAS_LLC(i915)) {
> /*
>* WaCompressedResourceDisplayNewHashMode:skl,kbl
>* Display WA #0390: skl,kbl
> @@ -54,41 +54,42 @@ static void gen9_init_clock_gating(struct
> drm_i915_private *dev_priv)
>* Must match Sampler, Pixel Back End, and Media. See
>* WaCompressedResourceSamplerPbeMediaNewHashMode.
>*/
> - intel_uncore_rmw(_priv->uncore, CHICKEN_PAR1_1, 0,
> SKL_DE_COMPRESSED_HASH_MODE);
> + intel_uncore_rmw(>uncore, CHICKEN_PAR1_1, 0,
> SKL_DE_COMPRESSED_HASH_MODE);
> }
>
> /* See Bspec note for PSR2_CTL bit 31, Wa#828:skl,bxt,kbl,cfl */
> - intel_uncore_rmw(_priv->uncore, CHICKEN_PAR1_1, 0,
> SKL_EDP_PSR_FIX_RDWRAP);
> + intel_uncore_rmw(>uncore, CHICKEN_PAR1_1, 0,
> SKL_EDP_PSR_FIX_RDWRAP);
>
> /* WaEnableChickenDCPR:skl,bxt,kbl,glk,cfl */
> - intel_uncore_rmw(_priv->uncore, GEN8_CHICKEN_DCPR_1, 0,
> MASK_WAKEMEM);
> + intel_uncore_rmw(>uncore, GEN8_CHICKEN_DCPR_1, 0, MASK_WAKEMEM);
>
> /*
>* WaFbcWakeMemOn:skl,bxt,kbl,glk,cfl
>* Display WA #0859: skl,bxt,kbl,glk,cfl
>*/
> - intel_uncore_rmw(_priv->uncore, DISP_ARB_CTL, 0,
> DISP_FBC_MEMORY_WAKE);
> + intel_uncore_rmw(>uncore, DISP_ARB_CTL, 0, DISP_FBC_MEMORY_WAKE);
> }
>
> -static void bxt_init_clock_gating(struct drm_i915_private *dev_priv)
> +static void bxt_init_clock_gating(struct drm_i915_private *i915)
> {
> - gen9_init_clock_gating(dev_priv);
> + gen9_init_clock_gating(i915);
>
> /* WaDisableSDEUnitClockGating:bxt */
> - intel_uncore_rmw(_priv->uncore, GEN8_UCGCTL6, 0,
> GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
> + intel_uncore_rmw(>uncore, GEN8_UCGCTL6, 0,
> GEN8_SDEUNIT_CLOCK_GATE_DISABLE);
>
> /*
>* FIXME:
>* GEN8_HDCUNIT_CLOCK_GATE_DISABLE_HDCREQ applies on 3x6 GT SKUs only.
>*/
> - intel_uncore_rmw(_priv->uncore, GEN8_UCGCTL6, 0,
> GEN8_HDCUNIT_CLOCK_GATE_DISABLE_HDCREQ);
> + intel_uncore_rmw(>uncore, GEN8_UCGCTL6, 0,
> GEN8_HDCUNIT_CLOCK_GATE_DISABLE_HDCREQ);
>
> /*
>* Wa: Backlight PWM may stop in the asserted state, causing backlight
>* to stay fully on.
>*/
> - intel_uncore_write(_priv->uncore, GEN9_CLKGATE_DIS_0,
> intel_uncore_read(_priv->uncore, GEN9_CLKGATE_DIS_0) |
> -PWM1_GATING_DIS | PWM2_GATING_DIS);
> + intel_uncore_write(>uncore, GEN9_CLKGATE_DIS_0,
> +intel_uncore_read(>uncore, GEN9_CLKGATE_DIS_0)
> |
> +PWM1_GATING_DIS | PWM2_GATING_DIS);
>
> /*
>* Lower the display internal timeout.
> @@ -96,42 +97,43 @@ static void bxt_init_clock_gating(struct drm_i915_private
> *dev_priv)
>* is off and a MMIO access is attempted by any privilege
>* application, using batch buffers or any other means.
>*/
> - intel_uncore_write(_priv->uncore, RM_TIMEOUT, MMIO_TIMEOUT_US(950));
> + intel_uncore_write(>uncore, RM_TIMEOUT, MMIO_TIMEOUT_US(950));
>
> /*
>* WaFbcTurnOffFbcWatermark:bxt
>* Display WA #0562: bxt
>*/
> - intel_uncore_rmw(_priv->uncore, DISP_ARB_CTL, 0, DISP_FBC_WM_DIS);
> + intel_uncore_rmw(>uncore, DISP_ARB_CTL, 0, DISP_FBC_WM_DIS);
>
> /*
>* WaFbcHighMemBwCorruptionAvoidance:bxt
>* Display WA #0883: bxt
>*/
> - intel_uncore_rmw(_priv->uncore, ILK_DPFC_CHICKEN(INTEL_FBC_A), 0,
> DPFC_DISABLE_DUMMY0);
> + intel_uncore_rmw(>uncore, ILK_DPFC_CHICKEN(INTEL_FBC_A), 0,
> DPFC_DISABLE_DUMMY0);
> }
>
> -static void glk_init_clock_gating(struct drm_i915_private *dev_priv)
> +static void glk_init_clock_gating(struct drm_i915_private *i915)
> {
> - gen9_init_clock_gating(dev_priv);
> + gen9_init_clock_gating(i915);
>
> /*
>* WaDisablePWMClockGating:glk
>* Backlight PWM may stop in the
Re: [Intel-gfx] [PATCH 5/6] drm/i915: rename intel_pm.[ch] to intel_clock_gating.[ch]
On Wed, Mar 01, 2023 at 03:54:19PM +0200, Jani Nikula wrote:
> Observe that intel_pm.[ch] is now purely about clock gating, so rename
> them to intel_clock_gating.[ch]. Rename the functions to
> intel_clock_gating_*() to follow coding conventions.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/Makefile | 2 +-
> drivers/gpu/drm/i915/display/intel_display.c | 4 ++--
> drivers/gpu/drm/i915/i915_driver.c | 8
> drivers/gpu/drm/i915/i915_gem.c| 8
> .../i915/{intel_pm.c => intel_clock_gating.c} | 8
> drivers/gpu/drm/i915/intel_clock_gating.h | 14 ++
> drivers/gpu/drm/i915/intel_pm.h| 18 --
> drivers/gpu/drm/i915/vlv_suspend.c | 4 ++--
> 8 files changed, 31 insertions(+), 35 deletions(-)
> rename drivers/gpu/drm/i915/{intel_pm.c => intel_clock_gating.c} (99%)
> create mode 100644 drivers/gpu/drm/i915/intel_clock_gating.h
> delete mode 100644 drivers/gpu/drm/i915/intel_pm.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index b2f91a1f8268..b88df8c10781 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -47,10 +47,10 @@ i915-y += i915_driver.o \
> i915_switcheroo.o \
> i915_sysfs.o \
> i915_utils.o \
> + intel_clock_gating.o \
> intel_device_info.o \
> intel_memory_region.o \
> intel_pcode.o \
> - intel_pm.o \
> intel_region_ttm.o \
> intel_runtime_pm.o \
> intel_sbi.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index a1fbdf32bd21..3f1b90a2f57c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -63,6 +63,7 @@
> #include "intel_audio.h"
> #include "intel_bw.h"
> #include "intel_cdclk.h"
> +#include "intel_clock_gating.h"
> #include "intel_color.h"
> #include "intel_crt.h"
> #include "intel_crtc.h"
> @@ -105,7 +106,6 @@
> #include "intel_pcode.h"
> #include "intel_pipe_crc.h"
> #include "intel_plane_initial.h"
> -#include "intel_pm.h"
> #include "intel_pps.h"
> #include "intel_psr.h"
> #include "intel_quirks.h"
> @@ -850,7 +850,7 @@ void intel_display_finish_reset(struct drm_i915_private
> *i915)
>*/
> intel_pps_unlock_regs_wa(i915);
> intel_modeset_init_hw(i915);
> - intel_init_clock_gating(i915);
> + intel_clock_gating_init(i915);
> intel_hpd_init(i915);
>
> ret = __intel_display_resume(i915, state, ctx);
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index a53fd339e2cc..e4809485e47c 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -79,11 +79,11 @@
> #include "soc/intel_dram.h"
> #include "soc/intel_gmch.h"
>
> -#include "i915_file_private.h"
> #include "i915_debugfs.h"
> #include "i915_driver.h"
> #include "i915_drm_client.h"
> #include "i915_drv.h"
> +#include "i915_file_private.h"
> #include "i915_getparam.h"
> #include "i915_hwmon.h"
> #include "i915_ioc32.h"
> @@ -97,11 +97,11 @@
> #include "i915_sysfs.h"
> #include "i915_utils.h"
> #include "i915_vgpu.h"
> +#include "intel_clock_gating.h"
> #include "intel_gvt.h"
> #include "intel_memory_region.h"
> #include "intel_pci_config.h"
> #include "intel_pcode.h"
> -#include "intel_pm.h"
> #include "intel_region_ttm.h"
> #include "vlv_suspend.h"
>
> @@ -252,7 +252,7 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
>
> intel_irq_init(dev_priv);
> intel_init_display_hooks(dev_priv);
> - intel_init_clock_gating_hooks(dev_priv);
> + intel_clock_gating_hooks_init(dev_priv);
>
> intel_detect_preproduction_hw(dev_priv);
>
> @@ -1238,7 +1238,7 @@ static int i915_drm_resume(struct drm_device *dev)
> i915_gem_resume(dev_priv);
>
> intel_modeset_init_hw(dev_priv);
> - intel_init_clock_gating(dev_priv);
> + intel_clock_gating_init(dev_priv);
> intel_hpd_init(dev_priv);
>
> /* MST sideband requires HPD interrupts enabled */
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 35950fa91406..6b6b0e575ef3 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -58,7 +58,7 @@
> #include "i915_file_private.h"
> #include "i915_trace.h"
> #include "i915_vgpu.h"
> -#include "intel_pm.h"
> +#include "intel_clock_gating.h"
>
> static int
> insert_mappable_node(struct i915_ggtt *ggtt, struct drm_mm_node *node, u32
> size)
> @@ -1164,7 +1164,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
> }
>
> /*
> - * Despite its name intel_init_clock_gating applies both display
> + * Despite
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Load DMC on MTL
On Thu, Mar 02, 2023 at 12:05:50PM -0300, Gustavo Sousa wrote:
> From: Madhumitha Tolakanahalli Pradeep
>
>
> Add support to load DMC on MTL.
>
> Signed-off-by: Madhumitha Tolakanahalli Pradeep
>
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index f70ada2357dc..dedf40cb85a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -60,6 +60,10 @@
>
> #define DISPLAY_VER12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE
>
> +#define MTL_DMC_PATH DMC_PATH(mtl)
> +#define MTL_DMC_MAX_FW_SIZE 0x1
Is there a reference somewhere in the bspec for the max DMC payload
size? It seems unusual that it would have reduced from ADL to MTL,
although the payloads in the current firmware do indeed fit within this
reduced limit.
Matt
> +MODULE_FIRMWARE(MTL_DMC_PATH);
> +
> #define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08)
> MODULE_FIRMWARE(DG2_DMC_PATH);
>
> @@ -943,7 +947,10 @@ void intel_dmc_init(struct drm_i915_private *dev_priv)
>*/
> intel_dmc_runtime_pm_get(dev_priv);
>
> - if (IS_DG2(dev_priv)) {
> + if (IS_METEORLAKE(dev_priv)) {
> + dmc->fw_path = MTL_DMC_PATH;
> + dmc->max_fw_size = MTL_DMC_MAX_FW_SIZE;
> + } else if (IS_DG2(dev_priv)) {
> dmc->fw_path = DG2_DMC_PATH;
> dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
> } else if (IS_ALDERLAKE_P(dev_priv)) {
> --
> 2.39.2
>
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
Re: [Intel-gfx] [PATCH 4/6] drm/i915: remove unnecessary intel_pm.h includes
On Wed, Mar 01, 2023 at 03:54:18PM +0200, Jani Nikula wrote:
> As intel_pm.[ch] used to contain much more, intel_pm.h was included in a
> lot of places. Many of them are now unnecessary. Remove.
>
> Signed-off-by: Jani Nikula
trusting the compiler:
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/i9xx_wm.c | 1 -
> drivers/gpu/drm/i915/display/intel_display_debugfs.c | 1 -
> drivers/gpu/drm/i915/display/intel_modeset_setup.c | 1 -
> drivers/gpu/drm/i915/display/skl_watermark.c | 1 -
> drivers/gpu/drm/i915/gt/intel_gt.c | 1 -
> drivers/gpu/drm/i915/gt/intel_gt_pm.c| 1 -
> drivers/gpu/drm/i915/gt/selftest_llc.c | 1 -
> drivers/gpu/drm/i915/i915_debugfs.c | 1 -
> drivers/gpu/drm/i915/i915_irq.c | 1 -
> drivers/gpu/drm/i915/i915_pmu.c | 1 -
> drivers/gpu/drm/i915/i915_request.c | 1 -
> drivers/gpu/drm/i915/i915_sysfs.c| 1 -
> drivers/gpu/drm/i915/intel_uncore.c | 1 -
> 13 files changed, 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/i9xx_wm.c
> b/drivers/gpu/drm/i915/display/i9xx_wm.c
> index 3d4687efe4dd..caef72d38798 100644
> --- a/drivers/gpu/drm/i915/display/i9xx_wm.c
> +++ b/drivers/gpu/drm/i915/display/i9xx_wm.c
> @@ -9,7 +9,6 @@
> #include "intel_display.h"
> #include "intel_display_trace.h"
> #include "intel_mchbar_regs.h"
> -#include "intel_pm.h"
> #include "intel_wm.h"
> #include "skl_watermark.h"
> #include "vlv_sideband.h"
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 25013f303c82..1e654ddd0815 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -26,7 +26,6 @@
> #include "intel_hdmi.h"
> #include "intel_hotplug.h"
> #include "intel_panel.h"
> -#include "intel_pm.h"
> #include "intel_psr.h"
> #include "intel_sprite.h"
> #include "intel_wm.h"
> diff --git a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> index 60f71e6f0491..7ff083ec2d1d 100644
> --- a/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> +++ b/drivers/gpu/drm/i915/display/intel_modeset_setup.c
> @@ -25,7 +25,6 @@
> #include "intel_fifo_underrun.h"
> #include "intel_modeset_setup.h"
> #include "intel_pch_display.h"
> -#include "intel_pm.h"
> #include "intel_wm.h"
> #include "skl_watermark.h"
>
> diff --git a/drivers/gpu/drm/i915/display/skl_watermark.c
> b/drivers/gpu/drm/i915/display/skl_watermark.c
> index 1300965d328a..f0af997d2a23 100644
> --- a/drivers/gpu/drm/i915/display/skl_watermark.c
> +++ b/drivers/gpu/drm/i915/display/skl_watermark.c
> @@ -18,7 +18,6 @@
> #include "intel_display_types.h"
> #include "intel_fb.h"
> #include "intel_pcode.h"
> -#include "intel_pm.h"
> #include "intel_wm.h"
> #include "skl_watermark.h"
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index f7f271708fc7..6ca944d01eb6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -28,7 +28,6 @@
> #include "intel_migrate.h"
> #include "intel_mocs.h"
> #include "intel_pci_config.h"
> -#include "intel_pm.h"
> #include "intel_rc6.h"
> #include "intel_renderstate.h"
> #include "intel_rps.h"
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> index cef3d6f5c34e..85ae7dc079f2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm.c
> @@ -17,7 +17,6 @@
> #include "intel_gt_print.h"
> #include "intel_gt_requests.h"
> #include "intel_llc.h"
> -#include "intel_pm.h"
> #include "intel_rc6.h"
> #include "intel_rps.h"
> #include "intel_wakeref.h"
> diff --git a/drivers/gpu/drm/i915/gt/selftest_llc.c
> b/drivers/gpu/drm/i915/gt/selftest_llc.c
> index cfd736d88939..779fadcec7c4 100644
> --- a/drivers/gpu/drm/i915/gt/selftest_llc.c
> +++ b/drivers/gpu/drm/i915/gt/selftest_llc.c
> @@ -3,7 +3,6 @@
> * Copyright © 2019 Intel Corporation
> */
>
> -#include "intel_pm.h" /* intel_gpu_freq() */
> #include "selftest_llc.h"
> #include "intel_rps.h"
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 45773ce1deac..16011c0286ad 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -52,7 +52,6 @@
> #include "i915_irq.h"
> #include "i915_scheduler.h"
> #include "intel_mchbar_regs.h"
> -#include "intel_pm.h"
>
> static inline struct drm_i915_private *node_to_i915(struct drm_info_node
> *node)
> {
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index 417c981e4968..6ce3c934d832 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@
Re: [Intel-gfx] [PATCH 3/6] drm/i915/pm: drop intel_suspend_hw()
On Wed, Mar 01, 2023 at 03:54:17PM +0200, Jani Nikula wrote:
> All intel_suspend_hw() does is clear PCH_LP_PARTITION_LEVEL_DISABLE bit
> in SOUTH_DSPCLK_GATE_D for LPT LP. intel_suspend_hw() gets called from
> i915_drm_suspend().
>
> However, i915_drm_suspend_late() calls
> intel_display_power_suspend_late(), which in turn calls hsw_enable_pc8()
> on HSW and BDW. The first thing that does is clear
> PCH_LP_PARTITION_LEVEL_DISABLE bit in SOUTH_DSPCLK_GATE_D.
For a moment I thought that the if HSW || BDW on the other call would
make some difference, but then I confirmed on intel_pch.c that only
HSW and BDW has PCH_LPT anyway. So,
Reviewed-by: Rodrigo Vivi
>
> Remove the duplicated clearing of the bit, effectively delaying it from
> i915_drm_suspend() to i915_drm_suspend_late(), and remove the
> unnecessary intel_suspend_hw() function altogether.
>
> Cc: Imre Deak
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/i915_driver.c | 2 --
> drivers/gpu/drm/i915/intel_pm.c| 16
> drivers/gpu/drm/i915/intel_pm.h| 1 -
> 3 files changed, 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 171ff4edabd6..a53fd339e2cc 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -1079,8 +1079,6 @@ static int i915_drm_suspend(struct drm_device *dev)
>
> intel_suspend_encoders(dev_priv);
>
> - intel_suspend_hw(dev_priv);
> -
> /* Must be called before GGTT is suspended. */
> intel_dpt_suspend(dev_priv);
> i915_ggtt_suspend(to_gt(dev_priv)->ggtt);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 8b02af531e82..c45af0d981fd 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -320,16 +320,6 @@ static void lpt_init_clock_gating(struct
> drm_i915_private *dev_priv)
>0, TRANS_CHICKEN1_DP0UNIT_GC_DISABLE);
> }
>
> -static void lpt_suspend_hw(struct drm_i915_private *dev_priv)
> -{
> - if (HAS_PCH_LPT_LP(dev_priv)) {
> - u32 val = intel_uncore_read(_priv->uncore,
> SOUTH_DSPCLK_GATE_D);
> -
> - val &= ~PCH_LP_PARTITION_LEVEL_DISABLE;
> - intel_uncore_write(_priv->uncore, SOUTH_DSPCLK_GATE_D, val);
> - }
> -}
> -
> static void gen8_set_l3sqc_credits(struct drm_i915_private *dev_priv,
> int general_prio_credits,
> int high_prio_credits)
> @@ -789,12 +779,6 @@ void intel_init_clock_gating(struct drm_i915_private
> *dev_priv)
> dev_priv->clock_gating_funcs->init_clock_gating(dev_priv);
> }
>
> -void intel_suspend_hw(struct drm_i915_private *dev_priv)
> -{
> - if (HAS_PCH_LPT(dev_priv))
> - lpt_suspend_hw(dev_priv);
> -}
> -
> static void nop_init_clock_gating(struct drm_i915_private *dev_priv)
> {
> drm_dbg_kms(_priv->drm,
> diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
> index 1dd464d2d186..f774bddcdca6 100644
> --- a/drivers/gpu/drm/i915/intel_pm.h
> +++ b/drivers/gpu/drm/i915/intel_pm.h
> @@ -13,7 +13,6 @@ struct intel_crtc_state;
> struct intel_plane_state;
>
> void intel_init_clock_gating(struct drm_i915_private *dev_priv);
> -void intel_suspend_hw(struct drm_i915_private *dev_priv);
> void intel_init_clock_gating_hooks(struct drm_i915_private *dev_priv);
>
> #endif /* __INTEL_PM_H__ */
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH 2/6] drm/i915/pm: drop intel_pm_setup()
On Wed, Mar 01, 2023 at 03:54:16PM +0200, Jani Nikula wrote:
> All the init in intel_pm_setup() is related to runtime pm. Move them to
> intel_runtime_pm_init_early(), and remove intel_pm_setup().
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_driver.c | 1 -
> drivers/gpu/drm/i915/intel_pm.c | 6 --
> drivers/gpu/drm/i915/intel_pm.h | 1 -
> drivers/gpu/drm/i915/intel_runtime_pm.c | 2 ++
> 4 files changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 8bc76dede332..171ff4edabd6 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -250,7 +250,6 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> /* This must be called before any calls to HAS_PCH_* */
> intel_detect_pch(dev_priv);
>
> - intel_pm_setup(dev_priv);
> intel_irq_init(dev_priv);
> intel_init_display_hooks(dev_priv);
> intel_init_clock_gating_hooks(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ddf004e5bb4b..8b02af531e82 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -899,9 +899,3 @@ void intel_init_clock_gating_hooks(struct
> drm_i915_private *dev_priv)
> dev_priv->clock_gating_funcs = _clock_gating_funcs;
> }
> }
> -
> -void intel_pm_setup(struct drm_i915_private *dev_priv)
> -{
> - dev_priv->runtime_pm.suspended = false;
> - atomic_set(_priv->runtime_pm.wakeref_count, 0);
> -}
> diff --git a/drivers/gpu/drm/i915/intel_pm.h b/drivers/gpu/drm/i915/intel_pm.h
> index eab60df0c6bb..1dd464d2d186 100644
> --- a/drivers/gpu/drm/i915/intel_pm.h
> +++ b/drivers/gpu/drm/i915/intel_pm.h
> @@ -15,6 +15,5 @@ struct intel_plane_state;
> void intel_init_clock_gating(struct drm_i915_private *dev_priv);
> void intel_suspend_hw(struct drm_i915_private *dev_priv);
> void intel_init_clock_gating_hooks(struct drm_i915_private *dev_priv);
> -void intel_pm_setup(struct drm_i915_private *dev_priv);
>
> #endif /* __INTEL_PM_H__ */
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 129746713d07..cf5122299b6b 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -652,6 +652,8 @@ void intel_runtime_pm_init_early(struct intel_runtime_pm
> *rpm)
>
> rpm->kdev = kdev;
> rpm->available = HAS_RUNTIME_PM(i915);
> + rpm->suspended = false;
> + atomic_set(>wakeref_count, 0);
>
> init_intel_runtime_pm_wakeref(rpm);
> INIT_LIST_HEAD(>lmem_userfault_list);
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH 1/6] drm/i915/wm: remove display/ prefix from include
On Wed, Mar 01, 2023 at 03:54:15PM +0200, Jani Nikula wrote:
> Remove the leftover from moving and renaming the file from driver top
> level.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/display/intel_wm_types.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_wm_types.h
> b/drivers/gpu/drm/i915/display/intel_wm_types.h
> index bac2b6fdc5d0..628b7c0ce484 100644
> --- a/drivers/gpu/drm/i915/display/intel_wm_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_wm_types.h
> @@ -8,7 +8,7 @@
>
> #include
>
> -#include "display/intel_display_limits.h"
> +#include "intel_display_limits.h"
>
> enum intel_ddb_partitioning {
> INTEL_DDB_PART_1_2,
> --
> 2.39.1
>
Re: [Intel-gfx] [PATCH] drm/i915/dmc: Load DMC on MTL
On Thu, Mar 02, 2023 at 12:05:50PM -0300, Gustavo Sousa wrote:
> From: Madhumitha Tolakanahalli Pradeep
>
>
> Add support to load DMC on MTL.
>
> Signed-off-by: Madhumitha Tolakanahalli Pradeep
>
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 9 -
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index f70ada2357dc..dedf40cb85a2 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -60,6 +60,10 @@
>
> #define DISPLAY_VER12_DMC_MAX_FW_SIZEICL_DMC_MAX_FW_SIZE
>
> +#define MTL_DMC_PATH DMC_PATH(mtl)
> +#define MTL_DMC_MAX_FW_SIZE 0x1
I thought the goal was to sync on the display_verN_*_size...
Why is MTL size so different than the similar versions?
If being different is still a thing, why were we adding the
version sizes above and simply not go with the individual platform
then?
Btw, do we get the max size from spec or from the dmc release notes?
Thanks,
Rodrigo.
> +MODULE_FIRMWARE(MTL_DMC_PATH);
> +
> #define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08)
> MODULE_FIRMWARE(DG2_DMC_PATH);
>
> @@ -943,7 +947,10 @@ void intel_dmc_init(struct drm_i915_private *dev_priv)
>*/
> intel_dmc_runtime_pm_get(dev_priv);
>
> - if (IS_DG2(dev_priv)) {
> + if (IS_METEORLAKE(dev_priv)) {
> + dmc->fw_path = MTL_DMC_PATH;
> + dmc->max_fw_size = MTL_DMC_MAX_FW_SIZE;
> + } else if (IS_DG2(dev_priv)) {
> dmc->fw_path = DG2_DMC_PATH;
> dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
> } else if (IS_ALDERLAKE_P(dev_priv)) {
> --
> 2.39.2
>
Re: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM DEMAND
> -Original Message-
> From: Intel-gfx On Behalf Of Kahola,
> Mika
> Sent: Thursday, March 2, 2023 1:40 AM
> To: Murthy, Arun R ; intel-gfx@lists.freedesktop.org
> Cc: Roper, Matthew D ; De Marchi, Lucas
>
> Subject: Re: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM
> DEMAND
>
> > -Original Message-
> > From: Murthy, Arun R
> > Sent: Thursday, March 2, 2023 10:50 AM
> > To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> > Cc: De Marchi, Lucas ; Roper, Matthew D
> >
> > Subject: RE: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM
> > DEMAND
> >
> > > -Original Message-
> > > From: Intel-gfx On Behalf Of
> > > Mika Kahola
> > > Sent: Friday, February 24, 2023 3:44 PM
> > > To: intel-gfx@lists.freedesktop.org
> > > Cc: De Marchi, Lucas ; Roper, Matthew D
> > >
> > > Subject: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM
> > > DEMAND
> > >
> > > Display14 introduces a new way to instruct the PUnit with power and
> > > bandwidth requirements of DE. Add the functionality to program the
> > > registers and handle waits using interrupts.
> > > The current wait time for timeouts is programmed for 10 msecs to
> > > factor in the worst case scenarios. Changes made to use REG_BIT for a
> > > register that we touched(GEN8_DE_MISC_IER _MMIO).
> > >
> > > v2:
> > > - Removed repeated definition of dbuf, which has been moved to struct
> > > intel_display. (Gustavo)
> > > - s/dev_priv->dbuf/dev_priv->display.dbuf/ (Gustavo)
> > >
> > > Bspec: 66451, 64636, 64602, 64603
> > > Cc: Matt Atwood
> > > Cc: Matt Roper
> > > Cc: Lucas De Marchi
> > > Cc: Gustavo Sousa
> > > Signed-off-by: José Roberto de Souza
> > > Signed-off-by: Radhakrishna Sripada
> > > Link:
> > > https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-
> 8-
> > > mika.kah...@intel.com
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bw.c | 4 +-
> > > drivers/gpu/drm/i915/display/intel_bw.h | 2 +
> > > drivers/gpu/drm/i915/display/intel_display.c | 14 +
> > > .../drm/i915/display/intel_display_power.c| 8 +
> > > drivers/gpu/drm/i915/i915_drv.h | 6 +
> > > drivers/gpu/drm/i915/i915_irq.c | 22 +-
> > > drivers/gpu/drm/i915/i915_reg.h | 33 +-
> > > drivers/gpu/drm/i915/intel_pm.c | 286 ++
> > > drivers/gpu/drm/i915/intel_pm.h | 35 +++
> > > 9 files changed, 405 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > > b/drivers/gpu/drm/i915/display/intel_bw.c
> > > index 202321ffbe2a..87c20bf52123 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > > @@ -746,8 +746,8 @@ static unsigned int
> > > intel_bw_num_active_planes(struct drm_i915_private *dev_priv
> > > return num_active_planes;
> > > }
> > >
> > > -static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > > -const struct intel_bw_state *bw_state)
> > > +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > > + const struct intel_bw_state *bw_state)
> > > {
> > > unsigned int data_rate = 0;
> > > enum pipe pipe;
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > > b/drivers/gpu/drm/i915/display/intel_bw.h
> > > index f20292143745..17fc0b61db04 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > > @@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private
> > > *dev_priv); int intel_bw_atomic_check(struct intel_atomic_state
> > > *state); void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> > > const struct intel_crtc_state *crtc_state);
> > > +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > > + const struct intel_bw_state *bw_state);
> > > int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> > > u32 points_mask);
> > > int intel_bw_calc_min_cdclk(struct intel_atomic_state *state, diff
> > > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > index 8030968e7008..676bf512b9ce 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > @@ -959,6 +959,9 @@ intel_get_crtc_new_encoder(const struct
> > > intel_atomic_state *state,
> > > num_encoders++;
> > > }
> > >
> > > + if (!encoder)
> > > + return NULL;
> > > +
> > > drm_WARN(encoder->base.dev, num_encoders != 1,
> > >"%d encoders for pipe %c\n",
> > >num_encoders, pipe_name(master_crtc->pipe)); @@ -
> > > 6823,6 +6826,10 @@ int intel_atomic_check(struct drm_device *dev,
> > > ret = intel_modeset_calc_cdclk(state);
> > > if (ret)
> > >
Re: [Intel-gfx] [PATCH] drm/i915/rps: split out display rps parts to a separate file
On Thu, Mar 02, 2023 at 06:49:36PM +0200, Jani Nikula wrote:
> Split out the RPS parts so they can be conditionally compiled out later.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../gpu/drm/i915/display/intel_atomic_plane.c | 79 ++
> .../gpu/drm/i915/display/intel_display_rps.c | 81 +++
> .../gpu/drm/i915/display/intel_display_rps.h | 22 +
> 4 files changed, 111 insertions(+), 72 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_display_rps.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_display_rps.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index b2f91a1f8268..8e46f57e4569 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -239,6 +239,7 @@ i915-y += \
> display/intel_display_power.o \
> display/intel_display_power_map.o \
> display/intel_display_power_well.o \
> + display/intel_display_rps.o \
> display/intel_dmc.o \
> display/intel_dpio_phy.o \
> display/intel_dpll.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 3bd8f7eb75a6..719a60e278f3 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -34,11 +34,10 @@
> #include
> #include
>
> -#include "gt/intel_rps.h"
> -
> #include "i915_config.h"
> #include "intel_atomic_plane.h"
> #include "intel_cdclk.h"
> +#include "intel_display_rps.h"
> #include "intel_display_trace.h"
> #include "intel_display_types.h"
> #include "intel_fb.h"
> @@ -941,64 +940,6 @@ int intel_atomic_plane_check_clipping(struct
> intel_plane_state *plane_state,
> return 0;
> }
>
> -struct wait_rps_boost {
> - struct wait_queue_entry wait;
> -
> - struct drm_crtc *crtc;
> - struct i915_request *request;
> -};
> -
> -static int do_rps_boost(struct wait_queue_entry *_wait,
> - unsigned mode, int sync, void *key)
> -{
> - struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait);
> - struct i915_request *rq = wait->request;
> -
> - /*
> - * If we missed the vblank, but the request is already running it
> - * is reasonable to assume that it will complete before the next
> - * vblank without our intervention, so leave RPS alone.
> - */
> - if (!i915_request_started(rq))
> - intel_rps_boost(rq);
> - i915_request_put(rq);
> -
> - drm_crtc_vblank_put(wait->crtc);
> -
> - list_del(>wait.entry);
> - kfree(wait);
> - return 1;
> -}
> -
> -static void add_rps_boost_after_vblank(struct drm_crtc *crtc,
> -struct dma_fence *fence)
> -{
> - struct wait_rps_boost *wait;
> -
> - if (!dma_fence_is_i915(fence))
> - return;
> -
> - if (DISPLAY_VER(to_i915(crtc->dev)) < 6)
> - return;
> -
> - if (drm_crtc_vblank_get(crtc))
> - return;
> -
> - wait = kmalloc(sizeof(*wait), GFP_KERNEL);
> - if (!wait) {
> - drm_crtc_vblank_put(crtc);
> - return;
> - }
> -
> - wait->request = to_request(dma_fence_get(fence));
> - wait->crtc = crtc;
> -
> - wait->wait.func = do_rps_boost;
> - wait->wait.flags = 0;
> -
> - add_wait_queue(drm_crtc_vblank_waitqueue(crtc), >wait);
> -}
> -
> /**
> * intel_prepare_plane_fb - Prepare fb for usage on plane
> * @_plane: drm plane to prepare for
> @@ -1089,13 +1030,13 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
> dma_resv_iter_begin(, obj->base.resv,
> DMA_RESV_USAGE_WRITE);
> dma_resv_for_each_fence_unlocked(, fence) {
> - add_rps_boost_after_vblank(new_plane_state->hw.crtc,
> -fence);
> +
> intel_display_rps_boost_after_vblank(new_plane_state->hw.crtc,
> + fence);
> }
> dma_resv_iter_end();
> } else {
> - add_rps_boost_after_vblank(new_plane_state->hw.crtc,
> -new_plane_state->uapi.fence);
> + intel_display_rps_boost_after_vblank(new_plane_state->hw.crtc,
> +
> new_plane_state->uapi.fence);
> }
>
> /*
> @@ -1106,10 +1047,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
>* that are not quite steady state without resorting to forcing
>* maximum clocks following a vblank miss (see do_rps_boost()).
>*/
> - if (!state->rps_interactive) {
> - intel_rps_mark_interactive(_gt(dev_priv)->rps, true);
> - state->rps_interactive = true;
> - }
> +
Re: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test
Hi Thomas, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/drm-tests-Suballocator-test/20230302-163704 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip patch link: https://lore.kernel.org/r/20230302083422.76608-1-thomas.hellstrom%40linux.intel.com patch subject: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test config: arm-allmodconfig (https://download.01.org/0day-ci/archive/20230303/202303030052.ybiikxrn-...@intel.com/config) compiler: arm-linux-gnueabi-gcc (GCC) 12.1.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/e970911bccf3145b76cd755e2d78c0c0f7f22ca1 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Thomas-Hellstr-m/drm-tests-Suballocator-test/20230302-163704 git checkout e970911bccf3145b76cd755e2d78c0c0f7f22ca1 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arm olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=arm SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202303030052.ybiikxrn-...@intel.com/ All errors (new ones prefixed by >>, old ones prefixed by <<): >> ERROR: modpost: "__aeabi_uldivmod" >> [drivers/gpu/drm/tests/drm_suballoc_test.ko] undefined! -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/rps: split out display rps parts to a separate file
== Series Details == Series: drm/i915/rps: split out display rps parts to a separate file URL : https://patchwork.freedesktop.org/series/114581/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:148:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:150:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:154:26: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:156:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:174:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:176:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:180:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:182:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:186:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:188:9: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:192:35: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:16: warning: unreplaced symbol 'oldbit' +./arch/x86/include/asm/bitops.h:195:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:237:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:239:9: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:66:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:92:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:100:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:100:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:100:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:105:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:107:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:108:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:109:9: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:111:14: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:111:20: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:17: warning: unreplaced symbol 'old' +./include/asm-generic/bitops/generic-non-atomic.h:112:23: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:112:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:121:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:128:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:166:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:168:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:169:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:170:9: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:19: warning: unreplaced symbol 'val' +./include/asm-generic/bitops/generic-non-atomic.h:172:25: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:172:9: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:28:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:30:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:31:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:33:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:37:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:39:9: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:40:9: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:10: warning: unreplaced symbol 'p' +./include/asm-generic/bitops/generic-non-atomic.h:42:16: warning: unreplaced symbol 'mask' +./include/asm-generic/bitops/generic-non-atomic.h:55:1: warning: unreplaced symbol 'return' +./include/asm-generic/bitops/generic-non-atomic.h:57:9: warning: unreplaced symbol 'mask'
Re: [Intel-gfx] [PATCH] drm/i915/debugfs: move IPS debugfs to hsw_ips.c
On Thu, 02 Mar 2023, Ville Syrjälä wrote:
> On Thu, Mar 02, 2023 at 06:16:17PM +0200, Jani Nikula wrote:
>> Follow the style of placing debugfs next to the implementation.
>>
>> Signed-off-by: Jani Nikula
>
> Reviewed-by: Ville Syrjälä
Thanks!
> Some ideas for future enhancements:
> - only register when IPS is actually supported
> - make it per-crtc since IPS only exists on pipe A
> - report the software state of IPS enable vs. disable
> - there's a false color bit just like with fbc, could
> hook that up to help verify that it actually works
Yeah, I considered that, but since
#define HAS_IPS(dev_priv) (IS_HSW_ULT(dev_priv) || IS_BROADWELL(dev_priv))
it's not really high up on the list of things to do... indeed I wanted
to stow this away in hsw_ips.[ch] because of that.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/i915/display/hsw_ips.c| 37 +++
>> drivers/gpu/drm/i915/display/hsw_ips.h| 2 +
>> .../drm/i915/display/intel_display_debugfs.c | 30 +--
>> 3 files changed, 41 insertions(+), 28 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c
>> b/drivers/gpu/drm/i915/display/hsw_ips.c
>> index 83aa3800245f..2910f5d0f3e2 100644
>> --- a/drivers/gpu/drm/i915/display/hsw_ips.c
>> +++ b/drivers/gpu/drm/i915/display/hsw_ips.c
>> @@ -267,3 +267,40 @@ void hsw_ips_get_config(struct intel_crtc_state
>> *crtc_state)
>> crtc_state->ips_enabled = true;
>> }
>> }
>> +
>> +static int hsw_ips_debugfs_status_show(struct seq_file *m, void *unused)
>> +{
>> +struct drm_i915_private *i915 = m->private;
>> +intel_wakeref_t wakeref;
>> +
>> +if (!HAS_IPS(i915))
>> +return -ENODEV;
>> +
>> +wakeref = intel_runtime_pm_get(>runtime_pm);
>> +
>> +seq_printf(m, "Enabled by kernel parameter: %s\n",
>> + str_yes_no(i915->params.enable_ips));
>> +
>> +if (DISPLAY_VER(i915) >= 8) {
>> +seq_puts(m, "Currently: unknown\n");
>> +} else {
>> +if (intel_de_read(i915, IPS_CTL) & IPS_ENABLE)
>> +seq_puts(m, "Currently: enabled\n");
>> +else
>> +seq_puts(m, "Currently: disabled\n");
>> +}
>> +
>> +intel_runtime_pm_put(>runtime_pm, wakeref);
>> +
>> +return 0;
>> +}
>> +
>> +DEFINE_SHOW_ATTRIBUTE(hsw_ips_debugfs_status);
>> +
>> +void hsw_ips_debugfs_register(struct drm_i915_private *i915)
>> +{
>> +struct drm_minor *minor = i915->drm.primary;
>> +
>> +debugfs_create_file("i915_ips_status", 0444, minor->debugfs_root,
>> +i915, _ips_debugfs_status_fops);
>> +}
>> diff --git a/drivers/gpu/drm/i915/display/hsw_ips.h
>> b/drivers/gpu/drm/i915/display/hsw_ips.h
>> index 4564dee497d7..7ed6061874f7 100644
>> --- a/drivers/gpu/drm/i915/display/hsw_ips.h
>> +++ b/drivers/gpu/drm/i915/display/hsw_ips.h
>> @@ -8,6 +8,7 @@
>>
>> #include
>>
>> +struct drm_i915_private;
>> struct intel_atomic_state;
>> struct intel_crtc;
>> struct intel_crtc_state;
>> @@ -22,5 +23,6 @@ bool hsw_crtc_state_ips_capable(const struct
>> intel_crtc_state *crtc_state);
>> int hsw_ips_compute_config(struct intel_atomic_state *state,
>> struct intel_crtc *crtc);
>> void hsw_ips_get_config(struct intel_crtc_state *crtc_state);
>> +void hsw_ips_debugfs_register(struct drm_i915_private *i915);
>>
>> #endif /* __HSW_IPS_H__ */
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> index 25013f303c82..8be606bfd2b4 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> @@ -8,6 +8,7 @@
>> #include
>> #include
>>
>> +#include "hsw_ips.h"
>> #include "i915_debugfs.h"
>> #include "i915_irq.h"
>> #include "i915_reg.h"
>> @@ -49,33 +50,6 @@ static int i915_frontbuffer_tracking(struct seq_file *m,
>> void *unused)
>> return 0;
>> }
>>
>> -static int i915_ips_status(struct seq_file *m, void *unused)
>> -{
>> -struct drm_i915_private *dev_priv = node_to_i915(m->private);
>> -intel_wakeref_t wakeref;
>> -
>> -if (!HAS_IPS(dev_priv))
>> -return -ENODEV;
>> -
>> -wakeref = intel_runtime_pm_get(_priv->runtime_pm);
>> -
>> -seq_printf(m, "Enabled by kernel parameter: %s\n",
>> - str_yes_no(dev_priv->params.enable_ips));
>> -
>> -if (DISPLAY_VER(dev_priv) >= 8) {
>> -seq_puts(m, "Currently: unknown\n");
>> -} else {
>> -if (intel_de_read(dev_priv, IPS_CTL) & IPS_ENABLE)
>> -seq_puts(m, "Currently: enabled\n");
>> -else
>> -seq_puts(m, "Currently: disabled\n");
>> -}
>> -
>> -intel_runtime_pm_put(_priv->runtime_pm, wakeref);
>> -
>> -return 0;
>> -}
>> -
>> static int i915_sr_status(struct seq_file *m, void *unused)
>> {
>> struct drm_i915_private *dev_priv =
[Intel-gfx] [PATCH] drm/i915/rps: split out display rps parts to a separate file
Split out the RPS parts so they can be conditionally compiled out later.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 1 +
.../gpu/drm/i915/display/intel_atomic_plane.c | 79 ++
.../gpu/drm/i915/display/intel_display_rps.c | 81 +++
.../gpu/drm/i915/display/intel_display_rps.h | 22 +
4 files changed, 111 insertions(+), 72 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_display_rps.c
create mode 100644 drivers/gpu/drm/i915/display/intel_display_rps.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index b2f91a1f8268..8e46f57e4569 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -239,6 +239,7 @@ i915-y += \
display/intel_display_power.o \
display/intel_display_power_map.o \
display/intel_display_power_well.o \
+ display/intel_display_rps.o \
display/intel_dmc.o \
display/intel_dpio_phy.o \
display/intel_dpll.o \
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 3bd8f7eb75a6..719a60e278f3 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -34,11 +34,10 @@
#include
#include
-#include "gt/intel_rps.h"
-
#include "i915_config.h"
#include "intel_atomic_plane.h"
#include "intel_cdclk.h"
+#include "intel_display_rps.h"
#include "intel_display_trace.h"
#include "intel_display_types.h"
#include "intel_fb.h"
@@ -941,64 +940,6 @@ int intel_atomic_plane_check_clipping(struct
intel_plane_state *plane_state,
return 0;
}
-struct wait_rps_boost {
- struct wait_queue_entry wait;
-
- struct drm_crtc *crtc;
- struct i915_request *request;
-};
-
-static int do_rps_boost(struct wait_queue_entry *_wait,
- unsigned mode, int sync, void *key)
-{
- struct wait_rps_boost *wait = container_of(_wait, typeof(*wait), wait);
- struct i915_request *rq = wait->request;
-
- /*
-* If we missed the vblank, but the request is already running it
-* is reasonable to assume that it will complete before the next
-* vblank without our intervention, so leave RPS alone.
-*/
- if (!i915_request_started(rq))
- intel_rps_boost(rq);
- i915_request_put(rq);
-
- drm_crtc_vblank_put(wait->crtc);
-
- list_del(>wait.entry);
- kfree(wait);
- return 1;
-}
-
-static void add_rps_boost_after_vblank(struct drm_crtc *crtc,
- struct dma_fence *fence)
-{
- struct wait_rps_boost *wait;
-
- if (!dma_fence_is_i915(fence))
- return;
-
- if (DISPLAY_VER(to_i915(crtc->dev)) < 6)
- return;
-
- if (drm_crtc_vblank_get(crtc))
- return;
-
- wait = kmalloc(sizeof(*wait), GFP_KERNEL);
- if (!wait) {
- drm_crtc_vblank_put(crtc);
- return;
- }
-
- wait->request = to_request(dma_fence_get(fence));
- wait->crtc = crtc;
-
- wait->wait.func = do_rps_boost;
- wait->wait.flags = 0;
-
- add_wait_queue(drm_crtc_vblank_waitqueue(crtc), >wait);
-}
-
/**
* intel_prepare_plane_fb - Prepare fb for usage on plane
* @_plane: drm plane to prepare for
@@ -1089,13 +1030,13 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
dma_resv_iter_begin(, obj->base.resv,
DMA_RESV_USAGE_WRITE);
dma_resv_for_each_fence_unlocked(, fence) {
- add_rps_boost_after_vblank(new_plane_state->hw.crtc,
- fence);
+
intel_display_rps_boost_after_vblank(new_plane_state->hw.crtc,
+fence);
}
dma_resv_iter_end();
} else {
- add_rps_boost_after_vblank(new_plane_state->hw.crtc,
- new_plane_state->uapi.fence);
+ intel_display_rps_boost_after_vblank(new_plane_state->hw.crtc,
+
new_plane_state->uapi.fence);
}
/*
@@ -1106,10 +1047,7 @@ intel_prepare_plane_fb(struct drm_plane *_plane,
* that are not quite steady state without resorting to forcing
* maximum clocks following a vblank miss (see do_rps_boost()).
*/
- if (!state->rps_interactive) {
- intel_rps_mark_interactive(_gt(dev_priv)->rps, true);
- state->rps_interactive = true;
- }
+ intel_display_rps_mark_interactive(dev_priv, state, true);
return 0;
@@ -1140,10 +1078,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
if (!obj)
return;
- if (state->rps_interactive) {
-
Re: [Intel-gfx] [PATCH] drm/i915/debugfs: move IPS debugfs to hsw_ips.c
On Thu, Mar 02, 2023 at 06:16:17PM +0200, Jani Nikula wrote:
> Follow the style of placing debugfs next to the implementation.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Ville Syrjälä
Some ideas for future enhancements:
- only register when IPS is actually supported
- make it per-crtc since IPS only exists on pipe A
- report the software state of IPS enable vs. disable
- there's a false color bit just like with fbc, could
hook that up to help verify that it actually works
> ---
> drivers/gpu/drm/i915/display/hsw_ips.c| 37 +++
> drivers/gpu/drm/i915/display/hsw_ips.h| 2 +
> .../drm/i915/display/intel_display_debugfs.c | 30 +--
> 3 files changed, 41 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c
> b/drivers/gpu/drm/i915/display/hsw_ips.c
> index 83aa3800245f..2910f5d0f3e2 100644
> --- a/drivers/gpu/drm/i915/display/hsw_ips.c
> +++ b/drivers/gpu/drm/i915/display/hsw_ips.c
> @@ -267,3 +267,40 @@ void hsw_ips_get_config(struct intel_crtc_state
> *crtc_state)
> crtc_state->ips_enabled = true;
> }
> }
> +
> +static int hsw_ips_debugfs_status_show(struct seq_file *m, void *unused)
> +{
> + struct drm_i915_private *i915 = m->private;
> + intel_wakeref_t wakeref;
> +
> + if (!HAS_IPS(i915))
> + return -ENODEV;
> +
> + wakeref = intel_runtime_pm_get(>runtime_pm);
> +
> + seq_printf(m, "Enabled by kernel parameter: %s\n",
> +str_yes_no(i915->params.enable_ips));
> +
> + if (DISPLAY_VER(i915) >= 8) {
> + seq_puts(m, "Currently: unknown\n");
> + } else {
> + if (intel_de_read(i915, IPS_CTL) & IPS_ENABLE)
> + seq_puts(m, "Currently: enabled\n");
> + else
> + seq_puts(m, "Currently: disabled\n");
> + }
> +
> + intel_runtime_pm_put(>runtime_pm, wakeref);
> +
> + return 0;
> +}
> +
> +DEFINE_SHOW_ATTRIBUTE(hsw_ips_debugfs_status);
> +
> +void hsw_ips_debugfs_register(struct drm_i915_private *i915)
> +{
> + struct drm_minor *minor = i915->drm.primary;
> +
> + debugfs_create_file("i915_ips_status", 0444, minor->debugfs_root,
> + i915, _ips_debugfs_status_fops);
> +}
> diff --git a/drivers/gpu/drm/i915/display/hsw_ips.h
> b/drivers/gpu/drm/i915/display/hsw_ips.h
> index 4564dee497d7..7ed6061874f7 100644
> --- a/drivers/gpu/drm/i915/display/hsw_ips.h
> +++ b/drivers/gpu/drm/i915/display/hsw_ips.h
> @@ -8,6 +8,7 @@
>
> #include
>
> +struct drm_i915_private;
> struct intel_atomic_state;
> struct intel_crtc;
> struct intel_crtc_state;
> @@ -22,5 +23,6 @@ bool hsw_crtc_state_ips_capable(const struct
> intel_crtc_state *crtc_state);
> int hsw_ips_compute_config(struct intel_atomic_state *state,
> struct intel_crtc *crtc);
> void hsw_ips_get_config(struct intel_crtc_state *crtc_state);
> +void hsw_ips_debugfs_register(struct drm_i915_private *i915);
>
> #endif /* __HSW_IPS_H__ */
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 25013f303c82..8be606bfd2b4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -8,6 +8,7 @@
> #include
> #include
>
> +#include "hsw_ips.h"
> #include "i915_debugfs.h"
> #include "i915_irq.h"
> #include "i915_reg.h"
> @@ -49,33 +50,6 @@ static int i915_frontbuffer_tracking(struct seq_file *m,
> void *unused)
> return 0;
> }
>
> -static int i915_ips_status(struct seq_file *m, void *unused)
> -{
> - struct drm_i915_private *dev_priv = node_to_i915(m->private);
> - intel_wakeref_t wakeref;
> -
> - if (!HAS_IPS(dev_priv))
> - return -ENODEV;
> -
> - wakeref = intel_runtime_pm_get(_priv->runtime_pm);
> -
> - seq_printf(m, "Enabled by kernel parameter: %s\n",
> -str_yes_no(dev_priv->params.enable_ips));
> -
> - if (DISPLAY_VER(dev_priv) >= 8) {
> - seq_puts(m, "Currently: unknown\n");
> - } else {
> - if (intel_de_read(dev_priv, IPS_CTL) & IPS_ENABLE)
> - seq_puts(m, "Currently: enabled\n");
> - else
> - seq_puts(m, "Currently: disabled\n");
> - }
> -
> - intel_runtime_pm_put(_priv->runtime_pm, wakeref);
> -
> - return 0;
> -}
> -
> static int i915_sr_status(struct seq_file *m, void *unused)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -1343,7 +1317,6 @@ static const struct file_operations
> i915_fifo_underrun_reset_ops = {
>
> static const struct drm_info_list intel_display_debugfs_list[] = {
> {"i915_frontbuffer_tracking", i915_frontbuffer_tracking, 0},
> - {"i915_ips_status", i915_ips_status, 0},
> {"i915_sr_status", i915_sr_status, 0},
> {"i915_opregion", i915_opregion, 0},
>
Re: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test
Hi Thomas, Thank you for the patch! Yet something to improve: [auto build test ERROR on drm-tip/drm-tip] url: https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/drm-tests-Suballocator-test/20230302-163704 base: git://anongit.freedesktop.org/drm/drm-tip drm-tip patch link: https://lore.kernel.org/r/20230302083422.76608-1-thomas.hellstrom%40linux.intel.com patch subject: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test config: mips-allyesconfig (https://download.01.org/0day-ci/archive/20230303/202303030056.cnezgrqr-...@intel.com/config) compiler: mips-linux-gcc (GCC) 12.1.0 reproduce (this is a W=1 build): wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross # https://github.com/intel-lab-lkp/linux/commit/e970911bccf3145b76cd755e2d78c0c0f7f22ca1 git remote add linux-review https://github.com/intel-lab-lkp/linux git fetch --no-tags linux-review Thomas-Hellstr-m/drm-tests-Suballocator-test/20230302-163704 git checkout e970911bccf3145b76cd755e2d78c0c0f7f22ca1 # save the config file mkdir build_dir && cp config build_dir/.config COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=mips olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.1.0 make.cross W=1 O=build_dir ARCH=mips SHELL=/bin/bash If you fix the issue, kindly add following tag where applicable | Reported-by: kernel test robot | Link: https://lore.kernel.org/oe-kbuild-all/202303030056.cnezgrqr-...@intel.com/ All errors (new ones prefixed by >>): arch/mips/kernel/head.o: in function `kernel_entry': (.ref.text+0xac): relocation truncated to fit: R_MIPS_26 against `start_kernel' init/main.o: in function `set_reset_devices': main.c:(.init.text+0x20): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0x30): relocation truncated to fit: R_MIPS_26 against `__sanitizer_cov_trace_pc' init/main.o: in function `debug_kernel': main.c:(.init.text+0xa4): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0xb4): relocation truncated to fit: R_MIPS_26 against `__sanitizer_cov_trace_pc' init/main.o: in function `quiet_kernel': main.c:(.init.text+0x128): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0x138): relocation truncated to fit: R_MIPS_26 against `__sanitizer_cov_trace_pc' init/main.o: in function `warn_bootconfig': main.c:(.init.text+0x1ac): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0x1bc): relocation truncated to fit: R_MIPS_26 against `__sanitizer_cov_trace_pc' init/main.o: in function `init_setup': main.c:(.init.text+0x234): relocation truncated to fit: R_MIPS_26 against `_mcount' main.c:(.init.text+0x254): additional relocation overflows omitted from the output mips-linux-ld: drivers/gpu/drm/tests/drm_suballoc_test.o: in function `drm_test_suballoc': >> drm_suballoc_test.c:(.text.drm_test_suballoc+0xcbc): undefined reference to >> `__udivdi3' >> mips-linux-ld: drm_suballoc_test.c:(.text.drm_test_suballoc+0xd20): >> undefined reference to `__udivdi3' mips-linux-ld: drm_suballoc_test.c:(.text.drm_test_suballoc+0xd84): undefined reference to `__udivdi3' mips-linux-ld: drm_suballoc_test.c:(.text.drm_test_suballoc+0xde8): undefined reference to `__udivdi3' mips-linux-ld: drm_suballoc_test.c:(.text.drm_test_suballoc+0xe40): undefined reference to `__udivdi3' mips-linux-ld: drivers/gpu/drm/tests/drm_suballoc_test.o:drm_suballoc_test.c:(.text.drm_test_suballoc+0xfb4): more undefined references to `__udivdi3' follow -- 0-DAY CI Kernel Test Service https://github.com/intel/lkp-tests
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Check HPD during eDP probe
== Series Details ==
Series: drm/i915: Check HPD during eDP probe
URL : https://patchwork.freedesktop.org/series/114577/
State : warning
== Summary ==
Error: dim checkpatch failed
c5a6c0899fb8 drm/i915: Populate dig_port->connected() before connector init
-:60: WARNING:BLOCK_COMMENT_STYLE: Block comments use a trailing */ on a
separate line
#60: FILE: drivers/gpu/drm/i915/display/intel_ddi.c:4538:
+* case we have some really bad VBTs... */
total: 0 errors, 1 warnings, 0 checks, 46 lines checked
e6b4f64ef131 drm/i915: Fix SKL DDI A digital port .connected()
e530dc71f2cd drm/i915: Get rid of the gm45 HPD live state nonsense
e6b7c6aa52d3 drm/i915: Introduce _hotplug_mask()
cbad8bc28638 drm/i915: Introduce intel_hpd_enable_detection()
1915f0f3e786 drm/i915: Check HPD live state during eDP probe
-:51: ERROR:GIT_COMMIT_ID: Please use git commit description style 'commit <12+
chars of sha1> ("")' - ie: 'commit 41e35ffb380b ("drm/i915: Favor
last VBT child device with conflicting AUX ch/DDC pin")'
#51:
Also the systems (Asrock B250M-HDV at least) fixed by commit
total: 1 errors, 0 warnings, 0 checks, 46 lines checked
1a502611a9d8 drm/i915: Reuse _hotplug_mask() in .hpd_detection_setup()
[Intel-gfx] [PATCH] drm/i915/debugfs: move IPS debugfs to hsw_ips.c
Follow the style of placing debugfs next to the implementation.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/hsw_ips.c| 37 +++
drivers/gpu/drm/i915/display/hsw_ips.h| 2 +
.../drm/i915/display/intel_display_debugfs.c | 30 +--
3 files changed, 41 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/hsw_ips.c
b/drivers/gpu/drm/i915/display/hsw_ips.c
index 83aa3800245f..2910f5d0f3e2 100644
--- a/drivers/gpu/drm/i915/display/hsw_ips.c
+++ b/drivers/gpu/drm/i915/display/hsw_ips.c
@@ -267,3 +267,40 @@ void hsw_ips_get_config(struct intel_crtc_state
*crtc_state)
crtc_state->ips_enabled = true;
}
}
+
+static int hsw_ips_debugfs_status_show(struct seq_file *m, void *unused)
+{
+ struct drm_i915_private *i915 = m->private;
+ intel_wakeref_t wakeref;
+
+ if (!HAS_IPS(i915))
+ return -ENODEV;
+
+ wakeref = intel_runtime_pm_get(>runtime_pm);
+
+ seq_printf(m, "Enabled by kernel parameter: %s\n",
+ str_yes_no(i915->params.enable_ips));
+
+ if (DISPLAY_VER(i915) >= 8) {
+ seq_puts(m, "Currently: unknown\n");
+ } else {
+ if (intel_de_read(i915, IPS_CTL) & IPS_ENABLE)
+ seq_puts(m, "Currently: enabled\n");
+ else
+ seq_puts(m, "Currently: disabled\n");
+ }
+
+ intel_runtime_pm_put(>runtime_pm, wakeref);
+
+ return 0;
+}
+
+DEFINE_SHOW_ATTRIBUTE(hsw_ips_debugfs_status);
+
+void hsw_ips_debugfs_register(struct drm_i915_private *i915)
+{
+ struct drm_minor *minor = i915->drm.primary;
+
+ debugfs_create_file("i915_ips_status", 0444, minor->debugfs_root,
+ i915, _ips_debugfs_status_fops);
+}
diff --git a/drivers/gpu/drm/i915/display/hsw_ips.h
b/drivers/gpu/drm/i915/display/hsw_ips.h
index 4564dee497d7..7ed6061874f7 100644
--- a/drivers/gpu/drm/i915/display/hsw_ips.h
+++ b/drivers/gpu/drm/i915/display/hsw_ips.h
@@ -8,6 +8,7 @@
#include
+struct drm_i915_private;
struct intel_atomic_state;
struct intel_crtc;
struct intel_crtc_state;
@@ -22,5 +23,6 @@ bool hsw_crtc_state_ips_capable(const struct intel_crtc_state
*crtc_state);
int hsw_ips_compute_config(struct intel_atomic_state *state,
struct intel_crtc *crtc);
void hsw_ips_get_config(struct intel_crtc_state *crtc_state);
+void hsw_ips_debugfs_register(struct drm_i915_private *i915);
#endif /* __HSW_IPS_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 25013f303c82..8be606bfd2b4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -8,6 +8,7 @@
#include
#include
+#include "hsw_ips.h"
#include "i915_debugfs.h"
#include "i915_irq.h"
#include "i915_reg.h"
@@ -49,33 +50,6 @@ static int i915_frontbuffer_tracking(struct seq_file *m,
void *unused)
return 0;
}
-static int i915_ips_status(struct seq_file *m, void *unused)
-{
- struct drm_i915_private *dev_priv = node_to_i915(m->private);
- intel_wakeref_t wakeref;
-
- if (!HAS_IPS(dev_priv))
- return -ENODEV;
-
- wakeref = intel_runtime_pm_get(_priv->runtime_pm);
-
- seq_printf(m, "Enabled by kernel parameter: %s\n",
- str_yes_no(dev_priv->params.enable_ips));
-
- if (DISPLAY_VER(dev_priv) >= 8) {
- seq_puts(m, "Currently: unknown\n");
- } else {
- if (intel_de_read(dev_priv, IPS_CTL) & IPS_ENABLE)
- seq_puts(m, "Currently: enabled\n");
- else
- seq_puts(m, "Currently: disabled\n");
- }
-
- intel_runtime_pm_put(_priv->runtime_pm, wakeref);
-
- return 0;
-}
-
static int i915_sr_status(struct seq_file *m, void *unused)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -1343,7 +1317,6 @@ static const struct file_operations
i915_fifo_underrun_reset_ops = {
static const struct drm_info_list intel_display_debugfs_list[] = {
{"i915_frontbuffer_tracking", i915_frontbuffer_tracking, 0},
- {"i915_ips_status", i915_ips_status, 0},
{"i915_sr_status", i915_sr_status, 0},
{"i915_opregion", i915_opregion, 0},
{"i915_vbt", i915_vbt, 0},
@@ -1385,6 +1358,7 @@ void intel_display_debugfs_register(struct
drm_i915_private *i915)
ARRAY_SIZE(intel_display_debugfs_list),
minor->debugfs_root, minor);
+ hsw_ips_debugfs_register(i915);
intel_dmc_debugfs_register(i915);
intel_fbc_debugfs_register(i915);
intel_hpd_debugfs_register(i915);
--
2.39.1
[Intel-gfx] [PATCH 7/7] drm/i915: Reuse _hotplug_mask() in .hpd_detection_setup()
From: Ville Syrjälä
Replace the hardcoded masks with just a loop over all hpd
pins using the _hotplug_mask() functions.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 57 +
1 file changed, 22 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 9d00b840727c..11c6a9ca3c23 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -82,6 +82,7 @@ static inline void pmu_irq_stats(struct drm_i915_private
*i915,
typedef bool (*long_pulse_detect_func)(enum hpd_pin pin, u32 val);
typedef u32 (*hotplug_enables_func)(struct intel_encoder *encoder);
+typedef u32 (*hotplug_mask_func)(enum hpd_pin pin);
static const u32 hpd_ilk[HPD_NUM_PINS] = {
[HPD_PORT_A] = DE_DP_A_HOTPLUG,
@@ -878,6 +879,18 @@ static u32 intel_hpd_hotplug_irqs(struct drm_i915_private
*dev_priv,
return hotplug_irqs;
}
+static u32 intel_hpd_hotplug_mask(struct drm_i915_private *i915,
+ hotplug_mask_func hotplug_mask)
+{
+ enum hpd_pin pin;
+ u32 hotplug = 0;
+
+ for_each_hpd_pin(pin)
+ hotplug |= hotplug_mask(pin);
+
+ return hotplug;
+}
+
static u32 intel_hpd_hotplug_enables(struct drm_i915_private *i915,
hotplug_enables_func hotplug_enables)
{
@@ -2886,10 +2899,7 @@ static void ibx_hpd_detection_setup(struct
drm_i915_private *dev_priv)
* The pulse duration bits are reserved on LPT+.
*/
intel_uncore_rmw(_priv->uncore, PCH_PORT_HOTPLUG,
-ibx_hotplug_mask(HPD_PORT_A) |
-ibx_hotplug_mask(HPD_PORT_B) |
-ibx_hotplug_mask(HPD_PORT_C) |
-ibx_hotplug_mask(HPD_PORT_D),
+intel_hpd_hotplug_mask(dev_priv, ibx_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
ibx_hotplug_enables));
}
@@ -2965,10 +2975,7 @@ static u32 icp_tc_hotplug_enables(struct intel_encoder
*encoder)
static void icp_ddi_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_DDI,
-icp_ddi_hotplug_mask(HPD_PORT_A) |
-icp_ddi_hotplug_mask(HPD_PORT_B) |
-icp_ddi_hotplug_mask(HPD_PORT_C) |
-icp_ddi_hotplug_mask(HPD_PORT_D),
+intel_hpd_hotplug_mask(dev_priv, icp_ddi_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
icp_ddi_hotplug_enables));
}
@@ -2984,12 +2991,7 @@ static void icp_ddi_hpd_enable_detection(struct
intel_encoder *encoder)
static void icp_tc_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_TC,
-icp_tc_hotplug_mask(HPD_PORT_TC1) |
-icp_tc_hotplug_mask(HPD_PORT_TC2) |
-icp_tc_hotplug_mask(HPD_PORT_TC3) |
-icp_tc_hotplug_mask(HPD_PORT_TC4) |
-icp_tc_hotplug_mask(HPD_PORT_TC5) |
-icp_tc_hotplug_mask(HPD_PORT_TC6),
+intel_hpd_hotplug_mask(dev_priv, icp_tc_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
icp_tc_hotplug_enables));
}
@@ -3075,12 +3077,7 @@ static void dg1_hpd_irq_setup(struct drm_i915_private
*dev_priv)
static void gen11_tc_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, GEN11_TC_HOTPLUG_CTL,
-gen11_hotplug_mask(HPD_PORT_TC1) |
-gen11_hotplug_mask(HPD_PORT_TC2) |
-gen11_hotplug_mask(HPD_PORT_TC3) |
-gen11_hotplug_mask(HPD_PORT_TC4) |
-gen11_hotplug_mask(HPD_PORT_TC5) |
-gen11_hotplug_mask(HPD_PORT_TC6),
+intel_hpd_hotplug_mask(dev_priv, gen11_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
gen11_hotplug_enables));
}
@@ -3096,12 +3093,7 @@ static void gen11_tc_hpd_enable_detection(struct
intel_encoder *encoder)
static void gen11_tbt_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, GEN11_TBT_HOTPLUG_CTL,
-gen11_hotplug_mask(HPD_PORT_TC1) |
-gen11_hotplug_mask(HPD_PORT_TC2) |
-gen11_hotplug_mask(HPD_PORT_TC3) |
-gen11_hotplug_mask(HPD_PORT_TC4) |
-gen11_hotplug_mask(HPD_PORT_TC5) |
-gen11_hotplug_mask(HPD_PORT_TC6),
+intel_hpd_hotplug_mask(dev_priv, gen11_hotplug_mask),
intel_hpd_hotplug_enables(dev_priv,
gen11_hotplug_enables));
}
@@ -3199,14 +3191,11 @@ static void
[Intel-gfx] [PATCH 6/7] drm/i915: Check HPD live state during eDP probe
From: Ville Syrjälä
We need to untangle the mess where some SKL machines (at least)
declare both DDI A and DDI E to be present in their VBT, and
both using AUX A. DDI A is a ghost eDP, wheres DDI E may be a
real DP->VGA converter.
Currently that is handled by checking the VBT child devices
for conflicts before output probing. But that kind of solution
will not work for the ADL phantom dual eDP VBTs. I think on
those we just have to probe the eDP first. And would be nice
to use the same probe scheme for everything.
On these SKL systems if we probe DDI A first (which is only
natural given it's declared by VBT first) we will get an answer
via AUX, but it came from the DP->VGA converter hooked to the
DDI E, not DDI A. Thus we mistakenly register eDP on DDI A
and screw up the real DP device in DDI E.
To fix this let's check the HPD live state during the eDP probe.
If we got an answer via DPCD but HPD is still down let's assume
we got the answer from someone else.
Smoke tested on all my eDP machines (ilk,hsw-ult,tgl,adl) and
I also tested turning off all HPD hardware prior to loading
i915 to make sure it all comes up properly. And I simulated
the failure path too by not turning on HPD sense and that
correctly gave up on eDP.
I *think* Windows might just fully depend on HPD here. I
couldn't really find any other way they probe displays. And
I did find code where they also check the live state prior
to AUX transfers (something Imre and I have also talked
about perhaps doing). That would also solve this as we'd
not succeed in the eDP probe DPCD reads.
Other solutions I've considered:
- Reintrduce DDI strap checks on SKL. Unfortunately we just
don't have any idea how reliable they are on real production
hardware, and commit 5a2376d1360b ("drm/i915/skl: WaIgnoreDDIAStrap
is forever, always init DDI A") does suggest that not very.
Sadly that commit is very poor in details :/
Also the systems (Asrock B250M-HDV at least) fixed by commit
41e35ffb380b ("drm/i915: Favor last VBT child device with
conflicting AUX ch/DDC pin") might still not work since we
don't know what their straps indicate. Stupid me for not
asking the reporter to check those at the time :(
We have currently two CI machines (fi-cfl-guc,fi-cfl-8700k
both MS-7B54/Z370M) that also declare both DDI A and DDI E
in VBT to use AUX A, and on these the DDI A strap is also
set. There doesn't seem to be anything hooked up to either
DDI however. But given the DDI A strap is wrong on these it
might well be wrong on the Asrock too.
Most other CI machines seem to have straps that generally
match the VBT. fi-kbl-soraka is an exception though as DDI D
strap is not set, but it is declared in VBT as a DP++ port.
No idea if there's a real physical port to go with it or not.
- Some kind of quirk just for the cases where both DDI A and DDI E
are present in VBT. Might be feasible given we've ignored
DDI A in these cases up to now successfully. But feels rather
unsatisfactory, and not very future proof against funny VBTs.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111966
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 28 +
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index aee93b0d810e..35b02278d840 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -46,6 +46,7 @@
#include "g4x_dp.h"
#include "i915_debugfs.h"
#include "i915_drv.h"
+#include "i915_irq.h"
#include "i915_reg.h"
#include "intel_atomic.h"
#include "intel_audio.h"
@@ -5308,6 +5309,15 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
goto out_vdd_off;
}
+ /*
+* Enable HPD sense for live status check.
+* intel_hpd_irq_setup() will turn it off again
+* if it's no longer needed later.
+*
+* The DPCD probe below will make sure VDD is on.
+*/
+ intel_hpd_enable_detection(encoder);
+
/* Cache DPCD and EDID for edp. */
has_dpcd = intel_edp_init_dpcd(intel_dp);
@@ -5319,6 +5329,24 @@ static bool intel_edp_init_connector(struct intel_dp
*intel_dp,
goto out_vdd_off;
}
+ /*
+* VBT and straps are liars. Also check HPD as that seems
+* to be the most reliable piece of information available.
+*/
+ if (!intel_digital_port_connected(encoder)) {
+ /*
+* If this fails, presume the DPCD answer came
+* from some other port using the same AUX CH.
+*
+* FIXME maybe cleaner to check this before the
+* DPCD read? Would need sort out the VDD handling...
+*/
+ drm_info(_priv->drm,
+"[ENCODER:%d:%s] HPD is down, disabling eDP\n",
+
[Intel-gfx] [PATCH 5/7] drm/i915: Introduce intel_hpd_enable_detection()
From: Ville Syrjälä
Add a mechanism by which we can enable the HPD sense for
individual encoders.
This will be used during eDP probing to figure out if
anything is actually connected. The normal intel_hpd_irq_setup()
thing doesn't work since we only do that after probing the
outputs, and we only enable HPD sense for encoders that were
successfully probed.
The other idea that crossed my minds was to just turn on
HPD sense for all pins before output probing and let hpd_irq_setup()
clean it up afterwards. But that doesn't work for BXT/GLK where
the HPD invert information comes from the VBT child device.
So looks like this really needs to be per-encoder.
v2: Give it a better name (Jani)
Cc: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 131
drivers/gpu/drm/i915/i915_irq.h | 2 +
2 files changed, 133 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1e6a6f14a968..9d00b840727c 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2893,6 +2893,15 @@ static void ibx_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
ibx_hotplug_enables));
}
+static void ibx_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, PCH_PORT_HOTPLUG,
+ibx_hotplug_mask(encoder->hpd_pin),
+ibx_hotplug_enables(encoder));
+}
+
static void ibx_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
u32 hotplug_irqs, enabled_irqs;
@@ -2963,6 +2972,15 @@ static void icp_ddi_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
icp_ddi_hotplug_enables));
}
+static void icp_ddi_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, SHOTPLUG_CTL_DDI,
+icp_ddi_hotplug_mask(encoder->hpd_pin),
+icp_ddi_hotplug_enables(encoder));
+}
+
static void icp_tc_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_TC,
@@ -2975,6 +2993,21 @@ static void icp_tc_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
icp_tc_hotplug_enables));
}
+static void icp_tc_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, SHOTPLUG_CTL_TC,
+icp_tc_hotplug_mask(encoder->hpd_pin),
+icp_tc_hotplug_enables(encoder));
+}
+
+static void icp_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ icp_ddi_hpd_enable_detection(encoder);
+ icp_tc_hpd_enable_detection(encoder);
+}
+
static void icp_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
u32 hotplug_irqs, enabled_irqs;
@@ -3025,6 +3058,14 @@ static void dg1_hpd_invert(struct drm_i915_private *i915)
intel_uncore_rmw(>uncore, SOUTH_CHICKEN1, 0, val);
}
+static void dg1_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ dg1_hpd_invert(i915);
+ icp_hpd_enable_detection(encoder);
+}
+
static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
dg1_hpd_invert(dev_priv);
@@ -3043,6 +3084,15 @@ static void gen11_tc_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
gen11_hotplug_enables));
}
+static void gen11_tc_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, GEN11_TC_HOTPLUG_CTL,
+gen11_hotplug_mask(encoder->hpd_pin),
+gen11_hotplug_enables(encoder));
+}
+
static void gen11_tbt_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, GEN11_TBT_HOTPLUG_CTL,
@@ -3055,6 +3105,26 @@ static void gen11_tbt_hpd_detection_setup(struct
drm_i915_private *dev_priv)
intel_hpd_hotplug_enables(dev_priv,
gen11_hotplug_enables));
}
+static void gen11_tbt_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+ intel_uncore_rmw(>uncore, GEN11_TBT_HOTPLUG_CTL,
+gen11_hotplug_mask(encoder->hpd_pin),
+gen11_hotplug_enables(encoder));
+}
+
+static void gen11_hpd_enable_detection(struct intel_encoder *encoder)
+{
+ struct drm_i915_private *i915 = to_i915(encoder->base.dev);
+
+
[Intel-gfx] [PATCH 4/7] drm/i915: Introduce _hotplug_mask()
From: Ville Syrjälä
Pair each _hotplug_enables() function with
a corresponding _hotplug_mask() function so that
we can determine right bits to clear on a per hpd_pin basis.
We'll need this for turning on HPD sense for a specific
encoder rather than just all of them.
v2: Drop the unused 'i915' param (Jani)
Cc: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 230 ++--
1 file changed, 159 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index cc3d016f76d1..1e6a6f14a968 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2836,6 +2836,22 @@ static void cherryview_irq_reset(struct drm_i915_private
*dev_priv)
spin_unlock_irq(_priv->irq_lock);
}
+static u32 ibx_hotplug_mask(enum hpd_pin hpd_pin)
+{
+ switch (hpd_pin) {
+ case HPD_PORT_A:
+ return PORTA_HOTPLUG_ENABLE;
+ case HPD_PORT_B:
+ return PORTB_HOTPLUG_ENABLE | PORTB_PULSE_DURATION_MASK;
+ case HPD_PORT_C:
+ return PORTC_HOTPLUG_ENABLE | PORTC_PULSE_DURATION_MASK;
+ case HPD_PORT_D:
+ return PORTD_HOTPLUG_ENABLE | PORTD_PULSE_DURATION_MASK;
+ default:
+ return 0;
+ }
+}
+
static u32 ibx_hotplug_enables(struct intel_encoder *encoder)
{
struct drm_i915_private *i915 = to_i915(encoder->base.dev);
@@ -2870,13 +2886,10 @@ static void ibx_hpd_detection_setup(struct
drm_i915_private *dev_priv)
* The pulse duration bits are reserved on LPT+.
*/
intel_uncore_rmw(_priv->uncore, PCH_PORT_HOTPLUG,
-PORTA_HOTPLUG_ENABLE |
-PORTB_HOTPLUG_ENABLE |
-PORTC_HOTPLUG_ENABLE |
-PORTD_HOTPLUG_ENABLE |
-PORTB_PULSE_DURATION_MASK |
-PORTC_PULSE_DURATION_MASK |
-PORTD_PULSE_DURATION_MASK,
+ibx_hotplug_mask(HPD_PORT_A) |
+ibx_hotplug_mask(HPD_PORT_B) |
+ibx_hotplug_mask(HPD_PORT_C) |
+ibx_hotplug_mask(HPD_PORT_D),
intel_hpd_hotplug_enables(dev_priv,
ibx_hotplug_enables));
}
@@ -2892,53 +2905,73 @@ static void ibx_hpd_irq_setup(struct drm_i915_private
*dev_priv)
ibx_hpd_detection_setup(dev_priv);
}
+static u32 _icp_ddi_hotplug_enables(enum hpd_pin hpd_pin)
+{
+ switch (hpd_pin) {
+ case HPD_PORT_A:
+ case HPD_PORT_B:
+ case HPD_PORT_C:
+ case HPD_PORT_D:
+ return SHOTPLUG_CTL_DDI_HPD_ENABLE(hpd_pin);
+ default:
+ return 0;
+ }
+}
+
+static u32 icp_ddi_hotplug_mask(enum hpd_pin hpd_pin)
+{
+ return _icp_ddi_hotplug_enables(hpd_pin);
+}
+
static u32 icp_ddi_hotplug_enables(struct intel_encoder *encoder)
{
- switch (encoder->hpd_pin) {
- case HPD_PORT_A:
- case HPD_PORT_B:
- case HPD_PORT_C:
- case HPD_PORT_D:
- return SHOTPLUG_CTL_DDI_HPD_ENABLE(encoder->hpd_pin);
+ return _icp_ddi_hotplug_enables(encoder->hpd_pin);
+}
+
+static u32 _icp_tc_hotplug_enables(enum hpd_pin hpd_pin)
+{
+ switch (hpd_pin) {
+ case HPD_PORT_TC1:
+ case HPD_PORT_TC2:
+ case HPD_PORT_TC3:
+ case HPD_PORT_TC4:
+ case HPD_PORT_TC5:
+ case HPD_PORT_TC6:
+ return ICP_TC_HPD_ENABLE(hpd_pin);
default:
return 0;
}
}
+static u32 icp_tc_hotplug_mask(enum hpd_pin hpd_pin)
+{
+ return _icp_tc_hotplug_enables(hpd_pin);
+}
+
static u32 icp_tc_hotplug_enables(struct intel_encoder *encoder)
{
- switch (encoder->hpd_pin) {
- case HPD_PORT_TC1:
- case HPD_PORT_TC2:
- case HPD_PORT_TC3:
- case HPD_PORT_TC4:
- case HPD_PORT_TC5:
- case HPD_PORT_TC6:
- return ICP_TC_HPD_ENABLE(encoder->hpd_pin);
- default:
- return 0;
- }
+ return _icp_tc_hotplug_enables(encoder->hpd_pin);
}
static void icp_ddi_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
intel_uncore_rmw(_priv->uncore, SHOTPLUG_CTL_DDI,
-SHOTPLUG_CTL_DDI_HPD_ENABLE(HPD_PORT_A) |
-SHOTPLUG_CTL_DDI_HPD_ENABLE(HPD_PORT_B) |
-SHOTPLUG_CTL_DDI_HPD_ENABLE(HPD_PORT_C) |
-SHOTPLUG_CTL_DDI_HPD_ENABLE(HPD_PORT_D),
+icp_ddi_hotplug_mask(HPD_PORT_A) |
+icp_ddi_hotplug_mask(HPD_PORT_B) |
+icp_ddi_hotplug_mask(HPD_PORT_C) |
+icp_ddi_hotplug_mask(HPD_PORT_D),
intel_hpd_hotplug_enables(dev_priv,
icp_ddi_hotplug_enables));
}
static void icp_tc_hpd_detection_setup(struct drm_i915_private *dev_priv)
{
[Intel-gfx] [PATCH 3/7] drm/i915: Get rid of the gm45 HPD live state nonsense
From: Ville Syrjälä
The idea that ctg uses different HPD live state bits is
total nonsense, at least on my machine (Dell Latitude
E5400).
The only reason DP-B even works on my ctg is that DP-D
live state is stuck high, even though there is no physical
DP-D port. So when the detect checks DP-B live state it
sees the stuck live state of DP-D instead. If I hack
the driver to not register DP-D at all, and thus we never
enabe DP-D HPD, DP-B stops working as well.
Just to put some conclusive evidence into this mess,
here are the actual hotplug register values for each port:
Everything disconnected:
PORT_HOTPLUG_EN (0x00061110): 0x
PORT_HOTPLUG_STAT (0x00061114): 0x
PORT_HOTPLUG_EN (0x00061110): 0x0800
PORT_HOTPLUG_STAT (0x00061114): 0x0800
PORT_HOTPLUG_EN (0x00061110): 0x1000
PORT_HOTPLUG_STAT (0x00061114): 0x
PORT_HOTPLUG_EN (0x00061110): 0x2000
PORT_HOTPLUG_STAT (0x00061114): 0x
Only port B connected:
PORT_HOTPLUG_EN (0x00061110): 0x
PORT_HOTPLUG_STAT (0x00061114): 0x
PORT_HOTPLUG_EN (0x00061110): 0x0800
PORT_HOTPLUG_STAT (0x00061114): 0x0800
PORT_HOTPLUG_EN (0x00061110): 0x1000
PORT_HOTPLUG_STAT (0x00061114): 0x
PORT_HOTPLUG_EN (0x00061110): 0x2000
PORT_HOTPLUG_STAT (0x00061114): 0x2000
Only port C connected:
PORT_HOTPLUG_EN (0x00061110): 0x
PORT_HOTPLUG_STAT (0x00061114): 0x
PORT_HOTPLUG_EN (0x00061110): 0x0800
PORT_HOTPLUG_STAT (0x00061114): 0x0800
PORT_HOTPLUG_EN (0x00061110): 0x1000
PORT_HOTPLUG_STAT (0x00061114): 0x1000
PORT_HOTPLUG_EN (0x00061110): 0x2000
PORT_HOTPLUG_STAT (0x00061114): 0x
So the enable bit and live state bit always match 1:1.
Acked-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/g4x_dp.c | 28 +--
drivers/gpu/drm/i915/i915_reg.h | 13 +
2 files changed, 2 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/g4x_dp.c
b/drivers/gpu/drm/i915/display/g4x_dp.c
index a50ad0fff57c..920d570f7594 100644
--- a/drivers/gpu/drm/i915/display/g4x_dp.c
+++ b/drivers/gpu/drm/i915/display/g4x_dp.c
@@ -1197,29 +1197,6 @@ static bool g4x_digital_port_connected(struct
intel_encoder *encoder)
return intel_de_read(dev_priv, PORT_HOTPLUG_STAT) & bit;
}
-static bool gm45_digital_port_connected(struct intel_encoder *encoder)
-{
- struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
- u32 bit;
-
- switch (encoder->hpd_pin) {
- case HPD_PORT_B:
- bit = PORTB_HOTPLUG_LIVE_STATUS_GM45;
- break;
- case HPD_PORT_C:
- bit = PORTC_HOTPLUG_LIVE_STATUS_GM45;
- break;
- case HPD_PORT_D:
- bit = PORTD_HOTPLUG_LIVE_STATUS_GM45;
- break;
- default:
- MISSING_CASE(encoder->hpd_pin);
- return false;
- }
-
- return intel_de_read(dev_priv, PORT_HOTPLUG_STAT) & bit;
-}
-
static bool ilk_digital_port_connected(struct intel_encoder *encoder)
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
@@ -1384,10 +1361,7 @@ bool g4x_dp_init(struct drm_i915_private *dev_priv,
dig_port->hpd_pulse = intel_dp_hpd_pulse;
if (HAS_GMCH(dev_priv)) {
- if (IS_GM45(dev_priv))
- dig_port->connected = gm45_digital_port_connected;
- else
- dig_port->connected = g4x_digital_port_connected;
+ dig_port->connected = g4x_digital_port_connected;
} else {
if (port == PORT_A)
dig_port->connected = ilk_digital_port_connected;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c1efa655fb68..de58695ad1c0 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2483,18 +2483,7 @@
#define CRT_HOTPLUG_DETECT_VOLTAGE_475MV (1 << 2)
#define PORT_HOTPLUG_STAT _MMIO(DISPLAY_MMIO_BASE(dev_priv) + 0x61114)
-/*
- * HDMI/DP bits are g4x+
- *
- * WARNING: Bspec for hpd status bits on gen4 seems to be completely confused.
- * Please check the detailed lore in the commit message for for experimental
- * evidence.
- */
-/* Bspec says GM45 should match G4X/VLV/CHV, but reality disagrees */
-#define PORTD_HOTPLUG_LIVE_STATUS_GM45 (1 << 29)
-#define PORTC_HOTPLUG_LIVE_STATUS_GM45 (1 << 28)
-#define PORTB_HOTPLUG_LIVE_STATUS_GM45 (1 <<
[Intel-gfx] [PATCH 1/7] drm/i915: Populate dig_port->connected() before connector init
From: Ville Syrjälä
We'll need dig_port->connected() to be there for a HPD live
state check during eDP connector probing. Reorder intel_ddi_init()
accordingly. g4x_dp_init() is already fine.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e5979427b38b..40b5c93f9223 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4504,6 +4504,26 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
drm_WARN_ON(_priv->drm, port > PORT_I);
dig_port->ddi_io_power_domain =
intel_display_power_ddi_io_domain(dev_priv, port);
+ if (DISPLAY_VER(dev_priv) >= 11) {
+ if (intel_phy_is_tc(dev_priv, phy))
+ dig_port->connected = intel_tc_port_connected;
+ else
+ dig_port->connected = lpt_digital_port_connected;
+ } else if (DISPLAY_VER(dev_priv) >= 8) {
+ if (port == PORT_A || IS_GEMINILAKE(dev_priv) ||
+ IS_BROXTON(dev_priv))
+ dig_port->connected = bdw_digital_port_connected;
+ else
+ dig_port->connected = lpt_digital_port_connected;
+ } else {
+ if (port == PORT_A)
+ dig_port->connected = hsw_digital_port_connected;
+ else
+ dig_port->connected = lpt_digital_port_connected;
+ }
+
+ intel_infoframe_init(dig_port);
+
if (init_dp) {
if (!intel_ddi_init_dp_connector(dig_port))
goto err;
@@ -4521,26 +4541,6 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
goto err;
}
- if (DISPLAY_VER(dev_priv) >= 11) {
- if (intel_phy_is_tc(dev_priv, phy))
- dig_port->connected = intel_tc_port_connected;
- else
- dig_port->connected = lpt_digital_port_connected;
- } else if (DISPLAY_VER(dev_priv) >= 8) {
- if (port == PORT_A || IS_GEMINILAKE(dev_priv) ||
- IS_BROXTON(dev_priv))
- dig_port->connected = bdw_digital_port_connected;
- else
- dig_port->connected = lpt_digital_port_connected;
- } else {
- if (port == PORT_A)
- dig_port->connected = hsw_digital_port_connected;
- else
- dig_port->connected = lpt_digital_port_connected;
- }
-
- intel_infoframe_init(dig_port);
-
return;
err:
--
2.39.2
[Intel-gfx] [PATCH 2/7] drm/i915: Fix SKL DDI A digital port .connected()
From: Ville Syrjälä
SKL doesn't have any north DE hotplug stuff. Currently we're
trying to read DDI A live state from the BDW north DE bit,
instead of the approproate south DE bit. Fix it.
And for good measure clear the pointer to the north hpd
pin array, so that we'll actually notice if some other
place is also using the wrong thing.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 11 +++
drivers/gpu/drm/i915/i915_irq.c | 2 ++
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 40b5c93f9223..1a042f3658eb 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -4509,13 +4509,16 @@ void intel_ddi_init(struct drm_i915_private *dev_priv,
enum port port)
dig_port->connected = intel_tc_port_connected;
else
dig_port->connected = lpt_digital_port_connected;
- } else if (DISPLAY_VER(dev_priv) >= 8) {
- if (port == PORT_A || IS_GEMINILAKE(dev_priv) ||
- IS_BROXTON(dev_priv))
+ } else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv)) {
+ dig_port->connected = bdw_digital_port_connected;
+ } else if (DISPLAY_VER(dev_priv) == 9) {
+ dig_port->connected = lpt_digital_port_connected;
+ } else if (IS_BROADWELL(dev_priv)) {
+ if (port == PORT_A)
dig_port->connected = bdw_digital_port_connected;
else
dig_port->connected = lpt_digital_port_connected;
- } else {
+ } else if (IS_HASWELL(dev_priv)) {
if (port == PORT_A)
dig_port->connected = hsw_digital_port_connected;
else
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 417c981e4968..cc3d016f76d1 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -198,6 +198,8 @@ static void intel_hpd_init_pins(struct drm_i915_private
*dev_priv)
hpd->hpd = hpd_gen11;
else if (IS_GEMINILAKE(dev_priv) || IS_BROXTON(dev_priv))
hpd->hpd = hpd_bxt;
+ else if (DISPLAY_VER(dev_priv) == 9)
+ hpd->hpd = NULL; /* no north HPD on SKL */
else if (DISPLAY_VER(dev_priv) >= 8)
hpd->hpd = hpd_bdw;
else if (DISPLAY_VER(dev_priv) >= 7)
--
2.39.2
[Intel-gfx] [PATCH 0/7] drm/i915: Check HPD during eDP probe
From: Ville Syrjälä Carved out the HPD changes from by big DDI probe series to get it tested separately. Also tweaked a few things Jani pointed out during earlier review, and tossed in one extra refactoring patch on top. Ville Syrjälä (7): drm/i915: Populate dig_port->connected() before connector init drm/i915: Fix SKL DDI A digital port .connected() drm/i915: Get rid of the gm45 HPD live state nonsense drm/i915: Introduce _hotplug_mask() drm/i915: Introduce intel_hpd_enable_detection() drm/i915: Check HPD live state during eDP probe drm/i915: Reuse _hotplug_mask() in .hpd_detection_setup() drivers/gpu/drm/i915/display/g4x_dp.c| 28 +- drivers/gpu/drm/i915/display/intel_ddi.c | 43 +-- drivers/gpu/drm/i915/display/intel_dp.c | 28 ++ drivers/gpu/drm/i915/i915_irq.c | 350 ++- drivers/gpu/drm/i915/i915_irq.h | 2 + drivers/gpu/drm/i915/i915_reg.h | 13 +- 6 files changed, 334 insertions(+), 130 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH] drm/i915/dmc: Load DMC on MTL
From: Madhumitha Tolakanahalli Pradeep
Add support to load DMC on MTL.
Signed-off-by: Madhumitha Tolakanahalli Pradeep
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index f70ada2357dc..dedf40cb85a2 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -60,6 +60,10 @@
#define DISPLAY_VER12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE
+#define MTL_DMC_PATH DMC_PATH(mtl)
+#define MTL_DMC_MAX_FW_SIZE0x1
+MODULE_FIRMWARE(MTL_DMC_PATH);
+
#define DG2_DMC_PATH DMC_LEGACY_PATH(dg2, 2, 08)
MODULE_FIRMWARE(DG2_DMC_PATH);
@@ -943,7 +947,10 @@ void intel_dmc_init(struct drm_i915_private *dev_priv)
*/
intel_dmc_runtime_pm_get(dev_priv);
- if (IS_DG2(dev_priv)) {
+ if (IS_METEORLAKE(dev_priv)) {
+ dmc->fw_path = MTL_DMC_PATH;
+ dmc->max_fw_size = MTL_DMC_MAX_FW_SIZE;
+ } else if (IS_DG2(dev_priv)) {
dmc->fw_path = DG2_DMC_PATH;
dmc->max_fw_size = DISPLAY_VER13_DMC_MAX_FW_SIZE;
} else if (IS_ALDERLAKE_P(dev_priv)) {
--
2.39.2
Re: [Intel-gfx] [PATCH v3] drm/i915/active: Fix misuse of non-idle barriers as fence trackers
Hi Janusz,
On Thu, Mar 02, 2023 at 01:08:20PM +0100, Janusz Krzysztofik wrote:
> Users reported oopses on list corruptions when using i915 perf with a
> number of concurrently running graphics applications. Root cause analysis
> pointed at an issue in barrier processing code -- a race among perf open /
> close replacing active barriers with perf requests on kernel context and
> concurrent barrier preallocate / acquire operations performed during user
> context first pin / last unpin.
>
> When adding a request to a composite tracker, we try to reuse an existing
> fence tracker, already allocated and registered with that composite. The
> tracker we obtain may already track another fence, may be an idle barrier,
> or an active barrier.
>
> If the tracker we get occurs a non-idle barrier then we try to delete that
> barrier from a list of barrier tasks it belongs to. However, while doing
> that we don't respect return value from a function that performs the
> barrier deletion. Should the deletion ever fail, we would end up reusing
> the tracker still registered as a barrier task. Since the same structure
> field is reused with both fence callback lists and barrier tasks list,
> list corruptions would likely occur.
>
> Barriers are now deleted from a barrier tasks list by temporarily removing
> the list content, traversing that content with skip over the node to be
> deleted, then populating the list back with the modified content. Should
> that intentionally racy concurrent deletion attempts be not serialized,
> one or more of those may fail because of the list being temporary empty.
>
> Related code that ignores the results of barrier deletion was initially
> introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the
> idle-barrier from other kernel requests"). However, all users of the
> barrier deletion routine were apparently serialized at that time, then the
> issue didn't exhibit itself. Results of git bisect with help of a newly
> developed igt@gem_barrier_race@remote-request IGT test indicate that list
> corruptions might start to appear after commit 311770173fac ("drm/i915/gt:
> Schedule request retirement when timeline idles"), introduced in v5.5.
>
> Respect results of barrier deletion attempts -- mark the barrier as idle
> only if successfully deleted from the list. Then, before proceeding with
> setting our fence as the one currently tracked, make sure that the tracker
> we've got is not a non-idle barrier. If that check fails then don't use
> that tracker but go back and try to acquire a new, usable one.
>
> v3: use unlikely() to document what outcome we expect (Andi),
> - fix bad grammar in commit description.
> v2: no code changes,
> - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement
> when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow
> sharing the idle-barrier from other kernel requests"), v5.4,
> - reword commit description.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
> Fixes: 311770173fac ("drm/i915/gt: Schedule request retirement when timeline
> idles")
> Cc: Chris Wilson
> Cc: sta...@vger.kernel.org # v5.5
> Cc: Andi Shyti
> Signed-off-by: Janusz Krzysztofik
Reviewed-by: Andi Shyti
I hope to see some future cleanups here, as well. Let's tie a
knot in our handkerchiefs to remind ourselves to revisit this in
the future.
Thanks,
Andi
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live (rev2)
== Series Details == Series: series starting with [v5,1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live (rev2) URL : https://patchwork.freedesktop.org/series/114432/ State : warning == Summary == Error: dim checkpatch failed bf643697763a drm/i915: Migrate platform-dependent mock hugepage selftests to live -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock selftests into total: 0 errors, 1 warnings, 0 checks, 58 lines checked 37dbdbff3204 drm/i915: Use correct huge page manager for MTL -:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #6: MTL currently uses gen8_ppgtt_insert_huge when managing huge pages. This is because total: 0 errors, 1 warnings, 0 checks, 15 lines checked
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
-Original Message-
From: Auld, Matthew
Sent: Thursday, March 2, 2023 2:36 AM
To: Cavitt, Jonathan ;
intel-gfx@lists.freedesktop.org
Cc: Dutt, Sudeep ; thomas.hellst...@linux.intel.com;
maarten.lankho...@linux.intel.com; Vetter, Daniel ; De
Marchi, Lucas ; chris.p.wil...@linux.intel.com
Subject: Re: [PATCH v5 1/2] drm/i915: Migrate platform-dependent mock hugepage
selftests to live
>
> On 28/02/2023 14:08, Matthew Auld wrote:
> > On 27/02/2023 17:19, Jonathan Cavitt wrote:
> >> Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock
> >> selftests into
> >> live selftests as their requirements have recently become
> >> platform-dependent.
> >> Additionally, apply necessary platform dependency checks to these tests.
> >>
> >> v2: Reorder
> >>
> >> Signed-off-by: Jonathan Cavitt
> >
> > r-b still stands for the series. Note that CI is busted atm though, so
> > we can't merge this yet. Likely need to re-trigger testing for the
> > series once CI/drm-tip is working again.
>
> CI looks to be back. Can you trigger a retest through patchwork, or
> resend the series?
Retest request submitted.
-Jonathan Cavitt
>
> >
> >
> >> ---
> >> .../gpu/drm/i915/gem/selftests/huge_pages.c | 22 ++-
> >> 1 file changed, 17 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> >> b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> >> index defece0bcb81..375f119ab261 100644
> >> --- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> >> +++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
> >> @@ -710,7 +710,7 @@ static void close_object_list(struct list_head
> >> *objects,
> >> }
> >> }
> >> -static int igt_mock_ppgtt_huge_fill(void *arg)
> >> +static int igt_ppgtt_huge_fill(void *arg)
> >> {
> >> struct i915_ppgtt *ppgtt = arg;
> >> struct drm_i915_private *i915 = ppgtt->vm.i915;
> >> @@ -784,7 +784,8 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
> >> GEM_BUG_ON(!expected_gtt);
> >> GEM_BUG_ON(size);
> >> - if (expected_gtt & I915_GTT_PAGE_SIZE_4K)
> >> + if (expected_gtt & I915_GTT_PAGE_SIZE_4K &&
> >> + GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
> >> expected_gtt &= ~I915_GTT_PAGE_SIZE_64K;
> >> i915_vma_unpin(vma);
> >> @@ -831,7 +832,7 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
> >> return err;
> >> }
> >> -static int igt_mock_ppgtt_64K(void *arg)
> >> +static int igt_ppgtt_64K(void *arg)
> >> {
> >> struct i915_ppgtt *ppgtt = arg;
> >> struct drm_i915_private *i915 = ppgtt->vm.i915;
> >> @@ -913,6 +914,17 @@ static int igt_mock_ppgtt_64K(void *arg)
> >> unsigned int offset = objects[i].offset;
> >> unsigned int flags = PIN_USER;
> >> + /*
> >> + * For modern GTT models, the requirements for marking a
> >> page-table
> >> + * as 64K have been relaxed. Account for this.
> >> + */
> >> +
> >> + if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
> >> + expected_gtt = 0;
> >> + expected_gtt |= size & (SZ_64K | SZ_2M) ?
> >> I915_GTT_PAGE_SIZE_64K : 0;
> >> + expected_gtt |= size & SZ_4K ? I915_GTT_PAGE_SIZE_4K : 0;
> >> + }
> >> +
> >> for (single = 0; single <= 1; single++) {
> >> obj = fake_huge_pages_object(i915, size, !!single);
> >> if (IS_ERR(obj))
> >> @@ -1910,8 +1922,6 @@ int i915_gem_huge_page_mock_selftests(void)
> >> SUBTEST(igt_mock_exhaust_device_supported_pages),
> >> SUBTEST(igt_mock_memory_region_huge_pages),
> >> SUBTEST(igt_mock_ppgtt_misaligned_dma),
> >> - SUBTEST(igt_mock_ppgtt_huge_fill),
> >> - SUBTEST(igt_mock_ppgtt_64K),
> >> };
> >> struct drm_i915_private *dev_priv;
> >> struct i915_ppgtt *ppgtt;
> >> @@ -1962,6 +1972,8 @@ int i915_gem_huge_page_live_selftests(struct
> >> drm_i915_private *i915)
> >> SUBTEST(igt_ppgtt_sanity_check),
> >> SUBTEST(igt_ppgtt_compact),
> >> SUBTEST(igt_ppgtt_mixed),
> >> + SUBTEST(igt_ppgtt_huge_fill),
> >> + SUBTEST(igt_ppgtt_64K),
> >> };
> >> if (!HAS_PPGTT(i915)) {
>
Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Jason Gunthorpe
> Sent: Thursday, March 2, 2023 8:35 PM
>
> On Thu, Mar 02, 2023 at 09:55:46AM +, Tian, Kevin wrote:
> > > From: Liu, Yi L
> > > Sent: Thursday, March 2, 2023 2:07 PM
> > >
> > > > - if (!vfio_dev_in_groups(cur_vma, groups)) {
> > > > + if (cur_vma->vdev.open_count &&
> > > > + !vfio_dev_in_groups(cur_vma, groups) &&
> > > > + !vfio_dev_in_iommufd_ctx(cur_vma, iommufd_ctx)) {
> > >
> > > Hi Alex, Jason,
> > >
> > > There is one concern on this approach which is related to the
> > > cdev noiommu mode. As patch 16 of this series, cdev path
> > > supports noiommu mode by passing a negative iommufd to
> > > kernel. In such case, the vfio_device is not bound to a valid
> > > iommufd. Then the check in vfio_dev_in_iommufd_ctx() is
> > > to be broken.
> > >
> > > An idea is to add a cdev_noiommu flag in vfio_device, when
> > > checking the iommufd_ictx, also check this flag. If all the opened
> > > devices in the dev_set have vfio_device->cdev_noiommu==true,
> > > then the reset is considered to be doable. But there is a special
> > > case. If devices in this dev_set are opened by two applications
> > > that operates in cdev noiommu mode, then this logic is not able
> > > to differentiate them. In that case, should we allow the reset?
> > > It seems to ok to allow reset since noiommu mode itself means
> > > no security between the applications that use it. thoughts?
> > >
> >
> > Probably we need still pass in a valid iommufd (instead of using
> > a negative value) in noiommu case to mark the ownership so the
> > check in the reset path can correctly catch whether an opened
> > device belongs to this user.
>
> There should be no iommufd at all in no-iommu mode
>
> Adding one just to deal with noiommu reset seems pretty sad :\
>
> no-iommu is only really used by dpdk, and it doesn't invoke
> VFIO_DEVICE_PCI_HOT_RESET at all.
Does it happen to be or by design, this ioctl is not needed by dpdk?
> I'd say as long as VFIO_DEVICE_PCI_HOT_RESET works if only one vfio
> device is open using a empty list (eg we should ensure that the
> invoking cdev itself is allowed) then I think it is OK.
Sorry, which empty list are your referring?
Regards,
Yi Liu
Re: [Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test
Am 02.03.23 um 09:34 schrieb Thomas Hellström:
Add a suballocator test to get some test coverage for the new drm
suballocator, and perform some basic timing (elapsed time).
Signed-off-by: Thomas Hellström
Nice, I haven't had time to go over it in all detail but it looks pretty
sophisticated.
Feel free to add an Acked-by: Christian König .
Regards,
Christian.
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/tests/Makefile| 3 +-
drivers/gpu/drm/tests/drm_suballoc_test.c | 356 ++
3 files changed, 359 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tests/drm_suballoc_test.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8fbe57407c60..dced53723721 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -78,6 +78,7 @@ config DRM_KUNIT_TEST
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
select DRM_BUDDY
+ select DRM_SUBALLOC_HELPER
select DRM_EXPORT_FOR_TESTS if m
select DRM_KUNIT_TEST_HELPERS
default KUNIT_ALL_TESTS
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index bca726a8f483..c664944a48ab 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_modes_test.o \
drm_plane_helper_test.o \
drm_probe_helper_test.o \
- drm_rect_test.o
+ drm_rect_test.o \
+ drm_suballoc_test.o
CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/gpu/drm/tests/drm_suballoc_test.c
b/drivers/gpu/drm/tests/drm_suballoc_test.c
new file mode 100644
index ..e7303a5505a0
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_suballoc_test.c
@@ -0,0 +1,356 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Test case for the drm_suballoc suballocator manager
+ * Copyright 2023 Intel Corporation.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SA_ITERATIONS 1
+#define SA_SIZE SZ_1M
+#define SA_DEFAULT_ALIGN SZ_4K
+
+static bool intr = true;
+static bool from_reclaim;
+static bool pre_throttle;
+static unsigned int num_rings = 4;
+static unsigned int iterations = SA_ITERATIONS;
+
+static atomic64_t free_space;
+
+static atomic_t other_id;
+
+struct suballoc_fence;
+
+/**
+ * struct suballoc_ring - fake gpu engine.
+ * @list: List of fences to signal.
+ * @signal_time: Accumulated fence signal execution time.
+ * @lock: Protects the suballoc ring members. hardirq safe.
+ * @hrtimer: Fake execution time timer.
+ * @active: The currently active fence for which we have pending work or a
+ * timer running.
+ * @seqno: Fence submissin seqno.
+ * @idx: Index for calculation of fake execution time.
+ * @work: Work struct used solely to move the timer start to a different
+ *processor than that used for submission.
+ */
+struct suballoc_ring {
+ ktime_t signal_time;
+ struct list_head list;
+ /* Protect the ring processing. */
+ spinlock_t lock;
+ struct hrtimer hrtimer;
+ struct suballoc_fence *active;
+ atomic64_t seqno;
+ u32 idx;
+ struct work_struct work;
+};
+
+/**
+ * struct suballoc_fence - Hrtimer-driven fence.
+ * @fence: The base class fence struct.
+ * @link: Link for the ring's fence list.
+ * @size: The size of the suballocator range associated with this fence.
+ * @id: Cpu id likely used by the submission thread for suballoc allocation.
+ */
+struct suballoc_fence {
+ struct dma_fence fence;
+ struct list_head link;
+ size_t size;
+ unsigned int id;
+};
+
+/* A varying but repeatable fake execution time */
+static ktime_t ring_next_delay(struct suballoc_ring *ring)
+{
+ return ns_to_ktime((u64)(++ring->idx % 8) * 200 * NSEC_PER_USEC);
+}
+
+/*
+ * Launch from a work item to decrease the likelyhood of the timer expiry
+ * callback getting called from the allocating cpu.
+ * We want to trigger cache-line bouncing between allocating and signalling
+ * cpus.
+ */
+static void ring_launch_timer_work(struct work_struct *work)
+{
+ struct suballoc_ring *ring =
+ container_of(work, typeof(*ring), work);
+
+ spin_lock_irq(>lock);
+ if (ring->active)
+ hrtimer_start_range_ns(>hrtimer, ring_next_delay(ring),
+ 100ULL * NSEC_PER_USEC,
+ HRTIMER_MODE_REL_PINNED);
+
+ spin_unlock_irq(>lock);
+}
+
+/*
+ * Signal an active fence and pull the next off the list if any and make it
+ * active.
+ */
+static enum hrtimer_restart ring_hrtimer_expired(struct hrtimer *hrtimer)
+{
+ struct suballoc_ring *ring =
+ container_of(hrtimer, typeof(*ring), hrtimer);
+ struct suballoc_fence *sfence;
+ ktime_t now, then;
+ unsigned long irqflags;
+
+
Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
On Thu, Mar 02, 2023 at 09:55:46AM +, Tian, Kevin wrote:
> > From: Liu, Yi L
> > Sent: Thursday, March 2, 2023 2:07 PM
> >
> > > - if (!vfio_dev_in_groups(cur_vma, groups)) {
> > > + if (cur_vma->vdev.open_count &&
> > > + !vfio_dev_in_groups(cur_vma, groups) &&
> > > + !vfio_dev_in_iommufd_ctx(cur_vma, iommufd_ctx)) {
> >
> > Hi Alex, Jason,
> >
> > There is one concern on this approach which is related to the
> > cdev noiommu mode. As patch 16 of this series, cdev path
> > supports noiommu mode by passing a negative iommufd to
> > kernel. In such case, the vfio_device is not bound to a valid
> > iommufd. Then the check in vfio_dev_in_iommufd_ctx() is
> > to be broken.
> >
> > An idea is to add a cdev_noiommu flag in vfio_device, when
> > checking the iommufd_ictx, also check this flag. If all the opened
> > devices in the dev_set have vfio_device->cdev_noiommu==true,
> > then the reset is considered to be doable. But there is a special
> > case. If devices in this dev_set are opened by two applications
> > that operates in cdev noiommu mode, then this logic is not able
> > to differentiate them. In that case, should we allow the reset?
> > It seems to ok to allow reset since noiommu mode itself means
> > no security between the applications that use it. thoughts?
> >
>
> Probably we need still pass in a valid iommufd (instead of using
> a negative value) in noiommu case to mark the ownership so the
> check in the reset path can correctly catch whether an opened
> device belongs to this user.
There should be no iommufd at all in no-iommu mode
Adding one just to deal with noiommu reset seems pretty sad :\
no-iommu is only really used by dpdk, and it doesn't invoke
VFIO_DEVICE_PCI_HOT_RESET at all.
I'd say as long as VFIO_DEVICE_PCI_HOT_RESET works if only one vfio
device is open using a empty list (eg we should ensure that the
invoking cdev itself is allowed) then I think it is OK.
Jason
[Intel-gfx] [PATCH v3] drm/i915/active: Fix misuse of non-idle barriers as fence trackers
Users reported oopses on list corruptions when using i915 perf with a
number of concurrently running graphics applications. Root cause analysis
pointed at an issue in barrier processing code -- a race among perf open /
close replacing active barriers with perf requests on kernel context and
concurrent barrier preallocate / acquire operations performed during user
context first pin / last unpin.
When adding a request to a composite tracker, we try to reuse an existing
fence tracker, already allocated and registered with that composite. The
tracker we obtain may already track another fence, may be an idle barrier,
or an active barrier.
If the tracker we get occurs a non-idle barrier then we try to delete that
barrier from a list of barrier tasks it belongs to. However, while doing
that we don't respect return value from a function that performs the
barrier deletion. Should the deletion ever fail, we would end up reusing
the tracker still registered as a barrier task. Since the same structure
field is reused with both fence callback lists and barrier tasks list,
list corruptions would likely occur.
Barriers are now deleted from a barrier tasks list by temporarily removing
the list content, traversing that content with skip over the node to be
deleted, then populating the list back with the modified content. Should
that intentionally racy concurrent deletion attempts be not serialized,
one or more of those may fail because of the list being temporary empty.
Related code that ignores the results of barrier deletion was initially
introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the
idle-barrier from other kernel requests"). However, all users of the
barrier deletion routine were apparently serialized at that time, then the
issue didn't exhibit itself. Results of git bisect with help of a newly
developed igt@gem_barrier_race@remote-request IGT test indicate that list
corruptions might start to appear after commit 311770173fac ("drm/i915/gt:
Schedule request retirement when timeline idles"), introduced in v5.5.
Respect results of barrier deletion attempts -- mark the barrier as idle
only if successfully deleted from the list. Then, before proceeding with
setting our fence as the one currently tracked, make sure that the tracker
we've got is not a non-idle barrier. If that check fails then don't use
that tracker but go back and try to acquire a new, usable one.
v3: use unlikely() to document what outcome we expect (Andi),
- fix bad grammar in commit description.
v2: no code changes,
- blame commit 311770173fac ("drm/i915/gt: Schedule request retirement
when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow
sharing the idle-barrier from other kernel requests"), v5.4,
- reword commit description.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
Fixes: 311770173fac ("drm/i915/gt: Schedule request retirement when timeline
idles")
Cc: Chris Wilson
Cc: sta...@vger.kernel.org # v5.5
Cc: Andi Shyti
Signed-off-by: Janusz Krzysztofik
---
drivers/gpu/drm/i915/i915_active.c | 25 ++---
1 file changed, 14 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 7412abf166a8c..a9fea115f2d26 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -422,12 +422,12 @@ replace_barrier(struct i915_active *ref, struct
i915_active_fence *active)
* we can use it to substitute for the pending idle-barrer
* request that we want to emit on the kernel_context.
*/
- __active_del_barrier(ref, node_from_active(active));
- return true;
+ return __active_del_barrier(ref, node_from_active(active));
}
int i915_active_add_request(struct i915_active *ref, struct i915_request *rq)
{
+ u64 idx = i915_request_timeline(rq)->fence_context;
struct dma_fence *fence = >fence;
struct i915_active_fence *active;
int err;
@@ -437,16 +437,19 @@ int i915_active_add_request(struct i915_active *ref,
struct i915_request *rq)
if (err)
return err;
- active = active_instance(ref, i915_request_timeline(rq)->fence_context);
- if (!active) {
- err = -ENOMEM;
- goto out;
- }
+ do {
+ active = active_instance(ref, idx);
+ if (!active) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ if (replace_barrier(ref, active)) {
+ RCU_INIT_POINTER(active->fence, NULL);
+ atomic_dec(>count);
+ }
+ } while (unlikely(is_barrier(active)));
- if (replace_barrier(ref, active)) {
- RCU_INIT_POINTER(active->fence, NULL);
- atomic_dec(>count);
- }
if (!__i915_active_fence_set(active, fence))
Re: [Intel-gfx] [PATCH v2] drm/i915/active: Fix misuse of non-idle barriers as fence trackers
Hi Andy,
Thanks for review.
On Thursday, 2 March 2023 01:42:05 CET Andi Shyti wrote:
> Hi Janusz,
>
> On Sat, Feb 25, 2023 at 11:12:18PM +0100, Janusz Krzysztofik wrote:
> > Users reported oopses on list corruptions when using i915 perf with a
> > number of concurrently running graphics applications. Root cause analysis
> > pointed at an issue in barrier processing code -- a race among perf open /
> > close replacing active barriers with perf requests on kernel context and
> > concurrent barrier preallocate / acquire operations performed during user
> > context first pin / last unpin.
> >
> > When adding a request to a composite tracker, we try to reuse an existing
> > fence tracker, already allocated and registered with that composite. The
> > tracker we obtain may already track another fence, may be an idle barrier,
> > or an active barrier.
> >
> > If the tracker we get occurs a non-idle barrier then we try to delete that
> > barrier from a list of barrier tasks it belongs to. However, while doing
> > that we don't respect return value from a function that performs the
> > barrier deletion. Should the deletion ever failed, we would end up
> > reusing the tracker still registered as a barrier task. Since the same
> > structure field is reused with both fence callback lists and barrier
> > tasks list, list corruptions would likely occur.
> >
> > Barriers are now deleted from a barrier tasks list by temporarily removing
> > the list content, traversing that content with skip over the node to be
> > deleted, then populating the list back with the modified content. Should
> > that intentionally racy concurrent deletion attempts be not serialized,
> > one or more of those may fail because of the list being temporary empty.
> >
> > Related code that ignores the results of barrier deletion was initially
> > introduced in v5.4 by commit d8af05ff38ae ("drm/i915: Allow sharing the
> > idle-barrier from other kernel requests"). However, all users of the
> > barrier deletion routine were apparently serialized at that time, then the
> > issue didn't exhibit itself. Results of git bisect with help of a newly
> > developed igt@gem_barrier_race@remote-request IGT test indicate that list
> > corruptions might start to appear after commit 311770173fac ("drm/i915/gt:
> > Schedule request retirement when timeline idles"), introduced in v5.5.
> >
> > Respect results of barrier deletion attempts -- mark the barrier as idle
> > only if successfully deleted from the list. Then, before proceeding with
> > setting our fence as the one currently tracked, make sure that the tracker
> > we've got is not a non-idle barrier. If that check fails then don't use
> > that tracker but go back and try to acquire a new, usable one.
> >
> > v2: no code changes,
> > - blame commit 311770173fac ("drm/i915/gt: Schedule request retirement
> > when timeline idles"), v5.5, not commit d8af05ff38ae ("drm/i915: Allow
> > sharing the idle-barrier from other kernel requests"), v5.4,
> > - reword commit description.
>
> That's a very good explanation and very much needed for such a
> catch. Thanks!
>
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6333
> > Fixes: 311770173fac ("drm/i915/gt: Schedule request retirement when
timeline idles")
> > Cc: Chris Wilson
> > Cc: sta...@vger.kernel.org # v5.5
> > Signed-off-by: Janusz Krzysztofik
> > ---
> > drivers/gpu/drm/i915/i915_active.c | 25 ++---
> > 1 file changed, 14 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/
i915_active.c
> > index 7412abf166a8c..f9282b8c87c1c 100644
> > --- a/drivers/gpu/drm/i915/i915_active.c
> > +++ b/drivers/gpu/drm/i915/i915_active.c
> > @@ -422,12 +422,12 @@ replace_barrier(struct i915_active *ref, struct
i915_active_fence *active)
> > * we can use it to substitute for the pending idle-barrer
> > * request that we want to emit on the kernel_context.
> > */
> > - __active_del_barrier(ref, node_from_active(active));
> > - return true;
> > + return __active_del_barrier(ref, node_from_active(active));
>
> In general, I support the idea of always checking the return
> value, even if we expect a certain outcome. In these cases, the
> likely/unlikely macros can be helpful.
OK.
> Given this change, I
> believe the patch deserves an ack.
>
> That being said, I was curious whether using an explicit lock
> and a normal list of active barriers, rather than a lockless
> list, could have solved the problem. It seems like using a
> lockless list and iterating over it could be overkill, unless
> there are specific scenarios where the lockless properties are
> necessary.
>
> Of course, this may be something to consider in a future cleanup,
> as it may be outside the scope of this particular patch.
Yes, I think so.
>
> > }
> >
> > int i915_active_add_request(struct i915_active *ref, struct i915_request
*rq)
> > {
> > + u64
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915/dmc: mass rename dev_priv to i915
On Wed, Mar 01, 2023 at 02:29:44PM +0200, Jani Nikula wrote:
> Follow the contemporary convention for struct drm_i915_private * naming.
>
> Cc: Imre Deak
> Signed-off-by: Jani Nikula
Looks ok to me, on the patchset:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dmc.c | 166 +++
> 1 file changed, 81 insertions(+), 85 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
> b/drivers/gpu/drm/i915/display/intel_dmc.c
> index 302a465ceb1f..6b162f77340e 100644
> --- a/drivers/gpu/drm/i915/display/intel_dmc.c
> +++ b/drivers/gpu/drm/i915/display/intel_dmc.c
> @@ -313,12 +313,12 @@ intel_get_stepping_info(struct drm_i915_private *i915,
> return si;
> }
>
> -static void gen9_set_dc_state_debugmask(struct drm_i915_private *dev_priv)
> +static void gen9_set_dc_state_debugmask(struct drm_i915_private *i915)
> {
> /* The below bit doesn't need to be cleared ever afterwards */
> - intel_de_rmw(dev_priv, DC_STATE_DEBUG, 0,
> + intel_de_rmw(i915, DC_STATE_DEBUG, 0,
>DC_STATE_DEBUG_MASK_CORES | DC_STATE_DEBUG_MASK_MEMORY_UP);
> - intel_de_posting_read(dev_priv, DC_STATE_DEBUG);
> + intel_de_posting_read(i915, DC_STATE_DEBUG);
> }
>
> static void disable_event_handler(struct drm_i915_private *i915,
> @@ -476,33 +476,33 @@ void intel_dmc_disable_pipe(struct drm_i915_private
> *i915, enum pipe pipe)
>
> /**
> * intel_dmc_load_program() - write the firmware from memory to register.
> - * @dev_priv: i915 drm device.
> + * @i915: i915 drm device.
> *
> * DMC firmware is read from a .bin file and kept in internal memory one
> time.
> * Everytime display comes back from low power state this function is called
> to
> * copy the firmware from internal memory to registers.
> */
> -void intel_dmc_load_program(struct drm_i915_private *dev_priv)
> +void intel_dmc_load_program(struct drm_i915_private *i915)
> {
> - struct i915_power_domains *power_domains =
> _priv->display.power.domains;
> - struct intel_dmc *dmc = i915_to_dmc(dev_priv);
> + struct i915_power_domains *power_domains = >display.power.domains;
> + struct intel_dmc *dmc = i915_to_dmc(i915);
> enum intel_dmc_id dmc_id;
> u32 i;
>
> - if (!intel_dmc_has_payload(dev_priv))
> + if (!intel_dmc_has_payload(i915))
> return;
>
> - pipedmc_clock_gating_wa(dev_priv, true);
> + pipedmc_clock_gating_wa(i915, true);
>
> - disable_all_event_handlers(dev_priv);
> + disable_all_event_handlers(i915);
>
> - assert_rpm_wakelock_held(_priv->runtime_pm);
> + assert_rpm_wakelock_held(>runtime_pm);
>
> preempt_disable();
>
> for_each_dmc_id(dmc_id) {
> for (i = 0; i < dmc->dmc_info[dmc_id].dmc_fw_size; i++) {
> - intel_de_write_fw(dev_priv,
> + intel_de_write_fw(i915,
>
> DMC_PROGRAM(dmc->dmc_info[dmc_id].start_mmioaddr, i),
> dmc->dmc_info[dmc_id].payload[i]);
> }
> @@ -512,23 +512,23 @@ void intel_dmc_load_program(struct drm_i915_private
> *dev_priv)
>
> for_each_dmc_id(dmc_id) {
> for (i = 0; i < dmc->dmc_info[dmc_id].mmio_count; i++) {
> - intel_de_write(dev_priv,
> dmc->dmc_info[dmc_id].mmioaddr[i],
> + intel_de_write(i915, dmc->dmc_info[dmc_id].mmioaddr[i],
> dmc->dmc_info[dmc_id].mmiodata[i]);
> }
> }
>
> power_domains->dc_state = 0;
>
> - gen9_set_dc_state_debugmask(dev_priv);
> + gen9_set_dc_state_debugmask(i915);
>
> /*
>* Flip queue events need to be disabled before enabling DC5/6.
>* i915 doesn't use the flip queue feature, so disable it already
>* here.
>*/
> - disable_all_flip_queue_events(dev_priv);
> + disable_all_flip_queue_events(i915);
>
> - pipedmc_clock_gating_wa(dev_priv, false);
> + pipedmc_clock_gating_wa(i915, false);
> }
>
> /**
> @@ -839,12 +839,12 @@ static u32 parse_dmc_fw_css(struct intel_dmc *dmc,
>
> static void parse_dmc_fw(struct intel_dmc *dmc, const struct firmware *fw)
> {
> - struct drm_i915_private *dev_priv = dmc->i915;
> + struct drm_i915_private *i915 = dmc->i915;
> struct intel_css_header *css_header;
> struct intel_package_header *package_header;
> struct intel_dmc_header_base *dmc_header;
> struct stepping_info display_info = { '*', '*'};
> - const struct stepping_info *si = intel_get_stepping_info(dev_priv,
> _info);
> + const struct stepping_info *si = intel_get_stepping_info(i915,
> _info);
> enum intel_dmc_id dmc_id;
> u32 readcount = 0;
> u32 r, offset;
> @@ -874,7 +874,7 @@ static void parse_dmc_fw(struct intel_dmc *dmc, const
> struct firmware *fw)
>
> offset = readcount +
Re: [Intel-gfx] [PATCH v4] drm/i915: add guard page to ggtt->error_capture
On 02.03.2023 11:43, Tvrtko Ursulin wrote:
On 08/02/2023 10:51, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
to prefetch memory beyond the error_capture, ie it tries
to read memory pointed by next PTE in GGTT.
If this PTE points to invalid address DMAR errors will occur.
This behaviour was observed on ADL, RPL, DG2 platforms.
To avoid it, guard scratch page should be added after error_capture.
The patch fixes the most annoying issue with error capture but
since WC reads are used also in other places there is a risk similar
problem can affect them as well.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Research tells the explanation is plausible so:
Acked-by: Tvrtko Ursulin
Thanks for looking at it.
On patch details below.
What about "simiar risk in other places" - are there any plans to
asses the potential impact elsewhere?
Yes, merging this patch is the 1st step, as error_capture is responsible
for most (maybe even all) regular
DMAR read errors. After removing this noise it will be much easier to
spot other DMAR read errors.
There are also multiple regular DMAR write errors (less frequent, but
still), which I hope to debug if time permits.
Regards
Andrzej
---
This patch tries to diminish plague of DMAR read errors present
in CI for ADL*, RPL*, DG2 platforms, see for example [1] (grep DMAR).
CI is usually tolerant for these errors, so the scale of the problem
is not really visible.
To show it I have counted lines containing DMAR read errors in dmesgs
produced by CI for all three versions of the patch, but in contrast
to v2
I have grepped only for lines containing "PTE Read access".
Below stats for kernel w/o patch vs patched one.
v1: 210 vs 0
v2: 201 vs 0
v3: 214 vs 0
Apparently the patch fixes all common PTE read errors.
In previous version there were different numbers due to less exact
grepping,
"grep DMAR" catched write errors and "DMAR: DRHD: handling fault
status reg"
lines, anyway the actual number of errors is much bigger - DMAR errors
are rate-limited.
[1]:
http://gfx-ci.igk.intel.com/tree/drm-tip/CI_DRM_12678/bat-adln-1/dmesg0.txt
Changelog:
v2:
- modified commit message (I hope the diagnosis is correct),
- added bug checks to ensure scratch is initialized on gen3
platforms.
CI produces strange stacktrace for it suggesting scratch[0] is
NULL,
to be removed after resolving the issue with gen3 platforms.
v3:
- removed bug checks, replaced with gen check.
v4:
- change code for scratch page insertion to support all platforms,
- add info in commit message there could be more similar issues
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 31
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 842e69c7b21e49..6566d2066f1f8b 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -503,6 +503,21 @@ static void cleanup_init_ggtt(struct i915_ggtt
*ggtt)
mutex_destroy(>error_mutex);
}
+static void
+ggtt_insert_scratch_pages(struct i915_ggtt *ggtt, u64 offset, u64
length)
+{
+ struct i915_address_space *vm = >vm;
+
+ if (GRAPHICS_VER(ggtt->vm.i915) < 8)
+ return vm->clear_range(vm, offset, length);
+ /* clear_range since gen8 is nop */
It would also work to simply drop the below, right? If so would that be clearer?
+ while (length > 0) {
Maybe add a GEM_BUG_ON if length is not aligned? Granted it may be a
huge stretch of imagination..
Regards,
Tvrtko
+ vm->insert_page(vm, px_dma(vm->scratch[0]), offset,
I915_CACHE_NONE, 0);
+ offset += I915_GTT_PAGE_SIZE;
+ length -= I915_GTT_PAGE_SIZE;
+ }
+}
+
static int init_ggtt(struct i915_ggtt *ggtt)
{
/*
@@ -551,8 +566,12 @@ static int init_ggtt(struct i915_ggtt *ggtt)
* paths, and we trust that 0 will remain reserved. However,
* the only likely reason for failure to insert is a driver
* bug, which we expect to cause other failures...
+ *
+ * Since CPU can perform speculative reads on error capture
+ * (write-combining allows it) add scratch page after error
+ * capture to avoid DMAR errors.
*/
- ggtt->error_capture.size = I915_GTT_PAGE_SIZE;
+ ggtt->error_capture.size = 2 * I915_GTT_PAGE_SIZE;
ggtt->error_capture.color = I915_COLOR_UNEVICTABLE;
if (drm_mm_reserve_node(>vm.mm, >error_capture))
drm_mm_insert_node_in_range(>vm.mm,
@@ -562,11 +581,15 @@ static int init_ggtt(struct i915_ggtt *ggtt)
0, ggtt->mappable_end,
DRM_MM_INSERT_LOW);
}
- if (drm_mm_node_allocated(>error_capture))
+ if (drm_mm_node_allocated(>error_capture)) {
+ u64
Re: [Intel-gfx] [PATCH v4] drm/i915: add guard page to ggtt->error_capture
On 08/02/2023 10:51, Andrzej Hajda wrote:
Write-combining memory allows speculative reads by CPU.
ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try
to prefetch memory beyond the error_capture, ie it tries
to read memory pointed by next PTE in GGTT.
If this PTE points to invalid address DMAR errors will occur.
This behaviour was observed on ADL, RPL, DG2 platforms.
To avoid it, guard scratch page should be added after error_capture.
The patch fixes the most annoying issue with error capture but
since WC reads are used also in other places there is a risk similar
problem can affect them as well.
Signed-off-by: Andrzej Hajda
Reviewed-by: Andi Shyti
Research tells the explanation is plausible so:
Acked-by: Tvrtko Ursulin
On patch details below.
What about "simiar risk in other places" - are there any plans to asses
the potential impact elsewhere?
---
This patch tries to diminish plague of DMAR read errors present
in CI for ADL*, RPL*, DG2 platforms, see for example [1] (grep DMAR).
CI is usually tolerant for these errors, so the scale of the problem
is not really visible.
To show it I have counted lines containing DMAR read errors in dmesgs
produced by CI for all three versions of the patch, but in contrast to v2
I have grepped only for lines containing "PTE Read access".
Below stats for kernel w/o patch vs patched one.
v1: 210 vs 0
v2: 201 vs 0
v3: 214 vs 0
Apparently the patch fixes all common PTE read errors.
In previous version there were different numbers due to less exact grepping,
"grep DMAR" catched write errors and "DMAR: DRHD: handling fault status reg"
lines, anyway the actual number of errors is much bigger - DMAR errors
are rate-limited.
[1]: http://gfx-ci.igk.intel.com/tree/drm-tip/CI_DRM_12678/bat-adln-1/dmesg0.txt
Changelog:
v2:
- modified commit message (I hope the diagnosis is correct),
- added bug checks to ensure scratch is initialized on gen3 platforms.
CI produces strange stacktrace for it suggesting scratch[0] is NULL,
to be removed after resolving the issue with gen3 platforms.
v3:
- removed bug checks, replaced with gen check.
v4:
- change code for scratch page insertion to support all platforms,
- add info in commit message there could be more similar issues
Regards
Andrzej
---
drivers/gpu/drm/i915/gt/intel_ggtt.c | 31
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 842e69c7b21e49..6566d2066f1f8b 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -503,6 +503,21 @@ static void cleanup_init_ggtt(struct i915_ggtt *ggtt)
mutex_destroy(>error_mutex);
}
+static void
+ggtt_insert_scratch_pages(struct i915_ggtt *ggtt, u64 offset, u64 length)
+{
+ struct i915_address_space *vm = >vm;
+
+ if (GRAPHICS_VER(ggtt->vm.i915) < 8)
+ return vm->clear_range(vm, offset, length);
+ /* clear_range since gen8 is nop */
It would also work to simply drop the below, right? If so would that be clearer?
+ while (length > 0) {
Maybe add a GEM_BUG_ON if length is not aligned? Granted it may be a
huge stretch of imagination..
Regards,
Tvrtko
+ vm->insert_page(vm, px_dma(vm->scratch[0]), offset,
I915_CACHE_NONE, 0);
+ offset += I915_GTT_PAGE_SIZE;
+ length -= I915_GTT_PAGE_SIZE;
+ }
+}
+
static int init_ggtt(struct i915_ggtt *ggtt)
{
/*
@@ -551,8 +566,12 @@ static int init_ggtt(struct i915_ggtt *ggtt)
* paths, and we trust that 0 will remain reserved. However,
* the only likely reason for failure to insert is a driver
* bug, which we expect to cause other failures...
+*
+* Since CPU can perform speculative reads on error capture
+* (write-combining allows it) add scratch page after error
+* capture to avoid DMAR errors.
*/
- ggtt->error_capture.size = I915_GTT_PAGE_SIZE;
+ ggtt->error_capture.size = 2 * I915_GTT_PAGE_SIZE;
ggtt->error_capture.color = I915_COLOR_UNEVICTABLE;
if (drm_mm_reserve_node(>vm.mm, >error_capture))
drm_mm_insert_node_in_range(>vm.mm,
@@ -562,11 +581,15 @@ static int init_ggtt(struct i915_ggtt *ggtt)
0, ggtt->mappable_end,
DRM_MM_INSERT_LOW);
}
- if (drm_mm_node_allocated(>error_capture))
+ if (drm_mm_node_allocated(>error_capture)) {
+ u64 start = ggtt->error_capture.start;
+ u64 size = ggtt->error_capture.size;
+
+ ggtt_insert_scratch_pages(ggtt, start, size);
drm_dbg(>vm.i915->drm,
"Reserved GGTT:[%llx, %llx]
Re: [Intel-gfx] [PATCH v5 1/2] drm/i915: Migrate platform-dependent mock hugepage selftests to live
On 28/02/2023 14:08, Matthew Auld wrote:
On 27/02/2023 17:19, Jonathan Cavitt wrote:
Convert the igt_mock_ppgtt_huge_fill and igt_mock_ppgtt_64K mock
selftests into
live selftests as their requirements have recently become
platform-dependent.
Additionally, apply necessary platform dependency checks to these tests.
v2: Reorder
Signed-off-by: Jonathan Cavitt
r-b still stands for the series. Note that CI is busted atm though, so
we can't merge this yet. Likely need to re-trigger testing for the
series once CI/drm-tip is working again.
CI looks to be back. Can you trigger a retest through patchwork, or
resend the series?
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 22 ++-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index defece0bcb81..375f119ab261 100644
--- a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
+++ b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
@@ -710,7 +710,7 @@ static void close_object_list(struct list_head
*objects,
}
}
-static int igt_mock_ppgtt_huge_fill(void *arg)
+static int igt_ppgtt_huge_fill(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -784,7 +784,8 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
GEM_BUG_ON(!expected_gtt);
GEM_BUG_ON(size);
- if (expected_gtt & I915_GTT_PAGE_SIZE_4K)
+ if (expected_gtt & I915_GTT_PAGE_SIZE_4K &&
+ GRAPHICS_VER_FULL(i915) < IP_VER(12, 50))
expected_gtt &= ~I915_GTT_PAGE_SIZE_64K;
i915_vma_unpin(vma);
@@ -831,7 +832,7 @@ static int igt_mock_ppgtt_huge_fill(void *arg)
return err;
}
-static int igt_mock_ppgtt_64K(void *arg)
+static int igt_ppgtt_64K(void *arg)
{
struct i915_ppgtt *ppgtt = arg;
struct drm_i915_private *i915 = ppgtt->vm.i915;
@@ -913,6 +914,17 @@ static int igt_mock_ppgtt_64K(void *arg)
unsigned int offset = objects[i].offset;
unsigned int flags = PIN_USER;
+ /*
+ * For modern GTT models, the requirements for marking a
page-table
+ * as 64K have been relaxed. Account for this.
+ */
+
+ if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50)) {
+ expected_gtt = 0;
+ expected_gtt |= size & (SZ_64K | SZ_2M) ?
I915_GTT_PAGE_SIZE_64K : 0;
+ expected_gtt |= size & SZ_4K ? I915_GTT_PAGE_SIZE_4K : 0;
+ }
+
for (single = 0; single <= 1; single++) {
obj = fake_huge_pages_object(i915, size, !!single);
if (IS_ERR(obj))
@@ -1910,8 +1922,6 @@ int i915_gem_huge_page_mock_selftests(void)
SUBTEST(igt_mock_exhaust_device_supported_pages),
SUBTEST(igt_mock_memory_region_huge_pages),
SUBTEST(igt_mock_ppgtt_misaligned_dma),
- SUBTEST(igt_mock_ppgtt_huge_fill),
- SUBTEST(igt_mock_ppgtt_64K),
};
struct drm_i915_private *dev_priv;
struct i915_ppgtt *ppgtt;
@@ -1962,6 +1972,8 @@ int i915_gem_huge_page_live_selftests(struct
drm_i915_private *i915)
SUBTEST(igt_ppgtt_sanity_check),
SUBTEST(igt_ppgtt_compact),
SUBTEST(igt_ppgtt_mixed),
+ SUBTEST(igt_ppgtt_huge_fill),
+ SUBTEST(igt_ppgtt_64K),
};
if (!HAS_PPGTT(i915)) {
Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET
> From: Liu, Yi L
> Sent: Thursday, March 2, 2023 2:07 PM
>
> > - if (!vfio_dev_in_groups(cur_vma, groups)) {
> > + if (cur_vma->vdev.open_count &&
> > + !vfio_dev_in_groups(cur_vma, groups) &&
> > + !vfio_dev_in_iommufd_ctx(cur_vma, iommufd_ctx)) {
>
> Hi Alex, Jason,
>
> There is one concern on this approach which is related to the
> cdev noiommu mode. As patch 16 of this series, cdev path
> supports noiommu mode by passing a negative iommufd to
> kernel. In such case, the vfio_device is not bound to a valid
> iommufd. Then the check in vfio_dev_in_iommufd_ctx() is
> to be broken.
>
> An idea is to add a cdev_noiommu flag in vfio_device, when
> checking the iommufd_ictx, also check this flag. If all the opened
> devices in the dev_set have vfio_device->cdev_noiommu==true,
> then the reset is considered to be doable. But there is a special
> case. If devices in this dev_set are opened by two applications
> that operates in cdev noiommu mode, then this logic is not able
> to differentiate them. In that case, should we allow the reset?
> It seems to ok to allow reset since noiommu mode itself means
> no security between the applications that use it. thoughts?
>
Probably we need still pass in a valid iommufd (instead of using
a negative value) in noiommu case to mark the ownership so the
check in the reset path can correctly catch whether an opened
device belongs to this user.
That implies we may instead use a flag bit to mark NOIOMMU
mode and in the kernel also has a noiommu flag in device
file to differentiate it from normal case.
Re: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM DEMAND
> -Original Message-
> From: Murthy, Arun R
> Sent: Thursday, March 2, 2023 10:50 AM
> To: Kahola, Mika ; intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas ; Roper, Matthew D
>
> Subject: RE: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM
> DEMAND
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Mika Kahola
> > Sent: Friday, February 24, 2023 3:44 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: De Marchi, Lucas ; Roper, Matthew D
> >
> > Subject: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM
> > DEMAND
> >
> > Display14 introduces a new way to instruct the PUnit with power and
> > bandwidth requirements of DE. Add the functionality to program the
> > registers and handle waits using interrupts.
> > The current wait time for timeouts is programmed for 10 msecs to
> > factor in the worst case scenarios. Changes made to use REG_BIT for a
> > register that we touched(GEN8_DE_MISC_IER _MMIO).
> >
> > v2:
> > - Removed repeated definition of dbuf, which has been moved to struct
> > intel_display. (Gustavo)
> > - s/dev_priv->dbuf/dev_priv->display.dbuf/ (Gustavo)
> >
> > Bspec: 66451, 64636, 64602, 64603
> > Cc: Matt Atwood
> > Cc: Matt Roper
> > Cc: Lucas De Marchi
> > Cc: Gustavo Sousa
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Radhakrishna Sripada
> > Link:
> > https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-8-
> > mika.kah...@intel.com
> > ---
> > drivers/gpu/drm/i915/display/intel_bw.c | 4 +-
> > drivers/gpu/drm/i915/display/intel_bw.h | 2 +
> > drivers/gpu/drm/i915/display/intel_display.c | 14 +
> > .../drm/i915/display/intel_display_power.c| 8 +
> > drivers/gpu/drm/i915/i915_drv.h | 6 +
> > drivers/gpu/drm/i915/i915_irq.c | 22 +-
> > drivers/gpu/drm/i915/i915_reg.h | 33 +-
> > drivers/gpu/drm/i915/intel_pm.c | 286 ++
> > drivers/gpu/drm/i915/intel_pm.h | 35 +++
> > 9 files changed, 405 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> > b/drivers/gpu/drm/i915/display/intel_bw.c
> > index 202321ffbe2a..87c20bf52123 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> > @@ -746,8 +746,8 @@ static unsigned int
> > intel_bw_num_active_planes(struct drm_i915_private *dev_priv
> > return num_active_planes;
> > }
> >
> > -static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > - const struct intel_bw_state *bw_state)
> > +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > + const struct intel_bw_state *bw_state)
> > {
> > unsigned int data_rate = 0;
> > enum pipe pipe;
> > diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> > b/drivers/gpu/drm/i915/display/intel_bw.h
> > index f20292143745..17fc0b61db04 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bw.h
> > +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> > @@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private
> > *dev_priv); int intel_bw_atomic_check(struct intel_atomic_state
> > *state); void intel_bw_crtc_update(struct intel_bw_state *bw_state,
> > const struct intel_crtc_state *crtc_state);
> > +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> > + const struct intel_bw_state *bw_state);
> > int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> > u32 points_mask);
> > int intel_bw_calc_min_cdclk(struct intel_atomic_state *state, diff
> > --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 8030968e7008..676bf512b9ce 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -959,6 +959,9 @@ intel_get_crtc_new_encoder(const struct
> > intel_atomic_state *state,
> > num_encoders++;
> > }
> >
> > + if (!encoder)
> > + return NULL;
> > +
> > drm_WARN(encoder->base.dev, num_encoders != 1,
> > "%d encoders for pipe %c\n",
> > num_encoders, pipe_name(master_crtc->pipe)); @@ -
> > 6823,6 +6826,10 @@ int intel_atomic_check(struct drm_device *dev,
> > ret = intel_modeset_calc_cdclk(state);
> > if (ret)
> > return ret;
> > +
> > + ret = intel_pmdemand_atomic_check(state);
> > + if (ret)
> > + goto fail;
> > }
> >
> > ret = intel_atomic_check_crtcs(state); @@ -7439,6 +7446,7 @@ static
> > void intel_atomic_commit_tail(struct intel_atomic_state *state)
> > }
> >
> > intel_sagv_pre_plane_update(state);
> > + intel_pmdemand_pre_plane_update(state);
> >
> > /* Complete the events for pipes that have now been
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/tests: Suballocator test (rev2)
== Series Details == Series: drm/tests: Suballocator test (rev2) URL : https://patchwork.freedesktop.org/series/114410/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12800 -> Patchwork_114410v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_114410v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_114410v2, 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_114410v2/index.html Participating hosts (38 -> 3) -- ERROR: It appears as if the changes made in Patchwork_114410v2 prevented too many machines from booting. Additional (1): bat-atsm-1 Missing(36): fi-rkl-11600 bat-adls-5 bat-dg1-5 bat-adlp-6 fi-apl-guc fi-snb-2520m bat-rpls-1 fi-blb-e6850 bat-rpls-2 fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 fi-ilk-650 fi-hsw-4770 bat-adln-1 fi-ivb-3770 bat-jsl-3 bat-rplp-1 fi-elk-e7500 bat-dg2-11 fi-bsw-nick fi-kbl-7567u bat-dg1-7 bat-kbl-2 bat-adlp-9 fi-skl-guc fi-cfl-8700k fi-glk-j4005 bat-jsl-1 fi-tgl-1115g4 fi-cfl-guc fi-kbl-guc fi-kbl-x1275 fi-cfl-8109u Known issues Here are the changes found in Patchwork_114410v2 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][3] ([i915#4077]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4079]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#6621]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@i915_pm_...@basic-api.html * igt@i915_suspend@basic-s3-without-i915: - bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#6645]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@size-max: - bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#6077]) +36 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@kms_addfb_ba...@size-max.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#6078]) +19 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html * igt@kms_flip@basic-plain-flip: - bat-atsm-1: NOTRUN -> [SKIP][9] ([i915#6166]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@kms_f...@basic-plain-flip.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-atsm-1: NOTRUN -> [SKIP][10] ([i915#6093]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@hang-read-crc: - bat-atsm-1: NOTRUN -> [SKIP][11] ([i915#1836]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@kms_pipe_crc_ba...@hang-read-crc.html * igt@kms_prop_blob@basic: - bat-atsm-1: NOTRUN -> [SKIP][12] ([i915#7357]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@kms_prop_b...@basic.html * igt@kms_psr@sprite_plane_onoff: - bat-atsm-1: NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - bat-atsm-1: NOTRUN -> [SKIP][14] ([i915#6094]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-flip: - bat-atsm-1: NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#6078]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_114410v2/bat-atsm-1/igt@prime_v...@basic-fence-flip.html * igt@prime_vgem@basic-fence-mmap: - bat-atsm-1:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/tests: Suballocator test (rev2)
== Series Details == Series: drm/tests: Suballocator test (rev2) URL : https://patchwork.freedesktop.org/series/114410/ State : warning == Summary == Error: dim checkpatch failed 6ee63db5189b drm/tests: Suballocator test Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:40: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #40: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 371 lines checked
[Intel-gfx] ✗ Fi.CI.BAT: failure for DP2.0 SDP CRC16 for 128/132b link layer (rev3)
== Series Details == Series: DP2.0 SDP CRC16 for 128/132b link layer (rev3) URL : https://patchwork.freedesktop.org/series/113134/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12800 -> Patchwork_113134v3 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_113134v3 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_113134v3, 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_113134v3/index.html Participating hosts (38 -> 3) -- ERROR: It appears as if the changes made in Patchwork_113134v3 prevented too many machines from booting. Additional (1): bat-atsm-1 Missing(36): fi-rkl-11600 bat-adls-5 bat-dg1-5 bat-adlp-6 fi-apl-guc fi-snb-2520m bat-rpls-1 fi-blb-e6850 bat-rpls-2 fi-skl-6600u fi-bsw-n3050 bat-dg2-8 bat-adlm-1 bat-dg2-9 fi-ilk-650 fi-hsw-4770 bat-adln-1 fi-ivb-3770 bat-jsl-3 bat-rplp-1 fi-elk-e7500 bat-dg2-11 fi-bsw-nick fi-kbl-7567u bat-dg1-7 bat-kbl-2 bat-adlp-9 fi-skl-guc fi-cfl-8700k fi-glk-j4005 bat-jsl-1 fi-tgl-1115g4 fi-cfl-guc fi-kbl-guc fi-kbl-x1275 fi-cfl-8109u Known issues Here are the changes found in Patchwork_113134v3 that come from known issues: ### IGT changes ### Issues hit * igt@fbdev@eof: - bat-atsm-1: NOTRUN -> [SKIP][1] ([i915#2582]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@fb...@eof.html * igt@gem_mmap@basic: - bat-atsm-1: NOTRUN -> [SKIP][2] ([i915#4083]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@gem_m...@basic.html * igt@gem_tiled_fence_blits@basic: - bat-atsm-1: NOTRUN -> [SKIP][3] ([i915#4077]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@gem_tiled_fence_bl...@basic.html * igt@gem_tiled_pread_basic: - bat-atsm-1: NOTRUN -> [SKIP][4] ([i915#4079]) +1 similar issue [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@gem_tiled_pread_basic.html * igt@i915_pm_rps@basic-api: - bat-atsm-1: NOTRUN -> [SKIP][5] ([i915#6621]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@i915_pm_...@basic-api.html * igt@i915_suspend@basic-s3-without-i915: - bat-atsm-1: NOTRUN -> [SKIP][6] ([i915#6645]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_addfb_basic@size-max: - bat-atsm-1: NOTRUN -> [SKIP][7] ([i915#6077]) +36 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@kms_addfb_ba...@size-max.html * igt@kms_cursor_legacy@basic-flip-after-cursor-atomic: - bat-atsm-1: NOTRUN -> [SKIP][8] ([i915#6078]) +19 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@kms_cursor_leg...@basic-flip-after-cursor-atomic.html * igt@kms_flip@basic-plain-flip: - bat-atsm-1: NOTRUN -> [SKIP][9] ([i915#6166]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@kms_f...@basic-plain-flip.html * igt@kms_force_connector_basic@prune-stale-modes: - bat-atsm-1: NOTRUN -> [SKIP][10] ([i915#6093]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@kms_force_connector_ba...@prune-stale-modes.html * igt@kms_pipe_crc_basic@hang-read-crc: - bat-atsm-1: NOTRUN -> [SKIP][11] ([i915#1836]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@kms_pipe_crc_ba...@hang-read-crc.html * igt@kms_prop_blob@basic: - bat-atsm-1: NOTRUN -> [SKIP][12] ([i915#7357]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@kms_prop_b...@basic.html * igt@kms_psr@sprite_plane_onoff: - bat-atsm-1: NOTRUN -> [SKIP][13] ([i915#1072]) +3 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@kms_psr@sprite_plane_onoff.html * igt@kms_setmode@basic-clone-single-crtc: - bat-atsm-1: NOTRUN -> [SKIP][14] ([i915#6094]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@kms_setm...@basic-clone-single-crtc.html * igt@prime_vgem@basic-fence-flip: - bat-atsm-1: NOTRUN -> [SKIP][15] ([fdo#109295] / [i915#6078]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113134v3/bat-atsm-1/igt@prime_v...@basic-fence-flip.html * igt@prime_vgem@basic-fence-mmap: - bat-atsm-1:
Re: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM DEMAND
> -Original Message-
> From: Intel-gfx On Behalf Of Mika
> Kahola
> Sent: Friday, February 24, 2023 3:44 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: De Marchi, Lucas ; Roper, Matthew D
>
> Subject: [Intel-gfx] [PATCH v4 07/22] drm/i915/mtl: Add support for PM
> DEMAND
>
> Display14 introduces a new way to instruct the PUnit with power and
> bandwidth requirements of DE. Add the functionality to program the
> registers and handle waits using interrupts.
> The current wait time for timeouts is programmed for 10 msecs to factor in
> the worst case scenarios. Changes made to use REG_BIT for a register that
> we touched(GEN8_DE_MISC_IER _MMIO).
>
> v2:
> - Removed repeated definition of dbuf, which has been moved to struct
> intel_display. (Gustavo)
> - s/dev_priv->dbuf/dev_priv->display.dbuf/ (Gustavo)
>
> Bspec: 66451, 64636, 64602, 64603
> Cc: Matt Atwood
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Cc: Gustavo Sousa
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Radhakrishna Sripada
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20221014124740.774835-8-
> mika.kah...@intel.com
> ---
> drivers/gpu/drm/i915/display/intel_bw.c | 4 +-
> drivers/gpu/drm/i915/display/intel_bw.h | 2 +
> drivers/gpu/drm/i915/display/intel_display.c | 14 +
> .../drm/i915/display/intel_display_power.c| 8 +
> drivers/gpu/drm/i915/i915_drv.h | 6 +
> drivers/gpu/drm/i915/i915_irq.c | 22 +-
> drivers/gpu/drm/i915/i915_reg.h | 33 +-
> drivers/gpu/drm/i915/intel_pm.c | 286 ++
> drivers/gpu/drm/i915/intel_pm.h | 35 +++
> 9 files changed, 405 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.c
> b/drivers/gpu/drm/i915/display/intel_bw.c
> index 202321ffbe2a..87c20bf52123 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.c
> +++ b/drivers/gpu/drm/i915/display/intel_bw.c
> @@ -746,8 +746,8 @@ static unsigned int
> intel_bw_num_active_planes(struct drm_i915_private *dev_priv
> return num_active_planes;
> }
>
> -static unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> -const struct intel_bw_state *bw_state)
> +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> + const struct intel_bw_state *bw_state)
> {
> unsigned int data_rate = 0;
> enum pipe pipe;
> diff --git a/drivers/gpu/drm/i915/display/intel_bw.h
> b/drivers/gpu/drm/i915/display/intel_bw.h
> index f20292143745..17fc0b61db04 100644
> --- a/drivers/gpu/drm/i915/display/intel_bw.h
> +++ b/drivers/gpu/drm/i915/display/intel_bw.h
> @@ -62,6 +62,8 @@ int intel_bw_init(struct drm_i915_private *dev_priv);
> int intel_bw_atomic_check(struct intel_atomic_state *state); void
> intel_bw_crtc_update(struct intel_bw_state *bw_state,
> const struct intel_crtc_state *crtc_state);
> +unsigned int intel_bw_data_rate(struct drm_i915_private *dev_priv,
> + const struct intel_bw_state *bw_state);
> int icl_pcode_restrict_qgv_points(struct drm_i915_private *dev_priv,
> u32 points_mask);
> int intel_bw_calc_min_cdclk(struct intel_atomic_state *state, diff --git
> a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 8030968e7008..676bf512b9ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -959,6 +959,9 @@ intel_get_crtc_new_encoder(const struct
> intel_atomic_state *state,
> num_encoders++;
> }
>
> + if (!encoder)
> + return NULL;
> +
> drm_WARN(encoder->base.dev, num_encoders != 1,
>"%d encoders for pipe %c\n",
>num_encoders, pipe_name(master_crtc->pipe)); @@ -
> 6823,6 +6826,10 @@ int intel_atomic_check(struct drm_device *dev,
> ret = intel_modeset_calc_cdclk(state);
> if (ret)
> return ret;
> +
> + ret = intel_pmdemand_atomic_check(state);
> + if (ret)
> + goto fail;
> }
>
> ret = intel_atomic_check_crtcs(state); @@ -7439,6 +7446,7 @@ static
> void intel_atomic_commit_tail(struct intel_atomic_state *state)
> }
>
> intel_sagv_pre_plane_update(state);
> + intel_pmdemand_pre_plane_update(state);
>
> /* Complete the events for pipes that have now been disabled */
> for_each_new_intel_crtc_in_state(state, crtc, new_crtc_state, i) {
> @@ -7551,6 +7559,7 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> intel_verify_planes(state);
>
> intel_sagv_post_plane_update(state);
> + intel_pmdemand_post_plane_update(state);
>
> drm_atomic_helper_commit_hw_done(>base);
>
> @@ -8282,6 +8291,7 @@ void
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DP2.0 SDP CRC16 for 128/132b link layer (rev3)
== Series Details == Series: DP2.0 SDP CRC16 for 128/132b link layer (rev3) URL : https://patchwork.freedesktop.org/series/113134/ State : warning == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/113134/revisions/3/mbox/ not found
[Intel-gfx] [PATCH RESEND] drm/tests: Suballocator test
Add a suballocator test to get some test coverage for the new drm
suballocator, and perform some basic timing (elapsed time).
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/tests/Makefile| 3 +-
drivers/gpu/drm/tests/drm_suballoc_test.c | 356 ++
3 files changed, 359 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/tests/drm_suballoc_test.c
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 8fbe57407c60..dced53723721 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -78,6 +78,7 @@ config DRM_KUNIT_TEST
select DRM_LIB_RANDOM
select DRM_KMS_HELPER
select DRM_BUDDY
+ select DRM_SUBALLOC_HELPER
select DRM_EXPORT_FOR_TESTS if m
select DRM_KUNIT_TEST_HELPERS
default KUNIT_ALL_TESTS
diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile
index bca726a8f483..c664944a48ab 100644
--- a/drivers/gpu/drm/tests/Makefile
+++ b/drivers/gpu/drm/tests/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_DRM_KUNIT_TEST) += \
drm_modes_test.o \
drm_plane_helper_test.o \
drm_probe_helper_test.o \
- drm_rect_test.o
+ drm_rect_test.o \
+ drm_suballoc_test.o
CFLAGS_drm_mm_test.o := $(DISABLE_STRUCTLEAK_PLUGIN)
diff --git a/drivers/gpu/drm/tests/drm_suballoc_test.c
b/drivers/gpu/drm/tests/drm_suballoc_test.c
new file mode 100644
index ..e7303a5505a0
--- /dev/null
+++ b/drivers/gpu/drm/tests/drm_suballoc_test.c
@@ -0,0 +1,356 @@
+// SPDX-License-Identifier: GPL-2.0 OR MIT
+/*
+ * Test case for the drm_suballoc suballocator manager
+ * Copyright 2023 Intel Corporation.
+ */
+
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SA_ITERATIONS 1
+#define SA_SIZE SZ_1M
+#define SA_DEFAULT_ALIGN SZ_4K
+
+static bool intr = true;
+static bool from_reclaim;
+static bool pre_throttle;
+static unsigned int num_rings = 4;
+static unsigned int iterations = SA_ITERATIONS;
+
+static atomic64_t free_space;
+
+static atomic_t other_id;
+
+struct suballoc_fence;
+
+/**
+ * struct suballoc_ring - fake gpu engine.
+ * @list: List of fences to signal.
+ * @signal_time: Accumulated fence signal execution time.
+ * @lock: Protects the suballoc ring members. hardirq safe.
+ * @hrtimer: Fake execution time timer.
+ * @active: The currently active fence for which we have pending work or a
+ * timer running.
+ * @seqno: Fence submissin seqno.
+ * @idx: Index for calculation of fake execution time.
+ * @work: Work struct used solely to move the timer start to a different
+ *processor than that used for submission.
+ */
+struct suballoc_ring {
+ ktime_t signal_time;
+ struct list_head list;
+ /* Protect the ring processing. */
+ spinlock_t lock;
+ struct hrtimer hrtimer;
+ struct suballoc_fence *active;
+ atomic64_t seqno;
+ u32 idx;
+ struct work_struct work;
+};
+
+/**
+ * struct suballoc_fence - Hrtimer-driven fence.
+ * @fence: The base class fence struct.
+ * @link: Link for the ring's fence list.
+ * @size: The size of the suballocator range associated with this fence.
+ * @id: Cpu id likely used by the submission thread for suballoc allocation.
+ */
+struct suballoc_fence {
+ struct dma_fence fence;
+ struct list_head link;
+ size_t size;
+ unsigned int id;
+};
+
+/* A varying but repeatable fake execution time */
+static ktime_t ring_next_delay(struct suballoc_ring *ring)
+{
+ return ns_to_ktime((u64)(++ring->idx % 8) * 200 * NSEC_PER_USEC);
+}
+
+/*
+ * Launch from a work item to decrease the likelyhood of the timer expiry
+ * callback getting called from the allocating cpu.
+ * We want to trigger cache-line bouncing between allocating and signalling
+ * cpus.
+ */
+static void ring_launch_timer_work(struct work_struct *work)
+{
+ struct suballoc_ring *ring =
+ container_of(work, typeof(*ring), work);
+
+ spin_lock_irq(>lock);
+ if (ring->active)
+ hrtimer_start_range_ns(>hrtimer, ring_next_delay(ring),
+ 100ULL * NSEC_PER_USEC,
+ HRTIMER_MODE_REL_PINNED);
+
+ spin_unlock_irq(>lock);
+}
+
+/*
+ * Signal an active fence and pull the next off the list if any and make it
+ * active.
+ */
+static enum hrtimer_restart ring_hrtimer_expired(struct hrtimer *hrtimer)
+{
+ struct suballoc_ring *ring =
+ container_of(hrtimer, typeof(*ring), hrtimer);
+ struct suballoc_fence *sfence;
+ ktime_t now, then;
+ unsigned long irqflags;
+
+ spin_lock_irqsave(>lock, irqflags);
+ sfence = ring->active;
+
+ if (sfence) {
+ struct dma_fence *fence = >fence;
+
+ if (sfence->id != get_cpu())
+ atomic_inc(_id);
+
[Intel-gfx] [PATCHv4 2/2] i915/display/dp: SDP CRC16 for 128b132b link layer
Enable SDP error detection configuration, this will set CRC16 in
128b/132b link layer.
For Display version 13 a hardware bit31 in register VIDEO_DIP_CTL is
added to enable/disable SDP CRC applicable for DP2.0 only, but the
default value of this bit will enable CRC16 in 128b/132b hence
skipping this write.
Corrective actions on SDP corruption is yet to be defined.
v2: Moved the CRC enable to link training init(Jani N)
v3: Moved crc enable to ddi pre enable
v4: Separate function for SDP CRC16 (Jani N)
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4
.../drm/i915/display/intel_dp_link_training.c | 20 +++
.../drm/i915/display/intel_dp_link_training.h | 2 ++
3 files changed, 26 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index e5979427b38b..127b3035f92d 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -2519,6 +2519,10 @@ static void intel_ddi_pre_enable_dp(struct
intel_atomic_state *state,
{
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
+ if (HAS_DP20(dev_priv))
+ intel_dp_128b132b_sdp_crc16(enc_to_intel_dp(encoder),
+ crtc_state);
+
if (DISPLAY_VER(dev_priv) >= 12)
tgl_ddi_pre_enable_dp(state, encoder, crtc_state, conn_state);
else
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..35d31e4efab9 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.c
@@ -1454,3 +1454,23 @@ void intel_dp_start_link_train(struct intel_dp *intel_dp,
if (!passed)
intel_dp_schedule_fallback_link_training(intel_dp, crtc_state);
}
+
+void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
+
+ /*
+* VIDEO_DIP_CTL register bit 31 should be set to '0' to not
+* disable SDP CRC. This is applicable for Display version 13.
+* Default value of bit 31 is '0' hence discarding the write
+* TODO: Corrective actions on SDP corruption yet to be defined
+*/
+ if (intel_dp_is_uhbr(crtc_state))
+ /* DP v2.0 SCR on SDP CRC16 for 128b/132b Link Layer */
+ drm_dp_dpcd_writeb(_dp->aux,
+ DP_SDP_ERROR_DETECTION_CONFIGURATION,
+ DP_SDP_CRC16_128B132B_EN);
+
+ drm_dbg_kms(>drm, "DP2.0 SDP CRC16 for 128b/132b enabled\n");
+}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
index 7fa1c0833096..2c8f2775891b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_link_training.h
+++ b/drivers/gpu/drm/i915/display/intel_dp_link_training.h
@@ -39,4 +39,6 @@ static inline u8 intel_dp_training_pattern_symbol(u8 pattern)
return pattern & ~DP_LINK_SCRAMBLING_DISABLE;
}
+void intel_dp_128b132b_sdp_crc16(struct intel_dp *intel_dp,
+const struct intel_crtc_state *crtc_state);
#endif /* __INTEL_DP_LINK_TRAINING_H__ */
--
2.25.1
[Intel-gfx] [PATCHv3 0/2] DP2.0 SDP CRC16 for 128/132b link layer
*** BLURB HERE *** Arun R Murthy (2): drm: Add SDP Error Detection Configuration Register i915/display/dp: SDP CRC16 for 128b132b link layer .../gpu/drm/i915/display/intel_dp_link_training.c| 12 include/drm/display/drm_dp.h | 3 +++ 2 files changed, 15 insertions(+) -- 2.25.1
[Intel-gfx] [RESEND PATCHv2 1/2] drm: Add SDP Error Detection Configuration Register
DP2.0 E11 defines a new register to facilitate SDP error detection by a 128B/132B capable DPRX device. v2: Update the macro name to reflect the DP spec(Harry) Signed-off-by: Arun R Murthy Reviewed-by: Harry Wentland --- include/drm/display/drm_dp.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/drm/display/drm_dp.h b/include/drm/display/drm_dp.h index 632376c291db..358db4a9f167 100644 --- a/include/drm/display/drm_dp.h +++ b/include/drm/display/drm_dp.h @@ -692,6 +692,9 @@ # define DP_FEC_LANE_2_SELECT (2 << 4) # define DP_FEC_LANE_3_SELECT (3 << 4) +#define DP_SDP_ERROR_DETECTION_CONFIGURATION 0x121 /* DP 2.0 E11 */ +#define DP_SDP_CRC16_128B132B_EN BIT(0) + #define DP_AUX_FRAME_SYNC_VALUE0x15c /* eDP 1.4 */ # define DP_AUX_FRAME_SYNC_VALID (1 << 0) -- 2.25.1
