[Intel-gfx] ✗ Fi.CI.BAT: failure for dyndbg & drm.debug to tracefs

== Series Details == Series: dyndbg & drm.debug to tracefs URL : https://patchwork.freedesktop.org/series/98590/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11053 -> Patchwork_21938 Summary --- **FAILURE** Serio

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for dyndbg & drm.debug to tracefs

== Series Details == Series: dyndbg & drm.debug to tracefs URL : https://patchwork.freedesktop.org/series/98590/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for dyndbg & drm.debug to tracefs

== Series Details == Series: dyndbg & drm.debug to tracefs URL : https://patchwork.freedesktop.org/series/98590/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1d9ff9e9bc72 dyndbg: add _DPRINTK_FLAGS_ENABLED -:23: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #23: F

[Intel-gfx] [PATCH v11 19/19] drm_print: use DEFINE_DYNAMIC_DEBUG_CLASSBITS for drm.debug

if CONFIG_DRM_USE_DYNDBG=y, use new macro to create the sysfs bitmap to control drm.debug callsites. DEFINE_DYNAMIC_DEBUG_CLASSBITS( debug, __drm_debug, "drm.debug - control summary", /* inline vector of dyndbg.class_id (uint:4, 0 is reserved) */ DRM_UT_CORE, DRM_UT

[Intel-gfx] [PATCH v11 16/19] drm_print: add struct _ddebug desc to drm_*dbg

A recent commit adding trace-events to drm noted: trace_*() additions are strictly redundant with printks to syslog, not properly placed to reduce overall work. That was because it didn't have the struct _ddebug *descriptor, whose .flags specify TRACE and PRINTK actions on a controlled call

[Intel-gfx] [PATCH v11 17/19] drm_print: add struct _ddebug *desc to trace-drm-*() params

Replace trace-drm-*()s category param with struct _ddebug *desc; it has .classid field, which is the category. This brings the events closer in line with those added for dyndbg; at least the 1st param, and possibly the struct device (tb-checked). There are still differences in the tail of the prot

[Intel-gfx] [PATCH v11 18/19] dyndbg: add DEFINE_DYNAMIC_DEBUG_CLASSBITS macro and callbacks

DEFINE_DYNAMIC_DEBUG_CLASSBITS(fsname, var, bitmap_desc, classes..) allows users to create a drm.debug style (bitmap) sysfs interface, to control sets of pr_debug's according to their .class_id's 1st, due to a recent commit, this already works: echo "module drm class 1 +p ; module drm class 3

[Intel-gfx] [PATCH v11 15/19] drm_print: use _dynamic_func_call_no_desc_cls

Upgrade the current use of _dynamic_func_call_no_desc(), adding the suffix and the category arg. The arg has been available via the macros implementing the drm.debug api, but dyndbg lacked a simple way to represent it and use it until recently. Signed-off-by: Jim Cromie --- include/drm/drm_prin

[Intel-gfx] [PATCH v11 14/19] drm_print: prefer bare printk KERN_DEBUG on generic fn

drm_print.c calls pr_debug() just once, from __drm_printfn_debug(), which is a generic/service fn. The callsite is compile-time enabled by DEBUG in both DYNAMIC_DEBUG=y/n builds. For dyndbg builds, reverting this callsite back to bare printk is correcting a few anti-features: 1- callsite is gene

[Intel-gfx] [PATCH v11 11/19] drm_print: wrap drm_dev_dbg in _dynamic_func_call_no_desc

make drm_dev_dbg() macro CONFIG_DRM_USE_DYNAMIC_DEBUG dependent: =N direct forwarding: drm_dev_dbg -> __drm_dev_dbg() =Y wrap __drm_dev_dbg in _dynamic_func_call_no_desc(). This adds the metadata which creates a /proc/dynamic_debug/control entry for each callsite, and exposes it for selective

[Intel-gfx] [PATCH v11 13/19] drm_print: refine drm_debug_enabled for dyndbg+jump-label

In order to use dynamic-debug's jump-label optimization in drm-debug, its clarifying to refine drm_debug_enabled into 3 uses: 1. drm_debug_enabled - legacy, public 2. __drm_debug_enabled - optimized for dyndbg jump-label enablement. 3. _drm_debug_enabled - pr_debug instrumented, observable 1.

[Intel-gfx] [PATCH v11 12/19] drm_print: wrap drm_dbg in _dynamic_func_call_no_desc

Change __drm_dbg() macro to be CONFIG_DRM_USE_DYNAMIC_DEBUG dependent: N- keep straight mapping to exported ___drm_dbg() Y- wrap ___drm_dbg() inside _dynamic_func_call_no_desc() This patch places ~1/2 of drm.debug API messages behind dyndbg's JUMP_LABEL/NOOP optimization. The CONFIG_DRM_USE_D

[Intel-gfx] [PATCH v11 10/19] drm_print: interpose drm_dev_dbg, __drm_dbg with forwarding macros

drm_dev_dbg() & _drm_dbg() sit below the categorized layer of the DRM debug API, and thus implement most of it. These are good places to insert dynamic-debug jump-label mechanics, allowing DRM to avoid the runtime cost of drm_debug_enabled(). Set up for this by changing the func names by adding '

[Intel-gfx] [PATCH v11 06/19] dyndbg: add class_id to callsites

DRM defines/uses a 10 enum drm_debug_category to create exclusive classes of debug messages. To support this directly in dynamic-debug, add the following: - struct _ddebug.class_id 4 bits is enough for drm_debug_category and the query support: - struct _ddebug_query.class_id - ddebug_chan

[Intel-gfx] [PATCH v11 09/19] drm_print: add CONFIG_DRM_USE_DYNAMIC_DEBUG

DRM.debug API is used thousands of times in drivers/gpu/drm/*; when these are implemented using dynamic-debug, DYNAMIC_DEBUG_METADATA adds a struct _ddebug (56 bytes) per site. Since i915 will have ~2k callsites, and amdgpu ~4k, the memory costs are substantial, and thus made configurable. For a

[Intel-gfx] [PATCH v11 07/19] drm_print: condense enum drm_debug_category

enum drm_debug_category has 10 hardcoded values, which could be "simplified" as sequential BIT(x)s. But lets take it one step further, removing the explicit initializations (other than starting at 1), and move the BIT() operation into drm_debug_enabled(). This gives us a more compact representati

[Intel-gfx] [PATCH v11 08/19] drm_print: add trace_drm_dbg, trace_drm_devdbg events

__drm_debug() and __drm_dev_dbg() currently printk to syslog. These 2 underlay the vast bulk of DRM.debug api calls; they are a significant source of debugging info, and could add useful context to debug traces. Wire them to emit 2 new trace_*() events: drm_prdbg and drm_devdbg. These events kee

[Intel-gfx] [PATCH v11 05/19] dyndbg: add desc, dev fields to event record

commit:HEAD~1 added pr_debug(), dev_dbg() params to the new events, but didn't actually capture the params. Do that now; add the other TP_* parts: __fields, fast-assign, and printk elements for the desccriptor and device params. The message capture part is copied from printk:console, it gets the

[Intel-gfx] [PATCH v11 04/19] dyndbg: add trace-events for pr_debug, dev_dbg

In commit HEAD~1, pr_debug temporarily issued a printk:console event. Replace that use with 2 new events: bash-5.1# ls events/dyndbg/ devdbg enable filter prdbg ..called from pr_debug(), dev_dbg() respectively for dyndbg builds. This links the old pr_debug API to tracefs, via dyndbg, allo

[Intel-gfx] [PATCH v11 03/19] dyndbg: add write-to-tracefs code

adds: dynamic_trace() uses trace_console() temporarily to issue printk:console event uses internal-ish __ftrace_trace_stack code: 4-context buffer stack, barriers per Steve call it from new funcs: dynamic_printk() - print to both syslog/tracefs dynamic_dev_printk() - dev-print to both

[Intel-gfx] [PATCH v11 02/19] dyndbg: add _DPRINTK_FLAGS_TRACE

add new flag, and OR it into _DPRINTK_FLAGS_ENABLED definition CC: vincent.whitchu...@axis.com Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index 25

[Intel-gfx] [PATCH v11 01/19] dyndbg: add _DPRINTK_FLAGS_ENABLED

Distinguish the condition: _DPRINTK_FLAGS_ENABLED from the bit: _DPRINTK_FLAGS_PRINT, in preparation to add _DPRINTK_FLAGS_TRACE next. Also add a 'K' to get _DPRINTK_FLAGS_PRINTK, to insure is not used elsewhere with a stale meaning. CC: vincent.whitchu...@axis.com Signed-off-by: Jim Cromie ---

[Intel-gfx] [PATCH v11 00/19] dyndbg & drm.debug to tracefs

hi Jason, Steve, Greg, DRM-folks, This patchset plumbs debug streams, from dynamic-debug, and from drm.debug, into tracefs. Enabling traffic is done on both source & destination: # enable at source echo module usbcore +T > /proc/dynamic_debug/control # enable events into

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Don't error on reset of banned context

== Series Details == Series: drm/i915/guc: Don't error on reset of banned context URL : https://patchwork.freedesktop.org/series/98580/ State : success == Summary == CI Bug Log - changes from CI_DRM_11053 -> Patchwork_21937 Summary ---

[Intel-gfx] ✗ Fi.CI.BAT: failure for Update to GuC version 69.0.3 (rev6)

== Series Details == Series: Update to GuC version 69.0.3 (rev6) URL : https://patchwork.freedesktop.org/series/98249/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11053 -> Patchwork_21936 Summary --- **FAILURE**

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Update to GuC version 69.0.3 (rev6)

== Series Details == Series: Update to GuC version 69.0.3 (rev6) URL : https://patchwork.freedesktop.org/series/98249/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Update to GuC version 69.0.3 (rev6)

== Series Details == Series: Update to GuC version 69.0.3 (rev6) URL : https://patchwork.freedesktop.org/series/98249/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3cb0d5aae374 drm/i915/guc: Temporarily bump the GuC load timeout ecc0ec4433ae drm/i915/guc: Update to GuC version

Re: [Intel-gfx] [PATCH] drm/i915/guc: Don't error on reset of banned context

On 1/6/2022 16:31, john.c.harri...@intel.com wrote: From: John Harrison There is a race (already documented in the code) whereby a context can be (re-)queued for submission at the same time as it is being banned due to a hang and reset. That leads to a hang/reset report from GuC for a context w

[Intel-gfx] [PATCH] drm/i915/guc: Don't error on reset of banned context

From: John Harrison There is a race (already documented in the code) whereby a context can be (re-)queued for submission at the same time as it is being banned due to a hang and reset. That leads to a hang/reset report from GuC for a context which i915 thinks is already banned. While the race is

[Intel-gfx] ✓ Fi.CI.BAT: success for Start cleaning up register definitions

== Series Details == Series: Start cleaning up register definitions URL : https://patchwork.freedesktop.org/series/98575/ State : success == Summary == CI Bug Log - changes from CI_DRM_11052 -> Patchwork_21935 Summary --- **SUCCESS**

[Intel-gfx] [PATCH v2 2/3] drm/i915/guc: Update to GuC version 69.0.3

From: John Harrison Update to the latest GuC release. The latest GuC firmware introduces a number of interface changes: GuC may return NO_RESPONSE_RETRY message for requests sent over CTB. Add support for this reply and try resending the request again as a new CTB message. A KLV (key-length-va

[Intel-gfx] [PATCH v2 3/3] drm/i915/guc: Improve GuC loading status check/error reports

From: John Harrison If the GuC fails to load, it is useful to know what firmware file / version was attempted. So move the version info report to before the load attempt rather than only after a successful load. If the GuC does fail to load, then make the error messages visible rather than being

[Intel-gfx] [PATCH v2 1/3] drm/i915/guc: Temporarily bump the GuC load timeout

From: John Harrison There is a known (but exceedingly unlikely) race condition where the asynchronous frequency management code could reduce the GT clock while a GuC reload is in progress (during a full GT reset). A fix is in progress but there are complex locking issues to be resolved. In the me

[Intel-gfx] [PATCH v2 0/3] Update to GuC version 69.0.3

From: John Harrison Update to the latest GuC version. This includes a suite of interface changes and new features with corresponding i915 side changes. v2: Rebased to latest tree. Signed-off-by: John Harrison John Harrison (3): drm/i915/guc: Temporarily bump the GuC load timeout drm/i91

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Start cleaning up register definitions

== Series Details == Series: Start cleaning up register definitions URL : https://patchwork.freedesktop.org/series/98575/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Start cleaning up register definitions

== Series Details == Series: Start cleaning up register definitions URL : https://patchwork.freedesktop.org/series/98575/ State : warning == Summary == $ dim checkpatch origin/drm-tip cd93e9e13e3d drm/i915: Drop unused register definitions -:34: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped

Re: [Intel-gfx] [PATCH v2 1/2] x86/quirks: Fix logic to apply quirk once

On Thu, Jan 06, 2022 at 02:30:47PM -0800, Lucas De Marchi wrote: > On Thu, Jan 06, 2022 at 03:58:50PM -0600, Bjorn Helgaas wrote: > > On Wed, Jan 05, 2022 at 04:36:53PM -0800, Lucas De Marchi wrote: > > > When using QFLAG_APPLY_ONCE we make sure the quirk is called only once. > > > This is useful w

[Intel-gfx] [PATCH 0/1] Start cleaning up register definitions

Our i915_reg.h file has become a huge unwieldy mess over the years. A lot of definitions don't follow any logical ordering, there's unintentional duplication of registers under different names, the coding style is very inconsistent, and there's tons of unused definitions (nearly a quarter of i915_

Re: [Intel-gfx] [PATCH v2 2/2] x86/quirks: better wrap quirk conditions

On Thu, Jan 06, 2022 at 04:23:25PM -0600, Bjorn Helgaas wrote: On Wed, Jan 05, 2022 at 04:36:54PM -0800, Lucas De Marchi wrote: Remove extra parenthesis and wrap lines so it's easier to read what are the conditions being checked. The call to the hook also had an extra indentation: remove here to

Re: [Intel-gfx] [PATCH v2 1/2] x86/quirks: Fix logic to apply quirk once

On Thu, Jan 06, 2022 at 03:58:50PM -0600, Bjorn Helgaas wrote: On Wed, Jan 05, 2022 at 04:36:53PM -0800, Lucas De Marchi wrote: When using QFLAG_APPLY_ONCE we make sure the quirk is called only once. This is useful when it's enough one device to trigger a certain condition or when the resource i

Re: [Intel-gfx] [PATCH v2 2/2] x86/quirks: better wrap quirk conditions

On Wed, Jan 05, 2022 at 04:36:54PM -0800, Lucas De Marchi wrote: > Remove extra parenthesis and wrap lines so it's easier to read what are > the conditions being checked. The call to the hook also had an extra > indentation: remove here to conform to coding style. It's nice when your subject lines

Re: [Intel-gfx] [PATCH v2 1/2] x86/quirks: Fix logic to apply quirk once

On Wed, Jan 05, 2022 at 04:36:53PM -0800, Lucas De Marchi wrote: > When using QFLAG_APPLY_ONCE we make sure the quirk is called only once. > This is useful when it's enough one device to trigger a certain > condition or when the resource in each that applies is global to the > system rather than lo

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/pxp: Hold RPM wakelock during PXP unbind (rev3)

== Series Details == Series: drm/i915/pxp: Hold RPM wakelock during PXP unbind (rev3) URL : https://patchwork.freedesktop.org/series/98245/ State : success == Summary == CI Bug Log - changes from CI_DRM_11052 -> Patchwork_21934 Summary

Re: [Intel-gfx] [PATCH i-g-t] tests/i915/perf_pmu: Fix allow hang handling

On Thu, 06 Jan 2022 08:42:58 -0800, Tvrtko Ursulin wrote: > > From: Tvrtko Ursulin > > Commit d7a74b959eea ("tests/i915/perf_pmu: Convert to intel_ctx_t (v3)") > broke the test when it is run in its entirety. > > Correct context id needs to be used with igt_allow_hang to avoid context > ban preven

[Intel-gfx] [PATCH v2 1/1] drm/i915/pxp: Hold RPM wakelock during PXP unbind

Similar to commit b8d8436840ca ("drm/i915/gt: Hold RPM wakelock during PXP suspend") but to fix the same warning for unbind during shutdown: [ cut here ] RPM wakelock ref not held during HW access WARNING: CPU: 0 PID: 4139 at drivers/gpu/drm/i915/intel_runtime_pm.h:115 gen1

[Intel-gfx] [PATCH v2 0/1] drm/i915/pxp: Hold RPM wakelock during PXP unbind

Similar to commit b8d8436840ca ("drm/i915/gt: Hold RPM wakelock during PXP suspend") but to fix the same warning for unbind during shutdown See https://patchwork.freedesktop.org/series/98310/ for trybot pass with DRM_I915_PXP enabled. Changes since v1: - Rebased to latest drm-tip Juston Li (1):

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915: don't call free_mmap_offset when purging

I believe that's because of missing machine Missing (7): bat-dg1-6 bat-dg1-5 fi-bsw-cyan bat-adlp-6 bat-rpls-1 fi-bdw-samus bat-jsl-1 Looks like DG1 results were not used while the report is generated. Good that you checked the full logs. +@Latvala, Petri Lakshmi. -Original Message- Fr

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/4] drm/i915: don't call free_mmap_offset when purging

== Series Details == Series: series starting with [v3,1/4] drm/i915: don't call free_mmap_offset when purging URL : https://patchwork.freedesktop.org/series/98562/ State : success == Summary == CI Bug Log - changes from CI_DRM_11052 -> Patchwork_21933 =

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v3,1/4] drm/i915: don't call free_mmap_offset when purging

== Series Details == Series: series starting with [v3,1/4] drm/i915: don't call free_mmap_offset when purging URL : https://patchwork.freedesktop.org/series/98562/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be chec

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v3,1/4] drm/i915: don't call free_mmap_offset when purging

== Series Details == Series: series starting with [v3,1/4] drm/i915: don't call free_mmap_offset when purging URL : https://patchwork.freedesktop.org/series/98562/ State : warning == Summary == $ dim checkpatch origin/drm-tip 11c0df259084 drm/i915: don't call free_mmap_offset when purging -:2

[Intel-gfx] ✓ Fi.CI.BAT: success for Per client GPU stats (rev6)

== Series Details == Series: Per client GPU stats (rev6) URL : https://patchwork.freedesktop.org/series/92574/ State : success == Summary == CI Bug Log - changes from CI_DRM_11052 -> Patchwork_21932 Summary --- **SUCCESS** No regr

Re: [Intel-gfx] [RFC 7/7] drm/i915/guc: Print the GuC error capture output register list.

On Thu, 2022-01-06 at 09:38 +, Tvrtko Ursulin wrote: > On 05/01/2022 17:30, Teres Alexis, Alan Previn wrote: > > On Tue, 2022-01-04 at 13:56 +, Tvrtko Ursulin wrote: > > > > The flow of events are as below: > > > > > > > > 1. guc sends notification that an error capture was done and ready

[Intel-gfx] ✗ Fi.CI.DOCS: warning for Per client GPU stats (rev6)

== Series Details == Series: Per client GPU stats (rev6) URL : https://patchwork.freedesktop.org/series/92574/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_context_types.h:417: warning: Function parameter or member 'client_link

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Per client GPU stats (rev6)

== Series Details == Series: Per client GPU stats (rev6) URL : https://patchwork.freedesktop.org/series/92574/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Per client GPU stats (rev6)

== Series Details == Series: Per client GPU stats (rev6) URL : https://patchwork.freedesktop.org/series/92574/ State : warning == Summary == $ dim checkpatch origin/drm-tip abb04b2f19c6 drm/i915: Explicitly track DRM clients -:129: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), do

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915: don't call free_mmap_offset when purging

Lakshmi, any idea why this reports as success? Clicking on the "See full logs" for BAT there is a clear new failure on DG1 in one of the selftests, which is caused by this series. It also doesn't appear in the issues hit below. On 06/01/2022 12:32, Patchwork wrote: *Patch Details* *Series:* s

[Intel-gfx] [PATCH v3 4/4] drm/i915/ttm: ensure we unmap when purging

Purging can happen during swapping out, or directly invoked with the madvise ioctl. In such cases this doesn't involve a ttm move, which skips umapping the object. v2(Thomas): - add ttm_truncate helper, and just call into i915_ttm_move_notify() to handle the unmapping step Fixes: cf3e3e86d779 (

[Intel-gfx] [PATCH v3 3/4] drm/i915/ttm: add unmap_virtual callback

Ensure we call ttm_bo_unmap_virtual when releasing the pages. Importantly this should now handle the ttm swapping case, and all other places that already call into i915_ttm_move_notify(). v2: fix up the selftest Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.") Signed-off-by:

[Intel-gfx] [PATCH v3 1/4] drm/i915: don't call free_mmap_offset when purging

The TTM backend is in theory the only user here(also purge should only be called once we have dropped the pages), where it is setup at object creation and is only removed once the object is destroyed. Also resetting the node here might be iffy since the ttm fault handler uses the stored fake offset

[Intel-gfx] [PATCH v3 2/4] drm/i915/ttm: only fault WILLNEED objects

Don't attempt to fault and re-populate purged objects. By some fluke this passes the dontneed-after-mmap IGT, but for the wrong reasons. Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.") Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Thomas Hellström --- driv

Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline

On Thu, Jan 06, 2022 at 04:51:21PM +, Tvrtko Ursulin wrote: > > On 06/01/2022 16:18, Matthew Brost wrote: > > On Thu, Jan 06, 2022 at 09:56:03AM +, Tvrtko Ursulin wrote: > > > > > > On 05/01/2022 16:24, Matthew Brost wrote: > > > > On Wed, Jan 05, 2022 at 09:35:44AM +, Tvrtko Ursulin

[Intel-gfx] [PATCH 7/7] drm/i915: Expose client engine utilisation via fdinfo

From: Tvrtko Ursulin Similar to AMD commit 874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the infrastructure added in previous patches, we add basic client info and GPU engine utilisation for i915. Example of the output: pos:0 flags: 012 mnt_id: 21 drm-driver:

[Intel-gfx] [PATCH 6/7] drm: Document fdinfo format specification

From: Tvrtko Ursulin Proposal to standardise the fdinfo text format as optionally output by DRM drivers. Idea is that a simple but, well defined, spec will enable generic userspace tools to be written while at the same time avoiding a more heavy handed approach of adding a mid-layer to DRM. i91

[Intel-gfx] [PATCH 5/7] drm/i915: Track context current active time

From: Tvrtko Ursulin Track context active (on hardware) status together with the start timestamp. This will be used to provide better granularity of context runtime reporting in conjunction with already tracked pphwsp accumulated runtime. The latter is only updated on context save so does not g

[Intel-gfx] [PATCH 4/7] drm/i915: Track all user contexts per client

From: Tvrtko Ursulin We soon want to start answering questions like how much GPU time is the context belonging to a client which exited still using. To enable this we start tracking all context belonging to a client on a separate list. Signed-off-by: Tvrtko Ursulin Reviewed-by: Aravind Iddamse

[Intel-gfx] [PATCH 3/7] drm/i915: Track runtime spent in closed and unreachable GEM contexts

From: Tvrtko Ursulin As contexts are abandoned we want to remember how much GPU time they used (per class) so later we can used it for smarter purposes. As GEM contexts are closed we want to have the DRM client remember how much GPU time they used (per class) so later we can used it for smarter

[Intel-gfx] [PATCH 2/7] drm/i915: Make GEM contexts track DRM clients

From: Tvrtko Ursulin Make GEM contexts keep a reference to i915_drm_client for the whole of of their lifetime which will come handy in following patches. v2: Don't bother supporting selftests contexts from debugfs. (Chris) v3 (Lucas): Finish constructing ctx before adding it to the list v4 (Ram)

[Intel-gfx] [PATCH 1/7] drm/i915: Explicitly track DRM clients

From: Tvrtko Ursulin Tracking DRM clients more explicitly will allow later patches to accumulate past and current GPU usage in a centralised place and also consolidate access to owning task pid/name. Unique client id is also assigned for the purpose of distinguishing/ consolidating between multi

[Intel-gfx] [PATCH 0/7] Per client GPU stats

From: Tvrtko Ursulin Same old work but now rebased and series ending with some DRM docs proposing the common specification which should enable nice common userspace tools to be written. For the moment I only have intel_gpu_top converted to use this and that seems to work okay. v2: * Added prot

Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline

On 06/01/2022 16:18, Matthew Brost wrote: On Thu, Jan 06, 2022 at 09:56:03AM +, Tvrtko Ursulin wrote: On 05/01/2022 16:24, Matthew Brost wrote: On Wed, Jan 05, 2022 at 09:35:44AM +, Tvrtko Ursulin wrote: On 04/01/2022 23:30, Matthew Brost wrote: Don't use the interruptable version

[Intel-gfx] [PATCH i-g-t 2/3] tests/i915/drm_fdinfo: Basic and functional tests for GPU busyness exported via fdinfo

From: Tvrtko Ursulin Mostly inherited from the perf_pmu, some basic tests, and some tests to verify exported GPU busyness is as expected. Signed-off-by: Tvrtko Ursulin --- tests/i915/drm_fdinfo.c | 555 tests/meson.build | 8 + 2 files changed,

[Intel-gfx] [PATCH i-g-t 0/3] Tests and intel_gpu_top with fdinfo support

From: Tvrtko Ursulin Mostly sending so I can use Test-with: but review is always welcome. Tvrtko Ursulin (3): lib: Helper library for parsing i915 fdinfo output tests/i915/drm_fdinfo: Basic and functional tests for GPU busyness exported via fdinfo intel-gpu-top: Add support for per cli

[Intel-gfx] [PATCH i-g-t 3/3] intel-gpu-top: Add support for per client stats

From: Tvrtko Ursulin Use the i915 exported data in /proc//fdinfo to show GPU utilization per DRM client. Example of the output: intel-gpu-top: Intel Tigerlake (Gen12) @ /dev/dri/card0 - 220/ 221 MHz 70% RC6; 0.62/ 7.08 W; 760 irqs/s ENGINES BUSY

[Intel-gfx] [PATCH i-g-t 1/3] lib: Helper library for parsing i915 fdinfo output

From: Tvrtko Ursulin Tests and intel_gpu_top will share common code for parsing this file. Signed-off-by: Tvrtko Ursulin --- lib/igt_drm_fdinfo.c | 161 +++ lib/igt_drm_fdinfo.h | 47 + lib/meson.build | 7 ++ 3 files changed, 215 ins

[Intel-gfx] [PATCH i-g-t] tests/i915/perf_pmu: Fix allow hang handling

From: Tvrtko Ursulin Commit d7a74b959eea ("tests/i915/perf_pmu: Convert to intel_ctx_t (v3)") broke the test when it is run in its entirety. Correct context id needs to be used with igt_allow_hang to avoid context ban preventing the test to run to completion. Signed-off-by: Tvrtko Ursulin Fixe

Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline

On Thu, Jan 06, 2022 at 09:56:03AM +, Tvrtko Ursulin wrote: > > On 05/01/2022 16:24, Matthew Brost wrote: > > On Wed, Jan 05, 2022 at 09:35:44AM +, Tvrtko Ursulin wrote: > > > > > > On 04/01/2022 23:30, Matthew Brost wrote: > > > > Don't use the interruptable version of the timeline mutex

Re: [Intel-gfx] [PATCH v5 3/6] drm/i915: Don't pin the object pages during pending vma binds

On 04/01/2022 12:51, Thomas Hellström wrote: A pin-count is already held by vma->pages so taking an additional pin during async binds is not necessary. When we introduce async unbinding we have other means of keeping the object pages alive. Signed-off-by: Thomas Hellström Reviewed-by: Matthew

Re: [Intel-gfx] [PATCH v5 2/6] drm/i915: Use the vma resource as argument for gtt binding / unbinding

On 04/01/2022 12:51, Thomas Hellström wrote: When introducing asynchronous unbinding, the vma itself may no longer be alive when the actual binding or unbinding takes place. Update the gtt i915_vma_ops accordingly to take a struct i915_vma_resource instead of a struct i915_vma for the bind_vma()

Re: [Intel-gfx] [PATCH v5 1/6] drm/i915: Initial introduction of vma resources

On 04/01/2022 12:51, Thomas Hellström wrote: Introduce vma resources, sort of similar to TTM resources, needed for asynchronous bind management. Initially we will use them to hold completion of unbinding when we capture data from a vma, but they will be used extensively in upcoming patches for a

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Fix the PIPE_MISC 12 BPC PORT_OUTPUT for DG2

== Series Details == Series: drm/i915/display: Fix the PIPE_MISC 12 BPC PORT_OUTPUT for DG2 URL : https://patchwork.freedesktop.org/series/98551/ State : success == Summary == CI Bug Log - changes from CI_DRM_11052 -> Patchwork_21931 Summar

[Intel-gfx] [PATCH] drm/i915/display: Fix the PIPE_MISC 12 BPC PORT_OUTPUT for DG2

Currently 12 BPC PORT_OUTPUT_BPC bits are set in PIPE_MISC register for all Display > 12. DG2 is an exception. This patch tweaks the condition to read and write the above bits for DG2. Signed-off-by: Ankit Nautiyal --- drivers/gpu/drm/i915/display/intel_display.c | 8 1 file changed, 4

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/4] drm/i915: don't call free_mmap_offset when purging

== Series Details == Series: series starting with [v2,1/4] drm/i915: don't call free_mmap_offset when purging URL : https://patchwork.freedesktop.org/series/98548/ State : success == Summary == CI Bug Log - changes from CI_DRM_11052 -> Patchwork_21930 =

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/4] drm/i915: don't call free_mmap_offset when purging

== Series Details == Series: series starting with [v2,1/4] drm/i915: don't call free_mmap_offset when purging URL : https://patchwork.freedesktop.org/series/98548/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be chec

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/4] drm/i915: don't call free_mmap_offset when purging

== Series Details == Series: series starting with [v2,1/4] drm/i915: don't call free_mmap_offset when purging URL : https://patchwork.freedesktop.org/series/98548/ State : warning == Summary == $ dim checkpatch origin/drm-tip ce8969fa161a drm/i915: don't call free_mmap_offset when purging -:2

Re: [Intel-gfx] [PATCH v5 4/6] drm/i915: Use vma resources for async unbinding

On 04/01/2022 12:51, Thomas Hellström wrote: Implement async (non-blocking) unbinding by not syncing the vma before calling unbind on the vma_resource. Add the resulting unbind fence to the object's dma_resv from where it is picked up by the ttm migration code. Ideally these unbind fences should

Re: [Intel-gfx] [PATCH v4 2/6] drm: improve drm_buddy_alloc function

Hi Am 03.01.22 um 08:41 schrieb Christian König: Am 26.12.21 um 21:59 schrieb Arunpravin: Hi Thomas On 16/12/21 5:05 pm, Thomas Zimmermann wrote: Hi Am 01.12.21 um 17:39 schrieb Arunpravin: - Make drm_buddy_alloc a single function to handle     range allocation and non-range allocation de

[Intel-gfx] [PATCH v2 4/4] drm/i915/ttm: ensure we unmap when purging

Purging can happen during swapping out, or directly invoked with the madvise ioctl. In such cases this doesn't involve a ttm move, which skips umapping the object. v2(Thomas): - add ttm_truncate helper, and just call into i915_ttm_move_notify() to handle the unmapping step Fixes: cf3e3e86d779 (

[Intel-gfx] [PATCH v2 3/4] drm/i915/ttm: add unmap_virtual callback

Ensure we call ttm_bo_unmap_virtual when releasing the pages. Importantly this should now handle the ttm swapping case, and all other places that already call into i915_ttm_move_notify(). Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.") Signed-off-by: Matthew Auld Cc: Thomas

[Intel-gfx] [PATCH v2 2/4] drm/i915/ttm: only fault WILLNEED objects

Don't attempt to fault and re-populate purged objects. By some fluke this passes the dontneed-after-mmap IGT, but for the wrong reasons. Fixes: cf3e3e86d779 ("drm/i915: Use ttm mmap handling for ttm bo's.") Signed-off-by: Matthew Auld Cc: Thomas Hellström Reviewed-by: Thomas Hellström --- driv

[Intel-gfx] [PATCH v2 1/4] drm/i915: don't call free_mmap_offset when purging

The TTM backend is in theory the only user here(also purge should only be called once we have dropped the pages), where it is setup at object creation and is only removed once the object is destroyed. Also resetting the node here might be iffy since the ttm fault handler uses the stored fake offset

Re: [Intel-gfx] [PATCH] drm/i915: Lock timeline mutex directly in error path of eb_pin_timeline

On 05/01/2022 16:24, Matthew Brost wrote: On Wed, Jan 05, 2022 at 09:35:44AM +, Tvrtko Ursulin wrote: On 04/01/2022 23:30, Matthew Brost wrote: Don't use the interruptable version of the timeline mutex lock in the interruptible error path of eb_pin_timeline as the cleanup must always

Re: [Intel-gfx] [RFC 7/7] drm/i915/guc: Print the GuC error capture output register list.

On 05/01/2022 17:30, Teres Alexis, Alan Previn wrote: On Tue, 2022-01-04 at 13:56 +, Tvrtko Ursulin wrote: The flow of events are as below: 1. guc sends notification that an error capture was done and ready to take. - at this point we copy the guc error captured dump into an in

Re: [Intel-gfx] [PATCH 4/4] drm/i915: Enabling WD Transcoder

> > Adding support for writeback transcoder to start capturing frames using > > interrupt mechanism > > I stopped reviewing this after a while, because there's just way too > much unrelated noise in the patch to even be able to focus on what's > actually being done functionally here. There are som

Re: [Intel-gfx] [PATCH 3/4] drm/i915: Define WD trancoder for i915

> > Adding WD Types, WD transcoder to enum list and WD Transcoder offsets > > This should be part of the patch that uses them. Got it will squash this patch with the one using the above Thanks, Suraj Kandpal > > BR, > Jani.

Re: [Intel-gfx] [PATCH 2/4] drm/komeda: change driver to use drm_writeback_connector.base pointer

> Every commit should build and work on its own, so this makes me believe > the previous patch breaks the build. > Sure Jani will address this in the next set of patches Thanks, Suraj Kandpal

Re: [Intel-gfx] [PATCH 03/21] drm/i915: split out i915_gem_evict.h from i915_drv.h

On 05/01/2022 19:56, Jani Nikula wrote: We already have the i915_gem_evicti915.c file. There's a stray paste here and a few new headers got the 2021 copyright, but other than that it all looks fine to me. For the series: Acked-by: Tvrtko Ursulin (I actually scrolled through it all so per

Re: [Intel-gfx] [PATCH 1/4] drm: add writeback pointers to drm_connector

> > Adding drm_connector and drm_encoder pointers in > > drm_writeback_connector > > Why? The elements of struct drm_writeback_connector are struct drm_writeback_connector { Struct drm_connector base; Struct drm_encoder encoder; Similarly the elements of intel_encoder and intel_