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

On 3/8/2023 10:41 AM, Andi Shyti wrote: 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

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

On 3/8/2023 10:41 AM, Andi Shyti wrote: Make version of the request creation that doesn't hold any lock. Signed-off-by: Andi Shyti Cc: sta...@vger.kernel.org Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/i915_request.c | 43 +++-- drivers/gpu/drm/i915/i915_r

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

On 3/8/2023 10:41 AM, Andi Shyti wrote: 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 Reviewed-by: Nirmoy Das -

Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO

Hi Alex, > From: Alex Williamson > Sent: Friday, April 7, 2023 8:04 PM > > On Fri, 7 Apr 2023 10:09:58 + > "Liu, Yi L" wrote: > > > Hi Alex, > > > > > From: Alex Williamson > > > Sent: Monday, April 3, 2023 11:02 PM > > > > > > On Mon, 3 Apr 2023 09:25:06 + > > > "Liu, Yi L" wrote: >

Re: [Intel-gfx] [PATCH v2 5/6] drm/i915/vrr: Relocate VRR enable/disable

On Mon, Mar 27, 2023 at 08:05:49PM +, Golani, Mitulkumar Ajitkumar wrote: > Hi Ville, > > > -Original Message- > > From: Intel-gfx On Behalf Of Ville > > Syrjala > > Sent: 21 March 2023 19:26 > > To: intel-gfx@lists.freedesktop.org > > Subject: [Intel-gfx] [PATCH v2 5/6] drm/i915/vrr:

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Introduce intel_csc_matrix struct

On 4/11/2023 10:37 AM, Ville Syrjälä wrote: @@ -294,13 +293,20 @@ static bool ilk_csc_limited_range(const struct intel_crtc_state *crtc_state) } static void ilk_csc_convert_ctm(const struct intel_crtc_state *crtc_state, - u16 coeffs[9], bool limited_col

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Introduce intel_csc_matrix struct

> > @@ -294,13 +293,20 @@ static bool ilk_csc_limited_range(const struct > > intel_crtc_state *crtc_state) > > } > > > > static void ilk_csc_convert_ctm(const struct intel_crtc_state *crtc_state, > > - u16 coeffs[9], bool limited_color_range) > > +

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/mtl: Define MOCS and PAT tables for MTL (rev3)

== Series Details == Series: drm/i915/mtl: Define MOCS and PAT tables for MTL (rev3) URL : https://patchwork.freedesktop.org/series/115980/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12984 -> Patchwork_115980v3 Summary -

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/mtl: Define MOCS and PAT tables for MTL (rev3)

== Series Details == Series: drm/i915/mtl: Define MOCS and PAT tables for MTL (rev3) URL : https://patchwork.freedesktop.org/series/115980/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/mtl: Define MOCS and PAT tables for MTL (rev3)

== Series Details == Series: drm/i915/mtl: Define MOCS and PAT tables for MTL (rev3) URL : https://patchwork.freedesktop.org/series/115980/ State : warning == Summary == Error: dim checkpatch failed b700f5f3cac2 drm/i915/mtl: Set has_llc=0 4f5011f8f265 drm/i915/mtl: Define MOCS and PAT tables

[Intel-gfx] [PATCH 8/9] drm/i915: making mtl pte encode generic for gen12

From: Fei Yang PTE encode is platform dependent. After replacing cache_level with pat_index, the newly introduced mtl_pte_encode is actually generic for all gen12 platforms, thus rename it to gen12_pte_encode and apply it to all gen12 platforms. Cc: Chris Wilson Cc: Matt Roper Cc: Andi Shyti

[Intel-gfx] [PATCH 4/9] drm/i915/mtl: workaround coherency issue for Media

From: Fei Yang This patch implements Wa_22016122933. In MTL, memory writes initiated by Media tile update the whole cache line even for partial writes. This creates a coherency problem for cacheable memory if both CPU and GPU are writing data to different locations within a single cache line. CT

[Intel-gfx] [PATCH 5/9] drm/i915/mtl: end support for set caching ioctl

From: Fei Yang The design is to keep Buffer Object's caching policy immutable through out its life cycle. This patch ends the support for set caching ioctl from MTL onward. While doing that we also set BO's to be 1-way coherent at creation time because GPU is no longer automatically snooping CPU

[Intel-gfx] [PATCH 0/9] drm/i915/mtl: Define MOCS and PAT tables for MTL

From: Fei Yang The series includes patches needed to enable MTL. Also add new extension for GEM_CREATE uAPI to let user space set cache policy for buffer objects. Fei Yang (9): drm/i915/mtl: Set has_llc=0 drm/i915/mtl: Define MOCS and PAT tables for MTL drm/i915/mtl: Add PTE encode functio

[Intel-gfx] [PATCH 1/9] drm/i915/mtl: Set has_llc=0

From: Fei Yang On MTL, GT is no longer allocated on LLC, set has_llc=0. Signed-off-by: Fei Yang --- drivers/gpu/drm/i915/i915_pci.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index cddb6e197972..025d32c0b161 100644 ---

[Intel-gfx] [PATCH 7/9] drm/i915: use pat_index instead of cache_level

From: Fei Yang Currently the KMD is using enum i915_cache_level to set caching policy for buffer objects. This is flaky because the PAT index which really controls the caching behavior in PTE has far more levels than what's defined in the enum. In addition, the PAT index is platform dependent, ha

[Intel-gfx] [PATCH 9/9] drm/i915: Allow user to set cache at BO creation

From: Fei Yang To comply with the design that buffer objects shall have immutable cache setting through out its life cycle, {set, get}_caching ioctl's are no longer supported from MTL onward. With that change caching policy can only be set at object creation time. The current code applies a defau

[Intel-gfx] [PATCH 6/9] drm/i915: preparation for using PAT index

From: Fei Yang This patch is a preparation for replacing enum i915_cache_level with PAT index. Caching policy for buffer objects is set through the PAT index in PTE, the old i915_cache_level is not sufficient to represent all caching modes supported by the hardware. Preparing the transition by a

[Intel-gfx] [PATCH 3/9] drm/i915/mtl: Add PTE encode function

From: Fei Yang PTE encode functions are platform dependent. This patch implements PTE functions for MTL, and ensures the correct PTE encode function is used by calling pte_encode function pointer instead of the hardcoded gen8 version of PTE encode. Signed-off-by: Fei Yang --- drivers/gpu/drm/i

[Intel-gfx] [PATCH 2/9] drm/i915/mtl: Define MOCS and PAT tables for MTL

From: Fei Yang On MTL, GT can no longer allocate on LLC - only the CPU can. This, along with addition of support for ADM/L4 cache calls a MOCS/PAT table update. BSpec: 44509, 45101, 44235 Cc: Matt Roper Cc: Lucas De Marchi Signed-off-by: Madhumitha Tolakanahalli Pradeep Signed-off-by: Aravi

Re: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

>Subject: Re: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables >for MTL > > On Fri, Apr 07, 2023 at 12:12:29AM -0700, > fei.y...@intel.com wrote: >> From: Fei Yang fei.y...@intel.com >> >> On MTL, GT can no longer allocate on L

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Disable PL1 power limit when loading GuC firmware

== Series Details == Series: drm/i915/guc: Disable PL1 power limit when loading GuC firmware URL : https://patchwork.freedesktop.org/series/116285/ State : success == Summary == CI Bug Log - changes from CI_DRM_12984_full -> Patchwork_116285v1_full =

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Disable PL1 power limit when loading GuC firmware

== Series Details == Series: drm/i915/guc: Disable PL1 power limit when loading GuC firmware URL : https://patchwork.freedesktop.org/series/116285/ State : success == Summary == CI Bug Log - changes from CI_DRM_12984 -> Patchwork_116285v1 S

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/guc: Disable PL1 power limit when loading GuC firmware

== Series Details == Series: drm/i915/guc: Disable PL1 power limit when loading GuC firmware URL : https://patchwork.freedesktop.org/series/116285/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86

Re: [Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete

On Fri, 07 Apr 2023 04:04:06 -0700, Rodrigo Vivi wrote: > Hi Rodrigo, > On Wed, Apr 05, 2023 at 09:45:22PM -0700, Ashutosh Dixit wrote: > > Instead of erroring out when GuC reset is in progress, block waiting for > > GuC reset to complete which is a more reasonable uapi behavior. > > > > Signed-o

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware

On Fri, 07 Apr 2023 04:08:31 -0700, Rodrigo Vivi wrote: > Hi Rodrigo, > On Wed, Apr 05, 2023 at 09:45:21PM -0700, Ashutosh Dixit wrote: > > On dGfx, the PL1 power limit being enabled and set to a low value results > > in a low GPU operating freq. It also negates the freq raise operation which > >

[Intel-gfx] [PATCH 3/3] drm/i915/hwmon: Block waiting for GuC reset to complete

Instead of erroring out when GuC reset is in progress, block waiting for GuC reset to complete which is a more reasonable uapi behavior. v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo) Signed-off-by: Ashutosh Dixit --- drivers/gpu/drm/i915/i915_hwmon.c | 38 +

[Intel-gfx] [PATCH 1/3] drm/i915/hwmon: Get mutex and rpm ref just once in hwm_power_max_write

In preparation for follow-on patches, refactor hwm_power_max_write to take hwmon_lock and runtime pm wakeref at start of the function and release them at the end, therefore acquiring these just once each. Signed-off-by: Ashutosh Dixit Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_hwmo

[Intel-gfx] [PATCH 0/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware

Updates to Patch 2/3 and Patch 3/3 in this version. Ashutosh Dixit (3): drm/i915/hwmon: Get mutex and rpm ref just once in hwm_power_max_write drm/i915/guc: Disable PL1 power limit when loading GuC firmware drm/i915/hwmon: Block waiting for GuC reset to complete drivers/gpu/drm/i915/gt/uc/

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Disable PL1 power limit when loading GuC firmware

On dGfx, the PL1 power limit being enabled and set to a low value results in a low GPU operating freq. It also negates the freq raise operation which is done before GuC firmware load. As a result GuC firmware load can time out. Such timeouts were seen in the GL #8062 bug below (where the PL1 power

[Intel-gfx] ✓ Fi.CI.IGT: success for Add support for dumping error captures via kernel logging

== Series Details == Series: Add support for dumping error captures via kernel logging URL : https://patchwork.freedesktop.org/series/116280/ State : success == Summary == CI Bug Log - changes from CI_DRM_12984_full -> Patchwork_116280v1_full ===

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Initialize dkl_phy spin lock from display code path

== Series Details == Series: series starting with [1/2] drm/i915: Initialize dkl_phy spin lock from display code path URL : https://patchwork.freedesktop.org/series/116272/ State : success == Summary == CI Bug Log - changes from CI_DRM_12984_full -> Patchwork_116272v1_full ===

[Intel-gfx] ✓ Fi.CI.BAT: success for Add support for dumping error captures via kernel logging

== Series Details == Series: Add support for dumping error captures via kernel logging URL : https://patchwork.freedesktop.org/series/116280/ State : success == Summary == CI Bug Log - changes from CI_DRM_12984 -> Patchwork_116280v1 Summary

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add support for dumping error captures via kernel logging

== Series Details == Series: Add support for dumping error captures via kernel logging URL : https://patchwork.freedesktop.org/series/116280/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add support for dumping error captures via kernel logging

== Series Details == Series: Add support for dumping error captures via kernel logging URL : https://patchwork.freedesktop.org/series/116280/ State : warning == Summary == Error: dim checkpatch failed 28aef43095be drm/i915: Dump error capture to kernel log -:61: WARNING:OOM_MESSAGE: Possible u

[Intel-gfx] [PATCH 1/2] drm/i915: Dump error capture to kernel log

From: John Harrison This is useful for getting debug information out in certain situations, such as failing kernel selftests and CI runs that don't log error captures. It is especially useful for things like retrieving GuC logs as GuC operation can't be tracked by adding printk or ftrace entries.

[Intel-gfx] [PATCH 2/2] drm/i915/guc: Dump error capture to dmesg on CTB error

From: John Harrison In the past, There have been sporadic CTB failures which proved hard to reproduce manually. The most effective solution was to dump the GuC log at the point of failure and let the CI system do the repro. It is preferable not to dump the GuC log via dmesg for all issues as it i

[Intel-gfx] [PATCH 0/2] Add support for dumping error captures via kernel logging

From: John Harrison Sometimes, the only effective way to debug an issue is to dump all the interesting information at the point of failure. So add support for doing that. Signed-off-by: John Harrison John Harrison (2): drm/i915: Dump error capture to kernel log drm/i915/guc: Dump error ca

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Initialize dkl_phy spin lock from display code path

== Series Details == Series: series starting with [1/2] drm/i915: Initialize dkl_phy spin lock from display code path URL : https://patchwork.freedesktop.org/series/116272/ State : success == Summary == CI Bug Log - changes from CI_DRM_12984 -> Patchwork_116272v1 =

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915: Initialize dkl_phy spin lock from display code path

== Series Details == Series: series starting with [1/2] drm/i915: Initialize dkl_phy spin lock from display code path URL : https://patchwork.freedesktop.org/series/116272/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be check

[Intel-gfx] [PATCH v3 2/6] drm/i915: Only initialize dlk phy lock in display 12 and newer

This spin lock will not be used in older display versions, so no need to initialize it. Cc: intel-gfx@lists.freedesktop.org Cc: intel...@lists.freedesktop.org Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_dkl_phy.c | 3 ++- 1 file changed,

[Intel-gfx] [PATCH v3 1/6] drm/i915: Initialize dkl_phy spin lock from display code path

Start to move the initialization of some lock from i915_driver_early_probe(). No dkl function is called prior to intel_setup_outputs(), so this is a good place to initialize it. This will also fix a warning in Xe kmd: [ 201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] failed to retr

[Intel-gfx] [PATCH 2/2] drm/i915: Only initialize dlk phy lock in display 12 and newer

This spin lock will not be used in older display versions, so no need to initialize it. Cc: intel-gfx@lists.freedesktop.org Cc: intel...@lists.freedesktop.org Reviewed-by: Rodrigo Vivi Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_dkl_phy.c | 3 ++- 1 file changed,

[Intel-gfx] [PATCH 1/2] drm/i915: Initialize dkl_phy spin lock from display code path

Start to move the initialization of some lock from i915_driver_early_probe(). No dkl function is called prior to intel_setup_outputs(), so this is a good place to initialize it. This will also fix a warning in Xe kmd: [ 201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] failed to retr

Re: [Intel-gfx] [PATCH v7 6/8] drm/i915/uapi/pxp: Fix UAPI spec comments and add GET_PARAM for PXP

On 4/6/2023 10:44 AM, Alan Previn wrote: 1. UAPI update: Without actually changing backward compatible behavior, update i915's drm-uapi comments that describe the possible error values when creating a context with I915_CONTEXT_PARAM_PROTECTED_CONTENT. Since the first merge of PXP support on AD

Re: [Intel-gfx] [Intel-xe] [PATCH v2 rebased 2/6] drm/i915: Initialize dkl_phy spin lock from display code path

On Mon, Apr 10, 2023 at 05:07:57PM +, Souza, Jose wrote: > On Mon, 2023-04-10 at 11:33 -0400, Rodrigo Vivi wrote: > > On Thu, Apr 06, 2023 at 07:31:29AM -0700, José Roberto de Souza wrote: > > > Start to move the initialization of some lock from > > > i915_driver_early_probe(). > > > This will

Re: [Intel-gfx] [Intel-xe] [PATCH v2 rebased 3/6] drm/i915: Only initialize dlk phy lock in display 12 and newer

On Mon, Apr 10, 2023 at 05:10:01PM +, Souza, Jose wrote: > On Mon, 2023-04-10 at 11:37 -0400, Rodrigo Vivi wrote: > > On Thu, Apr 06, 2023 at 07:31:30AM -0700, José Roberto de Souza wrote: > > > This spin lock will not be used in older display versions, so no need > > > to initialize it. > > >

Re: [Intel-gfx] [PATCH v7 5/8] drm/i915/pxp: Add ARB session creation and cleanup

On 4/6/2023 10:44 AM, Alan Previn wrote: Add MTL's function for ARB session creation using PXP firmware version 4.3 ABI structure format. Also add MTL's function for ARB session invalidation but this reuses PXP firmware version 4.2 ABI structure format. For both cases, in the back-end gsccs

Re: [Intel-gfx] [Intel-xe] [PATCH v2 rebased 3/6] drm/i915: Only initialize dlk phy lock in display 12 and newer

On Mon, 2023-04-10 at 11:37 -0400, Rodrigo Vivi wrote: > On Thu, Apr 06, 2023 at 07:31:30AM -0700, José Roberto de Souza wrote: > > This spin lock will not be used in older display versions, so no need > > to initialize it. > > Should we add some warn_on(disp_ver < 12) on the dkl phy functions? I

Re: [Intel-gfx] [PATCH v2 rebased 2/6] drm/i915: Initialize dkl_phy spin lock from display code path

On Mon, 2023-04-10 at 11:33 -0400, Rodrigo Vivi wrote: > On Thu, Apr 06, 2023 at 07:31:29AM -0700, José Roberto de Souza wrote: > > Start to move the initialization of some lock from > > i915_driver_early_probe(). > > This will also fix a warning in Xe kmd: > > > > [ 201.894839] xe :00:02.0:

Re: [Intel-gfx] [PATCH 1/8] drm/i915/mtl: Define MOCS and PAT tables for MTL

On Fri, Apr 07, 2023 at 12:12:29AM -0700, fei.y...@intel.com wrote: > From: Fei Yang > > On MTL, GT can no longer allocate on LLC - only the CPU can. > This, along with addition of support for ADM/L4 cache calls a > MOCS/PAT table update. Also defines PTE encode functions for > MTL as it has diff

Re: [Intel-gfx] [PATCH v7 4/8] drm/i915/pxp: Add GSC-CS backend to send GSC fw messages

On 4/6/2023 10:44 AM, Alan Previn wrote: Add GSC engine based method for sending PXP firmware packets to the GSC firmware for MTL (and future) products. Use the newly added helpers to populate the GSC-CS memory header and send the message packet to the FW by dispatching the GSC_HECI_CMD_PKT i

Re: [Intel-gfx] [PATCH v7 3/8] drm/i915/pxp: Add MTL helpers to submit Heci-Cmd-Packet to GSC

On 4/6/2023 10:44 AM, 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. NOTE1: These common functions for heci-packet-submission

Re: [Intel-gfx] [PATCH v9 4/4] drm/i915/selftests: skip comparison of power for discrete graphics

On Wed, 05 Apr 2023 18:02:04 -0700, Dixit, Ashutosh wrote: > > On Tue, 04 Apr 2023 23:59:30 -0700, Riana Tauro wrote: > > > > Hi Riana, > > > Hwmon reads the energy/power consumed by discrete soc, > > i.e. energy/power includes the power drawn from non-gfx discrete > > components > > > > This test

Re: [Intel-gfx] [Intel-xe] [PATCH v2 rebased 1/6] drm/i915: Nuke unused dsparb_lock

On Mon, Apr 10, 2023 at 11:26:57AM -0400, Rodrigo Vivi wrote: > On Mon, Apr 10, 2023 at 10:43:12AM -0400, Souza, Jose wrote: > > On Thu, 2023-04-06 at 16:38 -0400, Rodrigo Vivi wrote: > > > On Thu, Apr 06, 2023 at 07:31:28AM -0700, José Roberto de Souza wrote: > > > > dsparb_lock it not used anymor

Re: [Intel-gfx] [Intel-xe] [PATCH v2 rebased 3/6] drm/i915: Only initialize dlk phy lock in display 12 and newer

On Thu, Apr 06, 2023 at 07:31:30AM -0700, José Roberto de Souza wrote: > This spin lock will not be used in older display versions, so no need > to initialize it. Should we add some warn_on(disp_ver < 12) on the dkl phy functions? Anyway: Reviewed-by: Rodrigo Vivi > > Cc: intel-gfx@lists.fre

Re: [Intel-gfx] [PATCH v2 rebased 2/6] drm/i915: Initialize dkl_phy spin lock from display code path

On Thu, Apr 06, 2023 at 07:31:29AM -0700, José Roberto de Souza wrote: > Start to move the initialization of some lock from > i915_driver_early_probe(). > This will also fix a warning in Xe kmd: > > [ 201.894839] xe :00:02.0: [drm] [ENCODER:235:DDI A/PHY A] failed to > retrieve link info, di

Re: [Intel-gfx] [Intel-xe] [PATCH v2 rebased 1/6] drm/i915: Nuke unused dsparb_lock

On Mon, Apr 10, 2023 at 10:43:12AM -0400, Souza, Jose wrote: > On Thu, 2023-04-06 at 16:38 -0400, Rodrigo Vivi wrote: > > On Thu, Apr 06, 2023 at 07:31:28AM -0700, José Roberto de Souza wrote: > > > dsparb_lock it not used anymore, nuke it. > > > > Well, this doesn't exist in our drm-tip baseline,

Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO

On Mon, 10 Apr 2023 15:18:27 + "Liu, Yi L" wrote: > > From: Alex Williamson > > Sent: Monday, April 10, 2023 10:41 PM > > > > On Mon, 10 Apr 2023 08:48:54 + > > "Liu, Yi L" wrote: > > > > > > From: Alex Williamson > > > > Sent: Sunday, April 9, 2023 9:30 PM > > > [...] > > > >

Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO

> From: Alex Williamson > Sent: Monday, April 10, 2023 10:41 PM > > On Mon, 10 Apr 2023 08:48:54 + > "Liu, Yi L" wrote: > > > > From: Alex Williamson > > > Sent: Sunday, April 9, 2023 9:30 PM > > [...] > > > > yeah, needs to move the iommu group creation back to vfio_main.c. This > > > > w

Re: [Intel-gfx] [Intel-xe] [PATCH v2 rebased 1/6] drm/i915: Nuke unused dsparb_lock

On Thu, 2023-04-06 at 16:38 -0400, Rodrigo Vivi wrote: > On Thu, Apr 06, 2023 at 07:31:28AM -0700, José Roberto de Souza wrote: > > dsparb_lock it not used anymore, nuke it. > > Well, this doesn't exist in our drm-tip baseline, so it would be good > if this patch is a fixup! to whatever patch is a

Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO

On Mon, 10 Apr 2023 08:48:54 + "Liu, Yi L" wrote: > > From: Alex Williamson > > Sent: Sunday, April 9, 2023 9:30 PM > [...] > > > yeah, needs to move the iommu group creation back to vfio_main.c. This > > > would be a prerequisite for [1] > > > > > > [1] > > > https://lore.kernel.org/kvm/

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Use kmap_local_page() in gem/i915_gem_execbuffer.c

Thanks all for your review! On Fri, Mar 31, 2023 at 05:32:17PM +0200, Fabio M. De Francesco wrote: > Date: Fri, 31 Mar 2023 17:32:17 +0200 > From: "Fabio M. De Francesco" > Subject: Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in > gem/i915_gem_execbuffer.c > > On venerd? 31 marzo 2023 13

Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO

> From: Alex Williamson > Sent: Sunday, April 9, 2023 9:30 PM [...] > > yeah, needs to move the iommu group creation back to vfio_main.c. This > > would be a prerequisite for [1] > > > > [1] https://lore.kernel.org/kvm/20230401151833.124749-25-yi.l@intel.com/ > > > > I'll also try out your sug

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO creation

On 2023-04-05 13:26:43, Jordan Justen wrote: > On 2023-04-05 00:45:24, Lionel Landwerlin wrote: > > On 04/04/2023 19:04, Yang, Fei wrote: > > >> Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache > > >> at BO creation > > >> > > >> Just like the protected content uAPI, there is