[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gt: Add sysfs RAPL PL1 interface (rev2)

== Series Details == Series: drm/i915/gt: Add sysfs RAPL PL1 interface (rev2) URL : https://patchwork.freedesktop.org/series/110476/ State : success == Summary == CI Bug Log - changes from CI_DRM_12670 -> Patchwork_110476v2 Summary ---

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable YCbCr420 for VDSC (rev3)

== Series Details == Series: Enable YCbCr420 for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/112993/ 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.BAT: success for Enable YCbCr420 for VDSC (rev3)

== Series Details == Series: Enable YCbCr420 for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/112993/ State : success == Summary == CI Bug Log - changes from CI_DRM_12670 -> Patchwork_112993v3 Summary --- **SUCCESS**

[Intel-gfx] [PATCH i-g-t 0/2] tests/i915/perf: Add stress / race exercises

Users reported oopses on list corruptions when using i915 perf with a number of concurrently running graphics applications. That indicates we are currently missing some important tests for such scenarios. Cover that gap. Chris Wilson (1): i915/perf: Stress opening of new perf streams against e

[Intel-gfx] [PATCH i-g-t 1/2] i915/perf: Stress opening of new perf streams against existing contexts

From: Chris Wilson Try opening the perf stream while there is a flurry of activity on the system, both new and old contexts. This will exercise the ability of the driver to modify those contexts to work with perf. References: https://gitlab.freedesktop.org/drm/intel/-/issues/6333 Signed-off-by:

[Intel-gfx] [PATCH i-g-t 2/2] tests/i915/perf: Exercise barrier race

Add a new subtest focused on exercising interaction between perf open / close operations, which replace active barriers with perf requests, and concurrent barrier preallocate / acquire operations performed during context first pin / last unpin. References: https://gitlab.freedesktop.org/drm/intel/

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Add sysfs RAPL PL1 interface

Hi Sujaritha, Thank you for the patch! Perhaps something to improve: [auto build test WARNING on drm-tip/drm-tip] url: https://github.com/intel-lab-lkp/linux/commits/Sujaritha-Sundaresan/drm-i915-gt-Add-sysfs-RAPL-PL1-interface/20230131-152446 base: git://anongit.freedesktop.org/drm/drm

Re: [Intel-gfx] [PATCH 2/2] drm/ttm: revert "stop allocating dummy resources during BO creation"

On Wed, 25 Jan 2023 at 16:24, Matthew Auld wrote: > > On Wed, 25 Jan 2023 at 16:15, Christian König > wrote: > > > > Am 25.01.23 um 17:13 schrieb Matthew Auld: > > > On Wed, 25 Jan 2023 at 15:50, Christian König > > > wrote: > > >> This reverts commit 00984ad39599bb2a1e6ec5d4e9c75a749f7f45c9. >

[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable HDCP2.x via GSC CS (rev9)

== Series Details == Series: Enable HDCP2.x via GSC CS (rev9) URL : https://patchwork.freedesktop.org/series/111876/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12670_full -> Patchwork_111876v9_full Summary --- **F

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gt: Add sysfs RAPL PL1 interface (rev2)

== Series Details == Series: drm/i915/gt: Add sysfs RAPL PL1 interface (rev2) URL : https://patchwork.freedesktop.org/series/110476/ State : success == Summary == CI Bug Log - changes from CI_DRM_12670_full -> Patchwork_110476v2_full Summar

Re: [Intel-gfx] [PATCH v6] drm/i915/gt: Add selftests for TLB invalidation

On 30/01/2023 16:50, Andrzej Hajda wrote: From: Chris Wilson Check that we invalidate the TLB cache, the updated physical addresses are immediately visible to the HW, and there is no retention of the old physical address for concurrent HW access. Signed-off-by: Chris Wilson [ahajda: adjust

[Intel-gfx] [PATCH i-g-t 2/8] lib: Allow specifying custom engine map

From: Tvrtko Ursulin Instead of hard coding the engine names, allow a map of names to indices to either be passed in or it gets auto-detected (less efficient) while parsing. --- lib/igt_drm_clients.c | 18 +--- lib/igt_drm_clients.h | 3 ++- lib/igt_drm_fdinfo.c| 48

[Intel-gfx] [PATCH i-g-t 1/8] lib: Extract igt_drm_clients from intel_gpu_top

From: Tvrtko Ursulin Extract some code into a new library to prepare for further work towards making a vendor agnostic gputop tool. Signed-off-by: Tvrtko Ursulin --- lib/igt_drm_clients.c | 432 ++ lib/igt_drm_clients.h | 85 +++ lib/meson.build | 8

[Intel-gfx] [PATCH i-g-t v3 0/8] Vendor agnostic gputop

From: Tvrtko Ursulin This is a pile of patches which implements a rudimentary vendor agnostic gputop tool based of the new DRM spec as documented in Documentation/gpu/drm-usage-stats.rst. First part of the series is code refactoring which should be reasonably stable. I've tested it all while wor

[Intel-gfx] [PATCH i-g-t 3/8] lib/igt_drm_clients: Record client drm minor

From: Tvrtko Ursulin Prepare for supporting clients belonging to multiple DRM cards by storing the DRM minor in the client record. Signed-off-by: Tvrtko Ursulin --- lib/igt_drm_clients.c | 22 ++ lib/igt_drm_clients.h | 1 + 2 files changed, 15 insertions(+), 8 deletions(-

[Intel-gfx] [PATCH i-g-t 4/8] lib/igt_drm_clients: Support multiple DRM cards

From: Tvrtko Ursulin Require DRM minor match during client lookup. Signed-off-by: Tvrtko Ursulin --- lib/igt_drm_clients.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c index c23a3fae9793..e11c8b18188f 100644 --

[Intel-gfx] [PATCH i-g-t 5/8] lib/igt_drm_fdinfo: Track largest engine index

From: Tvrtko Ursulin Prep code for incoming work. Signed-off-by: Tvrtko Ursulin --- lib/igt_drm_fdinfo.c | 2 ++ lib/igt_drm_fdinfo.h | 1 + 2 files changed, 3 insertions(+) diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c index 68c89ad2c17e..b850d2210ae7 100644 --- a/lib/igt_drm_fdin

[Intel-gfx] [PATCH i-g-t 6/8] lib/igt_drm_clients: Decouple hardcoded engine assumptions

From: Tvrtko Ursulin Intel_gpu_top gets it's main engine configuration data via PMU probe and uses that for per client view as well. Furthemore code so far assumed only clients belonging from a single DRM card would be tracked in a single clients list. Break this inter-dependency by moving the e

[Intel-gfx] [PATCH i-g-t 7/8] lib/igt_drm_clients: Enforce client status sort order in the library

From: Tvrtko Ursulin Some libdrmclient operations require that inactive clients are last in the list. Rather than relying on callers of the library sort routine to implement their comparison callbacks correctly, enforce this order directly in the library and let callers comparison callbacks conce

[Intel-gfx] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool

From: Tvrtko Ursulin Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used to display a sorted by card and usage list of processes using GPUs. Borrows a bit of code from intel_gpu_top but for now omits the fancy features like interactive functionality, card selection, client

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gt: Use sysfs_emit() and sysfs_emit_at()

Rerun passed well https://patchwork.freedesktop.org/series/113490/ On 1/30/2023 6:49 PM, Patchwork wrote: Project List - Patchwork *Patch Details* *Series:* drm/i915/gt: Use sysfs_emit() and sysfs_emit_at() *URL:* https://patchwork.freedesktop.org/series/113490/ *State:*failure *D

Re: [Intel-gfx] [PATCH] drm/i915/gt: Use sysfs_emit() and sysfs_emit_at()

On 1/30/2023 9:43 PM, Andi Shyti wrote: Hi Nirmoy, On Mon, Jan 30, 2023 at 02:13:58PM +0100, Nirmoy Das wrote: Use sysfs_emit() and sysfs_emit_at() in show() callback as recommended by Documentation/filesystems/sysfs.rst Cc: Andi Shyti Signed-off-by: Nirmoy Das I thought we didn't have an

[Intel-gfx] ✓ Fi.CI.IGT: success for Enable YCbCr420 for VDSC (rev3)

== Series Details == Series: Enable YCbCr420 for VDSC (rev3) URL : https://patchwork.freedesktop.org/series/112993/ State : success == Summary == CI Bug Log - changes from CI_DRM_12670_full -> Patchwork_112993v3_full Summary --- **SU

Re: [Intel-gfx] [PATCH i-g-t 1/2] i915/perf: Stress opening of new perf streams against existing contexts

Hi, On 2023-01-31 at 10:17:30 +0100, Janusz Krzysztofik wrote: > From: Chris Wilson > > Try opening the perf stream while there is a flurry of activity on the > system, both new and old contexts. This will exercise the ability of the > driver to modify those contexts to work with perf. > > Refe

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for GuC oriented print macros (rev3)

On 28/01/2023 22:11, Patchwork wrote: *Patch Details* *Series:* GuC oriented print macros (rev3) *URL:* https://patchwork.freedesktop.org/series/113162/ *State:*success *Details:* https://intel-gfx-ci.01.org/tree/drm-tip/Patchw

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

On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote: > Hi all, > > Today's linux-next merge of the usb tree got a conflict in: > > drivers/gpu/drm/i915/gt/intel_engine_cs.c > > between commit: > > 5bc4b43d5c6c ("drm/i915: Fix up locking around dumping requests lists") > > from

Re: [Intel-gfx] [PATCH] drm/i915/gt: Fix sphinx warnings for workarounds documentation

On 1/24/23 20:39, Rodrigo Vivi wrote: On Sat, Jan 21, 2023 at 04:08:53PM -0300, Gustavo Sousa wrote: The wildchar ("*") used in the function name patterns in the documentation was taken as a start of an "emphasis" inline markup. Wrap the patterns with the inline literal markup and, for consist

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Add sysfs RAPL PL1 interface

Hi Sujaritha, 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/Sujaritha-Sundaresan/drm-i915-gt-Add-sysfs-RAPL-PL1-interface/20230131-152446 base: git://anongit.freedesktop.org/drm/drm-tip drm

Re: [Intel-gfx] [PATCH i-g-t 1/2] i915/perf: Stress opening of new perf streams against existing contexts

Hi Kamil, Thanks for review. On Tuesday, 31 January 2023 12:59:10 CET Kamil Konieczny wrote: ... > > @@ -5259,6 +5324,15 @@ igt_main > > igt_subtest("whitelisted-registers-userspace-config") > > test_whitelisted_registers_userspace_config(); > > > > Please add description to ne

Re: [Intel-gfx] [PATCH] kvm/vfio: Fix potential deadlock on vfio group_lock

I encountered a lockdep splat while running some regression tests today (see below). I suspected it might be this patch so I reverted it, rebuilt the kernel and ran the regression tests again; this time, the test ran cleanly. It looks like this patch may not have fixed the problem for which it

Re: [Intel-gfx] [PATCH] kvm/vfio: Fix potential deadlock on vfio group_lock

On Tue, Jan 31, 2023 at 09:27:54AM -0500, Anthony Krowiak wrote: > I encountered a lockdep splat while running some regression tests today (see > below). I suspected it might be this patch so I reverted it, rebuilt the > kernel and ran the regression tests again; this time, the test ran cleanly. >

Re: [Intel-gfx] [PATCH] kvm/vfio: Fix potential deadlock on vfio group_lock

On 1/31/23 9:27 AM, Anthony Krowiak wrote: > I encountered a lockdep splat while running some regression tests today (see > below). I suspected it might be this patch so I reverted it, rebuilt the > kernel and ran the regression tests again; this time, the test ran cleanly. > It looks like this

Re: [Intel-gfx] [PATCH] kvm/vfio: Fix potential deadlock on vfio group_lock

On 1/31/23 9:34 AM, Jason Gunthorpe wrote: On Tue, Jan 31, 2023 at 09:27:54AM -0500, Anthony Krowiak wrote: I encountered a lockdep splat while running some regression tests today (see below). I suspected it might be this patch so I reverted it, rebuilt the kernel and ran the regression tests

Re: [Intel-gfx] [PATCH] kvm/vfio: Fix potential deadlock on vfio group_lock

On Tue, Jan 31, 2023 at 09:46:18AM -0500, Anthony Krowiak wrote: > > Maybe you should split that lock and have a dedicated apcb lock? > > I don't think that would suffice for taking the vCPUs out of SIE. Then I think we have to keep this patch and also do Matthew's patch to keep kvm refs inside

Re: [Intel-gfx] [PATCH] kvm/vfio: Fix potential deadlock on vfio group_lock

On 1/31/23 9:48 AM, Jason Gunthorpe wrote: > On Tue, Jan 31, 2023 at 09:46:18AM -0500, Anthony Krowiak wrote: > >>> Maybe you should split that lock and have a dedicated apcb lock? >> >> I don't think that would suffice for taking the vCPUs out of SIE. > > Then I think we have to keep this patch

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement UHBR bandwidth check

On Mon, Jan 16, 2023 at 01:19:37PM +0200, Stanislav Lisovskiy wrote: > According to spec, we should check if output_bpp * pixel_rate is less > than DDI clock * 72, if UHBR is used. > > HSDES: 1406899791 > BSPEC: 49259 > > v2: - Removed wrong comment(Rodrigo Vivi) > - Added HSDES to the commit

[Intel-gfx] [PATCH v2 00/17] drm/i915: drm/i915/dp_mst: Fix MST payload removal during output disabling

This is v2 of [1], addressing the review comments from Ville. It also adds HW state verification for MST encoders and a workaround for a payload allocation problem in a DELL monitor's MST hub I noticed during testing. Tested on HSW, ICL, ADLP. [1] https://lore.kernel.org/intel-gfx/20230125114852

[Intel-gfx] [PATCH v2 01/17] drm/i915/dp_mst: Add the MST topology state for modesetted CRTCs

Add the MST topology for a CRTC to the atomic state if the driver needs to force a modeset on the CRTC after the encoder compute config functions are called. Later the MST encoder's disable hook also adds the state, but that isn't guaranteed to work (since in that hook getting the state may fail,

[Intel-gfx] [PATCH v2 03/17] drm/display/dp_mst: Add drm_atomic_get_old_mst_topology_state()

Add a function to get the old MST topology state, required by a follow-up i915 patch. While at it clarify the code comment of drm_atomic_get_new_mst_topology_state() and add _new prefix to the new state pointer to remind about its difference from the old state. v2: Use old_/new_ prefixes for the

[Intel-gfx] [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()

Atm, drm_dp_remove_payload() uses the same payload state to both get the vc_start_slot required for the payload removal DPCD message and to deduct time_slots from vc_start_slot of all payloads after the one being removed. The above isn't always correct, as vc_start_slot must be the up-to-date vers

[Intel-gfx] [PATCH v2 04/17] drm/i915/dp_mst: Fix payload removal during output disabling

Use the correct old/new topology and payload states in intel_mst_disable_dp(). So far drm_atomic_get_mst_topology_state() it used returned either the old state, in case the state was added already earlier during the atomic check phase or otherwise the new state (but the latter could fail, which can

[Intel-gfx] [PATCH v2 06/17] drm/display/dp_mst: Sanitize payload iteration in drm_dp_mst_dump_topology()

Simplify the loop iterating the payloads by using a helper to get a payload by its VCPI (keeping the list VCPI sorted). This also removes the assumption that the biggest VCPI matches the number of payloads (even though this holds now). Suggested-by: Ville Syrjälä Cc: Lyude Paul Cc: Ville Syrjälä

[Intel-gfx] [PATCH v2 07/17] drm/i915: Factor out helpers for modesetting CRTCs and connectors

Factor out and add the functions to intel_atomic.c to modeset pipes or connectors. These can be used in a few places, also making it a bit clearer where modeset forcing is needed. After this patch the MST topology state for modesetted CRTCs is added already in the connector's atomic check function

[Intel-gfx] [PATCH v2 08/17] drm/i915/dp_mst: Move getting the MST topology state earlier to connector check

Atm, the MST topology state for modesetted CRTCs may get added only in the encoder's compute config function. To make this more consistent with other encoders add these states already earlier in the connector atomic check function and just get the new MST state in the encoder's compute config funct

[Intel-gfx] [PATCH v2 05/17] drm/display/dp_mst: Fix the payload VCPI check in drm_dp_mst_dump_topology()

Fix an off-by-one error in the VCPI check in drm_dp_mst_dump_topology(). Cc: Lyude Paul Cc: Ville Syrjälä Cc: dri-de...@lists.freedesktop.org Signed-off-by: Imre Deak --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/g

[Intel-gfx] [PATCH v2 10/17] drm/i915/dp_mst: Verify the MST state of modesetted outputs

Verify the MST state after disabling/enabling outputs during an atomic commit. v2: Iterate through the connectors in each MST topology to prepare for a follow-up patch adding HW state verification. Cc: Lyude Paul Cc: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/

[Intel-gfx] [PATCH v2 12/17] drm/display/dp_mst: Add helpers to query payload allocation properties

Add helper functions to query the virtual channel and time slots for a payload and the current payload count and total allocated time slots in an MST topology. These are needed by a follow-up i915 patch verifying the SW vs. HW state of the MST topology. Cc: Lyude Paul Cc: Ville Syrjälä Cc: dri-d

[Intel-gfx] [PATCH v2 09/17] drm/display/dp_mst: Add a helper to verify the MST payload state

Add a function drivers can use to verify the MST payload state tracking and compare this to the sink's payload table. Cc: Lyude Paul Cc: Ville Syrjälä Cc: dri-de...@lists.freedesktop.org Signed-off-by: Imre Deak --- drivers/gpu/drm/display/drm_dp_mst_topology.c | 169 ++ includ

[Intel-gfx] [PATCH v2 11/17] drm/display/dp_mst: Add helpers to query for payload allocation errors

Add a way for drivers to query if allocating time slots for any payloads in a given MST topology failed. This is needed by a follow-up i915 patch verifying the SW vs. HW state of the MST topology. Cc: Lyude Paul Cc: Ville Syrjälä Cc: dri-de...@lists.freedesktop.org Signed-off-by: Imre Deak ---

[Intel-gfx] [PATCH v2 16/17] drm/i915/dp_mst: Add workaround for a DELL P2715Q payload allocation problem

The DELL P2715Q monitor's MST hub has a payload allocation problem, where the VCPI used to reserve the last two time slots (at position 0x3e, 0x3f) in the hub's payload table, this VCPI can't be reused for later payload configurations. The problem results at least in streams reusing older VCPIs to

[Intel-gfx] [PATCH v2 15/17] drm/dp: Add a quirk for a DELL P2715Q MST payload allocation problem

The DELL P2715Q monitor's MST hub has a payload allocation problem, where the VCPI used to reserve the last two time slots (at position 0x3e, 0x3f) in the hub's payload table, this VCPI can't be reused for later payload configurations. To work around the problem in a follow-up patch the driver need

[Intel-gfx] [PATCH v2 17/17] drm/i915/dp_mst: Verify the HW state of MST encoders

Read out and verify an MST encoder's HW state after any of the MST connectors driven by the encoder is modeset. Cc: Ville Syrjälä Signed-off-by: Imre Deak --- drivers/gpu/drm/i915/display/intel_ddi.c | 91 +-- drivers/gpu/drm/i915/display/intel_display.c | 2 +- .../drm/i

[Intel-gfx] [PATCH v2 14/17] drm/display/dp_mst: Factor out a helper to reset the payload table

A follow-up patch adds a workaround for a payload allocation problem in a DELL monitor. For this the driver needs to reset the payload table in the monitor's MST hub, factor out a helper to do this. While at it use DP_PAYLOAD_TABLE_SIZE in the reset command, instead of open coding it. Cc: Lyude P

[Intel-gfx] [PATCH v2 13/17] drm/display/dp_mst: Export the DP_PAYLOAD_TABLE_SIZE definition

In a follow-up workaround for a payload allocation problem the driver uses DP_PAYLOAD_TABLE_SIZE to determine when the workaround is needed, so export the definition. Cc: Lyude Paul Cc: Ville Syrjälä Cc: dri-de...@lists.freedesktop.org Signed-off-by: Imre Deak --- drivers/gpu/drm/display/drm_d

Re: [Intel-gfx] [PATCH] kvm/vfio: Fix potential deadlock on vfio group_lock

On Tue, Jan 31, 2023 at 10:00:14AM -0500, Matthew Rosato wrote: > On 1/31/23 9:48 AM, Jason Gunthorpe wrote: > > On Tue, Jan 31, 2023 at 09:46:18AM -0500, Anthony Krowiak wrote: > > > >>> Maybe you should split that lock and have a dedicated apcb lock? > >> > >> I don't think that would suffice fo

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement UHBR bandwidth check

On Tue, Jan 31, 2023 at 05:00:30PM +0200, Ville Syrjälä wrote: > On Mon, Jan 16, 2023 at 01:19:37PM +0200, Stanislav Lisovskiy wrote: > > According to spec, we should check if output_bpp * pixel_rate is less > > than DDI clock * 72, if UHBR is used. > > > > HSDES: 1406899791 > > BSPEC: 49259 > >

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: drm/i915/dp_mst: Fix MST payload removal during output disabling

== Series Details == Series: drm/i915: drm/i915/dp_mst: Fix MST payload removal during output disabling URL : https://patchwork.freedesktop.org/series/113527/ State : warning == Summary == Error: dim checkpatch failed dff29428fcc0 drm/i915/dp_mst: Add the MST topology state for modesetted CRT

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Implement UHBR bandwidth check

On Tue, Jan 31, 2023 at 05:20:44PM +0200, Lisovskiy, Stanislav wrote: > On Tue, Jan 31, 2023 at 05:00:30PM +0200, Ville Syrjälä wrote: > > On Mon, Jan 16, 2023 at 01:19:37PM +0200, Stanislav Lisovskiy wrote: > > > According to spec, we should check if output_bpp * pixel_rate is less > > > than DDI

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: drm/i915/dp_mst: Fix MST payload removal during output disabling

== Series Details == Series: drm/i915: drm/i915/dp_mst: Fix MST payload removal during output disabling URL : https://patchwork.freedesktop.org/series/113527/ State : success == Summary == CI Bug Log - changes from CI_DRM_12674 -> Patchwork_113527v1 ===

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 0/2] tests/i915/perf: Add stress / race exercises

On Tue, 31 Jan 2023 01:17:29 -0800, Janusz Krzysztofik wrote: > Hi Janusz, > Users reported oopses on list corruptions when using i915 perf with a > number of concurrently running graphics applications. That indicates we > are currently missing some important tests for such scenarios. Cover > t

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 0/2] tests/i915/perf: Add stress / race exercises

On Tue, 31 Jan 2023 08:19:48 -0800, Dixit, Ashutosh wrote: > > On Tue, 31 Jan 2023 01:17:29 -0800, Janusz Krzysztofik wrote: > > > > Hi Janusz, > > > Users reported oopses on list corruptions when using i915 perf with a > > number of concurrently running graphics applications. That indicates we >

Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/hdcp: Use HDCP helpers for i915

+Suraj who is also working on HDCP related code that even can conflict wit this. On Wed, Jan 18, 2023 at 07:30:12PM +, Mark Yacoub wrote: > From: Sean Paul First of all, Sean, please accept my public apologies here. I just noticed now that you had pinged me 9 *months* ago! I noticed while

[Intel-gfx] [linux-next:master] BUILD REGRESSION 80bd9028fecadae4e8e3a278cd32d74badc2a6e0

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master branch HEAD: 80bd9028fecadae4e8e3a278cd32d74badc2a6e0 Add linux-next specific files for 20230131 Error/Warning reports: https://lore.kernel.org/oe-kbuild-all/202301230743.xnut0zvc-...@intel.com https

Re: [Intel-gfx] [PATCH v6 07/10] drm/i915/hdcp: Use HDCP helpers for i915

+Suraj On Tue, Jan 31, 2023 at 12:16:44PM -0500, Rodrigo Vivi wrote: > > +Suraj who is also working on HDCP related code that even can conflict > wit this. > > On Wed, Jan 18, 2023 at 07:30:12PM +, Mark Yacoub wrote: > > From: Sean Paul > > First of all, Sean, please accept my public apo

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 0/2] tests/i915/perf: Add stress / race exercises

On Tuesday, 31 January 2023 17:19:48 CET Dixit, Ashutosh wrote: > On Tue, 31 Jan 2023 01:17:29 -0800, Janusz Krzysztofik wrote: > > > > Hi Janusz, > > > Users reported oopses on list corruptions when using i915 perf with a > > number of concurrently running graphics applications. That indicates

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 0/2] tests/i915/perf: Add stress / race exercises

On Tuesday, 31 January 2023 17:55:54 CET Dixit, Ashutosh wrote: > On Tue, 31 Jan 2023 08:19:48 -0800, Dixit, Ashutosh wrote: > > > > On Tue, 31 Jan 2023 01:17:29 -0800, Janusz Krzysztofik wrote: > > > > > > > Hi Janusz, > > > > > Users reported oopses on list corruptions when using i915 perf with a

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

On 1/31/2023 04:44, Andy Shevchenko wrote: On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote: Hi all, Today's linux-next merge of the usb tree got a conflict in: drivers/gpu/drm/i915/gt/intel_engine_cs.c between commit: 5bc4b43d5c6c ("drm/i915: Fix up locking around dump

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 0/2] tests/i915/perf: Add stress / race exercises

On Tue, 31 Jan 2023 09:36:30 -0800, Janusz Krzysztofik wrote: > > Since Chris' subtest didn't help in triggering the list corruption, I've > developed a new subtest that can do it. Since it is almost identical to the > one Chris added, I decided to reuse his code, then add my new subtest to perf >

[Intel-gfx] [PATCH 2/2] drm/i915: Move common mmio base out of private macros

Instead of using the common DISPLAY_MMIO_BASE(dev_priv) in all single macros, only use them in the macros that are to be used outside the header. This reduces the use of the implicit dev_priv, making it easier to remove it later. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_reg.h

[Intel-gfx] [PATCH 1/2] drm/i915: Split _MMIO() for _PORT3()/_PIPE3()

In some cases it might be preferred to use _MMIO() and _PORT3()/_PIPE3() separately, so a common mmio base can be added to all cases. In order to help removing the implicit dev_priv from some macros, this can be used in future patches to pass for example DISPLAY_MMIO_BASE(). Declare _MMIO_PIPE3()

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Split _MMIO() for _PORT3()/_PIPE3()

== Series Details == Series: series starting with [1/2] drm/i915: Split _MMIO() for _PORT3()/_PIPE3() URL : https://patchwork.freedesktop.org/series/113532/ State : success == Summary == CI Bug Log - changes from CI_DRM_12674 -> Patchwork_113532v1 ==

[Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock

After 51cdc8bc120e, we have another deadlock scenario between the kvm->lock and the vfio group_lock with two different codepaths acquiring the locks in different order. Specifically in vfio_open_device, vfio holds the vfio group_lock when issuing device->ops->open_device but some drivers (like vfi

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for vfio: fix deadlock between group lock and kvm lock

== Series Details == Series: vfio: fix deadlock between group lock and kvm lock URL : https://patchwork.freedesktop.org/series/113535/ State : warning == Summary == Error: dim checkpatch failed 22a38a2690cd vfio: fix deadlock between group lock and kvm lock -:91: CHECK:UNCOMMENTED_DEFINITION:

Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock

On Tue, Jan 31, 2023 at 03:06:35PM -0500, Matthew Rosato wrote: > @@ -799,13 +794,14 @@ EXPORT_SYMBOL_GPL(vfio_file_enforced_coherent); > void vfio_file_set_kvm(struct file *file, struct kvm *kvm) > { > struct vfio_group *group = file->private_data; > + unsigned long flags; > >

Re: [Intel-gfx] [PATCH v2] drm/i915/gt: Add sysfs RAPL PL1 interface

On Mon, 30 Jan 2023 22:25:50 -0800, Sujaritha Sundaresan wrote: > Hi Suja, > Adding sysfs attribute rapl_pl1_freq_mhz. This shows the RAPL PL1 > FREQUENCY LIMIT. For MTL do we know if this RAPL PL1 freq limit is for just the GPU or the SOC (CPU + GPU)? > > Signed-off-by: Sujaritha Sundaresan >

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: drm/i915/dp_mst: Fix MST payload removal during output disabling

== Series Details == Series: drm/i915: drm/i915/dp_mst: Fix MST payload removal during output disabling URL : https://patchwork.freedesktop.org/series/113527/ State : success == Summary == CI Bug Log - changes from CI_DRM_12674_full -> Patchwork_113527v1_full =

[Intel-gfx] ✗ Fi.CI.BAT: failure for vfio: fix deadlock between group lock and kvm lock

== Series Details == Series: vfio: fix deadlock between group lock and kvm lock URL : https://patchwork.freedesktop.org/series/113535/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12674 -> Patchwork_113535v1 Summary --

[Intel-gfx] [PATCH] drm/i915/guc: Improve debug message on context reset notification

Just recently we switched over to new GuC oriented log macros but in the meantime yet another message was added that we missed to update. While around improve that new message by adding engine name and use existing helpers to check for context state. Signed-off-by: Michal Wajdeczko Cc: John Harr

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915: Split _MMIO() for _PORT3()/_PIPE3()

== Series Details == Series: series starting with [1/2] drm/i915: Split _MMIO() for _PORT3()/_PIPE3() URL : https://patchwork.freedesktop.org/series/113532/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12674_full -> Patchwork_113532v1_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Improve debug message on context reset notification

== Series Details == Series: drm/i915/guc: Improve debug message on context reset notification URL : https://patchwork.freedesktop.org/series/113537/ State : success == Summary == CI Bug Log - changes from CI_DRM_12675 -> Patchwork_113537v1

[Intel-gfx] [PATCH] drm/i915/huc: Add and use HuC oriented print macros

Like we did it for GuC, introduce some helper print macros for HuC to have unified format of messages that also include GT#. While around improve some messages and use %pe if possible. Signed-off-by: Michal Wajdeczko Cc: John Harrison --- drivers/gpu/drm/i915/gt/uc/intel_huc.c | 44 +++

Re: [Intel-gfx] [PATCH v2 16/17] drm/i915/dp_mst: Add workaround for a DELL P2715Q payload allocation problem

On Tue, 2023-01-31 at 17:05 +0200, Imre Deak wrote: > The DELL P2715Q monitor's MST hub has a payload allocation problem, LMAO hello yet again, Dell P2715Q. It's been a while. > where the VCPI used to reserve the last two time slots (at position > 0x3e, 0x3f) in the hub's payload table, this VCPI

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: Add and use HuC oriented print macros

== Series Details == Series: drm/i915/huc: Add and use HuC oriented print macros URL : https://patchwork.freedesktop.org/series/113542/ State : success == Summary == CI Bug Log - changes from CI_DRM_12675 -> Patchwork_113542v1 Summary -

Re: [Intel-gfx] [PATCH v2 02/17] drm/display/dp_mst: Handle old/new payload states in drm_dp_remove_payload()

On Tue, 2023-01-31 at 17:05 +0200, Imre Deak wrote: > Atm, drm_dp_remove_payload() uses the same payload state to both get the > vc_start_slot required for the payload removal DPCD message and to > deduct time_slots from vc_start_slot of all payloads after the one being > removed. > > The above is

Re: [Intel-gfx] [PATCH v2 06/17] drm/display/dp_mst: Sanitize payload iteration in drm_dp_mst_dump_topology()

On Tue, 2023-01-31 at 17:05 +0200, Imre Deak wrote: > Simplify the loop iterating the payloads by using a helper to get a > payload by its VCPI (keeping the list VCPI sorted). This also removes > the assumption that the biggest VCPI matches the number of payloads > (even though this holds now). >

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Improve debug message on context reset notification

== Series Details == Series: drm/i915/guc: Improve debug message on context reset notification URL : https://patchwork.freedesktop.org/series/113537/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12675_full -> Patchwork_113537v1_full ===

Re: [Intel-gfx] [PATCH v2 16/17] drm/i915/dp_mst: Add workaround for a DELL P2715Q payload allocation problem

I mentioned this once already but: really, I am genuinely impressed at this! I never expected to see this monitor ever work. Also, thank you a ton for adding the payload table verification stuff here. For the whole series: Reviewed-by: Lyude Paul On Tue, 2023-01-31 at 17:05 +0200, Imre Deak wrot

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/huc: Add and use HuC oriented print macros

== Series Details == Series: drm/i915/huc: Add and use HuC oriented print macros URL : https://patchwork.freedesktop.org/series/113542/ State : success == Summary == CI Bug Log - changes from CI_DRM_12675_full -> Patchwork_113542v1_full Sum

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

Hi all, On Tue, 31 Jan 2023 10:27:29 -0800 John Harrison wrote: > > On 1/31/2023 04:44, Andy Shevchenko wrote: > > On Tue, Jan 31, 2023 at 01:03:05PM +1100, Stephen Rothwell wrote: > >> > >> Today's linux-next merge of the usb tree got a conflict in: > >> > >>drivers/gpu/drm/i915/gt/intel_

[Intel-gfx] ✗ Fi.CI.BUILD: failure for linux-next: manual merge of the usb tree with the drm-intel-fixes tree

== Series Details == Series: linux-next: manual merge of the usb tree with the drm-intel-fixes tree URL : https://patchwork.freedesktop.org/series/113544/ State : failure == Summary == Error: make failed CALLscripts/checksyscalls.sh DESCEND objtool CC [M] drivers/gpu/drm/i915/gt/int

Re: [Intel-gfx] [PATCH] vfio: fix deadlock between group lock and kvm lock

> From: Matthew Rosato > Sent: Wednesday, February 1, 2023 4:07 AM > > - device->kvm = kvm; > + /* > + * Get the KVM pointer currently associated with the group, if there > + * is one, and obtain a reference now that will be held until the > + * open_count reaches 0. Save

Re: [Intel-gfx] [PATCH 1/6] drm/i915/ttm: fix sparse warning

Am 30.01.23 um 11:12 schrieb Matthew Auld: Sparse complains with: drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: expected restricted vm_fault_t [assigned] [usertype] ret drivers/gpu/drm/i915/gem/i915_gem_ttm.c:1066:21: sparse: got int Fixes: 516198d317d8 ("drm/i915: audit bo->