[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Store DSC DPCD capabilities in the connector (rev9)

== Series Details == Series: drm/i915: Store DSC DPCD capabilities in the connector (rev9) URL : https://patchwork.freedesktop.org/series/124723/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13751_full -> Patchwork_124723v9_full

[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/3] drm/i915: make some error capture functions static (rev2)

== Series Details == Series: series starting with [1/3] drm/i915: make some error capture functions static (rev2) URL : https://patchwork.freedesktop.org/series/124993/ State : success == Summary == CI Bug Log - changes from CI_DRM_13749_full -> Patchwork_124993v2_full

[Intel-gfx] ✓ Fi.CI.BAT: success for Resolve suspend-resume racing with GuC destroy-context-worker (rev5)

== Series Details == Series: Resolve suspend-resume racing with GuC destroy-context-worker (rev5) URL : https://patchwork.freedesktop.org/series/121916/ State : success == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_121916v5

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Resolve suspend-resume racing with GuC destroy-context-worker (rev5)

== Series Details == Series: Resolve suspend-resume racing with GuC destroy-context-worker (rev5) URL : https://patchwork.freedesktop.org/series/121916/ 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.IGT: failure for drm/i915: stop including i915_utils.h from intel_runtime_pm.h (rev2)

== Series Details == Series: drm/i915: stop including i915_utils.h from intel_runtime_pm.h (rev2) URL : https://patchwork.freedesktop.org/series/124989/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13749_full -> Patchwork_124989v2_full

[Intel-gfx] [PATCH v5 2/3] drm/i915/guc: Close deregister-context race against CT-loss

If we are at the end of suspend or very early in resume its possible an async fence signal (via rcu_call) is triggered to free_engines which could lead us to the execution of the context destruction worker (after a prior worker flush). Thus, when suspending, insert rcu_barriers at the start of

[Intel-gfx] [PATCH v5 0/3] Resolve suspend-resume racing with GuC destroy-context-worker

This series is the result of debugging issues root caused to races between the GuC's destroyed_worker_func being triggered vs repeating suspend-resume cycles with concurrent delayed fence signals for engine-freeing. The reproduction steps require that an app is launched right before the start of

[Intel-gfx] [PATCH v5 1/3] drm/i915/guc: Flush context destruction worker at suspend

When suspending, flush the context-guc-id deregistration worker at the final stages of intel_gt_suspend_late when we finally call gt_sanitize that eventually leads down to __uc_sanitize so that the deregistration worker doesn't fire off later as we reset the GuC microcontroller. Signed-off-by:

[Intel-gfx] [PATCH v5 3/3] drm/i915/gt: Timeout when waiting for idle in suspending

When suspending, add a timeout when calling intel_gt_pm_wait_for_idle else if we have a lost G2H event that holds a wakeref (which would be indicative of a bug elsewhere in the driver), driver will at least complete the suspend-resume cycle, (albeit not hitting all the targets for low power hw

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for fix DRM_USE_DYNAMIC_DEBUG=y regression (rev3)

== Series Details == Series: fix DRM_USE_DYNAMIC_DEBUG=y regression (rev3) URL : https://patchwork.freedesktop.org/series/125063/ 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 fix DRM_USE_DYNAMIC_DEBUG=y regression (rev3)

== Series Details == Series: fix DRM_USE_DYNAMIC_DEBUG=y regression (rev3) URL : https://patchwork.freedesktop.org/series/125063/ State : warning == Summary == Error: dim checkpatch failed df3a4914f745 test-dyndbg: fixup CLASSMAP usage error c097f28a3829 dyndbg: reword "class unknown, " to

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/gt: Temporarily force MTL into uncached mode (rev4)

== Series Details == Series: drm/i915/gt: Temporarily force MTL into uncached mode (rev4) URL : https://patchwork.freedesktop.org/series/124866/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13749_full -> Patchwork_124866v4_full

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Define and use GuC and CTB TLB invalidation routines

== Series Details == Series: drm/i915: Define and use GuC and CTB TLB invalidation routines URL : https://patchwork.freedesktop.org/series/125136/ State : success == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125136v1

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Define and use GuC and CTB TLB invalidation routines

== Series Details == Series: drm/i915: Define and use GuC and CTB TLB invalidation routines URL : https://patchwork.freedesktop.org/series/125136/ 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: Define and use GuC and CTB TLB invalidation routines

== Series Details == Series: drm/i915: Define and use GuC and CTB TLB invalidation routines URL : https://patchwork.freedesktop.org/series/125136/ State : warning == Summary == Error: dim checkpatch failed 81011600b839 drm/i915: Add GuC TLB Invalidation device info flags 509d175695bb

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: DPLL code cleanups (rev2)

== Series Details == Series: drm/i915: DPLL code cleanups (rev2) URL : https://patchwork.freedesktop.org/series/125052/ State : success == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125052v2 Summary ---

[Intel-gfx] [PATCH v7b 20/25] dyndbg: add _DPRINTK_FLAGS_INCL_LOOKUP

dyndbg's dynamic prefixing (by +tmfsl flags) is needlessly expensive. When an enabled (with +p) pr_debug is called, _DPRINTK_FLAGS_INCL_ANY prefix decorations are sprintf'd into stack-mem for every call. This string (or part of it) could be cached once its 1st generated, and retrieved

[Intel-gfx] [PATCH v7b 25/25] drm: restore CONFIG_DRM_USE_DYNAMIC_DEBUG un-BROKEN

Lots of burn-in testing needed before signing, upstreaming. NOTE: I set default Y to maximize testing by default. Is there a better way to do this ? Signed-off-by: Jim Cromie --- drivers/gpu/drm/Kconfig | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git

[Intel-gfx] [PATCH v7b 23/25] drm: use correct ccflags-y spelling

Incorrectly spelled CFLAGS- failed to add -DDYNAMIC_DEBUG_MODULE, which broke builds with: CONFIG_DRM_USE_DYNAMIC_DEBUG=y CONFIG_DYNAMIC_DEBUG_CORE=y CONFIG_DYNAMIC_DEBUG=n Also add subdir-ccflags so that all drivers pick up the addition. Fixes: 84ec67288c10 ("drm_print: wrap drm_*_dbg in

[Intel-gfx] [PATCH v7b 22/25] dyndbg: change WARN_ON to WARN_ON_ONCE

This shouldn't ever happen, and 1st 2 conditions never have. The 3rd condition did happen, due to corrupt linkage due to a missing align(8) in DYNDBG_CLASSMAP_USE, on the static struct allocation into the __dyndbg_class_users section. Not sure whether changing to _ONCE is appropriate - this is a

[Intel-gfx] [PATCH v7b 19/25] dyndbg: reserve flag bit _DPRINTK_FLAGS_PREFIX_CACHED

Reserve bit 7 to remember that a pr-debug callsite is/was: - enabled, with +p - wants a dynamic-prefix, with one+ of module:function:sourcfile - was previously called - was thus saved in the cache. NOT YET. Its unclear whether any cache fetch would be faster than 2-3 field fetches, but theres

[Intel-gfx] [PATCH v7b 24/25] drm-drivers: DRM_CLASSMAP_USE in 2nd batch of drivers, helpers

Add a DRM_CLASSMAP_USE declaration to 2nd batch of helpers and *_drv.c files. For drivers, add the decl just above the module's PARAMs, since it identifies the "inherited" drm.debug param. Note: with CONFIG_DRM_USE_DYNAMIC_DEBUG=y, a module not also declaring DRM_CLASSMAP_USE will have its

[Intel-gfx] [PATCH v7b 21/25] dyndbg: refactor *dynamic_emit_prefix

Refactor the split of duties between outer & inner fns. The outer fn was previously just an inline unlikely forward to inner, which did all the work. Now, outer handles +t and +l flags itself, and calls inner only when _DPRINTK_FLAGS_INCL_LOOKUP is needed. No functional change. But it does

[Intel-gfx] [PATCH v7b 14/25] dyndbg-API: fix CONFIG_DRM_USE_DYNAMIC_DEBUG regression

DECLARE_DYNDBG_CLASSMAP() has a design error; it fails a basic K rule: "define once, refer many times". When DRM_USE_DYNAMIC_DEBUG=y, DECLARE_DYNDBG_CLASSMAP() is used across DRM core & drivers; they all repeat the same classmap-defn args, which must match for the modules to respond together when

[Intel-gfx] [PATCH v7b 18/25] dyndbg-doc: add classmap info to howto

Add some basic info on classmap usage and api cc: linux-...@vger.kernel.org Signed-off-by: Jim Cromie --- v5- adjustments per Randy Dunlap, me v7b- checkpatch fixes --- .../admin-guide/dynamic-debug-howto.rst | 60 ++- 1 file changed, 59 insertions(+), 1 deletion(-) diff

[Intel-gfx] [PATCH v7b 16/25] dyndbg: refactor ddebug_classparam_clamp_input

Extract input validation code, from param_set_dyndbg_module_classes() (the sys-node >handler) to new: ddebug_classparam_clamp_input(kp), call it from former. It takes kernel-param arg, so it can complain about "foo: bad input". Reuse ddparam_clamp_input(kp) in ddebug_sync_classbits(), to

[Intel-gfx] [PATCH v7b 15/25] dyndbg: add for_each_boxed_vector

Add a for_each iterator to walk a counted vector member in a struct (ie the box), and use it to replace 8 open-coded loops. Signed-off-by: Jim Cromie --- v5- parens-on-box-force-precedence --- lib/dynamic_debug.c | 20 +++- 1 file changed, 11 insertions(+), 9 deletions(-) diff

[Intel-gfx] [PATCH v7b 17/25] dyndbg-API: promote DYNDBG_CLASSMAP_PARAM to API

move the DYNDBG_CLASSMAP_PARAM macro from test-dynamic-debug.c into the header, and refine it, by distinguishing the 2 use cases: 1.DYNDBG_CLASSMAP_PARAM_REF for DRM, to pass in extern __drm_debug by name. dyndbg keeps bits in it, so drm can still use it as before 2.DYNDBG_CLASSMAP_PARAM

[Intel-gfx] [PATCH v7b 10/25] dyndbg: tighten ddebug_class_name() 1st arg type

Change function's 1st arg-type, and deref in the caller. The fn doesn't need any other fields in the struct. no functional change. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/lib/dynamic_debug.c

[Intel-gfx] [PATCH v7b 12/25] dyndbg: reduce verbose=3 messages in ddebug_add_module

The fn currently says "add-module", then "skipping" if the module has no prdbgs. Just check 1st and return quietly. no functional change Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/lib/dynamic_debug.c

[Intel-gfx] [PATCH v7b 13/25] dyndbg-API: remove DD_CLASS_TYPE_(DISJOINT|LEVEL)_NAMES and code

Remove the NAMED class types; these 2 classmap types accept class names at the PARAM interface, for example: echo +DRM_UT_CORE,-DRM_UT_KMS > /sys/module/drm/parameters/debug_names The code works, but its only used by test-dynamic-debug, and wasn't asked for by anyone else, so simplify things

[Intel-gfx] [PATCH v7b 11/25] dyndbg: tighten fn-sig of ddebug_apply_class_bitmap

old_bits arg is currently a pointer to the input bits, but this could allow inadvertent changes to the input by the fn. Disallow this. And constify new_bits while here. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 21 +++-- 1 file changed, 11 insertions(+), 10

[Intel-gfx] [PATCH v7b 08/25] dyndbg: reduce verbose/debug clutter

currently, for verbose=3, these are logged (blank lines for clarity): dyndbg: query 0: "class DRM_UT_CORE +p" mod:* dyndbg: split into words: "class" "DRM_UT_CORE" "+p" dyndbg: op='+' dyndbg: flags=0x1 dyndbg: *flagsp=0x1 *maskp=0x dyndbg: parsed: func="" file="" module=""

[Intel-gfx] [PATCH v7b 07/25] dyndbg: drop NUM_TYPE_ARRAY

ARRAY_SIZE works here, since array decl is complete. no functional change Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/include/linux/dynamic_debug.h b/include/linux/dynamic_debug.h index

[Intel-gfx] [PATCH v7b 09/25] dyndbg: silence debugs with no-change updates

check for actual changes before announcing them, declutter logs. Signed-off-by: Jim Cromie --- lib/dynamic_debug.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/lib/dynamic_debug.c b/lib/dynamic_debug.c index b0e11f6bfaa2..b07aab422604 100644 ---

[Intel-gfx] [PATCH v7b 06/25] dyndbg: split param_set_dyndbg_classes to module/wrapper fns

rename param_set_dyndbg_classes: add _module_ name & arg, old name is wrapper to new. New arg allows caller to specify that only one module is affected by a prdbgs update. Outer fn preserves kernel_param interface, passing NULL to inner fn. This selectivity will be used later to narrow the scope

[Intel-gfx] [PATCH v7b 04/25] dyndbg: replace classmap list with a vector

Classmaps are stored/linked in a section/array, but are each added to the module's ddebug_table.maps list-head. This is unnecessary; even when ddebug_attach_classmap() is handling the builtin section (with classmaps for multiple builtin modules), its contents are ordered, so a module's possibly

[Intel-gfx] [PATCH v7b 03/25] dyndbg: make ddebug_class_param union members same size

struct ddebug_class_param keeps a ref to the state-storage of the param, make both flavors use the same unsigned long under-type. ISTM this is simpler and safer. Signed-off-by: Jim Cromie --- include/linux/dynamic_debug.h | 2 +- lib/dynamic_debug.c | 2 +- 2 files changed, 2

[Intel-gfx] [PATCH v7b 05/25] dyndbg: ddebug_apply_class_bitmap - add module arg, select on it

Add query_module param to ddebug_apply_class_bitmap(). This allows its caller to update just one module, or all (as currently). We'll use this later to propagate drm.debug to each USEr as they're modprobed. No functional change. Signed-off-by: Jim Cromie --- after `modprobe i915`, heres the

[Intel-gfx] [PATCH v7b 01/25] test-dyndbg: fixup CLASSMAP usage error

more careful reading of test output reveals: lib/test_dynamic_debug.c:103 [test_dynamic_debug]do_cats =pmf "doing categories\n" lib/test_dynamic_debug.c:105 [test_dynamic_debug]do_cats =p "LOW msg\n" class:MID lib/test_dynamic_debug.c:106 [test_dynamic_debug]do_cats =p "MID msg\n" class:HI

[Intel-gfx] [PATCH v7b 02/25] dyndbg: reword "class unknown, " to "class:_UNKNOWN_"

This appears in the control-file to report an unknown class-name, which indicates that the class_id is not authorized, and dyndbg will ignore changes to it. Generally, this means that a DYNDBG_CLASSMAP_DEFINE or DYNDBG_CLASSMAP_USE is missing. But the word "unknown" appears in quite a few prdbg

[Intel-gfx] [PATCH v7b 00/25] fix DRM_USE_DYNAMIC_DEBUG=y regression

hi Jason, DRM-folk (now with checkpatch fixes) This patchest fixes the chicken-egg initialization problem in the 1st version of ddebug-class-maps, that DRM-CI uncovered. The root-problem was DECLARE_DYNDBG_CLASSMAP, which broke the K rule: "define once, refer many". In patch 14 it is replaced

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: DPLL code cleanups (rev2)

== Series Details == Series: drm/i915: DPLL code cleanups (rev2) URL : https://patchwork.freedesktop.org/series/125052/ 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.IGT: failure for Frontbuffer tracking preparing for Xe (rev2)

== Series Details == Series: Frontbuffer tracking preparing for Xe (rev2) URL : https://patchwork.freedesktop.org/series/125033/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13749_full -> Patchwork_125033v2_full Summary

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Move the g45 PEG band gap HPD workaround to the HPD code (rev2)

== Series Details == Series: drm/i915: Move the g45 PEG band gap HPD workaround to the HPD code (rev2) URL : https://patchwork.freedesktop.org/series/125053/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125053v2

[Intel-gfx] [PATCH v15 4/7] drm/i915: No TLB invalidation on suspended GT

In case of GT is suspended, don't allow submission of new TLB invalidation request and cancel all pending requests. The TLB entries will be invalidated either during GuC reload or on system resume. Signed-off-by: Fei Yang Signed-off-by: Jonathan Cavitt CC: John Harrison Reviewed-by: Andi Shyti

[Intel-gfx] [PATCH v15 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

From: Prathap Kumar Valsan The GuC firmware had defined the interface for Translation Look-Aside Buffer (TLB) invalidation. We should use this interface when invalidating the engine and GuC TLBs. Add additional functionality to intel_gt_invalidate_tlb, invalidating the GuC TLBs and falling back

[Intel-gfx] [PATCH v15 5/7] drm/i915: No TLB invalidation on wedged GT

It is not an error for GuC TLB invalidations to fail when the GT is wedged or disabled, so do not process a wait failure as one in guc_send_invalidate_tlb. Signed-off-by: Fei Yang Signed-off-by: Jonathan Cavitt CC: John Harrison Reviewed-by: Andi Shyti Acked-by: Tvrtko Ursulin Acked-by:

[Intel-gfx] [PATCH v15 1/7] drm/i915: Add GuC TLB Invalidation device info flags

Add device info flags for if GuC TLB Invalidation is enabled. Signed-off-by: Jonathan Cavitt Reviewed-by: Andi Shyti Acked-by: Tvrtko Ursulin Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_device_info.h | 1 + 2 files changed, 3

[Intel-gfx] [PATCH v15 6/7] drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck

For the gt_tlb live selftest, when operating on the GSC engine, increase the timeout from 10 ms to 200 ms because the GSC engine is a bit slower than the rest. Signed-off-by: Jonathan Cavitt Reviewed-by: Andi Shyti Acked-by: Tvrtko Ursulin Reviewed-by: Nirmoy Das ---

[Intel-gfx] [PATCH v15 7/7] drm/i915: Enable GuC TLB invalidations for MTL

Enable GuC TLB invalidations for MTL. Though more platforms than just MTL support GuC TLB invalidations, MTL is presently the only platform that requires it for any purpose, so only enable it there for now to minimize cross-platform impact. Signed-off-by: Jonathan Cavitt Reviewed-by: Andi Shyti

[Intel-gfx] [PATCH v15 2/7] drm/i915/guc: Add CT size delay helper

As of now, there is no mechanism for tracking a given request's progress through the queue. Instead, add a helper that returns an estimated maximum time the queue should take to drain if completely full. Suggested-by: John Harrison Signed-off-by: Jonathan Cavitt Reviewed-by: Andi Shyti

[Intel-gfx] [PATCH v15 0/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

Implement GuC-based TLB invalidations and use them on MTL. Some complexity in the implementation was introduced early on and will be required for range-based TLB invalidations. RFC: https://patchwork.freedesktop.org/series/124922/ v2: - Add missing supporting patches. v3: - Split suspend/resume

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bios: Clamp VBT HDMI level shift on BDW

== Series Details == Series: drm/i915/bios: Clamp VBT HDMI level shift on BDW URL : https://patchwork.freedesktop.org/series/125120/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125120v1 Summary ---

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Flush WC GGTT only on required platforms (rev2)

== Series Details == Series: drm/i915: Flush WC GGTT only on required platforms (rev2) URL : https://patchwork.freedesktop.org/series/125111/ State : success == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125111v2

Re: [Intel-gfx] [PATCH] drm/i915/gem: Allow users to disable waitboost

On Thu, Sep 28, 2023 at 01:48:34PM +0100, Tvrtko Ursulin wrote: > > On 27/09/2023 20:34, Belgaumkar, Vinay wrote: > > > > On 9/21/2023 3:41 AM, Tvrtko Ursulin wrote: > > > > > > On 20/09/2023 22:56, Vinay Belgaumkar wrote: > > > > Provide a bit to disable waitboost while waiting on a gem

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix LUT rounding

== Series Details == Series: drm/i915: Fix LUT rounding URL : https://patchwork.freedesktop.org/series/125116/ State : success == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_125116v1 Summary --- **SUCCESS** No

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix LUT rounding

== Series Details == Series: drm/i915: Fix LUT rounding URL : https://patchwork.freedesktop.org/series/125116/ 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: Fix LUT rounding

== Series Details == Series: drm/i915: Fix LUT rounding URL : https://patchwork.freedesktop.org/series/125116/ State : warning == Summary == Error: dim checkpatch failed e6e1f586ce6d drm: Fix color LUT rounding b3b1eb0a523e drm/i915: Adjust LUT rounding rules a0073c74c274 drm/i915:

Re: [Intel-gfx] [PATCH v2] drm/i915/display: Reset message bus after each read/write operation

On Fri, Oct 13, 2023 at 09:55:32AM +0300, Mika Kahola wrote: > Every know and then we receive the following error when running > for example IGT test kms_flip. > > [drm] *ERROR* PHY G Read 0d80 failed after 3 retries. > [drm] *ERROR* PHY G Write 0d81 failed after 3 retries. > > Since the error

Re: [Intel-gfx] [PATCH v14 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

Hi John, ... > > @@ -560,6 +562,17 @@ static int __uc_init_hw(struct intel_uc *uc) > > guc_info(guc, "submission %s\n", > > str_enabled_disabled(intel_uc_uses_guc_submission(uc))); > > guc_info(guc, "SLPC %s\n", > > str_enabled_disabled(intel_uc_uses_guc_slpc(uc))); > > + /* > > +

Re: [Intel-gfx] [PATCH v14 0/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

On 10/13/2023 10:52, Jonathan Cavitt wrote: Implement GuC-based TLB invalidations and use them on MTL. Some complexity in the implementation was introduced early on and will be required for range-based TLB invalidations. RFC: https://patchwork.freedesktop.org/series/124922/ v2: - Add

Re: [Intel-gfx] [PATCH v14 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

On 10/13/2023 10:52, Jonathan Cavitt wrote: From: Prathap Kumar Valsan The GuC firmware had defined the interface for Translation Look-Aside Buffer (TLB) invalidation. We should use this interface when invalidating the engine and GuC TLBs. Add additional functionality to

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Prevent potential null-ptr-deref in engine_init_common (rev4)

== Series Details == Series: drm/i915: Prevent potential null-ptr-deref in engine_init_common (rev4) URL : https://patchwork.freedesktop.org/series/124971/ State : success == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_124971v4

Re: [Intel-gfx] [PATCH v13 4/7] drm/i915: No TLB invalidation on suspended GT

On 10/13/2023 12:12, John Harrison wrote: On 10/13/2023 07:42, Cavitt, Jonathan wrote: -Original Message- From: Harrison, John C Sent: Thursday, October 12, 2023 6:08 PM To: Cavitt, Jonathan ; intel-gfx@lists.freedesktop.org Cc: Gupta, saurabhg ; chris.p.wil...@linux.intel.com;

Re: [Intel-gfx] [PATCH v13 4/7] drm/i915: No TLB invalidation on suspended GT

On 10/13/2023 07:42, Cavitt, Jonathan wrote: -Original Message- From: Harrison, John C Sent: Thursday, October 12, 2023 6:08 PM To: Cavitt, Jonathan ; intel-gfx@lists.freedesktop.org Cc: Gupta, saurabhg ; chris.p.wil...@linux.intel.com; Iddamsetty, Aravind ; Yang, Fei ; Shyti, Andi ;

Re: [Intel-gfx] [PATCH v13 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

On 10/13/2023 07:52, Cavitt, Jonathan wrote: -Original Message- From: Harrison, John C Sent: Thursday, October 12, 2023 6:11 PM To: Cavitt, Jonathan ; intel-gfx@lists.freedesktop.org Cc: Gupta, saurabhg ; chris.p.wil...@linux.intel.com; Iddamsetty, Aravind ; Yang, Fei ; Shyti, Andi ;

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: Reset message bus after each read/write operation (rev2)

== Series Details == Series: drm/i915/display: Reset message bus after each read/write operation (rev2) URL : https://patchwork.freedesktop.org/series/124602/ State : success == Summary == CI Bug Log - changes from CI_DRM_13754 -> Patchwork_124602v2

Re: [Intel-gfx] [PATCH] tests: save GPU engine information more properly

Hi Shawn, without the i-g-t tag in the title this path was picked up by the kernel's patchwork. Can you please use the [PATCH i-g-t] tag? On Fri, Oct 13, 2023 at 12:20:12PM +0800, Lee Shawn C wrote: > We encounter a unexpected error on chrome book device while > running kms_busy test. It will

[Intel-gfx] [CI] PR for new GuC v70.13.1

The following changes since commit 7727f7e3b3358713c7c91c64a835e80c331a6b8b: Merge branch 'patch-1696561325' into 'main' (2023-10-06 03:04:57 +) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware guc_70.13.1 for you to fetch changes up to

[Intel-gfx] [PATCH v14 6/7] drm/i915/gt: Increase sleep in gt_tlb selftest sanitycheck

For the gt_tlb live selftest, when operating on the GSC engine, increase the timeout from 10 ms to 200 ms because the GSC engine is a bit slower than the rest. Signed-off-by: Jonathan Cavitt Reviewed-by: Andi Shyti Acked-by: Tvrtko Ursulin Reviewed-by: Nirmoy Das ---

[Intel-gfx] [PATCH v14 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

From: Prathap Kumar Valsan The GuC firmware had defined the interface for Translation Look-Aside Buffer (TLB) invalidation. We should use this interface when invalidating the engine and GuC TLBs. Add additional functionality to intel_gt_invalidate_tlb, invalidating the GuC TLBs and falling back

[Intel-gfx] [PATCH v14 4/7] drm/i915: No TLB invalidation on suspended GT

In case of GT is suspended, don't allow submission of new TLB invalidation request and cancel all pending requests. The TLB entries will be invalidated either during GuC reload or on system resume. Signed-off-by: Fei Yang Signed-off-by: Jonathan Cavitt CC: John Harrison Reviewed-by: Andi Shyti

[Intel-gfx] [PATCH v14 7/7] drm/i915: Enable GuC TLB invalidations for MTL

Enable GuC TLB invalidations for MTL. Though more platforms than just MTL support GuC TLB invalidations, MTL is presently the only platform that requires it for any purpose, so only enable it there for now to minimize cross-platform impact. Signed-off-by: Jonathan Cavitt Reviewed-by: Andi Shyti

[Intel-gfx] [PATCH v14 2/7] drm/i915/guc: Add CT size delay helper

As of now, there is no mechanism for tracking a given request's progress through the queue. Instead, add a helper that returns an estimated maximum time the queue should take to drain if completely full. Suggested-by: John Harrison Signed-off-by: Jonathan Cavitt Reviewed-by: Andi Shyti

[Intel-gfx] [PATCH v14 0/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

Implement GuC-based TLB invalidations and use them on MTL. Some complexity in the implementation was introduced early on and will be required for range-based TLB invalidations. RFC: https://patchwork.freedesktop.org/series/124922/ v2: - Add missing supporting patches. v3: - Split suspend/resume

[Intel-gfx] [PATCH v14 5/7] drm/i915: No TLB invalidation on wedged GT

It is not an error for GuC TLB invalidations to fail when the GT is wedged or disabled, so do not process a wait failure as one in guc_send_invalidate_tlb. Signed-off-by: Fei Yang Signed-off-by: Jonathan Cavitt CC: John Harrison Reviewed-by: Andi Shyti Acked-by: Tvrtko Ursulin Acked-by:

[Intel-gfx] [PATCH v14 1/7] drm/i915: Add GuC TLB Invalidation device info flags

Add device info flags for if GuC TLB Invalidation is enabled. Signed-off-by: Jonathan Cavitt Reviewed-by: Andi Shyti Acked-by: Tvrtko Ursulin Reviewed-by: Nirmoy Das --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_device_info.h | 1 + 2 files changed, 3

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Add bigjoiner force enable option to debugfs (rev3)

== Series Details == Series: drm/i915: Add bigjoiner force enable option to debugfs (rev3) URL : https://patchwork.freedesktop.org/series/124730/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13747_full -> Patchwork_124730v3_full

Re: [Intel-gfx] [PATCH] drm/i915: Flush WC GGTT only on required platforms

On Fri, Oct 13, 2023 at 02:28:21PM +0200, Nirmoy Das wrote: > Hi Ville, > > On 10/13/2023 12:50 PM, Ville Syrjälä wrote: > > On Fri, Oct 13, 2023 at 12:31:40PM +0200, Nirmoy Das wrote: > > > gen8_ggtt_invalidate() is only needed for limitted set of platforms > > > where GGTT is mapped as WC > > I

Re: [Intel-gfx] [PATCH v2] drm/i915: Flush WC GGTT only on required platforms

On Fri, Oct 13, 2023 at 03:44:39PM +0200, Nirmoy Das wrote: > gen8_ggtt_invalidate() is only needed for limited set of platforms > where GGTT is mapped as WC otherwise this can cause unwanted > side-effects on XE_HP platforms where GFX_FLSH_CNTL_GEN6 is not > valid. > > v2: Add a func to detect

[Intel-gfx] Buggy graphics on 82G33/G31.

https://media.discordapp.com/attachments/697112906457677914/1161753753993621505/image.png Has somebody ever experienced such issue on a 82G33/G31 GPU? This issue happens on Windows too. It's more aggressive (in the sense it's more prone to happen) on Linux, though. Strangely, I've never found

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Clean up zero initializers

== Series Details == Series: drm/i915: Clean up zero initializers URL : https://patchwork.freedesktop.org/series/125050/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13746_full -> Patchwork_125050v1_full Summary ---

Re: [Intel-gfx] [PATCH v13 3/7] drm/i915: Define and use GuC and CTB TLB invalidation routines

-Original Message- From: Harrison, John C Sent: Thursday, October 12, 2023 6:11 PM To: Cavitt, Jonathan ; intel-gfx@lists.freedesktop.org Cc: Gupta, saurabhg ; chris.p.wil...@linux.intel.com; Iddamsetty, Aravind ; Yang, Fei ; Shyti, Andi ; Das, Nirmoy ; Krzysztofik, Janusz ; Roper,

Re: [Intel-gfx] [PATCH v13 4/7] drm/i915: No TLB invalidation on suspended GT

-Original Message- From: Harrison, John C Sent: Thursday, October 12, 2023 6:08 PM To: Cavitt, Jonathan ; intel-gfx@lists.freedesktop.org Cc: Gupta, saurabhg ; chris.p.wil...@linux.intel.com; Iddamsetty, Aravind ; Yang, Fei ; Shyti, Andi ; Das, Nirmoy ; Krzysztofik, Janusz ; Roper,

Re: [Intel-gfx] Regression in linux-next

Hello Rafael, > -Original Message- > From: Borah, Chaitanya Kumar > Sent: Wednesday, October 11, 2023 10:19 PM > To: Wysocki, Rafael J > Cc: intel-gfx@lists.freedesktop.org; Kurmi, Suresh Kumar > ; Saarinen, Jani > Subject: RE: Regression in linux-next > > Hello Rafael, > > >

[Intel-gfx] [PATCH] drm/i915/bios: Clamp VBT HDMI level shift on BDW

From: Ville Syrjälä Apparently some BDW machines (eg. HP Pavilion 15-ab) shipped with a VBT inherited from some earlier HSW model. On HSW the HDMI level shift value could go up to 11, whereas on BDW the maximum value is 9. The DDI code does clamp the bogus value, but it does so with a WARN

Re: [Intel-gfx] [PATCH 2/4] drm/i915/dsb: Correct DSB command buffer cache coherency settings

On Thu, Oct 12, 2023 at 09:40:23PM +, Shankar, Uma wrote: > > > > -Original Message- > > From: Intel-gfx On Behalf Of Ville > > Syrjala > > Sent: Monday, October 9, 2023 6:52 PM > > To: intel-gfx@lists.freedesktop.org > > Subject: [Intel-gfx] [PATCH 2/4] drm/i915/dsb: Correct DSB

[Intel-gfx] [PATCH v2] drm/i915: Flush WC GGTT only on required platforms

gen8_ggtt_invalidate() is only needed for limited set of platforms where GGTT is mapped as WC otherwise this can cause unwanted side-effects on XE_HP platforms where GFX_FLSH_CNTL_GEN6 is not valid. v2: Add a func to detect wc ggtt detection (Ville) Fixes: d2eae8e98d59 ("drm/i915/dg2: Drop

Re: [Intel-gfx] [PATCH v2] debugobjects: stop accessing objects after releasing spinlock

On Mon, Sep 25 2023 at 15:13, Andrzej Hajda wrote: > After spinlock release object can be modified/freed by concurrent thread. > Using it in such case is error prone, even for printing object state. It cannot be freed. If that happens then the calling code will have an UAF problem on the tracked

[Intel-gfx] [PATCH 4/4] drm/i915: Fix glk+ degamma LUT conversions

From: Ville Syrjälä The current implementation of change_lut_val_precision() is just a convoluted way of shifting by 8. Implement the proper rounding by just using drm_color_lut_extract() and intel_color_lut_pack() like everyone else does. And as the uapi can't handle >=1.0 values but the

[Intel-gfx] [PATCH 3/4] drm/i915: s/clamp()/min()/ in i965_lut_11p6_max_pack()

From: Ville Syrjälä Use min() instead of clamp() since the color values involved are unsigned. No functional changes. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [PATCH 2/4] drm/i915: Adjust LUT rounding rules

From: Ville Syrjälä drm_color_lut_extract() rounding was changed to follow the OpenGL int<->float conversion rules. Adjust intel_color_lut_pack() to match. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 14 ++ 1 file changed, 6 insertions(+), 8

[Intel-gfx] [PATCH 1/4] drm: Fix color LUT rounding

From: Ville Syrjälä The current implementation of drm_color_lut_extract() generates weird results. Eg. if we go through all the values for 16->8bpc conversion we see the following pattern: inout (count) 0 - 7f -> 0 (128) 80 - 17f -> 1 (256) 180 - 27f -> 2 (256) 280 -

[Intel-gfx] [PATCH 0/4] drm/i915: Fix LUT rounding

From: Ville Syrjälä The current LUT rounding is generating weird results. Adjust it to follow the OpenGL int<->float conversion rules. Ville Syrjälä (4): drm: Fix color LUT rounding drm/i915: Adjust LUT rounding rules drm/i915: s/clamp()/min()/ in i965_lut_11p6_max_pack() drm/i915: Fix

Re: [Intel-gfx] [PATCH] drm/i915: Flush WC GGTT only on required platforms

On 10/13/2023 2:55 PM, Ville Syrjälä wrote: On Fri, Oct 13, 2023 at 02:28:21PM +0200, Nirmoy Das wrote: Hi Ville, On 10/13/2023 12:50 PM, Ville Syrjälä wrote: On Fri, Oct 13, 2023 at 12:31:40PM +0200, Nirmoy Das wrote: gen8_ggtt_invalidate() is only needed for limitted set of platforms

Re: [Intel-gfx] [PATCH] drm/i915: Flush WC GGTT only on required platforms

On Fri, Oct 13, 2023 at 02:28:21PM +0200, Nirmoy Das wrote: > Hi Ville, > > On 10/13/2023 12:50 PM, Ville Syrjälä wrote: > > On Fri, Oct 13, 2023 at 12:31:40PM +0200, Nirmoy Das wrote: > >> gen8_ggtt_invalidate() is only needed for limitted set of platforms > >> where GGTT is mapped as WC > > I

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Remove the modparam verbose_state_checks

== Series Details == Series: drm/i915: Remove the modparam verbose_state_checks URL : https://patchwork.freedesktop.org/series/125047/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13746_full -> Patchwork_125047v1_full

Re: [Intel-gfx] [PATCH] drm/i915: Flush WC GGTT only on required platforms

Hi Ville, On 10/13/2023 12:50 PM, Ville Syrjälä wrote: On Fri, Oct 13, 2023 at 12:31:40PM +0200, Nirmoy Das wrote: gen8_ggtt_invalidate() is only needed for limitted set of platforms where GGTT is mapped as WC I know there is supposed to be some kind hw snooping of the ggtt pte writes to

Re: [Intel-gfx] [PATCH] drm/i915: Retry gtt fault when out of fence register

Hi Ville, > If we can't find a free fence register to handle a fault in the GMADR > range just return VM_FAULT_NOPAGE without populating the PTE so that > userspace will retry the access and trigger another fault. Eventually > we should find a free fence and the fault will get properly handled. >

  1   2   >