Re: [Intel-gfx] [PATCH 2/2] drm/i915/mtl: Disable MC6 for MTL A step

On Wed, Mar 08, 2023 at 03:51:09PM +0530, Badal Nilawar wrote: > The Wa_14017073508 require to send Media Busy/Idle mailbox while > accessing Media tile. As of now it is getting handled while __gt_unpark, > __gt_park. But there are various corner cases where forcewakes are taken > without __gt_unpa

[Intel-gfx] [PATCH v6 21/24] 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.

[Intel-gfx] [PATCH v6 13/24] vfio/iommufd: Split the compat_ioas attach out from vfio_iommufd_bind()

This makes the group code call .bind_iommufd and .attach_ioas in two steps instead of in a single step. This prepares the bind_iommufd and attach_ioas support in the coming cdev path. Signed-off-by: Yi Liu --- drivers/vfio/group.c | 26 ++- drivers/vfio/iommufd.c | 75 +

[Intel-gfx] [PATCH v6 11/24] vfio/pci: Accept device fd in VFIO_DEVICE_PCI_HOT_RESET ioctl

VFIO PCI device hot reset requires user to provide a set of FDs to prove ownership on the affected devices in the hot reset. Either group fd or device fd can be used. But when user uses vfio device cdev, there is only device fd, hence VFIO_DEVICE_PCI_HOT_RESET needs to be extended to accept device

[Intel-gfx] [PATCH v6 20/24] 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 v6 23/24] vfio: Compile group optionally

group code is not needed for vfio device cdev, so with vfio device cdev introduced, the group infrastructures can be compiled out if only cdev is needed. Signed-off-by: Yi Liu --- drivers/vfio/Kconfig | 16 +++- drivers/vfio/Makefile | 2 +- drivers/vfio/vfio.h | 94 +

[Intel-gfx] [PATCH v6 22/24] 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, hw_pagetable managed by iommufd. Attach can be undo b

[Intel-gfx] [PATCH v6 17/24] vfio-iommufd: Make vfio_iommufd_bind() selectively return devid

bind_iommufd() will generate an ID to represent this bond, it is needed by userspace for further usage. devid is stored in vfio_device_file to avoid passing devid pointer in multiple places. Signed-off-by: Yi Liu --- drivers/vfio/iommufd.c | 13 ++--- drivers/vfio/vfio.h | 6

[Intel-gfx] [PATCH v6 18/24] vfio-iommufd: Add detach_ioas support for physical VFIO devices

this prepares for adding DETACH ioctl for physical VFIO devices. Signed-off-by: Yi Liu Reviewed-by: Kevin Tian Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato --- Documentation/driver-api/vfio.rst | 8 +--- drivers/vfio/fsl-mc/vfio_fsl_mc.c

[Intel-gfx] [PATCH v6 15/24] vfio: Make vfio_device_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 v6 19/24] vfio-iommufd: Add detach_ioas support for emulated VFIO devices

this prepares for adding DETACH ioctl for emulated VFIO devices. Signed-off-by: Yi Liu Reviewed-by: Kevin Tian Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato --- drivers/gpu/drm/i915/gvt/kvmgt.c | 1 + drivers/s390/cio/vfio_ccw_ops.c | 1 + drivers/s390/crypto/

[Intel-gfx] [PATCH v6 16/24] vfio: Make vfio_device_first_open() to cover the noiommu mode in cdev path

vfio_device_first_open() now covers the below two cases: 1) user uses iommufd (e.g. the group path in iommufd compat mode); 2) user uses container (e.g. the group path in legacy mode); The above two paths have their own noiommu mode support accordingly. The cdev path also uses iommufd, so for th

[Intel-gfx] [PATCH v6 14/24] vfio: Add cdev_device_open_cnt to vfio_group

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

[Intel-gfx] [PATCH v6 12/24] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

This is another method to issue PCI hot reset for the users that bounds device to a positive iommufd value. In such case, iommufd is a proof of device ownership. By passing a zero-length fd array, user indicates kernel to do ownership check with the bound iommufd. All the opened devices within the

[Intel-gfx] [PATCH v6 09/24] vfio/pci: Only need to check opened devices in the dev_set for hot reset

If the affected device is not opened by any user, it is not necessary to check its ownership as it will not be opened by any user if a user is hot resetting a device within this dev_set. Signed-off-by: Yi Liu --- drivers/vfio/pci/vfio_pci_core.c | 17 +++-- include/uapi/linux/vfio.h

[Intel-gfx] [PATCH v6 10/24] vfio/pci: Rename the helpers and data in hot reset path to accept device fd

No function change is intended, just to make the helpers and structures to be prepared to accept device fds as proof of device ownership. Signed-off-by: Yi Liu --- drivers/vfio/pci/vfio_pci_core.c | 40 1 file changed, 20 insertions(+), 20 deletions(-) diff --gi

[Intel-gfx] [PATCH v6 08/24] vfio/pci: Update comment around group_fd get in vfio_pci_ioctl_pci_hot_reset()

this suits more on what the code does. Signed-off-by: Yi Liu Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe --- 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/vfio/pci/vfio_pci_core.c in

[Intel-gfx] [PATCH v6 05/24] 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. Signed-off-by: Yi Liu Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato --- Documentation/virt/kvm/devices/vfio.r

[Intel-gfx] [PATCH v6 07/24] 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 v6 06/24] vfio: Pass struct vfio_device_file * to vfio_device_open/close()

This avoids passing too much parameters in multiple functions. Signed-off-by: Yi Liu Reviewed-by: Kevin Tian Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato --- drivers/vfio/group.c | 19 +-- drivers/vfio/vfio.h

[Intel-gfx] [PATCH v6 04/24] kvm/vfio: Rename kvm_vfio_group to prepare for accepting vfio device fd

Meanwhile, rename related helpers. No functional change is intended. Signed-off-by: Yi Liu Reviewed-by: Kevin Tian Reviewed-by: Eric Auger Reviewed-by: Jason Gunthorpe Tested-by: Terrence Xu Tested-by: Nicolin Chen Tested-by: Matthew Rosato --- virt/kvm/vfio.c | 115 +++

[Intel-gfx] [PATCH v6 02/24] 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); Besides the above change, vfio_file_is_valid() is added to check

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

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

[Intel-gfx] [PATCH v6 00/24] cover-letter: 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 v6 01/24] 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

Re: [Intel-gfx] [PULL] drm-intel-next

On Tue, Mar 07, 2023 at 05:00:01PM -0500, Rodrigo Vivi wrote: > Hi Dave and Daniel, > > Here goes our first pull request towards 6.3. You know, I meant 6.4. :) Thank you Joonas for noticing that. > > drm-intel-next-2023-03-07: > > Cross-subsystem Changes: > - MEI patches to fix suspend/resume

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Ensure DSC has enough BW and stays within HW limits (rev3)

== Series Details == Series: drm/i915: Ensure DSC has enough BW and stays within HW limits (rev3) URL : https://patchwork.freedesktop.org/series/114679/ State : success == Summary == CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114679v3 ==

Re: [Intel-gfx] [PATCH v2 06/10] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

On Wed, 08 Mar 2023, Dmitry Baryshkov wrote: > On Wed, 8 Mar 2023 at 12:14, Jani Nikula wrote: >> >> On Tue, 07 Mar 2023, Dmitry Baryshkov wrote: >> > The array of rc_parameters contains a mixture of parameters from DSC 1.1 >> > and DSC 1.2 standards. Split these tow configuration arrays in >> >

Re: [Intel-gfx] [PATCH] drm/i915/gt: prevent forcewake releases during BAR resize

On Wed, Mar 08, 2023 at 12:23:49PM +0100, Andrzej Hajda wrote: > Tests on DG2 machines show that releasing forcewakes during BAR resize > results later in forcewake ack timeouts. Since forcewakes can be realeased > asynchronously the simplest way to prevent it is to get all forcewakes > for duratio

[Intel-gfx] [PATCH v1 4/5] Samples/mdev: Uses the vfio emulated iommufd ops set in the mdev sample drivers

This harmonizes the no-DMA devices (the vfio-mdev sample drivers) with the emulated devices (gvt-g, vfio-ap etc.). It makes it easier to add BIND_IOMMUFD user interface which requires to return an iommufd ID to represent the device/iommufd bond. Signed-off-by: Yi Liu --- drivers/vfio/iommufd.c

[Intel-gfx] [PATCH v1 5/5] vfio: Check the presence for iommufd callbacks in __vfio_register_dev()

After making the no-DMA drivers (samples/vfio-mdev) providing iommufd callbacks, __vfio_register_dev() should check the presence of the iommufd callbacks if CONFIG_IOMMUFD is enabled. Signed-off-by: Yi Liu --- drivers/vfio/vfio_main.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) d

[Intel-gfx] [PATCH v1 3/5] vfio-iommufd: Make vfio_iommufd_emulated_bind() return iommufd_access ID

vfio device cdev needs to return iommufd_access ID to userspace if bind_iommufd succeeds. Signed-off-by: Yi Liu --- drivers/iommu/iommufd/device.c | 4 +++- drivers/iommu/iommufd/selftest.c | 3 ++- drivers/vfio/iommufd.c | 2 +- include/linux/iommufd.h | 2 +- 4 files chang

[Intel-gfx] [PATCH v1 2/5] vfio-iommufd: No need to record iommufd_ctx in vfio_device

iommufd_ctx is stored in vfio_device for emulated devices per bind_iommufd. However, as iommufd_access is created in bind, no more need to stored it since iommufd_access implicitly stores it. Signed-off-by: Yi Liu --- drivers/vfio/iommufd.c | 10 +- include/linux/vfio.h | 1 - 2 files

[Intel-gfx] [PATCH v1 0/5] vfio: Make emulated devices prepared for vfio device cdev

The .bind_iommufd op of vfio emulated devices are either empty or does nothing. This is different with the vfio physical devices, to add vfio device cdev, need to make them act the same. This series first makes the .bind_iommufd op of vfio emulated devices to create iommufd_access, this introduces

[Intel-gfx] [PATCH v1 1/5] iommufd: Create access in vfio_iommufd_emulated_bind()

From: Nicolin Chen There are needs to created iommufd_access prior to have an IOAS and set IOAS later. Like the vfio device cdev needs to have an iommufd object to represent the bond (iommufd_access) and IOAS replacement. This moves iommufd_access_create() call into vfio_iommufd_emulated_bind(),

Re: [Intel-gfx] [PATCH v2 06/10] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

On Wed, 8 Mar 2023 at 12:14, Jani Nikula wrote: > > On Tue, 07 Mar 2023, Dmitry Baryshkov wrote: > > The array of rc_parameters contains a mixture of parameters from DSC 1.1 > > and DSC 1.2 standards. Split these tow configuration arrays in > > preparation to adding more configuration data. > > >

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Ensure DSC has enough BW and stays within HW limits (rev3)

== Series Details == Series: drm/i915: Ensure DSC has enough BW and stays within HW limits (rev3) URL : https://patchwork.freedesktop.org/series/114679/ State : warning == Summary == Error: dim checkpatch failed 702a04c13be5 drm/i915: Ensure DSC has enough BW and stays within HW limits -:16: W

Re: [Intel-gfx] [Intel-xe] [PATCH] drm/xe/display: Do not use i915 frontbuffer tracking implementation

On 2023-03-06 21:58, Ville Syrjälä wrote: On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote: Hey, On 2023-03-06 16:23, Souza, Jose wrote: On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote: As a fallback if we decide not to merge the frontbuffer tracking, allow i915

Re: [Intel-gfx] [PATCH 0/7] Enable YCbCr420 format for VDSC

On Wed, 08 Mar 2023, Dmitry Baryshkov wrote: > On 08/03/2023 13:30, Jani Nikula wrote: >> On Wed, 22 Feb 2023, Suraj Kandpal wrote: >>> This patch series aims to enable the YCbCr420 format >>> for DSC. Changes are mostly compute params related for >>> hdmi,dp and dsi along with the addition of ne

Re: [Intel-gfx] [PATCH 0/7] Enable YCbCr420 format for VDSC

On 08/03/2023 13:30, Jani Nikula wrote: On Wed, 22 Feb 2023, Suraj Kandpal wrote: This patch series aims to enable the YCbCr420 format for DSC. Changes are mostly compute params related for hdmi,dp and dsi along with the addition of new rc_tables for native_420 and corresponding changes to macr

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Adding the new registers for DSC

> -Original Message- > From: Jani Nikula > Sent: Wednesday, March 8, 2023 4:57 PM > To: Shankar, Uma ; Kandpal, Suraj > ; dri-de...@lists.freedesktop.org; intel- > g...@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCH 3/7] drm/i915: Adding the new registers for > DSC > > On Wed

Re: [Intel-gfx] [PATCH 0/7] Enable YCbCr420 format for VDSC

On Wed, 22 Feb 2023, Suraj Kandpal wrote: > This patch series aims to enable the YCbCr420 format > for DSC. Changes are mostly compute params related for > hdmi,dp and dsi along with the addition of new rc_tables > for native_420 and corresponding changes to macros used to > fetch them. > There ha

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Adding the new registers for DSC

On Wed, 08 Mar 2023, "Shankar, Uma" wrote: >> -Original Message- >> From: Kandpal, Suraj >> Sent: Wednesday, February 22, 2023 11:02 AM >> To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org >> Cc: Shankar, Uma ; Nautiyal, Ankit K >> ; Kandpal, Suraj ; >> Kulkarni, >> Va

[Intel-gfx] [PATCH] drm/i915/gt: prevent forcewake releases during BAR resize

Tests on DG2 machines show that releasing forcewakes during BAR resize results later in forcewake ack timeouts. Since forcewakes can be realeased asynchronously the simplest way to prevent it is to get all forcewakes for duration of BAR resizing. Signed-off-by: Andrzej Hajda --- drivers/gpu/drm/

Re: [Intel-gfx] [PATCH 6/7] drm/i915/vdsc: Check slice design requirement

> -Original Message- > From: Kandpal, Suraj > Sent: Wednesday, February 22, 2023 11:02 AM > To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > Cc: Shankar, Uma ; Nautiyal, Ankit K > ; Kandpal, Suraj > Subject: [PATCH 6/7] drm/i915/vdsc: Check slice design requiremen

[Intel-gfx] ✗ Fi.CI.BAT: failure for Fix error propagation amongst request (rev2)

== Series Details == Series: Fix error propagation amongst request (rev2) URL : https://patchwork.freedesktop.org/series/114451/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114451v2 Summary --- *

Re: [Intel-gfx] [PATCH v2 5/7] drm/i915/display: Fill in native_420 field

> -Original Message- > From: Kandpal, Suraj > Sent: Friday, March 3, 2023 11:05 AM > To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > Cc: Shankar, Uma ; Nautiyal, Ankit K > ; Kandpal, Suraj ; Jani > Nikula > > Subject: [PATCH v2 5/7] drm/i915/display: Fill in nat

Re: [Intel-gfx] [PATCH 1/2] Revert "drm/i915/mtl: Add Wa_14017073508 for SAMedia"

On Wed, 08 Mar 2023, Badal Nilawar wrote: > This reverts commit 8f70f1ec587da0b0d52d768fd8c3defbc5e5b55c. Reverts need a commit message too. The why. The cover letter is not recorded in git history. BR, Jani. > Signed-off-by: Badal Nilawar > --- > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 2

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Enable YCbCr420 for VDSC

> -Original Message- > From: Kandpal, Suraj > Sent: Wednesday, February 22, 2023 11:02 AM > To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > Cc: Shankar, Uma ; Nautiyal, Ankit K > ; Kandpal, Suraj ; > Kulkarni, > Vandita > Subject: [PATCH 4/7] drm/i915: Enable YC

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Adding the new registers for DSC

> -Original Message- > From: Kandpal, Suraj > Sent: Wednesday, February 22, 2023 11:02 AM > To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > Cc: Shankar, Uma ; Nautiyal, Ankit K > ; Kandpal, Suraj ; > Kulkarni, > Vandita > Subject: [PATCH 3/7] drm/i915: Adding th

Re: [Intel-gfx] [PATCH 2/7] drm/i915/dp: Check if DSC supports the given output_format

> -Original Message- > From: Kandpal, Suraj > Sent: Wednesday, February 22, 2023 11:02 AM > To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > Cc: Shankar, Uma ; Nautiyal, Ankit K > > Subject: [PATCH 2/7] drm/i915/dp: Check if DSC supports the given > output_format

Re: [Intel-gfx] [PATCH 2/2] drm/i915/pmu: Use correct requested freq for SLPC

On 08/03/2023 05:36, Dixit, Ashutosh wrote: On Mon, 06 Mar 2023 03:10:24 -0800, Tvrtko Ursulin wrote: Hi Tvrtko, On 04/03/2023 01:27, Ashutosh Dixit wrote: SLPC does not use 'struct intel_rps'. Use UNSLICE_RATIO bits from Would it be more accurate to say 'SLPC does not use rps->cur_fre

Re: [Intel-gfx] [PATCH 1/7] drm/dp_helper: Add helper to check DSC support with given o/p format

> -Original Message- > From: Kandpal, Suraj > Sent: Wednesday, February 22, 2023 11:02 AM > To: dri-de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org > Cc: Shankar, Uma ; Nautiyal, Ankit K > > Subject: [PATCH 1/7] drm/dp_helper: Add helper to check DSC support with given > o

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Use only freq bits for falling back to requested freq

On 08/03/2023 05:36, Dixit, Ashutosh wrote: On Mon, 06 Mar 2023 03:04:40 -0800, Tvrtko Ursulin wrote: Hi Tvrtko, On 04/03/2023 01:27, Ashutosh Dixit wrote: On newer generations, the GEN12_RPSTAT1 register contains more than freq information, e.g. see GEN12_VOLTAGE_MASK. Therefore use onl

[Intel-gfx] [PATCH 2/2] drm/i915/mtl: Disable MC6 for MTL A step

The Wa_14017073508 require to send Media Busy/Idle mailbox while accessing Media tile. As of now it is getting handled while __gt_unpark, __gt_park. But there are various corner cases where forcewakes are taken without __gt_unpark i.e. without sending Busy Mailbox especially during register reads.

[Intel-gfx] [PATCH 1/2] Revert "drm/i915/mtl: Add Wa_14017073508 for SAMedia"

This reverts commit 8f70f1ec587da0b0d52d768fd8c3defbc5e5b55c. Signed-off-by: Badal Nilawar --- drivers/gpu/drm/i915/gt/intel_gt_pm.c | 27 --- drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c | 13 +-- drivers/gpu/drm/i915/i915_reg.h | 9 3 files chan

[Intel-gfx] [PATCH 0/2] drm/i915/mtl: Disable MC6 for MTL A step

Disabling MC6 for A step as it is not feasible to extend Wa_14017073508 in forcewake path to cover all corner cases. Reverting the commit 8f70f1ec587da. Badal Nilawar (2): Revert "drm/i915/mtl: Add Wa_14017073508 for SAMedia" drm/i915/mtl: Disable MC6 for MTL A step drivers/gpu/drm/i915/g

Re: [Intel-gfx] [PATCH v2 06/10] drm/display/dsc: split DSC 1.2 and DSC 1.1 (pre-SCR) parameters

On Tue, 07 Mar 2023, Dmitry Baryshkov wrote: > The array of rc_parameters contains a mixture of parameters from DSC 1.1 > and DSC 1.2 standards. Split these tow configuration arrays in > preparation to adding more configuration data. > > Signed-off-by: Dmitry Baryshkov > --- > drivers/gpu/drm/di

[Intel-gfx] [PATCH v4 5/5] drm/i915/gt: Make sure that errors are propagated through request chains

Currently, when we perform operations such as clearing or copying large blocks of memory, we generate multiple requests that are executed in a chain. However, if one of these requests fails, we may not realize it unless it happens to be the last request in the chain. This is because errors are not

[Intel-gfx] [PATCH v4 4/5] drm/i915: Create the locked version of the request add

i915_request_add() assumes that the timeline is locked whtn the function is called. Before exiting it releases the lock. But in the next commit we have one case where releasing the timeline mutex is not necessary and we don't want that. Make a new i915_request_add_locked() version of the function

[Intel-gfx] [PATCH v4 3/5] drm/i915: Create the locked version of the request create

Make version of the request creation that doesn't hold any lock. Signed-off-by: Andi Shyti Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/i915_request.c | 43 +++-- drivers/gpu/drm/i915/i915_request.h | 2 ++ 2 files changed, 31 insertions(+), 14 deletions(-) diff

[Intel-gfx] [PATCH v4 2/5] drm/i915/gt: Add intel_context_timeline_is_locked helper

We have: - intel_context_timeline_lock() - intel_context_timeline_unlock() In the next patches we will also need: - intel_context_timeline_is_locked() Add it. Signed-off-by: Andi Shyti Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/gt/intel_context.h | 6 ++ 1 file changed, 6 ins

[Intel-gfx] [PATCH v4 1/5] drm/i915: Throttle for ringspace prior to taking the timeline mutex

From: Chris Wilson Before taking exclusive ownership of the ring for emitting the request, wait for space in the ring to become available. This allows others to take the timeline->mutex to make forward progresses while userspace is blocked. In particular, this allows regular clients to issue req

[Intel-gfx] [PATCH v4 0/5] Fix error propagation amongst request

Hi, This series of two patches fixes the issue introduced in cf586021642d80 ("drm/i915/gt: Pipelined page migration") where, as reported by Matt, in a chain of requests an error is reported only if happens in the last request. However Chris noticed that without ensuring exclusivity in the locking

Re: [Intel-gfx] [PATCH v2 6/7] drm/ttm: Reduce the number of used allocation orders for TTM pages

On 3/8/23 10:15, Christian König wrote: Am 07.03.23 um 15:46 schrieb Thomas Hellström: When swapping out, we will split multi-order pages both in order to move them to the swap-cache and to be able to return memory to the swap cache as soon as possible on a page-by-page basis. Reduce the page

Re: [Intel-gfx] [PATCH v2 6/7] drm/ttm: Reduce the number of used allocation orders for TTM pages

Am 07.03.23 um 15:46 schrieb Thomas Hellström: When swapping out, we will split multi-order pages both in order to move them to the swap-cache and to be able to return memory to the swap cache as soon as possible on a page-by-page basis. Reduce the page max order to the system PMD size, as we can

Re: [Intel-gfx] [PATCH v2 2/7] drm/ttm/pool: Fix ttm_pool_alloc error path

On 3/8/23 09:48, Christian König wrote: Am 07.03.23 um 15:46 schrieb Thomas Hellström: When hitting an error, the error path forgot to unmap dma mappings and could call set_pages_wb() on already uncached pages. Fix this by introducing a common __ttm_pool_free() function that does the right th

Re: [Intel-gfx] [PATCH v2 5/7] drm/ttm: Don't print error message if eviction was interrupted

Am 07.03.23 um 15:46 schrieb Thomas Hellström: Avoid printing an error message if eviction was interrupted by, for example, the user pressing CTRL-C. That may happen if eviction is waiting for something, like for example a free batch-buffer. Signed-off-by: Thomas Hellström Reviewed-by: Christ

Re: [Intel-gfx] [PATCH v2 4/7] drm/ttm: Unexport ttm_global_swapout()

Am 07.03.23 um 15:46 schrieb Thomas Hellström: Unexport ttm_global_swapout() since it is not used outside of TTM. Signed-off-by: Thomas Hellström Reviewed-by: Christian König --- drivers/gpu/drm/ttm/ttm_device.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/ttm/ttm_

Re: [Intel-gfx] [PATCH v2 3/7] drm/ttm: Use the BIT macro for the TTM_TT_FLAGs

Am 07.03.23 um 15:46 schrieb Thomas Hellström: New code is recommended to use the BIT macro instead of the explicit shifts. Change the older defines so that we can keep the style consistent with upcoming changes. v2: - Also change the value of the _PRIV_POPULATED bit (Christian König) Signed-of

Re: [Intel-gfx] [PATCH v2 2/7] drm/ttm/pool: Fix ttm_pool_alloc error path

Am 07.03.23 um 15:46 schrieb Thomas Hellström: When hitting an error, the error path forgot to unmap dma mappings and could call set_pages_wb() on already uncached pages. Fix this by introducing a common __ttm_pool_free() function that does the right thing. v2: - Simplify __ttm_pool_free() (Chr

Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

> From: Tian, Kevin > Sent: Wednesday, March 8, 2023 4:14 PM > > > From: Liu, Yi L > > Sent: Wednesday, March 8, 2023 4:01 PM > > > > > From: Tian, Kevin > > > Sent: Wednesday, March 8, 2023 3:55 PM > > > > > > > From: Liu, Yi L > > > > Sent: Wednesday, March 8, 2023 3:47 PM > > > > > > > > >

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: Wednesday, March 8, 2023 4:01 PM > > > From: Tian, Kevin > > Sent: Wednesday, March 8, 2023 3:55 PM > > > > > From: Liu, Yi L > > > Sent: Wednesday, March 8, 2023 3:47 PM > > > > > > > From: Tian, Kevin > > > > Sent: Wednesday, March 8, 2023 3:26 PM > > > > > > > > >

Re: [Intel-gfx] [PATCH v5 09/19] vfio/pci: Allow passing zero-length fd array in VFIO_DEVICE_PCI_HOT_RESET

> From: Tian, Kevin > Sent: Wednesday, March 8, 2023 3:55 PM > > > From: Liu, Yi L > > Sent: Wednesday, March 8, 2023 3:47 PM > > > > > From: Tian, Kevin > > > Sent: Wednesday, March 8, 2023 3:26 PM > > > > > > > From: Liu, Yi L > > > > Sent: Tuesday, March 7, 2023 9:29 PM > > > > > > > > > >

<    1   2