[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4)

== Series Details == Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4) URL : https://patchwork.freedesktop.org/series/101219/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11416_full -> Patchwork_22740_full

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Splitting up platform-specific calls (rev5)

== Series Details == Series: Splitting up platform-specific calls (rev5) URL : https://patchwork.freedesktop.org/series/99126/ State : failure == Summary == Applying: Split i915_run_as_guest into x86 and non-x86 Using index info to reconstruct a base tree... M

[Intel-gfx] [RFC PATCH v5 1/1] Split i915_run_as_guest into x86 and non-x86

Splitting i915_run_as_guest into a more arch-friendly function as non-x86 builds do not support this functionality. Signed-off-by: Casey Bowman --- drivers/gpu/drm/i915/i915_utils.h | 5 + 1 file changed, 5 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_utils.h

[Intel-gfx] [RFC PATCH v5 0/1] Splitting up platform-specific calls

In this RFC I would like to ask the community their thoughts on how we can best handle splitting architecture-specific calls. I would like to address the following: 1. How do we want to split architecture calls? Different object files per platform? Separate function calls within the same object

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Splitting intel-gtt calls for non-x86 platforms (rev5)

== Series Details == Series: Splitting intel-gtt calls for non-x86 platforms (rev5) URL : https://patchwork.freedesktop.org/series/101552/ State : failure == Summary == Applying: drm/i915/gt: Split intel-gtt functions by arch Using index info to reconstruct a base tree... M

[Intel-gfx] [PATCH v5 2/2] drm/i915: Require INTEL_GTT to depend on X86

The intel-gtt module is not used on other, non-x86 platforms, so we will restrict it to x86 platforms only. Signed-off-by: Casey Bowman --- drivers/gpu/drm/i915/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig

[Intel-gfx] [PATCH v5 1/2] drm/i915/gt: Split intel-gtt functions by arch

Some functions defined in the intel-gtt module are used in several areas, but is only supported on x86 platforms. By separating these calls and their static underlying functions to another area, we are able to compile out these functions for non-x86 builds and provide stubs for the non-x86

[Intel-gfx] [PATCH v5 0/2] Splitting intel-gtt calls for non-x86 platforms

The intel-gtt module defines some functions used by i915, but they are only supported by x86 platforms. In order to bring i915 to a more arch-neutral state, we split out these functions and provide stubs in the case of non-x86 builds. There may be a better filename choice for the files used in

[Intel-gfx] ✗ Fi.CI.BUILD: failure for Splitting intel-gtt calls for non-x86 platforms (rev4)

== Series Details == Series: Splitting intel-gtt calls for non-x86 platforms (rev4) URL : https://patchwork.freedesktop.org/series/101552/ State : failure == Summary == Applying: drm/i915/gt: Split intel-gtt functions by arch Using index info to reconstruct a base tree... M

[Intel-gfx] [PATCH v4 2/2] drm/i915: Require INTEL_GTT to depend on X86

The intel-gtt module is not used on other, non-x86 platforms, so we will restrict it to x86 platforms only. Signed-off-by: Casey Bowman --- drivers/gpu/drm/i915/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/Kconfig

[Intel-gfx] [PATCH v4 1/2] drm/i915/gt: Split intel-gtt functions by arch

Some functions defined in the intel-gtt module are used in several areas, but is only supported on x86 platforms. By separating these calls and their static underlying functions to another area, we are able to compile out these functions for non-x86 builds and provide stubs for the non-x86

[Intel-gfx] [PATCH v4 0/2] Splitting intel-gtt calls for non-x86 platforms

The intel-gtt module defines some functions used by i915, but they are only supported by x86 platforms. In order to bring i915 to a more arch-neutral state, we split out these functions and provide stubs in the case of non-x86 builds. There may be a better filename choice for the files used in

[Intel-gfx] ✗ Fi.CI.BUILD: failure for i915: Explicit handling of multicast registers

== Series Details == Series: i915: Explicit handling of multicast registers URL : https://patchwork.freedesktop.org/series/101992/ State : failure == Summary == Applying: drm/i915/gen8: Create separate reg definitions for new MCR registers Applying: drm/i915/xehp: Create separate reg

[Intel-gfx] [PATCH 15/15] drm/i915/xehp: Eliminate shared/implicit steering

Historically we've selected and programmed a single MCR group/instance ID at driver startup that will steer register accesses for GSLICE/DSS ranges to a non-terminated instance. Any reads of these register ranges that don't need a specific unicast access won't bother explicitly resteering because

[Intel-gfx] [PATCH 02/15] drm/i915/xehp: Create separate reg definitions for new MCR registers

Starting in Xe_HP, several registers our driver works with have been converted from singleton registers into replicated registers with multicast behavior. Although the registers are still located at the same MMIO offsets as on previous platforms, let's duplicate the register definitions in

[Intel-gfx] [PATCH 06/15] drm/i915: Drop duplicated definition of XEHPSDV_FLAT_CCS_BASE_ADDR

When this register was moved to intel_gt_regs.h it wasn't dropped from i915_reg.h; do so now. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/i915_reg.h | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index

[Intel-gfx] [PATCH 08/15] drm/i915: Define MCR registers explicitly

Rather than using the same _MMIO() macro to define MCR registers as singleton registers, let's use a new MCR_REG() macro to make it clear that these registers are special and should be handled accordingly. For now MCR_REG() will still generate an i915_reg_t with the given offset, but we'll change

[Intel-gfx] [PATCH 05/15] drm/i915/xehp: Check for faults on all mslices

The fault registers are multicast registers, replicated per-mslice starting on Xe_HP. When checking for faults, we should check each mslice's instance of the register rather than just one of the instances. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_gt.c | 44

[Intel-gfx] [PATCH 09/15] drm/i915/gt: Move multicast register handling to a dedicated file

Handling of multicast/replicated registers is spread across intel_gt.c and intel_uncore.c today. As multicast handling and the related steering logic gets more complicated with the addition of new platforms and new rules it makes sense to centralize it all in one place. For now the existing

[Intel-gfx] [PATCH 11/15] drm/i915/gt: Always use MCR functions on multicast registers

Rather than relying on the implicit behavior of intel_uncore_*() functions, let's always use the intel_gt_mcr_*() functions to operate on multicast/replicated registers. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_ggtt.c | 4 +- drivers/gpu/drm/i915/gt/intel_gtt.c |

[Intel-gfx] [PATCH 12/15] drm/i915/guc: Handle save/restore of MCR registers explicitly

MCR registers can be placed on the GuC's save/restore list, but at the moment they are always handled in a multicast manner (i.e., the GuC reads one instance to save the value and then does a multicast write to restore that single value to all instances). In the future the GuC will probably give

[Intel-gfx] [PATCH 14/15] drm/i915: Define multicast registers as a new type

Rather than treating multicast registers as 'i915_reg_t' let's define them as a completely new type. This will allow the compiler to help us make sure we're using multicast-aware functions to operate on multicast registers. This plan does break down a bit in places where we're just maintaining

[Intel-gfx] [PATCH 13/15] drm/i915/gt: Add MCR-specific workaround initializers

Let's be more explicit about which of our workarounds are updating MCR registers. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 346 +++- 1 file changed, 198 insertions(+), 148 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c

[Intel-gfx] [PATCH 07/15] drm/i915: Move XEHPSDV_TILE0_ADDR_RANGE to GT register header

XEHPSDV_TILE0_ADDR_RANGE is a GT register and requires multicast handling. Move the definition to the proper header. Fixes: b8ca8fef58d4 ("drm/i915/stolen: don't treat small BAR as an error") Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 1 +

[Intel-gfx] [PATCH 10/15] drm/i915/gt: Cleanup interface for MCR operations

Let's replace the assortment of intel_gt_* and intel_uncore_* functions that operate on MCR registers with a cleaner set of interfaces: * intel_gt_mcr_read -- unicast read from specific instance * intel_gt_mcr_read_any[_fw] -- unicast read from any non-terminated instance *

[Intel-gfx] [PATCH 03/15] drm/i915/gt: Drop a few unused register definitions

Let's drop a few register definitions that are unused anywhere in the driver today. Since the referenced offsets are part of what is now considered a multicast register region, the current definitions would not be correct for use on any future platform. Signed-off-by: Matt Roper ---

[Intel-gfx] [PATCH 04/15] drm/i915/gt: Correct prefix on a few registers

We have a few registers that have existed for several hardware generations, but are only used by the driver on Xe_HP and beyond. In cases where the Xe_HP version of the register is now replicated and uses multicast behavior, but earlier generations were singleton, let's change the register prefix

[Intel-gfx] [PATCH 01/15] drm/i915/gen8: Create separate reg definitions for new MCR registers

Gen8 was the first time our hardware had multicast registers (or at least the first time the multicast nature was exposed and MMIO accesses could be steered). There are some registers that transitioned from singleton behavior to multicast during the gen7 -> gen8 transition; let's duplicate the

[Intel-gfx] [PATCH 00/15] i915: Explicit handling of multicast registers

Multicast/replicated (MCR) registers on Intel hardware are a purely GT-specific concept. Rather than leaving MCR register handling spread across several places throughout the driver (intel_uncore.c, intel_gt.c, etc.) with confusing combinations of handler functions living in different namespaces,

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4)

== Series Details == Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4) URL : https://patchwork.freedesktop.org/series/101219/ State : success == Summary == CI Bug Log - changes from CI_DRM_11416 -> Patchwork_22740 Summary

[Intel-gfx] drm-tip compile break

Is anyone looking into fixing this: drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c: In function ‘amdgpu_gtt_mgr_recover’: drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c:200:31: error: ‘struct ttm_range_mgr_node’ has no member named ‘tbo’ amdgpu_ttm_recover_gart(node->tbo);

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4)

== Series Details == Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4) URL : https://patchwork.freedesktop.org/series/101219/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning:

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4)

== Series Details == Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4) URL : https://patchwork.freedesktop.org/series/101219/ 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/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4)

== Series Details == Series: drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES (rev4) URL : https://patchwork.freedesktop.org/series/101219/ State : warning == Summary == $ dim checkpatch origin/drm-tip 6f3dde840f67 drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES -:133: CHECK:SPACING:

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add driver for GSC controller (rev14)

== Series Details == Series: Add driver for GSC controller (rev14) URL : https://patchwork.freedesktop.org/series/98066/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11416 -> Patchwork_22739 Summary --- **FAILURE**

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/edid: fix invalid EDID extension block filtering

== Series Details == Series: drm/edid: fix invalid EDID extension block filtering URL : https://patchwork.freedesktop.org/series/101969/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11416_full -> Patchwork_22738_full

[Intel-gfx] [PATCH v4 RFC] drm/i915/uapi: Add DRM_I915_QUERY_GEOMETRY_SUBSLICES

Newer platforms have DSS that aren't necessarily available for both geometry and compute, two queries will need to exist. This introduces the first, when passing a valid engine class and engine instance in the flags returns a topology describing geometry. v2: fix white space errors v3: change

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Refactor the display power domain mappings (rev3)

== Series Details == Series: drm/i915: Refactor the display power domain mappings (rev3) URL : https://patchwork.freedesktop.org/series/99476/ State : success == Summary == CI Bug Log - changes from CI_DRM_11416_full -> Patchwork_22722_full

[Intel-gfx] ✗ Fi.CI.DOCS: warning for Add driver for GSC controller (rev14)

== Series Details == Series: Add driver for GSC controller (rev14) URL : https://patchwork.freedesktop.org/series/98066/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not found

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Add driver for GSC controller (rev14)

== Series Details == Series: Add driver for GSC controller (rev14) URL : https://patchwork.freedesktop.org/series/98066/ 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 driver for GSC controller (rev14)

== Series Details == Series: Add driver for GSC controller (rev14) URL : https://patchwork.freedesktop.org/series/98066/ State : warning == Summary == $ dim checkpatch origin/drm-tip 690fddb652c2 drm/i915/gsc: add gsc as a mei auxiliary device -:65: WARNING:FILE_PATH_CHANGES: added, moved or

Re: [Intel-gfx] [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid()

On Wed, 30 Mar 2022, Jani Nikula wrote: > On Wed, 30 Mar 2022, Ville Syrjälä wrote: >> This one points to extension blocks too so using >> struct edid doesn't seem entirely appropriate. > > So I've gone back and forth with this. I think I want to get rid of u8* > no matter what, because it

[Intel-gfx] [CI 4/6] mei: gsc: add runtime pm handlers

From: Tomas Winkler Implement runtime handlers for mei-gsc, to track idle state of the device properly. CC: Rodrigo Vivi Signed-off-by: Tomas Winkler Signed-off-by: Alexander Usyskin Reviewed-by: Rodrigo Vivi --- drivers/misc/mei/gsc-me.c | 67 ++- 1

[Intel-gfx] [CI 3/6] mei: gsc: setup char driver alive in spite of firmware handshake failure

From: Alexander Usyskin Setup char device in spite of firmware handshake failure. In order to provide host access to the firmware status registers and other information required for the manufacturing process. Signed-off-by: Alexander Usyskin Signed-off-by: Tomas Winkler Reviewed-by: Daniele

[Intel-gfx] [CI 5/6] mei: gsc: retrieve the firmware version

From: Alexander Usyskin Add a hook to retrieve the firmware version of the GSC devices to bus-fixup. GSC has a different MKHI clients GUIDs but the same message structure to retrieve the firmware version as MEI so mei_fwver() can be reused. CC: Ashutosh Dixit Signed-off-by: Alexander Usyskin

[Intel-gfx] [CI 2/6] mei: add support for graphics system controller (gsc) devices

From: Tomas Winkler GSC is a graphics system controller, based on CSE, it provides a chassis controller for graphics discrete cards, as well as it supports media protection on selected devices. mei_gsc binds to a auxiliary devices exposed by Intel discrete driver i915. Signed-off-by: Alexander

[Intel-gfx] [CI 1/6] drm/i915/gsc: add gsc as a mei auxiliary device

From: Tomas Winkler GSC is a graphics system controller, it provides a chassis controller for graphics discrete cards. There are two MEI interfaces in GSC: HECI1 and HECI2. Both interfaces are on the BAR0 at offsets 0x00258000 and 0x00259000. GSC is a GT Engine (class 4: instance 6). HECI1

[Intel-gfx] [CI 6/6] HAX: drm/i915: force INTEL_MEI_GSC on for CI

After the new config option is merged we'll enable it by default in the CI config, but for now just force it on via the i915 Kconfig so we can get pre-merge CI results for it. Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/Kconfig.debug | 1 + 1 file changed, 1 insertion(+)

[Intel-gfx] [CI 0/6] Add driver for GSC controller

Same as the v11 version already fully reviewed (bar a very minor rebase), but with an added patch to force the new aux driver to be built in CI. Resend to test with updated IGT. Test-with: 20220330183259.3003663-1-daniele.ceraolospu...@intel.com Cc: Alexander Usyskin Alexander Usyskin (2):

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

On Wed, 2022-03-30 at 19:29 +, Patchwork wrote: Patch Details Series: series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL URL:https://patchwork.freedesktop.org/series/101965/ State: failure Details:

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 02/11] tests/i915/drm_fdinfo: Basic and functional tests for GPU busyness exported via fdinfo

This looks very similar to existing perf_pmu tests with the slight change that the busyness is now captured from the fdinfo. lgtm, Reviewed-by: Umesh Nerlige Ramappa Umesh On Tue, Feb 22, 2022 at 01:55:56PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Mostly inherited from the

Re: [Intel-gfx] [PATCH] drm/i915/guc: Use iosys_map interface to update lrc_desc

On Wed, Mar 30, 2022 at 08:53:11AM -0700, John Harrison wrote: > Sorry, only just seen this patch. > > Please do not do this! > > The entire lrc_desc_pool entity is being dropped as part of the update to > GuC v70. That's why there was a recent patch set to significantly > re-organise how/where

Re: [Intel-gfx] [PATCH i-g-t 01/11] lib: Helper library for parsing i915 fdinfo output

On Tue, Feb 22, 2022 at 01:55:55PM +, Tvrtko Ursulin wrote: 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 | 183 +++ lib/igt_drm_fdinfo.h | 48

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

== Series Details == Series: series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL URL : https://patchwork.freedesktop.org/series/101965/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11416_full ->

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/edid: fix invalid EDID extension block filtering

== Series Details == Series: drm/edid: fix invalid EDID extension block filtering URL : https://patchwork.freedesktop.org/series/101969/ State : success == Summary == CI Bug Log - changes from CI_DRM_11416 -> Patchwork_22738 Summary

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gt: Split intel-gtt functions by arch

On 3/30/22 10:25, Jani Nikula wrote: On Wed, 30 Mar 2022, Casey Bowman wrote: On 3/30/22 02:55, Tvrtko Ursulin wrote: I mean I could suggest to do something about the incosistency of: static inline void intel_gt_gmch_gen5_chipset_flush(struct intel_gt *gt) vs: static inline int

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Refactor the display power domain mappings (rev3)

== Series Details == Series: drm/i915: Refactor the display power domain mappings (rev3) URL : https://patchwork.freedesktop.org/series/99476/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11416_full -> Patchwork_22722_full

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/edid: fix invalid EDID extension block filtering

== Series Details == Series: drm/edid: fix invalid EDID extension block filtering URL : https://patchwork.freedesktop.org/series/101969/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/display/intel_drrs.c:1: warning: 'intel_drrs_enable' not

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/adlp: Fix register corruption after DDI clock enabling (rev2)

== Series Details == Series: drm/i915/adlp: Fix register corruption after DDI clock enabling (rev2) URL : https://patchwork.freedesktop.org/series/101712/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11416_full -> Patchwork_22718_full

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gt: Split intel-gtt functions by arch

On Wed, 30 Mar 2022, Casey Bowman wrote: > On 3/30/22 02:55, Tvrtko Ursulin wrote: >> I mean I could suggest to do something about the incosistency of: >> >> static inline void intel_gt_gmch_gen5_chipset_flush(struct intel_gt *gt) >> >> vs: >> >> static inline int intel_gt_gmch_gen5_probe(struct

Re: [Intel-gfx] [PATCH] drm/edid: fix invalid EDID extension block filtering

On Wed, Mar 30, 2022 at 08:04:26PM +0300, Jani Nikula wrote: > The invalid EDID block filtering uses the number of valid EDID > extensions instead of all EDID extensions for looping the extensions in > the copy. This is fine, by coincidence, if all the invalid blocks are at > the end of the EDID.

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

== Series Details == Series: series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL URL : https://patchwork.freedesktop.org/series/101965/ State : success == Summary == CI Bug Log - changes from CI_DRM_11416 -> Patchwork_22737

Re: [Intel-gfx] [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid()

On Wed, 30 Mar 2022, Ville Syrjälä wrote: > I'd fix this up front so we don't end having to backport the whole > thing if/when some security scan gizmo stumbles on this. Sent separately [1]. I'll rebase this series on top once that gets merged, but the conflict is trivial so I think the first

[Intel-gfx] [PATCH] drm/edid: fix invalid EDID extension block filtering

The invalid EDID block filtering uses the number of valid EDID extensions instead of all EDID extensions for looping the extensions in the copy. This is fine, by coincidence, if all the invalid blocks are at the end of the EDID. However, it's completely broken if there are invalid extensions in

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Refactor the display power domain mappings (rev3)

== Series Details == Series: drm/i915: Refactor the display power domain mappings (rev3) URL : https://patchwork.freedesktop.org/series/99476/ State : success == Summary == CI Bug Log - changes from CI_DRM_11416 -> Patchwork_22722 Summary

Re: [Intel-gfx] [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid()

On Wed, Mar 30, 2022 at 07:28:56PM +0300, Jani Nikula wrote: > On Wed, 30 Mar 2022, Ville Syrjälä wrote: > > On Wed, Mar 30, 2022 at 06:16:17PM +0300, Jani Nikula wrote: > >> On Wed, 30 Mar 2022, Ville Syrjälä wrote: > >> > On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote: > >> >>

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gt: Split intel-gtt functions by arch

On 3/30/22 02:55, Tvrtko Ursulin wrote: On 30/03/2022 00:58, Casey Bowman wrote: Some functions defined in the intel-gtt module are used in several areas, but is only supported on x86 platforms. By separating these calls and their static underlying functions to another area, we are able to

Re: [Intel-gfx] [PATCH] drm/i915/dp: make DSC usage logging actually useful

On Wed, 30 Mar 2022, Ville Syrjälä wrote: > On Wed, Mar 30, 2022 at 12:30:19PM +0300, Jani Nikula wrote: >> Debug log when DSC is going to be used, and why, instead of >> unconditionally logging the rarely used debug option setting, which >> might not have any bearing on whether DSC is going to

Re: [Intel-gfx] [PATCH 1/2] drm/i915/audio: unify audio codec enable/disable debug logging

On Wed, 30 Mar 2022, Ville Syrjälä wrote: > On Wed, Mar 30, 2022 at 12:41:08PM +0300, Jani Nikula wrote: >> The audio codec enable/disable debug logging is spread around in callers >> and the platform specific hooks. Put them all together in one place on >> both the enable and disable paths. >>

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gt: Split intel-gtt functions by arch

On 3/30/22 03:16, Jani Nikula wrote: On Tue, 29 Mar 2022, Casey Bowman wrote: +/* Stubs for non-x86 platforms */ +#else +static inline void intel_gt_gmch_gen5_chipset_flush(struct intel_gt *gt) +{ +} +static inline int intel_gt_gmch_gen5_probe(struct i915_ggtt *ggtt) +{ + /* No HW

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915/gt: Split intel-gtt functions by arch

On 3/30/22 03:23, Jani Nikula wrote: On Wed, 30 Mar 2022, Tvrtko Ursulin wrote: On 30/03/2022 00:58, Casey Bowman wrote: Some functions defined in the intel-gtt module are used in several areas, but is only supported on x86 platforms. By separating these calls and their static underlying

Re: [Intel-gfx] [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid()

On Wed, 30 Mar 2022, Ville Syrjälä wrote: > On Wed, Mar 30, 2022 at 06:16:17PM +0300, Jani Nikula wrote: >> On Wed, 30 Mar 2022, Ville Syrjälä wrote: >> > On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote: >> >> Mixing u8 * and struct edid * is confusing, switch to the latter. >> >>

[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

== Series Details == Series: series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL URL : https://patchwork.freedesktop.org/series/101965/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

== Series Details == Series: series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL URL : https://patchwork.freedesktop.org/series/101965/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

== Series Details == Series: series starting with [CI,v3,1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL URL : https://patchwork.freedesktop.org/series/101965/ State : warning == Summary == $ dim checkpatch origin/drm-tip a389720ee911

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Refactor the display power domain mappings (rev3)

== Series Details == Series: drm/i915: Refactor the display power domain mappings (rev3) URL : https://patchwork.freedesktop.org/series/99476/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11416 -> Patchwork_22722 Summary

[Intel-gfx] [PATCH CI v3 3/3] drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTL

PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being enabled but that could potentially cause issues as it could have mismatching values while pipes are being enabled. So here moving the PIPE_MBUS_DBOX_CTL programming of all pipes to be executed before the function that enables all

[Intel-gfx] [PATCH CI v3 1/3] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

MBUS_DBOX_B2B_TRANSACTIONS_MAX, MBUS_DBOX_B2B_TRANSACTIONS_DELAY and MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN were being programmed with zeros while specification has different default values for this registers in display 12 and newer. While at it also converting all MBUS_DBOX macros to use REG_*

[Intel-gfx] [PATCH CI v3 2/3] drm/i915/display/adlp: Adjust MBUS DBOX BW and B credits

From: Caz Yokoyama Alderlake-P has different MBUS DBOX BW and B credits than other platforms, so here setting it properly. BSpec: 49213 BSpec: 50343 Cc: Matt Roper Cc: Stanislav Lisovskiy Cc: Jani Nikula Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Caz Yokoyama

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adlp: Fix register corruption after DDI clock enabling (rev2)

== Series Details == Series: drm/i915/adlp: Fix register corruption after DDI clock enabling (rev2) URL : https://patchwork.freedesktop.org/series/101712/ State : success == Summary == CI Bug Log - changes from CI_DRM_11416 -> Patchwork_22718

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CIv2,1/4] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

On Wed, 2022-03-30 at 15:54 +, Patchwork wrote: > == Series Details == > > Series: series starting with [CIv2,1/4] drm/i915/display/tgl+: Set default > values for all registers in PIPE_MBUS_DBOX_CTL > URL : https://patchwork.freedesktop.org/series/101963/ > State : failure > > == Summary

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CIv2,1/4] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

== Series Details == Series: series starting with [CIv2,1/4] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL URL : https://patchwork.freedesktop.org/series/101963/ State : failure == Summary == Applying: drm/i915/display/tgl+: Set default values for all

Re: [Intel-gfx] [PATCH] drm/i915/guc: Use iosys_map interface to update lrc_desc

Sorry, only just seen this patch. Please do not do this! The entire lrc_desc_pool entity is being dropped as part of the update to GuC v70. That's why there was a recent patch set to significantly re-organise how/where it is used. That patch set explicitly said - this is all in preparation

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: avoid concurrent writes to aux_inv (rev10)

On 30/03/2022 16:37, Yang, Fei wrote: *Patch Details* *Series:* drm/i915: avoid concurrent writes to aux_inv (rev10) *URL:* https://patchwork.freedesktop.org/series/100772/ *State:*success *Details:*

[Intel-gfx] [PATCH CIv2 2/4] drm/i915/display/adlp: Adjust MBUS DBOX BW and B credits

From: Caz Yokoyama Alderlake-P has different MBUS DBOX BW and B credits than other platforms, so here setting it properly. BSpec: 49213 BSpec: 50343 Cc: Matt Roper Cc: Stanislav Lisovskiy Cc: Jani Nikula Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Caz Yokoyama

[Intel-gfx] [PATCH CIv2 3/4] drm/i915/display: Add HAS_MBUS_JOINING

This will make easy to extend MBUS joining support to future platforms that also supports this feature. Reviewed-by: Ville Syrjälä Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_pm.c | 6 +++--- 2 files changed, 5 insertions(+), 3

[Intel-gfx] [PATCH CIv2 4/4] drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTL

PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being enabled but that could potentially cause issues as it could have mismatching values while pipes are being enabled. So here moving the PIPE_MBUS_DBOX_CTL programming of all pipes to be executed before the function that enables all

[Intel-gfx] [PATCH CIv2 1/4] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

MBUS_DBOX_B2B_TRANSACTIONS_MAX, MBUS_DBOX_B2B_TRANSACTIONS_DELAY and MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN were being programmed with zeros while specification has different default values for this registers in display 12 and newer. While at it also converting all MBUS_DBOX macros to use REG_*

Re: [Intel-gfx] [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid()

On Wed, Mar 30, 2022 at 06:16:17PM +0300, Jani Nikula wrote: > On Wed, 30 Mar 2022, Ville Syrjälä wrote: > > On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote: > >> Mixing u8 * and struct edid * is confusing, switch to the latter. > >> > >> Cc: Ville Syrjälä > >> Signed-off-by: Jani

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: avoid concurrent writes to aux_inv (rev10)

*Patch Details* *Series:* drm/i915: avoid concurrent writes to aux_inv (rev10) *URL:* https://patchwork.freedesktop.org/series/100772/ *State:* success *Details:*

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: avoid concurrent writes to aux_inv (rev10)

On 29/03/2022 16:59, Yang, Fei wrote: On 29/03/2022 03:30, Patchwork wrote: *Patch Details* *Series:* drm/i915: avoid concurrent writes to aux_inv (rev10) *URL:* https://patchwork.freedesktop.org/series/100772/ *State:*success

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] drm/i915/audio: unify audio codec enable/disable debug logging

== Series Details == Series: series starting with [1/2] drm/i915/audio: unify audio codec enable/disable debug logging URL : https://patchwork.freedesktop.org/series/101953/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11416_full -> Patchwork_22732_full

Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [RESEND,1/3] drm/i915/dmc: abstract GPU error state dump

On Wed, 30 Mar 2022, Patchwork wrote: > == Series Details == > > Series: series starting with [RESEND,1/3] drm/i915/dmc: abstract GPU error > state dump > URL : https://patchwork.freedesktop.org/series/101957/ > State : failure I don't get why this doesn't apply. It applies for me. BR,

Re: [Intel-gfx] [PATCH 01/12] drm/edid: use struct edid * in drm_do_get_edid()

On Wed, 30 Mar 2022, Ville Syrjälä wrote: > On Tue, Mar 29, 2022 at 09:42:08PM +0300, Jani Nikula wrote: >> Mixing u8 * and struct edid * is confusing, switch to the latter. >> >> Cc: Ville Syrjälä >> Signed-off-by: Jani Nikula >> --- >> drivers/gpu/drm/drm_edid.c | 31

[Intel-gfx] ✗ Fi.CI.BUILD: failure for series starting with [CI,1/4] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

== Series Details == Series: series starting with [CI,1/4] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL URL : https://patchwork.freedesktop.org/series/101961/ State : failure == Summary == Applying: drm/i915/display/tgl+: Set default values for all

[Intel-gfx] [PATCH CI 3/4] drm/i915/display: Add HAS_MBUS_JOINING

This will make easy to extend MBUS joining support to future platforms that also supports this feature. Reviewed-by: Ville Syrjälä Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/intel_pm.c | 6 +++--- 2 files changed, 5 insertions(+), 3

[Intel-gfx] [PATCH CI 4/4] drm/i915/display/adlp: Fix programing of PIPE_MBUS_DBOX_CTL

PIPE_MBUS_DBOX_CTL was only being programmed when a pipe is being enabled but that could potentially cause issues as it could have mismatching values while pipes are being enabled. So here moving the PIPE_MBUS_DBOX_CTL programming of all pipes to be executed before the function that enables all

[Intel-gfx] [PATCH CI 2/4] drm/i915/display/adlp: Adjust MBUS DBOX BW and B credits

From: Caz Yokoyama Alderlake-P has different MBUS DBOX BW and B credits than other platforms, so here setting it properly. BSpec: 49213 BSpec: 50343 Cc: Matt Roper Cc: Stanislav Lisovskiy Cc: Jani Nikula Cc: Ville Syrjälä Reviewed-by: Ville Syrjälä Signed-off-by: Caz Yokoyama

[Intel-gfx] [PATCH CI 1/4] drm/i915/display/tgl+: Set default values for all registers in PIPE_MBUS_DBOX_CTL

MBUS_DBOX_B2B_TRANSACTIONS_MAX, MBUS_DBOX_B2B_TRANSACTIONS_DELAY and MBUS_DBOX_REGULATE_B2B_TRANSACTIONS_EN were being programmed with zeros while specification has different default values for this registers in display 12 and newer. While at it also converting all MBUS_DBOX macros to use REG_*

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dp: make DSC usage logging actually useful

== Series Details == Series: drm/i915/dp: make DSC usage logging actually useful URL : https://patchwork.freedesktop.org/series/101952/ State : failure == Summary == CI Bug Log - changes from CI_DRM_11416_full -> Patchwork_22731_full

  1   2   >