[Intel-gfx] ✗ Fi.CI.SPARSE: warning for lib/string_helpers: Add a few string helpers

== Series Details == Series: lib/string_helpers: Add a few string helpers URL : https://patchwork.freedesktop.org/series/99030/ 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 lib/string_helpers: Add a few string helpers

== Series Details == Series: lib/string_helpers: Add a few string helpers URL : https://patchwork.freedesktop.org/series/99030/ State : warning == Summary == $ dim checkpatch origin/drm-tip 034eadde40c9 lib/string_helpers: Consolidate yesno() implementation 89d43a829163 lib/string_helpers: Add

[Intel-gfx] [PATCH 2/3] lib/string_helpers: Add helpers for enable[d]/disable[d]

Follow the yes/no logic and add helpers for enabled/disabled and enable/disable - those are not so common throughout the kernel, but they give a nice way to reuse the strings to log things as enabled/disabled or enable/disable. Signed-off-by: Lucas De Marchi --- drivers/gpu/drm/i915/i915_utils.h

[Intel-gfx] [PATCH 3/3] drm: Convert open yes/no strings to yesno()

linux/string_helpers.h provides a helper to return "yes"/"no" strings. Replace the open coded versions with yesno(). The places were identified with the following semantic patch: @@ expression b; @@ - b ? "yes" : "no" + yesno(b) Then the includes were adde

[Intel-gfx] [PATCH 0/3] lib/string_helpers: Add a few string helpers

Add some helpers under lib/string_helpers.h so they can be used throughout the kernel. When I started doing this there were 2 other previous attempts I know of, not counting the iterations each of them had: 1) https://lore.kernel.org/all/20191023131308.9420-1-jani.nik...@intel.com/ 2) https://lor

[Intel-gfx] [PATCH 1/3] lib/string_helpers: Consolidate yesno() implementation

There are a few implementations of yesno() in the tree. Consolidate them in include/linux/string_helpers.h. Quite a few users of open coded yesno() could later be converted to the new function: $ git grep '?\s*"yes"\s*' | wc -l 286 $ git grep '?\s*"no"\s*' | wc -l 20 The inlined function should

Re: [Intel-gfx] [PATCH v3 2/2] drm/i915/gt: make a gt sysfs group and move power management files

Quoting Tvrtko Ursulin (2022-01-17 18:02:50) > > On 17/01/2022 15:09, Andi Shyti wrote: > > The GT has its own properties and in sysfs they should be grouped > > in the 'gt/' directory. > > > > Create a 'gt/' directory in sysfs which will contain gt0...gtN > > directories related to each tile con

Re: [Intel-gfx] [PATCH 3/3] drm/i915/guc: Flush G2H handler during a GT reset

On 1/18/2022 13:43, Matthew Brost wrote: Now that the error capture is fully decoupled from fence signalling (request retirement to free memory, which is turn depends on resets) we s/is/in/ With that fixed: Reviewed-by: John Harrison John. can safely flush the G2H handler during a GT reset.

Re: [Intel-gfx] [PATCH 2/3] drm/i915/guc: Add work queue to trigger a GT reset

On 1/18/2022 13:43, Matthew Brost wrote: The G2H handler needs to be flushed during a GT reset but a G2H indicating engine reset failure can trigger a GT reset. Add a worker to trigger the GT when a engine reset failure is received to break this s/a/an/ circular dependency. Signed-off-by: Mat

Re: [Intel-gfx] [PATCH 6/7] drm/i915/guc: Copy new GuC error capture logs upon G2H notification.

A fresh round of offline design discussions with internal team has decided that: - we dont want to use an interim circular buffer to copy all of the GuC generated register dumps of one or more 'engine-capture-groups'. - instead, we shall dynamically allocate multiple nodes, each node being

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL

On 1/18/2022 13:43, Matthew Brost wrote: Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than GFP_KERNEL do fully decouple the error capture from fence signalling. s/do/to/ Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code") Does this really count as a

[Intel-gfx] ✓ Fi.CI.IGT: success for Flush G2H handler during a GT reset (rev2)

== Series Details == Series: Flush G2H handler during a GT reset (rev2) URL : https://patchwork.freedesktop.org/series/98855/ State : success == Summary == CI Bug Log - changes from CI_DRM_11094_full -> Patchwork_22019_full Summary ---

Re: [Intel-gfx] [PATCH] drm/i915/guc: Ensure multi-lrc fini breadcrumb math is correct

On 1/12/2022 21:59, Matthew Brost wrote: Realized that the GuC multi-lrc fini breadcrumb emit code is very delicate as the math this code does relies on functions it calls to emit a certain number of DWs. Add a few GEM_BUG_ONs to assert the math is correct. Signed-off-by: Matthew Brost Looks go

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev3)

== Series Details == Series: series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev3) URL : https://patchwork.freedesktop.org/series/98864/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11094_full -> Patchwork_22018_full ===

[Intel-gfx] ✓ Fi.CI.BAT: success for Flush G2H handler during a GT reset (rev2)

== Series Details == Series: Flush G2H handler during a GT reset (rev2) URL : https://patchwork.freedesktop.org/series/98855/ State : success == Summary == CI Bug Log - changes from CI_DRM_11094 -> Patchwork_22019 Summary --- **SUCCE

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Flush G2H handler during a GT reset (rev2)

== Series Details == Series: Flush G2H handler during a GT reset (rev2) URL : https://patchwork.freedesktop.org/series/98855/ 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 Flush G2H handler during a GT reset (rev2)

== Series Details == Series: Flush G2H handler during a GT reset (rev2) URL : https://patchwork.freedesktop.org/series/98855/ State : warning == Summary == $ dim checkpatch origin/drm-tip 49cfdd902b91 drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL ac359b31efe8 drm/i915/guc: Add

[Intel-gfx] [PATCH 2/3] drm/i915/guc: Add work queue to trigger a GT reset

The G2H handler needs to be flushed during a GT reset but a G2H indicating engine reset failure can trigger a GT reset. Add a worker to trigger the GT when a engine reset failure is received to break this circular dependency. Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/intel_guc.

[Intel-gfx] [PATCH 3/3] drm/i915/guc: Flush G2H handler during a GT reset

Now that the error capture is fully decoupled from fence signalling (request retirement to free memory, which is turn depends on resets) we can safely flush the G2H handler during a GT reset. This is eliminates corner cases where GuC generated G2H (e.g. engine resets) race with a GT reset. Signed-

[Intel-gfx] [PATCH 0/3] Flush G2H handler during a GT reset

After a small fix to error capture code, we now can flush G2H during a GT reset which simplifies code and seals some extreme corner case races. v2: (CI) - Don't trigger GT reset from G2H handler Signed-off-by: Matthew Brost Matthew Brost (3): drm/i915: Allocate intel_engine_coredump_alloc

[Intel-gfx] [PATCH 1/3] drm/i915: Allocate intel_engine_coredump_alloc with ALLOW_FAIL

Allocate intel_engine_coredump_alloc with ALLOW_FAIL rather than GFP_KERNEL do fully decouple the error capture from fence signalling. Fixes: 8b91cdd4f8649 ("drm/i915: Use __GFP_KSWAPD_RECLAIM in the capture code") Signed-off-by: Matthew Brost --- drivers/gpu/drm/i915/i915_gpu_error.c | 2 +- 1

Re: [Intel-gfx] [PATCH] drm/i915/dmc: Eliminate remnant GEN references

On Thu, Dec 23, 2021 at 03:18:57AM +, Tolakanahalli Pradeep, Madhumitha wrote: On Fri, 2021-12-17 at 21:37 +, Yokoyama, Caz wrote: On Thu, 2021-12-16 at 19:41 -0800, Madhumitha Tolakanahalli Pradeep wrote: > Replace GEN with DISPLAY_VER, in line with the naming > convention > followed i

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev3)

== Series Details == Series: series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev3) URL : https://patchwork.freedesktop.org/series/98864/ State : success == Summary == CI Bug Log - changes from CI_DRM_11094 -> Patchwork_22018 =

Re: [Intel-gfx] [PATCH] drm/i915/display: Move cdclk checks to atomic check

> -Original Message- > From: Jani Nikula > Sent: Tuesday, December 21, 2021 1:03 AM > To: Srivatsa, Anusha ; intel- > g...@lists.freedesktop.org > Cc: Syrjala, Ville > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Move cdclk checks to > atomic check > > On Fri, 17 Dec 2021, Anush

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev3)

== Series Details == Series: series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev3) URL : https://patchwork.freedesktop.org/series/98864/ State : warning == Summary == $ dim checkpatch origin/drm-tip 004c14a82918 x86/quirks: Fix stolen detection w

Re: [Intel-gfx] [PATCH v5 1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU

On Tue, Jan 18, 2022 at 07:37:29PM +0100, Borislav Petkov wrote: > On Tue, Jan 18, 2022 at 11:58:53AM -0600, Bjorn Helgaas wrote: > > I don't really care much one way or the other. I think the simplest > > approach is to remove QFLAG_APPLY_ONCE from intel_graphics_quirks() > > and do nothing else,

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

On Fri, Jan 14, 2022 at 4:46 AM Vincent Whitchurch wrote: > > On Fri, Jan 07, 2022 at 06:29:26AM +0100, Jim Cromie wrote: > > > > Enabling debug-to-tracefs is 2 steps: > > > > # event enable > > echo 1 > /sys/kernel/tracing/events/dyndbg/enable > > # callsite enable > > echo module foo +T

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev2)

== Series Details == Series: series starting with [v5,1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU (rev2) URL : https://patchwork.freedesktop.org/series/98864/ State : failure == Summary == Applying: x86/quirks: Fix stolen detection with integrated + discrete GPU error

Re: [Intel-gfx] [PATCH v5 1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU

On Tue, Jan 18, 2022 at 06:26:48PM +0100, Borislav Petkov wrote: On Tue, Jan 18, 2022 at 08:36:56AM -0800, Lucas De Marchi wrote: I had the impression the subject/title should be imperative, with it more relaxed in the body. It seems we have one more difference among subsystems and I will adapt

Re: [Intel-gfx] [PATCH v3] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

On Tue, Jan 18, 2022 at 06:34:20PM +0200, Ville Syrjälä wrote: > On Fri, Oct 22, 2021 at 12:51:12PM -0700, Navare, Manasi wrote: > > > > Hi Ville, > > > > Could you take a look at this, this addresses teh review comments from prev > > version > > I don't think I ever got an answer to my questio

[Intel-gfx] [drm-tip:drm-tip 8/10] drivers/gpu/drm/i915/i915_gem_evict.h:15:15: error: declaration of 'struct i915_gem_ww_ctx' will not be visible outside of this function

tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: ceefc39c8abf37ff93eb36001f82e725756863c8 commit: e38294cfc29f789b541ecc08be2e578da746663c [8/10] Merge remote-tracking branch 'drm-intel/drm-intel-gt-next' into drm-tip config: x86_64-randconfig-a002-20220117 (https://download.01.o

[Intel-gfx] ✗ Fi.CI.BAT: failure for discsrete card 64K page support

== Series Details == Series: discsrete card 64K page support URL : https://patchwork.freedesktop.org/series/98996/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11094 -> Patchwork_22016 Summary --- **FAILURE** Ser

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for discsrete card 64K page support

== Series Details == Series: discsrete card 64K page support URL : https://patchwork.freedesktop.org/series/98996/ 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 discsrete card 64K page support

== Series Details == Series: discsrete card 64K page support URL : https://patchwork.freedesktop.org/series/98996/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3fc953fbf8ce drm/i915: enforce min GTT alignment for discrete cards -:275: WARNING:DEEP_INDENTATION: Too many leading

Re: [Intel-gfx] [PATCH v5 1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU

On Tue, Jan 18, 2022 at 06:26:48PM +0100, Borislav Petkov wrote: > On Tue, Jan 18, 2022 at 08:36:56AM -0800, Lucas De Marchi wrote: > > I had the impression the subject/title should be imperative, with it > > more relaxed in the body. It seems we have one more difference among > > subsystems and I

[Intel-gfx] [PATCH v2 2/4] drm/i915: support 64K GTT pages for discrete cards

From: Matthew Auld discrete cards optimise 64K GTT pages for local-memory, since everything should be allocated at 64K granularity. We say goodbye to sparse entries, and instead get a compact 256B page-table for 64K pages, which should be more cache friendly. 4K pages for local-memory are no long

[Intel-gfx] [PATCH v2 3/4] drm/i915: add gtt misalignment test

add test to check handling of misaligned offsets and sizes Signed-off-by: Robert Beckett --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 130 ++ 1 file changed, 130 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i91

[Intel-gfx] [PATCH v2 4/4] drm/i915/uapi: document behaviour for DG2 64K support

From: Matthew Auld On discrete platforms like DG2, we need to support a minimum page size of 64K when dealing with device local-memory. This is quite tricky for various reasons, so try to document the new implicit uapi for this. v2: Fixed suggestions on formatting [Daniel] Signed-off-by: Matthe

[Intel-gfx] [PATCH v2 1/4] drm/i915: enforce min GTT alignment for discrete cards

From: Matthew Auld For local-memory objects we need to align the GTT addresses to 64K, both for the ppgtt and ggtt. We need to support vm->min_alignment > 4K, depending on the vm itself and the type of object we are inserting. With this in mind update the GTT selftests to take this into account.

[Intel-gfx] [PATCH v2 0/4] discsrete card 64K page support

This series continues support for 64K pages for discrete cards. It supersedes the 64K patches from https://patchwork.freedesktop.org/series/95686/#rev4 Changes since that series: - set min alignment for DG2 to 2MB in i915_address_space_init - replace coloring with simpler 2MB VA alignment for lme

[Intel-gfx] ✓ Fi.CI.IGT: success for Async flip optimization for DG2 (rev2)

== Series Details == Series: Async flip optimization for DG2 (rev2) URL : https://patchwork.freedesktop.org/series/98981/ State : success == Summary == CI Bug Log - changes from CI_DRM_11094_full -> Patchwork_22015_full Summary --- *

Re: [Intel-gfx] [PATCH v3] drm/atomic: Add the crtc to affected crtc only if uapi.enable = true

On Fri, Oct 22, 2021 at 12:51:12PM -0700, Navare, Manasi wrote: > > Hi Ville, > > Could you take a look at this, this addresses teh review comments from prev > version I don't think I ever got an answer to my question as to whether this was tested with all the interesting scenarios: 1) just wit

Re: [Intel-gfx] [PATCH 07/14] drm/i915: Clean up pre-skl primary plane registers

On Tue, Jan 18, 2022 at 01:40:41PM +, Souza, Jose wrote: > On Tue, 2022-01-18 at 02:55 +0200, Ville Syrjälä wrote: > > On Wed, Jan 12, 2022 at 08:12:31PM +, Souza, Jose wrote: > > > On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote: > > > > @@ -427,9 +427,9 @@ static void i9xx_plane_up

[Intel-gfx] ✗ Fi.CI.IGT: failure for Tile 4 format support (rev2)

== Series Details == Series: Tile 4 format support (rev2) URL : https://patchwork.freedesktop.org/series/98983/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11094_full -> Patchwork_22014_full Summary --- **FAILURE**

Re: [Intel-gfx] [PATCH] drm/i915: Use i915_gem_object_pin_map_unlocked function for lmem allocation

On Tue, Jan 18, 2022 at 01:45:10PM +, Matthew Auld wrote: > On Fri, 14 Jan 2022 at 08:25, Stanislav Lisovskiy > wrote: > > > > Using i915_gem_object_pin_map_unlocked instead of > > i915_gem_object_lmem_io_map, would eliminate the need > > of using I915_BO_ALLOC_CONTIGUOUS, when calling > > i91

Re: [Intel-gfx] [PATCH] drm/i915: Add locking to i915_gem_evict_vm(), v3.

Op 17-01-2022 om 15:08 schreef Thomas Hellström: > > On 1/17/22 08:56, Maarten Lankhorst wrote: >> i915_gem_evict_vm will need to be able to evict objects that are >> locked by the current ctx. By testing if the current context already >> locked the object, we can do this correctly. This allows us

Re: [Intel-gfx] [CI] PR for new GuC v69.0.3

Pulled and pushed out. josh On Fri, Jan 14, 2022 at 7:03 PM wrote: > > The following changes since commit b0e898fbaf377c99a36aac6fdeb7250003648ca4: > > linux-firmware: Update firmware file for Intel Bluetooth 9462 (2021-11-23 > 12:31:45 -0500) > > are available in the Git repository at: > >

[Intel-gfx] ✓ Fi.CI.BAT: success for Async flip optimization for DG2 (rev2)

== Series Details == Series: Async flip optimization for DG2 (rev2) URL : https://patchwork.freedesktop.org/series/98981/ State : success == Summary == CI Bug Log - changes from CI_DRM_11094 -> Patchwork_22015 Summary --- **SUCCESS**

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

On Mon, 2022-01-17 at 13:21 +0200, Jani Nikula wrote: > On Thu, 13 Jan 2022, Rodrigo Vivi wrote: > > On Thu, Jan 06, 2022 at 12:02:36PM -0800, Juston Li wrote: > > > Similar to commit b8d8436840ca ("drm/i915/gt: Hold RPM wakelock > > > during > > > PXP suspend") but to fix the same warning for unb

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Async flip optimization for DG2 (rev2)

== Series Details == Series: Async flip optimization for DG2 (rev2) URL : https://patchwork.freedesktop.org/series/98981/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/int

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Async flip optimization for DG2 (rev2)

== Series Details == Series: Async flip optimization for DG2 (rev2) URL : https://patchwork.freedesktop.org/series/98981/ State : warning == Summary == $ dim checkpatch origin/drm-tip af673ae37d0c drm/i915: Pass plane to watermark calculation functions 69a7c958433d drm/i915: Introduce do_async

Re: [Intel-gfx] [PATCH] drm/i915: Use i915_gem_object_pin_map_unlocked function for lmem allocation

On Fri, 14 Jan 2022 at 08:25, Stanislav Lisovskiy wrote: > > Using i915_gem_object_pin_map_unlocked instead of > i915_gem_object_lmem_io_map, would eliminate the need > of using I915_BO_ALLOC_CONTIGUOUS, when calling > i915_vma_pin_iomap, because it supports non-contiguous > allocation as well. >

Re: [Intel-gfx] [PATCH 07/14] drm/i915: Clean up pre-skl primary plane registers

On Tue, 2022-01-18 at 02:55 +0200, Ville Syrjälä wrote: > On Wed, Jan 12, 2022 at 08:12:31PM +, Souza, Jose wrote: > > On Wed, 2021-12-01 at 17:25 +0200, Ville Syrjala wrote: > > > @@ -427,9 +427,9 @@ static void i9xx_plane_update_noarm(struct > > > intel_plane *plane, > > >* progr

[Intel-gfx] ✓ Fi.CI.BAT: success for Tile 4 format support (rev2)

== Series Details == Series: Tile 4 format support (rev2) URL : https://patchwork.freedesktop.org/series/98983/ State : success == Summary == CI Bug Log - changes from CI_DRM_11094 -> Patchwork_22014 Summary --- **SUCCESS** No reg

Re: [Intel-gfx] [RE]: [PATCH v3 10/10] vfio/ccw: Move the lifecycle of the struct vfio_ccw_private to the mdev

On Fri, 2022-01-14 at 20:28 +0800, Liu Yi L wrote: > Hi Eric, > > Hope you are back from new year holiday.:-) Have you got chane to > consider > this patch? Hi Yi Liu, It's coming up the list, but it's not there yet. Haven't forgotten. :) Eric > > Regards, > Yi Liu > > On 2021/11/30 19:32, L

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Prepare for multiple GTs

On 14.1.2022 19.59, Andi Shyti wrote: Hi Matt, [...] -int intel_uncore_setup_mmio(struct intel_uncore *uncore) +int intel_uncore_setup_mmio(struct intel_uncore *uncore, phys_addr_t phys_addr) { struct drm_i915_private *i915 = uncore->i915; - struct pci_dev *pdev = to_pci_dev(i9

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Tile 4 format support (rev2)

== Series Details == Series: Tile 4 format support (rev2) URL : https://patchwork.freedesktop.org/series/98983/ 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.BAT: failure for Async flip optimization for DG2

== Series Details == Series: Async flip optimization for DG2 URL : https://patchwork.freedesktop.org/series/98981/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11094 -> Patchwork_22013 Summary --- **FAILURE** Ser

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Tile 4 format support (rev2)

== Series Details == Series: Tile 4 format support (rev2) URL : https://patchwork.freedesktop.org/series/98983/ State : warning == Summary == $ dim checkpatch origin/drm-tip 83703bfcc0cb drm/i915: Introduce new Tile 4 format -:9: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit descript

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/gt: make a gt sysfs group and move power management files

Hi Tvrtko, > > +bool is_object_gt(struct kobject *kobj) > > Not sure if you will need it exported in a later patch but for now it seems > only users are local to this file. it is actually used by sysfs_gt.c and sysfs_gt_pm.c. Thank you, Andi PS. in this v4 I forgot to replace many drm_err() wi

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Async flip optimization for DG2

== Series Details == Series: Async flip optimization for DG2 URL : https://patchwork.freedesktop.org/series/98981/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/intel_pm.c

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Async flip optimization for DG2

== Series Details == Series: Async flip optimization for DG2 URL : https://patchwork.freedesktop.org/series/98981/ State : warning == Summary == $ dim checkpatch origin/drm-tip b3d8c1a22c8c drm/i915: Pass plane to watermark calculation functions 16735b01eebb drm/i915: Introduce do_async_flip f

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [v9,1/6] drm: move the buddy allocator from i915 into common drm

== Series Details == Series: series starting with [v9,1/6] drm: move the buddy allocator from i915 into common drm URL : https://patchwork.freedesktop.org/series/98979/ State : failure == Summary == Applying: drm: move the buddy allocator from i915 into common drm Using index info to reconstr

[Intel-gfx] [PATCH 2/2] drm/i915/dg2: Tile 4 plane format support

Tile4 in bspec format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY which will be supported by Display13. v2: - Moved Tile4 assocating struct for modifier/display to the beginning(Imre Deak) - Removed unneeded case I915_FORMAT_MOD_4_TILED modifier

[Intel-gfx] [PATCH 1/2] drm/i915: Introduce new Tile 4 format

This tiling layout uses 4KB tiles in a row-major layout. It has the same shape as Tile Y at two granularities: 4KB (128B x 32) and 64B (16B x 4). It only differs from Tile Y at the 256B granularity in between. At this granularity, Tile Y has a shape of 16B x 32 rows, but this tiling has a shape of

[Intel-gfx] [PATCH 0/2] Tile 4 format support

Tile4 in bspec format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY. Stanislav Lisovskiy (2): drm/i915: Introduce new Tile 4 format drm/i915/dg2: Tile 4 plane format support drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/i915/display/

[Intel-gfx] [PATCH 0/2] Tile 4 format support

Tile4 in bspec format is 4K tile organized into 64B subtiles with same basic shape as for legacy TileY. Stanislav Lisovskiy (2): drm/i915: Introduce new Tile 4 format drm/i915/dg2: Tile 4 plane format support drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/i915/display/

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Fix bandwith related cdclk calculations

== Series Details == Series: drm/i915: Fix bandwith related cdclk calculations URL : https://patchwork.freedesktop.org/series/98975/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11094_full -> Patchwork_22010_full Summary -

Re: [Intel-gfx] [PATCH v4 2/2] drm/i915/gt: make a gt sysfs group and move power management files

On 17/01/2022 19:32, Andi Shyti wrote: The GT has its own properties and in sysfs they should be grouped in the 'gt/' directory. Create a 'gt/' directory in sysfs which will contain gt0...gtN directories related to each tile configured in the GPU. Move the power management files inside those d

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add GuC Error Capture Support (rev4)

== Series Details == Series: Add GuC Error Capture Support (rev4) URL : https://patchwork.freedesktop.org/series/97187/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11094 -> Patchwork_22011 Summary --- **FAILURE**

[Intel-gfx] [PATCH 4/4] drm/i915: Don't allocate extra ddb during async flip for DG2

In terms of async flip optimization we don't to allocate extra ddb space, so lets skip it. v2: - Extracted min ddb async flip check to separate function (Ville Syrjälä) - Used this function to prevent false positive WARN to be triggered(Ville Syrjälä) Signed-off-by: Stanislav Liso

[Intel-gfx] [PATCH 3/4] drm/i915: Use wm0 only during async flips for DG2

This optimization allows to achieve higher perfomance during async flips. For the first async flip we have to still temporarily switch to sync flip, in order to reprogram plane watermarks, so this requires taking into account old plane state's do_async_flip flag. v2: - Removed redundant new_plane_

[Intel-gfx] [PATCH 2/4] drm/i915: Introduce do_async_flip flag to intel_plane_state

There might be various logical contructs when we might want to enable async flip, so lets calculate those and set this flag, so that there is no need in long conditions in other places. v2: - Set do_async_flip flag to False, if no async flip needed. Lets not rely that it will be 0-initialize

[Intel-gfx] [PATCH 1/4] drm/i915: Pass plane to watermark calculation functions

Sometimes we might need to change the way we calculate watermarks, based on which particular plane it is calculated for. Thus it would be convenient to pass plane struct to those functions. v2: Pass plane instead of plane_id Signed-off-by: Stanislav Lisovskiy --- .../gpu/drm/i915/display/intel_

[Intel-gfx] [PATCH 0/4] Async flip optimization for DG2

Limitting the WM levels to 0 for DG2 during async flips, allows to slightly increase the perfomance, as recommended by HW team. Stanislav Lisovskiy (4): drm/i915: Pass plane to watermark calculation functions drm/i915: Introduce do_async_flip flag to intel_plane_state drm/i915: Use wm0 only

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add GuC Error Capture Support (rev4)

== Series Details == Series: Add GuC Error Capture Support (rev4) URL : https://patchwork.freedesktop.org/series/97187/ 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 Add GuC Error Capture Support (rev4)

== Series Details == Series: Add GuC Error Capture Support (rev4) URL : https://patchwork.freedesktop.org/series/97187/ State : warning == Summary == $ dim checkpatch origin/drm-tip c5b79a260782 drm/i915/guc: Update GuC ADS size for error capture lists -:32: WARNING:FILE_PATH_CHANGES: added, m

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Fix bandwith related cdclk calculations

== Series Details == Series: drm/i915: Fix bandwith related cdclk calculations URL : https://patchwork.freedesktop.org/series/98975/ State : success == Summary == CI Bug Log - changes from CI_DRM_11094 -> Patchwork_22010 Summary ---

[Intel-gfx] [PATCH 2/7] drm/i915/guc: Add XE_LP registers for GuC error state capture.

Add device specific tables and register lists to cover different engines class types for GuC error state capture for XE_LP products. Also, add runtime allocation and freeing of extended register lists for registers that need steering identifiers that depend on the detected HW config. Signed-off-b

[Intel-gfx] [PATCH 6/7] drm/i915/guc: Copy new GuC error capture logs upon G2H notification.

Upon the G2H Notify-Err-Capture event, make a snapshot of the error state capture logs from the GuC-log buffer (error capture region) into an bigger interim circular buffer store that can be parsed later during gpu coredump printing. Also, do the same for where we reset GuC submission and need to

[Intel-gfx] [PATCH 5/7] drm/i915/guc: Update GuC's log-buffer-state access for error capture.

GuC log buffer regions for debug-log-events, crash-dumps and error-state-capture are all a single bo allocation that includes the guc_log_buffer_state structures. Since the error-capture region is accessed with high priority at non- deterministic times (as part of gpu coredump) while the debug-log

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

Print the GuC captured error state register list (string names and values) when gpu_coredump_state printout is invoked via the i915 debugfs for flushing the gpu error-state that was captured prior. Since GuC could have reported multiple engine register dumps in a single notification event, parse t

[Intel-gfx] [PATCH 3/7] drm/i915/guc: Add DG2 registers for GuC error state capture.

Add additional DG2 registers for GuC error state capture. Signed-off-by: Alan Previn --- .../gpu/drm/i915/gt/uc/intel_guc_capture.c| 64 ++- 1 file changed, 49 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_capture.c b/drivers/gpu/drm/i915/

[Intel-gfx] [PATCH 4/7] drm/i915/guc: Add GuC's error state capture output structures.

Add GuC's error capture output structures and definitions as how they would appear in GuC log buffer's error capture subregion after an error state capture G2H event notification. Signed-off-by: Alan Previn Reviewed-by: Matthew Brost --- drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h | 35 ++

[Intel-gfx] [PATCH 0/7] Add GuC Error Capture Support

This series: 1. Enables support of GuC to execute error- state-capture based on a list of MMIO registers the driver registers and GuC will dump and report back right before a GuC triggered engine-reset event. 2. Updates the ADS blob creation to register lists of global

[Intel-gfx] [PATCH 1/7] drm/i915/guc: Update GuC ADS size for error capture lists

Update GuC ADS size allocation to include space for the lists of error state capture register descriptors. Also, populate the lists of registers we want GuC to report back to Host on engine reset events. This list should include global, engine-class and engine-instance registers for every engine-c

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: Fix bandwith related cdclk calculations

== Series Details == Series: drm/i915: Fix bandwith related cdclk calculations URL : https://patchwork.freedesktop.org/series/98975/ 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 drm/i915: Fix bandwith related cdclk calculations

== Series Details == Series: drm/i915: Fix bandwith related cdclk calculations URL : https://patchwork.freedesktop.org/series/98975/ State : warning == Summary == $ dim checkpatch origin/drm-tip f65f6b681b85 drm/i915: Drop pointless dev_priv argument 9668fabd85a5 drm/i915: Extract skl_ddb_entr

Re: [Intel-gfx] [PATCH v5 1/5] x86/quirks: Fix stolen detection with integrated + discrete GPU

n Thu, Jan 13, 2022 at 04:28:39PM -0800, Lucas De Marchi wrote: > early_pci_scan_bus() does a depth-first traversal, possibly calling > the quirk functions for each device based on vendor, device and class > from early_qrk table. intel_graphics_quirks() however uses PCI_ANY_ID > and does additional

[Intel-gfx] [PATCH 15/15] drm/i915: Add "maximum pipe read bandwidth" checks

From: Ville Syrjälä Make sure the CDCLK is high enough to support the so called "maximum pipe read bandwidth" limitation. Specified as 51.2 x CDCLK. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_bw.c | 36 + drivers/gpu/drm/i915/display/intel_bw.h

[Intel-gfx] [PATCH 14/15] drm/i915: Fix DBUF bandwidth vs. cdclk handling

From: Ville Syrjälä Make the dbuf bandwidth min cdclk calculations match the spec more closely. Supposedly the arbiter can only guarantee an equal share of the total bandwidth of the slice to each active plane on that slice. So we take the max bandwidth of any of the planes on each slice and mult

[Intel-gfx] [PATCH 13/15] drm/i915: Properly write lock bw_state when it changes

From: Ville Syrjälä The current code also forgets to call intel_atomic_lock_global_state() when other stuff besides the final min_cdlck changes in the state. That means we may throw away data which actually has changed, and thus we can't be at all sure what the code ends up doing during subsequen

[Intel-gfx] [PATCH 12/15] drm/i915: Round up when calculating display bandwidth requirements

From: Ville Syrjälä We should round up when doing bandwidth calculations to make sure our estimates don't fall short of the actual number. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_bw.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gp

[Intel-gfx] [PATCH 11/15] drm/i915: Nuke intel_bw_calc_min_cdclk()

From: Ville Syrjälä intel_bw_calc_min_cdclk() is entirely pointless. All it manages to do is somehow conflate the per-pipe min cdclk with dbuf min cdclk. There is no (at least documented) dbuf min cdclk limit on pre-skl so let's just get rid of all this confusion. Signed-off-by: Ville Syrjälä -

[Intel-gfx] [PATCH 10/15] drm/i915: Remove total[] and uv_total[] from ddb allocation

From: Ville Syrjälä There's really no need to maintain these total[] arrays to track the size of each plane's ddb allocation. We just stick the results straight into the crtc_state ddb tracking structures. The main annoyance with all this is the mismatch between wm_uv vs. ddb_y on pre-icl. If on

[Intel-gfx] [PATCH 09/15] drm/i915: Pre-calculate plane relative data rate

From: Ville Syrjälä Handle the plane relative data rate in exactly the same way as we already handle the real data rate. Ie. pre-calculate it during intel_plane_atomic_check_with_state(), and assign/clear it for the Y plane as needed. This should guarantee that the tracking is 100% consistent, an

[Intel-gfx] [PATCH 08/15] drm/i915: Split plane data_rate into data_rate+data_rate_y

From: Ville Syrjälä Split the currently combined plane data_rate into the proper Y vs. CbCr components. This matches how we now track the plane dbuf allocations, and thus will make the dbuf bandwidth calculations actually produce the correct numbers for each dbuf slice. Signed-off-by: Ville Syrj

[Intel-gfx] [PATCH 07/15] drm/i915: Tweak plane ddb allocation tracking

From: Ville Syrjälä Let's store the plane allocation in a manner which more closely matches how the hw operates. That is, we store the packed/CbCr ddb in one struct, and the Y ddb in another. Currently we're storing packed/Y in one struct, CbCr in the other. This also works pretty well for icl+

[Intel-gfx] [PATCH 06/15] drm/i915: Extract skl_crtc_calc_dbuf_bw()

From: Ville Syrjälä Extract the dbuf slice data_rate calculation into a small helper. Should make it a bit easier to handle the different color planes of planar formats correctly. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_bw.c | 82 + 1 file ch

[Intel-gfx] [PATCH 05/15] drm/i915: Extract skl_allocate_plane_ddb()

From: Ville Syrjälä Replace some copy-pasta with a function. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/intel_pm.c | 41 +++-- 1 file changed, 24 insertions(+), 17 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.

  1   2   >