Re: [Intel-gfx] [PATCH 1/5] drm/i915/dsc: Add PPS enum

> On Mon, 10 Jul 2023, Jani Nikula wrote: > > On Mon, 10 Jul 2023, Suraj Kandpal wrote: > >> Add PPS enum so that we can later on use it to distinguish which PPS > >> is being read or written onto. > > > > The patch adding the enum alone isn't useful, should be squashed with > > something that us

Re: [Intel-gfx] [PATCH v2 10/19] drm/i915/dsb: Add support for non-posted DSB registers writes

> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Wednesday, June 7, 2023 12:45 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 10/19] drm/i915/dsb: Add support for non- > posted DSB registers writes > > From: Ville Syrjälä > > Writi

[Intel-gfx] ✓ Fi.CI.IGT: success for Enhance vfio PCI hot reset for vfio cdev device (rev9)

== Series Details == Series: Enhance vfio PCI hot reset for vfio cdev device (rev9) URL : https://patchwork.freedesktop.org/series/116991/ State : success == Summary == CI Bug Log - changes from CI_DRM_13366_full -> Patchwork_116991v9_full

Re: [Intel-gfx] [PATCH 5/5] drm/i915/display: Compare the readout dsc pps params

> On Mon, 10 Jul 2023, Suraj Kandpal wrote: > > With the dsc config being readout and filled in crtc_state add macros > > and use them to compare current and previous PPS param in DSC. > > > > Signed-off-by: Suraj Kandpal > > --- > > drivers/gpu/drm/i915/display/intel_display.c | 55 > >

Re: [Intel-gfx] [PATCH v2 07/19] drm/i915/dsb: Don't use indexed writes when byte enables are not all set

> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Wednesday, June 7, 2023 12:45 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 07/19] drm/i915/dsb: Don't use indexed writes > when byte enables are not all set > > From: Ville Syrjälä

Re: [Intel-gfx] [PATCH v2 03/19] drm/i915/dsb: Dump the DSB command buffer when DSB fails

> -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: Wednesday, June 7, 2023 12:45 AM > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH v2 03/19] drm/i915/dsb: Dump the DSB command > buffer when DSB fails > > From: Ville Syrjälä > > Dump the fu

[Intel-gfx] ✓ Fi.CI.BAT: success for Enhance vfio PCI hot reset for vfio cdev device (rev9)

== Series Details == Series: Enhance vfio PCI hot reset for vfio cdev device (rev9) URL : https://patchwork.freedesktop.org/series/116991/ State : success == Summary == CI Bug Log - changes from CI_DRM_13366 -> Patchwork_116991v9 Summary --

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add vfio_device cdev for iommufd support (rev18)

== Series Details == Series: Add vfio_device cdev for iommufd support (rev18) URL : https://patchwork.freedesktop.org/series/113696/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/113696/revisions/18/mbox/ not applied Applying: vfio: Allocate per

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enhance vfio PCI hot reset for vfio cdev device (rev9)

== Series Details == Series: Enhance vfio PCI hot reset for vfio cdev device (rev9) URL : https://patchwork.freedesktop.org/series/116991/ State : warning == Summary == Error: dim checkpatch failed 50730df5f4fd vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset() 093

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Allow panel drrs modes to have differing sync polarities

== Series Details == Series: drm/i915: Allow panel drrs modes to have differing sync polarities URL : https://patchwork.freedesktop.org/series/120484/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13366_full -> Patchwork_120484v1_full ==

[Intel-gfx] [PATCH v14 26/26] docs: vfio: Add vfio device cdev description

This gives notes for userspace applications on device cdev usage. Reviewed-by: Kevin Tian Signed-off-by: Yi Liu --- Documentation/driver-api/vfio.rst | 139 ++ 1 file changed, 139 insertions(+) diff --git a/Documentation/driver-api/vfio.rst b/Documentation/driver-a

[Intel-gfx] [PATCH v14 23/26] vfio: Add VFIO_DEVICE_[AT|DE]TACH_IOMMUFD_PT

This adds ioctl for userspace to attach device cdev fd to and detach from IOAS/hw_pagetable managed by iommufd. VFIO_DEVICE_ATTACH_IOMMUFD_PT: attach vfio device to IOAS or hw_pagetable managed by iommufd. Attach can be undo

[Intel-gfx] [PATCH v14 24/26] vfio: Move the IOMMU_CAP_CACHE_COHERENCY check in __vfio_register_dev()

The IOMMU_CAP_CACHE_COHERENCY check only applies to the physical devices that are IOMMU-backed. But it is now in the group code. If want to compile vfio_group infrastructure out, this check needs to be moved out of the group code. Another reason for this change is to fail the device registration f

[Intel-gfx] [PATCH v14 20/26] iommufd: Add iommufd_ctx_from_fd()

It's common to get a reference to the iommufd context from a given file descriptor. So adds an API for it. Existing users of this API are compiled only when IOMMUFD is enabled, so no need to have a stub for the IOMMUFD disabled case. Signed-off-by: Yi Liu --- drivers/iommu/iommufd/main.c | 23 ++

[Intel-gfx] [PATCH v14 21/26] vfio: Avoid repeated user pointer cast in vfio_device_fops_unl_ioctl()

This adds a local variable to store the user pointer cast result from arg. It avoids the repeated casts in the code when more ioctls are added. Signed-off-by: Yi Liu --- drivers/vfio/vfio_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/vfio/vfio_main.c b/driv

[Intel-gfx] [PATCH v14 12/26] vfio: Record devid in vfio_device_file

.bind_iommufd() will generate an ID to represent this bond, which is needed by userspace for further usage. Store devid in vfio_device_file to avoid passing the pointer in multiple places. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Teste

[Intel-gfx] [PATCH v14 22/26] vfio: Add VFIO_DEVICE_BIND_IOMMUFD

This adds ioctl for userspace to bind device cdev fd to iommufd. VFIO_DEVICE_BIND_IOMMUFD: bind device to an iommufd, hence gain DMA control provided by the iommufd. open_device op is called after bind_iommufd op. Tested-by: Nicolin

[Intel-gfx] [PATCH v14 25/26] vfio: Compile vfio_group infrastructure optionally

vfio_group is not needed for vfio device cdev, so with vfio device cdev introduced, the vfio_group infrastructures can be compiled out if only cdev is needed. Reviewed-by: Jason Gunthorpe Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting Jiang Tested-by: Shameer Kolothum Te

[Intel-gfx] [PATCH v14 18/26] vfio: Add cdev for vfio_device

This allows user to directly open a vfio device w/o using the legacy container/group interface, as a prerequisite for supporting new iommu features like nested translation. The device fd opened in this manner doesn't have the capability to access the device as the fops open() doesn't open the devi

[Intel-gfx] [PATCH v14 11/26] vfio-iommufd: Split bind/attach into two steps

This aligns the bind/attach logic with the coming vfio device cdev support. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting Jiang Tested-by: Shameer Kolothum Signed-off-by: Yi Liu --- drivers/

[Intel-gfx] [PATCH v14 14/26] iommufd/device: Add iommufd_access_detach() API

From: Nicolin Chen Previously, the detach routine is only done by the destroy(). And it was called by vfio_iommufd_emulated_unbind() when the device runs close(), so all the mappings in iopt were cleaned in that setup, when the call trace reaches this detach() routine. Now, there's a need of a d

[Intel-gfx] [PATCH v14 19/26] vfio: Test kvm pointer in _vfio_device_get_kvm_safe()

This saves some lines when adding the kvm get logic for the vfio_device cdev path. This also renames _vfio_device_get_kvm_safe() to be vfio_device_get_kvm_safe(). Suggested-by: Jason Gunthorpe Signed-off-by: Yi Liu --- drivers/vfio/group.c | 7 +-- drivers/vfio/vfio.h | 6 +++---

[Intel-gfx] [PATCH v14 10/26] vfio-iommufd: Move noiommu compat validation out of vfio_iommufd_bind()

This moves the noiommu compat validation logic into vfio_df_group_open(). This is more consistent with what will be done in vfio device cdev path. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting J

[Intel-gfx] [PATCH v14 16/26] vfio: Move vfio_device_group_unregister() to be the first operation in unregister

This avoids endless vfio_device refcount increment by userspace, which would keep blocking the vfio_unregister_group_dev(). Reviewed-by: Jason Gunthorpe Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting Jiang Tested-by: Shameer Kolothum Tested-by: Terrence Xu Signed-off-by

[Intel-gfx] [PATCH v14 17/26] vfio: Move device_del() before waiting for the last vfio_device registration refcount

device_del() destroys the vfio-dev/vfioX under the sysfs for vfio_device. There is no reason to keep it while the device is going to be unregistered. This movement is also a preparation for adding vfio_device cdev. Kernel should remove the cdev node of the vfio_device to avoid new registration ref

[Intel-gfx] [PATCH v14 13/26] vfio-iommufd: Add detach_ioas support for physical VFIO devices

This prepares for adding DETACH ioctl for physical VFIO devices. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting Jiang Tested-by: Shameer Kolothum Signed-off-by: Yi Liu --- Documentation/drive

[Intel-gfx] [PATCH v14 15/26] vfio-iommufd: Add detach_ioas support for emulated VFIO devices

This prepares for adding DETACH ioctl for emulated VFIO devices. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting Jiang Tested-by: Shameer Kolothum Signed-off-by: Yi Liu --- drivers/gpu/drm/i91

[Intel-gfx] [PATCH v14 05/26] kvm/vfio: Accept vfio device file from userspace

This defines KVM_DEV_VFIO_FILE* and make alias with KVM_DEV_VFIO_GROUP*. Old userspace uses KVM_DEV_VFIO_GROUP* works as well. Reviewed-by: Jason Gunthorpe Reviewed-by: Kevin Tian Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting Jiang Tested-by: Sha

[Intel-gfx] [PATCH v14 08/26] vfio: Add cdev_device_open_cnt to vfio_group

This is for counting the devices that are opened via the cdev path. This count is increased and decreased by the cdev path. The group path checks it to achieve exclusion with the cdev path. With this, only one path (group path or cdev path) will claim DMA ownership. This avoids scenarios in which d

[Intel-gfx] [PATCH v14 09/26] vfio: Make vfio_df_open() single open for device cdev path

VFIO group has historically allowed multi-open of the device FD. This was made secure because the "open" was executed via an ioctl to the group FD which is itself only single open. However, no known use of multiple device FDs today. It is kind of a strange thing to do because new device FDs can na

[Intel-gfx] [PATCH v14 04/26] kvm/vfio: Prepare for accepting vfio device fd

This renames kvm_vfio_group related helpers to prepare for accepting vfio device fd. No functional change is intended. Reviewed-by: Kevin Tian Reviewed-by: Eric Auger Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato Tested-by: Yanting Jian

[Intel-gfx] [PATCH v14 07/26] vfio: Block device access via device fd until device is opened

Allow the vfio_device file to be in a state where the device FD is opened but the device cannot be used by userspace (i.e. its .open_device() hasn't been called). This inbetween state is not used when the device FD is spawned from the group FD, however when we create the device FD directly by openi

[Intel-gfx] [PATCH v14 06/26] vfio: Pass struct vfio_device_file * to vfio_device_open/close()

This avoids passing too much parameters in multiple functions. Per the input parameter change, rename the function to be vfio_df_open/close(). Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Reviewed-by: Eric Auger Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato

[Intel-gfx] [PATCH v14 03/26] vfio: Accept vfio device file in the KVM facing kAPI

This makes the vfio file kAPIs to accept vfio device files, also a preparation for vfio device cdev support. For the kvm set with vfio device file, kvm pointer is stored in struct vfio_device_file, and use kvm_ref_lock to protect kvm set and kvm pointer usage within VFIO. This kvm pointer will be

[Intel-gfx] [PATCH v14 02/26] vfio: Refine vfio file kAPIs for KVM

This prepares for making the below kAPIs to accept both group file and device file instead of only vfio group file. bool vfio_file_enforced_coherent(struct file *file); void vfio_file_set_kvm(struct file *file, struct kvm *kvm); Reviewed-by: Kevin Tian Reviewed-by: Eric Auger Reviewed-by: J

[Intel-gfx] [PATCH v14 01/26] vfio: Allocate per device file structure

This is preparation for adding vfio device cdev support. vfio device cdev requires: 1) A per device file memory to store the kvm pointer set by KVM. It will be propagated to vfio_device:kvm after the device cdev file is bound to an iommufd. 2) A mechanism to block device access through device

[Intel-gfx] [PATCH v14 00/26] Add vfio_device cdev for iommufd support

Existing VFIO provides group-centric user APIs for userspace. Userspace opens the /dev/vfio/$group_id first before getting device fd and hence getting access to device. This is not the desired model for iommufd. Per the conclusion of community discussion[1], iommufd provides device-centric kAPIs an

[Intel-gfx] [PATCH v9 04/10] iommufd: Add iommufd_ctx_has_group()

This adds the helper to check if any device within the given iommu_group has been bound with the iommufd_ctx. This is helpful for the checking on device ownership for the devices which have not been bound but cannot be bound to any other iommufd_ctx as the iommu_group has been bound. Tested-by: Te

[Intel-gfx] [PATCH v9 08/10] vfio/pci: Extend VFIO_DEVICE_GET_PCI_HOT_RESET_INFO for vfio device cdev

This allows VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl use the iommufd_ctx of the cdev device to check the ownership of the other affected devices. When VFIO_DEVICE_GET_PCI_HOT_RESET_INFO is called on an IOMMUFD managed device, the new flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID is reported to indicate the

[Intel-gfx] [PATCH v9 06/10] vfio: Mark cdev usage in vfio_device

This can be used to differentiate whether to report group_id or devid in the revised VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl. At this moment, no cdev path yet, so the vfio_device_cdev_opened() helper always returns false. Reviewed-by: Kevin Tian Tested-by: Terrence Xu Signed-off-by: Yi Liu ---

[Intel-gfx] [PATCH v9 07/10] vfio: Add helper to search vfio_device in a dev_set

There are drivers that need to search vfio_device within a given dev_set. e.g. vfio-pci. So add a helper. vfio_pci_is_device_in_set() now returns -EBUSY in commit a882c16a2b7e ("vfio/pci: Change vfio_pci_try_bus_reset() to use the dev_set") where it was trying to preserve the return of vfio_pci_tr

[Intel-gfx] [PATCH v9 05/10] iommufd: Add helper to retrieve iommufd_ctx and devid

This is needed by the vfio-pci driver to report affected devices in the hot-reset for a given device. Tested-by: Terrence Xu Reviewed-by: Jason Gunthorpe Signed-off-by: Yi Liu --- drivers/iommu/iommufd/device.c | 12 include/linux/iommufd.h| 3 +++ 2 files changed, 15 ins

[Intel-gfx] [PATCH v9 01/10] vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset()

This suits more on what the code does. Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Reviewed-by: Eric Auger Signed-off-by: Yi Liu --- drivers/vfio/pci/vfio_pci_core.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vf

[Intel-gfx] [PATCH v9 10/10] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

This is the way user to invoke hot-reset for the devices opened by cdev interface. User should check the flag VFIO_PCI_HOT_RESET_FLAG_DEV_ID_OWNED in the output of VFIO_DEVICE_GET_PCI_HOT_RESET_INFO ioctl before doing hot-reset for cdev devices. Suggested-by: Jason Gunthorpe Signed-off-by: Jason

[Intel-gfx] [PATCH v9 03/10] iommufd: Reserve all negative IDs in the iommufd xarray

With this reservation, IOMMUFD users can encode the negative IDs for specific purposes. e.g. VFIO needs two reserved values to tell userspace the ID returned is not valid but has other meaning. Tested-by: Terrence Xu Reviewed-by: Jason Gunthorpe Signed-off-by: Yi Liu --- drivers/iommu/iommufd/

[Intel-gfx] [PATCH v9 00/10] Enhance vfio PCI hot reset for vfio cdev device

VFIO_DEVICE_PCI_HOT_RESET requires user to pass an array of group fds to prove that it owns all devices affected by resetting the calling device. While for cdev devices, user can use an iommufd-based ownership checking model and invoke VFIO_DEVICE_PCI_HOT_RESET with a zero-length fd array. This se

[Intel-gfx] [PATCH v9 09/10] vfio/pci: Copy hot-reset device info to userspace in the devices loop

This copies the vfio_pci_dependent_device to userspace during looping each affected device for reporting vfio_pci_hot_reset_info. This avoids counting the affected devices and allocating a potential large buffer to store the vfio_pci_dependent_device of all the affected devices before copying them

[Intel-gfx] [PATCH v9 02/10] vfio/pci: Move the existing hot reset logic to be a helper

This prepares to add another method for hot reset. The major hot reset logic are moved to vfio_pci_ioctl_pci_hot_reset_groups(). No functional change is intended. Suggested-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Reviewed-by: Jason Gunthorpe Reviewed-by: Eric Auger Reviewed-by: Kev

Re: [Intel-gfx] linux-next: manual merge of the drm tree with the drm-misc-fixes tree

Hi all, On Tue, 27 Jun 2023 11:54:32 +1000 Stephen Rothwell wrote: > > Today's linux-next merge of the drm tree got a conflict in: > > include/drm/gpu_scheduler.h > > between commit: > > db8b4968a8d0 ("drm/sched: Call drm_sched_fence_set_parent() from > drm_sched_fence_scheduled()") >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow panel drrs modes to have differing sync polarities

== Series Details == Series: drm/i915: Allow panel drrs modes to have differing sync polarities URL : https://patchwork.freedesktop.org/series/120484/ State : success == Summary == CI Bug Log - changes from CI_DRM_13366 -> Patchwork_120484v1

[Intel-gfx] [preempt-rt] BUG: sleeping function called from invalid context at drivers/gpu/drm/i915/gt/uc/intel_guc.h

Hello everyone, I am a new kernel developer with the Red Hat real-time team. I am seeing two different call traces with 6.4-rt6 on my 12th Gen Intel Framework Laptop with i915 emit the same bug. Both of them occurred in the same boot. This kernel was built and tested on RHEL8. [1] occurs only on

[Intel-gfx] [PATCH] drm/i915: Allow panel drrs modes to have differing sync polarities

v2: Add Jani Nikula's change for quirk for sync polarity CC: Jani Nikula Credits-to: Jani Nikula Signed-off-by: Vidya Srinivas --- drivers/gpu/drm/i915/display/intel_display.c | 2 +- drivers/gpu/drm/i915/display/intel_panel.c | 10 ++ 2 files changed, 7 insertions(+), 5 deletions(-

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add rc_range_params for YUV420 (rev2)

== Series Details == Series: Add rc_range_params for YUV420 (rev2) URL : https://patchwork.freedesktop.org/series/120205/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13365_full -> Patchwork_120205v2_full Summary ---

[Intel-gfx] ✓ Fi.CI.IGT: success for MTL Degamma implementation (rev2)

== Series Details == Series: MTL Degamma implementation (rev2) URL : https://patchwork.freedesktop.org/series/119844/ State : success == Summary == CI Bug Log - changes from CI_DRM_13364_full -> Patchwork_119844v2_full Summary --- **

Re: [Intel-gfx] [PATCH v2] i915/display/hotplug: use drm_kms_helper_connector_hotplug_event()

It looks good to me and will be very helpful for Chrome userspace, but can we get some R-B from Intel folks so we can get this merged? Regards Manasi On Mon, Jul 10, 2023 at 12:27 AM Simon Ser wrote: > > Any news about this patch?

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read (rev2)

== Series Details == Series: drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read (rev2) URL : https://patchwork.freedesktop.org/series/120296/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13364_full -> Patchwork_120296v2_full =

Re: [Intel-gfx] [PATCH v3 RESEND] x86/mm: Fix PAT bit missing from page protection modify mask

On Mon, 2023-07-10 at 09:36 +0200, Janusz Krzysztofik wrote: > The issue needs to be fixed by including _PAGE_PAT bit into a bitmask > used > by pgprot_modify() for selecting bits to be preserved.  We can do > that > either internally to pgprot_modify() (as initially proposed), or by > making > _PA

[Intel-gfx] ✓ Fi.CI.BAT: success for Add rc_range_params for YUV420 (rev2)

== Series Details == Series: Add rc_range_params for YUV420 (rev2) URL : https://patchwork.freedesktop.org/series/120205/ State : success == Summary == CI Bug Log - changes from CI_DRM_13365 -> Patchwork_120205v2 Summary --- **SUCCES

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add rc_range_params for YUV420 (rev2)

== Series Details == Series: Add rc_range_params for YUV420 (rev2) URL : https://patchwork.freedesktop.org/series/120205/ 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:

[Intel-gfx] ✗ Fi.CI.BUILD: failure for v6.1 stable backport request

== Series Details == Series: v6.1 stable backport request URL : https://patchwork.freedesktop.org/series/120468/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/120468/revisions/1/mbox/ not applied Applying: drm/i915/tc: Fix system resume MST mode

[Intel-gfx] [PATCH v5 3/3] drm/i915/dsc: Add rc_range_parameter calculation for YCbCr420

Some rc_range_parameter calculations were missed for YCbCr420, add them to calculate_rc_param() --v2 -take into account the new formula to get bpp_i --v4 -Fix range_bpg_offset formula for YCbCr420 bpp <= 16 [Ankit] --v5 -Fix comment and mention use of DSC C Model [Ankit] Cc: Vandita Kulkarni C

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/dsc: Add rc_range_parameter calculation for YCbCr420

> > On 7/5/2023 10:45 AM, Suraj Kandpal wrote: > > Some rc_range_parameter calculations were missed for YCbCr420, add > > them to calculate_rc_param() > > > > --v2 > > -take into account the new formula to get bpp_i > > > > --v4 > > -Fix range_bpg_offset formula for YCbCr420 bpp <= 16 [Ankit] > >

[Intel-gfx] ✓ Fi.CI.BAT: success for MTL Degamma implementation (rev2)

== Series Details == Series: MTL Degamma implementation (rev2) URL : https://patchwork.freedesktop.org/series/119844/ State : success == Summary == CI Bug Log - changes from CI_DRM_13364 -> Patchwork_119844v2 Summary --- **SUCCESS**

[Intel-gfx] ✗ Fi.CI.IGT: failure for x86/mm: Fix PAT bit missing from page protection modify mask (rev4)

== Series Details == Series: x86/mm: Fix PAT bit missing from page protection modify mask (rev4) URL : https://patchwork.freedesktop.org/series/116883/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13363_full -> Patchwork_116883v4_full =

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read (rev2)

== Series Details == Series: drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read (rev2) URL : https://patchwork.freedesktop.org/series/120296/ State : success == Summary == CI Bug Log - changes from CI_DRM_13364 -> Patchwork_120296v2 ===

[Intel-gfx] [linux-next:master] BUILD REGRESSION fe57d0d86f03a8b2afe2869a95477d0ed1824c96

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: fe57d0d86f03a8b2afe2869a95477d0ed1824c96 Add linux-next specific files for 20230710 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/20230613.hher4zoo-...@intel.com https

[Intel-gfx] [PATCH 1/1] drm/i915/tc: Fix system resume MST mode restore for DP-alt sinks

commit 06f66261a1567d66b9d35c87393b6edfbea4c8f8 upstream. At least restoring the MST topology during system resume needs to use AUX before the display HW readout->sanitization sequence is complete, but on TC ports the PHY may be in the wrong mode for this, resulting in the AUX transfers to fail.

[Intel-gfx] [PATCH 0/1] v6.1 stable backport request

Stable team, please apply patch 1/1 in this patchset along with its dependencies to the v6.1 stable tree. The patch required a trivial rebase adding a header include, hence resending it, while its 2 dependencies listed at Cc: stable lines in the commit message can be cherry-picked as-is. Thanks, I

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read (rev2)

== Series Details == Series: drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read (rev2) URL : https://patchwork.freedesktop.org/series/120296/ State : warning == Summary == Error: dim checkpatch failed 417192a1727e drm/i915/pmu: Use local64_try_cmpxchg in i915_pmu_event_read -:7: WARN

Re: [Intel-gfx] [PATCH 2/2] drm/i915/color: For MTL convert 24 bit lut values to 16 bit

Hello Jani, > -Original Message- > From: Jani Nikula > Sent: Monday, June 26, 2023 5:53 PM > To: Borah, Chaitanya Kumar ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 2/2] drm/i915/color: For MTL convert 24 bit > lut > values to 16 bit > > On Mon, 26 Jun 2023, C

Re: [Intel-gfx] [PATCH 1/2] drm/i915/color: Add function to load degamma LUT in MTL

Hello Jani, > -Original Message- > From: Jani Nikula > Sent: Monday, June 26, 2023 5:52 PM > To: Borah, Chaitanya Kumar ; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 1/2] drm/i915/color: Add function to load > degamma LUT in MTL > > On Mon, 26 Jun 2023, Chaitany

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Replace acronym with full platform name in defines. (rev3)

== Series Details == Series: Replace acronym with full platform name in defines. (rev3) URL : https://patchwork.freedesktop.org/series/119380/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/119380/revisions/3/mbox/ not applied Applying: drm/i915/m

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add DSC PPS readout

== Series Details == Series: Add DSC PPS readout URL : https://patchwork.freedesktop.org/series/120456/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/120456/revisions/1/mbox/ not applied Applying: drm/i915/dsc: Add PPS enum Applying: drm/i915/vds

Re: [Intel-gfx] [v3] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform defines

> -Original Message- > From: Bhadane, Dnyaneshwar > Sent: Monday, July 10, 2023 4:28 PM > To: intel-gfx@lists.freedesktop.org > Cc: Ursulin, Tvrtko ; jani.nik...@linux.intel.com; > Srivatsa, Anusha ; Bhadane, Dnyaneshwar > > Subject: [v3] drm/i915/mtl: s/MTL/METEORLAKE for platform/sub

[Intel-gfx] [PATCH v2 2/2] drm/i915/color: Downscale degamma lut values read from hardware

For MTL and beyond, convert back the 24 bit lut values read from HW to 16 bit values to maintain parity with userspace values. This way we avoid pipe config mismatch for pre-csc lut values. v2: Add helper function to downscale values (Jani) Signed-off-by: Chaitanya Kumar Borah --- drivers/gpu/d

[Intel-gfx] [PATCH v2 1/2] drm/i915/color: Upscale degamma values for MTL

MTL onwards Degamma LUT/PRE-CSC LUT precision has been increased from 16 bits to 24 bits. Currently, drm framework only supports LUTs up to 16 bit precision. Until a new uapi comes along to support higher bitdepth, upscale the values sent from userland to 24 bit before writing into the HW to contin

[Intel-gfx] [PATCH 0/2] MTL Degamma implementation

MTL onwards Degamma LUT/PRE-CSC LUT precision has been increased from 16 bits to 24 bits. Currently, drm framework only supports LUTs up to 16 bit precision. Until a new uapi comes along to support higher bitdepth, upscale the values sent from userland to 24 bit before writing into the HW to contin

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add ability for tracking buffer objects per client

On 10/07/2023 11:44, Iddamsetty, Aravind wrote: On 07-07-2023 18:32, Tvrtko Ursulin wrote: From: Tvrtko Ursulin In order to show per client memory usage lets add some infrastructure which enables tracking buffer objects owned by clients. We add a per client list protected by a new per clien

Re: [Intel-gfx] [PATCH 18/19] drm: Add acquire ctx parameter to ->set_config

從我的iPhone傳送

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: update request engine before removing virtual GuC engine (rev2)

On 07.07.2023 04:52, Patchwork wrote: Project List - Patchwork *Patch Details* *Series:* drm/i915/gt: update request engine before removing virtual GuC engine (rev2) *URL:* https://patchwork.freedesktop.org/series/120238/ *State:*failure *Details:* https://intel-gfx-ci.01.org/tree/

[Intel-gfx] ✓ Fi.CI.BAT: success for x86/mm: Fix PAT bit missing from page protection modify mask (rev4)

== Series Details == Series: x86/mm: Fix PAT bit missing from page protection modify mask (rev4) URL : https://patchwork.freedesktop.org/series/116883/ State : success == Summary == CI Bug Log - changes from CI_DRM_13363 -> Patchwork_116883v4 ===

Re: [Intel-gfx] [PATCH v4 3/3] drm/i915/dsc: Add rc_range_parameter calculation for YCbCr420

On 7/5/2023 10:45 AM, Suraj Kandpal wrote: Some rc_range_parameter calculations were missed for YCbCr420, add them to calculate_rc_param() --v2 -take into account the new formula to get bpp_i --v4 -Fix range_bpg_offset formula for YCbCr420 bpp <= 16 [Ankit] Cc: Vandita Kulkarni Cc: Ankit Naut

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for x86/mm: Fix PAT bit missing from page protection modify mask (rev4)

== Series Details == Series: x86/mm: Fix PAT bit missing from page protection modify mask (rev4) URL : https://patchwork.freedesktop.org/series/116883/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

Re: [Intel-gfx] [PATCH 5/5] drm/i915/display: Compare the readout dsc pps params

On Mon, 10 Jul 2023, Suraj Kandpal wrote: > With the dsc config being readout and filled in crtc_state add > macros and use them to compare current and previous PPS param in > DSC. > > Signed-off-by: Suraj Kandpal > --- > drivers/gpu/drm/i915/display/intel_display.c | 55 >

Re: [Intel-gfx] [PATCH 4/5] drm/i915/vdsc: Fill the intel_dsc_get_pps_config function

On Mon, 10 Jul 2023, Suraj Kandpal wrote: > We have setup both the read and write functions so we can > move ahead and fill in all the readout state from PPS register > into the crtc_state so we can send it for comparision. > > Signed-off-by: Suraj Kandpal > --- > drivers/gpu/drm/i915/display/in

[Intel-gfx] [v3] drm/i915/mtl: s/MTL/METEORLAKE for platform/subplatform defines

Follow consistent naming convention. Replace MTL with METEORLAKE. Added defines that are replacing IS_MTL_GRAPHICS_STEP with IS_METEORLAKE_P_GRAPHICS_STEP and IS_METEORLAKE_M_GRAPHICS_STEP. Also replaced IS_METEORLAKE_MEDIA_STEP instead of IS_MTL_MEDIA_STEP and IS_METEORLAKE_DISPLAY_STEP instead of

Re: [Intel-gfx] [PATCH 3/5] drm/i915/vdsc: Add function to write in PPS registers

On Mon, 10 Jul 2023, Suraj Kandpal wrote: > Now that we have a function that reads any PPS register based > on intel_dsc_pps enum provided lets create a function that can > write on any PPS. > > Signed-off-by: Suraj Kandpal > --- > drivers/gpu/drm/i915/display/intel_vdsc.c | 494 +++-

Re: [Intel-gfx] [PATCH 2/5] drm/i915/vdsc: Add function to read any PPS register

On Mon, 10 Jul 2023, Jani Nikula wrote: > On Mon, 10 Jul 2023, Suraj Kandpal wrote: >> Add function to read any PPS register based on the >> intel_dsc_pps enum provided. Add a function which will call the >> new pps read function and place it in crtc state. Only PPS0 and >> PPS1 are readout the r

Re: [Intel-gfx] [PATCH 2/5] drm/i915/vdsc: Add function to read any PPS register

On Mon, 10 Jul 2023, Suraj Kandpal wrote: > Add function to read any PPS register based on the > intel_dsc_pps enum provided. Add a function which will call the > new pps read function and place it in crtc state. Only PPS0 and > PPS1 are readout the rest of the registers will be read in upcoming >

Re: [Intel-gfx] [PATCH 1/5] drm/i915/dsc: Add PPS enum

On Mon, 10 Jul 2023, Jani Nikula wrote: > On Mon, 10 Jul 2023, Suraj Kandpal wrote: >> Add PPS enum so that we can later on use it to distinguish which >> PPS is being read or written onto. > > The patch adding the enum alone isn't useful, should be squashed with > something that uses it. Also,

Re: [Intel-gfx] [PATCH 1/5] drm/i915/dsc: Add PPS enum

On Mon, 10 Jul 2023, Suraj Kandpal wrote: > Add PPS enum so that we can later on use it to distinguish which > PPS is being read or written onto. The patch adding the enum alone isn't useful, should be squashed with something that uses it. BR, Jani. > > Signed-off-by: Suraj Kandpal > --- > dr

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Add ability for tracking buffer objects per client

On 07-07-2023 18:32, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > In order to show per client memory usage lets add some infrastructure > which enables tracking buffer objects owned by clients. > > We add a per client list protected by a new per client lock and to support > delayed destru

Re: [Intel-gfx] [PATCH v3] drm/i915: Avoid circular locking dependency when flush delayed work on gt reset

Hi, On Thu, Jun 15, 2023 at 02:15:42PM -0700, Zhanjun Dong wrote: > This attempts to avoid circular locking dependency between flush delayed work > and intel_gt_reset. > Switched from cancel_delayed_work_sync to cancel_delayed_work, the non-sync > version for reset path, it is safe as the worker

[Intel-gfx] [PATCH 5/5] drm/i915/display: Compare the readout dsc pps params

With the dsc config being readout and filled in crtc_state add macros and use them to compare current and previous PPS param in DSC. Signed-off-by: Suraj Kandpal --- drivers/gpu/drm/i915/display/intel_display.c | 55 1 file changed, 55 insertions(+) diff --git a/drivers/gpu

[Intel-gfx] [PATCH 4/5] drm/i915/vdsc: Fill the intel_dsc_get_pps_config function

We have setup both the read and write functions so we can move ahead and fill in all the readout state from PPS register into the crtc_state so we can send it for comparision. Signed-off-by: Suraj Kandpal --- drivers/gpu/drm/i915/display/intel_vdsc.c | 152 +++--- .../gpu/drm/i91

[Intel-gfx] [PATCH 3/5] drm/i915/vdsc: Add function to write in PPS registers

Now that we have a function that reads any PPS register based on intel_dsc_pps enum provided lets create a function that can write on any PPS. Signed-off-by: Suraj Kandpal --- drivers/gpu/drm/i915/display/intel_vdsc.c | 494 +++--- 1 file changed, 252 insertions(+), 242 deletions

[Intel-gfx] [PATCH 2/5] drm/i915/vdsc: Add function to read any PPS register

Add function to read any PPS register based on the intel_dsc_pps enum provided. Add a function which will call the new pps read function and place it in crtc state. Only PPS0 and PPS1 are readout the rest of the registers will be read in upcoming patches. Signed-off-by: Suraj Kandpal --- drivers

[Intel-gfx] [PATCH 1/5] drm/i915/dsc: Add PPS enum

Add PPS enum so that we can later on use it to distinguish which PPS is being read or written onto. Signed-off-by: Suraj Kandpal --- drivers/gpu/drm/i915/display/intel_vdsc.c | 17 + 1 file changed, 17 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_vdsc.c b/drive

[Intel-gfx] [PATCH 0/5] Add DSC PPS readout

Up until now we only verified one or two of the dsc pps params like bits_per_component and bits_per_pixel this patch series aim to readout almost all PPS param and get them compared. Along with that some work on making a common function to read and write PPS param regiters is also done. Signed-off

Re: [Intel-gfx] [PATCH] drm/i915: Remove dead code from gen8_pte_encode

Hi Tvrtko, > Commit 9275277d5324 ("drm/i915: use pat_index instead of cache_level") > added a dedicated gen12_pte_encode but forgot to remove the Gen12 specific > bit from gen8_pte_encode. > > Signed-off-by: Tvrtko Ursulin > Fixes: 9275277d5324 ("drm/i915: use pat_index instead of cache_level")

  1   2   >